Секрет идеального технического задания: как получить именно то, что вы хотите, и упростить работу исполнителю

Когда результат не совпадает с ожиданиями

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

Первый порыв — искать виноватых среди разработчиков. Но в большинстве случаев причина не в качестве исполнения. Причина раньше: в том, как были сформулированы требования.

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

Почему проекты «едут» даже с хорошими исполнителями

Представьте: вы нанимаете сильную команду, даёте им задачу — и через три месяца получаете не то. Как так вышло?

Чаще всего причина одна из четырёх.

Требования размыты. «Хотим автоматизировать продажи» — это не задача. Это направление. Что именно автоматизировать? На каком этапе? По каким правилам? Что считать успехом? Без ответов на эти вопросы каждый член команды будет додумывать по-своему.

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

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

Аналитики перегружены. Даже если в команде есть грамотный специалист, у него уже есть текущие задачи. Проект по автоматизации бизнес-процессов добавляется сверху — и прорабатывается в режиме «между делом».

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

Что такое техническое задание на самом деле

Техническое задание — это не бюрократический документ, который нужно подписать, чтобы начать работу. Это инструмент синхронизации.

Хорошее техническое задание отвечает на три вопроса:

• Как устроен процесс сейчас?

• Как он должен работать после внедрения?

• По каким критериям мы поймём, что всё сделано правильно?

Когда на эти вопросы есть чёткие ответы — заказчик и исполнитель смотрят в одну сторону. Когда ответов нет — каждая сторона смотрит в свою.

Из чего состоит сильное техническое задание

Сильное техническое задание при автоматизации бизнес-процессов включает несколько обязательных блоков. Каждый из них важен — и каждый требует отдельной работы. 

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

Описание процессов «как будет». Целевое состояние должно быть описано не на уровне желаний, а на уровне конкретных действий: что происходит, в какой момент, по какому условию, кто отвечает за результат.

Схемы и диаграммы. Текст хорошо передаёт логику, но плохо передаёт взаимосвязи. Схемы процессов, диаграммы потоков данных, макеты интерфейсов — это язык, который понятен и бизнесу, и разработчикам одновременно.

Функциональные и нефункциональные требования. Что система должна делать — и как она должна это делать. Скорость, надёжность, интеграции с другими системами, ограничения по безопасности. Всё это влияет на архитектуру и должно быть зафиксировано заранее.

Критерии приёмки. По каким признакам заказчик поймёт, что задача выполнена? Конкретные сценарии, конкретные результаты. Без этого блока любая сдача проекта превращается в переговоры о том, «правильно» ли сделано.

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

Проработать все эти блоки качественно — значит потратить время и привлечь людей с нужной экспертизой. Это не та работа, которую можно сделать «заодно».

Где компании чаще всего теряют качество требований

Есть три типичных сценария, которые повторяются из проекта в проект.

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

Требования пишет «тот, кто свободен». У этого человека может не быть ни опыта системной аналитики, ни понимания, как устроено внедрение. Он старается — но делает то, что умеет: описывает задачу так, как понимает её сам. Этого недостаточно.

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

Подробнее о том, почему автоматизация бизнес-процессов буксует ещё до старта разработки, мы писали в статье о типичных ошибках при выборе подрядчика.

Как внешние специалисты помогают закрыть этот разрыв

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

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

Предоставление специалистов по модели аутстаффинга решает сразу несколько практических вопросов.

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

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

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

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

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

Практические ориентиры

Когда стоит привлекать внешнего аналитика:

• в команде нет специалиста по системной аналитике

• проект затрагивает несколько подразделений и процессов

• уже был опыт неудачного внедрения

• сроки сжатые и нет времени на ошибки

Как понять, что техническое задание слабое:

• в документе нет описания текущих процессов — только пожелания

• нет схем и диаграмм

• требования написаны на уровне «должно быть удобно»

• отсутствуют критерии приёмки

• непонятно, что происходит при изменении требований

Какие вопросы задать внешнему аналитику на входе:

• Как вы будете собирать требования от бизнеса?

• Какие артефакты будут на выходе?

• Как вы работаете с противоречиями в требованиях от разных подразделений?

• Был ли у вас опыт в нашей отрасли или с похожими системами?

Вывод

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

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

Если в команде не хватает экспертизы для качественной системной аналитики, это не повод откладывать проект или рисковать результатом. Это повод усилить команду теми, у кого эта экспертиза есть.

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

Правильно поставленная задача — это уже половина решения. Иногда для этого достаточно одного правильного человека рядом.