Какова роль Product Engineering в разработке цифровых продуктов?

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

Для более полного освещения этой темы я счел нужным взять в соавторы моего коллегу Павла Максимова, лид-менеджера Akhter Studios, имеющего многолетний опыт управления различными командами в сфере разработки ПО. Благодаря его ценным мыслям и комментариям часть очерка об организации спринтов значительно выиграла в плане фактологии.

Продакт-инжиниринг vs. software development

В это трудно сейчас поверить, но в истории кодинга (software development) был такой длительный период, когда рядовым программистам приходилось заниматься буквально всем, что касалось создания цифровых продуктов: от системной архитектуры и бизнес-аналитики до разработки дизайна интерфейса. Даже сейчас эта ниша универсалов-многостаночников (full-stack developer) вполне процветает, пусть и в ограниченном объеме.

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

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

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

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

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

Казалось бы, продакт-инжиниринг в целом соотносится с понятием software development, ведь он охватывает все основные процессы производства цифровых продуктов. Тем не менее эти понятия не являются синонимичными. Новизна данного подхода состоит в замене привычной проектной иерархии на методологию Agile, которая в корне меняет отношение программиста к сути того, чем он занимается. Об этом расскажет Павел Максимов во второй части статьи.

Роль продуктовых исследований и дизайна в постановке задач

В своей прошлой статье «В чем ценность Product discovery для начинающих бизнесменов», посвященной фазе продакт-дискавери, я подробно рассказывал о важности исследований в продуктовом подходе.

Только с помощью исследований команда разработчиков может получить ответ на ряд жизненно важных вопросов, без решения которых работа над заказом грозит превратиться в бесконечный бег по замкнутому кругу:
- Насколько актуальным будет приложение или сервис на предполагаемом рынке?
- Какими важными свойствами должен обладать продукт, чтобы завоевать внимание?
- Что движет людьми, чего они ожидают от нас?
- Какие качества целевой аудитории могут оказаться полезными для заказчика?

Кроме этих знаний, исследования дают ответ на ряд важных общемаркетинговых вопросов, которыми не следует пренебрегать даже в эпоху цифры:
- Как выстроить финансовую модель — то есть где клиент будет тратить и зарабатывать деньги.
- С помощью чего расписать первичный функционал.
- Для чего нужно знать примерный объем рынка.

Весь этот массив запросов обрабатывается продакт-оунером с одной целью — составить и детализировать так называемый БФТ к будущему продукту (Бизнес Функциональные Требования) — основополагающий документ, в котором без углубления в технические спецификации излагается логика работы всей системы или приложения.

В пакет исследований также входит готовая документация и заключение в виде артефактов. Таким образом команда под управлением продакт-оунера заявляет об общем понимании ею поставленных задач, специфики рынка и особенностей целевой аудитории. Этот набор знаний может быть подкреплен презентацией и КП (коммерческое предложение) для отправки в разработку.

После того как БФТ сформулировано, к работе подключается продуктовый дизайнер, который путем анализа и экспериментов воздвигает жизнеспособную концепцию будущего сервиса или программы. Подробней о фазе продакт-дизайна вы можете прочесть в моей статье «Как донести до клиентов важность продакт-дизайна?», где рассказывается об отличиях между продакт-дизайном и UX/UI.

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

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

Кроме дизайнера, продакт-менеджер и продакт-оунер часто подключают к работе QA-инженера, чтобы протестировать рабочую модель продукта и выявить скрытые проблемы. В таких случаях присутствие дев-команды (то бишь программистов), хотя бы в точечном формате, тоже бывает очень полезным.

Миссия технической команды

В конечном счете в техзадании должны найти свое отражение все ключевые требования клиента. Особенно важен на этом этапе вклад системного аналитика: он считывает и анализирует спецификации исходных программ, проводит серию интервью с заказчиком. Например, если требуется создать мультиплатформенное приложение, то будет использован стек Flutter, а если клиент хочет ограничиться платформами iOS и MacOS, то подойдет язык программирования Swift.

Пока финализируются БФТ и техзадание, дорабатываются все оставшиеся артефакты, которые необходимы для передачи в фазу инжиниринга, в свои права вступает техническая команда. Ей скоро предстоит запустить ряд важных процедур:
- Создание архитектуры продукта — выбор краеугольных элементов организации всего приложения или сервиса.
- Развертывание так называемой среды разработки (dev) — подключение сервера, на котором программисты будут кодить.
- Заведение необходимых артефактов для кодинга — в программировании термин «артефакты» описывает ключевые рабочие документы.
- Отладка алгоритмов — это workflow всей команды, то есть последовательность действий, обусловленная причинно-следственной связью и логикой программирования.

Ближайшая цель на данном этапе инженерной работы — создать архитектуру программы, которая, подобно каркасу или фундаменту, будет способствовать гладкому процессу написания кода и обслуживания готового ПО. От этого зависит и перспектива развития продукта в будущем: хорошая архитектура позволяет легко тестировать результаты труда инженеров, добавлять новый функционал и интегрировать с другими системами.

Итогом технической работы должны стать элементы для сборки MVP (minimum viable product — минимально жизнеспособный продукт), обладающего ограниченным функционалом, но вполне пригодного для испытаний, либо уже готовое к запуску ПО.

Этап тестирования

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

Очевидно, что на выходе каждый образец ПО должен решать одну или несколько основных задач, заложенных в него в начале проектирования. Если вы создаете приложение для получения скидок в фитнес-центрах, то вас в первую очередь должно волновать, как программа справляется с основной задачей. Такой вид тестирования называется функциональным, оно позволяет выявить ЧТО именно в программе работает/не работает.

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

По итогам тестирования готовится отчет с перечнем доработок и настроек всех модулей.

Работа над релизом

После того, как QA-специалисты завершили тестирование, а кодеры исправили все ошибки, готовое цифровое изделие передается в пользование заказчику. Как и в случае с любым сложным техническим устройством, процесс сдачи/приемки сопровождается целым набором процедур, из которых следует отметить самые главные: подготовка документации и инструкций пользователя, обучение представителей клиента, передача исходников, дизайн-системы, элементов фирменного стиля.

Продуктовая команда стремится не ограничивать возможности своего участия в будущей судьбе продукта, поэтому обязательно предлагает заказчику дополнительную фазу продвижения – product launch. Особенно это важно, если команда обладает значительной экспертизой и опытом запуска ПО, следовательно может создать для клиента целостную стратегию по продвижению и развитию продукта. Данная тема хорошо проработана на практике, поэтому продакт-менеджеры всегда могут предложить заказчику различные подходы типа «Стратегия Go-to-Market», PMF (product/market fit) и мн. др. Этому большому финальному этапу цифрового производства я планирую посвятить отдельный материал, благо там есть о чем рассказать.

Принципы управления в продакт-инжиниринге

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

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

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

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

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

В соответствии с этим мы действуем по инкрементальной схеме (incremental life cycle). Особенность данного подхода заключается в том, что программисты сдают клиенту работу отдельными завершенными фрагментами, практически готовыми к использованию. Каждая такая единица нашего труда называется инкрементом.

В качестве основной техники мы используем Scrum, что подразумевает работу спринтами — хронологически равными итерациями по 1-2 недели. Учитывая, что продакт-инжиниринг относится к фазе глубокой разработки, к началу инженерных работ все артефакты должны быть качественно прописаны: созданы «эпики» (крупные этапы работы) и «сторики» (небольшие задания в составе эпиков). Необходимо убедиться, что задачи как следует «прогрумлены», то есть бэклог продукта изучен и проработан всеми заинтересованными участниками, а текущий спринт спланирован полностью.

В конце каждого спринта мы стараемся предоставить клиенту очередной инкремент, причем в таком виде, чтобы его можно было либо сразу запустить в работу, либо протестировать и изучить на предмет дальнейшего использования в бизнесе. Все это происходит, конечно, под неусыпным оком продакт-оунера, который продолжает сопровождать готовый модуль после релиза. Он заносит в бэклог обнаруженные «баги» (ошибки), изучает реакцию и действия пользователей (customer journey), одним словом, готовит участников к следующей итерации. 

Со временем все продуктовые команды оттачивают собственный стиль производства, выпуская улучшенные версии рабочего фреймворка. Например, в нашей компании вышла уже 9-я редакция нашего workflow. Каждая такая версия строится на основе обратной связи от клиентами и проектными группами, и, соответственно, с каждой версией команда растет и масштабируется.

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