От провалов в внедрении ERP до построения системы эскалаций — всё самое интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в моем канале «Проектный дайджест».

Как встроить PDCA для топ-менеджмента, чтобы он не умер через месяц

Про довольно приземленный способ превратить легендарный цикл Деминга (я его помню еще с эпохи внедрения ISO 9001) в рабочую управленческую практику. Суть: каждое решение оформляется как гипотеза с ожидаемым результатом, показателем, ответственным и датой проверки. Раз в неделю руководители разбирают, что сработало, а что нет. Условия успеха:
постоянный ритм,
заранее определённая реакция на отклонение,
право публично признать неудачную гипотезу.
Ограничение: если решение уже принято сверху и никакие данные его не изменят, эксперименты не нужны. 

Как бы мы закрывали уязвимости в SELECTOS, если бы у нас были спринты

Менеджер проектов Selectel рассказывает, почему дважды убирала спринты из технических команд, при этом проблема при этом была вовсе не в «неправильном скраме». Дело в том, что команда легко начинает “ритуальничать” вместо того, чтобы решать исходную задачу. Поэтому ежедневные встречи можно заменить письменной синхронизацией, ретроспективу строить вокруг реализовавшихся рисков, а оценку проводить только с теми, кто действительно будет выполнять работу. Также рекомендуют прежде чем менять очередную методологию, разобрать накопившийся список задач и связать оставшиеся работы с целями продукта: иногда этого уже достаточно, чтобы “процесс” внезапно поправился. 

Построение нормальной системы эскалаций

Эскалация — это передача наверх конкретного решения, которое участники объективно не могут принять на своем уровне. Перед этим действием авторы предлагают сформулировать варианты, последствия каждого, собственную рекомендацию, владельца решения и срок, после которого решение уже потеряет смысл.
Важно: обратимые решения с ограниченным ущербом должны оставаться внутри команды; наверх отправляются:
— вопросы, затрагивающие чужие зоны ответственности,
— обязательства перед клиентом,
— конфликтующие цели нескольких частей системы.
А вот  если наверх постоянно уходит один и тот же класс вопросов, лечить надо уже границы полномочий и устройство процесса. 

Вместо DORA: как перестать измерять всё подряд и начать управлять процессом разработки

В «Точке» столкнулись с классической проблемой: данных о работе команды разработки стало много, а понять по ним, стало лучше или хуже, — всё сложнее. Для решения команда построила двухуровневую систему: 1) несколько верхнеуровневых показателей дают сигнал об отклонении, 2) более детальные помогают найти его причину. Также отдельно учитывается, на что вообще уходит время — развитие продукта, поддержание существующего или пожаротушение. И якобы изменения эти привели к росту пропускной способности на 39% и экономическим эффектом в 112 млн рублей.

Почему задачи всегда возвращаются к руководителю: обратное делегирование глазами менеджера проектов

Про ситуацию, когда руководитель вроде бы делегировал задачу, но через некоторое время снова принимает по ней все решения, отвечает на вопросы и фактически становится главным исполнителем собственного поручения. Автор называет это постепенным обратным делегированием и связывает его не столько с несамостоятельностью сотрудников, сколько с неясными границами ответственности, размытыми критериями готовности и привычкой руководителя отвечать быстрее, чем подчинённый успевает подумать. Рекомендации:
— заранее определить право принятия решения,
— фиксировать контекст в рабочей системе,
— приучать команду приходить не с вопросом «что делать?», а со своим вариантом решения и оценкой последствий. 

Можно ли оценить систему правления проектной деятельностью и зачем это делать

Большой обзор моделей зрелости проектного управления, по сути — способности организации в принципе регулярно и предсказуемо реализовывать проекты. Автор проходит по различным моделям (уровневые, непрерывные, лепестковые…) и показывает общую схему:
— оценить процессы, компетенции, инструменты и результаты,
— найти разрывы,
— затем превратить их в план развития системы управления.

При этом зацикливаться на уровнях зрелости не стоит, чтобы он сами не стали предметом корпоративного культа.

Сократили цикл разработки на 20% — и получили вдвое больше инцидентов

Если вы знаете про закон Гудхарта (“Когда мера становится целью, она перестает быть хорошей мерой”), то вот прямо кейс под него. Компания поставила командам единственную измеримую цель — на 20% сократить цикл разработки, и в итоге… получила именно этот показатель: люди рационально начали сокращать проверки, обходить всё, что мешало улучшению показателя. А через несколько месяцев число инцидентов выросло вдвое.
Как решили? Ввели показатели-противовесы: если ускоряем выпуск, одновременно следим, чтобы не ухудшалась надёжность. Причём заранее задаём не только допустимые значения, но и действия при выходе за границы. А еще и персональную ответственность за инциденты. И якобы это помогло — инциденты вернулись на прежний уровень) 

«Грабли» проектов ERP

Большая коллекция ошибок из реальных проектов внедрения КИС:
— неподготовленные справочники,
— недостоверные начальные данные,
— слабое участие заказчика,
— отсутствие запасного плана,
— чрезмерное обследование,
— желание доработать типовой продукт до полного сходства со старой системой.
Сквозная мысль стара как мир: технологические проблемы часто оказываются проще организационных, а информационная система не исправляет процессы и данные, которые были плохими до её появления.
Из совсем прикольного — пример с остатками, которые дважды загружали из разных систем, прежде чем признали очевидное: достоверных исходных данных просто не было и требовалась обычная инвентаризация. Автор также советует не превращать предпроектное обследование в самостоятельную отрасль производства документов, а как можно раньше переходить к моделированию на реальных данных.

Управление ожиданиями заказчика на 1С-проекте: как не доводить до “мы думали, будет иначе”

Хороший разбор самого дешёвого способа избежать дорогой переделки: договориться о результате до начала разработки. Автор предлагает фиксировать не только то, что входит в задачу, но и то, что не входит, отдельно проговаривать этапы и сроки, критерии приемки, ограничения и ответственность заказчика. Разработчик думает о корректности системы, а пользователь — понимает ли он, что теперь делать и помогает ли изменение решить его рабочую задачу. Для большинства относительно небольших доработок вся эта конструкция вполне помещается в короткое резюме договорённостей после встречи — на 1-2 страницы.

От ТЗ к диагностике: как меняется модель AI-разработки

Кратко — нужно уходить от идеи «что заказчик просит сделать?» в сторону «какую проблему и с каким измеримым эффектом мы решаем?». Вместо работы по ТЗ, когда заказчик принёс задачу, а исполнитель оценил и сделал, надо заниматься диагностикой: сначала разобраться, где на самом деле находится проблема, оценить потенциальный эффект и только после этого начинать разработку. А значит, нужно выходить в поля, делать интервью и руководителей, и непосредственных исполнителей, измерять их трудозатраты, отбирать процессы для автоматизации и заранее договариваться о критериях результата. И уже потом делать (втч с использованием AI).