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

Если задача поставлена плохо, то велики риски провалить результат, даже если за решение возьмется лучший из специалистов.

Если задача сложная и занимает более 2-х часов времени, требует умственных затрат, то постановку лучше делать в форме технических заданий.

Вот как раз о том как мы пишем ТЗ, тут и поговорим.

Изначальные условия, из которых выросла наша методика:

  1. Мы перестали работать с крупными проектами. Если задача слишком большая, мы просто разбиваем ее на куски и делаем по шагам. Сначала самые важные части, затем докручивая постепенно дополнительные компоненты. Задачи делим на куски по 1-2 недели. Иногда по 2-4 недели. Слишком большие задачи сложнее ставить, легко допустить ошибки в постановке задачи и затем получить проблемы в результате. Пошаговая схема — оптимальна. Еще этот метод называют Agile.
  2. Мерилом прогресса являются итерации или версии продукта. Чем чаще делаются итерации тем лучше.

Состав ТЗ

Таким образом родилась наша методика, которую тезисами можно обозначить так:

Берем чистый лист бумаги (Google Документ лучше всего) и начинаем писать ТЗ, которое состоит из следующих основных разделов:

Задача

Первый раздел ТЗ звучит как Задача.

Тут коротко и в общих чертах пишем что нужно сделать. Возможно надо создать сайт, разработать форму заказа, сверстать страницу или страницы, реализовать новую версию продукта и т д. В 1-3 предложения. Максимально простыми словами. Что и зачем нужно сделать.

Исходные данные

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

Требования к результату

Третий раздел это Требования. Вот он самый сложный. Тут нужно через многоуровневый нумерованный список, расписать основные идеи, пожелания, условия и пользовательские истории. Все то что должно получиться в результате. Нумерованным список должен быть чтобы иметь возможность при общении называть пункт требования. А многоуровневый он должен быть чтобы соблюдать метод структурирования ВИСИ.

ВИСИ — это один из важнейших принципов в постановке задачи. Если требования не структурировать по ВИСИ, то потом можно схлопотать проблем полные штаны. Упустить риски или проблемы, которые скрываются в требованиях.

Тут есть засада и проблема. Часто новички думают что для написания ТЗ нужно понять задачу. Ошибка в том что все наоборот. Ты не поймешь задачу, пока не напишешь ТЗ. И для этого есть прием из двух шагов: Во-первых надо выключить мозг и составить простой список из идей, условий, историй и любых комментариев и примечаний по задаче. Во-вторых, после того как список будет составлен, надо начать его структурировать по ВИСИ. Выделать общие пункты, подпункты и т д, все по принципу ВИСИ. Вот только после этого начнет приходить понимание. Полное понимание придет только в том случае если удасться структурировать требования и привести список к норме из 3-4 верхних пунктов. До тех пор пока не будет структрирированного списка, вы лишь можете думать что чего то понимаете, но на самом деле это не так. Это иллюзия, в которую вы верите. Структурирование позволяет лишь слегка развеять эту иллюзию и именно это состояние и называется понимание достаточное для исполнения.

Ограничения

Третий раздел звучит как Ограничения и он состоит из подразделов: Стоимость и Срок. Тут пишем стоимость и срок решения задачи исходя из описанных требований. Изначально стоимость и срок можно определить лишь вилкой (от и до). Это нормально. В ходе обсуждения и детализации требований, можно будет уточнить.

Согласование

После того как Задача и Требования обозначены, мы обычно отправляем ссылку на ТЗ всем участникам и просим согласовать. Тут начинают возникать вопросы, начинаем детализировать требования (углублять список, детализировать), что то меняется, предлагаются варианты решений, согласовываются и т д. Вопросы задаются до тех пор, пока не получится назвать окончательную стоимость решения.

Как пишет задачу клиент?

Клиенты разные по характеру — пишут задачи по разному:

  1. Кто то пишет просто задачу в одну строку «Нужен сайт, который будет продавать Угги».
  2. Часть клиентов описывают задачи в Evernote с гиперссылками между требованиями. Где на каждый важный участок есть своя карточка.
  3. А кто то пишет ТЗ в трекерах, где каждый тикет — это часть задачи, а задача определяется как веха (millestone).
  4. Кто то пишем в MindMap.
  5. Есть те кто все еще используют в MS Word.
  6. Самые любимые наши клиенты пишут задачи в  Google Документах. Таким сразу +10 к уровню уважения и любви 🙂

Почти каждый из них думает что это ТЗ. И отчасти оно так и есть. Другой вопрос что это не то ТЗ, которое можно оценить и сделать достаточно точно. Все эти ТЗ переводятся в наш формат. Наш формат позволят точнее ставить задачу, исключать проблемные участки, вылавливать риски, лучше делать оценку и находить оптимальные решения.

Пример ТЗ

По ссылке можно посмотреть один из примеров такого ТЗ.