Comments 8
«Как мы сократили срок разработки с года до четырех месяцев?» — сделали в три раза меньше функций, чем было запланировано изначально.
Получается, что проанализировали результат проектирования, сделали собственное проектирование и изменили функционал проекта. По факту сделали другой проект с другим набором функций.
Тут возникает много вопросов, которые влияют на восприятие статьи: кто делал первоначальное проектирование, кто делал новое проектирование, как согласовывали уменьшение функциональности в три раза и т.п. Не хватает контекста.
TL;DR
Waterfall vs Agile
Один из самых эффективных способов избежать перегруженных требований — формулировать задачи через пользовательские истории.
Наивная ложь. Минусы у этого подхода тоже есть, и утверждать что он лучше в плане работы с требованиями - значит не иметь реального опыта фрагментации и размазывания некачественных требований по треккеру, да так что ты потом не знаешь а как оно на самом деле должно работать. Так же хочется объявить какой-то инструмент нашим спасением. Но нет. Он никогда не заменит разум.
В одном из проектов стояла задача создать новый цифровой сервис для клиентов компании.
Какой сервис? Какая компания?
У каждой компании есть какой-то набор сервисов (то есть — услуг). Откуда возникает необходимость в новой услуге? Компания решила расширить свой бизнес? А как были реализованы прежние услуги? И как в эту реализацию вписывается (или может вписаться) новая услуга? И, конечно же, крайне интересно знать, а нет ли конторы, где эта услуга уже реализована в полном объёме, и не целесообразнее взять её уже готовую и интегрировать?
Пока команда полгода готовит документацию, меняются приоритеты бизнеса, требования рынка и ожидания пользователей.
Постановка неактуальной задачи? Как можно было так грубо ошибиться в оценках перспективы?!! И, конечно же, вездесущие ожидания пользователей. Я как пользователь много чего ожидаю от программного обеспечения. Но, почему-то, мои ожидания никто не торопится реализовывать. Например, мне нужно 1) иметь протокол действий каждого приложения ОС (с возможностью отмены); 2) полное описание работы самого приложения (чтобы понять, как оно работает; не справка, а живая демонстрация возможностей без реальных последствий); 3) полный контроль над данными приложения (чтобы можно было самому решать, что, как и где должно хранится; а то память телефона/системный диск практически заполнены, а что там можно и как удалить, неизвестно). Никто никогда не сделает!
К моменту начала разработки часть требований уже устаревает.
Это ещё почему? Если есть определённый сервис, то у него есть и такие же определённые фиксированные требования, которые навсегда останутся с этим сервисом, и их все нужно реализовывать.
Часть задач оказалось связана с реальными сценариями использования продукта. Но значительная часть представляла собой дополнительные функции, которые могли быть полезны когда-нибудь, но не были необходимы для запуска.
Кто сказал, что дополнительные? Потом опять что-то изменится, и некоторые дополнительные станут основными. Сколько ещё месяцев придётся накинуть?
При этом продукт начал приносить бизнесу ценность гораздо раньше.
Без реального примера невозможно ничего обсуждать конкретно.
Такая формулировка заставляет команду думать о потребности пользователя, а не о функциях системы.
Кэшбек (он же возврат?) — это одна из функций системы. Либо она есть, и её надо реализовывать. Либо её нет, и тогда её не надо будет реализовывать. Всё просто.
Длинное техническое задание не гарантирует успех проекта. На практике большие документы часто приводят к избыточной функциональности, росту бюджета и увеличению сроков разработки.
Вопрос не в длине, а в качестве.
И ещё.
Это позволило сократить срок разработки до четырех месяцев. Если посчитать экономику проекта, результат становится еще более наглядным.
Более всего интересует, а чем заняты эти месяцы? Вот, кто-нибудь взял бы и расписал, как на деле происходит разработка. Почему такая-то операция потребовала такого-то времени? Можно было бы сделать быстрее? И что нужно было бы иметь, чтобы сделать быстрее?
Куда идут средства от экономии на разработке?
Как плохое ТЗ может удвоить стоимость проекта
Хорошее (идеальное) ТЗ может написать только разработчик и только после завершения разработки (и это будет первая часть ТУ на программу).
Как плохое ТЗ может удвоить стоимость проекта