Это совсем не то, что вы себе представляли. Хотя это, возможно, и соответствует тому, что вы рассказали дизайнеру, но это не то, что вам нужно. Обивка слишком светлая и абсолютно не нравится вашей новой подружке. Вдобавок выяснилось, что у вашего пса — аллергия на пух в подушках. Стол слишком высокий, а кресла — слишком громоздкие. Но это уже все согласовано с фирмой-изготовителем и у них есть ваша подпись. Поменять ничего нельзя, вернее — можно, но это будет стоить столько же денег и займет еще столько же времени. О гарантии результата можно вообще не говорить.
Управление разработкой ПО — это почти как руководство мебельной фабрикой
Кстати, вы знаете, почему пришлось столько ждать? Вам, возможно, будет приятна мысль, что мастер неделями трудился над каждой доской вашего гарнитура, или вышивальщица днями делала стежок за стежком, чтобы успеть вовремя сделать качественную вышивку. Что всё это ежечасно сверялось с дизайном, а менеджер по качеству неусыпно следил за производством.
Однако на деле большую часть времени ваша мебель лежала в полусобранном состоянии и дожидалась своей очереди. Лежала в виде спиленных деревьев где-то на пилораме.
Потом — в цехе, то у одного станка, то у другого. Потом — на многочисленных складах. Потом — в транспортном вагоне. А вы все это время были вынуждены использовать неудобный хлам.
Скажите, вы действительно думаете, что на сборку ваших шкафов у профессионалов ушел целый месяц? А теперь представьте, что вы решили заказать себе новый крутой сайт, вместо старого и неудобного… ну, вы поняли.
ОК, это плохо. Но как этого можно было избежать?
Во-первых, вы могли заказать поэтапную разработку мебели, разработка которой должна вестись по чётко поставленным вами приоритетам. Допустим, больше всего вам нужен диван, потому, что старый уже совсем того, а кресла и стол могут еще немного потерпеть. Соответственно, диван будет первым в списке приоритетов, а студия обязуется изготовить и доставить его в первую очередь.
Что это дает? Во-первых, вы удовлетворяете свою самую важную потребность в первую очередь, и пружины уже не скрипят по ночам. А, во-вторых, если вашей новой подружке сразу не понравился цвет обивки и вы решительно захотите ее поменять (обивку, не подружку) — ваши затраты будут только на диван, без необходимости менять обивку на креслах (т. к. те еще не готовы). Или вообще, вы можете абсолютно без затрат изменить состав заказа, убрав из него кресла, и добавив пуфики.
Во-вторых, вы могли попросить студию ежедневно рассказывать вам о ходе работы. Всего три простых вопроса: что было сделано за вчера, какие планы на сегодня, какие есть проблемы — и вы получаете полный контроль над ситуацией. И это хорошо!
SCRUM помог бы вам в ситуации, когда…
• Куча денег и времени ушла на проработку ТЗ, но по ходу работы над проектом поменялась концепция или бизнес-процессы. Доводить проект до конца в том виде, как описано в ТЗ — нет смысла. Деньги на ТЗ выброшены напрасно.
• Разработчик отказывается вносить изменения по ходу работы, ссылаясь на ТЗ. Разработчик показывает проект в последний день перед запуском. Однако все сделано не так, как вы себе это представляли. Нужна значительная переделка. Разработчик по-своему трактует описанные в ТЗ требования и отказывается вносить изменения в проект на этом основании.
• Нужно запустить костяк интернет-проекта с минимально-возможным бюджетом и сроками. Дополнительные функции разрабатывать уже после запуска, когда проект начнёт отбивать начальные инвестиции.