Что делать, когда Лебедь, Рак и Щука задумали писать ТЗ? Как разработчик может им помочь?

Меня зовут Михаил Иванычев, я CTO в компании Зионек. Мы внедряем CRM, занимаемся сложной разработкой, и создаём корпоративные порталы и сложные высоконагруженные системы. Я уже писал о нашем нестандартном подходе — мы никогда не "брифуем" клиентов и используем наши собственные методы составления технических заданий для разных видов работ. Однако, не всегда легко объяснить заказчикам, зачем вообще нужно "ТЗ". Данная статья — попытка такого объяснения. Буду рад комментариям — как вы объясняете заказчикам ценность правильного ТЗ?

Позвольте мне начать эту статью не с того, кто, как и почему делает что-то неправильно, а с конца — и описать, как всё должно быть на самом деле, чтобы всё получилось хорошо и работы по созданию новой системы и внедрению завершились успехом.

Однако, что такое успех?

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

А вот тогда, когда исполнителю/разработчику это на самом деле неясно, и новые задачи вдруг неожиданно всплывают в процессе выполнения работ — вот тогда-то и оказываются сроки — сорванными, а затраты превышают запланированный бюджет.

И вот выходит на сцену Техническое Задание.

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

Откуда же берётся такое ТЗ? Кто его пишет так, чтобы оно получилось одновременно и совершенно конкретным, детальным, и пригодным к тому, чтобы разработчик мог немедленно начать его реализовывать, и при этом, чтобы заказчик прекрасно видел и понимал, какая система у него будет?

Всё просто: такое ТЗ может составить, и должен составить — сам исполнитель.

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

В отличие от ТЗ (технического документа в специальном формате), функциональные требования можно изложить и передать исполнителю в любом удобном виде (в том числе нарисовать на салфетке, написать на листочке А4 или рассказать на созвоне в Зуме), и эти требования описываются в терминах бизнеса заказчика (а не на техническом языке разработчика).

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

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

Созданное таким образом ТЗ становится далее частью договора на дальнейшую разработку и основой для расчета сметы на работы.

А теперь, после такого длинного спойлера выше— описания того, как всё должно быть, когда всё правильно — давайте посмотрим, почему иногда оказывается, что что-то идёт не так.

Время от времени появляются заказчики, которые уверены, что именно перед ними стоит задача «написать ТЗ». Иногда заказчики даже приходят к специалистам-разработчикам с «готовым ТЗ», которое где-то скачали, как готовую школьную домашку. Почему случилось так, что термин «ТЗ» почти повсеместно (кроме области профессиональной разработки) применяется вместо правильного термина «Функциональные Требования»? Откуда взялась эта ошибка в мышлении людей? Ведь заказчик не обладает компетентностью , позволяющей вести разработку или руководить ею, а разработка ТЗ — это первый этап разработки самой системы.

Источник проблемы, скорее всего, в том, что специальный термин «Техническое Задание» (обладающий очень узким и конкретным смыслом), оказался слишком сильно похож на обычное бытовое слово «задание» — а оно, в свою очередь, в быту ничем не отличается от слова «задача». Задача — это и «поставить задачу в CRM», это и записаться к врачу, это и школьная задача на умножение, с которой ребёнок просит ему помочь.

Детям задают в школе разные «домашние задания», родители пытаются усадить детей делать эти «задания»; спрашивают, какую оценку ребёнок получил за то или иное «задание» и так далее. Задания вполне могут быть и устными, и неконкретными, и непонятными, а в процессе выполнения очень часто меняются: никакой чёткости в них нет, никто чёткости не ждёт, и всё это воспринимается спокойно. Со школьных времён всё это слилось в один мутный образ, который теперь мешает нам внятно думать.

В результате, слово «задание» с детства стало в нашей жизни настолько бытовым и нечётким, что уже выросшие взрослые, ставшие заказчиками различных работ, предполагают, что если просто «подробно и детально описать, что нам нужно» — то это описание и будет являться Техническим Заданием для исполнителя (разработчика). «Мы же, в конце концов, описываем серьёзные технические вещи, а не рецепт пирога, — думает заказчик, — значит, у нас получилось Техническое Задание». Увы, это не так.

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

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

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

Откуда берётся эта разница в качестве ТЗ (и соответственно, в качестве будущей системы)?

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

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

Мы в Зионек за много лет накопили очень большой опыт внедрения сложных систем и разработали собственные методы составления ТЗ и выявления потребностей и функциональных требований клиентов — при этом у нас различные подходы к разработке ТЗ для веб-порталов и для внедрения CRM.

Подробно о нашем подходе я написал в следующих статьях:

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

И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!