Правильно поставленная задача, это 50% успеха. Без хорошего ТЗ – результат ХЗ.
Как называть документы, в которых описываете требования?
За 10 лет практики я встречал такие:
- ТЗ – тех задания
- PRD – Product Requirements Document
- SRS – Software Requirements Specification
- RFC – Request for Comments
И самый главный инсайт, к которому я пришел – это всего лишь слова. В целом не важно как называть документ, важно уметь подбирать хорошие паттерны описания внутри.
Самое интересное, что если понаблюдать за современными командами разработки, то там требования описывают внутри трекеров – и обычно вообще никак не называют такие документы. Просто вот есть задача, вот описание, вот дизайн макеты. Пошли делать. И это работает круто – при грамотном описании.
Из всего этого списка за 10 лет я пришел к тому что наиболее эффектно называть такие вещи – RFC. Просто потому что такое название подразумевает что важно затем получить по нему комментарии и обсудить. Без обсуждения – такие документы часто превращаются в мусор, который только мешает работать.
Практики и паттерны эффективной постановки задач
Вот это самое интересное. Не важно где и как будет описываться задача. Важно чтобы описание было сделано при помощи эффективных паттернов и методов.
Опять же тут множество практик:
- WWH и более сложный варианты 5W1H
- AsIs – ToBe
- User story
- Todo
- Checklists – AC, DoD etc.
- Visual design, UI, UX
Выбор метода описания задачи зачастую зависит от ее типа.
- например задачи про разработку новых фич и функций – хорошо описывать через WWH, User Story …
- баги и проблемы хорошо описывать через AsIs – ToBe
- если в задаче важен UI – обязательно прорисовывается дизайн UI/UX
Типовые ошибки и проблемы
Зачастую множество проблем в процессах разработки и реализации проектов связаны с плохим выбором методов описания задач.
Вот типовые и популярные ошибки:
- В каких то командах люди думают что нужно все задачи описывать через 1 шаблон. Получается аляповато, дорого и плохо.
- Избыточное описание ради описания – например пишут множество бесмысленных чек листов на каждую задачу. Очень дорого и сильно снижает эффективность разработки.
- Попытка словами описать визуал – это когда есть какой то UI, и вместо того чтобы 1 раз нарисовать как это выглядит, пытаются на словах описать как это должно быть – простейшие задачи становятся очень тяжелыми в реализации
Итого
В этом мире не все всегда и везде, а кое что иногда и местами. Важно подбирать методы описания задачи с учетом контекста и ее особенностей. Для разных задач – разные методы описания.
Попытки забивать гвозди микроскопом – приводят к печальным результатам.
Потому пробуйте и изучайте разные практики описания задач, подбирайте те что работают лучше в конкретных кейсах.
