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

Итого

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

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

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

Специализация: разработка сайтов, SEO & WordPress Опыт: более 10 лет

Комментировать

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