Продуктовый или проектный подход?

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

Вам как заказчику важно определиться, кто именно вам требуется – просто проектный исполнитель или технологический партнер. Разница между ними ощутимая. Проектный исполнитель обычно работает по проектному подходу в разработке: когда заказчик приходит с готовым ТЗ, а главная цель подрядчика – действовать строго по нему и попадать в указанные сроки и бюджеты. При таком формате работы на заказчика возложена ответственность не только за подготовку технических требований, но и за жизнеспособность продукта, его соответствие рынку и удобство для пользователей. Главный риск проектного подхода заключается в том, что можно получить продукт, который полностью соответствует ТЗ, но не реалиям рынка: длительная разработка (в среднем 6-9 месяцев) на стороне исполнителя обычно ведется практически в “вакууме”.

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

Что еще отличает продуктовый подход от проектного? В первую очередь – фокусирование на создании ценного для пользователей продукта, а не выполнении условий ТЗ. До начала работы продуктовая команда узнает целевую проблему заказчика и проводит подготовительную работу: изучает рынок, формирует предположения, проводит эксперименты, валидирует гипотезы, прорабатывает пользовательские пути, готовит прототипы, анализирует варианты с минимальными сроками и бюджетом. Цель каждого этапа – понять, как наилучшим образом выполнить задание заказчика. После всей подготовки команда выпускает часть IT-продукта, которая уже представляет собой полноценное и функционирующее решение, и отправляет его на тесты, чтобы дорабатывать его на основе обратной связи. При этом параллельно идет работа над следующими частями решения, благодаря чему увеличивается как скорость выхода решения, так и его отладка. Подводя итог, выбирая подрядчика, обратите внимание, какой вопрос он задаст вам при первой встрече. “Что вы хотите, чтобы мы вам разработали?” – это отличный клиентоориентированный вопрос от подрядчика. Но вам надо ждать вопроса: “Какую проблему вы хотите решить?”

Кроме того, при продуктовом подходе выше Time to Market – скорость передачи продукта в пользование и получение от него положительного эффекта. Команда стремится создать минимально жизнеспособный продукт, в котором есть все базовые функции и ничего лишнего, чтобы быстрее выпустить его для тестирования в реальных условиях рынка. Вместо того, чтобы удариться в затяжную разработку, продуктовая команда действует итеративно – выпускает часть продукта в какой-то короткий промежуток времени (обычно каждые две недели). Для сравнения, в проектном подходе финальный продукт можно получить через 6-9 месяцев и после этого отправить его на доработку, если обнаружатся проблемы. В продуктовом подходе первая версия выпускается уже через 1,5 месяца и дорабатывается в процессе по результатам тестов, которые проходят параллельно.

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

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

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

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

Автор – директор по продуктам компании BSL