Триединство проекта: Стейкхолдеры, Команда, Коммуникации

Обратная связь по

COIN

Что бы лучше научиться давать обратную через сообщения, письменные или вербальные, хорошей практикой является применение предоставления обратной связи по COIN. Модель COIN — это акроним, последовательно описывающий четыре ключевых этапа предоставления обратной связи: Контекст (Context), Наблюдение (Observation), Влияние (Impact), Следующие шаги (Next steps).

С- Контекст: Цель — обозначить тему и ситуацию. Например, начать с фразы «Я хотел бы обсудить с тобой нашу вчерашнюю встречу с начальником отдела продаж, чтобы вместе разобрать детали".

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

О - Наблюдение

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

Говоря про «другие», хотел бы заметить, что общественное мнение может выступить мощным усилителем обратной связи — оно придаёт ей вес, и избавляет РП от сбора серьёзной доказательной базы. Ведь в головах людей, в отличии от персональной оценки, коллективное суждение воспринимается как объективный "барометр" качества действий.

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

I - Влияние

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

N- Следующие шаги

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

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

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

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

Например, для члена команды который целеустремлен, нетерпелив, прагматичен, ценит эффективность и контроль можно сократить введение и оперируя цифрами сделать уклон на влияние и решение:

Контекст: Сразу к сути.

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

Влияние: Акцент на влияние на цель, KPI, скорость, бюджет.

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

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

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

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

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

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

COIN прекрасно работает «сверху вниз» и «снизу вверх»:

Сверху вниз (от руководителя к сотруднику): Использует COIN для постановки задач, корректировки поведения, оценки результата. Основный упор демонстрация и закрепление власти, и формирование ощущения партнерства.

Снизу вверх (от сотрудника к руководителю или системе): Это очень важный вектор способствующий улучшению процессов. Главное, поделиться с сотрудниками о том как COIN работает, как правильно давать обратную связь по этой методике и создать у членов команды ощущение безопасности и того, что РП прислушается к их мнению. Тогда сотрудник, используя упор на «Наблюдение и «Влияние», может предоставить РП важную информации о неэффективности инструмента или управленческом решении.

Коммуникации между членами команды и через сервисно-процессные отношения.

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

- Делегирование и контроль

- Взаимодействие в рамках сервисно-процессных отношений

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

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

Сервисно-процессные отношения — это модель взаимодействия между командой проекта и другими функциональными подразделениями, в которой одна сторона (поставщик услуг, провайдер) предоставляет определённые сервисы или услуги другой стороне (клиенту) в рамках чётко определённых процессов. И РП с командой проекта в таких отношениях выступает клиентом на ровне с другими сотрудниками компании. Это накладывает ограничения на способы контакта и возможности управлять сроками и приоритетами. Эти взаимодействия строятся на основе договорённостей о качестве обслуживания и прямых указаний от руководителя функционального отдела о приоритетах и сроках выполнения задач.

Как я писал ранее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 задач" слабее, чем "Мы достигли всех трёх согласованных целей проекта, что подтверждается вот этими итоговыми данными". Это превращает закрытие проекта из бюрократического акта в подтверждение успеха.

Этап 4: Опционально. "Послепроектная поддержка"

Часто упускаемый из виду, но критически важный для долгосрочного доверия этап. Его суть — показать, что успех проекта — не сиюминутная победа, а устойчивый результат. Коммуникация здесь сводится к периодическим (раз в квартал) лаконичным дайджестам: "Спустя 6 месяцев после запуска, ключевые показатели, заложенные в проект (NPS, время выполнения операции), стабильно держатся на целевом уровне. Проект продолжает приносить ценность". Это закрепляет вашу репутацию как команды, которая не просто сдаёт "коробку с кодом", а создаёт рабочие решения.

Формирование схемы коммуникаций и её анализ

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

Шаг 1. Выписать все инструменты общения, которые используются в проекте. Определите ключевые и вспомогательные.

Само по себе упражнение видится не сложным, достаточно просто перечислить все развёрнутые системы в Компании, в которых ведётся активная работа командой, почтовые клиенты и мессенджеры. Главное не забыть указать облачные сервисы, файловый сервер, базу знаний и список мессенджеров, которые РП уже видел в общении внутри команды или с заказчиком. Так же внутри одной системы могут быть сразу несколько инструментов для совместной работы, и их надо разделить. Например, Битрикс24 для новых задач, и Битрикс24 - Чат для общения, у вас должно в списке получиться две строки.

Шаг2. Укажите доступность в данном инструменте информации – могут ли не члены команды видеть или создавать сообщения?

Данная информация потребуется для последовательности анализа и оптимизации на следующих шагах.

Шаг 3. Укажите имена членов команды, которые точно в них работают

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

Шаг 4. Проведите оптимизацию списка и уберите избыточные по вашему мнению инструменты для определённых активностей.

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

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

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

Например, такие:

В тикетной системе, следует создавать задачи, для их выполнения членами команды проекта, такие как:

- В продукте фиксируется сбой работы

- Продукт работает не так, как ожидается

- Требуется помощь в настройке продукта на локальном рабочем месте

- Предоставления доступа к другим разделам продукта

- Настройки смартфонов или домашних ПК для работы с продуктом

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

Это могут быть:

- добавление нового функционала в продукт

-обсуждением проблем или поиск нового технического решения;

-изменения текущих процессов;

-заполнение и создание документации

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

Ещё один пример. Огромный зоопарк на рабочем месте с программной средой для проведения видеоконференций. Члены команды в зависимости от своего «настроения» или удобства могут инициировать собрания в той среде, где им удобно. И каждому члену команды приходится держать установленными на своих ПК множество приложений, ИТ службе обеспечивать их обновление, сопровождение, написание инструкций.

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

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

Шаг 4. Продумайте каким образом можно «регламентировать» работу в ключевых системах.

Определите тип информации, который в неё вносится и из неё черпается. Кто уполномочен вносить данные, а кто только читать.

Шаг 6. Проведите анализ используемых лицензий для программных продуктов и проведите оптимизацию.

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

Формирование устойчивого и единого словаря, залог успешного проекта

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

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

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

Повышение эффективности: Чёткое понимание терминов способствует более быстрому и точному обмену информацией, что ускоряет процесс принятия решений.

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

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

Данный словарь мог бы иметь следующие разделы:

Общепринятые термины – описание основных терминов, описание прав и обязанностей ролей

Только внутри команды – закрытая от остальных часть словаря, содержит в себе термины, формулы и «жаргонизмы» используемые и понятные только внутри команды. Например, специальные формулы, которые сокращённо описывают алгоритм действий - «Поиграй в больную графиню…» или «Быстрые свидания». 13

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