Читать книгу Триединство проекта: Стейкхолдеры, Команда, Коммуникации - Сергей Барамба - Страница 14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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