Как написать техническое задание

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

Так как КодЛикс - компания занимающаяся разработкой программного обеспечения, будем рассматривать особенности технического задания именно на программное обеспечение.

Если подходить к вопросу формально, то в Российской системе государственных стандартов (ГОСТов) существует отдельный документ, регламентирующий содержание ТЗ на программное обеспечение. Это ГОСТ 19.201-78. 19-я серия ГОСТов относится к программной документации и носит название "Единая система программной документации" (ЕСПД). Число 78 - это год разработки документа. Документ старый, если не сказать больше. Однако, структура ТЗ описанная в ГОСТ 19.201-78 вполне удовлетворяет современным требованиям и может быть взята за основу.

Некоторые разработчики берут за основу стандарт на техническое задание на автоматизированную систему - ГОСТ 34.602-89. Документ обширный, содержит множество пунктов, необходимость которых весьма сомнительна. В итоге ТЗ получается насыщенным излишней информацией, содержит море "воды", из которой вычленить суть крайне сложно (если до неё вообще доходят руки разработчика документа).

Если со структурой более или менее понятно, то содержание - огромное поле для творчества.

Начну с типичных ошибок, с того, что не стоит включать в ТЗ:

  1. Указание инструментария или стека разработки. Если перед Вами не стоит задача применения определённых технологий, например, разрабатываемое программное обеспечение должно быть технологически на одной платформе с уже разработанным, то оставьте выбор инструментария профессионалам. Во-первых, разработчик может иметь готовые решения или наработки, полученные в других заказах, что значительно сократит сроки и цену разработки, но, естественно, не в случае если он будет повторно разрабатывать то же самое под модную платформу заказчика. Во-вторых, разработчики многих платформ и технологий сильно преувеличивают преимущества и старательно замалчивают слабые места своих разработок. Неопытный в разработке программного обеспечения заказчик может поддаться воздействию маркетологов и веянию "новых технологий", а в результате получить медленную, нестабильную или невероятно дорогую в содержании разработку (мода пройдёт, разработчики и программисты работающие с данной технологией "вымрут" естественным образом, те единицы что останутся, будут стоить невероятно дорого).
  2. Выделение программных модулей, связей между ними. По классике, это работа системного архитектора (проектировщика, аналитика). Если Вы обладаете достаточным опытом и знаниями что бы спроектировать сбалансированную и не избыточную систему, то Вам стоит разработать полноценный технический проект и передать его на реализацию - это значительно дешевле. Однако, хороший системный архитектор - дефицит, стоит достаточно дорого. И это не просто так. Что бы качественно выполнять проектирование программного обеспечения, нужно обладать колоссальным объемом знаний и опыта. Например, что бы правильно выбрать платформу и средства реализации нужно знать все доступные технологии, их слабые и сильные стороны, особенности "поведения" в различных условиях, под нагрузкой или в условиях низкой производительности вычислительных средств. На технологическую платформу нужно наложить программные модули (или типовые паттерны) и связи между ними, что бы избежать "узких мест", обеспечить должную надёжность и производительность - всё это задачи требующие обширных знаний, подкреплённых опытом.
  3. Эскизы или формы пользовательского интерфейса. В первом приближении это задача системного архитектора - именно он, основываясь на ролевой модели, составит сценарии работы пользователя(ей), перечни представляемой информации и элементов управления. Эта информация так же входит в технический проект. Далее, возможны два сценария разработки пользовательского интерфейса: внешний вид разрабатывает программист и приводит его в соответствие с пожеланиями заказчика или интерфейс формируется эргономистом, с учётом стандартов и требований. Второй вариант предпочтительнее, т.к. обеспечивает наиболее комфортные и эффективные инструменты для работы пользователя, что, в свою очередь, сказывается на результативности применения разработанного программного обеспечения Заказчиком.

Далее, что стоит включить в техническое задание:

  1. Требования к аппаратному обеспечению на котором планируется работа программного обеспечения. Данный фактор влияет как на выбор платформы (например, некоторые операционные системы могут попросту не иметь драйверов для Вашего оборудования), так и на непосредственное проектирование: к примеру, ни один разработчик не справится с задачей качественного отображения 3D-графики на старенькой встроенной видеокарте, но данную задачу можно решить в распределённой системе применением механизма тонких клиентов. 
  2. Требования к объёмам обрабатываемой информации: например, если Вы планируете вести учёт 50-60 клиентов в год (не важно в какой области), то ваше программное обеспечение сможет работать на бытовом персональном компьютере. Однако, если у вас большой поток клиентов, достигающий 30-40 тысяч клиентов в год и Вы видите расширение своего бизнеса, то программное обеспечение необходимо разрабатывать распределённым, предполагающим несколько рабочих мест для сотрудников и выделенным сервисом хранения и обработки данных.
  3. Список ролей пользователей. Чётко определите возможные роли, например: администратор, оператор колл-центра, директор колл-центра, специалист по приёму, директор. "Добавить" забытую роль будет стоить средств, а иногда может потребовать и кардинальных изменений в программном обеспечении.
  4. Для каждой роли определите функциональные задачи и возможности, которые должно предоставлять программное обеспечение.

Для формирования пунктов 3 и 4 удобно применять диаграмму использования - стандартным инструментом UML: в "овалах" опишите желаемые функции, возможности, решаемые задачи, "человечками" обозначьте роли пользователей или смежных систем, после чего соедините связями овалы с соответствующими ролями (см. рисунок).

Диаграмма использования

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

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