Comments 45
Хотелось бы более подробного разъяснения, что же такое эта ваша загадочная аббревиатура, а то в вики сплошная реализация:
Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности.
На сколько мне рассказывали в нашей конторе, компания сама не может быть стандартизована по CMMI, стандартизуется отдел или проект. Ну, если все стандартизованы — то да, можно сказать что компания стандартизована, единственное, что на это надо угрохать совсем много денег. Ну и поэтому bodyshop стандартизировать просто не получится, так как такой отдел ничего не производит.
А вообще, CMMI, PMBOK и другие слова, я согласен, что не на пустом месте родились, просто там все так описано, чтобы консультанты и аудиторы могли заработать денег, а люди просто не понимают и отказываются когда видять, что надо описывать кучу макулатуры.
Вот конкретно вы, кто поддерживает level 3, можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах, наподобие того, что вы написали про PMP и traceability?
Кстати вот хороший пример — traceability, что вы привели. Т.е. тупо требуют issue tracker. И вы хорошо это объяснили. Вот если так объяснять все требования, то получается, что не все так и страшно, а очень разумно, и таких описаний не хватает.
А вообще, CMMI, PMBOK и другие слова, я согласен, что не на пустом месте родились, просто там все так описано, чтобы консультанты и аудиторы могли заработать денег, а люди просто не понимают и отказываются когда видять, что надо описывать кучу макулатуры.
Вот конкретно вы, кто поддерживает level 3, можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах, наподобие того, что вы написали про PMP и traceability?
Кстати вот хороший пример — traceability, что вы привели. Т.е. тупо требуют issue tracker. И вы хорошо это объяснили. Вот если так объяснять все требования, то получается, что не все так и страшно, а очень разумно, и таких описаний не хватает.
— компания сама не может быть стандартизована по CMMI, стандартизуется отдел или проект.
Отдел или подразделение — Да. Но не проект. Хотя, если этот проект тянет на подразделение — то можно и так сказать:). В обиходе говорят «компания», имея ввиду, что в рамках этой компании есть подразделение, которое оценено на такой-то уровень. Так вот и у нас: есть bodyshop, который, разумеется, не входил в группу оцениваемых проектов.
Однако, так как CMMI касается не только проектного управления, но и организационного, то даже при сосуществовании полного цикла оказания услуги и bodyshop есть общие организационные процессы, такие как, например, развитие персонала (в CMMI — Organizational Training).
Отдел или подразделение — Да. Но не проект. Хотя, если этот проект тянет на подразделение — то можно и так сказать:). В обиходе говорят «компания», имея ввиду, что в рамках этой компании есть подразделение, которое оценено на такой-то уровень. Так вот и у нас: есть bodyshop, который, разумеется, не входил в группу оцениваемых проектов.
Однако, так как CMMI касается не только проектного управления, но и организационного, то даже при сосуществовании полного цикла оказания услуги и bodyshop есть общие организационные процессы, такие как, например, развитие персонала (в CMMI — Organizational Training).
— а люди просто не понимают и отказываются когда видять, что надо описывать кучу макулатуры
Абсолютно с Вами согласна. Как я уже писала, я не фанатка CMMI, очень долго сама пыталась разобраться что к чему :)
— можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах
Могу, возможно не все, но вот пару примеров в статье привела. В принципе, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :).
Абсолютно с Вами согласна. Как я уже писала, я не фанатка CMMI, очень долго сама пыталась разобраться что к чему :)
— можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах
Могу, возможно не все, но вот пару примеров в статье привела. В принципе, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :).
CMMI — это модель оценки уровня зрелости? Почему был выбран именно CMMI? Во многих методологиях (например, для управления ИТ-инфраструктурами, проектами, офисами управления проектами) есть свои модели оценки зрелости.
Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности». Это мои личные сомнения, поэтому хотелось бы Вашего комментария.
Спасибо кстати, стало понятно чуть больше о том, как способствует CMMI зрелости организации, и тому, что она
1. управляется лучше,
2. выполняет задачи лучше.
Но пока не очевидно, что того же нельзя было бы достичь повышая роль и зрелость офиса управления проектами например.
Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности». Это мои личные сомнения, поэтому хотелось бы Вашего комментария.
Спасибо кстати, стало понятно чуть больше о том, как способствует CMMI зрелости организации, и тому, что она
1. управляется лучше,
2. выполняет задачи лучше.
Но пока не очевидно, что того же нельзя было бы достичь повышая роль и зрелость офиса управления проектами например.
— Почему был выбран именно CMMI?
Наше руководство решило, что нам это нужно. Какие у них тогда были соображения — я не буду предполагать.
Насколько я помню, тогда же рассматривался вариант OPM3. Но от него отказались, вероятно потому, что CMMI, в принципе, включает и управление проектами. К тому же, видимо, на рынке клиентов спроса на OPM3 не было :). Точно не помню сейчас OPM3 (помню, что много общего), но CMMI включет помимо Organizational Project Management еще и Organizational Process Management, Engineering и Support области.
— Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности».
CMMI имеет варианты для Development, Services, Systems (и даже People). CMMI for Development, о котором и идет речь, рассматривает необходимые условия для работы IT подразделения, то есть «уровень зрелости IT подразделения/компании». Но я бы все-таки определяла немного по-другому: уровень зрелости управления IT подразделением/компанией.
Наше руководство решило, что нам это нужно. Какие у них тогда были соображения — я не буду предполагать.
Насколько я помню, тогда же рассматривался вариант OPM3. Но от него отказались, вероятно потому, что CMMI, в принципе, включает и управление проектами. К тому же, видимо, на рынке клиентов спроса на OPM3 не было :). Точно не помню сейчас OPM3 (помню, что много общего), но CMMI включет помимо Organizational Project Management еще и Organizational Process Management, Engineering и Support области.
— Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности».
CMMI имеет варианты для Development, Services, Systems (и даже People). CMMI for Development, о котором и идет речь, рассматривает необходимые условия для работы IT подразделения, то есть «уровень зрелости IT подразделения/компании». Но я бы все-таки определяла немного по-другому: уровень зрелости управления IT подразделением/компанией.
Trivia: СMM (мама) СMMI была разработана по заказу американских военных. Им нужна была метрика, чтобы оценивать конторы, которые предлагают услуги по производству софта.
en.wikipedia.org/wiki/Capability_Maturity_Model
«At the request of the U.S. Air Force he began formalizing his Process Maturity Framework to aid the U.S. Department of Defense in evaluating the capability of software contractors as part of awarding contracts.»
en.wikipedia.org/wiki/Capability_Maturity_Model
«At the request of the U.S. Air Force he began formalizing his Process Maturity Framework to aid the U.S. Department of Defense in evaluating the capability of software contractors as part of awarding contracts.»
Если же после получения этого лэйбла, Вы все спокойно забудете на ближайшие 3 года, умный клиент раскусит Вас, не сомневайтесь. Подобная же опасность поджидает и те компании, которые, оценив отдельное подразделение (например, офис в одном городе), объявляют, что вся компания имеет такой-то уровень CMMI. Быть оцененным намного проще, чем поддерживать этот статус (или распространить навыки и процесс на другие подразделения).
Сомневаюсь (работаю в CMMI5 компании).
ну или я неправильно понял назначение CMMI. Слышал мнение что это примерно как перечень инструментария который нужен для работы. Понятно что врачу со стетоскопом доверяеш больше, но гарантий это не дает.
— но гарантий это не дает.
Не дает. CMMI говорит о потенциальных возможностях. Но не гарантирует, что каждый проект будет идеальным.
Не дает. CMMI говорит о потенциальных возможностях. Но не гарантирует, что каждый проект будет идеальным.
это есть такая грубая поговорка про «прикрывает но не защищает».
Собственно я за CMMI так как какая то попытка навести порядок лучше чем отсутвие её. А комент мой первый был о том что вы говорите
Собственно я за CMMI так как какая то попытка навести порядок лучше чем отсутвие её. А комент мой первый был о том что вы говорите
В статье я попытаюсь «развенчать» некоторые мифы, развеять скептицизмно развенчания второго мифа я так и не увидел. То что фирме было бы лучше еслиб все следовали процессам определенным для получения CMMI5 не означет что они захотят или смогут внедрить их. А без этого так и остается маркетинговый ход потому что без cmmi тупо к проекту не подпускают.
— Сомневаюсь (работаю в CMMI5 компании).
Ваше право. Но нут возможны вопросы:
а) играет ли этот статус какую-то роль для ваших клиентов? Если нет, то он и не будет пытаться вас «раскусить». (это по поводу маркетинга)
б) работали ли Вы в «неCMMI5» компании? И как долго работали там и там? если да, работали и достаточно долго, то тогда действительно интересно услышать Ваше мнение по поводу сравнения этих компаний.
в) Вы работаете в том подразделении, которое проходило оценивание? Или, скажем, в другом офисе этой компании (или в другом направлении)? Тоже интересно, есть ли отличия.
Ну и, в конце концов, про Level 5. Судя по тому, что я слышала, этому мало кто доверяет. Как сказал один из наших потенциальных клиентов, «я буду работать с Level 3, так как тут меньше шансов фальсификации».
Ваше право. Но нут возможны вопросы:
а) играет ли этот статус какую-то роль для ваших клиентов? Если нет, то он и не будет пытаться вас «раскусить». (это по поводу маркетинга)
б) работали ли Вы в «неCMMI5» компании? И как долго работали там и там? если да, работали и достаточно долго, то тогда действительно интересно услышать Ваше мнение по поводу сравнения этих компаний.
в) Вы работаете в том подразделении, которое проходило оценивание? Или, скажем, в другом офисе этой компании (или в другом направлении)? Тоже интересно, есть ли отличия.
Ну и, в конце концов, про Level 5. Судя по тому, что я слышала, этому мало кто доверяет. Как сказал один из наших потенциальных клиентов, «я буду работать с Level 3, так как тут меньше шансов фальсификации».
Интересно было бы видеть реализацию конкретных практик CMM (кто-то выше уже просил).
Агитации за советскую власть, т.е., что CMMI полезна, и так много. Жизненных примеров мало.
Агитации за советскую власть, т.е., что CMMI полезна, и так много. Жизненных примеров мало.
реализация это например список правил
1)перед началом проекта мы всегда будем проводить тщательный анализ требований
2)во время выполнения проекта всегда будем выделять адекватные ресурсы
3)после окончания проекта всегда будем корректировать подход с учетом полученых новых данных.
1)перед началом проекта мы всегда будем проводить тщательный анализ требований
2)во время выполнения проекта всегда будем выделять адекватные ресурсы
3)после окончания проекта всегда будем корректировать подход с учетом полученых новых данных.
а если вы попробуете почитать пролистать (или даже просмотреть список практик)… то вы найдете там то, о чем просите, например (соответственно с вашими пунктами):
1) Requirements Development (вся практика)
2) Project Planning -> SP 2.4. Plan for Project Resources
3) Causal Analysis and Resolution (но это не обязательно после окончания проекта)
там вам и будет список правил :)
1) Requirements Development (вся практика)
2) Project Planning -> SP 2.4. Plan for Project Resources
3) Causal Analysis and Resolution (но это не обязательно после окончания проекта)
там вам и будет список правил :)
Да я, собственно, не агитирую. Более того, мыслью подтолкнувшей меня на написание статьи было «не трогайте CMMI, если Вам это действительно не надо». Кому и зачем надо — я написала. Так же, сделала акцент на том, что применение (реализация конкретных практик) зависит от профессионального кругозора тех кто применяет и от знания всей модели, а не отдельных ее частей.
Как я уже ответила уважаемому 1nd1go, который просил больше примеров, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :). Я привела несколько жизненных примеров, когда стоит и когда не стоит применять CMMI, пару примеров реализации практик. Задачей этой статьи не было объяснение большинства практик простыми словами. Те пример, которые я привела, показывают, что это возможно.
Востребованность я поняла. Постараюсь оправдать Ваши надежды.
Как я уже ответила уважаемому 1nd1go, который просил больше примеров, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :). Я привела несколько жизненных примеров, когда стоит и когда не стоит применять CMMI, пару примеров реализации практик. Задачей этой статьи не было объяснение большинства практик простыми словами. Те пример, которые я привела, показывают, что это возможно.
Востребованность я поняла. Постараюсь оправдать Ваши надежды.
После прочтения вашей статьи я не стал больше знать про CMMI ни на йоту. Можете какие-нибудь примеры вида: мы начали депремировать уборщицу Клаву за то-то и премировать за это и тараканы в нашей столовой перестали докучать посетителям?
У каждой статьи свой читатель. Значит Вы знаете много. Мой опыт показывает, что далеко не все такие образованные в этом плане.
Я пишу статьи чтобы «забэйзлайнить» свои мысли. Возможно, я до Вас еще не доросла.
По поводу примеров я уже писала в ответах на предыдущие комментарии. Целью этой статьи не было ни продвижение CMMI в массы, ни рассказ об успехах его применения.
Наоборот, я говорю об ошибках, которые совершили мы, поверив в мифы про CMMI.
Я пишу статьи чтобы «забэйзлайнить» свои мысли. Возможно, я до Вас еще не доросла.
По поводу примеров я уже писала в ответах на предыдущие комментарии. Целью этой статьи не было ни продвижение CMMI в массы, ни рассказ об успехах его применения.
Наоборот, я говорю об ошибках, которые совершили мы, поверив в мифы про CMMI.
Нет. В смысле, я как не знал ничего, так и не стал знать ничего.
В таком случае надо начать и литературы попроще, если вообще есть цель понять.
Там в начале статьи есть ссылки на базовую информацию, о чем уже писали на Хабре
Эта информация никак не проясняет. Я пока понимаю суть CMMI только с прикладной точки зрения: это такое заклинание, которое позволяет получать контракты от государства (берём США, например) и от крупных корпораций. На качество итогового продукта (на практике) это влияет мало.
Мой любимый пример: производители тушёнки сертифицированы по ISO9000, однако выпускаемую ими продукцию есть невозможно.
Мой любимый пример: производители тушёнки сертифицированы по ISO9000, однако выпускаемую ими продукцию есть невозможно.
Данный пост как раз для этого и написан. У меня опять возникают сомнения в желании понять у комментирующих.
Не вижу никакой ясности, а вижу набор стандартных баззвордов: CMMI, ROI итп. Примерно такой же фигнёй любят засыпать неосведомлённого человека евангелисты ERP-систем. Да, на словах оно всё идеально, но на практике… см. пример выше про тушёнку. CMMI не гарантирует качество продукта, оно гарантирует качество процесса. Одно с другим, конечно, связано, но не напрямую. Техпроцесс производства дерьмовой тушёнки идеально соответствует ISO9000, вот только на выходе получается дерьмо.
Я не знаю, что вы читали, но здесь нет ни баззвордов, ни идеальности на словах.
Я не спорю, что проще привести пример с тушенкой, чем написать большой текст. Только в большом тексте и аргументов больше. Если в ответ на них у вас есть только пример с тушенкой, то у меня в третий раз за сегодня возникают сомнения в желании понять этот пост.
Я не спорю, что проще привести пример с тушенкой, чем написать большой текст. Только в большом тексте и аргументов больше. Если в ответ на них у вас есть только пример с тушенкой, то у меня в третий раз за сегодня возникают сомнения в желании понять этот пост.
Можно наладить суперский процесс производства продукции разных сортов. Даже той тушенки о которой Вы говорите. Процесс гарантирует однородность и повторяемость. Если вся тушенка одинаково «дерьмовая», то производство преуспело в процессе :).
Другое дело, стоит ли за производством задача улучшения и роста. Вероятно у производителя этой тушенки — нет. Возможно, производителя устраивает и спрос и себестоимость.
Другое дело, стоит ли за производством задача улучшения и роста. Вероятно у производителя этой тушенки — нет. Возможно, производителя устраивает и спрос и себестоимость.
Во, именно про это я и говорю. CMMI стоит рассматривать исключительно как маркетинговый (хотя и сложный) инструмент. Дополнительный путь для зарабатывания кучи денег.
Вы говорите совсем не об этом. CMMI (и другие стандарты) — это необходимое условия для ведения нормального бизнеса, а не достаточное. Плохую тушенку вы сделаете и без CMMI, а хорошую только при условии внедрения нормальных процессов. Но если поставите туповатого менеджера ими руководить, то снова получите плохую тушенку. И расскажете, что во всем виновата CMMI, хотя всем вокруг будет понятно, что виноват выбор туповатого менеджера.
Не совсем согласна. Снова получим плохую тушенку в случае если
а. менеджер будет пренебрегать этапами процесса,
б. менеджер не будет реагировать на метрики и другие знаки того, что процесс вышел из под контроля, и
в. требования к выходному продукту каждого этапа производства будут снижены
или не будут проверяться (что есть пренебрежение процессом)
а. менеджер будет пренебрегать этапами процесса,
б. менеджер не будет реагировать на метрики и другие знаки того, что процесс вышел из под контроля, и
в. требования к выходному продукту каждого этапа производства будут снижены
или не будут проверяться (что есть пренебрежение процессом)
Попробуйте почитать требования. И сложить их в систему.
Тут всех пугает кажущаяся сложность текста. Поэтому читать стоит людям подкованным в нескольких инженерных и управленческих областях.
И потому же я теперь уже однозначно буду писать «CMMI для чайников» :).
Тут всех пугает кажущаяся сложность текста. Поэтому читать стоит людям подкованным в нескольких инженерных и управленческих областях.
И потому же я теперь уже однозначно буду писать «CMMI для чайников» :).
Начну с начала — CMM возникла как попытка перенести успешный опыт повышения качества шесть-сигма в софтверную индустрию, но понятно что провалилась, ибо процессы неустойчивые сами по себе. На самом деле все забывают сказать что любая оптимизация процессов должна быть объективно полезна для исполнителей, иначе она будет в лучшем случае поддерживаться формально или даже подтасовываться. То есть новые процессы должны быть устойчивыми.
Обычно пишут что целей внедрения CMM(I) бывает 2 — требования заказчика или внутренняя потребность формализовать процессы. Фишка в том что полезной она может быть только в случае если сама организация достаточно созрела для оптимизации и ее кадры понимают что делают. Но такой организации как правило уже не нужен костыль в виде формальных правил СММ.
В целом же лейбл с уровнем СММ(I) как правило не соответствует действительности.
Обычно пишут что целей внедрения CMM(I) бывает 2 — требования заказчика или внутренняя потребность формализовать процессы. Фишка в том что полезной она может быть только в случае если сама организация достаточно созрела для оптимизации и ее кадры понимают что делают. Но такой организации как правило уже не нужен костыль в виде формальных правил СММ.
В целом же лейбл с уровнем СММ(I) как правило не соответствует действительности.
— Фишка в том что полезной она может быть только в случае если сама организация достаточно созрела для оптимизации и ее кадры понимают что делают. Но такой организации как правило уже не нужен костыль в виде формальных правил СММ.
Согласна! Но чтобы созреть и понимать, можно идти своим собственным путем проб и ошибок, не умея применять чужой опыт или отвергая его в принципе. (В данном случае, мне кажется, что многие комментаторы даже не пробовали читать CMMI, и я их понимаю, слишком уж много текста.)
Другой путь — все таки взять на вооружение такие модели, как CMMI. Но взять на вооружение должно руководство, чем выше, тем лучше. Индивидуальный забег проджект менеджера или тим лида может привести к конфликту, разочарованию, или, в лучшем случае, к успеху этого конкретного проекта и этого конкретного менеджера.
Все мы ходили в школу, читали учебники в институтах. Сейчас мы их уже, может быть кто-то за редким исключением, не перечитываем. Потому что созрели и поняли, и запомнили. То же и с моделями зрелости, стандартами и т.д.
Согласна! Но чтобы созреть и понимать, можно идти своим собственным путем проб и ошибок, не умея применять чужой опыт или отвергая его в принципе. (В данном случае, мне кажется, что многие комментаторы даже не пробовали читать CMMI, и я их понимаю, слишком уж много текста.)
Другой путь — все таки взять на вооружение такие модели, как CMMI. Но взять на вооружение должно руководство, чем выше, тем лучше. Индивидуальный забег проджект менеджера или тим лида может привести к конфликту, разочарованию, или, в лучшем случае, к успеху этого конкретного проекта и этого конкретного менеджера.
Все мы ходили в школу, читали учебники в институтах. Сейчас мы их уже, может быть кто-то за редким исключением, не перечитываем. Потому что созрели и поняли, и запомнили. То же и с моделями зрелости, стандартами и т.д.
* Не Гербалайф!
CMMI требует наличие планов работ, при чем они должны быть «консолидированными». Мы создали шаблон Project Management Plan (PMP), который менеджеры должны были писать, а все остальные – читать. Мы же создали процесс Планирование Проекта, в ходе которого создается план. В результате, наши PMP создавались к концу проекта, и никто никогда их не читал. Тем не менее, вся информация, которую должен содержать этот документ, уже обязательно где-то есть к началу проекта: обычно в письмах, в инструментах, картинках и т.д. Наличие регистра информации со ссылками на источники этой информации вполне решает проблему наличия PMP, то есть удовлетворяет требования CMMI, и никакой бюрократии.
Я чего-то не понял в вашем примере :(.
CMMI требует консолидированного плана работ. Вы придумали как он должен выглядеть — разработали шаблон и правила его заполнения. Но шаблон этот никто не использовал (заполняли к концу проекта, и вообще не читали). А потом вы делаете хитрый финт, мол, эта информация уже где-то есть — в письмах, картинках, поэтому мы сделали регистр информации со ссылками.
Но вы же сами сказали, что план работ должен быть консолидированным. ИМХО, это означает что я могу открыть один документ (файл, проект в проджекте, etc) и увидеть общий план проекта. В вашем реестре отображается плановая дата завершения проекта?
Не поленился и залез на
www.software-quality-assurance.org
в раздел Develop a Project Plan:
A project plan is a formal, approved document used to manage and control the execution of the project. It is based on the project requirements and the established estimates.
Так что не понял я ваш пример. С тем же успехом можно сказать, что CMMI требует, чтобы у проекта были требования. Ну так они есть!.. Точно помню кто-то в почту мне присылал, а еще нашему директору кто-то смской пару замечаний отправил. Значит у нас уже полный CMMI и проводить сбор-анализ-документирование-согласование требований уже не надо. :)
Я чего-то не понял в вашем примере :(.
CMMI требует консолидированного плана работ. Вы придумали как он должен выглядеть — разработали шаблон и правила его заполнения. Но шаблон этот никто не использовал (заполняли к концу проекта, и вообще не читали). А потом вы делаете хитрый финт, мол, эта информация уже где-то есть — в письмах, картинках, поэтому мы сделали регистр информации со ссылками.
Но вы же сами сказали, что план работ должен быть консолидированным. ИМХО, это означает что я могу открыть один документ (файл, проект в проджекте, etc) и увидеть общий план проекта. В вашем реестре отображается плановая дата завершения проекта?
Не поленился и залез на
www.software-quality-assurance.org
в раздел Develop a Project Plan:
A project plan is a formal, approved document used to manage and control the execution of the project. It is based on the project requirements and the established estimates.
Так что не понял я ваш пример. С тем же успехом можно сказать, что CMMI требует, чтобы у проекта были требования. Ну так они есть!.. Точно помню кто-то в почту мне присылал, а еще нашему директору кто-то смской пару замечаний отправил. Значит у нас уже полный CMMI и проводить сбор-анализ-документирование-согласование требований уже не надо. :)
— план работ должен быть консолидированным. ИМХО, это означает что я могу открыть один документ (файл, проект в проджекте, etc) и увидеть общий план проекта.… С тем же успехом можно сказать, что CMMI требует, чтобы у проекта были требования. Точно помню кто-то в почту мне присылал, а еще нашему директору кто-то смской пару замечаний отправил.
В нашем документе есть разделы, необходимые для Project Management Plan, соответствующие всем базовым требованиям разных стандартов (они все примерно одинаковы для PMP). Эти разделы должны
а) либо заполняться в самом документе, но во время, то есть до того, как этот раздел нужен для работы;
б) либо ссылаться на описание всей необходимой для этого раздела информации, которая хранится в другом файле или инструменте. При этом все эти файлы и инструменты должны быть сохранены в специально отведенном для PMP хранилище (например, как у нас, SharePoint библиотека на сайте проекта).
Эта информация, из каждого раздела PMP, независимо в каком формате она сохранена, обязательно должна быть:
а. доступна из PMP (я его назвала «регистр» информации и ссылок)
б. обязательно ревьюится всеми вовлеченными в работу по этому разделу людьми, а так же службой обеспечения качества (моя епархия)
в. формально утверждается и «бэйзлайнится». Заказчику не всегда нужно (и хочется) видеть весь документ целиком. С заказчиком формально утверждается то, что ему нужно и что нам нужно от заказчика. Все целиком формально утверждается службой обеспечения качества или менеджером данного account-a.
г. есть процесс управления изменениями, поэтому новые поступления либо вливаются в уже существующую информацию. Например, файл с описанием объема работ пересохраняется с новой версией.
Таким образом, PMP — консолидированный, формально утвержденный, используется для контроля и управления. Информация не разбросана по смс-кам и почтам, а хранится в одном месте и содержит актуальную информацию.
Что очень важно, эта информация всегда публикуется своевременно. И психологически легче для того, кто публикует и тех, кто читает. Это то же, что переслать письмо (часто это пересланное письмо и является новой версией документа).
— В вашем реестре отображается плановая дата завершения проекта?
Дата завершения проекта в нашем случае отражается в MS project-e. На MS Project, как на расписание, задачи, зависимости ссылаемся из PMP (регистра информации и ссылок). В том же PMP должна быть ссылка на контрактные условия (к сожалению, работа с контрактом у нас пока слабое место, поэтому пишу «должна быть»), в которых тоже прописана дата окончания проекта. Собственно оттуда она попадает в расписание, или наоборот (в зависимости от того, когда подписан контракт).
— С тем же успехом можно сказать, что CMMI требует, чтобы у проекта были требования… Значит у нас уже полный CMMI и проводить сбор-анализ-документирование-согласование требований уже не надо. :)
не совсем так, CMMI, помимо того, что предполагает наличие требований, требует, чтобы эти требования были согласованы, утверждены, актуальны, протрассированы к бизнесс потребностям, тест кейсам и пр., чтобы была система управления изменениями и т.д.
Попробуйте почитать CMMI. Если говорить CMMI-ными терминами, то, что нужны требования и какими они должны быть, описано в Specific Practices соответствующих Process Areas (в данном случае Requirements development and Requirements management), а то, как гарантировать, чтобы они были актуальны, доступны, известны, управляемы — в Generic Practices.
В нашем документе есть разделы, необходимые для Project Management Plan, соответствующие всем базовым требованиям разных стандартов (они все примерно одинаковы для PMP). Эти разделы должны
а) либо заполняться в самом документе, но во время, то есть до того, как этот раздел нужен для работы;
б) либо ссылаться на описание всей необходимой для этого раздела информации, которая хранится в другом файле или инструменте. При этом все эти файлы и инструменты должны быть сохранены в специально отведенном для PMP хранилище (например, как у нас, SharePoint библиотека на сайте проекта).
Эта информация, из каждого раздела PMP, независимо в каком формате она сохранена, обязательно должна быть:
а. доступна из PMP (я его назвала «регистр» информации и ссылок)
б. обязательно ревьюится всеми вовлеченными в работу по этому разделу людьми, а так же службой обеспечения качества (моя епархия)
в. формально утверждается и «бэйзлайнится». Заказчику не всегда нужно (и хочется) видеть весь документ целиком. С заказчиком формально утверждается то, что ему нужно и что нам нужно от заказчика. Все целиком формально утверждается службой обеспечения качества или менеджером данного account-a.
г. есть процесс управления изменениями, поэтому новые поступления либо вливаются в уже существующую информацию. Например, файл с описанием объема работ пересохраняется с новой версией.
Таким образом, PMP — консолидированный, формально утвержденный, используется для контроля и управления. Информация не разбросана по смс-кам и почтам, а хранится в одном месте и содержит актуальную информацию.
Что очень важно, эта информация всегда публикуется своевременно. И психологически легче для того, кто публикует и тех, кто читает. Это то же, что переслать письмо (часто это пересланное письмо и является новой версией документа).
— В вашем реестре отображается плановая дата завершения проекта?
Дата завершения проекта в нашем случае отражается в MS project-e. На MS Project, как на расписание, задачи, зависимости ссылаемся из PMP (регистра информации и ссылок). В том же PMP должна быть ссылка на контрактные условия (к сожалению, работа с контрактом у нас пока слабое место, поэтому пишу «должна быть»), в которых тоже прописана дата окончания проекта. Собственно оттуда она попадает в расписание, или наоборот (в зависимости от того, когда подписан контракт).
— С тем же успехом можно сказать, что CMMI требует, чтобы у проекта были требования… Значит у нас уже полный CMMI и проводить сбор-анализ-документирование-согласование требований уже не надо. :)
не совсем так, CMMI, помимо того, что предполагает наличие требований, требует, чтобы эти требования были согласованы, утверждены, актуальны, протрассированы к бизнесс потребностям, тест кейсам и пр., чтобы была система управления изменениями и т.д.
Попробуйте почитать CMMI. Если говорить CMMI-ными терминами, то, что нужны требования и какими они должны быть, описано в Specific Practices соответствующих Process Areas (в данном случае Requirements development and Requirements management), а то, как гарантировать, чтобы они были актуальны, доступны, известны, управляемы — в Generic Practices.
Теперь стало понятней, спасибо. :)
Я правильно понял вашу мысль, что «избавлением от бюрократии» стало то, что вместо формирования некоего документа по шаблону, вы теперь храните все артефакты относящиеся к планированию проекта в отдельной библиотеке SharePoint?
P.S. CMMI читал. Свой пример про требования хотел пометить тэгом sarcasm, но решил, что и так будет понятно…
Я правильно понял вашу мысль, что «избавлением от бюрократии» стало то, что вместо формирования некоего документа по шаблону, вы теперь храните все артефакты относящиеся к планированию проекта в отдельной библиотеке SharePoint?
P.S. CMMI читал. Свой пример про требования хотел пометить тэгом sarcasm, но решил, что и так будет понятно…
Процесс и инструментарий могут быть нам предложены (или подсмотрены у кого-то). И если он кажется нам тяжеловесным и бюрократичным, мы должны в первую очередь понять назначение процесса или документа, а потом научиться делать так, чтобы назначение выполнялось, но другим путем.
Я подчеркнул главную, на мой взгляд, мысль статьи.
Только я бы сформулировал еще жестче — понять назначение процесса / документа надо в любом случае — кажется он вам тяжеловесным или нет. :) Возможно он вообще не применим к вашему проекту.
В описании CMMI много сказано о том, что нужно делать. Но очень мало написано — зачем это нужно делать. И получаются две крайности:
Умудренные prodject management'ом гуру читают все эти практики по диагонали и думают — «Блин, ну ведь это же очевидные вещи, мы уже давно все так и делаем», потому что уже наступили на все грабли, от которых пытается спасти CMMI.
C другой стороны, начинающий PM читает описания практик, не понимает зачем они нужны, но «раз написано — надо делать». Отсюда и вырастает бюрократия и тяжеловесные процедуры.
Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.
Например, в Project Planning есть такой пункт: SP 2.6 Plan Stakeholder Involvement
Вроде бы написано, что надо делать, но начинающим PMам может быть не очевидно, что будет если этим пунктом пренебречь.
Я подчеркнул главную, на мой взгляд, мысль статьи.
Только я бы сформулировал еще жестче — понять назначение процесса / документа надо в любом случае — кажется он вам тяжеловесным или нет. :) Возможно он вообще не применим к вашему проекту.
В описании CMMI много сказано о том, что нужно делать. Но очень мало написано — зачем это нужно делать. И получаются две крайности:
Умудренные prodject management'ом гуру читают все эти практики по диагонали и думают — «Блин, ну ведь это же очевидные вещи, мы уже давно все так и делаем», потому что уже наступили на все грабли, от которых пытается спасти CMMI.
C другой стороны, начинающий PM читает описания практик, не понимает зачем они нужны, но «раз написано — надо делать». Отсюда и вырастает бюрократия и тяжеловесные процедуры.
Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.
Например, в Project Planning есть такой пункт: SP 2.6 Plan Stakeholder Involvement
Вроде бы написано, что надо делать, но начинающим PMам может быть не очевидно, что будет если этим пунктом пренебречь.
Согласна с Вами
Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.
очень хочу это сделать, я уже выше писала про идею «CMMI для чайников».
Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.
очень хочу это сделать, я уже выше писала про идею «CMMI для чайников».
Жаль что не написали еще. Все руки не доходят?
С одной стороны — руки не доходят, с другой — спокойнее стала относиться к непониманию, не задевает, а следовательно нет вдохновения :). К тому же пугает объем работы — Подобное описание означает Краткий курс Software Engineering, Project Management и управление организацией )))
Может, как-нибудь соберусь…
Может, как-нибудь соберусь…
Отличная статья! Поражает невежество и, своего рода, потребительский подход комментаторов — всё разжевывать нужно.
Со своей стороны есть несколько комментариев/вопросов.
1. Результаты анализа данных о прошедших (с 2006 г.) оцениваниях относительно модели CMMI, опубликованные SEI в сентябре 2011, показывают, что 66% оцениваний проведены в компаниях категории «1-100 человек», при этом внутри этой категории главные подкатегории «25 и менее» и «26-50». Сложно поверить в то, что небольшие компании могут обладать высокими уровнями CMMI. Насколько я понял из пояснения к первому мифу, достаточно высок процент небольших компаний, обладающих каким либо уровнем зрелости. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться — компания и ее сотрудники должны обладать высокой культурой ведения IT-бизнеса и хорошим пониманием процессов. Или, другими словами, все 50 человек включая девушку на ресепшне — это монстры своего дела, а о сотрудниках-джуниорах не может идти даже речи. Это при всём том, что для большинства процессных задач можно найти нужные и эффективные инструменты. Если большинство компаний небольшого размера имеют уровень не выше 3-го, тогда вопрос снимается. Вообщем, очень интересно было бы посмотреть на статистику.
2. Из практики (и из Agile Manifesto): несмотря на все желание быть Agile и работать с заказчиком ну очень близко, наша компания, обжегшись, все же взялась за усиление контрактной составляющей сотрудничества.
Не совсем понятно зачем понадобилось усиление контрактной составляющей. Неужели для того, чтобы заставлять заказчика что-то делать в соответствии с выстроенными процессами? :) Если заказчик хочет одновременно agile и cmmi, то он должен понимать что это серьезный коммитмент в интересах качества, а также иметь в виду усилия, которые со своей стороны нужно прикладывать. Если же в компании cmmi, a заказчик хочет agile и нужно их как-то подружить, то ОЧЕНЬ много зависит от адекватности заказчика. Часто слишком много усилий уходит для того, чтобы объяснить, почему процесс построен так, а не иначе. Я бы не стал предлагать/навязывать свои процессные модели заказчику если он не способен безболезненно в эти модели интегрироваться. А контрактные обязательства — это не всегда безболезненно.
3. CMMI будет оправдывать ожидания (и затраченные средства), если компания продает solution, управляет процессом удовлетворения бизнес потребностей клиента.
Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это. Так что не совсем обязательно, что CMMI аппрайзал не может быть использован для повышения эффективности аутсорсинговых компаний. Согласен с тем, что это несколько сложнее. Но если заказчик хочет и готов к сотрудничеству в этом направлении, то выстроить процессы может оказаться даже проще, чем для продуктовой компании.
Со своей стороны есть несколько комментариев/вопросов.
1. Результаты анализа данных о прошедших (с 2006 г.) оцениваниях относительно модели CMMI, опубликованные SEI в сентябре 2011, показывают, что 66% оцениваний проведены в компаниях категории «1-100 человек», при этом внутри этой категории главные подкатегории «25 и менее» и «26-50». Сложно поверить в то, что небольшие компании могут обладать высокими уровнями CMMI. Насколько я понял из пояснения к первому мифу, достаточно высок процент небольших компаний, обладающих каким либо уровнем зрелости. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться — компания и ее сотрудники должны обладать высокой культурой ведения IT-бизнеса и хорошим пониманием процессов. Или, другими словами, все 50 человек включая девушку на ресепшне — это монстры своего дела, а о сотрудниках-джуниорах не может идти даже речи. Это при всём том, что для большинства процессных задач можно найти нужные и эффективные инструменты. Если большинство компаний небольшого размера имеют уровень не выше 3-го, тогда вопрос снимается. Вообщем, очень интересно было бы посмотреть на статистику.
2. Из практики (и из Agile Manifesto): несмотря на все желание быть Agile и работать с заказчиком ну очень близко, наша компания, обжегшись, все же взялась за усиление контрактной составляющей сотрудничества.
Не совсем понятно зачем понадобилось усиление контрактной составляющей. Неужели для того, чтобы заставлять заказчика что-то делать в соответствии с выстроенными процессами? :) Если заказчик хочет одновременно agile и cmmi, то он должен понимать что это серьезный коммитмент в интересах качества, а также иметь в виду усилия, которые со своей стороны нужно прикладывать. Если же в компании cmmi, a заказчик хочет agile и нужно их как-то подружить, то ОЧЕНЬ много зависит от адекватности заказчика. Часто слишком много усилий уходит для того, чтобы объяснить, почему процесс построен так, а не иначе. Я бы не стал предлагать/навязывать свои процессные модели заказчику если он не способен безболезненно в эти модели интегрироваться. А контрактные обязательства — это не всегда безболезненно.
3. CMMI будет оправдывать ожидания (и затраченные средства), если компания продает solution, управляет процессом удовлетворения бизнес потребностей клиента.
Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это. Так что не совсем обязательно, что CMMI аппрайзал не может быть использован для повышения эффективности аутсорсинговых компаний. Согласен с тем, что это несколько сложнее. Но если заказчик хочет и готов к сотрудничеству в этом направлении, то выстроить процессы может оказаться даже проще, чем для продуктовой компании.
Спасибо за понимание :)
Попробую ответить:
1. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться
Статистика не засекречена, смотрите тут http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011SeptCMMI-2.pdf.
В целом, Вы правы, чаще они идут на 2-3 уровень. Но выше им и не надо. Уровень 3 покрывает практически все необходимое. Уровень 4 требует очень большого прыжка и зрелости и людей и компании. Когда у компании появляется все необходимое для 4 уровня, она уже, скорее всего, выросла больше 100 человек :).
2. Не совсем понятно зачем понадобилось усиление контрактной составляющей.
Наш менеджмент решил, что нам надо быть ну очень Agile. Делали ставку на постоянное общение с заказчиками, не закрепляя практически ничего в контрактах. Потеряли деньги, пришлось ввязаться чуть ли не в суд, то есть опять растраты… ну и прочее. В общем, обожглись на «слабой контрактной составляющей».
По поводу навязывания процессных моделей. Речь не о навязывании процессных моделей, а про адаптацию (tailoring) процесса. Если мы работаем по bodyshop модели — мы ничего не навязываем, как я и писала. Если мы берем на себя управление проектом, а соответственно и процессом, мы адаптируем процесс под конкретные условия. (Ну или стараемся это делать).
3. Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это.
Это работает тогда, когда заказчик хочет наладить процесс получения продукта или услуги. Я не слышала никогда о таких заказчиках, которые применяют CMMI for Acquisition для этого. В общем, аутсорсинговая организация не может быть инициатором, вернее, это уж точно будет навязыванием клиенту процессных моделей :). Тут скорее интересно побольше узнать по CMMI for Services. Но эта модель еще слишком молода, и лично у меня еще не дошли до нее руки.
Попробую ответить:
1. Интересно было бы подробнее узнать, какие это уровни. Не уверен что коллективу из 50 человек может быть нужен 4-й уровень, а если даже и нужен, то непонятно как этот уровень в естесственных (не навязанных заказчиком, менеджментом, еще кем либо) условиях может поддерживаться
Статистика не засекречена, смотрите тут http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2011SeptCMMI-2.pdf.
В целом, Вы правы, чаще они идут на 2-3 уровень. Но выше им и не надо. Уровень 3 покрывает практически все необходимое. Уровень 4 требует очень большого прыжка и зрелости и людей и компании. Когда у компании появляется все необходимое для 4 уровня, она уже, скорее всего, выросла больше 100 человек :).
2. Не совсем понятно зачем понадобилось усиление контрактной составляющей.
Наш менеджмент решил, что нам надо быть ну очень Agile. Делали ставку на постоянное общение с заказчиками, не закрепляя практически ничего в контрактах. Потеряли деньги, пришлось ввязаться чуть ли не в суд, то есть опять растраты… ну и прочее. В общем, обожглись на «слабой контрактной составляющей».
По поводу навязывания процессных моделей. Речь не о навязывании процессных моделей, а про адаптацию (tailoring) процесса. Если мы работаем по bodyshop модели — мы ничего не навязываем, как я и писала. Если мы берем на себя управление проектом, а соответственно и процессом, мы адаптируем процесс под конкретные условия. (Ну или стараемся это делать).
3. Интересно было бы узнать о практике применения CMMI для аутсорсинга. Ведь есть отдельный раздел — CMMI for Acquisition, ориентированный на это.
Это работает тогда, когда заказчик хочет наладить процесс получения продукта или услуги. Я не слышала никогда о таких заказчиках, которые применяют CMMI for Acquisition для этого. В общем, аутсорсинговая организация не может быть инициатором, вернее, это уж точно будет навязыванием клиенту процессных моделей :). Тут скорее интересно побольше узнать по CMMI for Services. Но эта модель еще слишком молода, и лично у меня еще не дошли до нее руки.
Sign up to leave a comment.
Мифы о CMMI, или кому и зачем она нужна