В прошлой моей статье мы разобрались, как сделать так, чтобы ожидания менеджера продукта совпали с реальностью, а в этой статье обсудим, как сделать так, чтобы задача вышла в продакшен раньше, чем она потеряла смысла. В современном конкурентном бизнесе побеждает и захватывает новую нишу тот, кто первый сделает классные доработки и захватывает этим внимание пользователя.
Мы должны очень быстро бежать, чтобы успевать за конкурентами. С другой стороны, мы должны выдавать качественный продукт, а иначе в нем нет никакого смысла. В этой статье расскажу, какой инструмент мы нащупали, чтобы ускориться и повысить качество. А еще, конечно, снизить стресс команды разработки. Меньше стресса — лучше результаты.
При составлении требований к задаче очень важно понимать, для кого мы их пишем и зачем. Для себя мы обозначили следующее:
Четкие и однозначные требования от бизнеса нужны команде:
чтобы мы реализовали то, о чем договорились. Требования могут меняться во время и после груминга, это нормально. Важно, чтобы все договоренности были зафиксированы.
чтобы команда понимала, какую проблему пользователя мы решаем. Это необходимо для того, чтобы проверить, точно ли проблема пользователя решена.
Product-менеджер описывает требования в классическом стиле. Они обязательно содержат:
Предыстория. Откуда появилась проблема и в чем ее суть.
Цель. Что мы ожидаем в результате реализации задачи.
Критерии приемки. Этот пункт самый важный. Описываем от лица пользователя желаемое поведение при каждом шаге. На эти критерии будем опираться при реализации, по ним Product-менеджер будет принимать результат. Это обязательно должны быть понятные и простые формулировки. Должно быть описано каждое нажатие на кнопку, каждый переход на новый экран.
Эксперимент или нет. Будем запускать это в рамках эксперимента или полностью меняем текущую функциональность.
Аналитика. Нужны ли аналитические события на действия пользователя.
Пример хорошо описанных требований:
Далее идет груминг и перевод продуктовых требований в технические. Можно описывать их с разной степенью детализации, для себя мы выбрали следующий подход: описываем технические требования на уровне логики, а глубокую архитектуру оставляем на реализацию разработчикам. Например, мы описываем, что в результате выполнения задачи у нас должны быть добавлены два новых поля в базу данных и в три существующих запроса, названия которых перечисляем. Далее описываем логику, по которой должны новые поля заполняться. Но названия переменных и полей, а также способ хранения и таблицу мы не перечисляем, это все остается на усмотрение разработчика. По результатам выполнения задачи разработчик должен приложить эту информацию.
Задача на технические требования всегда содержит в себе следующие разделы:
Проблема. Описываем, зачем мы делаем эту задачу.
Необходимо. Перечисляем всю логику, которую необходимо реализовать. Должно быть описано:
поведение каждой кнопки;
ссылка на каждую гиперссылку;
способ и логика перехода на следующий экран;
изменение местоположения каждого элемента;
дополнительная важная информация.
Для тестирования. Опциональный пункт, в котором содержатся важные corner-кейсы или нюансы при тестировании, на которые хочется обратить внимание.
Локализация. Нужен ли перевод на другие языки (специфика нашего продукта).
Эксперимент. Будем ли мы запускать задачу в рамках feature flag или нет.
Аналитика. Нужна ли нам продуктовая аналитика о действиях пользователя в рамках этой функциональности.
После написания технической задачи важно пройтись по критериям бизнес-задачи и убедиться, что ничто не забыто и написанное не противоречит друг другу.
Пример технической задачи:
Все изменения договоренностей важно фиксировать в задаче, иначе она быстро потеряет актуальность и не будет единым источником истины. О том, кто будет актуализировать договоренности, можно условиться заранее, а можно ситуативно, то есть сразу же после обсуждения.
Что помогла улучшить документация:
Product-менеджер заранее формулирует четкие требования и согласовывает их с командой. Не остается непонятных мест и разночтений. При описании критериев менеджер продукта может внимательнее продумать все детали задачи.
Благодаря хорошему описанию технических и бизнес-требований разработчику не приходится тратить время на вспоминание того, что мы когда-то обсуждали на груминге и на поиск контекста перед началом и во время реализации задачи. Экономим время на дополнительных созвонах команды, встречах с заказчиком и обсуждении одного и того же несколько раз.
QA-специалист при тестировании не тратит время на выяснение того, как это должно быть, так как требования едины для менеджера продукта, разработчика и QA.
У нас меньше исправлений багов из-за того, что требования зафиксированы заранее. Не возникает ошибок из-за того, что кто-то забыл о договоренности.
Любому члену команды легко вернуться к предыдущей задаче и доработать ее. Мы не завязаны на разработчика и тестировщика, у которых требования хранятся в голове. Каждый может вникнуть в задачу, перечитав ее описание.
