Что такое матрица raci
Матрица ролей и прав: техника BABOK®Guide для описания CRUD-операций при разработке ТЗ
В рамках обучения начинающих системных и бизнес-аналитиков сегодня разберем еще одну технику BABOK®Guide и ее практическое использование в разработке ТЗ и описании программных систем. Что такое матрица ролей и прав, чем она отличается от RACI-таблицы, при чем здесь CRUD-операции с данными и в каком разделе технического задания на разработку информационной системы ее размещать.
Знай свои права: что такое матрица ролей и прав, и чем она отличается от RACI-таблицы: комментарии BABOK®Guide
Матрица ответственности, которую мы разбирали здесь, вместе с другими техниками BABOK®Guide для анализа стейкхолдеров, — это отличный инструмент документирования характера вовлечения организационной единицы в бизнес-процесс. RACI – это англоязычный акроним от основных видов участия в процессе:
Эти 4 роли в матрице ответственности могут назначаться отдельным людям, структурным подразделениям или целым организациям. В качестве иллюстрации рассмотрим процесс предпроектного обследования перед заключением договора на разработку ПО для конкретных бизнес-потребностей. Например, нужна интеграция имеющейся на предприятии системы электронного документооборота с внешним порталом для получения исходных данных и выгрузки отчетов. Для этого Заказчик обратился в ИТ-компанию по разработке ПО. Клиентский менеджер принял заявку и завел карточку клиента в CRM-системе, а менеджер проекта привлек аналитика и ведущего разработчика, чтобы они оценили реализуемость, а также стоимость и сроки выполнения работ. В этом кейсе аналитик будет совмещать обязанности системного и бизнес-аналитика, работая как в области проблем, так и в области решений.
Таким образом, исполнителем предпроектного обследования является аналитик, который уточняет бизнес-потребность, а также возможности и ограничения интегрируемых систем. В технических тонкостях его консультирует ведущий разработчик, а представитель Заказчика выступает экспертом домена, проясняя особенности предметной области. Клиентский менеджер является связующим звеном между руководством 2-х предприятий (компании Заказчика и Исполнителя), поэтому должен быть проинформирован о результатах предпроектного обследования, чтобы внести запись о заключении договора или прекращении работ в CRM-системе. RACI-матрица для рассматриваемого кейса будет выглядеть так:
| Участник | Роль |
| Менеджер проекта | A |
| Аналитик | R |
| Ведущий разработчик | C |
| Представитель Заказчика (эксперт предметной области, SME) | C |
| Клиентский менеджер | I |
Хотя эта RACI-таблица достаточно четко определяет ответственность участников бизнес-процесса, она не показывает детали выполнения отдельных операций, важные для реализации. В частности, что именно может делать та или иная роль с конкретными артефактами, под которыми чаще всего понимаются различные виды данных. Например, во внутренней системе управления проектами Менеджер проекта может создавать карточку проекта, изменять и просматривать ее содержимое, и даже удалять. Остальные участники (аналитик, ведущий разработчик, SME и клиентский менеджер) могут лишь просматривать эту информацию.
Аналогичную детализацию можно привести и для данных, которые связаны с проектом: задача и документ. В следующей таблице показаны возможности различных пользователей по работе с этими видами данных. Здесь и далее под видом данных будем понимать сущность доменной области подобно классу в объектно-ориентированном подходе.
Пример матрицы ролей и разрешений
Такая таблица, которая показывает, какими правами обладает конкретная роль на отдельные виды данных, называется матрица ролей и прав (или разрешений). Профессиональное руководство к своду знаний по бизнес-анализу BABOK®Guide упоминает эту технику как наглядный и понятный способ определение ролей с привязкой к действиям. При этом BABOK отмечает, что на высоком уровне абстракции роли и их ответственность чаще определяются в виде RACI-матрицы, а на более детальном, в частности, на уровне информационных систем и работы с конкретными артефактами – в виде таблицы CRUD-операций. Что это такое и как она используется аналитиками при разработке ТЗ и описании программных систем, мы поговорим далее.
Методика RACI: оптимизация распределения полномочий и ответственности
Делегирование является неотъемлемой частью роли менеджера, поэтому определение ролей и обязанностей в начале проекта очень важно. В обязанности менеджера лежит определение ожиданий людей, участвующих в проекте с самого начала.
Проекты требуют участия многих людей, но как избежать ситуации, когда люди борются против друг друга при осуществлении определенной задачи. Столь же сложным является ситуация, когда никто не берет на себя ответственность и не принимает решения. Как люди должны понимать уровень собственной ответственности? К кому можно обратиться при возникновении вопроса? Кто должен быть проинформирован при осуществления задачи или процесса? Применение модели RACI может помочь ответить на все эти вопросы.
Матрица RACI представляет собой простой инструмент, используемый для определения ролей и обязанностей и избежания путаницы при исполнении задач или процессов. Используется при управления проектами и для показа обязанностей в состояниях «AS-IS» и «TO-BE».
Матрица ответственности представляет собой особый метод определения функциональных областей, ключевых направлений деятельности, критериев принятия управленческих решений, где существуют неясности. Все разногласия, возникающие в ходе данного процесса, могут быть вынесены на общее обсуждение и впоследствии разрешены путем принятия коллективного решения.
Подобный подход позволяет менеджерам активно участвовать в систематическом процессе описания деятельности, решений, которые должны быть осуществлены, а также прояснить обязательства и обязанности, которые несет каждый участник по отношению к сфере занятости и управленческим решениям. Подобный подход позволяет содействовать естественному рабочему процессу и согласованному распределению ролей и ответственности внутри группы. Основные преимущества использования матрицы ответственности заключаются в том, чтобы прояснить разграничение ролей и ответственности как индивидуальных, так и в команде. Зачастую внутри группы возникает недопонимание, отсутствие четкой специализации и расплывчатое представление о собственных полномочиях, что приводит к ослаблению командного духа и, как следствие, к низкой производительности. Поэтому определение сфер ответственности и полномочий повышает результативность деятельности как каждого работника, так и группы в среднем.
В частности, матрица распределения ответственности дает возможность избежать дупликации выполняемых функций в коллективе. При возникновении спорных ситуаций руководитель процесса может ссылаться на конкретное лицо, отвечающее за цепочку процесса, где возникло разногласие или ошибка. Таким образом, в коллективе устанавливается более открытый метод коммуникации, основывающийся на консультировании и информировании участников процесса.
Таблица 1. Резюме: Критические вопросы модели
| Распределение ролей и обязательств | — Для лучшего понимания собственных полномочий — Для повышения эффективности коммуникаций |
| Ответственность | — Для разъяснения, кто и кому подотчетен |
| Обязательства | — Для выявления полномочий |
| Ответственность за работу | — С целью наделить сотрудников полномочиями, необходимыми для выполнения конкретной работы |
| Роль менеджера среднего звена | — Ускорить координацию выполняемых процессов с поставленными задачами |
| Утверждение | — Во избежание неопределенностей при многоразовой отчетности |
Указания к построению матрицы
| «R» Исполнитель (Responsible) | Лежит ответственность за выполнение поставленной задачи. На каждую задачу должно приходиться не менее одного Исполнителя. Степень ответственности распределяется Утверждающим |
| «A» Утверждающий (Accountable) | Перед ним производится отчет в полученном результате, имеются полномочия, как принимать, так и отвергать предложения, накладывать на них вето. На каждый проект выделяется не более одного Утверждающего |
| «С» Консультант (Consulted) | Консультация и согласование принимаемых решений. Характеризуется двусторонней связью между подразделениями |
| «I» Информируемый (Informed) | Поступает конечная информация о проделанной работе. Характеризуется односторонней связью |
Матрица ответственности выстраивается в шесть этапов:
Основными принципами принятия решений с помощью RACI являются:
Вертикальный анализ (по функциональным ролям) позволяет выявить соответствующие проблемы: Если у Вас получилось:
При горизонтальном анализе рассматриваются действия Если у вас получилось, что
Подводя итог, стоит отметить, что матрица распределения ответственности является важным элементом успешного планирования рабочего процесса. В ходе ее грамотного использоваться должна повыситься производительность на проекте, достигаемая за счет наличия Утверждающего. При умелом построении рабочего процесса сформируется сильная команда, состоящая из грамотных и натренированных игроков, способных предлагать нестандартные подходы к принятию решений. Как результат можно будет выстроить более продуктивную систему коммуникаций между всеми участниками благодаря разработке интерфейса связи (Консультант и Информированный).
Список литературы
1. Андерсен Б. Бизнес-процессы. Инструменты совершенствования. — М.: РИА «Стандарты и качество», 2014.
2. Деминг В. Эдвардс. Выход из кризиса. — Тверь: Альба, 2009.
3. Дрожжинов В. Реинжиниринг бизнес-процессов в компании // Ваш банкъ. Экономист. — 2012. № 2.
4. Друкер П.Ф. Практика менеджмента: Пер. с англ. — М.: Изд. дом «Вильямс», 2011.
5. Ефремов В.С. Организации, бизнес-системы и стратегическое планирование //Менеджмент в России и за рубежом. — 2013. — № 2.
6. Кальянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнес-процесса». — М.: СИНТЕГ, 2012.
Развитие матриц ответственности от RACI к РАЗУ
Сегодня вряд ли можно представить любой проект без использования матрицы ответственности, и это естественно. История применения инструмента насчитывает чуть более полувека. Довольно приличный срок, чтобы аналитическая таблица МО прочно утвердилась в качестве управленческого стандарта. Базовым методом считается матрица ответственности по методу RACI. Традиционный подход и рекомендации данного метода были рассмотрены ранее. Однако помимо RACI в современной практике возникли новые разновидности матриц, и они как средства управления значительно ушли вперед. С этих позиций представляет интерес матрица РАЗУ, с которой и приглашаю вас познакомиться в итоге.
Классический способ построения матрицы
МО применяется в различных доктринах управления: функциональной, процессной и проектной. Проектное управление предъявляет к процедурам использования матриц особые требования. Для построения их применяется табличная форма, в ее строках указываются операции, работы, этапы и даже фазы проекта, а в столбцах – роли в проекте, функциональные должности, подразделения и т.п. В матричных ячейках проставляются крестики или условные знаки, обозначающие вид ответственности.
Как было отмечено, для разработки МО традиционно используется методика RAСI: Responsible (отвечает), Accountable (утверждает), Consult before doing (консультирует), Inform after doing (информируется). Модель RACI широко распространена в проектной деятельности. Более того, эта форма рекомендована руководством PMBOK в качестве матричных диаграмм.
Данный подход, на мой взгляд, вполне лаконичен в силу того, что здесь отсутствуют такие условные знаки, как «исполнитель» и «ознакомлен», ответственность которых установить крайне затруднительно. Впрочем, и для «консультирует» также непросто определить ответственность, но все-таки это возможно. Поэтому считаю RACI наиболее уравновешенной среди аналогичных МО. Ниже представлен пример такой матрицы.
Методика RACI предполагает, что перед заполнением МО созданная команда управления проектом разработала иерархическую структуру работ, расписала проектные роли по участникам команды. На отдельном заседании производится разработка таблицы, после чего готовая матрица подвергается перекрестному анализу по следующему составу вопросов:
Типовые матрицы и их разновидности
Модель одноранговой МО, где присутствует только знаки «R» или крестики, фиксирующие ответственность члена команды, имеет ценное преимущество перед остальными типами. Такая матрица – самая рабочая и легкая в применении для контроля результатов. То, что нельзя увидеть глубину участия других членов, на мой взгляд, к недостаткам отнести нельзя, потому что если применить и другие условные знаки, в геометрической прогрессии нарастают вопросы, на которые ответить непросто. Ниже приведен пример такой простой МО.
В некоторых случаях матрица ответственности наглядно представляется в форме изометрической композиции (трехмерного графика). 3D-направление набирает популярность и в проектном управлении. Такой вариант МО предоставляет руководству компании возможность быстро сравнить глубину участия в проекте функциональных подразделений, задействованных в разных видах деятельности компании. Пример матричной трехмерной изометрии дан на следующем рисунке.
МО в модели RACI в определенных случаях рекомендуется разрабатывать по укрупненным блокам проектных мероприятий. Соответственно, и по столбцам в такой таблице представляются не конкретные участники команды, а задействованные организационно-структурные единицы компании. Вместе с тем, ответственность в этом случае возлагается на функциональных руководителей этих единиц в силу того, что ее должны адресно принять конкретные должностные лица. Далее представлен сокращенный пример МО по укрупненным блокам.
Важно помнить! Методика распределения и контроля ответственности в МО предписывает менеджеру соблюдать меру соразмерности матрицы этапу и уровню проектной задачи. На этапе разработки концепции проекта лучше всего применить МО по укрупненным блокам работ, пусть с поливариантной ответственностью, но в упрощенном варианте.
Если проект небольшой, а его задача несколько тяготеет к бизнес-процессу, рекомендую использовать одноранговую упрощенную матрицу. Если пользователями матричной модели являются руководители компании, а задействованных в проекте подразделений достаточно много, то нагляднее будет применить матричную трехмерную изометрию. А если же мы имеем дело с развернутым детализированным планом работ, принятым к распределению ответственности, тут, пожалуй, и классическую RACI будет расписать полезно, но без фанатизма. Кто же любит увлекаться творчеством, однозначно высоко оценит матрицу РАЗУ (разделения административных задач управления). Ниже представлен пример ее фрагмента.
Матрица разделения административных задач управления
Мне весьма импонирует замысловатый инструмент – матрица РАЗУ. Трехранговая, двухтабличная МО, позволяющая оценивать сравнительную трудоемкость всех операций и сравнивать ФОТ с экспертной оценкой результатов, а также многое другое. Просто любо-дорого и для PM, и экономиста-трудовика, курирующего проекты. Здесь привожу пример карты логических аспектов РАЗУ с тремя направления привязки.
Смотрю я на эту карту и вижу одно из изящных решений не только в проектном, но и в операционном, и даже общем менеджменте. Сами посудите: первый раздел идентифицирует тип принятия решения, второй – отграничивает функции управления друг от друга, а третий – форму участия в исполнении. Это так эффектно – соблюсти в сводном символе три объемных элемента самой сущности управления и исполнения.
Матрица РАЗУ – метод сложный, и от него никто не ждет простоты. Тем не менее, понять его не так трудно. Нужно вникнуть в содержание карты и выполнить несколько немудреных правил. Есть разрешенные сочетания знаков-символов, а есть запрещенные. Особенность этих правил в их безусловной обязательности.
Второй формой, включенной в метод РАЗУ, является так называемая таблица парного сравнения. Благодаря этой матрице достигается возможность оцифровки ответственности. Методика позволяет анализировать приведенные в первой таблице символьные значения и обеспечить вывод сравнительной трудоемкости представленных в ней видов.
Символы переименовываются в ряд К1, К2… К8 и попарно выстраивают в столбцах и в строках так, чтобы на пересечении одноименных ячеек всегда были проставлены «1», в другие ячейки сочетаний поставляются либо «2» (значимый), либо «0» (незначимый). Для равноценных символов устанавливается «1». Таким образом, по строкам в итоге получается значимость символа. Работа производится группой экспертов в форме индивидуальной оценки.
Благодаря полученным результатам, аналитик может вычислить:
Матрица РАЗУ, исходя из изложенного, состоит из двух таблиц и целого комплекса аналитической обработки данных и представляет собой системный инструмент оптимизации проектов и операционного управления. Применяя РАЗУ как информационный базис, вы расширяете возможности функционально-стоимостного анализа на основе сравнения оценок внутренней стоимости и эффективности структурных единиц.
Уважаемые коллеги, хочу донести мысль о том, что практика в применении матриц ответственности при управлении проектами – это тот бесценный опыт, который навсегда остается с РМ. Разнообразие инструментов МО в современной управленческой парадигме позволяет искать свои «ключики к замку» каждого ответственного ресурса, которого вы осмысляете под свои задачи. И чем сложнее проект, тем техничнее должны быть процедуры контроля ответственности. При осмотрительном применении матрицы РАЗУ и RACI обязательно принесут вам долгожданный успех.
Работа с проектом: этапы, особенности и артефакты
Начинаем серию статей для быстрого погружения в проджект-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь первый урок в текстовом виде — для тех, кому удобнее читать.
Этапы проекта
Любой проект состоит из четырёх этапов: инициализации, планирования, реализации и завершения. Рассмотрим каждый подробнее.
Инициализация. Заказчик приходит к проджект-менеджеру с запросом. Менеджер анализирует бизнес-идею (определяет содержание и длительность проекта), разрабатывает проектное задание и выполняет стратегическое планирование.
Планирование. Проджект-менеджер определяет, из каких специалистов будет состоять команда, каковы объёмы проекта, его этапы и контрольные точки для сверки с заказчиком. Также выявляет возможные риски и рассчитывает ресурсы.
Реализация. Проджект помогает команде создать конечный продукт или его часть — для этого отслеживает и контролирует каждый из этапов, решает проблемы, информирует заказчика о ходе проекта и управляет изменениями.
Завершение. Проджект-менеджер сдаёт продукт заказчику, оценивает уровень удовлетворённости клиента и приобретённый опыт. Фиксирует успехи, неудачи и их причины, чтобы стать эффективнее и избежать негативного опыта в будущем.
Проектные артефакты
Артефакты проекта — это физические носители информации, которые подтверждают договорённости и позволяют всем членам команды следить за ходом проекта. Например, договор, коммерческое предложение, техническое задание, сопроводительные документы, исполняемые файлы, исходные тексты, веб-страницы, файлы с данными и справочной информацией. При этом универсального набора артефактов не существует — на каждом проекте он свой.
Рассмотрим, как распределяются артефакты на каждом из этапов проекта. При этом от проекта к проекту набор будет немного разным.
Инициализация: техническое задание, коммерческое предложение, договор и приложение к нему, дополнительное соглашение.
Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.
Реализация: акт сдачи-приёмки работ, замечания и доработки.
Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.
Так могут выглядеть основные артефакты по IT-проекту:
Сбор артефактов
Проджект-менеджер собирает артефакты проекта во время согласования требований с заказчиком и уточнения деталей — лучше показаться дотошным и избежать недоразумений, чем поскромничать и недопонять клиента.
Проджект обсуждает требования с командой, чтобы быть уверенным, что каждый понял свою задачу и выполнит работу корректно. Это ещё один этап, на котором формируются артефакты проекта.
Проджект-менеджер согласовывает результаты с конечными пользователями — это подтверждает, что команда делает именно то, что нужно заказчику.
Результаты каждой встречи фиксируются — это позволяет избегать многих неприятных ситуаций. Например, если заказчик попросит разработать новую фичу, которая не была прописана в изначальном техническом задании, — будет возможность обсудить условия дополнительной оплаты и новые сроки. Клиент не сможет сказать, что он говорил о ней ранее и вы обещали реализовать её в рамках стандартной оплаты. Также это не позволит заказчику выставить одни требования, а затем сказать: «Я видел это совсем иначе». У вас всё зафиксировано!
После встречи проджект рассылает её итоги всем участникам проекта, а клиента просит подтвердить, что он тоже ознакомился с ними. Если он не отвечает, то менеджер не стесняется напомнить о письме.
Виды артефактов
Артефакты делятся на формальные и неформальные.
Формальные — обязательные, прописанные в договоре, на которых стоят реквизиты заказчика и исполнителя. Также к формальным артефактам относится документация и элементы, которые указаны в официальных документах. Если в договоре написано, что исполнитель обязан предоставить результаты исследования, то они будут формальным артефактом.
Неформальные артефакты — вся остальная информация: итоги переписок, сообщения в мессенджерах, записи с флипчарта, на котором команда фиксирует ход проекта, стикеры с канбан-доски и даже матрица RACI.
Виды заказчиков
Заказчиков принято разделять по двум принципам. Первый — по традиционному объёму документации, который необходимо вести по проекту. Второй — с точки зрения того, как происходит процесс взаимодействия до запуска проекта. В этой классификации выделяют четыре вида заказчиков:
Есть и другая категоризация заказчиков — по ней они могут быть внутренними и внешними. Внутренний заказчик — это смежный отдел. Если GeekBrains закажет IT-решение у отдела разработки, входящего в Mail.ru Group, то станет для него внутренним заказчиком — всё будет происходить в рамках одной компании. Если GeekBrains поставит задачу разработать IT-решение стороннему подрядчику, то выступит для него внешним заказчиком.
Зона ответственности заказчика
Работая в любом проекте, нужно понимать, к кому и с каким вопросом обращаться: что может решить заказчик, что руководитель, а когда стоит получить больше информации от команды. Чтобы не растеряться в самый неподходящий момент, на старте нужно распределить зоны ответственности. Один из классических инструментов для этого — матрица RACI.
Матрица RACI — это таблица, в которой проджект-менеджер по горизонтали вписывает зоны ответственности, а по вертикали — исполнителей и другие действующие лица на проекте (заказчиков, членов команды, подрядчиков). Этот инструмент помогает распределить ответственность ещё на этапах инициализации и планирования проекта.
В матрице выделяется четыре зоны ответственности: R — responsible (исполняет), A — accountable (несёт ответственность) C — consult before doing (консультирует до исполнения), I — inform after doing (оповещает после исполнения). Рассмотрим это на примере.
По горизонтали прописаны зоны ответственности, а по вертикали — действующие лица. Анна разрабатывает устав, а Бен несёт ответственность за выполнение этой задачи. Если у кого-то из членов команды появится вопрос про устав, он сразу поймёт, к кому обратиться.
Чтобы составить матрицу RACI, нужно выполнить следующие шаги:
При этом важно соблюдать основные принципы:
Удержать все эти вещи в голове непросто, но благодаря практике можно стать эффективным проджект-менеджером. Попробуйте начать свой путь в профессии с бесплатного курса GeekBrains. Желаем удачи!
Начинаем серию статей для быстрого погружения в проджект-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь первый урок в текстовом виде — для тех, кому удобнее читать.
Этапы проекта
Любой проект состоит из четырёх этапов: инициализации, планирования, реализации и завершения. Рассмотрим каждый подробнее.
Инициализация. Заказчик приходит к проджект-менеджеру с запросом. Менеджер анализирует бизнес-идею (определяет содержание и длительность проекта), разрабатывает проектное задание и выполняет стратегическое планирование.
Планирование. Проджект-менеджер определяет, из каких специалистов будет состоять команда, каковы объёмы проекта, его этапы и контрольные точки для сверки с заказчиком. Также выявляет возможные риски и рассчитывает ресурсы.
Реализация. Проджект помогает команде создать конечный продукт или его часть — для этого отслеживает и контролирует каждый из этапов, решает проблемы, информирует заказчика о ходе проекта и управляет изменениями.
Завершение. Проджект-менеджер сдаёт продукт заказчику, оценивает уровень удовлетворённости клиента и приобретённый опыт. Фиксирует успехи, неудачи и их причины, чтобы стать эффективнее и избежать негативного опыта в будущем.
Проектные артефакты
Артефакты проекта — это физические носители информации, которые подтверждают договорённости и позволяют всем членам команды следить за ходом проекта. Например, договор, коммерческое предложение, техническое задание, сопроводительные документы, исполняемые файлы, исходные тексты, веб-страницы, файлы с данными и справочной информацией. При этом универсального набора артефактов не существует — на каждом проекте он свой.
Рассмотрим, как распределяются артефакты на каждом из этапов проекта. При этом от проекта к проекту набор будет немного разным.
Инициализация: техническое задание, коммерческое предложение, договор и приложение к нему, дополнительное соглашение.
Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.
Реализация: акт сдачи-приёмки работ, замечания и доработки.
Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.
Так могут выглядеть основные артефакты по IT-проекту:
Сбор артефактов
Проджект-менеджер собирает артефакты проекта во время согласования требований с заказчиком и уточнения деталей — лучше показаться дотошным и избежать недоразумений, чем поскромничать и недопонять клиента.
Проджект обсуждает требования с командой, чтобы быть уверенным, что каждый понял свою задачу и выполнит работу корректно. Это ещё один этап, на котором формируются артефакты проекта.
Проджект-менеджер согласовывает результаты с конечными пользователями — это подтверждает, что команда делает именно то, что нужно заказчику.
Результаты каждой встречи фиксируются — это позволяет избегать многих неприятных ситуаций. Например, если заказчик попросит разработать новую фичу, которая не была прописана в изначальном техническом задании, — будет возможность обсудить условия дополнительной оплаты и новые сроки. Клиент не сможет сказать, что он говорил о ней ранее и вы обещали реализовать её в рамках стандартной оплаты. Также это не позволит заказчику выставить одни требования, а затем сказать: «Я видел это совсем иначе». У вас всё зафиксировано!
После встречи проджект рассылает её итоги всем участникам проекта, а клиента просит подтвердить, что он тоже ознакомился с ними. Если он не отвечает, то менеджер не стесняется напомнить о письме.
Виды артефактов
Артефакты делятся на формальные и неформальные.
Формальные — обязательные, прописанные в договоре, на которых стоят реквизиты заказчика и исполнителя. Также к формальным артефактам относится документация и элементы, которые указаны в официальных документах. Если в договоре написано, что исполнитель обязан предоставить результаты исследования, то они будут формальным артефактом.
Неформальные артефакты — вся остальная информация: итоги переписок, сообщения в мессенджерах, записи с флипчарта, на котором команда фиксирует ход проекта, стикеры с канбан-доски и даже матрица RACI.
Виды заказчиков
Заказчиков принято разделять по двум принципам. Первый — по традиционному объёму документации, который необходимо вести по проекту. Второй — с точки зрения того, как происходит процесс взаимодействия до запуска проекта. В этой классификации выделяют четыре вида заказчиков:
Есть и другая категоризация заказчиков — по ней они могут быть внутренними и внешними. Внутренний заказчик — это смежный отдел. Если GeekBrains закажет IT-решение у отдела разработки, входящего в Mail.ru Group, то станет для него внутренним заказчиком — всё будет происходить в рамках одной компании. Если GeekBrains поставит задачу разработать IT-решение стороннему подрядчику, то выступит для него внешним заказчиком.
Зона ответственности заказчика
Работая в любом проекте, нужно понимать, к кому и с каким вопросом обращаться: что может решить заказчик, что руководитель, а когда стоит получить больше информации от команды. Чтобы не растеряться в самый неподходящий момент, на старте нужно распределить зоны ответственности. Один из классических инструментов для этого — матрица RACI.
Матрица RACI — это таблица, в которой проджект-менеджер по горизонтали вписывает зоны ответственности, а по вертикали — исполнителей и другие действующие лица на проекте (заказчиков, членов команды, подрядчиков). Этот инструмент помогает распределить ответственность ещё на этапах инициализации и планирования проекта.
В матрице выделяется четыре зоны ответственности: R — responsible (исполняет), A — accountable (несёт ответственность) C — consult before doing (консультирует до исполнения), I — inform after doing (оповещает после исполнения). Рассмотрим это на примере.
По горизонтали прописаны зоны ответственности, а по вертикали — действующие лица. Анна разрабатывает устав, а Бен несёт ответственность за выполнение этой задачи. Если у кого-то из членов команды появится вопрос про устав, он сразу поймёт, к кому обратиться.
Чтобы составить матрицу RACI, нужно выполнить следующие шаги:
При этом важно соблюдать основные принципы:
Удержать все эти вещи в голове непросто, но благодаря практике можно стать эффективным проджект-менеджером. Попробуйте начать свой путь в профессии с бесплатного курса GeekBrains. Желаем удачи!