Продуктовая жизнь проектной разработки

Эта статья написана по мотивам моего выступления на 404.fest в сентябре 2019 года в Самаре. Я там рассказывал об интересной вещи, а именно о связи проектной и продуктовой разработки и некоторых приемах, помогающих жить проще в этой области.

Выровняем понятия, или Что такое продукт?

Что такое продукт применительно к ИТ-разработке? Для разработчиков ИТ-продукт – это долговременно развиваемая ИТ-система, программный либо программно-аппаратный комплекс, который нужен для выполнения определенных задач для различных клиентов. В этом определении важно то, что продукт, как правило, подразумевает определенный объем клиентов, каждый из которых имеет некие ожидания по отношению к продукту. При этом ожидания могут пересекаться, могут не пересекаться, а некоторые – вообще могут противоречить друг другу. Еще продукт отличает долговременность: в хорошем случае продукт может развиваться и 10, и 20 лет. В качестве примера долговременно развивающихся продуктов можно привести Windows или отдельные дистрибутивы Linux. Эти продукты на слуху, динамично развиваются – и по ходу своего развития претерпели существенные изменения.

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

Итак, проект – это деятельность, ограниченная временем, ресурсами и всегда с понятным на старте результатом к заданной дате. Соответственно, ИТ-проект – это проект, в результате которого получается определенный результат, приносящий пользу либо в том или ином продукте, либо самостоятельно. Важно отметить, что само понятие «проект» по своей сути может трактоваться по-разному в разных организациях. В какой-то организации проект ограничен бюджетом («все, что до 100 000 рублей – не проект»), где-то – деятельностью («все что не относится к информационным системам, не входящим в реестр – не проект»), где-то пользователи («если результат используют более N человек»), где-то проект – это деятельность, которая обязательно должна быть инициирована с соблюдением определенных процедур... В конце концов, «проект» или «не проект» может быть просто решением, принимаемом на определенном уровне. Но для того чтобы действительно развивать ИТ-продукты и ИТ в целом, важно понимать, где начинается и заканчивается «настоящий», а где «виртуальный» проект.

Теперь про процесс. Процесс, условно, представляет собой непрерывную деятельность. То, что происходит каждый день. Например, процессом применительно к ИТ является процесс написания кода или обработки обращений пользователей. Процесс отличается тем, что имеет входы («инициирующее воздействие») и выходы («результат»). Процесс отличается стандартизацией, то есть, как правило, протекает по одному и тому же алгоритму для схожих по сути инициирующих явлений.

Немного о связях и стратегии

Рассмотрим, как связаны процесс, проект и продукт применительно к продуктовой разработке. Основа разработки – это процесс, или, точнее, набор процессов. От сбора требований до выпуска продукта. Продукт – то, что получается в итоге процессной деятельности. Ну а проект – то, что позволяет финансировать процессы. Рассмотрим очень приближенную модель заработка компании, которая производит программное обеспечение. В случае с коммерческой компанией компания продает лицензии, сопровождение и услуги внедрения. Из заработанных таким образом денег выплачивается заработная плата, арендуется офис, обеспечиваются хозяйственные нужды компании и платятся налоги. Как все это связано с проектом, процессом, продуктом? Напрямую! Чтобы быть успешной компанией, которая приносит устойчивую прибыль и имеет возможность вкладываться в сотрудников, необходимо:

●                 производить востребованный продукт, который имеет реальную рыночную ценность;

●                 сделать так, чтобы продукт можно было легко попробовать и приобрести;

●                 обеспечивать конкурентоспособную заработную плату чтобы привлекать лучших специалистов;

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

Получается, что для компании ситуация выглядит так: больше зарабатываем – больше вкладываем в продукт и процессы – больше продаж – больше денег – лучше продукт. Идеальная картина, не так ли? К сожалению, в реальности все намного сложнее.

Например, что такое «идеальный продукт»? Как достичь состояния, когда продукт станет идеальным? В целом, ответ лежит в плоскости стратегического планирования продукта. Это значит, что у продукта должна быть стратегия развития (крупные блоки – что будет востребовано на рынке) и мелкие «кубики», составляющие эти блоки. Что характеризует отличный продукт? По сути, есть два противоречивых аспекта:

●                 наличие стратегии (куда идем);

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

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

Чем лучше продукт, тем больше у него потребителей. Чем больше потребителей у продукта – тем больше доход у вендора. Даже если это потребители, которые не платят прямо, косвенно они участвуют в монетизации. Через социальную рекламу («сарафанное радио») и рекламу в продукте (например, большинство бесплатных приложений из «Гугл Плэй» показывают рекламу только так).

Таким образом, цель производителя продукта в конечном итоге – сделать такой продукт, который бы хорошо монетизировался. Причем не надо забывать, что внутри этого самого вендора есть другие подразделения с другими целями (которые тем не менее коррелируются с основной целью). Например, есть подразделение продаж, их цель – максимизировать прибыль в каждый момент времени. Им более важна стратегия продаж, чем стратегия продукта. При этом данная ситуация абсолютно нормальна: «за продажи» спрашивают с них!

Жизнь как она есть

Как известно, жизнь – большая любительница внесения свои корректировок в прекрасные планы живущих. Представим себе ситуацию: есть компания – производитель ПО. Самого прекрасного программного продукта, который сделает мир лучше. У продукта есть свой Roadmap. Более того, у продукта есть своя продуктовая стратегия. И цели. И ресурсы уже распределены, запланированы. В этот момент приходит письмо из отдела продаж, в нем говорится: «Товарищи! у меня клиент! Большой! 1000… нет, 5000 лицензий в продаже, если мы прямо сейчас, в ближайшее время включим вот эту Очень Важную функцию!» Занавес? Если бы.

Еще раз напомню: любая продуктовая разработка живет за счет денег, которые в компанию приходят с рынка.

Вернемся к ситуации и рассмотрим ее со стороны «как должно быть».

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

Второе. Очень важная часть продуктовой разработки – процессы непрерывного улучшения продукта. Это формирование и тестирование гипотез, это формирование релизов, это стратегия, рынок, донесение до клиента...

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

Третье. Что будет, если мы в релиз заложим много roadmap-а? Скорее всего, появятся обиженные клиенты, которые годами ждут доработок. А что будет, если заложить в релиз много доработок под клиентов? Скорее всего, не оценит рынок. Особенно если эти доработки будут скрыты от всех (например, их надо «включать» отдельно). Тогда для них вообще ничего не изменится. Кстати, поэтому в релиз опасно закладывать много рефакторинга. У клиентов будет вопрос: «А что мы получаем нового?» Из моей практики близкое к идеальному соотношение представляет собой 60% роадмап, 30% проектные доработки и 10% – резерв или рефакторинг.

Про релизы и срочность

Возвращаясь к вопросу о том, что делать, если релиз уже идет, а туда приходят новые фичи, приведу алгоритм, которым пользуюсь сам.

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

●                 Это может быть просто маленькая доработка. Настолько маленькая, что никто и не заметит ничего.

●                 Это может быть большая доработка. Такая, которая занимает весь релиз, а то и больше.

●                 Это может быть доработка, которая больше половины релиза.

●                 Это может быть доработка, которая до 25% релиза.

●                 Это может быть доработка, которая до 10% релиза.

В зависимости от масштаба требуемой доработки выбираем стратегию. Какие стратегии/рецепты вообще могут быть?

Самое простое – можно взять и сделать. Это если доработка небольшая (в пределах рисков или допустимых погрешностей) или есть свободные разработчики. А что делать в остальных случаях?

Конкретных рецептов не так много, но они есть:

Можно торговаться и договариваться.

●       можно договориться о том, что что-то берем в релиз, а что-то делаем потом. Например, самая важная для заказчика функция включается в текущий релиз. Остальное – в следующие.

●       можно договориться о том, что все запрошенное делаем потом.

●       можно договориться, что все делаем сейчас (отмечу, что это наиболее болезненный вариант: придется менять планы производства, заморозить текущие доработки).

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

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

Резерв персонала:

●           дорого, но надежно – можно резервировать собственный персонал. Например, создать резерв сотрудников, 20–30%, которые занимаются оптимизациями и улучшениями, но «если что» – могут быстро перейти на разработку требований. Как развитие этой идеи – пул разработчиков, который разделяется между продуктами или направлениями. Тут, правда, есть риски, что, когда надо – никого не окажутся, все будут в соседних проектах;

●           в формате готовых разработчиков партнеров. Тут тоже есть свои тонкие моменты. Во-первых, разработчиков партнера надо готовить. То есть вкладывать в них время, усилия... Во-вторых, нет гарантии, что подготовленные разработчики в нужный момент времени не окажутся утилизированными на других проектах партнера.

Если говорить о партнерах, можно рассмотреть вариант, при котором RoadMap разрабатывается собственными силами, а доработки – выполняются с помощью партнеров. При наличии устойчивого спроса на доработки подобный подход позволяет развести разработку и почти неограниченно использовать ресурсы партнеров для решения клиентских проектных задач. В этой ситуации есть тонкость, даже две: приемка работы от подрядчика или как минимум авторский надзор – должен быть обеспечен со стороны вендора.

Немного из практики

Теперь – о тех рецептах, которые я видел и которые работают.

Во-первых, автоматизация всего, что можно, в процессе разработки. Использование CI, автотестирования – как обязательная часть процесса. Позволяет сэкономить на тестировании и качестве поставляемого продукта.

Во-вторых, неявный резерв времени в спринтах. Есть смысл резервировать порядка 10% времени в релизе на риски, и порядка 10% времени – на важные, но несрочные задачи. В итоге получается, что в критической ситуации 20% времени спринта можно освободить достаточно легко.

В-третьих, если 20% времени мало – стоит привлекать инициаторов других доработок, и вести переговоры со всеми заинтересованными сторонами.

Далее, о том, чего стоит избегать.

Первое, это форки. Иногда для скорости доработку проще сделать на ветке, отдать и забыть. Так ли все просто? Как показывает практика – нет. В моменте так, безусловно, быстрее, но потом возникают последствия в виде возможных тяжелых переносов кода из ветки в ветку, которые отнимают время команды (порой большее, чем на саму разработку). Можно, конечно, попробовать договориться о том, что делаем форк, и забываем про ветку... Скорее всего, с вами согласятся, а через какое-то время к вам же придут с тем, что «не работает» или завалят запросами на ТП ветки. В итоге на выходе на поддержке разработки оказывается столько похожих, но разных систем, сколько было веток.

Второе, это доработки, вредные для продукта.

Вообще говоря, вредность или полезность доработки для продукта – вещь достаточно субъективная. Даже если есть критерии полезности, то с большой вероятностью они будут опираться на субъективное мнение экспертов. Для себя я сформулировал так: доработка, которая ломает основной процесс и/или существенно усложняет его, является вредной. Так же вредной доработкой является доработка, при которой система теряет стабильность. В-третьих, а что делать, если просят именно это?

Вариантов тут немного:

Отказаться. Наверное, это допустимо где-то в идеальном мире. Но в жизни очень сложно обосновать отказ.

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

Взять и сделать. Тут тоже есть варианты:

■           включать данную функциональность на уровне настроек. По умолчанию – выключено;

■           если позволяет архитектура – сделать плагином/модулем (самый хороший способ, он не пугает заказчиков, которые случайно включили лишнее).

■           самый плохой и крайне не рекомендуемый способ – форки. О них я писал выше.

Вместо заключения

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