Если вы поняли это, и никто другой этого не сделал, и вы хотите, чтобы проект был успешным, то вам нужно потратить несколько дополнительных часов и составить план, а затем продать его людям, которые номинально ответственен за принятие решения.
Реальные проекты имеют «перезапуски». Это не значит, что вы отбрасываете всю свою существующую работу. Это означает, что вы найдете новую оболочку, в которую поместятся фрагменты этой работы. Это намного проще, если ваша работа до сих пор состоит из хорошо понятых самосогласованных маленьких компонентов, слабо связанных друг с другом. Вот почему люди так работают - потому что по опыту знают, что им придется что-то переставлять. Почти все функции, добавленные в языки программирования в течение десятилетий, связаны с тем, что мы знаем, что каждый кусок кода, который мы пишем, может быть в нестабильном путешествии - он может выжить, но, вероятно, придется столкнуться с множеством незнакомых сред на путешествие, чтобы выпустить.
Итак, вы заметили, что соответствующая информация постоянно появляется на протяжении всего проекта. Не всегда все отображается в одном пакете прямо перед началом ввода кода. Написание документа спецификации не решает эту проблему вообще. Поэтому вам нужно изменить способ работы, чтобы проект постоянно получал новую информацию - новая появляющаяся информация извне - это та пища, которая движет вашим проектом вперед. Попробуйте с нетерпением ждать каждого нового удивительного откровения и приветствовать его как друга!
Что это значит? Это означает, что «архитектурные» части проекта не более стабильны, чем «мелкие детали». Вы должны быть в состоянии изменить архитектуру. У вас недостаточно информации в начале, чтобы принять окончательное решение о чем-либо.
Основная проблема может заключаться в том, что у вас изначально есть восьмимесячный проект. Реальные восьмимесячные проекты (которые успевают вовремя) на самом деле, если присмотреться, представляют собой множество более коротких проектов: 16 двухнедельных проектов - идеальный вариант.
Вы должны поместить все цели проекта (пока что) в большой список в приоритетном порядке. Напишите каждое требование к функции с точки зрения пользователя. «Пользователь должен иметь возможность бла-бла-бла», такого рода вещи. Избегайте разговоров о технических проблемах текущего дизайна. Подумайте о том, как пользователь будет иметь дело с отсутствием какого-либо продукта (или того, чем он в настоящее время пользуется), и расскажите, как его опыт может быть улучшен с помощью определенной функции.
Важным является порядок приоритетов. Цель состоит в том, чтобы сказать: у нас есть время отгружать только первые 10 готовых изделий. Это лучше, чем 9 предметов, что, в свою очередь, лучше, чем 8, и так далее. Но даже с 8 предметами это было бы лучше, чем ничего, потому что каждый элемент - это функция, которая сама по себе могла бы улучшить пользовательский опыт.
Список называется отставанием.
Если вы сравните свою работу до сих пор с отставанием, вы, как правило, обнаружите, что работали над вещами с низким приоритетом, потому что думаете, что вам это понадобится позже. Постарайтесь не делать этого с этого момента. Материал с низким приоритетом ... низкий приоритет. Что, если между новым временем и датой отправки появятся новые запросы с более высоким приоритетом? Они почти наверняка будут! Несмотря на то, что некоторые люди будут требовать («Это будет абсолютно бесполезно без функции A!»), Вы, вероятно, могли бы поставлять без функции A и функции B. Но если бы вам пришлось выбрать одну, вы бы выбрали функцию A. И вы вполне возможно, придется грузить без функции B, из-за нехватки времени. Так что не подвергайте опасности А ради того, чтобы быть «готовым» для добавления Б. позже. Готовьтесь заранее только в том случае, если это будет стоить вам почти ничего - оставляйте места, где вы можете добавлять вещи, делать все расширяемым, но не тогда, когда это замедляет вас прямо сейчас.
Затем начните работать над новой версией продукта (каннибализируя проделанную работу там, где это имеет смысл), которая позаботится о первых нескольких элементах в списке - минимум. Потратьте на это не больше недели. Неделя составляет 6,25% от вашего оставшегося времени, так что это довольно дорого. Но в конце этого у вас есть изображение того, что вы готовы отправить до сих пор. Это единственный способ измерить ваш прогресс с сегодняшнего дня.
Остальная часть вашего проекта состоит из:
Неоднократно выпускали новые рабочие версии продукта, каждый раз добавляя еще несколько функций из списка приоритетов. Получите небольшое сообщество пользователей для работы с каждой версией и дайте прямой отзыв вашей команде. Стремитесь делать новую версию каждые пару недель.
Превращение отзывов пользователей в новые "истории", которые можно отправлять "в отставание". Это, конечно, включает в себя их приоритетность.
Вы делаете это снова и снова, за короткие итерации, пока не закончится время (у вас, вероятно, есть время сделать шесть-восемь итераций). В конце каждой итерации у вас есть что-то «лучшее» (имеет более высокоприоритетные функции, включает в себя больше обратной связи), чем то, что вы имели в конце предыдущей итерации. Это прогресс.
Каждый выпуск в конце итерации имеет две цели: показать прогресс и, конечно, сделать сообщество пользователей немного счастливее, но также получить больше отзывов, чтобы найти новую информацию. Каждая версия - это и решение, и зонд. Эта двойственная природа сохраняется после первого публичного выпуска. Публичный релиз - это зонд в глубоком космосе, который вы отправляете в солнечную систему для отправки изображений странных новых миров (в виде следов стека исключений).
Все это научно и рационально. Вы принимаете решения о порядке работы исходя из очередности. Вы получаете постоянную обратную связь, основываясь на рабочей версии вашего продукта, вместо того, чтобы угадывать обратную связь, которую вы получите от воображаемой версии вашего продукта.
Люди ответят на этот подход, сказав, что он будет ужасно "неэффективным". Эффективность - это относительный термин. Проекты, которые не работают таким образом, в конечном итоге всегда работают таким образом. Но «в конце» очень поздно. Обычно существует безумная паника в течение дополнительных N месяцев после первоначального крайнего срока, когда проект продолжает выпускать повторяющиеся версии продукта, которые «почти правильные» или «почти готовые», в сумасшедшей самообманчивой пародии итеративной разработки. 1041 *
К счастью, вы можете начать думать и работать таким образом в любое время. Лучше начинать на полпути к первоначальному сроку, чем вскоре после него.