Самые частые ошибки при запуске
продукта

Управление продуктом, как процесс

Продуктовая разработка — своеобразный творческий процесс, который серьезно зависит от организации работы внутри и снаружи команды. Любая итерация этого процесса объединена общими идеями управления качеством продукта. Если в самом начале вы не заложили верные ориентиры для команды, вас ждут проблемы, которые могут растянуться на весь жизненный цикл работ. Иными словами, все нужно организовать так, чтобы довольны были все: от разработки до стейкхолдеров. Как думаете, так бывает?

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

В общем, выяснили, что управление продуктом превращается в многоступенчатый процесс, где каждый этап становится неотъемлемой частью стремления к качеству. В идеале, нужно добиться такой стабильности, в которой продукт будет получать +1 к совершенству, каждый раз, когда вы решаете выпустить релиз. И здесь на помощь команде приходит грамотный продакт, который владеет не только даром самообладания, но и разными методиками управления процессами. Одна из таких — система Всеобщего управления качеством (Total Quality Management, TQM). Здесь не будем приводить подробных исторических справок, информации об этом достаточно много. Нас интересует ее «частный элемент», цикл Шухарта — Деминга и то, как он помогает нашей продуктовой команде решать рабочие задачи.

Цикл Деминга PDSA подразумевает под собой четыре принципа:

• планируем (plan) — ставим перед собой достижимые цели, рассматриваем технологии, которые помогут этих целей достичь, занимаемся распределением командных ресурсов для решения задач;
• делаем (do) — собственно, следуем выработанному ранее плану;
• изучаем (study) — изучаем, насколько хорошо выполнены запланированные задачи, выявляем проблемы и документируем;
• исправляем (act) — вносим изменения, корректируем все, что требуется для достижения наилучшего результата.

В некоторых случаях, методология PDSA может быть заменена на схожий вариант — PDCA, где под C (Check) подразумевается не изучение, а проверка. Этот метод был предложен Эндрю Шухартом в 1939 году, а Деминг усовершенствовал его позже. Разница между двумя вариантами зависит от того, предполагаете ли вы перед релизом проведение аналитического этапа с оценкой существующих процессов, или хотите найти какой-то дополнительный потенциал. Оба цикла могут повторяться сколько угодно раз.

Выбран неподходящий стек технологий.

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

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

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

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

Отсутствуют оценочные метрики.

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

а) помогают оценить итоги работы команды;
б) позволяют увидеть итоги тестирования;
в) дают возможность оценить качество продукта.

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

Здесь в силу вступает S (изучение), когда мы не только проверяем конкретное выполнение задач, но и делаем выводы на их основе. Примеры некоторых метрик:

• каков таймлайн подготовки и релиза?
• сколько времени ушло на написание документации и тест-кейсов?
• сколько времени было затрачено на кросс-ревью?
• достаточно ли автотестов с покрытием основного сценария или нужны еще?

На основе данных по ним, тимлид сможет сделать выводы и улучшить внутренние процессы в будущем.


Случается срыв срока релиза.

Сразу из-за двух частей цикла PDSA — планирования (P) и выполнения (D), если они были неверно рассчитаны, у таймлайна начинаются проблемы. Релизный цикл нарушается, а команда не выполняет своих обязательств перед заказчиком. Причем срыв сроков не всегда происходит потому, что команда разработки забыла вовремя закрыть таски. Состояние релизов зависит от организации регламентов внутри компаний и команд, от оценочных метрик (например, сколько этапов тестирования еще осталось?) и инструментов. Если вы решили интегрировать трендовые биометрические технологии на основе алгоритмов искусственного интеллекта (AI) и машинного обучения (ML) за ночь до начала продуктовой разработки, вас ждут неприятности.

Неочевидные подводные камни

Есть проблемы, которые кажутся только вершиной айсберга. Например, не всем очевидно, что проектную разработку может погубить один «слишком инициативный» человек. Это такой bus-фактор, когда вся документация или ревью завязаны на конкретного разработчика. Его отсутствие (отпуск, больничный, увольнение) не должны влиять на процесс, но влияют критически.

Сюда же можно отнести отсутствие декомпозиции процессов, отвечающих критериям INVEST (независимые, обсуждаемые, ценные, с реальной оценкой риска, масштабируемые, проверяемые). Каждый запланированный процесс должен приближать нас к ответам на вопросы: в чем польза внедрения/интеграции, что нам мешает, какие ограничения критичны, какие инструменты нужно задействовать, чтобы справиться с возникающими проблемами.

Закрывая эти вопросы, философия TQM помогает управлять качеством процессов через тот же цикл Деминга. Смысл не в том, чтобы нагрузить команду дополнительной работой или метриками, а в том, чтобы достигнуть результата эффективно. Вы не просто бежите к релизу, а стремитесь к совершенству через планирование. Важна даже тонкая настройка: например, от грамотного онбординга зависит коммуникация внутри компании, а от нее — способность верно оценить состояние команды. Каждый сотрудник должен быть на своем месте, тогда и внутри процессов будет порядок.

Вывод

Легкого пути или волшебной таблетки не будет. Методология работы над качеством процессов очень обширна, нужен комплексный подход и люди в команде, разделяющие эти ценности. При возникновении ошибок при запуске продукта, вы теряете время и ресурсы, а иногда — репутацию. Но если в компании уже существует дорожная карта PDCA/PDSA-методологии, проводится аудит внутренних процессов, можно достичь:

• роста скорости разработки без потери качества;
• снижения рисков;
• роста лояльности заказчиков и потенциальных клиентов;
• стабильности рабочих процессов;
• снижение показателя time-to-market (времени вывода продукта на рынок).