Нередко тяжелые испытания проекта происходят не из-за технических сложностей реализации и сложных задач, а из-за заказчика и заинтересованных лиц. Кто не слышал чего-то из разряда «А давайте вы сделаете этот проект, который оценили в три месяца за полтора в том же виде»?

Даже опытным руководителям проектов бывает сложно сказать заказчику: «Нет, так не пойдет, мы не будем так делать». Потому что в ход идут прямые и косвенные манипуляции, вроде «войдите в моё положение», «в компании девушки моего брата такую проблему решали в 7 раз быстрее», «а давайте вы просто нормально поработаете, напряжётесь и успеете?». В статье я расскажу о возможных вариантах реагирования на серьезные изменения бюджета, содержания и сроков проекта.

Задача: обеспечить информированность участников о проблемах, вызванных изменениями, оценить риски, не давать нереалистичных обещаний и сохранить нервы команды.

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

Причина появления статьи: Часто замечаю, что руководители проектов испытывают трудности, душевные терзания и чувство вины из-за проблем, вызванных тем, что заказчик требует невыполнимого и, откровенно говоря, путает берега. Даже зная и понимая, что это неосуществимо, теряешься и вместо решительного «Нет» говоришь неуверенное «Посмотрим, что можно сделать». Это приводит к выгоранию, и проект все равно не будет реализован по этим условиям — вы останетесь виноватым, потому что согласились.

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

Для упрощения понимания ситуации зададим стартовые условия:

• Мы разрабатываем мобильное приложение в продуктовой компании.

• Пройдены этапы сбора требований и оценки, недавно начали разработку. 

• Срок разработки: 6 месяцев. 

• Команда укомплектована и её компетенций достаточно, чтобы успеть в срок. 

1. Заказчик забирает ресурсы на другой проект

Ситуация: к вам приходит заказчик и говорит, что ему нужны два ваших мобильных разработчика (iOS/Android) на 2 недели, чтобы спасти другой горящий проект. 

Проблема: то, что разработчиков забрали на 2 недели, не означает, что вернут через 2 недели.

Реальность: вместо 2 недель разработчики вернутся через 4 недели из-за багфикса. Наши потери: 8 недель. 

Что делаем: 

• До того как разработчиков забрали, оцениваем как изменится план-график с учетом того, что разработчиков заберут на 2 недели и показываем заказчику. 

  • Если принял план — всё хорошо.

  • Если нет, то уведомляем, что либо разработчики остаются на проекте и работают, либо сокращаем объем работы на соразмерную величину. Договариваемся. Согласовываем новый план-график через официальный канал, например, почту. 

• Прошло 2 недели. Если разработчики не вернулись и оказалось, что нужны еще 2 недели, то готовите новый план-график, где срок проекта отодвигается с учетом новых вводных, либо уменьшается объем работ. Стараетесь согласовать новый план.

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

Действия в случае конфликта:

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

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

Что нельзя делать: не замалчивайте такие ситуации, либо согласовывайте новый план-график, либо форсируйте принятие решения руководством. 

Главная мысль: если обещали ресурсы и их не дали, вы не виноваты. Нужно искать варианты решений и передоговариваться.

2. Внезапное изменение содержания

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

Проблема: добавляется новая фича, которая сильно увеличивает риски. 

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

Что делаем: 

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

• Параллельно ищем варианты привлечения дополнительных ресурсов — забрать программистов с другого проекта, привлечь подрядчиков или нанять новых разработчиков. Учитываем, что на поиск разработчиков и включения их в работу может уйти 1-2 месяца минимум. Скорее это не наш вариант, но его нужно рассмотреть.

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

• Презентуем новый план-график по критическому пути проекта с учетом нового дедлайна, не вошедшие фичи отодвигаются на срок после релиза MVP. Приглашайте на встречу руководство и техлида. 

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

Действия в случае конфликта: 

• Обращаемся к руководству.

• Если не помогло, еще раз анализируем можем ли мы добавить новые ресурсы.

• Пообщайтесь с коллегами и командой для того, чтобы найти еще способы успеть к сроку. Например, можно прибегнуть к помощи костылей или упростить некоторые решения до безобразия. 

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

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

Что нельзя делать: как бы на вас не давили, не подписывайтесь под невыполнимые условия, ищите компромиссы и точки соприкосновения. 

Главная мысль: как бы не говорили обратное, вы не обязаны удовлетворять все хотелки заказчика в те сроки, которые он сам себе выдумал. Действуйте проактивно, но если чувствуете, что никак не получается – честно скажите об этом. 

3. Изменение сроков

Ситуация: приходит заказчик и говорит, что проект на 6 месяцев нужно сделать за 3 с неизменным содержанием, потому что это пообещали генеральному директору или акционерам. 

Проблема: ускорится в два раза на ровном месте нельзя, если оценивали сроки корректно.

Реальность: часто такие предложения приходят с формулировкой «мы уважаемому человеку, акционеру пообещали, ОЧЕНЬ надо сделать». Это может сильно нервировать, так как тот человек точно уважаемый, а вы еще можете себя таким не чувствовать. Недавно работаете в компании, например. 

Для успокоения перенесите ситуацию на реальную жизнь, где вас просят: «Мы уважаемому человеку пообещали, что вы стометровку пробежите за 9 секунд. ОЧЕНЬ надо.» Ощутите насколько странно это звучит.  Мы оценивали не от балды, значит сроки корректные и со временем они имеют тенденцию увеличиваться, а не уменьшаться.  

Что делаем: 

• По аналогии с предыдущей частью собираем команду, техлида и изыскиваем способы, чтобы сократить сроки. Что еще можно сделать: пожертвовать качеством.

• Вспоминаем продвинутые техники сжатия расписания вроде fast tracking. Например, можно начать разработку интерфейсов мобильного приложения и API, не дожидаясь дизайна. Подробная статья на Хабре.

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

• С финальными результатами приходим к заказчику и показываем. Даже если не получилось сократить сроки на 3 месяца, то полтора будет неплохо. Дальше можно просить его поспособствовать — дать больше денег, уменьшить содержание, уговорить на ухудшение качества в угоду скорости. Помните, что он тоже заинтересован в том, чтобы успеть к сроку.

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

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

Что нельзя делать: соглашаться на то, что вы как-нибудь ускоритесь и придумаете что-то в процессе. Давайте будем честными — это вряд ли произойдет. 

Осознайте, что будет, если вы сдадитесь без боя:

1. Команда начнет перерабатывать, недовольство возрастет, а вместе с ним и желание искать работу в другом месте.

2. Соглашаясь на невыполнимые условия, вы рискуете выглядеть как не самый компетентный руководитель, который уступает давлению без понимания последствий.

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

Главная мысль: мы живем в реальном мире и чтобы успеть в сроки недостаточно просто желания, нужно изыскивать способы и чем-то жертвовать. Ваша работа найти эти способы, но если их нет — заказчик должен принять тот факт, что невозможно ускорится настолько сильно.

Послесловие

Задача заказчика — сделать проект в минимальные сроки и бюджет, запихав при этом максимальное содержание. 

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

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

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