Аннотация
- Докладчик
- Руслан Мартимов
Корпорация — это, прежде всего много людей. Каждый со своими интересами, но при этом работающие в одной системе. Существует большое количество заинтересованных сторон, что стоит учитывать. Если это разумно в конкретном случае, возможно, стоит составить план коммуникаций.
Вся работа по выпуску новых продуктов строится на основе жесткого плана, для реализации которого подключаются компании (направления или объединения отделов) работающие внутри корпорации.
Наиболее интересными являются именно те проекты, в которых участвуют несколько компаний. Поскольку в этом случае наиболее ярко проявляются характерные черты.
При разработке сложного продукта является обязательным не только должность ведущего менеджера, но и архитектора, даже когда кажется, что команды касаемо своих частей могут договориться. Эта необходимость была проверена также на своем негативном опыте. В проекте из-за отсутствия сквозной архитектуры возникло большое количество несостыковок, не очевидных на первый взгляд при грамотном при этом прописи интерфейсов, что привело к сдвигу срока сдачи.
Кроме этого в процессе работы автор наблюдал лично ряд интересных организационных проблем и хотел бы поделиться со слушателями:
- различный приоритет одного и того же проекта в разных компаниях (подразделениях) — в одной компании проект может иметь не высокий приоритет, а в другой main stream.
- влияние прошлого негативного опыта — зачастую наблюдается ситуация когда целые компании основываясь на прошлом не очень удачном опыте, не хотят искать решения возникших новых проблем, а обвиняют другую в «кривизне рук». При этом это нисколько не приближает достижение конечной цели.
- недоверие между участвующими командами — известная проблема. В частности это проявляется, когда участники имеют смутное представление о работе других команд. (Поставка закрытых библиотек, разнесенные компоненты системы и т. д.)
- Высокая бюрократизация — чем больше становится компания, тем больше административных усилий нужно для ее поддержания и как следствие растет бюрократизация и число уровней управления проектами. Может привести к тому, что за проект ни кто единолично не отвечает.
Некоторые, из которых не очевидны на первый взгляд, но могут быть очень вредоносны, как например различный приоритет проекта. То, что это происходит, как и большинство негативных явлений именно как следствие недоработки организации, а не недостатки каких то отдельных людей.
Поэтому особенно необходимо отстраняться от процесса и постараться посмотреть сверху на то, что собственно происходит для выявления как раз этих системных проблем.
Решать их также необходимо системными методами, такими как, например:
- Планирование с большим количеством вех по каждой из команд и для всего проекта целиком.
- К сожалению, реальность такова, что одни и те же люди работают одновременно в нескольких проектах. Четко обговоренным ресурсом (ч/ч) (по возможности и дни недели) когда каждая из команд будет работать над проектом
- Ясный и понятный протокол взаимодействия между командами, — каким набором документов, доп. средств и т. п. к примеру, будут снабжаться поставляемые на интеграцию модули.
- Систематическое выстраивание взаимоотношений между командами, чтобы устранить недоверие и связанные с этим проблемы.
Видео
Оцените доклад «Управление проектами по разработке ПО в корпорациях (Руслан Мартимов, SPMConf-2011)»:
Слайды
Примечания и отзывы
Репликация: База Знаний «Заказных Информ Систем» → «Управление проектами по разработке ПО в корпорациях (Руслан Мартимов, SPMConf-2011)»
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
