В статье хотел бы поделиться наблюдениями о вызовах, с которыми сегодня сталкиваются команды разработки, а также представить наработки, основанные на личном опыте руководства наукоемкими проектами и продуктами в нефтегазовой сфере.
Почему это актуально? В мире технологий мы находимся в условиях постоянно меняющихся потребностей и активной конкуренции. Успех наших решений и эффективность взаимодействия между собой напрямую влияют на наше будущее. Существует мнение, что в будущем будут две профессии: те, кто следит за компьютерами, и те, за кем следят компьютеры. Давайте обсудим, как адаптироваться к этим изменениям и оставаться на шаг впереди.
Дисклеймер
Естественно, не существует универсального решения, но постараюсь следовать методу «прогрессивного джипега». Это подход, при котором детали могут быть размытыми, но общее понимание складывается. Функционально изложенное ниже помогало автору и прошло проверку практикой. В зависимости от задач, личных предпочтений и стиля работы некоторые тезисы могут показаться спорными или пересекаться с существующими методологиями. Однако, если читатель найдет что-то полезное, значит, моя цель достигнута.
Преамбула
В 2016 году автор занял руководящую должность и, готовясь к этому шагу, наткнулся на доклад Германа Грефа о трансформации Сбербанка в Agile. Этот материал вызвал у меня отклик: в 2011 году в Петергофе я впервые столкнулся с электронной очередью, что произвело на меня впечатление – не нужно было спрашивать, кто последний. Логично предположить, что такой сервис стал результатом проекта и был упакован в соответствующий продукт. Полезно различать термины «проект» и «продукт», чтобы понять, чем мы на самом деле управляем – об этом будет первая часть статьи.
С 2016 года автор приобрел опыт управления проектами и продуктовыми командами в нефтегазовой отрасли под единым началом. Если кто-то работал в культуре, где проектные и продуктовые команды разделены, буду рад услышать ваши мысли в комментариях. Кстати, по информации ChatGPT, первым среди российских банков электронные очереди внедрил Альфа-банк в 2008 году.
Над чем мы работаем?
Перейдем к конкретике. Рассмотрим разработку с точки зрения проектов. Приведенная ниже схема может показаться тривиальной для руководителей, но полезна для разработчиков. Проект – это деятельность с четким началом и концом, обязательно с заказчиком. Он проходит три стадии: инициирование, выполнение и завершение. На стадии инициирования проводятся итерации с заказчиком, формируются техническое задание и календарный план. После того как договоры попадают в тематический план и сформированы проектные команды, начинается стадия выполнения под руководством проектных менеджеров.
Результаты проектов обычно включают в себя результаты интеллектуальной деятельности, такие как программы, код, расчеты, методики и другие артефакты, а также техническую и бухгалтерскую отчетность. В классическом проектном управлении результаты ожидаются в установленные сроки, с необходимым качеством и в рамках бюджета – это проверяется на стадии приемки. Существует множество методологий управления проектами, каждая из которых предлагает свои подходы для снижения рисков; выбирайте ту, которая наиболее соответствует вашим потребностям. Все они подчеркивают важность создания проектных артефактов, способствующих достижению целей. Умение эффективно исполнять договорные обязательства важно для устойчивого развития многих организаций. Однако давайте сосредоточимся на пользователе: какие у него ожидания?
Если спросить ChatGPT о том, каким общим термином можно обозначить результаты проектной деятельности и сборки ПО, с которыми взаимодействуют пользователи, то это будет готовое программное обеспечение.
Важно убедиться, что готовность бывает двух видов – с точки зрения разработчика и с точки зрения пользователя. Под разработчиком я имею ввиду поставщика ПО в целом, который не обязательно является отдельным программистом.
В пределе ИТ-продукт – это готовое ПО
Таким образом, в конечном счете ИТ-продукт – это готовое программное обеспечение, которое не только решает задачи пользователя, но и вызывает доверие, отвечая на вызовы времени. В этом контексте проект становится вспомогательным инструментом и одним из источников развития продукта, в ходе которого мы постоянно сверяем готовность с потребностями пользователей. Продемонстрирую связь между проектом и продуктом с помощью схемы, которую разработал.
Представим, что мы только начинаем выполнение проекта. На этом этапе заявок от пользователей еще нет, задачи проекта формализованы, технический долг отсутствует, а продуктовые гипотезы уже сформулированы Заказчиком. Двигаясь вправо, мы видим бэклог продукта – список задач текущего этапа. Еще правее находится план релизов, например, календарный график. Когда мы достигаем стадии сборки, необходимо сверить критерии готовности. Если повезет, в техническом задании четко прописаны процедуры приемки. Однако на практике это часто бывает не так. Заказчик может быть занят и попросить продемонстрировать какую-либо историю апробации и тестирования совместно с пользователями. Важно уметь использовать эту ситуацию в интересах продукта. Встает вопрос: как к этому подготовиться? Это необходимо, поскольку процесс получения обратной связи должен быть управляемым; в противном случае могут возникнуть антипаттерны, которые мы можем назвать «граблями». Я поделюсь своим опытом, расскажу о тех трудностях, с которыми сталкивался, и о том, как их избежать.
Антипаттерны и паттерны сверки готовности ПО
Рассмотрим матрицу, где по оси Y отложена ваша внутренняя оценка готовности продукта на тот момент времени, когда будет передаваться обновление на внешнее использование. По оси X отложена оценка готовности пользователя к приемке. Готов означает пользователь опытен в данном классе ПО. При этом совершенно необязательно, что он заинтересован именно в нашей реализации. Не готов означает высокую занятость или данное ПО для него в новинку.
Итак, первые грабли по величине ущерба имиджу – это вслепую отправить экспертам сырое ПО с просьбой дать отзыв. Вы знаете, что оно сырое, он нет, иначе бы не взялся за экспертизу, поэтому будет тестировать сообразно своему разумению. Получите отрицательное заключение, будете итерировать и учиться на своих ошибках, возможно, при этом будет срыв сроков.
Вторые грабли – когда не вовлеченный пользователь получает сырое ПО, опять нехорошо – либо останетесь без ответа, либо проколетесь на простых тестах, так как в отличие от предыдущего случая продвинутые сценарии вряд ли будут протестированы
Третий вариант – фичи готовы к апробации. Независимая экспертиза здесь плоха в меньшей степени чем раньше, но «тайм то маркет» опять будет отложен.
Наконец, последние грабли, ваше ПО может, пользователь потенциально хочет, а мы про него не знаем и ничего не делаем. Так мы теряем инновационный потенциал продукта.
Об артефактах продукта
Вернемся к рисунку выше с артефактами продукта. Если нам удалось избежать «граблей», то контакт пользователя с сборкой уже состоялся, и в процессе решения задач будут поступать заявки. Их необходимо собирать в журнал заявок и связывать с проектными задачами. В простом случае следующий этап проекта может быть ориентирован на выполнение этих заявок, в более сложном – ожидаться инкремент функциональности, а в еще более сложном — запуск смежного проекта, использующего нашу версию продукта.
Кроме того, всегда возникает технический долг, как явный, так и неявный, которым нужно управлять. Игнорирование этого долга может привести к росту стоимости изменений в программном коде. Чем, например, отличается успешный продукт от неуспешного? Успешный продукт приносит больше дохода, чем затраты на его разработку. В этом контексте важен такой артефакт, как единый бэклог продукта. Однако его создание – это только первый шаг.
Первый вызов заключается в том, чтобы определить метрики, по которым готовность ПО вырастет, например, через год. Второй вызов – на основе этих метрик и с учетом обратного отсчета сформировать план достижения целей. Здесь помогут такие артефакты, как дорожная карта продукта, план релизов и карта событий.
Продукт ≠ Проект
• Продукт невозможен без формализации и отслеживания целевых метрик качества и внедрения, в проекте, по-умолчанию, это необязательный атрибут
• Продукт развивается за счет проектов, в том числе внутренних, объединенных общей дорожной картой
• Продукт, как и проект, может финансироваться из разных договоров
• Продукт не обязательно является результатом проекта
• В жизненном цикле продукта защита этапа проекта это один из критериев готовности ПО, но не единственный
• Продукт всегда имеет технический долг, явный или неявный, которым нужно управлять
Что важно отметить и этот проверено личным опытом – в пределе продуктовая команда способна самостоятельно синтезировать и достигать метрики развития, даже в условиях неопределенности, через эмпатию к пользователю (продуктовое мышление) и планирование обратным счетом (продуктовый подход).
О роли командного взаимодействии и продуктовом подходе
В авиации существует профессия диспетчера по центровке грузов, который отвечает за распределение грузов на борту самолета для обеспечения безопасности и экономии топлива. При взлете критична задняя центровка, а при посадке – передняя. Поэтому иногда диспетчер сопровождает самолет в полете.
Можно ли выделить, кто важнее для доставки груза: летный экипаж или диспетчер? На мой взгляд, это невозможно. Часто возникает вопрос о том, кто отвечает за выпуск релиза. Этот вопрос некорректен до тех пор, пока не будет достигнуто общее понимание того, что:
Ответственность и риск: Ответственность за результат всегда несет риск.
Обоснование риска: Риск должен быть оправдан, для чего необходимы регламенты и соглашения в рамках системы продуктового подхода.
В продуктовом подходе мы должны регулярно синхронизироваться друг с другом на всех этапах разработки – от планирования спринта до выпуска релиза, охватывая несколько направлений (командные вызовы, условно soft- и hard-циклы продуктовой разработки):
На вопрос зачем продуктовое мышление разработчику ПО, можно сделать отдельные упражнение..
Скрытый текст
Для того, чтобы быть в тренде цифровой трансформации отрасли
Для того, чтобы быть в курсе состояния своего продукта, а также смежных продуктов
Для того, чтобы экспериментировать с технологиями
Для того, чтобы было время на «заточку пилы» и рефакторинг
Для того, чтобы оказывать влияние на развитие продукта своими идеями
Для того, чтобы совместно с командой планировать знаковые события
Для того, чтобы научиться рисковать и брать на себя ответственность за результат
Для того, чтобы прокачивать свои софт скиллы
Для того, чтобы быть конкурентно‑способным на рынке
Для того, чтобы получать удовольствие от процесса разработки
В итоге как «поженить» проектную разработку и продуктовую?
• Определиться с портфелем продуктов, существующих или создаваемых, поместить их в единое информационное поле
• Двигаться «методом прогрессивного джипега» и создать артефакты продуктов версии, поместить их в единое информационное поле
• Провести эксперимент продуктовых команд по выполнению дорожных карт при одном обязательном условии – выполнение в срок и с должным качеством тематического плана проектов
• Поместить внешние артефакты продуктов в единое информационное поле с пользователями и заказчиками
Бонус
Шаблон дорожной карты продукта в Excel
В заключение прошу высказаться практиков продуктовой разработки по кейсам перехода со стороны проектной разработки
