Написание таких проектов можно назвать обманом заказчика и даже самообманом. Осознанным или неосознанным, но обманом. Вы наверняка видели в своём городе дома, на которые вместо ремонта распечатывают баннер (рис. 34).
Рис. 34. Дом не отремонтирован, а закрыт распечаткой красивого фасада
Наступает момент, когда распечатку убирают и оказывается, что внутри развалившийся фасад. То же самое происходит и с проектами. Заказчик узнаёт реальную ситуацию, когда приходит к внешнему консультанту, приносит проект, просит разобраться в чём дело. Он говорит: «Мы же полгода делали, всё было так быстро, мы уже были готовы к релизу, и тут раз – ничего не работает». Конечно, не работает; собственно, это и не работало никогда. Увы, оно только делало вид.
Реальные случаи таких «фасадов»:
1. Проект работает, когда им пользуются одновременно не более 10 человек. На демо всё было отлично, но вот в реальности сервер падал под «нагрузкой». Есть практика нагрузочного тестирования, но кто этим занимался?
2. Программа запускается только на одной операционной системе, грузит её на 100% и обычно падает с BSOD. Заказчика убедили, что иначе никак. При реальной работе этой системой невозможно пользоваться.
3. «Всё готово, – говорит заказчик, – надо только добавить редактирование ленты новостей и управлять фильтрацией новостей. На главной странице их всего пять, надо добавить несколько свежих». Заглядываем в код, а там все новости в статичных HTML-файлах без бизнес-логики, как и контроль их фильтрации. Новости только «нарисовали», но не реализовали.
4. Система голосового распознавания неправильно отвечает на звонки пользователей после запуска. Разработчики убеждают заказчика, что её надо дообучить на реальных пользователях, то есть запустить систему, которая будет ошибаться и учиться на звонках. Пользователи при этом в гневе, они не получают результат, зато система обучается, а заказчик уверен, что иначе никак нельзя.
5. Проект для B2B сектора был уже запущен и отлично работал. У руководства на него были большие планы, но первое же изменение заставило переписать очень много. Дело в том, что в нём было очень-очень-очень много дублирования в коде (раздел II, глава 6). Одно бизнес-правило могло быть записано в пяти-шести частях системы. Быстрый рост сменился стагнацией и привёл к закрытию проекта.
Надо признать, что разработчики научились имитировать бурную деятельность вместо реальной результативной работы. Эффективные менеджеры научились убеждать заказчиков, что текущая ситуация на проекте – это норма, что IT-рынок может работать только так и никак иначе.
Такие проекты – самообман разработчиков. Они уверены, что лучше сделать невозможно. Создатели «фасадных» проектов говорят заказчику: «Мы построили масштабируемую систему, она может хорошо расширяться под любой нагрузкой». Надо понимать, что ни одни действительно опытный разработчик так не скажет. Он сделает множество оговорок про реальную масштабируемость, загонит её в рамки ограничений и опишет возможные риски.
Заявления о надёжности в 146% характерны для программистов, которые находятся в квадрате неосознанной некомпетентности (рис. 35).
Рис. 35. Матрица Осознанность – Компетентность
Не смотрите на количество отработанных лет на должности программиста (кто-то считает это показателем опыта), от них ничего не зависит. Плохо, когда такие «ведущие» программисты имеют дар убеждения заказчика или являются техлидами с его стороны, потому что заказчик остаётся совсем один в этой неравной битве за истину. В таких ситуациях нужно звать внешних консультантов, которым доверяют. Обращайте внимание на реализованные проекты, на роль этих людей в проектах, давайте им небольшие тестовые приложения, которые надо сделать от начала и до конца. При этом обязательно приглашайте консультантов, которые смогут оценить качество. Я сам частенько выполняю эту задачу, например, меня зовут устраивать публичные слушания[46] по проекту.