Абсолютно любое требование состоит из:
- «У меня или кого-то возникает вот такая вот потребность вот в такой ситуации (контекст)»
- «Когда я пытаюсь решить эту потребность возникает проблема и она болит на Х из 10«
- «Я ожидаю в конце получить решение своей потребности / проблемы вот в таком виде»
- «Решение можно считать сделанным (Definition of Done) если будет работать вот так«
Формула Требования:
Требование = Потребность + Проблема (с оценкой боли) + Ожидание + Definition of Done (DoD)
Так вы получаете ВЕСЬ возможный контекст задачи понимая мотивы, боли, ожидания и способы подтвердить успешность выполнения. Без этих вы обязательно что-то упустите и попадете в залупу или на этапе придумывания решения по несуществующей проблеме, или даже на этапе ощущения «что все сделано», когда на деле у заказчика было совсем другое ожидание».
Запомним эти 4 элемента, как «4-х всадников требования»:
- Потребность – чего, в каком контексте и как хотят
- Проблема – что мешает добиться потребности + оценка боли по 10-бальной шкале
- Ожидание – что хотят получить от решения потребности + проблемы
- Definition of Done (DoD) – после какого события можно считать, что потребность + проблема решены успешно
Задача БСА выявить и описать все составляющие у всех цепочек звена (от пользователя, до менеджера, который передаёт эту потребность).
Делается это при помощи методик CustDev и JTBD Interview. Об этом будут отдельные статьи и ссылки на полезные материалы. Сейчас могу посоветовать погуглить эти тематики и начать копать.
Интересный факт 1. Потребность чаще всего рождается из Проблемы.
Интересный факт 2. К Требованию нужно относится, как к «гипотезе»
Правило 1. «Нет» реализациям
В Требовании никогда не должна быть описана реализация!
Неправильно: «сделать красную кнопку с отправкой сообщения»
Правильно: «нужен способ отправки сообщений»
(более подробно опишу позже)
Правило 2. «Который час?»
Обязательно во всех пунктах, всегда уточняйте «К которому времени надо чтобы было вот это, вот это, вот это».
Абсолютно любой кусок информации требования должен быть покрыт сроками.
Очень полезный лайфхак
Уже сейчас попробуйте все свои задачи (которые не касаются чего-то слишком процессуального, типа «поправить вот эту кнопку») в таск-трекере оформлять по шаблону:
- Название
- Потребность
- Проблема
- Ожидание
- DoD
Например кейс moikrug.ru:
- Название: Нужно добавить возможность сохранить несколько фильтров поиска в «избранные фильтры»
- Потребность: конкретный пользователь, который ищет работу чаще всего каждый день производит фильтрацию по одному и тому же набору фильтров
- Проблема: сейчас для этого ему приходиться вводить их каждый раз заново, что вызывает дискомфорт
- Ожидание: мы должны реализовать функционал, который даст возможность пользователю сохранять набор фильтров, скажем, в «избранные фильтры»
- DoD: у нас на сайте в том или ином виде пользователь может сохранить набор фильтров, а потом одним нажатием воспользоваться ими
Или более специфичный кейс внутренней задачи:
- Название: Составить варианты оптимизации работы сервиса
- Потребность: мы хотим иметь стабильную работу сервиса для пользователей (примером показателя может быть ответ от сервера на любой запрос не более 1 секунды)
- Проблема: сейчас многие функции нашего интерфейса прогружаются слишком долго, потому что сервис написан слишком давно и плохо.
- Ожидание: в идеале, нужно найти способ прооптимизировать систему без рефакторинга, но при этом не привлекая кодеров или же надо доказать, что такое невозможно и придется все переписывать
- DoD: документ с гипотезами того, как реализовать оптимизацию без рефакторинга и аргументы подтверждающими / опровергающими возможность и эффективность их внедрения.
