Мы разрабатываем программное обеспечение для сложных бизнес-процессов, которые укладывать в рамки готовых продуктов неэффективно. Часто готовых решений нет в принципе.
Как мы работали
- Заказчик описывает проблему и желаемое решение.
- Мы изучаем бизнес-процессы, помогаем составить максимально детальное техническое задание или принимаем готовое.
- Подписываем договор и приступаем к разработке.
- Сдаем продукт с проверкой ТЗ.
Недостатки такого подхода
- Долгое составление ТЗ. Со стороны заказчика проектом руководит собственник бизнеса или руководитель одного из отделов. У них и до этого времени не хватало, а стало ещё меньше.
- Ошибки в ТЗ. Заказчик привлекает других сотрудников к обсуждению, но невозможно учесть все моменты без опыта использования нового продукта.
- Нет оперативной обратной связи. Компания ждет итоговый вариант продукта. Смотреть на промежуточные результаты не горит желанием.
- Долгий процесс разработки. Между составлением ТЗ и сдачей рабочей версии проходит несколько месяцев.За это время может многое поменяться в компании.
Как стали работать
Совместили итеративную разработку с техническим заданием:
- Согласуем с компанией общее видение целей, задач, аудитории и приоритетных функций продукта.
- Составляем общее техническое задание без излишней детализации. Посмотрите примеры ТЗ на разработку и доработку программного обеспечения.
Для первой итерации готовим более детальное ТЗ. - Оцениваем ориентировочно стоимость всего проекта и точную для первого этапа, на котором внедряем самые важные функции с учетом проектирования по DDD.
- Приступаем к разработке и максимально быстро сдаем первую версию продукта. Упор на функции, на уровне интерфейса минимализм.
- Собираем обратную связь по доработке или внедрению новых функций.
- Итеративно дорабатываем продукт. При необходимости составляем дополнительные технические задания на крупные итерации.
Ситуация из практики
К нам обратилась компания, с которой мы быстро нашли общий язык. Первый релиз небольшой, но достаточный для погружения в предметную область.
В приложении к договору ТЗ оформляем почти всегда. Исключение — постоянные клиенты, продукт которых развиваем на протяжении многих лет. Однако для новых клиентов ТЗ — обоюдная гарантия выполнения работ.
В этом случае наше ТЗ уместилось на 7 листов с описанием основной функциональности первого релиза с точки зрения бизнеса. Это то, что важно для компании и по чему можно принять работу.
Но со стороны клиента внезапно появились новые требования — ТЗ по ГОСТ со всеми вытекающими: начиная от структуры БД, заканчивая пунктами о разрешении коллизий. От проекта отказались.
Мы не всегда против жесткого ТЗ. Иногда оно нужно. Например, работаем с одним крупным заводом. В проекте много вычисляемых параметров, расчетов и т.д. ТЗ здесь необходимо, без него проект не оценить и не реализовать.
Понимаем требования клиента: формализация проекта желательна. Вдруг с нами что-то не срастется — продукт хотелось бы легко передать другим разработчикам. Но это решается не до мелочей проработанным до начала разработки ТЗ, а документацией после.
По ходу разработки меняется многое. Зачастую клиент сам вносит новые идеи. Кроме того, команда погружена в проект и в предметную область лучше, чем до начала работ. В итоге решения будут более взвешенными, чем при составлении ТЗ для данных и процессов в вакууме.
