Как плохое ТЗ может удвоить стоимость проекта

«Как мы сократили срок разработки с года до четырех месяцев?» — сделали в три раза меньше функций, чем было запланировано изначально.

Получается, что проанализировали результат проектирования, сделали собственное проектирование и изменили функционал проекта. По факту сделали другой проект с другим набором функций.

Тут возникает много вопросов, которые влияют на восприятие статьи: кто делал первоначальное проектирование, кто делал новое проектирование, как согласовывали уменьшение функциональности в три раза и т.п. Не хватает контекста.

TL;DR

Waterfall vs Agile

Один из самых эффективных способов избежать перегруженных требований — формулировать задачи через пользовательские истории.

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

В одном из проектов стояла задача создать новый цифровой сервис для клиентов компании.

Какой сервис? Какая компания?

У каждой компании есть какой-то набор сервисов (то есть — услуг). Откуда возникает необходимость в новой услуге? Компания решила расширить свой бизнес? А как были реализованы прежние услуги? И как в эту реализацию вписывается (или может вписаться) новая услуга? И, конечно же, крайне интересно знать, а нет ли конторы, где эта услуга уже реализована в полном объёме, и не целесообразнее взять её уже готовую и интегрировать?

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

Постановка неактуальной задачи? Как можно было так грубо ошибиться в оценках перспективы?!! И, конечно же, вездесущие ожидания пользователей. Я как пользователь много чего ожидаю от программного обеспечения. Но, почему-то, мои ожидания никто не торопится реализовывать. Например, мне нужно 1) иметь протокол действий каждого приложения ОС (с возможностью отмены); 2) полное описание работы самого приложения (чтобы понять, как оно работает; не справка, а живая демонстрация возможностей без реальных последствий); 3) полный контроль над данными приложения (чтобы можно было самому решать, что, как и где должно хранится; а то память телефона/системный диск практически заполнены, а что там можно и как удалить, неизвестно). Никто никогда не сделает!

К моменту начала разработки часть требований уже устаревает.

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

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

Кто сказал, что дополнительные? Потом опять что-то изменится, и некоторые дополнительные станут основными. Сколько ещё месяцев придётся накинуть?

При этом продукт начал приносить бизнесу ценность гораздо раньше.

Без реального примера невозможно ничего обсуждать конкретно.

Такая формулировка заставляет команду думать о потребности пользователя, а не о функциях системы.

Кэшбек (он же возврат?) — это одна из функций системы. Либо она есть, и её надо реализовывать. Либо её нет, и тогда её не надо будет реализовывать. Всё просто.

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

Вопрос не в длине, а в качестве.

И ещё.

Это позволило сократить срок разработки до четырех месяцев. Если посчитать экономику проекта, результат становится еще более наглядным.

Более всего интересует, а чем заняты эти месяцы? Вот, кто-нибудь взял бы и расписал, как на деле происходит разработка. Почему такая-то операция потребовала такого-то времени? Можно было бы сделать быстрее? И что нужно было бы иметь, чтобы сделать быстрее?

Куда идут средства от экономии на разработке?

Как плохое ТЗ может удвоить стоимость проекта

Хорошее (идеальное) ТЗ может написать только разработчик и только после завершения разработки (и это будет первая часть ТУ на программу).