Сергей Барамба – Триединство проекта: Стейкхолдеры, Команда, Коммуникации (страница 8)
Коммуникации между членами команды и через сервисно-процессные отношения.
Работая над проектом, у РП есть возможность применять только два подхода к взаимодействию для постановки и контроля задач и получения результата:
– Делегирование и контроль
– Взаимодействие в рамках сервисно-процессных отношений
Делегирование задач и контроль их выполнения работают и подчинёнными обусловлены иерархией и субординацией, которая установлена в границах проектной команды. Для достижения эффективности руководитель должен использовать простые каналы связи – личная встреча, летучки, телефонные звонки и работа в изолированных от других участников, вне команды, информационных системах.
Участников коммуникации связывают не только должностные инструкции, в которых прописаны обязанности, но и желание достигнуть целей проекта и получить заслуженное вознаграждение в конце. Поэтому уровень сопротивления тут не высокий и легко может быть преодолён авторитетом РП или авторитарным решением с контролем обязательного его исполнения.
Сервисно-процессные отношения – это модель взаимодействия между командой проекта и другими функциональными подразделениями, в которой одна сторона (поставщик услуг, провайдер) предоставляет определённые сервисы или услуги другой стороне (клиенту) в рамках чётко определённых процессов. И РП с командой проекта в таких отношениях выступает клиентом на ровне с другими сотрудниками компании. Это накладывает ограничения на способы контакта и возможности управлять сроками и приоритетами. Эти взаимодействия строятся на основе договорённостей о качестве обслуживания и прямых указаний от руководителя функционального отдела о приоритетах и сроках выполнения задач.
Как я писал ранее10 внутри команды проекта возможны активности двух типов:
–Координация – постановка новых задач, изменение условий, согласование сроков. Такие взаимодействия возможны только между лицами наделёнными полномочиями на внесение корректировок.
–Взаимодействие – обмен информаций о уже согласованных задачах, без корректировки их сути. Особые полномочия тут не требуются, все операции идут в рамках стандартных полномочий и налаженных регламентов, низкий уровень ответственности за результат. Между рядовыми членами команды и «провайдерами» возможно только взаимодействие, а координация осуществляется только РП. Чуть позже, мы ещё вернёмся к роли РП в таких ситуациях.
В процессно-сервисных в среде исполнителей выделяют следующие роли:
Операторы – рядовые исполнители, им все равно каких целей достигает команда проекта и насколько важен продукт. Для них главным является соблюдение правил – запрос должен поступить через правильный интерфейс, содержать все необходимые данные и согласования что бы быть обработанным.
Типовая ошибка – когда, рядовые члены команды пытаются спорить и требовать от операторов быстрее решить вопрос или без соблюдения стандартных требований. Хуже всего, когда РП требует это делать своих подчинённых, не понимая природы вещей.
Спорить с ними бесполезно и неэффективно, ведь «закон» на их стороне. Они выполняют свою функцию, подчиняются и отчитываются за свои действия только своему непосредственному начальнику.
1.5. Процессно- сервисные отношения
В процессе реализации проекта может оказаться, что необходимо один раз обойти процедуру, когда стандартные сроки и приоритеты категорически не устраивают, и несут серьёзные риски для проекта. Тогда необходимо РП организовать корректное взаимодействие.
Поэтому в таких отношениях выделяют две управляющие роли «Менеджер процесса» и «Владелец процесса»
Менеджер процесса – это специалист или роль, отвечающая за планирование, координацию, контроль и оптимизацию работы рядовых специалистов. Это может быть старший смены, супервайзер, ведущий юрист. Именно к «Менеджеру процесса» можно обратиться один раз за длительный период и попросить отойти от сложившихся правил и сделать исключение. От налаженности контакта, харизмы и лидерских качеств РП зависит результат общения.
Владелец процесса – это специалист или роль, ответственного за управление, развитие и улучшение конкретного бизнес-процесса. Он обладает полномочиями и ответственностью за эффективность выполнения процесса, его соответствие заложенным в него целям и постоянное совершенствование. Владелец процесса может внести корректировки в регламенты, сменить каналы связи и инструменты, используемые операторами. Менеджер процесса в первую очередь подчиняется указаниям и распоряжениям созданного документа «Владельцем процесса».
Владелец процесса и РП контактируют в такие моменты, когда в целом взаимодействие между командой проекта и функциональным подразделением не устраивает РП. В такие моменты может понадобиться пересмотреть для всех обращений в функциональное подразделение:
– состав уполномоченных для создания новой задачи;
– сроки выполнения;
– набор предварительных требований к задачам, которые необходимо соблюсти инициатору;
– канал связи, по которому должна поступать задача;
– цепочка согласования.
Как правило, РП, для ускорения достижения целей и упрощения работы, согласовывает упрощённый формат и более приоритетную обработку. Вот несколько примеров:
– Разрешение брать на исполнение задачу по оплате счета только по устному согласованию ГД переданному РП через email, не дожидаясь визы в специальной системе;
– Создавать учётные записи и предоставлять доступ по запросу от старшего разработчика по почте, без заполнения формы сотрудником отдела кадров в день поступления заявки, вместо трёх рабочих дней;
– Выдавать оборудование со склада членам команды в день формирования запроса, а не на следующий рабочий день;
– при контроле посещаемости не учитывать приход и уход с работы из системы СКУД для членов команды проекта.
Для того что бы легитимизировать11 новые правила работы с функциональным подразделением, необходимо что бы владелец процесса внёс необходимые изменения в уже налаженные процессы. Как правило процесс изменения в документах и инструкциях имеет регламентированный способ внесения предложения, рассмотрения и публикации новой версии. Надо иметь в виду, что для РП должно быть не важно, как это произойдёт – будет написанная новая версия регламента или будет достаточно e-mail в котором будет указано что все заявки от команды принимать в особом формате. Главное, чтобы в следующий раз, когда он или член команды проекта обратиться к специалистам с новой задачей, то она будет обработана в рамках новых параметров. Важно помнить, что изменения условий должны касаться только обращений со стороны членов команды проекта, а не всей компании в целом.
Понимая законы и принципы взаимодействия в сервисно-процессных отношениях РП может правильным и эффективным путём воздействовать на сроки и уровни исполнения задач, выполняемых вне границ команды проекта.
Взаимосвязь между эффективными коммуникациями и критериями успеха проекта
Из учебников по проектному управлению мы знаем, что – критерии успеха проекта – это стандарты, по которым проект будет оцениваться в конце, чтобы решить, был ли он успешным в глазах заинтересованных сторон12. Эти критерии служат измеримыми показателями эффективности, позволяющими объективно оценить результативность проекта в соответствии с заранее установленными требованиями и ожиданиями, сформулированными на этапе планирования. Выделяют критерии, связанные с управлением проектами и критерии, связанные с конечными результатами.
Какая же роль коммуникаций и взаимосвязи? Все просто – ясное и своевременное общение способствует правильному пониманию целей, требований и ожиданий всеми участниками.
С моей точки зрения коммуникаций в области критериев успеха делятся на 4 этапа:
Этап 1: Формирование и согласование целей
Этап 2: Демонстрация успеха
Этап 3: Финальное подтверждение
Этап 4: Опционально. «Послепроектная поддержка».
Давайте их разберём поподробнее.
Этап 1: Формирование и согласование целей
Это самый важный этап, где закладывается основа всего. Коммуникация здесь – это не разовая презентация, а интенсивный диалог. Задача – перевести размытые пожелания ("сделать удобный интерфейс") в измеримые критерии ("90% тестовой группы выполняет ключевой сценарий менее чем за 3 клика"). Успех этого этапа – это не просто подписанный документ, а общее понимание у команды и стейкхолдеров, что именно и почему будет считаться победой. Здесь ключевые вопросы – "как мы это измерим?" и "что случится, если мы этого достигнем?". Только когда ответы на эти вопросы ясны и приняты всеми, проект получает чёткую карту для движения вперёд.
Этап 2: Демонстрация успеха в процессе проекта
Это не просто отчёты "работа идёт", а постоянная сверка с изначальными критериями. На языке бизнеса: "Мы договорились, что успех A измеряется метрикой B. На нашей текущей версии метрика B показывает рост на 15%. Вот график, вот тестовые данные". Важно говорить на языке целей, а не просто задач: не "мы разработали 10 экранов", а "мы реализовали пользовательский поток, который увеличил конверсию на этапе регистрации".
Этап 3: Финальное подтверждение
Момент истины, когда происходит формальное закрытие проекта или этапа. Коммуникация здесь – это церемониальный акт, который ставит точку. Вы представляете итоговый отчёт, где ключевые показатели (KPI) напрямую сопоставляются с целями из Этапа 1. Это презентация не проделанной работы, а достигнутого результата. Фраза "Мы выполнили все 100 задач" слабее, чем "Мы достигли всех трёх согласованных целей проекта, что подтверждается вот этими итоговыми данными". Это превращает закрытие проекта из бюрократического акта в подтверждение успеха.