Разработка по ТЗ: что нужно знать

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

Как мы работали

  1. Заказчик описывает проблему и желаемое решение.
  2. Мы изучаем бизнес-процессы, помогаем составить максимально детальное техническое задание или принимаем готовое.
  3. Подписываем договор и приступаем к разработке.
  4. Сдаем продукт с проверкой ТЗ.

Недостатки такого подхода

  • Долгое составление ТЗ. Со стороны заказчика проектом руководит собственник бизнеса или руководитель одного из отделов. У них и до этого времени не хватало, а стало ещё меньше.
  • Ошибки в ТЗ. Заказчик привлекает других сотрудников к обсуждению, но невозможно учесть все моменты без опыта использования нового продукта.
  • Нет оперативной обратной связи. Компания ждет итоговый вариант продукта. Смотреть на промежуточные результаты не горит желанием.
  • Долгий процесс разработки. Между составлением ТЗ и сдачей рабочей версии проходит несколько месяцев.За это время может многое поменяться в компании.

Как стали работать

Совместили итеративную разработку с техническим заданием:

  • Согласуем с компанией общее видение целей, задач, аудитории и приоритетных функций продукта.
  • Составляем общее техническое задание без излишней детализации. Посмотрите примеры ТЗ на разработку и доработку программного обеспечения.
    Для первой итерации готовим более детальное ТЗ.
  • Оцениваем ориентировочно стоимость всего проекта и точную для первого этапа, на котором внедряем самые важные функции с учетом проектирования по DDD.
  • Приступаем к разработке и максимально быстро сдаем первую версию продукта. Упор на функции, на уровне интерфейса минимализм.
  • Собираем обратную связь по доработке или внедрению новых функций.
  • Итеративно дорабатываем продукт. При необходимости составляем дополнительные технические задания на крупные итерации.

Ситуация из практики

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

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

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

Но со стороны клиента внезапно появились новые требования — ТЗ по ГОСТ со всеми вытекающими: начиная от структуры БД, заканчивая пунктами о разрешении коллизий. От проекта отказались.

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

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

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