Практики постановки задач: ТЗ, PRD, SRS, RFC

Правильно поставленная задача, это 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 раз нарисовать как это выглядит, пытаются на словах описать как это должно быть — простейшие задачи становятся очень тяжелыми в реализации

Итого

В этом мире не все всегда и везде, а кое что иногда и местами. Важно подбирать методы описания задачи с учетом контекста и ее особенностей. Для разных задач — разные методы описания.

Попытки забивать гвозди микроскопом — приводят к печальным результатам.

Потому пробуйте и изучайте разные практики описания задач, подбирайте те что работают лучше в конкретных кейсах.