Водопады

Несколько раз в своей практике мне приходилось сталкиваться со следующей ситуацией: существует заказчик с крупным проектом, который находится в стадии постоянного развития и изменения в течении нескольких лет.

Все работы обычно при этом ведутся одним генеральным подрядчиком, который передает их на субподряд более мелким компаниям (обычно в регионах, так как это дешевле) и получает свою маржу, либо же реализует изменения самостоятельно.

При этом подход часто в таких случаях выбирается следующий - заказчик передает бизнес-требования для относительно небольшой порции изменений имеющейся системы подрядчику на изучение и оценку (Change Request), потом согласовывает бюджет и запускает в разработку.

Т.е. используется небольшой водопадный процесс (waterfall) для реализации изменений.

 

На первый взгляд вроде бы все хорошо:

• заказчику понятен бюджет - это важно для крупных заказчиков, которые имеют сложную бюрократическую систему согласования бюджета
  
• заказчику понятно что именно он покупает за свои деньги, какую пользу от изменений он получит, как это повлияет на его бизнес - это также важно для согласования изменений внутри заказчика
  
• при желании заказчик может устроить тендер на реализацию изменений и выбрать подрядчика с минимальной ценой.

Однако, на практике, поскольку система крупная, то в ней обычно возникает постоянно большое количество изменений, которые отправляются в разное время на изучение, оценку и реализацию одному или нескольким подрядчикам.

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

Для заказчика это опять же выглядит хорошо по описанным выше причинам - он платит только за то, что заказал, всегда контролирует бюджет, ясно видит как изменяется его система и т.п.

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

Причин тому несколько:

• Пытаясь представить и согласовать наименьший бюджет (особенно в условиях тендера) заказчик часто вынужден предлагать сиюминутное решение, которые удовлетворит заказчика в рамках текущего запроса, но внесет некоторый (пусть и небольшой) дисбаланс во внутреннюю организацию системы
  
• Заказчик, даже если он и осведомлен о том, что с точки зрения архитектуры, решение предлагается не самое оптимальное, тоже идет на это, находят под давлением со стороны учредителей, которые не желают тратить лишний бюджет.
  
• Узкий горизонт планирования, сопутствующий реализации запросов, приводит к тому, что архитектурные решения могут приниматься даже и оптимальные с точки зрения текущего запроса, но не самые удачные с точки зрения стратегии развития системы в целом. Стратегия в данном случае теряется за большим количеством параллельных запросов на изменения.
  
• Параллельно работающие команды над слабосвязанными изменениями системы часто уводят развитие архитектуры системы в различные направления, разрабатывают частично-дублирующиеся подсистемы и т.п.

Все это с течением времени приводит к постепенной деградации внутреннего качества и постепенной деградации архитектуры, а в итоге и к увеличение стоимости ее поддержки и развития.

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

В конечном итоге это приводит к смерти продукта и запуску разработки нового.