Мои инструменты проектного управления

В своем телеграмм канале @iostechrutg я как-то спросил про интерес к инструментам проектного управления, которыми я пользуюсь и которые на мой взгляд работают.

Сразу хочу сказать - нет единой парадигмы или какой-то панацеи, которую можно натянуть на любой проект и вывезти ))

Сегодня разберу 2 кейса:

1. Инструмент портфельного управляющего проектами, где несколько команд, продуктов, автоматизированных систем выполняют схожие действия для достижения общей цели, она же цель проекта.

Так как цели схожие, делим их на направления или стримы.

Например:

- перенести базы данных с СУБД Оракл на Постгресс

- Сменить операционную систему сервера приложений с Windows на Linux

 

Что общего у этих двух разных стримов? Они могут быть образмерены (количественный показатель цели проекта) и разделены на схожие этапы для всех участников проекта.

Графически складывается в постримовую дорожную карту:

Screenshot 2025 02 25 at 10 31 47

Инструмент позволяет также быстро считать интегральный статус проекта, диагностировать проблемы, организовывать обмен опытом между командами (первые уже выполнили этап и поняли как это делать - вторые используют их опыт и сокращают время на разработку методики).

Использовался мной на проектах с бюджетами в несколько (больше 5) миллиардов рублей и с участием порядка 200 команд. Это был проект на 200 команд с одним стримом, второй был на 24 команды, но с 14 стримами.

Инструмент подразумевает возможность совместной работы, автоматизацию сбора статусов или интеграцию с системами управления задачами, принятых в компании. То есть не создает дополнительного ощутимого корпоративного налога на управление инициативой.

Дайте знать, если интересно подробней рассказать, тут пора переходить к второму инструменту.

 

2. Инструмент менеджера продукта, ответственного за доставку ценности от продукта конечному пользователю, клиенту.

В центре внимания и самой диаграммы будет доставка фичи, или ценности клиенту. То есть когда мы её доставим, в каком составе. Какие еще запуски планируются.

В верхней части диаграммы -  задачи бизнеса - проработки идеи, постановка задачи, согласование и получение бюджетов, разработка дизайна, исследования и т.д.

В нижней части - работы технологических команд. В проекте оно выглядит намного сложнее, но для иллюстрации существенно упростил и укрупнил.

Screenshot 2025 02 25 at 11 04 29

Хотелось бы уточнить, что эта диаграмма, не предназначена для отчетности руководителям в высоких кабинетах - это именно рабочий инструмент команд, показывающий лидерам команд и направлений всю картинку.

Одним взглядом можно оценить и увидеть перегруз команд - по вертикали очень много наслоений - это значит что что-то точно не будет сделано и будет сдвиг сроков. Можно увидеть “выпавшие” запуски, по которым еще не делаются все необходимые этапы. Используя цветовую схему отметки рисков - можно подсветить приоритетные работы, работы требующие внимания или работы с уже сорванным сроком - значит будет нужно перепланирование.

Этот инструмент я использую сейчас каждый день. Над продуктом, которым я сейчас занимаюсь трудятся 4 команды из 32 человек. Благодаря тому, что мы начали видеть цельную картину - удалось согласовать действия команд и взаимодействия на пограничных точках, управление приоритетами для того, чтобы клиент не заметил отсрочки. Клиент не виноват - он деньги платит.

Такие вот инструменты.

Интересно?

Ищу площадку, чтобы можно было подробней рассказать и поотвечать на вопросы - очно их, обычно, больше.

Мои инструменты проектного управления
Метки:         

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *