Управление ожиданиями на проекте

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

• что у него месяц будет закрываться автоматически;

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

• что у него отчетность в головную организацию будет сама отправляться.

Но есть один нюанс: он почему-то забыл нам об этом сказать. Или мы его не до конца расспросили.

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

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

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

Когда мы внедряем систему, решаем те или иные задачи, мы, по сути, являемся исполнителями. А нашими заказчиками являются непосредственно функциональные специалисты – начальник отдела продаж, начальник отдела производства, начальник отдела закупок, генеральный директор – именно они и будут принимать решения.

О том, как взаимодействовать с лицами, принимающими решения, я и собираюсь рассказать.

Что такое ожидания, и зачем ими управлять?

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

Для работы с ожиданиями нужно выделить всех ключевых функциональных специалистов в нашем проекте, и максимально отрабатывать их обращения, собирать, что они хотят.

Но тут есть один очень важный момент: управлять ожиданиями – это не значит делать любую хотелку пользователей. Управлять ожиданиями – это значит сформировать единую картину мира между заказчиком и исполнителем. Чтобы оба понимали, что мы делаем, как мы это делаем, и что получится на выходе. А если мы эту задачу не делаем, донести, почему.

Когда у нас получается сформировать единое информационное поле, и все правильно понимают, что происходит, проект идет на порядок гораздо более управляемо.

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

Первая и самая основная причина – нет согласованных целей в проекте:

• Сначала продажники пришли к заказчику, что-то красиво наобещали.

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

• И когда разработчик приходит к исполнению, он открывает договор и пытается понять – что нужно сделать? Зачем это делать? Для кого это нужно? Вообще непонятно.

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

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

Бывает так, что сверху большие начальники спустили: «Надо перейти на ERP». А кому надо, для чего надо – непонятно. В этом случае, что бы команда исполнителей ни делала – система не взлетит. Все будут на совещаниях головой дружно кивать: «Да, мы идем в светлое будущее!» А потом потихоньку спустят проект на тормозах, и через год-два как-нибудь все замылится.

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

Еще одна из распространенных проблем – сотрудники исполнителя по-разному понимают качество своей работы. Например, у нас довольно большая команда, где работает 10-15-20 аналитиков, и в их понимании задачи возникает разрыв:

• Один сотрудник сделал описание контрольного примера, четко все расписал, прикрепил картинки, схему процессов «как есть». Пришел и все сдал с первого раза.

• Второй исполнитель на 20 листах перепечатал книжку по ERP, пошел сдавать и удивляется, что у него с восьмого раза не принимают.

А потом заказчик приходит к руководителю проекта и говорит: «Уберите второго мальчика, он какой-то бракованный! Дайте мне первого!»

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

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

Через месяц прибегает, показывает, какая у него красивая чудесная система получилась, не демонстрируя промежуточных результатов, не согласовывая никаких внутренних документов. А заказчик (начальник производства) на это говорит: «Все, конечно, красиво, но это вообще не для меня. Зачем это было сделано?»

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

Как ключевые цели в проекте коррелируют с общими ожиданиями всех участников команды?

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

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

Поэтому на этапе продажи проекта мы четко должны понимать наши цели:

• для чего;

• кому мы делаем;

• и что мы на выходе должны получить.

В идеале мы должны прописать эти цели не только в договоре, но и во внутреннем уставе.

Даже выполняя внутренние проекты, устав желательно делать. В уставе мы описываем:

• что мы хотим;

• как мы хотим;

• как мы будем работать с рисками – решать те или иные проблемы.

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

А когда мы пришли к этапу обследования, мы можем более глубоко погрузиться в процессы и уже детально разобрать те или иные цели – понять, как вообще они выглядят.

На одном из проектов по автоматизации страховой компании нам директор поставил цель: навести прозрачность в отделе продаж. Что такое «прозрачность в отделе продаж»? Как я это должен навести?

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

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

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

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

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

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

Такой функциональности в 1С:ERP не было, и мы понимали, что переписывать типовой механизм резервирования – не вариант. Я думаю, те, кто переходил с 2.4 на 2.5, понимают, о чем я говорю – сколько там седых волос добавилось на этом переходе.

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

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

На следующих этапах (Техническое задание, разработка и опытно-промышленная эксплуатация) точно так же возникают моменты пересечения с ключевыми целями проекта. И каждую задачу, которая приходит, нужно трезво оценивать:

• Как новая задача повлияет на наши цели – что у нас получится, если мы вкинем новую задачу?

• Как новый сотрудник, который присоединяется к проекту, повлияет на эти цели?

• Как новые требования, которые возникают, отобразятся на наших целях?

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

Управление ожиданиями со стороны заказчика

Еще раз хочу остановиться на таком моменте: а заказчик – это вообще кто?

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

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

Я думаю, все были на таких совещаниях, когда подписывается итоговый акт или принимаются итоговые работы, генеральный собирает ползавода, и начинается: «Ну-ка, Вася, расскажи, все ли твои требования учли? Ну-ка, Петя, расскажи, а тебе все автоматизировали?»

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

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

Перечислю, на что нужно обратить внимание:

Цели проекта. Все должны однозначно четко понимать: что мы делаем; зачем мы это делаем; как мы это делаем; и куда мы идем.

Поверьте мне, на практике цели проекта принимаются не сразу и не всеми. Поэтому, чем чаще мы будем поднимать этот вопрос на каждом совещании, тем выше наш шанс, что мы все-таки объединимся в одно единое информационное пространство и будем идти в одном направлении.

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

И был у меня на практике забавный случай. Мы автоматизировали мясокомбинат в Республике Марий Эл и занимались там обучением бухгалтеров.

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

Оказалось, что на предприятии была такая практика: если на складе не хватало людей в момент отгрузки, они брали бухгалтеров и говорили: «Давайте-ка, друзья, с 6 до 10 вы работаете грузчиками и занимаетесь выпиской документов». Понятно, что если они с 6 до 10 грузили эту колбасу, а потом приходили к нам на обучение, они сидели со стеклянными глазами и думали: «Что здесь вообще происходит?»

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

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

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

На одном из проектов, который мы недавно выполняли, делали обследование. Наш довольно опытный специалист всех опросил, написал документ. Через две недели приходит довольный к заказчику, показывает результат обследования. Заказчик полистал документ и говорит: «А я хотел совсем другое. Мне интересно было, как идет взаимодействие между системами, кто мне из функциональных специалистов какую задачу решает и т.д.»

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

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

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

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

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

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

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

Что вообще нужно прописывать в протоколах? Я у себя на практике использую следующие основные пункты:

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

• цель встречи;

• что обсуждали;

• достигнутый результат;

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

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

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

По поводу статус совещаний. На статус совещаниях необходимо прописывать:

• чего мы достигли в результатах текущей недели;

• что мы планируем на следующей неделе;

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

Потому что нужно понимать, что у любого руководителя проекта и со стороны заказчика есть свои начальники, которые у него точно так же спрашивают: «А куда мы вообще идем? Когда мы это все дело закончим? Есть ли у нас какие-то сложности или недопонимания?»

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

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

Управление ожиданиями команды со стороны исполнителя

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

Здесь хотелось бы разделить все эти ожидания на 2 группы:

• что конкретный специалист (консультант, программист) ожидает от руководителя и от проекта;

• и наоборот – то, что руководитель проекта ожидает от исполнителей.

Как вы думаете, что конкретный специалист ожидает от проекта и от руководителя?

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

При входе в проект важно со всей командой исполнителей проговорить, кто сколько на этом заработает. А самое важное – что необходимо сделать, чтобы это заработать.

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

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

Если мы не назначим пофамильно ответственного, люди начинают думать: «Это, наверное, он сделает». Либо, наоборот, два специалиста начинают конкурировать за интересную задачу, и начинается внутренний конфликт.

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

Постановка и контроль задач. В этом пункте я хотел бы обратиться к трудам Тарасова Владимира Константиновича. Это очень опытный бизнес-тренер, который разработал хорошие 4 правила о том, как ставить и контролировать задачи:

1. Разработка порядка;

2. Доведение порядка до подчиненных;

3. Контроль исполнения;

4. Санкционирование.

С разработкой порядка мы все более-менее научились работать. Мы все знаем, как формулировать цели по SMART, и более-менее можем поставить задачу.

Но на следующем пункте (доведение порядка до подчиненных) уже начинает сбоить.

Помните детскую игру – «испорченный телефон»? Когда первый говорит историю второму, второй – третьему, третий – четвертому и т.д., и в конце все дружно смеются, потому что первая и последняя истории вообще никак между собой не совпадают?

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

Поэтому при работе с пунктом «доведение порядка до подчиненных» стоит особое внимание уделять следующим моментам:

• как исполнитель понял задачу;

• может ли он в принципе эту задачу решить.

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

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

Поэтому, когда мы доносим эту задачу до подчиненных, смотрим:

• может ли человек эту задачу сделать;

• есть ли у него техническая возможность;

• есть ли у него компетенции;

• есть ли у него на это время.

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

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

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

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

Для санкционирования есть очень хорошие инструменты.

• Это регулярные встречи 1:1, когда мы садимся с нашим исполнителем и говорим: «Давай пообщаемся? Что вообще происходит? У тебя все получается?» На этих встречах мы очень хорошо сближаемся по понятиям и работаем с ожиданиями конкретного исполнителя: «Что же ты вообще хочешь получить? Что у тебя получается, что – не получается, куда ты хочешь развиваться?» Так у нас получается сблизить наши картины мира.

• И второй пункт – это проектная документация. Проектную документацию нужно вести. Мы должны регламентировать, как должны выглядеть технические задания, инструкции или контрольные примеры. Поэтому, когда команда внедренцев становится чуть побольше, невозможно уследить за каждым – как он написал инструкцию или ТЗ. Один РП не может проверить за 10 специалистами, как они написали задачу. У нас должен быть четкий и понятный регламент о том, что:

  • в каждом техническом задании должен быть такой-то и такой-то пункт;

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

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

• доносите риски до всей команды;

• обсуждайте с ними реестр рисков;

• разрабатывайте вместе план «A», план «Б»;

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

Открытость в проекте и ее влияние на неоправданные ожидания

Еще раз хочу сказать об открытости в проекте.

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

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

• Регулярно проводим планерки.

• Регулярно проводим статус-совещания.

• Регулярно показываем наши результаты.

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

Как безболезненно передать наш проект на сервис, чтобы у конкретных специалистов заказчика не возникло культурного шока?

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

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

Но когда мы выводим проектную команду и переводим пользователей на сервис (на техподдержку), у конкретных специалистов заказчика возникает культурный шок: «Как так? Почему какая-то элементарная задача по печатной форме делается две недели? Что произошло?»

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

1. Подготовка кадров. Сервисных специалистов я начинаю подключать на этапе промышленной эксплуатации. Когда мы запустились в проект, я туда уже загоняю молодых специалистов. Они начинают знакомиться с функциональными потребителями, начинают знакомиться с задачами, которые есть, начинают въезжать в технологию, как это вообще происходит. И когда я вывожу сильных исполнителей из проекта, сервисные специалисты уже более-менее подготовлены. Они могут решать задачи, могут как-то коммуницировать, понимают, к кому идти, чтобы что-то решить;

2. Актуализация документации. Это вообще лютая боль. При запуске проекта обычно всем не до этого, там и так все очень насыщенно. Получается, что когда мы передаем проект на сервис, к нему прилагаются старые инструкции, старые учетные модели. Они не актуализированы – там написано уже не то, что есть. Конечно, на этапе внедрения очень тяжело убедить специалистов, которые уже в мыле: «А давай-ка после того, как ты свою задачу сделал, ты еще и актуализируешь документацию?» Но не сделав этот шаг, мы однозначно столкнемся с ошибками и недовольством пользователей из-за устаревшей документации.

3. Service Desk – система учета внутренних заявок. Запускать Service Desk нужно еще на этапе промышленной эксплуатации, чтобы постепенно приучать людей работать с системой. Потому что, когда идет запуск, наши специалисты находятся на территории заказчика, мы все тесно общаемся, и эти задачи очень часто решаются в частном режиме. Позвонил завскладом, говорит, что у него что-то не работает, просит прийти и посмотреть. Специалист туда стартанул и все починил. Переводить функциональных специалистов на то, что все заявки должны учитываться, очень тяжело. Позвонил? Хорошо, давай в первый раз я за тебя оформлю. Во второй раз я тебе покажу, как это делать. А в третий раз, если у тебя нет заявки, я к тебе не пойду. Можно сослаться на директора или еще что-нибудь, но запускать и внедрять систему Service Desk надо. Если мы перейдем на сервис без внедренной системы Service Desk, у нас все встанет колом. Специалисты не смогут постоянно прибегать по первому чиху пользователей, и эти задачи будут просто теряться;

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

5. И последний пункт, который я хотел проговорить, это сроки перехода. Это не должно быть как гром среди ясного неба. Уже на этапе промышленной эксплуатации надо подготавливать наших специалистов, что рано или поздно она закончится, что через два месяца у нас будет переход на сервис. Вот те люди, которые будут вас сопровождать, вот такая система Service Desk у вас будет и т.д. Нужно потихоньку подготавливать людей, что рано или поздно проект закончится и мы перейдем на новый формат работы.

Еще раз подчеркну, что именно правильно сформированные ожидания – это ключ к успеху проекта.

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

Основная работа руководителей проекта (70-80% времени) – это именно эти коммуникации, налаживание единой картины мира.

Если не получилось наладить общее представление о проекте, будет крайне тяжело его выполнить.

Вопросы

Я внутренний специалист заказчика. Допустим, высокие начальники хотят что-то внедрить, а я считаю, что это будет не перспективно. Как убедить руководство?

Здесь нужно садиться и взвешивать все «за» и «против».

Есть известный видеоролик о том, как заказчик просит нарисовать 7 параллельных линий, 5 из них перпендикулярных, 3 – зеленого, а 2 – красного цвета. Раньше при его просмотре я думал: «Какой неадекватный заказчик! Мы вроде все геометрию знаем». Но есть и другая сторона – может быть, мы в текущий момент не до конца понимаем цели, зачем они хотят это внедрить? И нужно садиться и разбираться с этим моментом – для чего они хотят внедрить?

Не всегда айтишники и функциональные специалисты понимают друг друга. Мы со стороны айтишников думаем: «Какую дичь они предлагают! Зачем? Это нерентабельно! Это в принципе не взлетит!»

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

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

Здесь надо смотреть на масштаб проекта.

• Если у меня в небольших проектах работает 1-2 консультанта, они и так понимают, что в проекте есть.

• Если в проекте становится 10 человек, они уже полную картину проекта себе не представляют. Мне нужно одного человека в какой-то момент вывести, второго посадить, он придет и скажет: «А дальше-то мне что делать?»

• И когда мы рано или поздно передадим проект на сервис, как это сопровождать? Ты будешь каждый раз бегать к тому консультанту и спрашивать: «А ну-ка, расскажи, что ты там сделал, как ты это запустил?»

Рано или поздно все специалисты выйдут из проекта, и где-то должна сохраниться компетенция. Нельзя все сохранить в головах у людей. Они уволятся, перейдут на другой проект, и мы просто потеряем информацию о том, как работать с тем или иным механизмом.

Тем более, что информация о системе меняется – ее нужно актуализировать, ее нужно поддерживать. Это большая и очень трудоемкая задача.

Что можно использовать для управления документацией и упрощения актуализации документации? Не всех же устраивает вариант просто хранить инструкции в Word на ftp. Мы сейчас пытаемся делать корпоративные XWiki и не просто заливать туда pdf-ки, а делать отдельные страницы под каждую инструкцию, чтобы у всех был доступ к актуальному варианту, плюс там сразу видна версия. Какими инструментами пользуетесь вы?

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

В больших корпоративных проектах всегда есть внутренняя информационная система по учету заявок, где аккумулируется эта информация. Кто-то такие системы на 1С пишет, кто-то на «Битриксе», кто-то еще на чем – много различных систем.

Какие есть критерии того, что мы с заказчиком друг друга поняли – сформировали эту картину мира и видим ее вместе правильно? Нет ли там каких-то подводных камней с его стороны?

Есть. Я сразу скажу, что в любой картине мира всегда есть подводные камни. Когда человек сформировал себе какие-то ожидания, нам он об этом забыл сказать.

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

Допустим, мы пришли к какому-то первоначальному пониманию, сформировали документацию, подписали договор, зашли в проект, начали работать, и тут резко начинают всплывать эти подводные камни. Как с этим работать дальше? Нужно тыкать в договоры: «Мы с тобой на берегу договорились об этом!», так?

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

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

Но когда мы на каждой планерке, на каждой встрече говорим: «Ребята, мы сейчас внедряем ERP-систему. Основная задача – автоматизация производства» И прибегают бюджетники и говорят: «Мы хотим платежный календарь», мы говорим: «Стоп, ребята! Вы – молодцы, хотите платежный календарь, но наша цель сейчас – запустить производство, и мы сейчас все силы кидаем на производство. Мы вам сделаем платежный календарь, но чуть позже».

Возвращаться к целям очень важно. Это позволяет донести до заказчика, что мы сейчас делаем другое, и не надо ничего нового выкидывать. Он начинает это понимать, и сам уже на каких-то встречах тем же самым бюджетникам скажет: «Вы откуда вообще взялись? Мы сделаем это, но позже!»

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

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".