«Поставьте, пожалуйста, исполнителей в задачах»
«Залогируйте время»
«Почему мы не успеваем по спринту?»
«У нас горит план на год!»

Вы управляете разработкой и узнали свою команду в этих фразах? 

Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC.

Недавно мы записали выпуск подкаста «Мы обречены»‎ с Артемом Малышевым и Филом Ранжиным про то, как управлять разработкой так, чтобы команда не превращалась в конвейер по перемещению тасков. 

В статье — кратко о том, что мы обсудили в подкасте. Полную версию подкаста смотрите на любом удобном видеохостинге. 

Проблема вашей команды не в ленивых разработчиках, а в устаревшей системе управления. Давайте разберемся, как это изменить.

Принцип 1: Перестаньте быть «школьным учителем». Управляйте неопределенностью, а не планами

Проблема

Вы создаете «расписание на четверть» — детальные планы на год вперед в мире, который меняется каждый квартал.

Проектный подход работает как школа: открыли дневник, знаете, что завтра математика, русский и английский. Так до конца четверти. Все предсказуемо и понятно.

Но в разработке это не работает. Вот реальная история из нашей практики в SimpleOne SDLC.

В прошлом году к нам приходили потенциальные клиенты и говорили: «Нам нужна интеграция с GitLab». Просто все подряд — каждый второй. Мы послушали рынок, сделали интеграцию. Начался новый год — те же самые компании приходят: «Слушайте, нам эта интеграция с GitLab, если честно, не нужна. А вот диаграмма Ганта нам, конечно, нужна».

Окей, мы начинаем работать над диаграммой Ганта. Проходит еще несколько месяцев, сейчас все приходят и говорят: «Слушайте, Ганта, если честно, не очень нужна. Нам база знаний нужна».

Запросы постоянно меняются. И это нормально — рынок живой, потребности бизнеса меняются. Мы могли бы спланировать красивый роадмап на год-два вперед, сказать «мы вот так делаем». А рынок придет и скажет: «Слушайте, это, конечно, круто, но мы уже передумали».   

Решение

Примите простую вещь: вы не можете знать, что будет через год. И это нормально.

Продуктовый подход говорит: мы не знаем, что будет завтра. Возможно, математика завтра не понадобится, потому что откроют новую формулу. Поэтому сегодня занимаемся математикой, а завтра посмотрим ближе к делу.

Мы в SimpleOne перестраиваем бэклоги почти каждый квартал. Понимаем, что рынок вот здесь сейчас поменялся. Вместо жесткого плана создаем гибкий бэклог, который регулярно пересматривается.

Принцип 2: Забудьте про детальки. Создавайте команду единомышленников

Проблема

Разработчик получает спецификацию от аналитика, пишет код, передает тестировщику. Он — винтик в системе, который не видит целой картины.

Проблема многих разработчиков — они просто деталька. К ним приходит задача, они думают: «Ладно, аналитик мне обозначил спецификацию, я ее напишу». Чем такой разработчик отличается от искусственного интеллекта? Только тем, что у него больше знаний. Но это вопрос времени.

Человек должен творить. Он должен приходить и предлагать: «Ребята, ну фигню мы делаем, давайте перепишем». Я очень люблю таких разработчиков, которые приходят и говорят: «Блин, мы, конечно, такое наколхозили, придется переписать». Я всеми руками и ногами за это.

Решение

Ломайте функциональные «колодцы». Когда аналитик пишет аналитику, разработчик делает разработку, тестировщик тестирование — они все сидят и ничего не делают, пока до них не дойдет очередь.

Мы внедрили другой подход. Аналитик собрал требования с владельцем продукта на верхнем уровне. Разработчик накидал прототип, посмотрел, какой тип данных можем использовать. Аналитик накидал примерные тезисы спецификации, тестировщик параллельно накидал тест-план.

Все три человека работают. Да, с разными усилиями. Но плюс-минус все работают. 

Принцип 3: Прекратите мотивировать через KPI. Мотивируйте смыслом

Проблема

KPI «сделать 10 тасков» или «закрыть спринт без переносов» приводят к тому, что команда учится получать пятерки, а не знать предмет.

Это как с ребенком в школе — хотим, чтобы он учился на отлично. Приходим к ребенку и говорим: «Ты будешь получать тысячу рублей за пятерки». Вроде хорошая мотивация? Ребенок начинает получать пятерки. А потом понимаем, что ребенок не то чтобы учится — он просто получает пятерки. Находит, как списать, как подойти к учителю с конфетками.

Наша изначальная цель была обучить ребенка. Мы дали понятную задачу, дали деньги — человек должен делать то, что мы хотим. Но на деле он идет самым коротким путем.

Так же и в разработке. Когда ставим KPI на количество фичей, человек не будет делать хорошие фичи— он будет делать максимум фичей.

Решение

Откажитесь от KPI, привязанных к процессу. Вместо этого привязывайте команду к успеху продукта.

Артем Малышев рассказал на подкасте: «На прошлой работе я работал с задачей с промокодами для подписки. У меня был классный дашборд: сколько существует промокодов, сколько сработало, сколько перешли в платную подписку. Я мог зайти утром и посмотреть: сколько сейчас человек в онлайне, сколько всего зарегистрировано пользователей, сколько пользуются подпиской. 

Сидеть и смотреть на это было очень классно — это превращало работу в игру. Нематериальная мотивация — самая важная. Когда тебе интересно — это самая большая мотивация работать».

[Почему измерять ≠ управлять: как KPI искажают реальность и какой инструмент использовать осознанному руководителю — Читать в статье]

Принцип 4: Перестаньте требовать часы. Начинайте требовать ценность

Проблема

Логирование каждого часа — иллюзия контроля. На практике это приводит к массовому творчеству в табелях в конце месяца.

Я до сих пор помню случай из работы в офисе. В конце дня коллега спрашивает: «А что, мы время списывать будем?», ей отвечают: «Да, сейчас пишем на эту задачу 8 часов, и всё». При этом весь день они просто общались.

Так происходит, к сожалению. Меня мучило больше всего это логирование времени. 

Артем поделился аналогичной историей из своего опыта: «Рано или поздно я переставал этим заниматься. Наставал момент, когда надо было и за полгода это сделать. Уже нельзя залогировать время в задачу полгода назад, приходится писать менеджеру: “Открой, пожалуйста, заново, и я залогирую время”».

Идея здравая: это делается чтобы мы понимали, какая у нас производительность. Не для того, чтобы разобраться, кто ничего не делает, а для того, чтобы понять, сколько мы в среднем тратим на задачи времени. Если бы это время логировали честно —  оно бы, может, и работало. Но никто никогда его честно не будет логировать — это все делают конце месяца.

Решение

Вы платите команде за результат и экспертизу, а не за отсиженные часы.

В методологии Scrum говорится: мы платим людям зарплату за месяц, за функциональность в целом. Неважно, человек проработал 2 часа или 10 часов. Это уже вопрос статистики.

У нас есть команда, есть фонд оплаты труда для этой команды. Мы понимаем, сколько времени они затратили и можем примерно оценить стоимость продукта — стоимость наших инвестиций в этот продукт.

Используйте стори-поинты для относительной оценки сложности, а не для подсчета трудозатрат. Scrum также говорит, что достаточно стори-поинтов, оценки и просто статистики. Нет смысла погружаться глубже. Часы — бессмысленная история, потому что вы никогда не попадете в них.

Принцип 5: Наймите лидера, а не прокси. Правильно расставьте роли

Проблема

Владелец продукта часто становится просто переводчиком с языка бизнеса на язык разработки, не имея полномочий принимать решения.

Я слышал, люди говорят про это как про что-то хорошее: «Владелец продукта должен объяснить разработке, что от него хотят пользователи, клиенты, инвесторы». Это прокси, переводчик. Если они хотят владельца продукта, который может гибко подстроить продукт под причины, нишу, рынки — это другой вопрос.

Есть даже кривая владельца продукта. Самая нижняя точка на этой кривой — когда владелец продукта становится прокси, и у него минимальная производительность. Он просто переводит запросы инвесторов на язык разработки.

Идеальный вариант — это генеральный директор. Человек, который может всё: у него есть бюджеты, команда, последнее слово и максимальная производительность. Тогда продукт может достаточно гибко развиваться, потому что PO не надо бегать согласовывать бюджет.

Решение

Настоящий владелец продукта — это мини-генеральный директор. Он должен:

• владеть видением и стратегией продукта;

• иметь бюджет и право его тратить;

• приоритизировать бэклог, основываясь на данных, а не на указаниях сверху.

Заключение: С чего начать изменения?

Управление разработкой — не про таски и часы. Это про создание культуры, в которой умные люди объединены общей целью, имеют свободу для творчества и видят результаты своего труда.

Когда гендиректор приходит и говорит: «У меня команда — они меня задолбали, они все делают медленно и поэтапно», первым делом я спрашиваю у него: а что он хочет? Как он контролирует?

Очень важно понять, насколько генеральный директор готов делегировать. Если он все время будет приходить и говорить: «Надо сделать это завтра», то владелец продукта никогда не будет владельцем продукта — он просто прослойка.

Первый шаг: проведите ретроспективу и честно спросите команду: «Что из того, что мы делаем, на самом деле не имеет смысла? Что мешает вам делать крутой продукт?»

Начните с малого: внедрите один из принципов, добейтесь в нем успеха и двигайтесь дальше. Ваша цель — перестать управлять тасками и начать управлять разработкой.