Правило 17. Архитектура в идеальный шторм

Как писал в своей книге «Введение в транзактный анализ» Эрик Берн, человеку всегда приходится противостоять трем силам:

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

Но в жизнь каждого инженера (а IT-шники — это инженеры) однажды приходит «идеальный шторм». Неблагоприятные факторы не просто случаются все и сразу, а ещё и усиливают друг друга, в результате относительно просто решаемые по отдельности проблемы складываются в клубок непреодолимых противоречий.

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

Планировать в эти периоды сдачу проектов или ключевые вехи — крайне сомнительная затея, которая существенно повышает шансы на провал. Но сам по себе один этот фактор ещё может быть учтён в плане и компенсирован различными мероприятиями.

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

И вот у вас есть проект, который нужно сдавать в середине лета, у вас есть полгода, и кажется, что есть все шансы уложиться.

Руководитель проекта составляет календарный план, который местами уже не выполнен, а некоторые задачи, которые нужно было выполнить «вчера», даже не были начаты.

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

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

Рефакторинг пытаются в срочном порядке вернуть в план проекта, но весь он туда не помещается. Начинается попытка выдернуть отдельные задачи рефакторинга и реализовать их параллельно работам над новым проектом, из-за чего в плане возникает бардак, а ресурсов начинает остро не хватать.

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

Приближается период отпусков, и команда начинает уходить в отпуск. А вместе с этим некоторые члены команды решают уволиться. Запланированные работы распределяются по меньшему количеству людей.

Остаётся 5 недель, и вот уже весь проект оказываются на критическом пути. И в этот самый момент бизнес выкатывает запоздалые макеты, которые сильно отличаются от ранее обговоренной реализации. Новые бизнес-требования не учтены в плане, но именно они «бизнес-критичны». Начинается борьба за скоуп, требующая от и так перегруженной команды реализации обоснований, почему этого сделать нельзя, и поиска ответов, почему это не было учтено.

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

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

Проект накрывает идеальный шторм. Так происходит в моём проекте в тот самый момент, когда я пишу этот пост.

Идеальный шторм — это жёсткая проверка на прочность вашей архитектуры. К нему нельзя быть полностью готовым: если вы всё учли, значит, это не идеальный шторм.

Но архитектор не имеет права полагаться на волю случая и проектировать архитектуру только «солнечного дня» (противоположность идеального шторма, когда всё идёт по плану и даже лучше).

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

Архитектор — не специалист по рискам, потому расчёт проектных рисков — не его область деятельности, но всё же стоит прикинуть наиболее существенные риски и продумать возможные меры противодействия.

Архитектуру нужно защищать, будьте уверены: когда проект начнёт разваливаться, «охотники на ведьм» в первую очередь постараются обвинить команду проектирования в недальновидности.

К обороне стоит готовиться заранее:

Всё, описанное выше, — не гарантия выжить в шторме, но без такой «архитектурной гигиены» шансы погибнуть в шторме куда выше.