Comments 45
Стало непонятно зачем
Интересно, а как решить вопрос с тем как собрать представительную выборку для группы в реальном проекте (в вашем случае папа, мама, сын, бабушка, кот)? Или это всегда лотерея и кто во что горазд в зависимости от культуры и процессов в компании?
Насколько я понимаю всё идет от А.
У А появляется требование. В процессе обсуждения с командой выясняется кто будет R, кто может C и кого надо I.
В статье говорится, что надо использовать Роли, а не Имена. Это выглядит плохой идеей. Потому что задачи идут не от Роли А, а от конкретного человека, у которого по какой-то причине есть требование это А получить. И если завтра *bus factor* и придет новый человек на туже должность - далеко не факт что А останется актуальным.
В случае бас фактора никакого "передали ответственность по умолчанию на нового человека с той же ролью" очевидно не работает и в любом случае придется пересматривать столбец связанный с этим человеком.
У меня так новоиспеченный техдир чуть не отъехал по здоровью, т.к. многие проекты мы завязали на него, а не на роль. Техдир сначала был тимлидом, компания начала расти и тимлид стал техдиром. В роли тимлидов оказались другие ребята, но они не смогли забрать задачи, техдир зашивался, мы срывали сроки.
Но вы правы, что «роль» должна коррелировать с «именем». Это и про вовлеченность, и про компетентность. Но все же, рисовать роль под одного человека — очень рискованно.
=======
Еще дополню.
Я писала выше, что в матрице «задача/таск», это вроде значимого этапа проекта. Иллюстрация с семьей может немного путать.
Если совсем докапываться, то команда под названием «семья», делает проект под названием «выезд на дачу», где есть этап «сбор и подготовка провизии», «транспортировка», «интерактивно-развлекательный модуль» и т.п.
К примеру, роль «Папа» — глава семьи, с пулом скиллов и обязанностей. Тогда Папа был бы «A» в задаче(этапе) «транспортировка»; при чем Папа вполне мог бы делегировать конкретную фичи в проекте «прогреть машину» или «выкопать машину из сугроба» Сыну, т.к. Сыну хватило бы на это компетенций.
Для абстракных процессов надо использовать Роли, а для реального проекта Имена.
Если вы под «представительной выборкой» имеете в виду, какие должны быть роли в проекте вместо Мамы и Папы, то это по команде смотрится, как я понимаю.
Типа собрались делать проект. Поняли из чего проект состоит (этапы раз, два, три); поняли, что за скилы нужны, чтобы эти этапы реализовать; поняли у кого эти скилы есть (инженер, разработчик, дизайнер, артдир, манагер, аналитик); прописали роли и проверяем, а действительно ли все эти люди в проекте нужны; или наоборот, точно ли мы никого не забыли.
Выглядит очень интересным инструментом. Спасибо.
Инструмент интересный. Понятно, что упрощений много, но лучше, чем просто список "ответственных" через запятую без уточнения ролей.
Но вот единственное, что хочется прямо обязательно уточнить - это разделить "C" на собственно консультантов ("спросим у бабушки совета, какой горошек взять") и согласующих лиц ("обязательно согласуем марку горошка с бабушкой, т.к. она очень придирчива к выбору данного продукта, и пока бабушка не согласовала - не купим"). А лучше ещё и собственно консультантов - на обязательных ("даже если сами можем выбрать горошек - всё равно послушаем по этому поводу мнение бабушки") и факультативных ("спросим бабушку, только если сами запутались в 20 сортах горошка"). Иначе порядок взаимодействия со всеми этими "C", мягко говоря, неочевиден и может привести к конфликтам.
Требования к горшочку это уже не С, а А. Может быть больше одного А(хоть это сразу не очевидно).
Первое правило RACI матрицы — только одна А для каждого этапа проекта.
A - все таки, отвечающий за результат, при этом в горшочках он может не шарить.
C - следует понимать широко, не просто возможность опциональной консультации, но и ответственность за рекомендации, которые должны привести к нужному результату.
Так что бабушка - С.
Если С начинает что-то апрувить это уже А, даже если мы его так не называем.
Так С может совмещаться с А.
Что такое С? С это:
я не знаю где купить горшок
посмотри в магазине на углу
С не апрувит магазин. И не апрувит горшок. С рассказывает варианты решения и отвечает на вопросы в рамках своей компетенции.
Горшок апрувит А. Потому что А решает что задача выполнена правильно. Если А пофиг на горшок и есть еще кто-то, кому не пофиг у нас получается два А. Никак не может быть С тот кто что-то апрувит.
К примеру, за этап «согласование с заказчиком макетов» отвечает А. Но на самих стейкхолдерах не будет никакой ответственности. Именно А несет ответственность за согласование макетов и должен знать, что для этого надо сделать.
Это не имеет значения. Нам в рамках матрицы не важны критерии по которым А принимает задачу. Личное желание, требование закона, кто-то выше рангом.
Здесь же обсуждается ситуация, когда у нас бабушка горшок хочет другой. То есть в матрице есть еще кто-то принимающий результат.
Мы можем взаимодействовать с ним через А, но это выглядит как костыль, когда у нас уже есть конкретный апрувер в рамках матрицы. Впихивать костыль просто чтобы не было двух А у задачи?
Нет такого этапа «купить горшки», т.к. «купить горшки» — способ достижения. Допустим, мы покупаем горшки, чтобы посадить рассаду, т.е. это будет мелкий таск для этапа «Подготовка К Агрофитнесу», в большом проекте «Летнее Рабство В Усадьбе Для Заготовки Провианта На Голодную Зиму».
Бабушка шарит за горшки, она авторитетный источник. Мама тоже авторитетный источник и тоже шарит за горшки, только у нее чуть меньше опыта.
Кто будет А зависит от того, к кому потом всё семейство подойдет и скажет: «Где рассада? Че сажать? Как нет рассады? Мы же с голода теперь помрем.»
Т.е. по итогу, это тот, к кому зимой пойдет Папа, Сын и Кот за едой, на кого будут смотреть голодными глазами и кому будут мяукать голодным ртом.
Помните рекомендацию?
Лучше устанавливать A и R на минимальный соответствующий уровень.
Так что тут вероятно Мама будет A, а Бабушка будет C.
Разгоняемся. При назначении ролей, мы должны учитывать вовлеченность в проект и способности / возможности.
У Бабушки чисто статистически вероятность дотянуть до зимы меньше, с кого тогда спрашивать?
Да с С неразбериха. Даже в больших компаниях с PLM роль С зачастую считают вспомогательной хотя именно они определяют что и как R должен делать, а А - проверить. Потому что R - исполнитель, А - менеджер и только С носитель знаний.
Ну вот, Microsoft избавляется от Котика и вы тоже избавляетесь от котика.
Вот если бы рассматривали «создание уюта» как проект, то Кот вполне мог бы быть R с его скилами мурчания, лежания на коленках и тыканья мордочкой в ухо. Но в проекте «поездка на дачу» он оказался не нужен как ответственное лицо.
Согласен, но в контексте проекта нужно не забыть про управление рисками, так как котики не только мурчат и создают уют, но и шипят и мочатся на пол.
(Мое слабое место, видимо, пришла пора закрывать пробелы)
С котиками вы слабо можете контролировать выполнение их непосредственных служебных обязанностей (мурчать), т.к. они практически не поддаются дрессировке и заменить исполнителя обычно невозможно (рука не поднимется). Поэтому нужно особенно тщательно подходить к выбору исполнителя этой роли (котенка) :)
а что со Скрепышом?
оффтоп: Так вроде как остается Котик
«Я не ответственный, я — Responsible»
У моего отца когда-то была футболка с надписью "I'm very responsible. Everytime something goes wrong - I'm responsible!".
Я правильно понимаю, что "кот" был в девичестве "Питомец Шарик", поэтому его спрайт на картинке, и фраза "попал в проект через мур-мур" вызывают когнитивный диссонанс?
Инструмент в теории звучит красиво и интересно. Однако из моей практике он ни разу нам не пригодился... (про RACI марицу знали и понимали, как она работает). У нас реализовано много проектов небольших с очень коротким циклом Time2Market (от 2 недель до 2-х месяцев) Для каждого из них прописывать RACI - себе дороже (время - самый ценный ресурс), лучше это время посвятить развитию проекту(ам).
На проекте с сроком вывода в ОПЭ в 9 месяцев он тоже не зашел... Своего заказачика мы знали очень хорошо, как и он нас - наверное, это и помогло - на старте проекта договорились о "правилах игры" и никакого RACI нам делать не пришлось - все "неожиданные" вопросы решалось оперативно и в режиме онлайн.
Возможно, в RACI есть смысл на очень больших, длительных проектах и с высоким фактором неопределености (хотя бы в начальных его фазах).
Так что ограничения для применения инструмента есть, но за статью спасибо - подано интересно!
У меня просто пригорело с того, что в интернетах пытаются объяснить как пользоваться инструментом на пальцах, а в итоге чепуха получается.
По моему опыту, RACI полезен при составлении должностных инструкций.
Без привязки к проектам - можно наглядно изобразить кто и за что в принципе отвечает в процессе работы, как информация взаимно передается. Особенно это актуально для случаев, когда отделы никак на словах не могут договориться или регулярно спорят кто кому что должен. К сожалению, такое часто встречается.
Кстати, для перфекционистов есть еще такой вариант, как матрица "РАЗУ" (разделения административных задач управления). Там вообще гипертрофированное разделение ответственности между участниками.
вероятно, попал в проект через мур-мур
Бывает хрен выгонишь тех, кто попал через мур-мур, спасибо за статью, повеселили и инфу полезную дали
То есть, кота вы за человека не считаете? И за коньячком он у вас не гоняет и мышей не ловит? Стыдно, ей-богу, девушка. Лоток, кстати, финально контролирует тоже он. Только кот, и никто иной, может утверждать, достаточно ли он для него чист. Иной ведь при неправильной чистке могёт и промазать туалет то! А кто определяет вкусноту купленного мяса и правильность приготовленного шашлыка? Кто контролирует любой процесс в доме?
Сразу видно, - нет у вас кота, и - не было!
Тот самый момент когда бабушка — это ты. Узнал для себя интересный способ оптимизации. Спасибо автору.
За кота дизлайк. Сразу видно афтар редиска. Не надо так!
как раз сейчас будем на проектах обкатывать разные инструменты. Спасбо автор, попробую сос воей командой эту матрицу.
«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица