С одной стороны — руки не доходят, с другой — спокойнее стала относиться к непониманию, не задевает, а следовательно нет вдохновения :). К тому же пугает объем работы — Подобное описание означает Краткий курс Software Engineering, Project Management и управление организацией )))
Может, как-нибудь соберусь…
ISO сертификация может также и увеличить количество менеджеров ))) если неправильно внедрять. А если правильно — то все сертификации типа ISO предполагают наличие бизнес-процессов, которые дают представление об ожидаемом результате, точно указывают кто это должен делать и кому при каких условиях отдавать. Так сокращается время на ожидание указаний-фидбэков, вероятность того, что сделают не то, что нужно, то есть переработки.
Правильно подобранные тулзы дают возможность получать инфу без привлечение специальных сборщиков, в том числе координаторов.
Количество менеджеров легко сокращается при наличии работающих бизнес-процессов и ответственностей, встроенных в процесс. Бизнес-процесс указывает куда обратиться по какому вопросу и откуда какие данные взять. А для этого еще и инструментарий нужен, более продвинутый, чем excel. В общем, думать нужно.
А до тех пор без менеджеров никуда, кто ж будет всю инфу собирать, передавать (!) и в excel запихивать :)
Спасибо за понимание :)
Попробую ответить: 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. Но эта модель еще слишком молода, и лично у меня еще не дошли до нее руки.
Согласна с Вами Было бы здОрово, если бы кто-нибудь разобрал 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.
— Фишка в том что полезной она может быть только в случае если сама организация достаточно созрела для оптимизации и ее кадры понимают что делают. Но такой организации как правило уже не нужен костыль в виде формальных правил СММ.
Согласна! Но чтобы созреть и понимать, можно идти своим собственным путем проб и ошибок, не умея применять чужой опыт или отвергая его в принципе. (В данном случае, мне кажется, что многие комментаторы даже не пробовали читать CMMI, и я их понимаю, слишком уж много текста.)
Другой путь — все таки взять на вооружение такие модели, как CMMI. Но взять на вооружение должно руководство, чем выше, тем лучше. Индивидуальный забег проджект менеджера или тим лида может привести к конфликту, разочарованию, или, в лучшем случае, к успеху этого конкретного проекта и этого конкретного менеджера.
Все мы ходили в школу, читали учебники в институтах. Сейчас мы их уже, может быть кто-то за редким исключением, не перечитываем. Потому что созрели и поняли, и запомнили. То же и с моделями зрелости, стандартами и т.д.
Не совсем согласна. Снова получим плохую тушенку в случае если
а. менеджер будет пренебрегать этапами процесса,
б. менеджер не будет реагировать на метрики и другие знаки того, что процесс вышел из под контроля, и
в. требования к выходному продукту каждого этапа производства будут снижены
или не будут проверяться (что есть пренебрежение процессом)
Можно наладить суперский процесс производства продукции разных сортов. Даже той тушенки о которой Вы говорите. Процесс гарантирует однородность и повторяемость. Если вся тушенка одинаково «дерьмовая», то производство преуспело в процессе :).
Другое дело, стоит ли за производством задача улучшения и роста. Вероятно у производителя этой тушенки — нет. Возможно, производителя устраивает и спрос и себестоимость.
У каждой статьи свой читатель. Значит Вы знаете много. Мой опыт показывает, что далеко не все такие образованные в этом плане.
Я пишу статьи чтобы «забэйзлайнить» свои мысли. Возможно, я до Вас еще не доросла.
По поводу примеров я уже писала в ответах на предыдущие комментарии. Целью этой статьи не было ни продвижение CMMI в массы, ни рассказ об успехах его применения.
Наоборот, я говорю об ошибках, которые совершили мы, поверив в мифы про CMMI.
Да я, собственно, не агитирую. Более того, мыслью подтолкнувшей меня на написание статьи было «не трогайте CMMI, если Вам это действительно не надо». Кому и зачем надо — я написала. Так же, сделала акцент на том, что применение (реализация конкретных практик) зависит от профессионального кругозора тех кто применяет и от знания всей модели, а не отдельных ее частей.
Как я уже ответила уважаемому 1nd1go, который просил больше примеров, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :). Я привела несколько жизненных примеров, когда стоит и когда не стоит применять CMMI, пару примеров реализации практик. Задачей этой статьи не было объяснение большинства практик простыми словами. Те пример, которые я привела, показывают, что это возможно.
Востребованность я поняла. Постараюсь оправдать Ваши надежды.
— компания сама не может быть стандартизована по CMMI, стандартизуется отдел или проект.
Отдел или подразделение — Да. Но не проект. Хотя, если этот проект тянет на подразделение — то можно и так сказать:). В обиходе говорят «компания», имея ввиду, что в рамках этой компании есть подразделение, которое оценено на такой-то уровень. Так вот и у нас: есть bodyshop, который, разумеется, не входил в группу оцениваемых проектов.
Однако, так как CMMI касается не только проектного управления, но и организационного, то даже при сосуществовании полного цикла оказания услуги и bodyshop есть общие организационные процессы, такие как, например, развитие персонала (в CMMI — Organizational Training).
— Сомневаюсь (работаю в CMMI5 компании).
Ваше право. Но нут возможны вопросы:
а) играет ли этот статус какую-то роль для ваших клиентов? Если нет, то он и не будет пытаться вас «раскусить». (это по поводу маркетинга)
б) работали ли Вы в «неCMMI5» компании? И как долго работали там и там? если да, работали и достаточно долго, то тогда действительно интересно услышать Ваше мнение по поводу сравнения этих компаний.
в) Вы работаете в том подразделении, которое проходило оценивание? Или, скажем, в другом офисе этой компании (или в другом направлении)? Тоже интересно, есть ли отличия.
Ну и, в конце концов, про Level 5. Судя по тому, что я слышала, этому мало кто доверяет. Как сказал один из наших потенциальных клиентов, «я буду работать с Level 3, так как тут меньше шансов фальсификации».
Может, как-нибудь соберусь…
Правильно подобранные тулзы дают возможность получать инфу без привлечение специальных сборщиков, в том числе координаторов.
А до тех пор без менеджеров никуда, кто ж будет всю инфу собирать, передавать (!) и в excel запихивать :)
Попробую ответить:
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. Но эта модель еще слишком молода, и лично у меня еще не дошли до нее руки.
Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.
очень хочу это сделать, я уже выше писала про идею «CMMI для чайников».
Да :)
пример про требования хотел пометить тэгом sarcasm, но решил, что и так будет понятно
понятно, я на всякий случай расписала
В нашем документе есть разделы, необходимые для 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.
Согласна! Но чтобы созреть и понимать, можно идти своим собственным путем проб и ошибок, не умея применять чужой опыт или отвергая его в принципе. (В данном случае, мне кажется, что многие комментаторы даже не пробовали читать CMMI, и я их понимаю, слишком уж много текста.)
Другой путь — все таки взять на вооружение такие модели, как CMMI. Но взять на вооружение должно руководство, чем выше, тем лучше. Индивидуальный забег проджект менеджера или тим лида может привести к конфликту, разочарованию, или, в лучшем случае, к успеху этого конкретного проекта и этого конкретного менеджера.
Все мы ходили в школу, читали учебники в институтах. Сейчас мы их уже, может быть кто-то за редким исключением, не перечитываем. Потому что созрели и поняли, и запомнили. То же и с моделями зрелости, стандартами и т.д.
а. менеджер будет пренебрегать этапами процесса,
б. менеджер не будет реагировать на метрики и другие знаки того, что процесс вышел из под контроля, и
в. требования к выходному продукту каждого этапа производства будут снижены
или не будут проверяться (что есть пренебрежение процессом)
Тут всех пугает кажущаяся сложность текста. Поэтому читать стоит людям подкованным в нескольких инженерных и управленческих областях.
И потому же я теперь уже однозначно буду писать «CMMI для чайников» :).
Не сработать может по двум причинам — либо клиент на это «не клюет», либо «клюнул», потом приехал посмотрел своими глазами и разочарованный уехал.
Другое дело, стоит ли за производством задача улучшения и роста. Вероятно у производителя этой тушенки — нет. Возможно, производителя устраивает и спрос и себестоимость.
Я пишу статьи чтобы «забэйзлайнить» свои мысли. Возможно, я до Вас еще не доросла.
По поводу примеров я уже писала в ответах на предыдущие комментарии. Целью этой статьи не было ни продвижение CMMI в массы, ни рассказ об успехах его применения.
Наоборот, я говорю об ошибках, которые совершили мы, поверив в мифы про CMMI.
Как я уже ответила уважаемому 1nd1go, который просил больше примеров, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :). Я привела несколько жизненных примеров, когда стоит и когда не стоит применять CMMI, пару примеров реализации практик. Задачей этой статьи не было объяснение большинства практик простыми словами. Те пример, которые я привела, показывают, что это возможно.
Востребованность я поняла. Постараюсь оправдать Ваши надежды.
Абсолютно с Вами согласна. Как я уже писала, я не фанатка CMMI, очень долго сама пыталась разобраться что к чему :)
— можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах
Могу, возможно не все, но вот пару примеров в статье привела. В принципе, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :).
Отдел или подразделение — Да. Но не проект. Хотя, если этот проект тянет на подразделение — то можно и так сказать:). В обиходе говорят «компания», имея ввиду, что в рамках этой компании есть подразделение, которое оценено на такой-то уровень. Так вот и у нас: есть bodyshop, который, разумеется, не входил в группу оцениваемых проектов.
Однако, так как CMMI касается не только проектного управления, но и организационного, то даже при сосуществовании полного цикла оказания услуги и bodyshop есть общие организационные процессы, такие как, например, развитие персонала (в CMMI — Organizational Training).
Не дает. CMMI говорит о потенциальных возможностях. Но не гарантирует, что каждый проект будет идеальным.
Ваше право. Но нут возможны вопросы:
а) играет ли этот статус какую-то роль для ваших клиентов? Если нет, то он и не будет пытаться вас «раскусить». (это по поводу маркетинга)
б) работали ли Вы в «неCMMI5» компании? И как долго работали там и там? если да, работали и достаточно долго, то тогда действительно интересно услышать Ваше мнение по поводу сравнения этих компаний.
в) Вы работаете в том подразделении, которое проходило оценивание? Или, скажем, в другом офисе этой компании (или в другом направлении)? Тоже интересно, есть ли отличия.
Ну и, в конце концов, про Level 5. Судя по тому, что я слышала, этому мало кто доверяет. Как сказал один из наших потенциальных клиентов, «я буду работать с Level 3, так как тут меньше шансов фальсификации».