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

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

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

1. Софтскиллы, которым не учат ни в одной школе Руководителей проектов, но которые вам понадобятся сразу на вашей работе.

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

Введение. Если от вас все хотят услышать «ДА», а вы его говорить не хотите?

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

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

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

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

Если вы хотите довести ваш проект до успешного завершения, рано или поздно у вас возникнет острое желание сказать:

• нет, я не сделаю это в 2 раза быстрее;

• нет, я не сделаю это, если у меня забрать половину команды;

• нет, я не буду автоматизировать этот процесс и «заодно» еще 2;

• нет, я не смогу это сделать дешевле, чем оценили;

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

Что же делать? Как соблюсти баланс между клиентоцентричностью и желанием послать всех далеко и надолго?

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

Как говорить «НЕТ»?

Начну с базы. Чтобы сказать «НЕТ», не обязательно говорить «нет».

Есть такой анекдот (это его часть, остальное тоже смешно, но не про то):
если дипломат говорит «Да» – это «Может быть»,
если дипломат говорит «Может быть» – это «Нет»,
если дипломат говорит «Нет» – это не дипломат.

Руководитель проектов должен быть дипломатом. Я это многократно проверил на своем опыте. Мое «нет», совершенно обоснованное, очень редко принимали мои руководители, мои заказчики. Даже если я был на 100% прав, говоря «Нет», меня считали негативным, негибким и неконструктивным. Меня это сердило, я не хотел меняться и это было моим стеклянным потолком достаточно долгое время. А потом я изменил подход, и это сработало.

Гибкость не означает подчинение вашему заказчику (бизнес, аккаунт, ваш руководитель). Это означает, что вы стараетесь найти варианты решения. как в пошлой, но 100% верной американской фразе «не говори мне, почему ты это не сделаешь. Скажи, что тебе надо, чтобы это было сделано?».  Эта гибкость должна иметь свои границы, чтобы вам не сели на шею, об этом тоже скажу ниже.

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

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

1. Негативное мышление.

2. Нежелание вникнуть в проблему клиента – обыкновенная лень.

3. Неумение видеть пространство возможностей для решения п2 выше.

4. Неумение взять паузу, обсудить и подумать.

5. Неумение быть проактивным.

1. Негативное мышление РП

Основная проблема.  Негативное – это когда я воспринимаю любое изменение, как что-то ужасное, невыносимое, нерешаемое и говорю «нет» даже не подумав, как это можно решить. Для меня стакан наполовину пуст.

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

Мораль: воевать с бизнесом или дружить – выбирать вам. Я предпочитаю договариваться, обозначая границы.

2. Нежелание вникнуть в проблему клиента - Лень

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

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

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

3. Неумение видеть пространство возможностей

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

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

Мораль: вы должны видеть не только ваше «НЕТ, идите нафиг», а пространство возможностей. Не видите – делайте п2 выше и п4 ниже. 

4. Неумение взять паузу и подумать

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

Стоит вам согласиться, дать слабину – и вы попались. Вы стали крайним, потому что доработочка не такая маленькая, ресурсов нет и вообще, ваши финансисты требуют бабки завтра, согласно вашему же плану работ. Знакомо? А всего лишь надо было сказать золотую мантру РП: «коллеги, я замечание понял, мне нужно немного времени, чтобы его оценить, до конца дня я скажу, что можно с этим сделать». Да, на вас могут давить, ругаться, но взять паузу на оценку вы всегда имеете право. Даже несколько часов помогут вам

• выдохнуть и успокоиться.

• поговорить и посоветоваться (с коллегами, руководителем или кем-то), чтобы не принимать решения сгоряча.

Тут как в боксе: если вы пошли в открытый размен, велик риск ошибиться и пропустить удар (в нашем случае – непредсказуемо большую доработку). Лучше не торопиться и принять обдуманное решение, за которое вы реально сможете ответить.

Мораль: никогда не называйте срок сразу. Не стесняйтесь брать паузу. Это не стыдно. Стыдно – пообещать и облажаться. РП который думает, перед тем, как говорит – хороший РП. 

5. Неумение быть проактивным

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

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

1. Поймите, для чего изменение нужно вашему заказчику? Что за приоритет, какой там объем работы и стоит ли вообще ради этого тратить время (или все решается проектным запасом)? Золотой вопрос: «Кто умрет, если мы этого не сделаем?»

2. Возьмите паузу, не принимайте решения сразу. Если решение не приходит или очень страшно его принять, поговорите с кем-то. Руководитель, коллега. Даже психолог сгодится.

3. Поймите, какое есть пространство решений вашей проблемы. Решений, как правило, есть несколько. Решения можно выписать на бумажке. Эти решения тоже можно обсудить с кем-то, чтобы понять плюсы и минусы каждого.

4. Проактивно предлагайте решения заказчику сами, не ждите, чтобы заказчик принял решение за вас. Это тоже классика: «не можешь остановить процесс – возглавь его».

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

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

Вывод

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

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

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

Поэтому мой выбор – не говорить «нет», а говорить «давайте поглядим, что мы можем сделать».