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

Разработка программного обеспечения может осуществляться различными способами. Один из подходов – это когда заказчик описывает свою проблему и желаемый выход из неё, а специалисты, изучив бизнес-процессы, помогают ему составить самое подробное техзадание или принимают уже готовое. Далее сторонами подписывается договор – и начинается процесс разработки. Итогом становится сдача продукта с проверкой ТЗ.

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

Более эффективный подход – совмещение итеративной разработки с техническим заданием: с компанией согласовывается общее видение целей, аудитории и самых важных функций продукта; составляется общее техзадание без лишней детализации, затем – более подробное; ориентировочно оценивается весь проект и определяется точная его стоимость для первого этапа, в рамках которого внедряются самые важные функции при учёте проектирования по DDD. После этого эксперты приступают к разработке - и в максимально краткие сроки сдают первую версию продукта. Упор при этом делается на функции, а не на интерфейс. Далее специалисты собирают обратную связь по доработке либо внедрению новых опций – и итеративно дорабатывают продукт. В случае необходимости составляются дополнительные ТЗ на крупные итерации.

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