Не всегда провалы проектов связаны с плохим планированием, недостаточными компетенциями или ошибками в разработке. Иногда из-за «теория, рассматривающая труднопрогнозируемые и редкие события, которые имеют значительные последствия; получившее своё название по одноимённой книге Нассима Талеба. </p>" data-abbr="черных лебедей">черных лебедей» проект начинает жить настолько бредовым и непредсказуемым образом, что ты ощущаешь себя героем трагикомедии.
Для кого: для начинающих проектных менеджеров, которым требуется заряд мотивации и сочувствия; для тех, кто любит читать производственные романы; для разработчиков, которые не понимают, что за фигня иногда творится на их проектах.
Давайте смотреть реально. Комедия — мёртвый жанр, а трагедия — это смешно!
Футурама, «20th Century Fox», Мэтт Грейнинг, Дэвид Коэн
Акт 1: Разборки в стиле кунг-фу
Пролог: Крупная коммерческая компания с российскими и международными заказчиками. Новое руководство хочет навести порядок в делах и автоматизировать процессы по-правильному.
В течение полугода проводится цикл из 30 встреч с ведущими участниками рынка, где функциональные заказчики, безопасники и ИТ-службы оценивают компетенции, опыт и качество продуктов. Готовятся демо-стенды, проводится тестовая эксплуатация по каждому продукту по несколько дней. Далее следует презентация топ-менеджерам и собственникам. К этому моменту, как вы понимаете, трудозатраты каждого участника пресейла уже достигают нескольких человеко-месяцев.
На основе встреч и рабочих обсуждений создается Техническое задание (ТЗ) для конкурса на площадке компании, которое могут выполнить 6 участников рынка и их франчайзи. Первый контракт не самый большой, но все дело в дальнейшем развитии системы. Ожидается нешуточная заруба на конкурсе. И она случается!
Происходит чудо и в совокупности по десятку параметров моя конкурсная заявка выигрывает. Подробно разбираются сметы, фиксируется почасовая ставка на развитие и техническую поддержку на несколько лет вперед. Далее следует настойчивое требование со стороны заказчика начать работы до заключения контракта. Мол, конкурс все равно выигран, контракт обязательно будет подписан, обычная практика в отрасли, нужно успеть завершить работы пораньше и развесить всем медальки. Я по своей обычной практике настойчиво сливаюсь.
Драма: Согласование контракта идет планово, минорные замечания оперативно устраняются, мы близимся к подписанию. Проектная команда сформирована и забронирована, мои аналитики, инженеры и разработчики бьют копытом и рвутся в бой. Дальше события не развиваются стремительно:
Вторник, контракт подписан с нашей стороны. Я везу его заказчику, заказчик принимает контракт в секретариат для проверки.
Среда. Контракт проверен и завизирован, с ним все хорошо. Меня хочет видеть куратор, член Совета директоров. Он сообщает, что подписание с их стороны состоится завтра утром. Примерно в 5 вечера мы пожимаем руки и уверяем друг друга, что проект пройдет максимально быстро и качественно, нас ждет чудесное развитие впереди, а все знакомые куратора обязательно восхитятся нашим проектом и тоже захотят себе такую чудесную систему.
Четверг, 11 утра. Звоню директору по закупкам. Он сбрасывает. Ну сбрасывает и сбрасывает, на совещании человек, наверное. Вечером тоже сбрасывает, начинаю напрягаться. Набираю главного ИТ-шника — он говорит, что в компании случилось ЧП, проблема не в нашем контракте, нужно подождать пару дней. В четверг и пятницу без изменений — ребят, все будет хорошо, ЧП, подождите немного.
На следующей неделе выставка, в которой участвует все руководство компании. Не до нас, но все будет хорошо.
Активно пытаюсь понять в чем дело, может, кто-то после конкурса пришел с условиями получше, может, нужно усилить предложение. Дозваниваюсь до директора по закупкам через его секретаря — он подтверждает, что усиление предложения поможет. За пару дней согласуем и подписываем гарантийное письмо, что в рамках проекта отгрузим еще и дополнительные лицензии.
Контракт не подписан и не подписывается, тишина, но все говорят, что с новым предложением все точно будет хорошо.
Эпилог: Через несколько недель выяснилось, что в среду, прямо после встречи со мной, топ-менеджеры поехали в ресторан отмечать помолвку функционального заказчика. Функциональный заказчик предложил гулять за его счет без ограничений по бюджету, а после десяти бутылок коньяка на шестерых отказался оплачивать счет в среднюю годовую зарплату в стране. После этого он перевернул стол, разбил окно, начал кидаться стульями в официантов, а затем и в вызванных официантами сотрудников полиции и был уволен по собственному желанию задним числом. Проект стало некому вести.
Описать уровень моего удивления из-за такого хода развития событий очень сложно, ведь несмотря на хорошую часть про риски в целом, в Project Management Body of Knowledge, Библия проектного управления</p>" data-abbr="PMBoK">PMBoK, почему-то, конкретно такие случаи и меры противодействия им подробно не описаны. Попробую дождаться новой редакции и глянуть там.
Сцена после занавеса: Сначала заказчик пытался разгрести дела ушедшего по собственному желанию сотрудника и понять, как все работало. Потом нашел нового. Через некоторое время новый функциональный заказчик заключил контракт с конкурентом напрямую, без проведения конкурса.
Акт 2: Счастливый конец
Пролог: Региональное правительство. Что-то около 1000 пользователей системы, министерства и муниципалитеты. Развитием в прошлые годы занимался конкурент, но конкурс есть конкурс — наше предложение было наилучшим по совокупности показателей. Из-за дополнительных для нас работ по миграции данных, плановая прибыль и плановые риски стремились к нулю, была надежда на дальнейшее развитие проекта в заказчике в следующие годы. Текущий контракт был на полгода.
Драма: Половина Стейкхолдеры — Лицо, группа или организация, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта. PMBoK</p>" data-abbr="стейкхолдеров ">стейкхолдеров ждали других ребят, другая половина просто бесились из-за нового интерфейса. И те и другие смотрели на нас как на источник геморроя.
Конкуренты, которые занимались проектом до этого конкурса, настойчиво просились пойти на субподряд с компенсацией их потерь (и с убытком в 30% суммы контракта для нас). Некоторые стейкхолдеры намекали, что это наилучший выход для всех.
ИТ-службы заказчика решили, что проект намечается слишком простым и скучным и расторгли контракт с победителем параллельного конкурса на поставку оборудования. Нам сообщили, что из-за конкурсных процедур железо будет через месяц-два после формального окончания нашего проекта. “Так бывает, привезите свое железо, вы ж ИТ-компания”.
В итоге заказчик позвал на совещание и сделал предложение, от которого нельзя отказаться. Проект вы все равно не выполните, давайте, мол, расторгнем контракт по соглашению сторон. В реестр недобросовестных поставщиков, мол, вы не попадете, мы умеем так расторгаться.
Я осознал, что списание в невозвратные потери еще нескольких человеко-месяцев трудозатрат добавят нам сюжетный твист и сменят вектор моей карьерной траектории в сторону работы грузчиком и решил бороться. Руководству сообщил, что все идет шикарно, скоро закроемся и получим миллионы миллиардов на развитие.
Эпилог: Эти полгода в итоге мне пришлось прожить в городе у заказчика, заниматься проектом практически эксклюзивно, сняв всю прочую нагрузку и забыв о личной жизни. Я регулярно проводил совещания у каждого из функциональных заказчиков, чтобы детально показывать им прогресс в настройке системы по их зоне ответственности. Я приходил в здание аппарата первым и уходил последним, старался учитывать все замечания и пожелания и выстраивал отношения так, как никогда в жизни не выстраивал. Из-за дополнительных незапланированных затрат на реализацию “хотелок” и завоевание доверия некоторую часть работ пришлось выполнять самостоятельно, выступая и в роли аналитика и в роли инженера, только чтобы поместиться в бюджет. На самом деле, перерабатывала вся команда, по итогам проекта я разделил с ребятами свою проектную премию.
Для помощи в миграции БД я обратился к бывшим сотрудникам моей компании — они согласились помочь за сдельную плату во внерабочее время.
Способствовал исправлению настроений и честный разговор с командой заказчика на одном из совещаний — мол, ребят, есть поручение губернатора, по голове за потерянные 3 месяца получат все, не только мы. После разговора число замечаний вида «я приму проект только если кнопочки будут все слева и круглые, сделайте мне так же, как сейчас в системе» драматически уменьшилось.
Спустя 2 месяца от старта проекта пришел новый советник по ИТ, с которым сразу удалось наладить отношения — он разобрался в ситуации и значительно помог с желающими вставлять палки в колеса.
По оборудованию — сначала я обратился в свою компанию, чтобы взять наши внутренние серверы, которые мы использовали под SaaS и тестирование. Мне их не дали. Второй идеей было покопаться на складах и барахолках у заказчика, но там было пусто. Я попробовал связаться с их поставщиками оборудования, затем с Ростелекомом, который отгружал им феерические мощности для «Умного» и «Безопасного города» и ситуационного центра. Мимо. В итоге удалось заключить дополнительное соглашение аж на 3% суммы проекта и на эти деньги и остатки рисков арендовать серверы на полгода.
Сцена после занавеса: Проект в итоге удалось сдать и защитить почти без просрочек. Заказчик пользовался системой и после моего ухода из компании-исполнителя. ЦОД получил от меня пару заказов на аренду по полной цене. Я серьезно прокачался в софт скиллах, в переговорах и в построении отношений со стейкхолдерами. Меня бросила девушка, которую не устроили мои полгода в другом городе и даже проведенный там двухнедельный отпуск. Но это, наверное, и к лучшему. Наверное.
Акт 3: Любовь и прочие неприятности
Пролог: Крупный промышленный холдинг, в рамках которого есть материнская организация и несколько дочерних с филиалами в самых отдаленных уголках необъятной. В рамках всего холдинга внедрена и поддерживается уже много лет некоторая ключевая система с элементами организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности. Википедия</p><p></p>" data-abbr="ERP ">ERP с привязанной прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками (клиентами), в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процессов и последующего анализа результатов. Википедия</p><p></p>" data-abbr="CRM">CRM.
Стейкхолдеры максимально довольны, на еженедельных совещаниях тишь да гладь, все возносят хвалу лучшим подрядчикам в части ИТ, которые когда-либо были. ИТ-директор строгий, но справедливый, держит и меня и других подрядчиков в ежовых рукавицах, но и он не имеет глобальных претензий. Единственное, что портит малину — репликация, в основном отчетов по продажам и производству (внутренняя кухня филиала остается только внутри). В одном из филиалов то электричество упадет прямо в процессе переноса данных, то интернет, а иногда уборщица решает перезагрузить серверы в последние дни предоставления квартальных отчетов.
Вот уже несколько лет я продвигаю идею централизации. Меньше затрат на поддержку и серверы, меньше затрат на лицензии для БД и серверной ОС, оперативнее обмен данными, лучше средства контроля для материнской организации, а еще никакой репликации. Из приятных бонусов — дочерние организации больше не смогут вручную править записи в БД и перед проверкой в серверных комнатах прекратятся пожары и потопы (серьезно, у них 3 таких случая за 4 года).
Тут все начинают суетиться по поводу импортозамещения и наконец-то моему проекту развития приходит зеленый свет.
Драма: Заказчик быстро самостоятельно пишет неплохое ТЗ с объективными требованиями, запрашивает по рынку желающих поучаствовать. Заявляется несколько небольших компаний и пара ИП, весь крупняк решает, что за эти копейки возиться с заменой системы, да еще и с миграцией ~50 БД из всех филиалов, не очень хочется. Ожидается публикация конкурса на одной из внешних коммерческих площадок со дня на день.
В рамках контракта по поддержке я по-прежнему участвую в регулярных совещаниях, все системой довольны, но в какой-то момент начинают прятать глаза. В кулуарных разговорах после совещаний у стейкхолдеров, по их словам, просто неудачный день. ИТ-директор все так же дружелюбен и рад меня видеть, но в какой-то момент начинает переносить совещания. Выглядит странно, ведь раньше у него всегда находилось на меня время.
Так проходит несколько месяцев.
Эпилог: С помощью остальных стейкхолдеров и других подрядчиков холдинга восстанавливаю события. Оказывается, жена одного из согласующих контракт менеджеров работает заместителем начальника отдела сопровождения системы. Оказывается, у них с мужем легкий семейный кризис и ее адюльтеры его слегка бесят. Оказывается, на ее маму записано практически все имущество согласующего.
Имел место легкий публичный скандал между менеджером и начальником отдела сопровождения системы, где оба послали друг друга в попу и почти подрались. Собственник не хочет увольнять менеджера и начальника отдела (потому что они хорошие работники и молодцы, а без начальника отдела сопровождения система в целом быстро загнется), жена готова разводиться, но не готова делить имущество. Менеджер не готов поощрять начальника отдела сопровождения и выделять ему бюджет на развитие системы, не согласует контракт всеми силами и всеми поводами. Это же касается, кстати, и контрактов следующего года на развитие, благо поддержка шла по Time and Materials, поквартальная оплата фактических затрат подрядчика на разрешение инцидентов по фиксированной ставке </p>" data-abbr="T&M">T&M.
Вся эта ситуация равномерно надоедает согласующему менеджеру, руководителю и ИТ-директору. Мой мобильный добавляют в черный список, для поддержки просят другого руководителя проектов.
Сцена после занавеса: Новую жену для согласующего менеджера с аналогичным пакетом имущества я не нашел, хотя и не то чтобы сильно искал. На встрече, куда я все-таки смог пробиться спустя несколько месяцев, что руководитель, что ИТ-директор загадочно ржали и отказывались обсуждать конструктивные способы решения проблемы. Репликация продолжила втыкать нож в спину и и спустя пару лет, а потом систему поменяли.
Заключение
Почему так сильно бесят «черные лебеди» проектного управления, помимо потерь на неудачных пресейлах и периодической работы в стол?
-
С учетом прочих проблем, ты не можешь достоверно планировать время и загруженность разработчиков и проектной команды, выполнять показатели по прибыли и выручке. Единственный выход — вести больше пресейлов и иметь больше проектов в воронке, сталкиваясь с переработками.
-
Работа над проектами зачастую связана с существенными интеллектуальными и эмоциональными вложениями всей команды. «Черные лебеди» сильно бьют по мотивации и уверенности в способностях держать проект под контролем.
Практически каждый проект имеет свойство расползаться и обрастать дополнительными сложностями. Некоторые проблемы становятся непреодолимыми, но сочетание стратегического
Как в басне о кузнечике и осьминоге: весь год кузнечик запасал травку на зиму, а осьминог тискал свою подружку и смотрел ящик. Потом пришла зима и кузнечик умер, а осьминог съел все его запасы и купил спортивный автомобиль. Понимаешь, как устроен мир?
Футурама, «20th Century Fox», Мэтт Грейнинг, Дэвид Коэн
*истории выбраны и описаны таким образом, чтобы никому не навредить; произошли более 6 лет назад
Автор: Сергей Власов