«Поставьте, пожалуйста, исполнителей в задачах»
«Залогируйте время»
«Почему мы не успеваем по спринту?»
«У нас горит план на год!»
Вы управляете разработкой и узнали свою команду в этих фразах?
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC.
Недавно мы записали выпуск подкаста «Мы обречены» с Артемом Малышевым и Филом Ранжиным про то, как управлять разработкой так, чтобы команда не превращалась в конвейер по перемещению тасков.
В статье — кратко о том, что мы обсудили в подкасте. Полную версию подкаста смотрите на любом удобном видеохостинге.
Проблема вашей команды не в ленивых разработчиках, а в устаревшей системе управления. Давайте разберемся, как это изменить.
Принцип 1: Перестаньте быть «школьным учителем». Управляйте неопределенностью, а не планами
Проблема
Вы создаете «расписание на четверть» — детальные планы на год вперед в мире, который меняется каждый квартал.
Проектный подход работает как школа: открыли дневник, знаете, что завтра математика, русский и английский. Так до конца четверти. Все предсказуемо и понятно.
Но в разработке это не работает. Вот реальная история из нашей практики в SimpleOne SDLC.
В прошлом году к нам приходили потенциальные клиенты и говорили: «Нам нужна интеграция с GitLab». Просто все подряд — каждый второй. Мы послушали рынок, сделали интеграцию. Начался новый год — те же самые компании приходят: «Слушайте, нам эта интеграция с GitLab, если честно, не нужна. А вот диаграмма Ганта нам, конечно, нужна».
Окей, мы начинаем работать над диаграммой Ганта. Проходит еще несколько месяцев, сейчас все приходят и говорят: «Слушайте, Ганта, если честно, не очень нужна. Нам база знаний нужна».
Запросы постоянно меняются. И это нормально — рынок живой, потребности бизнеса меняются. Мы могли бы спланировать красивый роадмап на год-два вперед, сказать «мы вот так делаем». А рынок придет и скажет: «Слушайте, это, конечно, круто, но мы уже передумали».
Решение
Примите простую вещь: вы не можете знать, что будет через год. И это нормально.
Продуктовый подход говорит: мы не знаем, что будет завтра. Возможно, математика завтра не понадобится, потому что откроют новую формулу. Поэтому сегодня занимаемся математикой, а завтра посмотрим ближе к делу.
Мы в SimpleOne перестраиваем бэклоги почти каждый квартал. Понимаем, что рынок вот здесь сейчас поменялся. Вместо жесткого плана создаем гибкий бэклог, который регулярно пересматривается.
Принцип 2: Забудьте про детальки. Создавайте команду единомышленников
Проблема
Разработчик получает спецификацию от аналитика, пишет код, передает тестировщику. Он — винтик в системе, который не видит целой картины.
Проблема многих разработчиков — они просто деталька. К ним приходит задача, они думают: «Ладно, аналитик мне обозначил спецификацию, я ее напишу». Чем такой разработчик отличается от искусственного интеллекта? Только тем, что у него больше знаний. Но это вопрос времени.
Человек должен творить. Он должен приходить и предлагать: «Ребята, ну фигню мы делаем, давайте перепишем». Я очень люблю таких разработчиков, которые приходят и говорят: «Блин, мы, конечно, такое наколхозили, придется переписать». Я всеми руками и ногами за это.
Решение
Ломайте функциональные «колодцы». Когда аналитик пишет аналитику, разработчик делает разработку, тестировщик тестирование — они все сидят и ничего не делают, пока до них не дойдет очередь.
Мы внедрили другой подход. Аналитик собрал требования с владельцем продукта на верхнем уровне. Разработчик накидал прототип, посмотрел, какой тип данных можем использовать. Аналитик накидал примерные тезисы спецификации, тестировщик параллельно накидал тест-план.
Все три человека работают. Да, с разными усилиями. Но плюс-минус все работают.
Принцип 3: Прекратите мотивировать через KPI. Мотивируйте смыслом
Проблема
KPI «сделать 10 тасков» или «закрыть спринт без переносов» приводят к тому, что команда учится получать пятерки, а не знать предмет.
Это как с ребенком в школе — хотим, чтобы он учился на отлично. Приходим к ребенку и говорим: «Ты будешь получать тысячу рублей за пятерки». Вроде хорошая мотивация? Ребенок начинает получать пятерки. А потом понимаем, что ребенок не то чтобы учится — он просто получает пятерки. Находит, как списать, как подойти к учителю с конфетками.
Наша изначальная цель была обучить ребенка. Мы дали понятную задачу, дали деньги — человек должен делать то, что мы хотим. Но на деле он идет самым коротким путем.
Так же и в разработке. Когда ставим KPI на количество фичей, человек не будет делать хорошие фичи— он будет делать максимум фичей.
Решение
Откажитесь от KPI, привязанных к процессу. Вместо этого привязывайте команду к успеху продукта.
Артем Малышев рассказал на подкасте: «На прошлой работе я работал с задачей с промокодами для подписки. У меня был классный дашборд: сколько существует промокодов, сколько сработало, сколько перешли в платную подписку. Я мог зайти утром и посмотреть: сколько сейчас человек в онлайне, сколько всего зарегистрировано пользователей, сколько пользуются подпиской.
Сидеть и смотреть на это было очень классно — это превращало работу в игру. Нематериальная мотивация — самая важная. Когда тебе интересно — это самая большая мотивация работать».
[Почему измерять ≠ управлять: как KPI искажают реальность и какой инструмент использовать осознанному руководителю — Читать в статье]
Принцип 4: Перестаньте требовать часы. Начинайте требовать ценность
Проблема
Логирование каждого часа — иллюзия контроля. На практике это приводит к массовому творчеству в табелях в конце месяца.
Я до сих пор помню случай из работы в офисе. В конце дня коллега спрашивает: «А что, мы время списывать будем?», ей отвечают: «Да, сейчас пишем на эту задачу 8 часов, и всё». При этом весь день они просто общались.
Так происходит, к сожалению. Меня мучило больше всего это логирование времени.
Артем поделился аналогичной историей из своего опыта: «Рано или поздно я переставал этим заниматься. Наставал момент, когда надо было и за полгода это сделать. Уже нельзя залогировать время в задачу полгода назад, приходится писать менеджеру: “Открой, пожалуйста, заново, и я залогирую время”».
Идея здравая: это делается чтобы мы понимали, какая у нас производительность. Не для того, чтобы разобраться, кто ничего не делает, а для того, чтобы понять, сколько мы в среднем тратим на задачи времени. Если бы это время логировали честно — оно бы, может, и работало. Но никто никогда его честно не будет логировать — это все делают конце месяца.
Решение
Вы платите команде за результат и экспертизу, а не за отсиженные часы.
В методологии Scrum говорится: мы платим людям зарплату за месяц, за функциональность в целом. Неважно, человек проработал 2 часа или 10 часов. Это уже вопрос статистики.
У нас есть команда, есть фонд оплаты труда для этой команды. Мы понимаем, сколько времени они затратили и можем примерно оценить стоимость продукта — стоимость наших инвестиций в этот продукт.
Используйте стори-поинты для относительной оценки сложности, а не для подсчета трудозатрат. Scrum также говорит, что достаточно стори-поинтов, оценки и просто статистики. Нет смысла погружаться глубже. Часы — бессмысленная история, потому что вы никогда не попадете в них.
Принцип 5: Наймите лидера, а не прокси. Правильно расставьте роли
Проблема
Владелец продукта часто становится просто переводчиком с языка бизнеса на язык разработки, не имея полномочий принимать решения.
Я слышал, люди говорят про это как про что-то хорошее: «Владелец продукта должен объяснить разработке, что от него хотят пользователи, клиенты, инвесторы». Это прокси, переводчик. Если они хотят владельца продукта, который может гибко подстроить продукт под причины, нишу, рынки — это другой вопрос.
Есть даже кривая владельца продукта. Самая нижняя точка на этой кривой — когда владелец продукта становится прокси, и у него минимальная производительность. Он просто переводит запросы инвесторов на язык разработки.
Идеальный вариант — это генеральный директор. Человек, который может всё: у него есть бюджеты, команда, последнее слово и максимальная производительность. Тогда продукт может достаточно гибко развиваться, потому что PO не надо бегать согласовывать бюджет.
Решение
Настоящий владелец продукта — это мини-генеральный директор. Он должен:
-
владеть видением и стратегией продукта;
-
иметь бюджет и право его тратить;
-
приоритизировать бэклог, основываясь на данных, а не на указаниях сверху.
Заключение: С чего начать изменения?
Управление разработкой — не про таски и часы. Это про создание культуры, в которой умные люди объединены общей целью, имеют свободу для творчества и видят результаты своего труда.
Когда гендиректор приходит и говорит: «У меня команда — они меня задолбали, они все делают медленно и поэтапно», первым делом я спрашиваю у него: а что он хочет? Как он контролирует?
Очень важно понять, насколько генеральный директор готов делегировать. Если он все время будет приходить и говорить: «Надо сделать это завтра», то владелец продукта никогда не будет владельцем продукта — он просто прослойка.
Первый шаг: проведите ретроспективу и честно спросите команду: «Что из того, что мы делаем, на самом деле не имеет смысла? Что мешает вам делать крутой продукт?»
Начните с малого: внедрите один из принципов, добейтесь в нем успеха и двигайтесь дальше. Ваша цель — перестать управлять тасками и начать управлять разработкой.
Автор: SimpleOne_it
