Читать книгу - "Антихрупкость в IT - Александр Васильевич Бындю"

волшебным образом уложить оборотней наповал.

Хорошо знакомый программный проект напоминает таких оборотней (по крайней мере, в представлении менеджеров, не являющихся техническими специалистами) тем, что, будучи простым и невинным на вид, он может стать чудищем проваленных графиков работы, раздувшихся бюджетов и неработающих продуктов. «Мифический человеко-месяц». Ф. Брукс.

Хочу поделиться обобщением историй от заказчиков IT-проектов, с которыми мне удалось пообщаться и поработать. Эти истории очень похожи, а значит, на их примере можно научиться, сделав нужные выводы.

Мне часто попадаются проекты со сложной историей: прошёл первый дедлайн, прошёл второй, релиза нет, инвесторы в отчаянии, готовы выкинуть проект и признать провал. Что объединяет эти истории?

История провальных проектов

Проблемы с проектами появляются в разного размера компаниях, на разных платформах разработки и в разных странах. История одинаково повторяется в России, США и Англии. Повторяется почти в деталях. Анализируя историю таких проектов, я заметил тенденцию и выделил её суть.

Сцена первая – обнадёживающая

Когда проект только начинается, работа над ним кипит, заказчик очень быстро получает много новых функций. Надо добавить регистрацию – пожалуйста. Ленту новостей – пожалуйста. Разделение на роли – без проблем. Прохождение документов по основной ветке бизнес-процесса – очень быстро.

Компоненты системы почти не связаны друг с другом (рис. 32). Система растёт высокими темпами, скорость роста стабильна. При этом сложность увеличивается линейно, то есть пропорционально количеству добавленных компонентов.

Рис. 32. Компоненты системы не связаны друг с другом

Первый этап – самый простой для разработчиков. Для него не требуются сильные инженерные навыки.

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

Этот этап счастливого неведения может длиться довольно долго. История знает случаи, когда команды работают в режиме «только добавление» по полгода.

Сцена вторая – разочаровывающая

Начались изменения в первоначальных требованиях. Например, поменялся бизнес, или пришли конкуренты, или заказчик увидел новые пути развития. И оказалось, что система не готова к изменениям. Добавлять новое – не то же самое, что изменять уже созданное. Кроме того, одна часть системы могла быть сделана недостаточно гибко, а в другой код мог быть хрупкий, поэтому при изменении ломается то, что раньше работало. Теперь заказчику приходится ждать значительное время, когда разработчики внесут изменения.

Меняется логика регистрации, добавлены регистрации через соцсети, через внутренние сервисы компании, через промоакции со сторонних сайтов партнёров и так далее до бесконечности (рис. 33).

Рис. 33. Сильная взаимосвязь компонентов системы

При изменении компонентов система ломается в неожиданных местах (раздел II, глава 6), появляются сложные связи между разными частями системы. Заливка новых версий становится всё сложнее, и ещё хорошо, если кто-то позаботился об автоматической интеграции[44] и разворачивании новых версий. Обнаруживается дублирование в коде и ошибки во внутреннем дизайне, но времени на исправление особо нет, заказчик и так переходит в категорию недовольных.

Заказчик, который просит «всего лишь добавить кнопку», не понимает, почему это занимает две недели. Раньше за две недели он получал несколько новых функций, а теперь небольшие изменения требуют значительных затрат. После релизов выявляются проблемы в уже отлаженных частях системы, то есть в уже оплаченных частях системы.

Сцена третья – провальная

Заказчик недоволен, он требует былых скоростей. Он требует, чтобы как минимум вернулось то, что уже было в рабочем состоянии.

Дальше два варианта развития событий:

1. Команда осознаёт, что она некомпетентна развивать проект. Она тихо «сливается» и идёт за следующим проектом. Заказчик остаётся с кучей плохого кода и горящими сроками.

2. Команда не осознаёт своей некомпетентности[45]. Тогда паутина кода вьётся до момента, пока кто-то не скажет заветную фразу: «Проще всё выкинуть и переписать заново». Что это значит для заказчика? В лучшем случае, потеря денег и времени, в худшем – потеря бизнеса.

Рисуем красивые фасады

Написание таких проектов можно назвать обманом заказчика и даже самообманом. Осознанным или неосознанным, но обманом. Вы наверняка видели в своём городе дома, на которые вместо ремонта распечатывают баннер (рис. 34).

Рис. 34. Дом не отремонтирован, а закрыт распечаткой красивого фасада

Наступает момент, когда распечатку убирают и оказывается, что внутри развалившийся фасад. То же самое происходит и с проектами. Заказчик узнаёт реальную ситуацию, когда приходит к внешнему консультанту, приносит проект, просит разобраться в чём дело. Он говорит: «Мы же полгода делали, всё было так быстро, мы уже были готовы к релизу, и тут раз – ничего не работает». Конечно, не работает; собственно, это и не работало никогда. Увы, оно только делало вид.

Реальные случаи таких «фасадов»:

1. Проект работает, когда им пользуются одновременно не более 10 человек. На демо всё было отлично, но вот в реальности сервер падал под «нагрузкой». Есть практика нагрузочного тестирования, но кто этим занимался?

2. Программа запускается только на одной операционной системе, грузит её на 100% и обычно падает с BSOD. Заказчика убедили, что иначе никак. При реальной работе этой системой невозможно пользоваться.

3. «Всё готово, – говорит заказчик, – надо только добавить редактирование ленты новостей и управлять фильтрацией новостей. На главной странице их всего пять, надо добавить несколько свежих». Заглядываем в код, а там все новости в статичных HTML-файлах без бизнес-логики, как и контроль их фильтрации. Новости только «нарисовали», но не реализовали.

4. Система голосового распознавания неправильно отвечает на звонки пользователей после запуска. Разработчики убеждают заказчика, что её надо дообучить на реальных пользователях, то есть запустить систему, которая будет ошибаться и учиться на звонках. Пользователи при этом в гневе, они не получают результат, зато система обучается, а заказчик уверен, что иначе никак нельзя.

5. Проект для B2B сектора был уже запущен и отлично работал. У руководства на него были большие планы, но первое же изменение заставило переписать очень много. Дело в том, что в нём было очень-очень-очень много дублирования в коде (раздел II, глава 6). Одно бизнес-правило могло быть записано в пяти-шести частях системы. Быстрый рост сменился стагнацией и привёл к закрытию проекта.

Надо признать, что разработчики научились имитировать бурную деятельность вместо реальной результативной работы. Эффективные менеджеры научились убеждать заказчиков, что текущая ситуация на проекте – это норма, что IT-рынок может работать только так и