Несколько раз в своей практике мне приходилось сталкиваться со следующей ситуацией: существует заказчик с крупным проектом, который находится в стадии постоянного развития и изменения в течении нескольких лет.
Все работы обычно при этом ведутся одним генеральным подрядчиком, который передает их на субподряд более мелким компаниям (обычно в регионах, так как это дешевле) и получает свою маржу, либо же реализует изменения самостоятельно.
При этом подход часто в таких случаях выбирается следующий - заказчик передает бизнес-требования для относительно небольшой порции изменений имеющейся системы подрядчику на изучение и оценку (Change Request), потом согласовывает бюджет и запускает в разработку.
Т.е. используется небольшой водопадный процесс (waterfall) для реализации изменений.
На первый взгляд вроде бы все хорошо:
- заказчику понятен бюджет - это важно для крупных заказчиков, которые имеют сложную бюрократическую систему согласования бюджета
- заказчику понятно что именно он покупает за свои деньги, какую пользу от изменений он получит, как это повлияет на его бизнес - это также важно для согласования изменений внутри заказчика
- при желании заказчик может устроить тендер на реализацию изменений и выбрать подрядчика с минимальной ценой.
Однако, на практике, поскольку система крупная, то в ней обычно возникает постоянно большое количество изменений, которые отправляются в разное время на изучение, оценку и реализацию одному или нескольким подрядчикам.
В результате это приводит к тому, что в рамках работы над системой возникает
много параллельных мелких водопадных процессов.
Для заказчика это опять же выглядит хорошо по описанным выше причинам - он платит только за то, что заказал, всегда контролирует бюджет, ясно видит как изменяется его система и т.п.
Однако, такая организация работы приводит к тому, что заказчик и подрядчик ориентируются на краткосрочные цели в ущерб долгосрочным целям и в конечном счете в ущерб внутреннему качеству продукта.
Причин тому несколько:
- Пытаясь представить и согласовать наименьший бюджет (особенно в условиях тендера) заказчик часто вынужден предлагать сиюминутное решение, которые удовлетворит заказчика в рамках текущего запроса, но внесет некоторый (пусть и небольшой) дисбаланс во внутреннюю организацию системы
- Заказчик, даже если он и осведомлен о том, что с точки зрения архитектуры, решение предлагается не самое оптимальное, тоже идет на это, находят под давлением со стороны учредителей, которые не желают тратить лишний бюджет.
- Узкий горизонт планирования, сопутствующий реализации запросов, приводит к тому, что архитектурные решения могут приниматься даже и оптимальные с точки зрения текущего запроса, но не самые удачные с точки зрения стратегии развития системы в целом. Стратегия в данном случае теряется за большим количеством параллельных запросов на изменения.
- Параллельно работающие команды над слабосвязанными изменениями системы часто уводят развитие архитектуры системы в различные направления, разрабатывают частично-дублирующиеся подсистемы и т.п.
Все это с течением времени приводит к постепенной
деградации внутреннего качества и постепенной
деградации архитектуры, а в итоге и к увеличение стоимости ее поддержки и развития.
Попытки выполнить
рефакторинг часто
обречены на провал, так как выгода рефакторинга не очевидна для акционеров либо учредителей заказчика, доступ подрядчика к ним часто затруднен, а ориентированы они на покупку конкретных изменений в их системе.
В конечном итоге это приводит к смерти продукта и запуску разработки нового.
