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