Техническое задание – один из первых документов, который появляется перед разработкой программного обеспечения. На практике именно на этом этапе закладывается значительная часть будущего проекта: его стоимость, сроки, состав команды, архитектура и итоговый результат.
При этом для бизнеса техническое задание часто остается непонятным документом. Заказчик знает, какую проблему хочет решить, но не всегда понимает, как описать ее так, чтобы разработчики одинаково представляли будущую систему.
В результате уже во время работы появляются дополнительные требования, меняются приоритеты, пересматриваются сроки и увеличивается бюджет проекта.
Проблема обычно не в том, что компания внесла изменения в требования. Для сложных IT-проектов это нормально. Основной риск возникает тогда, когда на старте не определены границы проекта, бизнес-цели и ожидаемый результат.
Поэтому хорошее техническое задание – это не документ «для программистов». В первую очередь это инструмент управления проектом со стороны бизнеса.
В этой статье разберем, что такое ТЗ на разработку программного обеспечения, какую информацию в него нужно включить, как правильно сформулировать требования к будущей системе и какие ошибки чаще всего приводят к росту стоимости и сроков разработки.
Что такое техническое задание на разработку ПО
Универсального шаблона ТЗ, который одинаково подойдет для любого проекта, не существует. Документ для мобильного приложения будет отличаться от ТЗ на ERP-систему, B2B-платформы или требований к внутреннему корпоративному порталу.
При этом логика подготовки документа обычно остается похожей. В первую очередь необходимо описать сам проект и бизнес-задачу: зачем создается система, какую проблему она должна решить и какой результат ожидает компания.
Например: формулировка «создать внутреннюю систему управления заказами» – слишком общая.
Гораздо полезнее описать задачу через конкретный процесс: «создать единую систему управления заказами, которая 1- позволяет менеджерам принимать заявки, 2-контролировать их статус, 3- передавать информацию в производство и получать актуальные данные о выполнении заказа без ручного обмена файлами между отделами».
Такая формулировка уже дает разработчикам представление о том, какую задачу должна решать система.
Следующий важный элемент – цели проекта. Их желательно формулировать так, чтобы результат можно было проверить. Вместо абстрактного «сократить время обработки заявки» можно поставить конкретную цель: например, уменьшить среднее время обработки с 20 до 10 минут.
Другой вариант – исключить ручной перенос данных между CRM и учетной системой или предоставить клиентам возможность самостоятельно отслеживать статус заказа.
После этого необходимо описать пользователей будущей системы. В корпоративном ПО редко все работают с одинаковым набором функций. Менеджеру может быть доступна информация о его клиентах и сделках, руководителю – данные всего подразделения, финансовому специалисту – платежная информация, а клиенту – только его собственные заказы. Эти различия важно определить еще до начала разработки, поскольку они влияют и на интерфейс, и на бизнес-логику, и на систему прав доступа.
Особое внимание стоит уделить описанию бизнес-процессов. Это одна из наиболее важных частей ТЗ с точки зрения бизнеса. Разработчику недостаточно знать, что в системе должны существовать заявки, счета и уведомления. Необходимо понимать, как эти элементы связаны между собой.
Например, процесс может начинаться с заявки клиента, после чего менеджер проверяет данные, формирует коммерческое предложение, получает подтверждение, передает заказ в производство, создает счет и контролирует оплату.
Если описать только отдельные функции, связь между ними может потеряться. Описание процесса позволяет увидеть будущую систему целиком.
Именно поэтому перед разработкой часто требуется не просто составить список пожеланий, а разобраться в том, как компания работает сейчас и каким должен стать процесс после внедрения новой системы.
Как описать функциональные требования
Функциональные требования определяют, что именно должна уметь система. Это наиболее привычная часть технического задания, однако именно здесь часто появляется слишком много общих формулировок.
Например, требование «пользователь должен иметь возможность создать заявку» само по себе мало что говорит разработчику. Необходимо понимать, какие данные вводятся, какие поля обязательны, можно ли прикреплять документы, кто получает уведомление после создания заявки, какие статусы существуют и что происходит после изменения каждого из них.
Хорошая формулировка должна описывать не только действие пользователя, но и результат этого действия. Например: «Менеджер создает новую заявку, указывает данные клиента и параметры заказа. После сохранения заявка получает статус “Новая” и становится доступна руководителю отдела».
В таком описании уже присутствует бизнес-логика. Разработчик понимает, кто выполняет действие, какие данные ему доступны и что должно произойти после сохранения информации.
При этом не стоит пытаться превратить техническое задание в описание каждой кнопки будущего интерфейса. Если конкретное визуальное решение не влияет на бизнес-процесс, его лучше оставить на этап проектирования интерфейса. ТЗ должно фиксировать требования к системе, а не заранее диктовать дизайнеру расположение каждого элемента.
Какие требования бизнес часто забывает включить в ТЗ
Помимо функциональности, необходимо определить, как система должна работать. Это так называемые нефункциональные требования.
Для бизнеса здесь важны прежде всего практические параметры. Сколько пользователей одновременно смогут работать в системе? Как быстро должны выполняться основные операции? Что произойдет при увеличении нагрузки? Как организуется резервное копирование? Какие требования предъявляются к доступности системы? Какие данные нельзя показывать определенным категориям сотрудников?
Для небольшого внутреннего проекта часть этих вопросов действительно может быть несущественной. Но если речь идет о корпоративной платформе с большим количеством пользователей, высокой нагрузкой или большим объемом данных, оставлять их без внимания рискованно.
Представим интернет-платформу, которая хорошо работает при нескольких сотнях пользователей. Если при ее проектировании никто не определил требования к производительности и масштабированию, рост аудитории может привести к необходимости серьезной переработки системы. Поэтому предполагаемый рост лучше учитывать еще до начала разработки.
То же касается безопасности. Формулировка «система должна быть защищена» слишком общая. Необходимо понимать, какие категории пользователей существуют, какие данные они могут видеть, какие действия должны журналироваться и какие требования предъявляются к авторизации и хранению информации.
Как описывать интеграции
Современное корпоративное ПО редко работает изолированно. Новая система может взаимодействовать с CRM, ERP, 1С, сайтом, телефонией, платежными сервисами, складской системой или внутренними базами данных.
Поэтому фразы вроде «интегрировать систему с 1С» недостаточно. В ТЗ необходимо определить, какие данные передаются, в каком направлении происходит обмен, когда он запускается и что должно происходить при ошибке.
Например, после создания оплаченного заказа новая система может передавать информацию о нем в 1С, а из 1С получать сведения о статусе оплаты и наличии товара. Такая формулировка уже описывает не просто факт интеграции, а ее бизнес-логику.
Это важно и для оценки стоимости проекта. На практике интеграция часто оказывается сложнее, чем кажется на первом этапе. У разных систем могут отличаться справочники, идентификаторы, форматы данных и правила обработки информации. Поэтому интеграцию следует рассматривать не как простое «соединение двух программ», а как отдельную задачу по согласованию данных и бизнес-логики.
Почему важно описать данные
Если новая система заменяет существующее ПО, необходимо заранее определить, какие данные будут перенесены. Это могут быть сведения о клиентах, заказах, договорах, документах, справочниках и истории операций.
Однако здесь важно учитывать не только объем информации, но и ее качество. В старой системе могут существовать дубликаты, устаревшие записи, незаполненные поля или несколько вариантов одного и того же справочника.
Если перенести все данные без предварительной проверки, новая система просто унаследует старые проблемы. Поэтому миграция данных иногда становится отдельным этапом проекта, который необходимо учитывать еще при подготовке ТЗ.
Как определить границы проекта
Одна из главных задач технического задания – зафиксировать, что именно входит в проект.
На старте компания может планировать относительно простую систему, а в процессе обсуждения обнаружить множество дополнительных потребностей. Например, к базовой CRM постепенно добавляются телефония, интеграция с 1С, мобильное приложение, автоматическое формирование документов, расширенная аналитика и импорт данных из старой системы.
Каждая функция сама по себе может быть оправданной. Но вместе они существенно меняют масштаб проекта.
Поэтому еще на этапе подготовки ТЗ полезно определить, что необходимо для первого запуска, а что можно реализовать позже. Это позволяет не отказываться от перспективных функций, но и не перегружать первую версию продукта.
Здесь же появляется понятие MVP – минимальной версии продукта, которая уже решает основную бизнес-задачу. MVP не означает, что система должна быть недоделанной. Его смысл в том, чтобы сначала реализовать наиболее важный сценарий и получить работающий результат, а затем развивать продукт на основании реального опыта пользователей.
Как ТЗ влияет на стоимость разработки
Стоимость разработки программного обеспечения зависит от большого количества факторов. На нее влияют не только количество функций, но и сложность бизнес-логики, число пользователей, интеграции, объем данных, требования к безопасности и производительности.
Например, две системы управления заказами могут выглядеть похожими с точки зрения названия, но принципиально отличаться по сложности. Первая может использоваться двадцатью сотрудниками и работать автономно. Вторая должна взаимодействовать с CRM, ERP и 1С, поддерживать несколько тысяч пользователей и обеспечивать высокую доступность.
Поэтому вопрос «сколько стоит разработать такую систему?» имеет смысл только после определения требований.
При этом даже качественное ТЗ не означает, что стоимость проекта никогда не изменится. Бизнес может добавить новую функцию, изменить приоритеты или принять решение о подключении еще одной внешней системы. Важно другое: изменения должны быть зафиксированы и оценены до того, как они попадут в разработку.
Как проверить ТЗ перед началом разработки
Перед согласованием документа стоит проверить, можно ли по нему получить однозначное представление о будущем продукте.
Прежде всего должно быть понятно, какую бизнес-проблему решает система и какого результата компания ожидает после ее внедрения. Должны быть определены пользователи и их права, описаны основные бизнес-процессы и зафиксирован необходимый функционал.
Отдельно стоит проверить интеграции и работу с данными. Если система заменяет существующее ПО, должно быть понятно, что именно переносится и как будет организована миграция.
Наконец, необходимо определить критерии приемки. Бизнес и команда разработки должны одинаково понимать, по каким признакам можно считать конкретную функцию или весь проект выполненным.
Если для ответа на эти вопросы приходится постоянно обращаться к человеку, который составлял ТЗ, значит, документ еще недостаточно проработан.
Техническое задание как инструмент управления проектом
Техническое задание на разработку ПО – это не формальность и не документ исключительно для программистов. Для бизнеса это способ заранее договориться о том, какую проблему должна решить система, кто будет ей пользоваться, как должны работать основные процессы и какой результат можно считать успешным.
Чем сложнее программный продукт, тем большее значение имеет такая подготовка. Особенно это касается корпоративных систем, которые должны взаимодействовать с существующей IT-инфраструктурой, поддерживать несколько подразделений, работать с большими объемами данных и развиваться вместе с компанией.
При этом хорошее ТЗ не требует заранее описывать каждую кнопку и выбирать технологию для каждой функции. В первую очередь оно должно зафиксировать бизнес-логику и требования к результату, оставляя команде разработки возможность выбрать оптимальный способ реализации.
Самый правильный вопрос перед началом IT-проекта звучит не «какую программу мы хотим сделать?», а «какую проблему бизнеса мы хотим решить с помощью этой системы?».
Именно с ответа на него начинается качественное техническое задание.