Всегда ли чем быстрее тем лучше?

В данном тексте мы поговорим о том: всегда ли быстрее сданный проект лучше чем проект сданный в изначально оговоренный срок.

Во первых, спешка в урезании сроков проекта часто означает постоянное изменение сроков выпуска проекта. Люди ненавидят постоянное изменение сроков, так что, ни менеджемент ни тем более участники проекта не будут благодарны вам. Природа человечества требует стабильности и предсказуемого будущего. В противном лусчае вы рискуете оказаться в ситуации когда никто уже не помнит каков же был последний срок сдачи проекта!?

Кроме того, решение, что проект может быть закончен быстрее на более или менее раннем этапе означает, что у вас больше нет этого времени для дальнейшего улучшения проекта, особенно если новые сроки были оглашены для директоров. Хотя данное описание кажется элементраным и естественным: «решили, что надо меньше времени» – «меньше времени имеем» оно не столь очевидно для многих из-за простоты урезания сроков. Многим кажется, что убавить сроки разработки и увеличить – всё это одинаково легко. Как правило убавить легко, так как с радостью воспринимается менаджементом, а вот прибавить воспринимается с недовольством, так что «что с возу упало, то пропало».

Типичным явлением после уменьшение сроков является:
1. Попытка менаджемента добавить функциональность по требованиям клиентов на достаточно позднем этапе
2. Обнаружение серьёзных неточётов – мой опыт показывает, что вероятность возникновение данной проблемы 200%, т.е. мало того, что они возникнут гарантировано, так ещё и не одна. Проблемами могут быть логические несогласованности функциональностей либо технической инфраструктуры, проблемы с производительностью итд.

Более того, самым опасным здесь является тот факт, что в результате разнообразные надстройки/подпорки в коде будут использованы чтобы решить проблему. Как правило такие решение принимаются с лёгкостью ибо все убеждены – исправим в следующей версии. Реальность такова, что в следующей версии будут более высокоприоритетные задачи – «ибо тут и так рабатоет, да и дополнительное тестирование понадобиться – так что давайте оставим». Особенно если никто из клиентов не жалуется на данный участок функциональности. В результате производства всех этих подпорок, вы получите код который будет очень и очень сложно продолжать и будете строить «workaround» (обходной код) вокруг существующего обходного кода и так до бесконечности, пока разрабочики не плюнут и не уйдут в другую фирму (чтобы там столкнуться с таким же кодом :) ). Поэтому ни в коем случае не полагайтесь на «потом исправим» - постарайтесь сделать нормально сразу, а чтобы было достаточно времени, подумайте трижды урезая свои ресурсы.

И естественно учитывайте, что чем больше вы работаете над функциональностью, чем лучше вы видите возможности сделать всё «идеально», и соответственно оставьте себе время на переработку кода под конец проекта.

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

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

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