В прошлом блоге мы остановились на «обычной» ситуации: итогом проекта должно нечто в разы большее, чем проектная команда может сделать. Или же чем технически или технологически возможно сделать в принципе. Это знают все. Заказчики, команда, собственный менеджмент,‑ и никто не собирается чесатся до тех пор, пока по графику, определенному контрактом, не грянет гром. И когда он грянет, первым, кто окажется крайним, скорее всего будет менеджер проекта. Т.е. вы. Закономерен вопрос: а можно ли что-то сделать? И нужно ли?

Давайте расставим некоторые точки над i для полноты картины. С точки зрения менеджера проекта, работающего в компании-разрботчике ПО (или же ИТ-отделе крупной организации), ему доверили обеспечить успех вот в такой авантюре:

1. Контракт на реализацию проекта уже подписан. Функциональность и её характеристики уже описаны. Сроки, условия приемки, и все остальные относящиеся к делу и не очень детали, до которых додумались сейлс и юристы – уже «зафиксированы». Пересматривать контракт никто не собирается.
2. Собственный менеджмент очень-очень хочет, чтобы проект отдали в компанию. Именно поэтому он уже пообещал клиенту все, что тот хотел услышать. Понятно, о том, что пообещали то, что невозможно сделать, никто не хочет слышать.
3. Принимающая сторона уже успела пообещать всему миру и своей бабушке о том, что разработчик ПО сделает точно все по контракту и в оговоренные контрактом сроки, и что все будет чудеснейшим образом работать.

Что может сделать менеджер, если выполнить требования в полном объеме, в контрактные срок, да с нужным качеством невозможно? В зависимости от внутренней порядочности конкретного человека в конкретной ситуации, это может быть:

1. Назначение «стрелочника». Когда грянет гром, стрелочник будет отсрелен, им и прикрыть задержки и проблемы, не утруждая себя объяснениями;
2. Уход в формальную сторону: делать только то, что явно прописано контратом. Контрактом предусмотрено, что проект не принимается, если в нем больше 25 известных багов? Прекрасно. Определим термин «баг» так, чтобы этих багов вообще не было;
3. Прессинг и выжимание команды: психологическими трюками заставить людей работать круглыми сутками и в выходные, чтобы склепать и выпихнуть что-то как-то дышащее. А там и потом это уже будет чья-то другая забота, что со всем этим делать.
4. Проверка на практике, что из agile арсенала среботает в этой ситуации. ;-)

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

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

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

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

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

Первой реакцией эти на эти не сильно приятные новости скорее всего будет пренебрежение, наезд, угрозы отдать проект другому подрядчику, может быть даже и крик. Это нормально. Улыбаемся. Благодарим за уделенное время и проявленную настойчивость. Поясняем, что в нашем опыте заказчики (которых мы не называем по этическим соображениям) наистаивали на похожих проектах. Так вот нам коллеги неофициально рассказывали, что подписывавшим приемку приходилось объяснять, откуда взялись серьезные убытки в годовом балансе. Мы конечно же ожидаем, что наши опасения беспочвенны. Но все же, поскольку мы крутые сертифицированные менеджеры и у нас профессиональная этика и все такое, мы обязаны проверить допущения, которые столь критичны для успеха проекта. Даете под подпись отмашку с учетом озвученных пунктов? А то у нас народ к клавиатуре рвется.

В обстановке совещания вряд ли кто-то будет кидаться на вас с криками «ну и где тут подписывать?» Скорее вам объяснят, почему надо делать именно то, что написано в контракте, а не тратить впустую время. Например, так: «Наш вице-президент дал коммитмент основным клиентам, что к концу лета они смогут пользоваться обновлненной биллинговой системой. Мы ценим вашу профессиональную позицию. Надемся, она поможет вам поставить нам то, что мы заказали.» Тупик?

А вот если вы понимаете экосистему вокруг проекта – это может быть рычагом, которым можно развернуть разговор на 180 градусов. «Насколько мы понимаем вашего вице-президента, он проталкивает этот проект потому, что он так же дал коммитмент сократить обработку счетов до 48 часов и свести ошибки, допускаемые персоналом, до менее 1%. Кроме того, ему необходимо сократить внутренние издержки проведения платежей на 30% к концу года. Обновления, которые вы заказали, заметно улучшают условия труда пользователей. Изначальная идея была, что именно они и решат эту задачу. Однако мы уже знаем, что это не так: в лучшем случае они замедлят обработку на 20-25% по сравнению с текущей ситуацией.»

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