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

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

Матрица ответственности: 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 #ТаймМенеджмент #Автоматизация