
В своем телеграмм канале @iostechrutg я как-то спросил про интерес к инструментам проектного управления, которыми я пользуюсь и которые на мой взгляд работают.
Сразу хочу сказать - нет единой парадигмы или какой-то панацеи, которую можно натянуть на любой проект и вывезти ))
Сегодня разберу 2 кейса:
1. Инструмент портфельного управляющего проектами, где несколько команд, продуктов, автоматизированных систем выполняют схожие действия для достижения общей цели, она же цель проекта.
Так как цели схожие, делим их на направления или стримы.
Например:
- перенести базы данных с СУБД Оракл на Постгресс
- Сменить операционную систему сервера приложений с Windows на Linux
Что общего у этих двух разных стримов? Они могут быть образмерены (количественный показатель цели проекта) и разделены на схожие этапы для всех участников проекта.
Графически складывается в постримовую дорожную карту:
Инструмент позволяет также быстро считать интегральный статус проекта, диагностировать проблемы, организовывать обмен опытом между командами (первые уже выполнили этап и поняли как это делать - вторые используют их опыт и сокращают время на разработку методики).
Использовался мной на проектах с бюджетами в несколько (больше 5) миллиардов рублей и с участием порядка 200 команд. Это был проект на 200 команд с одним стримом, второй был на 24 команды, но с 14 стримами.
Инструмент подразумевает возможность совместной работы, автоматизацию сбора статусов или интеграцию с системами управления задачами, принятых в компании. То есть не создает дополнительного ощутимого корпоративного налога на управление инициативой.
Дайте знать, если интересно подробней рассказать, тут пора переходить к второму инструменту.
2. Инструмент менеджера продукта, ответственного за доставку ценности от продукта конечному пользователю, клиенту.
В центре внимания и самой диаграммы будет доставка фичи, или ценности клиенту. То есть когда мы её доставим, в каком составе. Какие еще запуски планируются.
В верхней части диаграммы - задачи бизнеса - проработки идеи, постановка задачи, согласование и получение бюджетов, разработка дизайна, исследования и т.д.
В нижней части - работы технологических команд. В проекте оно выглядит намного сложнее, но для иллюстрации существенно упростил и укрупнил.
Хотелось бы уточнить, что эта диаграмма, не предназначена для отчетности руководителям в высоких кабинетах - это именно рабочий инструмент команд, показывающий лидерам команд и направлений всю картинку.
Одним взглядом можно оценить и увидеть перегруз команд - по вертикали очень много наслоений - это значит что что-то точно не будет сделано и будет сдвиг сроков. Можно увидеть “выпавшие” запуски, по которым еще не делаются все необходимые этапы. Используя цветовую схему отметки рисков - можно подсветить приоритетные работы, работы требующие внимания или работы с уже сорванным сроком - значит будет нужно перепланирование.
Этот инструмент я использую сейчас каждый день. Над продуктом, которым я сейчас занимаюсь трудятся 4 команды из 32 человек. Благодаря тому, что мы начали видеть цельную картину - удалось согласовать действия команд и взаимодействия на пограничных точках, управление приоритетами для того, чтобы клиент не заметил отсрочки. Клиент не виноват - он деньги платит.
Такие вот инструменты.
Интересно?
Ищу площадку, чтобы можно было подробней рассказать и поотвечать на вопросы - очно их, обычно, больше.