👋 Как обсудить задачу, чтобы все поняли её одинаково. Метод "Дано Когда Тогда".
Возьму небольшой перерыв в кафкианской саге и расскажу тут про одну мегаполезную штуку, которая вот уже год служит нашей команде верой и правдой и помогает делать встречи короче и продуктивнее.

❓ С самого начала работы в IT у меня крутился в голове вопрос, как же сформулировать задачу так, чтобы в конце все поняли её одинаково?
 
Заебывало знаете ли, что, бывает, сидишь на встречах, слушаешь по 30 минут, как люди спорят, куда надо подвинуть кнопку, а в итоге выясняют, что они вообще говорят о разных кнопках. И потом еще 30 минут слушаешь, как люди пытаются выяснить, кто из них бОльший долбоеб. (А потом выясняют, что говорили про разных людей, ахах!😂)
 
🅰️ Освоил простую, но эффективную технику и спустя год работы с ней, могу порекомендовать её однозначно. Она простая до того, что стыдно писать про неё пост (но я все же напишу). Называется техника "Дано, Когда, Тогда".
 
Суть простая. Когда кто-то из бизнеса описывает функционал, то проговаривает каждую фичу в формате:
"Дано: Кто-то хочет что-то"
"Когда: Этот кто-то делает действие"
"Тогда: Видит результат в таком-то формате"

К примеру, одна из наших фич с сумрачным названием:
Скопировать поп-ап управления отложек МенСмены в МенОфиса/ День

Что должно быть в результате? Хер знает. Вызываем технику Дано Когда Тогда:
 
Дано: Я как региональный управляющий могу зайти в Менеджер Офиса.
Когда: Я в интерфейсе МО на главной странице в разделе Трекинг — Отложено нажимаю мышкой на отложенные заказы
Тогда: Появляется такой же интерфейс как в Менеджере Смены при нажатии на кнопку Отложенных заказов - 0 в разделе Кухня на вкладке Главная.

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

Такое описание привело к тому, что мы начали рассматривать различные корнер-кейсы и выяснили, что к примеру не все детали интерфейса нужно будет переносить в окончательном решении:

Дано: Я как Менеджер Офиса выбираю пиццерию Сыктывкар-1. Я открываю Отложенные заказы на главной и вижу отложенные заказы из Сыктывкара-1.
Когда: Я смотрю на место, где в Менеджере Смены есть иконка принтера
Тогда: Вижу, что в Менеджере офиса ее там нет.

Конкретно этот критейрий снял головную боль по переносу функционала печати, который намертво вбит в Менеджера Смены.
 
⁉️ Тут же возникнет вопрос. Но, Дмитрий, пардон, есть же User Story Mapping, есть же доски в Miro, макеты, разве этого добра не хвататет?
 
Хватает, но User Story Mapping – формат тяжелый, как хрюкающие подсвинки сатаны. А функционал бывает не визуальным, к примеру в итоге действия должен проигрываться звук, так что фигмы никакой не будет. И еще плюсом этого формата является то, что он позволяет покрыть, как маленькие задачи, так и довольно большие.
 
User Story Mapping все еще отличный инструмент, но подходит он скорее для очень больших задач. Которых у нас не так много.

Как начать использовать Дано, Когда, Тогда? Да супер-изи!
1️⃣ Для пункта Дано, попросите продакта максимально описать пользователя, который будет производить действие. Его роль в системе, данные, которые должны быть заполнены, что он хочет сделать.
2️⃣ Для пункта Когда. Попросите сформулировать, что будет делать пользователь. Откуда он начинает своё действие, куда кликает, чтобы прийти на нужный экран или  перевести систему в нужное состояние.
3️⃣ Для пункта Тогда попросите описать конечный результат. Как поменялось состояние системы? Что увидел пользователь? Почему ему это было полезно?
 
Повторяйте до тех пор, пока не покроете все крайние случаи. Будет сложно, но через несколько PBRов навык отточится, и вы поймете насколько глубоко нужно детализировать каждый пункт и сколько таких пунктов нужно.
 
Еще можно позвать инженера по тестированию, чтобы он помог вам не сдаться на пути в бездну и помочь МАКСИМАЛЬНО детализировать крайние случаи.
#процессы