Формулируем MVP в заказной разработке

Как провести этап аналитики и составить ТЗ, чтобы ожидания заказчика и исполнителя совпали?

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

Давайте вспомним, что такое MVP. Вроде, термин не новый, некоторые даже успели усомниться в его работоспособности, и появилось множество других терминов, таких как Riskiest Assumption Test (RAT), Exceptional Viable Product (EVP), Minimum Lovable Product (MLP), Minimum Valuable Problem (MVP), Minimum Beautiful Product (MBP). Но до сих пор я встречаю некорректное использование подходов.

Википедия дает следующее определение.

Как понять, что MVP успешен?

Результатом MVP являются знания и информация о том, подтвердилась ли основная гипотеза.

Что такое гипотеза и как понять, подтвердилась она или нет?

Гипотеза - это формулировка, которая описывает сегмент пользователей, их проблему, что именно будет являться решением данной проблемы и показатели успешности MVP, т.е. метрики. Для отслеживания метрик надо придумать и реализовать “линейку”.

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

Суть MVP - с минимальными вложениями и за кратчайший срок проверить гипотезу.

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

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

Давайте рассмотрим гипотетическую ситуацию. С ее помощью я хочу показать:

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

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

В компании Олега появилась потребность в новом сервисе как для внутреннего использования, так и для отдельного продукта на их рынке - системе мониторинга. Олег сверстал бюджет, выбрал Ивана в качестве разработчика, и ребята подписали контракт на предпроектные работы и составление ТЗ. Чем можно руководствоваться при выборе подрядчика мы вскользь затронули здесь.

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

“Классические” аналитики Ивана выяснили, как заказчик видит реализацию функций и составили список требований. При интервьюировании заказчика и сборе требований они задавали вопросы, подобные следующим:

Также они описали системы, которые используются заказчиком. Исходя из того, что сказал заказчик, они придумали решение и оформили ТЗ, в котором указали: список устройств и протоколов для интеграции; точное кол-во устройств в каждом Data-центре; нефункциональные требования и функциональное описание MVP в виде пользовательских историй, которые выглядели так:

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

Помимо прочего, Олег захотел крутой дизайн и ожидал wow-эффект.

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

Иван декомпозировал функционал, посчитал риски, прикрепил к ТЗ вышеописанную информацию и отправил Олегу. Оказалось, что сумма, требуемая для реализации, превышала ту, которой располагал Олег. Скрывать этот факт было нельзя. Олег и Иван начали упрощать функционал, чтобы уложиться в бюджет. Однако, после того, как убрали несколько функций, Олег отказался от дальнейших сокращений и потребовал скидку: “Больше некуда урезать! Есть компании, которые готовы в два раза дешевле работу выполнить. Мы же с тобой давно работаем, от нас регулярно приходят заказы. Давай, подвигайся!” Иван вынужден был уступить: он не видел, как можно упростить систему на основании аналитики и дизайн-макетов, и давние партнерские отношения с Олегом не хотел портить.

Началась разработка MVP. Пока писали код нашли несколько непродуманных сценариев, тестировщики нашли ещё пару. Когда продемонстрировали результат Олегу, то он внёс свои корректировки. После того, как “завели” в систему данные, оказалось, что надо править дизайн и корректировать ряд сценариев. Результат не соответствовал тому, что было написано в ТЗ на все 100%, но система работала.

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

Олег пилотировал MVP в компании, фиксируя обратную связь от пользователей. Оценить, насколько он успешен было тяжело - субъективные оценки и общие формулировки не давали четкую картину. Этой информации недостаточно, чтобы маркетологи с минимальными затратами могли упаковать систему в предложение для Б2Б рынка и отстроиться от конкурентов.

Итак, ни у Ивана, ни у Олега нет чёткого понимания, успешен MVP или нет. Без этого вся эта история может превратиться в дорогостоящее бремя, постоянно требующее доработок.

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

И вот, пожалуйста, ситуация no-win. Так или иначе, в проигрыше оказались оба партнера.

“Продуктовые” аналитики Ивана выяснили, какие пользователи могут быть задействованы при работе с новой системой, т.е. выявили роли пользователей. Составили их портреты, определили мотивацию для каждого пользователя. Описали основной процесс и дополнительные процессы, в которых работают все участники будущей системы. Провели ряд интервью.

Заказчику и всем лицам, участвующим в создании запроса на разработку продукта, задавали следующие вопросы:

Иногда ответы заказчика было тяжело интерпретировать с точки зрения экономики решения. “Ну, мне нужна данная система, чтобы контролировать моих сотрудников и видеть отчётность по закрытию инфраструктурных инцидентов.” Тогда аналитики задавали ещё 5 вопросов “зачем”. “А зачем вам видеть отчёты сотрудников и контролировать их? Что будет если вы это не будете делать?”

Интервью с потенциальными пользователями системы выстраивалось вокруг следующих вопросов:

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

Пример Шаблона MVP

Для кого: Для администраторов и их менеджеров в среднем по размеру дата-центрированном бизнесе с географически распределенным оборудованием.

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

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

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

В отличие от: Решений X,Y,Z данный продукт будет иметь X,Y,Z фичи

Опережающие индикаторы:

-Промежуток времени с момента возникновения инцидента до старта работ администратором.

-Время, которое тратит администратор на решение инцидента.

-Количество критичных инцидентов в системе в месяц.

Нефункциональные требования:

-Система должна выдерживать нагрузку и обрабатывать X гигабайт данных в секунду.

- и т.д.

Иногда для заполнения этого шаблона глубинного интервью не достаточно. Для более основательного понимания, что нужно делать для правильного заполнения шаблона можно прочитать статью про SAFe Epic, опубликованную на ресурсе Scaled Agile Framework.

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

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

После этого они отделили самые верхние минимальные пользовательские истории горизонтальной линией. Таким образом у них получился MVP. При этом, объём MVP можно увеличивать или уменьшать, варьируя количество пользовательских историй, который влияют каким-либо образом на индикатор.

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

В сравнении с результатом, полученным в первом подходе, решение в рамках MVP изменилось. Например, чат-бот полностью не реализуется. Появляется бесконечный скоуп возможных улучшений продукта по каждой из веток. Становится ясно, как каждая User Story влияет на MVP.

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

Тем более основная цель не контроль, а влияние на метрики. А значит и функционал для этого должен быть немного иным.

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

За годы работы в продуктовой разработке я пришел к твердому убеждению, что тщательно проработанное ТЗ не гарантирует, что все ожидания заказчика будут прозрачными и результат сойдётся с желаемым! “Ожидания”, как и “контекст”, нельзя полностью описать. Можно лишь постараться описать образ ожиданий, но все детали станут видны только после того, как продуктом или сервисом начнут пользоваться.

Существует много практик, которые позволяют добиться положительных результатов. Например, вместо User Story Mapping можно использовать Impact Mapping. Для выявления дополнительных метрик при формировании сервиса или продукта для использования внутри компании можно прибегнуть к анализу Total Value of Opportunity.

Считаю, что для того, чтобы команды работали автономно, сохраняя высокое качество и скорость, необходимо внедрять такие подходы на системном уровне в компании и показывать, как они работают на практике.

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

Кто-то из коллег ответил, что если такая ситуация случилась, то виноваты аналитики и те, кто делал ТЗ. Кто-то сказал, что во избежание подобных ситуаций, нужно работать по Agile. Были люди, которые акцентировали внимание на том, что надо переставать работать по ТЗ и бумажкам, а стараться запускать продукт и валидировать результат, дизайн и всё остальное может подождать до более поздней стадии. Эти и другие ответы дали почву для размышлений и, безусловно, повлияли на материал.

Disclaimer 1: В этой статье я не пытался дать “волшебный рецепт” на все случаи жизни. Я говорю лишь о том, как можно экономить силы и деньги, если не допускать элементарных ошибок.

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