Управление проектами

Матрица ответственности: RACI, DACI, RAPID. Что использовать? Разница между RACI, DACI и RAPID — не в буквах или их количестве. А в том, какой подход для принятия решения они обеспечивают. RACI — для работы, а не для выработки решений. R (Responsible) — делает. A (Accountable) — отвечает за результат (всегда один). C (Consulted) — с кем советуются, консультируются. I (Informed) — кого информируют. RACI хорош, когда нужно показать, кто что делает в проекте. Но он не отвечает на вопрос, кто имеет право финального голоса или право вето. DACI — для быстрых решений. Аббревиатура расшифровывается так: D (Driver) — «двигатель». Тот, кто ведёт процесс принятия решения и следит за сроками. A (Approver) — «утверждающий». Один человек, у которого финальное слово. Он говорит «да» или «нет». C (Contributors) — «участники». Те, кто даёт входные данные и экспертизу до принятия решения. I (Informed) — «информируемые». Те, кого ставят в известность после того, как решение принято. DACI работает, когда решение нужно принять быстро и чётко. Если в строке появляется два Approver — это уже не DACI, а повод для применения RAPID. RAPID — для сложных решений с правом вето. Аббревиатура расшифровывается так: R (Recommend) — «рекомендующий». Тот, кто предлагает варианты и даёт обоснование. A (Agree) — «согласующий с правом вето». Тот, кто может сказать «стоп», но только по строго определённым основаниям (юридические, регуляторные, бюджетные ограничения). Не по настроению — а по мандату. P (Perform) — «исполняющий». Тот, кто реализует принятое решение. I (Input) — «предоставляющий входные данные». Тот, кого консультируют до принятия решения. D (Decide) — «решающий». Один человек, который принимает финальное решение после учёта всех входных данных и ограничений. RAPID нужен, когда решение высокорисковое и затрагивает несколько функций, у каждой из которых есть законное право сказать «стоп». Подведём итог: RACI — кто делает работу. DACI — кто решает, когда решение принимается единолично (Driver → Approver). RAPID — кто решает, когда есть несколько сторон с правом вето (Recommend → Agree → Decide). И в заключении: любой инструмент, включая матрицу ответственности, можно и нужно адаптировать под ваши проекты. Никто не запрещает вам взять за основу RACI и добавить нужные, с вашей точки зрения, роли. #УправлениеПроектами #RACI #DACI #RAPID #PMO #Ответственность

Как перестать быть секретарём и начать управлять проектом Открываете Jira, Project или любой другой инструмент — и начинается. Где задача? Почему статус не обновлён? Кто переместил тикет? Почему исполнитель не отметил прогресс? Проходит два часа. Вы ничего не управляли. Вы администрировали трекер. Знакомая ловушка. PM постепенно превращается в секретаря: вручную обновляет статусы, переносит тикеты, напоминает о дедлайнах, ищет потерянные задачи. Признаки того, что вы стали секретарём: Вы знаете номер каждой задачи, но не знаете, приближается ли проект к цели. Вы тратите больше времени на обновление статусов, чем на разговоры с людьми. Вы вручную собираете статусы для отчёта, потому что «в Jira всё неправильно заполнено». Вы ощущаете себя администратором, а не управленцем. Что делегировать: Обновление статусов. Это ответственность исполнителя, а не PM. Если команда не обновляет задачи — это вопрос дисциплины и договорённостей, а не вашей личной нагрузки. Перемещение тикетов. Настройте автоматические переходы по статусам. Если задача перешла в «В работе» — она должна двигаться сама, а не через вас. Сбор статусов для отчёта. Если вы собираете данные вручную — вы не управляете, вы стенографируете. Настройте дашборды и автоматические выгрузки. Напоминания о дедлайнах. Это задача самой команды и настроенных уведомлений, а не вашей памяти. Что автоматизировать: Автоматические переходы статусов на основе событий (например, pull request создан — задача в «Ревью»). Уведомления и напоминания для исполнителей и стейкхолдеров. Дашборды и отчёты, которые собираются сами и не требуют ручной сборки. Интеграции между инструментами (Project, Jira, Git, Confluence и т.д.), чтобы данные синхронизировались без вас. Как вернуть себе роль управленца: Сместите фокус с задач на цели. Вас должно волновать не то, сколько тикетов закрыто, а то, приближается ли проект к результату. Работайте с людьми, а не с трекером. Ваша задача — договариваться, снимать препятствия, управлять рисками, а не перемещать карточки. Настройте правила игры. Договоритесь с командой: кто и когда обновляет статусы, как мы понимаем «готово», что считается блокером. И следите за соблюдением правил, а не за каждым тикетом. Делегируйте администрирование. Если рутины слишком много — настройте автоматизацию или передайте часть задач администратору проекта. Задайте себе вопрос: «Если я не буду трогать Project / Jira неделю — что сломается?» Если ответ «ничего» — значит, система работает. Если «всё» — значит, вы всё ещё секретарь. Главное: Jira — это инструмент. Он не управляет проектом. Управляете вы. Если вы тратите больше времени на обслуживание трекера, чем на управление людьми и результатами, — пора что-то менять. #УправлениеПроектами #Jira #PMO #ТаймМенеджмент #Автоматизация

Стейкхолдеры: как выжить среди политических игр Проект — это не только задачи, сроки и бюджет. Это ещё и люди. С интересами, амбициями, страхами и скрытыми повестками. И чем крупнее проект, тем сложнее политическая карта. Заказчик говорит одно, его заместитель — другое. Функциональный руководитель «поддерживает» проект, но не выделяет людей. Спонсор молчит, а потом неожиданно спрашивает: «А почему мы ещё не закончили?» И это не саботаж. Практические приёмы работы с конфликтующими интересами: Составьте карту стейкхолдеров. Не формальную, а рабочую. Кто влияет на решения? Кто блокирует? Кто выигрывает от успеха проекта? Кто проигрывает? У кого есть скрытый интерес? Выявите скрытые повестки. За красивыми словами о «стратегической важности» часто стоят личные цели: бюджет на следующий год, повышение, устранение конкурента. Понимание мотивации меняет тактику работы. Работайте с каждым отдельно. Публичные встречи — для согласования уже принятых решений. Реальные договорённости — в личных разговорах. Не пытайтесь понравиться всем. Невозможно. Ваша задача — не дружба, а достижение результата. Иногда это значит, что кто-то останется недоволен. Фиксируйте договорённости письменно. После каждого совещания — протокол: что решили, кто ответственный, к какому сроку. Это защищает от «я этого не говорил». Работа с «токсичными» заказчиками: Не принимайте на личный счёт. Токсичность часто — следствие страха, давления сверху или прошлого негативного опыта. Отделяйте эмоции от фактов. «Вы всё провалили» — это эмоция. «Срок сдвинулся на две недели» — это факт. Работайте с фактами. Устанавливайте границы. Если заказчик переходит на личности — остановите разговор. Вежливо, но твёрдо. Привлекайте спонсора. Если поведение заказчика мешает проекту — это уже не ваш уровень. Это вопрос уровня выше. Когда эскалация — это инструмент, а не слабость: - Многие PM боятся эскалации. Кажется, что жаловаться наверх — это признание собственной некомпетентности. Это ошибка. - Эскалация — это управленческий инструмент. Он нужен, когда: - Решение выходит за пределы ваших полномочий (изменение контракта, бюджета, сроков). - Конфликт между стейкхолдерами блокирует проект, и вы не можете его разрешить на своём уровне. - Поведение заказчика или участника команды создаёт риски для результата. Как эскалировать правильно: - Не «жаловаться», а «информировать и запрашивать решение». - Приходить с фактами, а не эмоциями. - Предлагать варианты, а не просто описывать проблему. - Делать это своевременно, а не когда проект уже горит. Главное: проект — это временное предприятие, а политика — постоянна. Не игнорируйте её. Не боритесь с ней в одиночку. Управляйте ею. #УправлениеПроектами #Стейкхолдеры #PMO #Политика