Продуктовый инжиниринг в корне меняет подходы к созданию цифровых сервисов и приложений, фокусируясь не на количестве функций, а на ожиданиях и бизнес-целях клиентов.
Для более полного освещения этой темы я счел нужным взять в соавторы моего коллегу Павла Максимова, лид-менеджера Akhter Studios, имеющего многолетний опыт управления различными командами в сфере разработки ПО. Благодаря его ценным мыслям и комментариям часть очерка об организации спринтов значительно выиграла в плане фактологии.
Шамиль Ахмедов, CPO & Co-Founder 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, поэтому следует учитывать, что указанные сведения привязаны к особенностям моей команды и могут отличаться от стиля работы в других продуктовых компаниях.
Павел Максимов, CPMO (Chief Project Management Officer) Akhter Studios
Для начала скажу пару слов о так называемых циклах разработки ПО. Как понятно из названия, жизненный цикл означает некий период времени от запуска до завершения проекта. Последовательность событий внутри цикла состоит из следующих этапов: дизайн проекта → программирование → тестирование → готовность проекта.
Такая идеальная схема событий называется predictive life cycle, то есть прогнозируемый жизненный цикл.
Конечно, на практике в эту стройную картину неизбежно приходится вносить коррективы, исходящие, во-первых, от самого клиента, а во-вторых, от участников: тестировщиков, менеджеров, дизайнеров, аналитиков. Реакция команды на эти изменения и определяет характер избранного исполнителем стиля управления проектом.
Наша продуктовая компания работает по методологии Agile, следовательно, проповедует определенные ценности, присущие «гибким» методам управления: сотрудничество с заказчиком и стремление выдавать качественные решения на каждом шаге производства.
В соответствии с этим мы действуем по инкрементальной схеме (incremental life cycle). Особенность данного подхода заключается в том, что программисты сдают клиенту работу отдельными завершенными фрагментами, практически готовыми к использованию. Каждая такая единица нашего труда называется инкрементом.
В качестве основной техники мы используем Scrum, что подразумевает работу спринтами — хронологически равными итерациями по 1-2 недели. Учитывая, что продакт-инжиниринг относится к фазе глубокой разработки, к началу инженерных работ все артефакты должны быть качественно прописаны: созданы «эпики» (крупные этапы работы) и «сторики» (небольшие задания в составе эпиков). Необходимо убедиться, что задачи как следует «прогрумлены», то есть бэклог продукта изучен и проработан всеми заинтересованными участниками, а текущий спринт спланирован полностью.
В конце каждого спринта мы стараемся предоставить клиенту очередной инкремент, причем в таком виде, чтобы его можно было либо сразу запустить в работу, либо протестировать и изучить на предмет дальнейшего использования в бизнесе. Все это происходит, конечно, под неусыпным оком продакт-оунера, который продолжает сопровождать готовый модуль после релиза. Он заносит в бэклог обнаруженные «баги» (ошибки), изучает реакцию и действия пользователей (customer journey), одним словом, готовит участников к следующей итерации.
Со временем все продуктовые команды оттачивают собственный стиль производства, выпуская улучшенные версии рабочего фреймворка. Например, в нашей компании вышла уже 9-я редакция нашего workflow. Каждая такая версия строится на основе обратной связи от клиентами и проектными группами, и, соответственно, с каждой версией команда растет и масштабируется.
Надеюсь, наше совместное описание фазы продакт-инжиниринга окажется полезным для тех молодых бизнесменов, кто желает попробовать себя в IT-бизнесе и уже задумывается о формировании своей первой команды. Как неоднократно говорилось на самых разных медийных площадках, многие проекты часто стагнируют или даже закрываются, столкнувшись с критической нехваткой инженерной экспертизы. В таком случае хочется пожелать нашим читателям главного – обращать внимание на технический опыт управленцев, которым вы хотите доверить свой бизнес.
Подпишитесь на недельный обзор главных казахстанских и мировых событий
По сообщению сайта kapital.kz