Обсуждение

"Признать наличие всех этих фреймворков и их важность, найти ответственных за них на предприятии (стейкхолдеров), посадить их за общий стол. Задать вопросы -- "по чьим процессам будем жить"?" чисто вопросы: 1. фреймворк - в единственном числе? (см. начало поста) 2. стейкхолдеры не МОГУТ быть ответстенными, а только заинтересованными? 3. надо жить не по процессам, а их результатам?

1. Не понял вопроса. Каждый фреймворк -- единственен, содержит собственную классификацию процессов, имеет собственную процессную онтологию (какие аспекты процессов описываются), собственную телеологию (для чего именно нужно эти процессы описывать). А в организации таких фреймворков используется множество -- менеджер по качеству опирается на адаптированный к его нуждам ISO 9000, менеджер по внедрению проектного управления -- на доработанный по вкусу PMI PMBoK. 2. Стейкхолдеры -- по определению заинтересованные. И они могут считать себя ответственными (и даже другие люди могут считать их ответственными). Но ответственность (responsibility) и полномочия (authority) -- это про разное. Зъисть-то он зъисть, та хто ж ему дасть? 3. "Надо жить по процессам/результатам" -- вопрос странный. Процессы как раз определяются как то, что должно вести к результатам. Если нет результатов процесса, то процесса нет (а для гарантирования результатов нужно также определить методологии, методики, инструменты, техники, это обязательно проговаривается во всех процессных фреймворках). Другое дело, что люди могут не признавать процессный подход как таковой, и фиксировать только их outcomes, не заморачиваясь с самими processes, activities, tasks (тут я использую терминологию процессного фреймворка системной инженерии, определенную в ISO TR 24774). Кстати, интересная дискуссия про "процессы vs результаты" была у меня тут: http://ailev.livejournal.com/620100.html

по поводу "... а также модели зрелости CMMI. Как ни странно, сюда же (а не к проектному управлению! ибо затрагиваются и способы работы, а не только способы планирования и контроля исполнения) я отношу процессные фреймворки SCRUM, eXtreme programming и прочие Agile ..." Собственно вот опять пример: "CMMI и Agile – возможен ли симбиоз? Пример интернационального распределенного проекта с использованием комбинированного процесса" http://secr.ru/?pageid=4548&submissionid=5260 слайдов организаторы еще не вывесили.

Вот тут я отношусь не к содержанию, а к форме: предлагается какой-то набор процессов (независимо от их содержательных принципов), который закрывает различные технологические аспекты (например, рефакторинг и подготовку stories в XP, а в CMMI это запрятано в результаты различных технологических "управлений"), так и аспекты управленческие (планирующие игры в XP, а в CMMI "управленческим управлениям" также уделено огромное внимание -- например, http://ailev.livejournal.com/560707.html). Содержания же (agile против водопада в "управленческих управлениях" или разделение функциональных требований и конструктивных в "технических процессах") я тут вообще не касаюсь, о совместимости или несовместимости не говорю. То, что содержательно все водопадчики сегодня пытаются сообщить, что agile они очень уважают, давно уже понятно. Даже в новой версии PMI PMBoK обедали сделать разрешающие agile высказывания (хотя и не более того).