Разработка ТЗ: как составить качественное техническое задание — отвечают эксперты

Мое направление в департаменте разработки ПО занимается проектами автоматизации процессов документооборота. Мы разрабатываем и внедряем ECM, СЭД (вендорские решения и систему КСЭД 3.0, собственную разработку, которая включена в реестр российского ПО), электронные архивы, помогаем интегрировать эти системы с ERP, сервисами ЭДО, МЭДО, ССТУ и пр. И входим в пятерку ведущих российских игроков на рынке систем документооборота.

Каждый месяц мы отсматриваем примерно три-четыре десятка ТЗ от разных организаций и сами их пишем, например, для проектов внутренней автомаизации компании или оказывая консалтинг по составлению технического задания в рамках проектов обследования бизнес-процессов заказчиков. При этом мы готовим проектные решения, схемы бизнес-процессов as is / to be, а также экспертные рекомендации по их оптимизации. И здесь важно иметь ввиду возможность последующей реализации таких рекомендаций. Некоторые заказчики или другие игроки рынка ИТ об этом периодически забывают. И, бывает, открываешь техническое задание и не знаешь, как это все сделать исходя из описанного в ТЗ.

Составляем понятное ТЗ для разработчика и заказчика

tproger.ru

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

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

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

Нередко, уже взглянув на первые 3-4 страницы технического задания, можно определить, кто готовил — айтишник, будущий пользователь или бизнес-аналитик. И это плохо, потому что первые — нередко слишком углубляются в технические детали реализации проекта, вторые — концентрируются на деталях работы в системе, которой еще пока нет и не понятно, как она будет выглядеть по результатам опытной эксплуатации, а третьи — на том, как это повлияет на эффективность бизнеса. А еще сразу заметно, когда техническое задание написано наотмашь или когда весь результат проекта не столь важен.

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

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

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

Если вы располагаете информацией об исполнителе, то стоит на этапе анализа обсудить с ним возможные варианты реализации, выслушать его экспертное мнение.

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

По итогам каждой встречи составляйте протокол принятых решений. Таким образом у вас на руках всегда будут аргументы для ответов на спорные вопросы.

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

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

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

Не забывайте про оформление: структурированный текст — 50% успеха.

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

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

Типичные ошибки и подводные камни при составлении ТЗ:

• Не указана ЦА. Когда необходимо рассказать о пользователях продукта или какой-то отдельной его функциональности, заказчик часто углубляется в описание рабочих процессов, но никакой информации о ЦА или о том, какие ее проблемы необходимо решить, так и не обозначает.
• Нет конкретной цели. Из полученного ТЗ не всегда могут быть понятны приоритеты задач и назначение функций.
• Не определены ответственные с каждой из сторон. Очень важно, чтобы заказчик и исполнитель одинаково прозрачно понимали конечное ожидание от продукта или его функциональности. Для этого необходимо иметь возможность обратиться друг к другу с уточняющими вопросами. Чтобы этот процесс был структурирован, с каждой из сторон должны быть определены ответственные сотрудники.

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

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

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

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

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

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

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

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

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

• Максимально подробным в отношении важных функций проекта.
• Однозначно трактуемым.

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

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

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

Вот основные пункты, которые точно должно содержать любое ТЗ:

• Цели и задачи, которые должны быть решены в проекте.
• Сроки.
• Рамки проекта (что должно быть сделано, а что не входит в проект).
• Подробное описание состава проекта и требований к нему.
• Требования к результату.
• Порядок сдачи/приемки проекта.

Ну и последнее, но немаловажное. Цель должна оправдывать средства, поэтому если проект небольшой (условно, сделать работу по нему будет быстрее, чем написать ТЗ), то скорее всего для такого проекта ТЗ будет избыточным. В таких кейсах можно использовать более лаконичные способы формулировки содержания проекта, например, Бриф или Устав.

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

Основная задача ТЗ – донести до разработчика идею заказчика. При этом важно, чтобы:

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

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

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

Несколько советов для заказчика:

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

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

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

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

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

Речь не идет о конкретных архитектурных решениях — как именно мы будем хранить данные. В ТЗ должны быть отражены вопросы такого плана: удаление или архивирование сущностей (пользователей, данных), логирование, статистика, администрирование контента и фильтры, сортировки по этому контенту в административном разделе. Использование коробочных систем, например 1С-Битрикс, много таких вопросов снимает. Но при кастомной разработке ничто не может «подразумеваться по умолчанию». Для разработчика не существует того, что не описано в ТЗ и договоре. Хорошо, если при вышеупомянутой оценке разработчик обратил внимание на отсутствие ряда функциональностей и в смету включил. Но на этапе тендера такие правильные детали могут сделать коммерческое предложение неконкурентным, а представитель заказчика, проводящий тендер, не всегда готов улавливать такие тонкости – у него иные критерии на этапе выбора подрядчика: цена, опыт в схожих проектах и тематике. А внимательность и техническая компетенция при оценке проекта будут далеко не первым критерием при оценке.

Получается палка о двух концах. Либо мы профессионалы и еще на этапе оценки помогаем заказчику с ТЗ, либо мы выбираем другой подход – с рамками и рисками.

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

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

Примеры ошибок в ТЗ из нашей практики:

1. Не учтено логирование при большом количестве контент-менеджеров: невозможно найти, кто внес то или иное изменение. Здесь же обратный случай: не продуманы группы пользователей и их права, со стороны клиента все ходят в админку под одним логином администратора (и люди, отвечающие за добавление новостей, и seo-специалисты, и бухгалтеры).
2. Не продумано удаление и архивирование элементов и разделов: если на элементы завязана какая-то статистика или заказы и это где-то демонстрируется, надо продумать, оставляем ли мы архив и как мы решаем, что показывается. Это важно и для поискового индекса.
3. Не описан механизм нетиповой интеграции с 1С (endpoint, принципы, пр.) – согласование и выстраивание этой интеграции потребует плотных коммуникаций разработчиков и 1с-специалистов, времени и плотного контроля заказчика.
4. Нет выгрузки товарного каталога и описания хранимых данных в 1С по товарам – все они в итоге отдают одно свойство «характеристики», а в ТЗ предусмотрена фильтрация.
5. Не описана созависимость фильтров.
6. Упущены сортировки как таковые.
7. Административный раздел не описан полностью.
8. В административном разделе не описаны фильтры по заказам по дате, номеру, телефону, вообще какие-либо фильтры, которые будут необходимы администратору.
9. Управление мета-тегами забывают всегда: про то, откуда у страницы берется title – нигде не зафиксировано. Здесь же можно отметить весь пул SEO чек-листа (ЧПУ, 404, хлебные крошки, robots, коды счетчиков, редиректы и т.п.).
10. Не прописаны обязательные по законодательству ссылки в футере (например, СОУТ или «Политика конфиденциальности»).
11. Не описаны почтовые уведомления, которые вообще должны быть (о заказе, регистрации, отправленной форме и т.д.).
12. Не описано управление промо-баннерами. Описано все, но про сквозные картинки в дизайне и про слайдер – забыли.
13. Не продумана и, соответственно, не описана работа с заказами, оплатой и доставкой. Какие будут возможности оплатить заказ? Будет ли работа с юридическими лицами, можно ли им дать возможность сразу выставлять счет или работаем только через менеджера? Какие службы доставки используются, какие данные по заказу и товару нужны для расчета стоимости и сроков доставки? Какие статусы заказов, на каких этапах происходит оповещение пользователя о смене статуса и по каким каналам?
14. Клиент при написании ТЗ не продумал структуру контента, не определил разделы и подразделы. Необходимость вложенного меню с подуровнями может выясниться уже после завершения программирования при внесении контента.

Пишите и читайте ТЗ внимательно. Помните: любые неоплачиваемые доработки проекта вне ТЗ и договора съедают вашу маржинальность.

Разбалансированность ТЗ (превалирование «как » над «что»)

Часто бывает, что большую часть ТЗ занимают требования, как должен работать требуемый функционал ПО (процессы работы). А требования к самим результатам работы ПО даны в малом и часто недостаточном количестве. Обычно это связанно с тем, что ТЗ написано специалистами, которые уверены, что если очень детально описать процессы, то этот «путь» неминуемо приведет исполнителя к разработке требуемого ПО. Это ошибка. В реальности, исполнитель потратит дополнительное время на уточнение требований к целевому функционалу, а часть требований к процессам/методам/способам будут оспорены и в итоге признаны опциональными и вторичными.

В первую очередь, в ТЗ должны быть требования к результату работы («что»).

В ТЗ нет нефункциональных требований или они неполные

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

Полноценные нефункциональные требования должны быть неотъемлемой частью ТЗ.

Противоречивые требования

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

ТЗ должно содержать конкретные и точные требования. Многословности без конкретики следует избегать.

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

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

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