Привет, Хабр. Меня зовут Алексей Бруевич, я руковожу продуктовой разработкой в Почте Mail. Хочу рассказать о граблях, на которые наступал в своей карьере я и команды разного уровня зрелости под моим руководством. То есть расскажу об антипаттернах, с которыми вы можете столкнуться, и как их можно преодолеть, чтобы успешно запускать проекты.

Первая заметка: не берись за всё подряд

Это случай из моей практики, я тогда ещё не был тимлидом. Наслушавшись идей начальника, я, окрылённый, побежал их реализовывать. Спустя некоторое время начальник меня спросил: «А зачем мы всё это сделали?» Это был очень важный для меня урок.

Что пошло не так?

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

• Ресурсы потрачены впустую. Команда тратила время на задачу, которая, возможно, и не требовалась.

• Репутационные потери. Кто отвечает за этот провал? Я считаю, что отвечает тот, кто взял задачу в таком виде и начал её делать.

Как подобного избежать?

Разобраться, зачем нужно делать эту задачу. Какую проблему клиента или бизнеса мы решаем? Как понять, что эта проблема вообще существует?

Оценить влияние на продуктовые метрики. Какие метрики изменятся и насколько? Например, если у команды цель на «деньги», то если команда потратит 3 млн на разработку фичи, которая даст выгоду в 1 млн, значит что-то точно сделано неправильно.

Есть ли более важные задачи? Возможно, сейчас есть другая задача, для решения которой можно потратить те же ресурсы, но получить больше пользы. Мы выявляем такие задачи с помощью методики RICE/ICE. 

Немного расскажу про RICE. Это методика оценки любых задач, чтобы присваивать им «баллы» и сравнивать друг с другом. 

Баллы RICE = (Reach × Impact × Confidence) / Effort,

где:

• Reach — сколько пользователей затронет;

• Impact — насколько сильно повлияет;

• Confidence — насколько уверены в оценке;

• Effort — трудозатраты.

Таким образом можно оценить все задачи по единой системе и сравнить их друг с другом. 

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

Вторая заметка: формируй образ результата

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

Что пошло не так?

У заказчика и исполнителя не совпали представления о конечном результате.

Как подобного избежать?

• Не бойтесь задавать вопросы. Чем больше спросите, тем больше информации соберёте, и тем выше шансы на запуск проекта. В нашей команде это работает именно так.

• При этом учитывайте культуру компании. Ремарка: в ряде организаций вопросы могут посчитать признаком слабости. Если это ваш случай, то постарайтесь сделать так, чтобы ваши вопросы воспринимались как ваша сильная сторона.

Как сформировать единый для всех образ результата?

• Выясните, кто принимает результат. Задачу мог принести вам начальник, но поставить её мог ещё более высокий руководитель. 

• Очень желательно понимать контекст, в котором «конечный заказчик» будет принимать результат. Так вы сможете лучше разобраться, в чём для него ценность задачи, на что он будет обращать внимание. Вы сможете выдвинуть гипотезы, возможно, даже напрямую обсудить с ним задачу. 

• Список вопросов, которые помогут собирать требования:

  • Опишите идеальный результат.

  • Какие критерии хорошо выполненной задачи?

  • Какие ограничения есть в ресурсах (люди, время, технологии, оборудование и т. д.).

  • Какие критерии «достаточного качества»: прототип или полноценная реализация?

  • Как будет проходить приёмка задачи? Что должно быть готово? 

Всё это соберите в едином документе, в любом формате, чтобы он был доступен и вам, и заказчику. Вы могли что-то неправильно понять, услышать или исказить, поэтому пусть заказчик проверит этот документ и подтвердит правильность. 

Когда требования к задаче скорректированы, можно приступать к работе. 

Рекомендация за скобками: выполняйте задачу прозрачно. Договоритесь с заказчиком, как и когда вы будете обновлять статус. Чем заказчик спокойнее, тем меньше он будет вас дёргать и тем больше к вам будет доверия. При этом мяч окажется на вашей стороне, вы станете управлять игрой.

Третья заметка: долго запрягаем, да быстро едем

Такое происходит очень часто. Начальник пришёл с хорошей и полезной задачей. Мы опытные, всё выяснили, собрали требования, определились с ожидаемым результатом. Нам дали всего месяц. Все собрались и начали быстро работать, сроки поджимают. И в конце вдруг понимаем, что неизвестно, как всё это запускать. У меня был случай, когда в архитектуре не учли необходимость проведения А/Б-тестов, и пришлось вносить правки, из-за которых релиз задержали на полторы недели.

Что пошло не так? 

Из-за того, что сроки сжаты, начали делать слишком рано. Команда не проработала задачу и потом столкнулась с неожиданностями, что привело к срыву сроков. Важно не спешить и достаточно прорабатывать задачу. 

Допустим, мы начали делать какую-то задачу, ошиблись при выработке требований, но заметили это на том же этапе. «Стоимость» исправления такой ошибки будет 1 единица. Если же мы найдём её позже, на этапе проектирования архитектуры, то исправление будет «стоить» 3 единицы. На этапе конструирования (программирования) — от 5 до 10. И обратите внимание, что после выпуска программного обеспечения «стоимость» исправления ошибки, допущенной при выработке требований, может достигать 100 единиц. 

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

Как подобного избежать?

Полностью подготовьтесь к решению, несмотря на внешнее давление со стороны начальства. Игнорируйте фразы вроде: «Вы ещё не начали писать?!» Важно вложить силы в подготовку, а не быстрое начало работ. 

Перед работой над большой задачей (длительностью примерно в месяц) мы в команде составляем и защищаем проектный документ. Затем исправляем найденные ошибки, и только после этого начинаем разрабатывать. 

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

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

Затем мы прорабатываем архитектуру, чтобы понимать, как мы будем запускать продукт, какие технологии использовать, какие будут взаимодействия. Обсуждаем, как тестировать задачу. Обращаю на это внимание, потому что раньше я пренебрегал этим, но оказалось, что продакты и разработчики — ребята очень творческие и могут нафантазировать такое решение, которое потом не получается протестировать. То есть вопросы со стороны тестирования могут внести изменения в CJM и проектирование архитектуры. 

Далее мы обсуждаем, как будем запускать систему и проводить A/Б-тесты, какая нагрузка ожидается, какие продуктовые метрики нужно отслеживать. 

После завершения документа мы его защищаем. Цель защиты — получить максимально проработанный план разработки, когда каждый участник команды понимает, что и как будет сделано. В защите должны участвовать все, кто будет задействован в реализации задачи. Происходит всё так: идём по структуре документа и рассказываем о каждом этапе. Идёт бурное обсуждение. Чем больше людей, тем больше будет вопросов и мнений, а это главное! Мы записываем все вопросы, после защиты их прорабатываем и, при необходимости, повторяем защиту. И так до тех пор, пока не отшлифуем документ. Обычно двух защит хватает для перехода к программированию. 

Теперь можно писать код.

Четвёртая заметка: не клади все яйца в одну корзину

Начальник принёс задачу, мы её проработали, начали делать, а перед запуском сообразили, что используемая технология работает не так. Мы в панике, дедлайн близок, на ходу что-то придумываем.

Что пошло не так?

Очень часто вижу, что команды не закладывают и не прорабатывают риски. То есть не продумывают план Б, план В. А это очень важно, потому что уже на этапе проектирования архитектуры вы можете учесть возможные неопределённости.

Как подобного избежать?

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

Как работать с рисками?

1. Идентифицируйте риски: что может пойти не так при разработке и запуске? Например, срыв сроков, задержки из-за другой команды, баги в эксплуатации и т. д.

2. Оцените риски от 1 до 5 по двум шкалам: вероятности (1 — маловероятно, 5 — почти наверняка случится) и серьёзности последствий (1 — не критично, 5 — провал задачи).

3. Составьте матрицу и приоритизируйте риски: низкими можно пренебречь, средние и высокие требуют подготовки. Чем выше степень риска, тем тщательнее нужно проработать свои действия на этот случай и тем внимательнее контролировать. 

4. Обработайте риски:

   1. избежать — изменить план так, чтобы риск не возник;

   2. снизить — придумать, как уменьшить вероятность или ущерб;

   3. принять — если это допустимо;

   4. передать — другим исполнителям (аутсорс, страховка, внешние подрядчики).

Важно всё это отразить в проектном документе. Здесь вы можете ознакомиться с примером окончательного документа.

Пирамида проекта

Напоследок снова обращусь к книге «Совершенный код» Стива МакКоннелла. На этот раз рекомендую воспользоваться идеей про пирамиду проекта. 

Чем ниже ступенька, тем она больше, и значит, тем больше времени нужно уделять соответствующему этапу. 

Резюме

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

• Что прошло хорошо? Не забудьте похвалить себя, это важно.

• Что можно улучшить?

• Что можно пообещать себе сделать в будущем проекте?

• Что можно изменить здесь и сейчас?

«Никто не может научить вас так, как ваш собственный опыт» 

Уильям Джеймс