Счастливый заказчик, или Как управлять ИТ-проектом, не привлекая внимание санитаров?

Меня зовут Константин Попов. Я руководитель направления компании Т1 Консалтинг, уже семь лет я руковожу проектами ИТ-внедрения. Эти проекты очень часто попадали ко мне по следующим причинам:

• либо это была какая-то конфликтная ситуация;

• либо это был проект, где заказчик не знает, чего хочет – так мне говорили;

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

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

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

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

• Вы сдаете работы, и все принято… но далее тишина.

• А потом вы узнаете, что и разработкой толком не пользуются.

• И заказчик уже ищет другого исполнителя.

Де-юре проект был сдан, но де-факто результат достигнут не был.

А еще возникает ситуация, как из анекдота про воздушные шарики, которые и расцветки веселой, и надуваются хорошо, и не сдуваются… Все вроде по ТЗ у шариков, но они не радуют заказчика.

Как разобраться с этой ситуацией?

Кто такой счастливый заказчик?

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

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

Интереснее строки, которые идут ниже первой тройки. Это признаки того, что заказчик после сотрудничества с вами счастлив:

• он получил какой-то карьерный рост или похвалу;

• порекомендовал вас какому-то знакомому;

• окупил затраты на ИТ-разработку;

• советуется с вами о дальнейших ИТ-внедрениях;

• обращается к вам с какими-то новыми запросами.

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

Зачем нам делать заказчика счастливым? Когда я думал над этим вопросом, то нашел изречение древнего мыслителя Платона: «Стараясь о счастье других, мы находим свое собственное».

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

Чтобы этого добиться, нам нужны четыре составляющие:

• соответствие целям;

• правильно выстроенная коммуникация;

• персонализация обращения;

• и еще один секретный ингредиент, о котором я расскажу в конце.

Цели

Начнем с целей.

У нас есть заказчик. Я решил персонализировать заказчика и выделил три типа:

• Лицо, принимающее решения ЛПР – гендиректор, фаундер.

• Бизнес-заказчик – какой-то коммерческий директор, HR-директор и т.д.

• И наш знакомый ИТ-директор или админ.

У разных типов заказчиков для ИТ-проекта разные цели.

Почему-то чаще всего считается, что основная цель основателя или гендиректора – это получить прибыль, сократить затраты, повысить рентабельность (ROIT). На это очень часто упирают, в том числе, когда продают гендиректору проект.

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

• Первоочередная цель ЛПР состоит в том, чтобы развиваться, внедрять новое, «чтобы сотрудники не закостенели». Этими словами гендир или основатель выражает желание развивать компанию.

• Следующая цель – страх не успеть за какими-то инновациями. Владелец бизнеса узнал, что его конкурент внедрил какую-то ИТ-фишку – он понимает, что сейчас нужно что-то сделать, иначе компания может отстать.

• И третья цель – экономия! Причем именно прямая экономия, которую мы можем выразить в деньгах и посчитать по формулам, а не говорить что-то из разряда: «Удалось сократить рабочие часы, и теперь вместо трех секретарш достаточно платить двум». Важна именно прямая экономия или прямая выгода, которая приносится.

Идем дальше. Какие цели у бизнес-заказчика – HR или коммерческого директора?

Когда мы продаем ИТ-проект этому бизнес-заказчику, мы почему-то всегда упираем на функциональность. Мы обещаем, что сделаем такие-то функции, поможем решить такие-то бизнес-задачи, и все заработает – например, процессы согласования, бюджетирования, все что угодно.

А на самом деле у бизнес-заказчика в приоритете совсем другие задачи:

• Он переживает за свое место, и ИТ-проект – это для него способ быть в тренде, быть актуальным.

• Вторая его цель – это карьерные и финансовые перспективы. Он рассматривает успешный ИТ-проект как драйвер карьеры.

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

И последний заказчик из нашей тройки – это наш друг айтишник, которому мы продаем проект.

Поскольку это «наш» человек – мы с ним разговариваем на одном языке. И считаем, что для него важнее всего внедрить эффективное ИТ-решение.

Но на самом деле, его цели состоят в другом:

• Его основная цель – это безопасность ИТ-инфраструктуры. Ему главное, чтобы после того, как вы что-то внедрите, у него ничего не рухнуло.

• Вторая его цель – это поддержка решения в будущем. Эффективное решение, которое внедряет 10 человек в стране – это очень большие риски. Если с вами что-то не сложится – вы закроетесь или решите перепрофилировать свою деятельность – кто будет заниматься поддержкой этого решения? Эти две цели в первую очередь стоят во главе угла, и их нужно отрабатывать в проекте.

• Естественно, это поддержание актуальной ИТ-инфраструктуры. Человек оценивает, что его профессиональный и карьерный рост не должен останавливаться, и ИТ-проект, в том числе, работает с этой целью.

На ИТ-проекте мы должны работать со всеми типами целей одновременно.

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

Страхи и развитие – это основные цели, которые движут людьми, задействованными в ИТ-проекте со стороны заказчика.

В качестве примера расскажу кейс проекта:

• Небольшая семейная компания – сеть торговых точек по продаже дверей.

• Ильяс и Тимур – совладельцы. Молодые ребята, 30 с небольшим лет. Они хотят развивать компанию.

• Сергей – коммерческий директор, и Зоя – директор по развитию. Это топы. Они пришли в эту семейную компанию со стороны и поняли, что без внедрения CRM-системы работать нельзя. Но как ее использовать конкретно в этом бизнесе, конкретно в этих магазинах, им было не до конца понятно. Они так и говорили: «Помогите разобраться! Мы знаем, что надо внедрять, но не знаем, зачем».

Мы с командой проработали все эти типы целей.

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

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

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

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

В качестве второй выгоды придумали проект «нестандарт» – проведя мозговой штурм с Сергеем и Зоей.

«Нестандарт» – это нестандартные размеры. Когда к ним в магазины приходили покупатели, у них были двери стандартных размеров – в основном, проем 80 на 200. А приходили люди, которым нужна была дверь в коттедж размером 100 на 220 – таких готовых дверей не было, и человек уходил.

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

Эту прямую выгоду увидели ЛПР и подумали: «Ничего себе, есть какая-то ИТ-система, которая может нам денег принести?!»

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

Мы хорошо поработали, и они периодически возвращаются с вопросом: «А давайте придумаем что-нибудь еще?»

Коммуникации

От целей перейдем к коммуникациям.

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

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

Вопрос: что здесь не так?

Здесь все не так:

• Канал в данном случае – не Email, а сам ИТ-директор. Потому что ИТ-директор не будет решать этот вопрос сам, ему нужно идти куда-то дальше. Фактически вы делаете ИТ-директора каналом для передачи вашего сообщения об увеличении бюджета.

• Способ, которым ИТ-директор согласует нам бюджет – вообще неизвестен. Либо ИТ-директор сделает это докладом, либо отправит ваше письмо, либо подготовит свое.

• Что касается сообщения – вполне возможно, что он заглянет в кабинет генерального директора, скажет: «Подрядчик просит увеличения бюджета. Он прислал таблицу, но не уверен в ее обоснованиях».

• Уровень контроля с вашей стороны в данном случае – практически нулевой.

Как же сделать правильно?

• Нужна встреча в офисе заказчика.

• Нужно собрать большое серьезное совещание, сделать презентацию.

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

• Таким образом мы сделаем максимально возможное, чтобы решить эту задачу.

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

Для лиц, принимающих решения:

• В качестве канала взаимодействия, помимо встреч, очень хороший вариант – чат. Сейчас все владельцы бизнеса стали очень мобильны, и если есть возможность, вы можете списаться с ЛПР по какому-то поводу и решить вопросы в чате.

• Способ передачи – устав проекта и презентация, в которой нужно выделить главное.

• С ЛПР вы в первую очередь обсуждаете бюджет, цели и сроки – отсюда вытекают и типы вопросов, которые нужно адресовать Главному.

При общении с бизнес-заказчиком:

• Желательно проводить встречи и формировать отчеты – это самые лучшие каналы.

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

• Предметом обсуждения могут быть функциональные требования и сроки проекта.

Ну и с ИТ:

• Можно так же быстро переписываться в чате или написать email.

• Дать аргументацию тезисно.

• Сроки и бюджет ИТ-шника мало касаются – для него в основном важны технические и функциональные требования.

Персонализация

Что я хочу здесь дополнить.

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

• вы идете от шаблона;

• работаете с целями проекта;

• выстраиваете определенную специфику общения с заказчиком;

• и в конечном счете получаете персональное обращение.

Как это все понять? Выясняете, спрашиваете. Здесь нет какой-то жесткой теории. Стройте гипотезу, проверяйте ее, и все получится.

У меня был кейс:

• Руководитель проекта по личным причинам покинул проект на начальном этапе, и проект перешел ко мне – в этот момент в проекте еще шла подготовка технического задания.

• Федеральная сеть, CRM, колл-центр, несколько сайтов, интеграции и т.д. – многогранный проект с очень сложной инфраструктурой.

• Начинаю вести первую встречу и понимаю, что коммуникация не строится – со мной как-то холодно разговаривают. Все это происходило дистанционно: я в Питере, они в Москве.

• Что делать? Какой канал? Какой способ? Что с целями проекта? Ничего же не понятно, проект мне внезапно упал как снег на голову – просто в пятницу сказали, что со вторника нужно вести проектные встречи.

Я обратился к предыдущему руководителю проекта – спросил, что к чему. Он мне посоветовал поехать туда и поговорить с руководителем проекта (с их стороны – ИТ-директором).

Терять мне было нечего. Я решил поехать туда и встретиться в офисе.

Я позвонил, сказал, что подъеду. Он сказал: «Хорошо. Жду, пообщаемся».

Мы с ним садимся в отдельном помещении, начинаем общаться. Он долго меня расспрашивает: кто я, какие проекты вел и так далее. И через пол часа, когда эти вопросы выдохлись, он у меня спросил: «Так зачем вы приехали?»

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

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

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

Секретный ингредиент. Матрица «сложно-важно»

Правильные коммуникации, выстроенные цели и персонализация – это, конечно, здорово. Но есть еще одна вещь: матрица «сложно-важно».

Расскажу, какой смысл я вкладываю в этот термин.

В первую очередь идет эффект. Знаете, когда показываем заказчику какую-то стандартную функциональность на уровне 2*2=4, а он: «Вау!!» Вроде простенько, но заказчика это восхищает.

Или наоборот: мы пилим сложную кастомную интеграцию – нам очень непросто. Месяц ее пилим, кровь и пот льются, показываем заказчику, а он говорит: «Ну ок. А что вы так долго возились?»

В чем смысл:

• Сложно или просто можно сделать с точки зрения исполнителя. Если вы исполнитель или руководитель проекта, вы с этой стороны и будете расставлять приоритеты, ресурсы выделять, акценты выставлять и т.д. Мы, айтишники, берем и оцениваем – сложно это сделать или просто. Отсюда и пляшем. У заказчика нет квалификации для того, чтобы он мог это оценить. Мы ему это транслируем, а ему приходится соглашаться. Он нас выбрал, нам доверяет и нас будет слушаться. И он говорит: «Да. Это, наверное, сложно. Это, наверное, дорого. А здесь просто? Ну да, наверное…» Мы не спрашиваем при этом заказчика.

• А у заказчика это – «важно» или «не важно». Нужно плясать от того, что для заказчика важно, а что не важно.

Сопоставить наше «сложно/просто» и заказчика «важно/не важно» – это ключевой момент для успеха проекта.

Мы получаем матрицу, где у нас есть четыре квадранта:

• Важно заказчику, сложно делать. Отлично. Значит нужен ресурс, желательно с запасом. Следим за сроками – это ключевая точка проекта, приоритет №1.

• Важно заказчику, а нам просто сделать. Здесь главное не сказать вслух: «Ерунда, сейчас быстро сделаем!» Если вы понимаете, что это важно для заказчика, не нужно торопиться. Проработайте этот вопрос, уделите внимание обучению. Не нужно доводить до заказчика информацию о простоте.

• Не сильно важно для заказчика, но и сделать просто. Может быть, вам это поможет для сдачи проекта или для каких-то еще задач. Например, вы можете сдать простые и неважные задачи, когда у вас затянулись первые две группы разработки («важно/сложно» и «важно/не сложно»).

• И последний, самый страшный квадрант. Заказчику не важно, а сделать сложно. Обычно заказчик говорит: «У вас здесь все хорошо сделано, но давайте еще одну фишечку добавим – чтобы сообщение улетало мне в Telegram-канал». А стандартной функциональности такой нет. И он спрашивает: «Ну вы же знаете, как это подключить в Telegram-канал?» И вы киваете, говорите: «Хорошо, сделаем». И кидаетесь выполнять, хотя понимаете, что делать будете долго. Если вы видите, что это сложно и не важно для заказчика, не кидайтесь это выполнять – лучше вообще отговорите его от этой задачи. В крайнем случае, переведите ее на типовое решение. «В стандартной функциональности присутствует отправка на email – вам отправится email-уведомление». Может оказаться, что заказчику этого хватит, и он согласится.

От этой матрицы «сложно-важно» проистекает практически все:

• приоритеты проекта;

• ресурсы проекта;

• грамотное ТЗ;

• цели проекта – все что угодно.

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

Резюме

Подведем итоги.

Вся наука о счастливом заказчике заключается в следующем:

• Понять цели участников проекта. Берем типовые шаблоны, пробуем их, проверяем, выясняем в диалоге, внимательно слушаем;

• Коммуникация. Правильно выстраиваем коммуникацию, через правильные каналы, в правильном русле, правильно готовим сообщение для работы с заказчиком;

• Персонализация. Видим реальных людей за этими функциями, общаемся с ними, понимаем их личные цели и приоритеты в проекте;

• Приоритезируем управление задачами проекта через матрицу «сложно-важно».

Это те инструменты, которые помогают достигать гармонии с заказчиком и делать его счастливым.

И небольшой чек-лист. 10 пунктов из моего опыта, которые тоже помогут сделать заказчика счастливым.

• Первый пункт – очень простой: не переносите встречи. Прошу вас, всегда проводите встречи в назначенное время. Либо меняйте повестку, но проводите встречу.

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

• Если вы не можете сразу принять решение, хотя бы сразу дайте обратную связь, что вы приняли информацию. Напишите: «Я вас услышал».

• Обязательно: не допускайте поступления задач от заказчика из более чем двух источников. В идеале должен быть один источник, максимум – два.

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

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

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

• И последнее – «Управляйте проектом, не привлекайте внимания санитаров». К «санитарам» я отношу юристов и службу безопасности. Не доводите до этого. Как только до этого дошло – все проиграли. Проект рухнул, все стало плохо, ничего хорошего уже не будет. Так что не привлекайте внимание «санитаров».

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.