Кто должен составлять техническое задание?

Этим вопросом часто задаются представители заказчика, когда возникает необходимость автоматизировать какой-либо бизнес-процесс. Почему-то сегодня со стороны большинства заказчиков нет полного понимания того, насколько это важный этап, а не простая бюрократическая волокита. И насколько скрупулезно обе стороны подойдут к этому этапу работ, настолько будет более точным, правильным, ожидаемым и быстрым результат проекта.
Что ж попробуем разобраться. Давайте для начала все-таки определимся, что же такое техническое задание?
Техническое задание (ТЗ) — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Можно сказать, что ТЗ - документ, в котором описывается, ЧТО нужно заказчику, в отличие от последующей проектной документации, в которой акцент переносится на ответ на вопрос, КАК этого достичь.
(Материал из Википедии).
Данное определение, на мой взгляд, полностью раскрывает суть термина. Итак, основное назначение ТЗ полностью раскрыть и описать все требования, предъявляемые к желаемому результату заказчиком. От того, как сформулированы эти требования, зависит успех или неуспех проекта. И на данном этапе заинтересованность в успехе должны проявлять максимально обе стороны. Заказчик – чтобы потратить меньше средств на переделку неудачного проекта, исполнитель – чтобы меньшими усилиями успешно завершить проект и получить прибыль. И как раз на этом этапе возникает резонный вопрос: кто должен писать данный документ?
С одной стороны, казалось бы, это должен делать заказчик, т.к. он и только он полностью знает, что же он хочет видеть в результате. Но сможет ли данная сторона, не обладая техническими знаниями в области разработки программного обеспечения, корректно изложить все свои требования? Провести их анализ на предмет того, что каждое требование должно быть понятным, конкретным, тестируемым, как того требуют правила составления ТЗ. «Хочу кнопку красного цвета, дающую точные данные по продажам за месяц!». Наверное, ничего вразумительного на основе данного ТЗ исполнитель не реализует.
Тогда ТЗ должен писать сам исполнитель? Тоже не идеальный вариант. Исполнитель, получив от заказчика изложение задачи, может интерпретировать её немного в ином русле, как понимает задачу сам. И сухой технический язык, на котором будут изложены все понятые исполнителем требования, не даст ответа заказчику – то ли он имел в виду, описывая желаемый результат. Особенно комично выглядит ситуация, когда на стол руководителя заказчика попадает документ, изобилующий технической терминологией, специфическими словами, зачастую на английском языке, который он должен подписать и, соответственно, подтвердить, что всё написанное это то, что они и просили!
Поэтому наиболее оптимальный вариант – это работа в тандеме. Именно при полном погружении исполнителя в предметную область заказчика, разговор на одном языке при построении списка требований, когда сходятся воедино язык потребителя-неспециалиста и язык разработчика, рождается документ, на основании которого будет создан продукт, максимально приближенный к исходной поставленной цели. Такой синтез даст обеим сторонам полное понимание описываемого процесса. Не будет сомнений в том, что какая-то часть технического документа осталась «белым пятном» и во что эта часть превратится в результате.
Да, написание ТЗ сложная задача, но лучше временные инвестиции вложить в данный этап, нежели найти брешь и выяснить, что нужно переделывать фундамент, когда пришло время положить крышу.
И главное, перед тем, как создавать документ, заказчику нужно понять, что именно он хочет видеть в результате, а исполнителю – отказаться от реализации невыполнимых требований.
Успешных вам проектов!