Создание продукта по воле заказчика без исследований.
Свежий кейс из моей менторской практики.
У меня есть один клиент, который находится н
а ментор
ской поддержке из студии разработки.
Он получил новый заказ, где заказчик по
просил реализовать продукт согласно ТЗ, которое они вместе написали. ТЗ написано по принципу use case.
Во время последней нашей встречи мы договорились, что он нарисует продуктовую архитектуру, и я дал свой шаблон, по которому он сможет это сделать.
Продуктовая архитектура - диаграмма, где показаны модули продукта, их связи друг с другом и описание ценностей каждого.
Наступает очередная встреча, где мы эту архитектуру смотрим. - Максим, я нарисовал продуктовую архитектуру. Дай, пожалуйста, обратную связь.
- Окей. Обратную связь на предмет чего?
Я всегда спрашиваю, какую цель преследует человек, когда просит обратную связь
- Ну в целом. Нам нужно было все собрать в единую картинку.
- Супер, а что нам это даст?
- Поймем как это все согласуется друг с другом и .. поймем с в чем будет заключаться MVP продукта
MVP - минимально жизнеспособный продукт, который дает ценность.
Далее от меня последовал ряд вопросов, чтобы мы поняли, что нам с этим делать. ⁃ А заказчик что хочет получить в итоге? Он уверен, что нужно делать именно
такой продукт?
- Он уверен.
- А он проводил исследование? Как он решил, что нужно именно это?
- Никак. Он просто хочет, чтобы было как в ТЗ.
- Понял. Если я надеваю шляпу продакта, то мы с тобой думаем, как минимизировать риски, чтобы быстро проверить идею и решить, с какой части продукта лучше стартовать, чтобы чувствовать его востребованность. А если тебе нужно просто в точности повторить ТЗ, то тебе нужен комментарий от разработчика-архитектора, который разложит это дело по технической архитектуре и скажет что сделать, чтобы оптимально сделать проект. Фактически по каскадной модели разработки.
Какая мораль у этой истории?
Когда мы строим продуктовую архитектуру и выделяем из нее MVP, важно понимать, какие цели мы преследуем.
Полная реализация в соответствии с ТЗ? Или у нас гибкий подход, где наша цель минимизировать риски и затраты?
От этого зависит и наш подход в реализации продукта или проекта. Каскадный подход waterflow или гибкая модель lean?