Руководитель проектов: как говорить заказчику «нет», когда заказчик хочет слышать только «да»?

Сейчас в моде слово «клиентоцентричность», которое заменило привычное мне «клиентоориентированность». И выглядит это так, что если раньше важно было делать свой продукт или сервис, ориентируясь на клиента, то сейчас надо просто пойти и сделать, как тебе сказал твой клиент. И неважно, что ты там думаешь, ты же должен быть клиентоцентричным. Для гос проектов это весьма актуально, кто работал, тот знает.

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

В своей работе я много раз приходил на аккаунты или проекты, которые надо было спасать. Однажды меня взяли на проект, где до меня за 4 месяца сменилось 4 РП, ведущий архитектор готовился написать заявление «по собственному», потому что он не подписывался под то, что продали, а заказчик понимал, что дело неладно и уже думал о смене подрядчика. На выходе, спустя год, получился успешный проект, выполненный с отклонением от бюджета на 0.5% (не шучу, я проверял), довольный заказчик и продолжение работ на много лет для моей компании. А с тем архитектором мы и вовсе подружились.

И это – не единичный случай, в моем опыте таких историй примерно десяток.

Вначале почти любой проект выглядит примерно так: вы тихо и мирно согласовываете со всеми ТЗ, планы работ, бюджет, устав и все остальное. Царят приятные ожидания и легкая эйфория: «ура, мы все согласовали и щас как начнем!».

А дальше ваш проект начинает напоминать телегу, несущуюся с горы, в которую пытаются накидать все больше требований, сроки уменьшить, а половину колес от телеги забрать (вы же классный РП, справитесь и так, а на другом проекте все пылает, там нужнее). Но если телега не долетит до финиша или долетит, но не так, как было согласовано – виноваты будете вы. Да-да, именно вы, дорогой РП.

В работе Руководителя проектов неизбежно (и очень быстро) наступает момент, когда остро захочется сказать «нет»:

и много других «нет». Однако, есть проблема. Ваши заказчики не хотят слышать «нет», оно их печалит. Ваш руководитель тоже не хочет слышать «нет, я не могу». Он хочет, чтобы вы постарались сделать.

Что же делать? Как соблюсти баланс между отказом с риском испортить отношения и желанием сделать хорошо за ваш же собственный счет?

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

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

Вот эти причины:

Негативное – это когда я воспринимаю любое изменение, как что-то ужасное, невыносимое, нерешаемое и говорю «нет» даже не подумав, как это можно решить. Еще бы: чтобы подумать, надо тратить энергию, а делать лишних движений не хочется, и большой соблазн просто ответить «этого нет в ТЗ, и я этого делать не буду, обратитесь к руководителю». К сожалению, это плохо работает, заказчик воспринимает это, как негативную и неконструктивную позицию. Я много раз проверял это на себе и много раз видел, как это плохо работает у моих менеджеров. У РП с негативным подходом работа превращается в ежедневный бой. А в драке ничего хорошего ни для кого нет. Мы тут собрались работать и зарабатывать деньги, а не ругаться. Be positive, don't be negative.

Это вторая причина по важности. Часто вижу, что РП воспринимает заказчика как врага, который пришел специально, чтобы навредить РП. Почему-то сложно понять, что с изменениями пришли не просто так. У твоего заказчика проблема, и чтобы ее понять, надо приложить усилия: осознать его процессы, приоритеты и боли. Одним словом, потратить энергию и провести небольшой бизнес-анализ. Проблема в том, что многие РП ленятся это делать, мотивируя это тем… на практике ничем не мотивируя. Просто не делают. У РП с таким подходом никогда не получится установить доверительные отношения с заказчиком (внутренним, внешним – без разницы). А нет доверительных отношений – жди больше проблем.

Это про гибкость. Не в том смысле, что это умение прогибаться и делать хорошо другим за свой счет. А про умение искать компромисс с выгодой для себя (так как РП – наемник, то выгоду для своей компании). Если, решая проблему, вы видите десятки вариантов решения – смело пропускайте этот пункт, он не про вас. Для остальных скажу, что анализ изменений необходим для того, чтобы предложить ваши варианты решения. Обратите внимание: вы не делаете то, что вам сказали, но вы выслушали, поняли, о чем речь и, как эксперт, предлагаете компромиссные варианты. Что видит ваш заказчик? Вы ограничены рамками своего проекта, но вы искренне стараетесь помочь и ищете варианты решения. К вам уже будет совершенно другое отношение. И еще по этому пункту. Если вам кажется, что вариантов решения проблемы нет, кроме как сдаться и просто согласиться – вам кажется. Вариантов всегда много, просто вы мало подумали или см. следующий пункт.

Это классика переговоров: вам звонит разгневанный заказчик или ваш руководитель и требует немедленно что-то сделать. Что-то, что повлияет на ваш проект. И требует немедленно назвать срок, когда вы это сделаете. Или вы проводите показ функционала, заказчик говорит, что все замечательно, но вот тут надо сделать маааленькую доработочку. Маленькую. До пятницы. Если вы согласитесь, не подумав, вам придется много страдать. Вас будет ненавидеть команда, вас будет ругать ваш босс, да и заказчик спасибо не скажет. А всего лишь надо было сказать золотую мантру РП: «коллеги, я замечание понял, мне нужно немного времени, чтобы его оценить, до конца дня я скажу, что можно с этим сделать». Да, на вас могут давить, ругаться, но взять паузу на оценку вы всегда имеете право. Даже несколько часов помогут вам а) выдохнуть и успокоиться б) поговорить и посоветоваться (с коллегами, руководителем или кем-то), чтобы не принимать решения сгоряча. Тут как в боксе: если вы пошли в открытый размен, велик риск ошибиться и пропустить удар (в нашем случае – непредсказуемо большую доработку). Лучше не торопиться и принять обдуманное решение, за которое вы реально сможете ответить.

Реактивность – это когда меня бьют, а я отвечаю. Я реагирую. Проактивность – это когда я понимаю, что сейчас вечер, идти через темный и страшный район не хочется и я вызываю такси. Это когда я действую на упреждение. Реактивный менеджер никогда не заглядывает вперед. У него и сейчас дел полно, не отвлекайте. В итоге он не видит ничего дальше своего носа, по которому он регулярно получает, за то, что ничего не видит. Умение выйти из операционки и умение видеть проблемы проекта заранее – обязанность хорошего РП. Видеть проблемы ваших заказчиков, которые могут повлиять на ваш проект – тоже. Для этого есть матрицы рисков, статусные встречи и много других инструментов, которыми далеко не все умеют пользоваться. «Зачем мне делать таблицу рисков, толку нет», «зачем мне проводить статусы с заказчиком – только время проводить зря». Ребята, если неправильно пользоваться этими инструментами, конечно, незачем. Хороший статус, к примеру, может занимать 15 минут: РП вышел, рассказал главный риск, требующий решения, обосновал, предложил пути решения. Заказчики и спонсоры согласовали – все, всем спасибо. Если вы это не делаете, вы - реактивный менеджер, и будете получать за это по голове регулярно, пока не научитесь быть проактивным.

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

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

Я люблю отсчитывать от крайностей. В случае работы Руководителя проектов есть две крайности: «соглашайся на все и попробуй быть хорошим для всех» и «противься вообще всему, а кто против – пусть идет читать ТЗ» (матрицу RACI, устав проекта и что там еще).

И то и то – крайние стратегии. Первая приведет к тому, что вы доблестно сгорите, пытаясь понравиться всем, а потом вас еще и уволят, потому что всем понравиться не получится. Вторая приведет к тому, что вас назовут негибким, негативным и неумеющим идти на встречу заказчику и тоже уволят.

Для меня истина лежит посередине, в балансе. Никогда нельзя забывать про границы вашего проекта. Но не стоит и думать, что эти границы незыблемы, скорее – это ваша переговорная база, от которой надо начинать обсуждения. Границы можно пересогласовать, а объем можно изменить и, если после этого все ваши стейкхолдеры и заказчики счастливы – вы все сделали правильно, и следующий проект позовут делать именно вас, а не того парня, который вначале пути испугался изменений, и всех послал нафиг, обосновывая это тем, что в ТЗ не было. Люди неидеальны: заказчики неидеальны, спонсоры неидеальны, вы сами неидеальны, ошибаются все. Стратегия помощника гораздо выгоднее стратегии «я делаю только то, что в ТЗ». По моему опыту – в 95 случаях из 100. Поэтому мой выбор – не говорить «нет», а говорить «давайте поглядим, что мы можем сделать».