Пять шагов к образцовому ТЗ: рекомендации от эксперта

Автор курса Анастасия Гиззатуллина рассказывает о своих ошибках на пути к идеальному ТЗ, опираясь на пятиступенчатую модель для оценки ресурсов и текущего состояния. Эта модель даст вам ориентиры, как нужно действовать, чтобы составить техзадание, которое примут с первого раза.

Пять шагов к образцовому ТЗ

За основу мы берем схему SCORE для оценки ресурсов и текущего состояния, которую применяют для решения задач. В ней пять составляющих – по числу букв в аббревиатуре. Рассмотрим каждую из них подробнее.

S (Symptom): текущая нежелательная ситуация или проблема, с которой мы столкнулись

У каждого человека хоть раз возникала ситуация, когда сложно донести информацию и получить желаемое: начиная от заказа в ресторане, заканчивая общением с ремонтной бригадой. То мы не можем внятно объяснить, что нам надо, то собеседник упорно не понимает нас и закономерно выполняет задачу не так, как мы это представляем. В каких-то случаях идеальными результатами можно пренебречь. Но есть сферы деятельности, в которых потраченные в никуда ресурсы стоят не только больших денег, но и репутации.

Один из главных признаков неудачного ТЗ – когда обе стороны подумали, что поняли друг друга правильно, но результат далек от желаемого. На своей первой работе я полностью полагалась на опыт разработчика и надеялась, что он сделает все, как мне надо, и не следила за тем, чтобы он реализовывал все строго по техническому заданию.

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

C (Cause): факторы, события или убеждения, которые привели к возникновению проблемы

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

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

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

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

O (Outcome): желаемое состояние или цель, которую мы хотим достичь

В идеале ТЗ должно работать как «мост» между заказчиком и исполнителем, по которому обе стороны без потерь переходят от идеи к результату. Это значит, что каждая деталь задачи понятна, проверяема и согласована, а вложенное время и ресурсы окупаются в виде правильно реализованного функционала. Минимум усилий и максимальная выгода.

Чтобы корректно отразить желаемое состояние и цель, в техзадании описывают:

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

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

R (Resource): навыки, знания, связи и другие факторы, необходимые для достижения цели

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

В работе я использую следующие ресурсы, которые помогают мне создать образцовое ТЗ:

Ориентированность на цели и проблемы заказчика и пользователей.

Важно не просто зафиксировать требования, а понять, зачем они нужны. Хороший автор ТЗ видит за каждым пунктом конкретную задачу бизнеса и «боль» пользователя. Умение выделять приоритеты помогает сосредоточиться на том, что действительно принесет результат.

Базовое знание технической стороны.

Необязательно уметь программировать, но нужно понимать, что реально выполнить, а что потребует слишком много ресурсов. Это помогает формулировать требования корректно и избегать двусмысленностей.

Понимание предметной области.

Даже если вы не эксперт в теме, нужно знать контекст: как работает бизнес-процесс, кто конечный пользователь, какие у него «боли». Без этого ТЗ превращается в список пожеланий, а не в осмысленный документ.

Навык коммуникации.

ТЗ пишется не в одиночку. Нужно уметь задавать вопросы, слушать, уточнять, обсуждать детали. Качественное техзадание рождается из диалога – с заказчиком, пользователем, командой. Хорошие навыки коммуникации станут опорой, пока мы недостаточно погружены в предметную область.

Расширение кругозора.

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

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

E (Effect): позитивные последствия, которые наступят после достижения цели

Когда вы научились формулировать понятные и точные технические задания, результат ощущается не только в цифрах, но и в атмосфере работы.

Я выделяю такие позитивные последствия:

Быстрее достигается результат: ТЗ принимают с первого раза, без десятков уточнений и переписок, и команда фокусируется на реализации;
Повышается доверие: заказчик видит, что его услышали и правильно поняли; это укрепляет отношения и открывает путь к новым проектам;
Растет профессионализм: каждый новый опыт написания ТЗ повышает навык структурирования, логики и коммуникации; со временем формируется собственный стиль и «чутье» на потенциальные недочеты.

Конечно, на первых порах времени и усилий на составление ТЗ уйдет много, но с каждым разом, видя позитивный результат, вы быстрее и легче будете формулировать то техническое задание, которое примут с первого раза.

Путь к образцовому ТЗ начинается с записи на курс

Если вы хотите не просто писать технические задания, а создавать эффективные документы, которые понятны разработчикам и заказчикам, приглашаем пройти курс «Освойте написание ТЗ от и до: полный цикл на практике».