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

Итого

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

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

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

Поделитесь с друзьями

Ответить

Ваш адрес email не будет опубликован. Обязательные поля помечены *