MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям

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

Преимущества работы с мелкими партиями

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

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

Определение трудозатрат на основе балльной оценки историй пользователя

Читатели, имеющие опыт Agile-разработки, вероятно, знакомы с принципом дробления функций на более мелкие фрагменты. После создания пользовательских историй команда разработчиков обсуждает каждую из них, оценивая при этом объем усилий, требуемых для реализации. Для этого часто используется балльная система оценки масштаба рассматриваемых пользовательских историй. Например, самая «мелкая» история может быть оценена в один балл, в то время как история среднего масштаба наберет, скажем, три балла, а крупномасштабная история – все восемь баллов. Я более подробно рассматриваю эту тему в главе 12.

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

Использование показателя рентабельности инвестиций для расстановки приоритетов