Проблемы с проектами появляются в разного размера компаниях, на разных платформах разработки и в разных странах. История одинаково повторяется в России, США и Англии. Повторяется почти в деталях. Анализируя историю таких проектов, я заметил тенденцию и выделил её суть.
Когда проект только начинается, работа над ним кипит, заказчик очень быстро получает много новых функций. Надо добавить регистрацию – пожалуйста. Ленту новостей – пожалуйста. Разделение на роли – без проблем. Прохождение документов по основной ветке бизнес-процесса – очень быстро.
Компоненты системы почти не связаны друг с другом (рис. 32). Система растёт высокими темпами, скорость роста стабильна. При этом сложность увеличивается линейно, то есть пропорционально количеству добавленных компонентов.
Рис. 32. Компоненты системы не связаны друг с другом
Первый этап – самый простой для разработчиков. Для него не требуются сильные инженерные навыки.
На этом этапе заказчик счастлив. Он видит, что задачи реализуются быстро, возможно даже быстрее плана, новые функции льются рекой.
Этот этап счастливого неведения может длиться довольно долго. История знает случаи, когда команды работают в режиме «только добавление» по полгода.
Начались изменения в первоначальных требованиях. Например, поменялся бизнес, или пришли конкуренты, или заказчик увидел новые пути развития. И оказалось, что система не готова к изменениям. Добавлять новое – не то же самое, что изменять уже созданное. Кроме того, одна часть системы могла быть сделана недостаточно гибко, а в другой код мог быть хрупкий, поэтому при изменении ломается то, что раньше работало. Теперь заказчику приходится ждать значительное время, когда разработчики внесут изменения.
Меняется логика регистрации, добавлены регистрации через соцсети, через внутренние сервисы компании, через промоакции со сторонних сайтов партнёров и так далее до бесконечности (рис. 33).
Рис. 33. Сильная взаимосвязь компонентов системы
При изменении компонентов система ломается в неожиданных местах (раздел II, глава 6), появляются сложные связи между разными частями системы. Заливка новых версий становится всё сложнее, и ещё хорошо, если кто-то позаботился об автоматической интеграции[44] и разворачивании новых версий. Обнаруживается дублирование в коде и ошибки во внутреннем дизайне, но времени на исправление особо нет, заказчик и так переходит в категорию недовольных.
Заказчик, который просит «всего лишь добавить кнопку», не понимает, почему это занимает две недели. Раньше за две недели он получал несколько новых функций, а теперь небольшие изменения требуют значительных затрат. После релизов выявляются проблемы в уже отлаженных частях системы, то есть в уже оплаченных частях системы.
Заказчик недоволен, он требует былых скоростей. Он требует, чтобы как минимум вернулось то, что уже было в рабочем состоянии.
Дальше два варианта развития событий:
1. Команда осознаёт, что она некомпетентна развивать проект. Она тихо «сливается» и идёт за следующим проектом. Заказчик остаётся с кучей плохого кода и горящими сроками.
2. Команда не осознаёт своей некомпетентности[45]. Тогда паутина кода вьётся до момента, пока кто-то не скажет заветную фразу: «Проще всё выкинуть и переписать заново». Что это значит для заказчика? В лучшем случае, потеря денег и времени, в худшем – потеря бизнеса.