МАТРИЦА РОЛЕЙ ДЛЯ ПРОЗРАЧНОГО УПРАВЛЕНИЯ

Сегодня в рамках программы ИТ-MBA говорили о ролях и матрице ролей в проекте.
🔒 Посмотреть можно здесь. Все записи программ формата MBA доступны уровню Heavy metal или доступ к ним можно приобрести отдельно.
➖➖➖➖➖
Из ключевых тезисов по матрице ролей вообще:
1️⃣ Она должна быть. Если ее нет - то как люди работают? Матрица позволяет сделать процессы исполнения и управления прозрачными, коммуникации эффективными и не дублировать задачи, которые не нужно дублировать.
2️⃣ Матрица РОЛЕВАЯ, то есть, проектная. Потому что сущность ролей у нас только в проектах. Значит, матрица есть там, где проекты - в проектных офисах, в проектных командах, в матричной орг структуре.
3️⃣ Матрица динамическая, потому что проектные роли чаще всего изменчивы.
4️⃣ Матрица может быть хоть в какой форме, главное открытой и доступной - таблица, wiki, наклейки на шкафчиках.
➖➖➖➖➖
СТРУКТУРА МАТРИЦЫ
0️⃣ Нумерация, понятно.
1️⃣ Наименование роли и все возможные сокращения или как вы у себя это называете. Знаете ли, PO, HQA могут в разных компаниях оказаться кем-угодно.
2️⃣ Функциональное описание роли. Что вообще делает? Вот возьмем среднестатистическую неделю - чем занят этот уважаемый человек? Напишите кратко тезисами.
Знание и понимание функции другой роли повышает вовлеченность сотрудника и его уровень спокойствия. Когда я знаю, кто что будет делать в случае беды, мне более норм.
3️⃣ Приоритетная функция. Что эта роль делает в первую очередь? Вот все - завал. И ТЗ согласовать, и тещу встретить, и мир спасти, и на ретро сгонять в соседнее здание. Что в первую очередь будет делать роль, а что по остаточному принципу?
Это важно знать. Что я точно не могу попросить сделать или убедить сделать прямо сейчас? Эта информация снижает уровень внутренней манипуляции и давления власти.
4️⃣ Чего не должен делать. В решении критических инцидентов информация на вес золота! С кого мы не спрашиваем? Кто не должен лезть в решение не своих вопросов?
Как минимум, кого не приглашать на совещания по вопросам бюджета? Это сокращает интеллектуальные потери.
5️⃣ Что может сделать по желанию? Например, сотрудник прекрасно прекрасно разбирается в вине. Пусть выберет подарок для спонсора проекта. Или разработчик - бог сложных переговоров. Пусть идет и сам рассказывает про изменения в плане.
6️⃣ С кем согласовывает свои условия? Понятно, у кого просит разрешения.
7️⃣ Кому согласовывает? То есть, кому дает подтверждение условий для принятия решений?
В проекте нет иерархии, и согласование не сопряжено с уровнем власти и влияния в рамках проекта. Поэтому эти два пункта всегда вызывают легкое опьянение.
8️⃣ Владельцем каких данных является? К кому мы пойдем, чтобы получить чистые данные по какому-то аспекту работы?
9️⃣ RPI. Ролевые показатели эффективности. По каким метрикам мы будем оценивать эффективность роли?
Настоящую (значимую для проекта) эффективность, чтобы еще какой-то анализ иметь возможность сделать. Тут может быть 1-3-5 метрик. Ну 2 и 4 тоже может быть.
В конце можно указать ФИО, почту, телефон, приметы.
➖➖➖➖➖
ЧТО СДЕЛАТЬ СЕЙЧАС
1️⃣ Провести диагностику ролей - все ли на месте? Все ли знают свои роли? Никто ли ничего не попутал?
2️⃣ Провести оценку знаний своего функционала - что должен делать, чего не должен, что должен делать в первую очередь - совпадает ли знание людей с тем, чего мы от них ожидаем?
3️⃣ Провести оценку знаний смежного функционала - все ли знают, кто чем занимается в команде? К кому по каким вопросам обращаться?
4️⃣ Проверить на новичке. Просто дать квест-задание - получить конкретные данные, например, и внести их в систему (которой еще нет или которой уже никто не пользуется). Что будет на выходе?
5️⃣ Дать возможность самим сотрудникам внести корректировки в описание своих ролей. Вы же не можете быть уверены в том, что сильно хорошо разбираетесь в проектных ролях, не так ли?