Почему у некоторых компаний вместо портфолио — некролог

Анамнез

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

За 17 лет я поработал в проектах разных видов:

• сервисных — когда нужно обеспечивать работу людей, сервисов и систем в рамках SLA;
• интеграционных — когда проект уже есть и нужно точно выполнить работы по нему;
• разработки — порталы, программное обеспечение, платформы;
• полного цикла — когда твоя команда сначала проектирует систему, а затем сама же её внедряет;
• импортозамещения — их я выделяю в отдельный вид: сжатые сроки плюс решения, которые ещё не успели созреть.

Именно на проектах полного цикла компании чаще всего ломают себе шею.

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

Весь мой опыт — собственный. Не перенятый у старших и не подсмотренный в учебниках: такому там не учат.

Жалобы: «Где болит? — Везде»

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

Начиналось всё классически. У крупного клиента, энергетической компании, была боль. Если перевести её на язык медицины, разговор с врачом звучал бы так:

— Где болит? — Везде.

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

Получился монструозный проект в духе «а давайте пересоберём всё ИТ»:

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

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

Осмотр: два месяца тишины

Меня пригласили на собеседование, когда подходил к концу второй месяц.

На встрече выяснилась деталь. Спустя два месяца работы по договору кто-то наконец открыл ТЗ и дочитал до раздела с требованиями к документированию: состав сдаваемой документации и стандарты, по которым она должна быть написана. Для таких систем это комплекс ГОСТ 34 — например, ГОСТ Р 59795-2021 определяет, что именно должно быть в каждом документе.

За два месяца не было написано ни строчки.

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

Лечение: одна точка принятия решений

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

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

Мне пошли навстречу. Мы пожали руки и начали перестраивать подход.

Результат: проектная документация в полном объёме была сдана в срок и соответствовала ТЗ, нормативным требованиям и договору.

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

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

Патогенез: шхуна и авианосец

Почему опытная сервисная компания едва не похоронила проект на старте? Дело не в людях, а в расстоянии между ними.

В бизнесе, как в мореплавании, есть два разных типа управления.

Шхуна — небольшая гибкая компания. Капитан стоит на мостике и может отдать приказ голосом. Его слышат все, команда реагирует мгновенно, и шхуна меняет курс за секунды. Но тяжёлый контракт, как шторм, такой корабль может не выдержать.

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

Если доклад идёт по длинной цепочке, авианосец на полном ходу встречает айсберг.

Красная папка

Эту проблему отлично показывает фильм «Ford против Ferrari». Кэрролл Шелби приходит к Генри Форду II, который готов закрыть гоночную программу. На вопрос, почему бы не уволить всех причастных, Шелби отвечает примерно так:

«Я сидел в вашей приёмной и смотрел, как вот эта красная папка прошла через четыре пары рук, прежде чем попасть к вам. И это не считая двадцати двух сотрудников, которые наверняка держали её до того, как она поднялась на девятнадцатый этаж. При всём уважении, сэр, гонку не выиграть комитетом. Нужен один главный».

В материале MIT News эту сцену разбирают как пример «скрытой фабрики» — работы промежуточных звеньев, которая снижает качество и скорость, но не видна руководству (MIT News).

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

Сигнал проходит через них как через «испорченный телефон». Наверх доходит успокаивающее: «Всё под контролем, есть рабочие моменты». Руководство узнаёт о проблеме, когда проект уже не спасти.

Закон Конвея

У этого явления есть теоретическая основа. В 1968 году программист Мелвин Конвей сформулировал наблюдение: любая организация, которая проектирует систему, создаёт систему, повторяющую структуру её собственных коммуникаций (М. Конвей, «How Do Committees Invent?»). Фред Брукс в книге «Мифический человеко-месяц» назвал это законом Конвея, а Мартин Фаулер подробно разбирает его применительно к архитектуре программных систем (М. Фаулер, «Conway's Law»).

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

Эпикриз

Мой кейс с энергетической компанией закончился хорошо по одной причине: на входе я фактически повторил манёвр Шелби. Убрал лишние промежуточные звенья и согласования и взял управление проектом на себя.

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

Рабочая цепочка выглядит так: руководитель проекта → директор по производству или куратор → генеральный директор.

Как только между ними появляется прослойка из заместителей, начальников управлений, директоров департаментов и советников, компания начинает слепнуть:

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

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

Иначе будьте готовы регулярно пополнять своё «маленькое кладбище» новыми дорогими проектами.