Как не дать команде выгореть из-за заказчика
Нередко тяжелые испытания проекта происходят не из-за технических сложностей реализации и сложных задач, а из-за заказчика и заинтересованных лиц. Кто не слышал чего-то из разряда «А давайте вы сделаете этот проект, который оценили в три месяца за полтора в том же виде»?
Даже опытным руководителям проектов бывает сложно сказать заказчику: «Нет, так не пойдет, мы не будем так делать». Потому что в ход идут прямые и косвенные манипуляции, вроде «войдите в моё положение», «в компании девушки моего брата такую проблему решали в 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, либо ничего не получится.
Что нельзя делать: соглашаться на то, что вы как-нибудь ускоритесь и придумаете что-то в процессе. Давайте будем честными — это вряд ли произойдет.
Осознайте, что будет, если вы сдадитесь без боя:
- Команда начнет перерабатывать, недовольство возрастет, а вместе с ним и желание искать работу в другом месте.
- Соглашаясь на невыполнимые условия, вы рискуете выглядеть как не самый компетентный руководитель, который уступает давлению без понимания последствий.
- Опасный прецедент: Если заказчик поймет, что на вас можно надавить и вы согласитесь, он будет использовать этот метод снова и снова.
Главная мысль: мы живем в реальном мире и чтобы успеть в сроки недостаточно просто желания, нужно изыскивать способы и чем-то жертвовать. Ваша работа найти эти способы, но если их нет — заказчик должен принять тот факт, что невозможно ускорится настолько сильно.
Послесловие
Задача заказчика — сделать проект в минимальные сроки и бюджет, запихав при этом максимальное содержание.
Ваша задача — достичь целей проекта, не загубив при этом команду и себя.
Вы непременно будете испытывать давление и манипуляции со стороны заказчика и заинтересованных лиц из-за расхождения интересов. В разных компаниях бывает по-разному. Я видел неоднократно случаи, когда дело доходило до криков и оскорблений, и даже сам на себе испытывал подобное давление.
Это действительно нелегко, но это можно пережить, помните, что за вами команда, которой придется вместе с вами делать всё то, что вы наобещали из-за чувства страха и вины.
Я думаю написать статью о том как руководителям проекта переживать и бороться с неприятными чувствами из-за давления заказчика и как изменить к этому своё отношение, но это совсем не формат VC.RU, поэтому предлагаю подписаться на мой Телеграм-канал, где я опубликую эту статью.
Для проджектов все четенько, а если я и есть тот самый руководитель проектного офиса, которого зовут, чтобы разобраться с этим, и вот я слушаю все эти замечательные пожелания клиента, надеющегося, что вот я-то сейчас наконец войду в его положение и соглашусь на все, и.... рекомендаций для руководителей не пишет никто 😅
(я понимаю почему. просто откликнулась потому что есть эмоции по отношению к таким ситуациям)
Правильно, никаких рекомендаций в публичном доступе — не будем давать потенциальным противникам шансов подготовиться к боевым действиям :)
Спасибо за отклик, у меня тоже к таким ситуациям особое отношение, поэтому я и написал эту статью.