Скудное ТЗ в четкое видение  продукта

«Из продукта», #1.
В рубрике объясняю процессы работы над продуктом, делюсь примерами
и гайдами. Показываю, как не быть Теджем из двойного форсажа и не улететь в стену на 200км/ч вылететь по часам из оценки.

Продукт только стартанул или находится в пресейле: с чего начать
фриланс-дизайнеру или студийной команде?

📌 Пример брифа

Оставшиеся 20% — точечные вопросы, которые закрывают «инфраструктурные» дыры в видении. Какую технологию использовать, сколько пользовательских ролей, как подключить складской сканер к приложению. Эти вопросы возникают из-за бизнес-цели, аудитории или специфических функций.

Плюсы вижена:

• Определяться граница проекта. Легко выделится МВП, ставьте к статье
  «⏳(sand…)», и объясню что такое МВП.
• Уменьшиться время на погружение членов команды в проект.
• Повысится объективность оценки сроков реализации. А оценка с небольшой разницей между min и max часами, покажет клиенту вашу погруженность
  в проект и экспертность.

Про то, как составить файл-оценки и определить формат работы будет в посте «Из продукта #2». Следите за телеграм-каналом 👀

Минусы:

• Поверхностное описание функционала: в карточке-шаге «Страница жк» не будет пунктов про количество квартир в доме, средней стоимости м2. Будет просто: параметры квартиры. Детальное описание делается на другом этапе, о котором расскажу в посте «Из продукта», #2.

А как вижен делать?

С помощью Story mapping-га. Инструмент, который на разных этапах трех крупных проектов помогал мне метчить ожидания клиента с видением команды. Мы НЕ переделывали работу, а клиент экономил деньги.

По шагам:

1. Строим путь человека от входа в сервис (А) до решения задачи (Б)
   с разделением на шаги.
2. В каждый шаг добавляем необходимый* функционал.
3. Ищем пробелы — места, в которых путь нелогично прерывается
   или недостаточно понятен. Заполняем их.
4. Расставляем приоритеты. Высокий ставим функциям, без которых не работает бизнес-логика или невозможно пройти путь из А в Б.
   Средний для функций, которые влияют на опыт пользователя.
   Низкий для функций, которые делают удобный продукт максимально удобным, но глобально не влияют на путь от А до B.
5. Распределяем функции по версиям: версия 1, МВП — с высоким приоритетом и одна-две со средним. Версия 2: со средним. Версия 3: с низким.

*Значимость функционала можно определить методом из 4 пункта ⬆️
или с помощью фреймфорков: ICE, КАНО, MoSCow, RICE, Value&Effort.
Интересно узнать про них? Пишите в комментах.

📌 Пример Story mapping-га

Согласовываем вижен с клиентом. Если в вижене остались логические или инфраструктурные пробелы, то проводите ребрифинг, задавая клиенту уточняющие вопросы, те самые 20%

«Картина» проекта в нашей голове и голове клиента совпадают — юху 🙌.
Если у продукта несколько бизнес-целей или много функций, то стройте два, три или больше story mapping-гов.

Задавайте вопросы, применяйте новые знания на практике.

В посте #2 рубрики «Из продукта» расскажу про то, как оценить сколько времени и денег потребуется на работу. Следите за телеграм-каналом 👀