Многие проекты в АйТи часто бывают охвачены пожаром. Большой объём работ, короткие сроки вынуждают на чём-то экономить. И эту самую экономию в первую очередь обеспечивают за счёт снижения качества и его контроля.
Поскольку пожар проектный и не думает угасать, разработчики быстро привыкают к такому положению вещей и забывают про то, как вообще можно работать качественно. Даже когда их никто не торопит.
Что интересно - такое положение вещей достаточно выгодно. Сплочённые «пожарники» продолжают получать за свою отвагу «плюшки» и премии. При этом никто даже и не смотрит, что они сами же создают многочисленные баги, работая по классической схеме «правим одно, ломаем другое».
А раз появляются новые баги, значит, продолжает «ехать» план работ, и команда может ещё подзаработать на сверхурочных выходных днях. И чем критичнее баги, тем наиболее вероятнее это произойдёт.
Исчерпание бюджета не меняет ситуацию. Потому что «уже поздно, всё нужно переписывать, требуется дорогой рефакторинг, ничего уже быстро не переделать».
Если срок жизни проекта небольшой и делается он с демонстрационной целью, к какому-то мероприятию, то это вполне нормально. Правда, и будет это являться не проектом, а скорее прототипом.
Если целью ставится разработка долгосрочного продукта, который нужно будет постоянно дорабатывать и сопровождать, то вся экономия в итоге не только сходит на нет, но и проводит к крупным убыткам.
После этого начинают всерьёз задумываться о ревью кода. Но на этом этапе неожиданно вскрывается много новых проблем - как технических, так и социальных. Об этих аспектах я расскажу в следующей статье.
Читайте продолжение истории "Почему Code Review никому не нужно? Часть II".
