Когда начинается ИТ-проект, все его участники — и менеджеры, и разработчики — хотят чувствовать, что они движутся вперед. Они стремятся продемонстрировать это и своему руководству. Поэтому совершенно естественно человеческое желание вначале сфокусироваться на самых простых проблемах, которые можно легко разрешить и проверить.

Такой задачей можно назвать, например, создание интерфейса для пользователей (ГИП) — если он требуется, конечно. Инструменты и библиотеки для разработки ГИП за последние годы стали весьма сложными и мощными. Вполне возможно организовать такой интерфейс и сделать его наглядным и действующим еще до того, как у приложения появится какая-то функциональность.

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

Еще одна распространенная тенденция в крупных ИТ-проектах состоит в том, чтобы сделать 80% работы в какой-то из подсистем и, дойдя до сложных моментов в ней, переключиться на другой модуль или подсистему, где вы опять можете быстро продвигаться. Это также дает ощущение серьезного прогресса и позволяет вам рапортовать руководству, как хорошо идут дела.

Но так поступать нельзя. Вы действительно выполнили определенную работу. ГИП готов и может быть оценен случайными пользователям, ваши модули и подсистемы тоже готовы процентов на 80. Вы вроде бы строго придерживаетесь графика или даже опережаете его. То есть на первый взгляд всё выглядит прекрасно. Но именно здесь и начинаются затруднения.

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

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

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

Все происходит примерно так. Предположим, у вас в подсистеме А есть сложная проблема Х, которую надо решить, но в подсистеме В есть сложная проблема Y, которую тоже надо решить. После “мозгового штурма” и блестящей работы вы решаете обе проблемы. Однако появляется новая: полученные решения несовместимы друг с другом. Другими словами, решение проблемы X мешает решению проблемы Y и наоборот. Это может звучать, как нечто невероятное, но так происходит во многих случаях, особенно когда проблема X — это проблема функциональности, требующая обработки больших объемов информации, а Y — проблема производительности, требующая гораздо более быстрого отклика или более высокой производительности, чем система может предоставить.

А теперь представьте, что перед вами стоит десяток самых разных “тяжелых проблем” с любым числом взаимозависимостей и исключений. И тогда вы начинаете понимать, почему так много ИТ-проектов доходят до 80–90%-ной стадии готовности, а затем как бы замирают на месте на целые месяцы.

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

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

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

Просто помните об этом примере.