Кому и зачем нужна CMMI

CMMI — аббревиатура английского выражения Capability Maturity Model Integration, комплекс моделей развития и совершенствования процессов, или, как принято интерпретировать это понятие у нас, модель, по которой оценивается зрелость компании.

Оценка производится по потенциалам:

• производственному
• техническому
• управленческому

Модель создана в Питтсбурге, в институте разработки программного обеспечения (SEI). В процессе знакомства с этим фреймфорком интересующиеся, как правило, заявляют, что сам по себе он хорош, но слабо применим в реальных условиях. Некоторая часть воспринимает модель достаточно скептически изначально, кто-то разочаровывается позже из-за своих слишком высоких ожиданий относительно неё.

Предупрежу сразу, к фанатам CMMI я не отношусь, но вот уже на протяжении пяти лет моя повседневная работа — поддерживать соответствие компании CMMI Level 3. Должен признаться, что деятельность эта требует полной отдачи, и связано это, прежде всего с немалым количеством мифов о CMMI.

Появление мифов обусловлено целой серией причин:

• во-первых, это большое количество доводов о пользе данной модели, которыми пестрят все публикации рекламного характера;
• во-вторых, это известные примеры повышения эффективности трудового процесса в компаниях высочайшего уровня, как например «Боинг»;
• в-третьих, это попытки внедрить модель в российские компании с последующими возгласами о том, что «ничего не изменилось»,
• это и опыт совместной деятельности с компаниями из Индии, которые сами себя позиционируют как соответствующие CMMI Level 5;
• сюда же включаем пункт о большом объёме непонимания того, каким же образом нужно использовать CMMI, чтобы она приносила ощутимую пользу.

Таким образом, цель данной статьи — попытаться развенчать мифы, поколебать позиции скептиков, и помочь тем, кто хотел бы использовать CMMI, но нуждается в советах и помощи.

Для тех, кто впервые столкнулся с понятием CMMI, представлю её с максимумом наглядности.

Имеется программист начального уровня, владеющий определённым количеством базовых навыков. Для того чтобы перейти на следующий уровень, и стать программистом второго уровня, количество базовых навыков должно быть расширено, программист должен приобрести некоторые специальные навыки, овладеть инженерными практиками. Перейдя на следующий уровень, программист получит большую зарплату, и клиенты будут ему больше доверять.

Этот же алгоритм можно применить к компании. После того, как она выполнит определённые практики, она повысит свой уровень зрелости, так называемый maturity уровень. Одновременно повысится уровень доверия к компании от партнёров и клиентов. Рассмотрим по порядку те мифы, в которых раскрываются причины недостаточного приятия CMMI.

Миф № 1. Модель применима только в очень крупной компании

Если посмотреть на статистические данные, начиная с 2006 года, которые осенью 2011 года опубликовал SEI, окажется, что 66% оценивающихся по CMMI — это компании с количеством сотрудников «1-100 человек», причём большая часть из них ещё мельче: «до 25 человек» и «26-50 человек».

Оценивание — процедура недешёвая, поэтому участвовать в официальном оценивании может лишь компания, на счету которой есть на это свободные средства, при этом, только тогда, когда считает эту процедуру полезной.

Сумма, затраченная на оценивание для очень крупной компании, будет для неё не столь значительной. Но остаётся вопрос: а нужно ли это большой компании?

CMMI нацелена на усиление эффективности процесса работы в компании, что естественно, так как она является моделью управления процессом деятельности. Отсюда следует, что заинтересованы в ней те, кто процессом работы управляет, то есть делает процесс эффективным, удовлетворяющим потребности клиентов, и снижающим себестоимость.

Теперь рассмотрим особенности ведения бизнеса в достаточно крупных украинских и российских компаниях. Для украинского outsource-а характерна прямая отдача людей в пользование иностранным клиентам, в организацию (IT), которая занимается процессом управления (здесь используется термин Bodyshop), но не принятиями решений (solution) относительно услуг, направленных на решение бизнес — целей клиентов. Хочу оговориться, ничего плохого или неправильного в компаниях первого типа нет, это разные подходы к ведению бизнеса. Тогда получается, что если мы не управляем процессом, совсем неочевидно, что CMMI окажется для нас выгодным вложением. Компания, не управляющая процессом работы, не сможет применить то, что рекомендует и требует CMMI, и её использование будет полезно лишь для общего развития и получения опыта.

По-другому обстоит дело в небольших компаниях. Они осуществляют весь цикл оказания услуги клиенту, сами отвечают за процесс работы, регулируя и управляя им. И поэтому должны обратить внимание на CMMI. Почему я употребил, и даже пытаюсь подчеркнуть слово «должны»? Потому что таким образом они получают целое учебное пособие с уроками, которые уже сумели извлечь из своих ошибок компании из разных стран. К слову, переход на новые версии модели — это добавление туда новых и новых уроков с учётом новых реалий в производстве программных продуктов. Это огромное количество уроков. Вряд ли мы такие оригинальные, что нам это не пригодится, и не понадобится.

А как именно можно обратить внимание на CMMI?

Можно сделать это

• стандартным, формальным способом, произведя официальное оценивание с последующим занесением в соответствующий регистр SEI (это обойдётся дороже);
• или неформально, прибегнув к услугам консультантов. Это обойдётся несколько дешевле;
• можно всё выполнить и самостоятельно, что обойдётся и ещё дешевле. Однако при этом следует помнить, что ROI, верность и адекватность понимания, и соответствующее серьёзное отношение, как правило, прямо пропорционально стоимости.

Миф № 2. CMMI — ничто иное как маркетинговый ход, хотя и эффектный

Возвращаемся к предыдущей логической цепочке. Если бизнес — это bodyshop в чистом виде, то ваши потенциальные клиенты действительно будут не слишком заинтересованы в вашей сертификации. Исключение составит случай, когда они хотят приобрести «систему» полностью, включая управление. Ну, или они уже ранее работали в «системе».

Допустим, ваш бизнес ориентирован на продажу собственных решений, тогда маркировка «rated at CMMI level… n» будет полезной. Наличие сертификата будет означать, что в компании умеют управлять процессом, и смогут предложить хорошее качество в минимальные сроки и по невысокой цене. В таком случае будет спокойнее и клиенту: ему не придётся вмешиваться в процесс, затрачивая свои нервные клетки.

Заинтересованные клиенты нередко организуют тендеры, где условием победы как раз и является официальное подтверждение соответствия компании уровню зрелости по CMMI. Как правило, это компании в IT- области, которым нужна не дешёвая рабочая сила, а субподрядчики, или же те структуры, которые сами производством программных продуктов не занимаются (например, банки).

Статус CMMI будет полезен и тогда, когда компания выходит на рынок с собственными

продуктами.

Речь идёт именно о статусе, и его вполне можно предъявить как коллегам, так и заказчикам. Однако если пройдёт время, допустим 2-3 года, и вы всё уже забудете, умные клиенты поймут это очень быстро. То же касается и ситуации, когда компания оценивает по CMMI один свой филиал, или подразделение, а затем заявляет, что определённый уровень зрелости по CMMI распространяется и на остальные подразделения тоже. Следует учесть, что оказаться оцененным во много раз проще, чем поддерживать потом этот статус во времени, или распространяя на другие подразделения компании.

Подчеркну свою мысль: если ваша компания планирует использовать CMMI в целях маркетинга, и заказчик ждёт работу в полном соответствии с сертификатом, следует использовать те практики и навыки, о которых говорится в модели.

Предвижу возражения такого плана: мы продаём самостоятельное решение, но являемся при этом мелким бизнесом или фрилансом. Мы и рады бы работать в рамках статуса, но заказчику такой формат не интересен. Вариантов тут может быть несколько:

• либо работа с заказчиком ведётся в неверном ключе;
• либо правила и установки применяются слишком прямолинейно, без подстройки к конкретным условиям;
• ещё одно возможное объяснение — отношение заказчика к фрилансу. Тот, кто пользуется услугами фриланса, вряд ли оценит маркетинговое значение CMMI.

Миф № 3: CMMI – это по большей части — бюрократия

Модель как таковая не даёт конкретных указаний на тему: как именно вам следует работать, и какие процессы и документы вам нужно подготовить. Она направлена на то, чтобы рекомендовать действия, а не ведение документации. И эти действия выполняются в рамках стандартных инженерных практик, которые производятся для того, чтобы качество продукта или услуги имели бы соответствующую гарантию.

Посмотрим на бизнес — модели. Для того чтобы клиент остался доволен при продаже рабочей силы, CMMI не обязательно, обязательно лишь качественно и грамотно выполнить работу в рамках процесса, установленного клиентом. Вполне вероятно, что клиентский процесс — бюрократичен сам по себе, но вы действуете в рамках полученной инструкции, и в управлении процессом принимаете лишь минимальное участие, вы о степени бюрократизации можете не подозревать.

Другой разговор, когда вы выполняете полный цикл работ. Здесь инженерные практики, рекомендованные CMMI — оказываются незаменимыми. Например, checklist. Однако при этом необходимо следить за тем, что все наши действия укладываются в бизнес — потребности клиента относительно услуги или продукта, и что мы от этих потребностей не отходим в сторону. Именно этого от нас и требует модель. Каким образом мы сможем удовлетворять бизнес – потребности, зависит от нас. Работа может выполняться= бюрократично, или же мы сможем подобрать инструменты, её облегчающие, и позволяющие избежать ошибок.

Требования CMMI: обмен знаниями, умение учиться на своих ошибках, как в рамках самого процесса работы, так и в рамках его последующего анализа. Уровень формализации процесса при этом определяем мы сами.

Опыт работы позволяет заметить, что чем более бюрократичен и формален уровень, тем меньше у людей, устанавливающих процесс, профессионализма. Дело не в том, что умным людям нужно меньше записывать, а просто в силу более успешной оптимизации работы с базами данных и документацией. Оптимизация позволяет вместо пяти документов создать только два. Но процесс при этом будет идти так, что документы будут использоваться 5-ю сотрудниками, или применяться в 5-и процессах.

Позвольте привести несколько примеров, они как раз связаны и с бюрократией, и с возможностями оптимизации работы. Примеры — наглядная демонстрация того, что бюрократию и тяжеловесность мы создаём сами, а не вместо нас это делает CMMI.а) CMMI обязывает иметь консолидированные планы работ. Мы разработалишаблон Project Management Plan, который должны были написать нашименеджеры, а остальные сотрудники должны были прочитать. Мы прошли подругому пути и создали процесс Планирование Проекта. Что получилось: нашиPMP создавались уже ближе к концу проекта, поэтому ин в общем случае и непрочли. Но вся нужная для этого документа информация уже существовала кначалу работы над проектом: в картинках и письмах, в инструментах. Если естьрегистр информации, в регистре имеются ссылки на её источники, это полностьюрешает проблему наличия PMP, удовлетворяя требованиям CMMI. А никакойбюрократии здесь нет.б) CMMI обязывает поддерживать traceability между конечным продуктом и бизнес- потребностями клиента на всех этапах процесса. Это означает необходимостьналичия тестовой документации, спецификаций, других видов документов. Что мысделали: настроили конкретный инструмент, например багтрекер, или таблицу вexcel, и получили матрицу, Requirements Traceability Matrix, позволяющую следитьза трансформацией требований в сам продукт и его компоненты.

Вполне вероятно, что и сам процесс, и инструменты нам предложили, или же мы их увидели у кого- то. Если они кажутся нам бюрократичными, мы должны поступить так: понять их назначение и постараться сделать, чтобы назначение выполнялось, но не таким тяжеловесным путём. Назначение и цель практик CMMI применимы всегда, а вот процедуры и документы могут оказаться плохо применимыми, но это зависит не от модели.

Миф № 4: CMMI нельзя использовать в Agile-проектах

На конференции Agileee уже звучал доклад на эту тему, встречается и другая информация. Дело в том, что CMMI к методикам ведения проекта никак не привязана, не привязана она и к SDLC. Единственная её привязка, это управленческие и инженерные практики. В любой модели разработки эти практики одинаковы, будь это итеративная модель, или же водопадная, Agile или RUP методология.

В последних версиях то, как именно практика работает с Agile методами, специально выделено в каждом разделе. Всё просто: модель CMMI говорит нам, что именно надо делать, а практики Agile рассказывают нам, каким образом это делается.

Миф № 4 подпитывается спекуляциями, касающимися Agile Manifesto. Термин «over», который встречается в манифесте, указывает на процессы, коммуникации, документы, сам рабочий продукт, и тому подобное. И это именно «over», а не «instead». Судя по опыту работы, и исходя из Agile Manifesto, можно заключить, что при всём желании называться Agile, и близко работать с заказчиком, наша компания получила негативный опыт и занялась усилением контрактной составляющей сотрудничества.

Один не слишком простой момент касается передачи знаний. Адепты Agile утверждают, что знания передаются в процессе работы как результат личного общения. Требования модели — это несколько другое, Collect Process Related experience. Цель передачи знания здесь — повторяемость успешной практики, вне зависимости от того, переданы ли они лично преемнику в процессе работы, или же нет. В настоящее время с процессом Knowledge Management не всё идёт гладко, и в успехе или неудаче большую роль продолжает играть человеческий фактор.

Нужно отметить, что под человеческим фактором ни в коей мере не оспариваются авторское право, или чей-то личный опыт. Не идёт здесь речь и о необходимости такой системы, где человек — лишь винтик в точно обозначенном месте. Речь о другом. Только о передаче знаний, о рисках, возможных ошибках, способах, которые уже помогли кому-то их избежать. Речь идёт о хорошо зарекомендовавших себя практиках, их можно будет использовать и в следующих проектах, передавать от одной команды к другой, если люди в команде разные.

Вывод: цель CMMI не только успешное выполнение конкретного проекта, нужное в первую очередь проектным менеджерам, но и обеспечение непрерывности бизнеса, и поэтому требуется и руководителям компании. Примером здесь может послужить история с необходимостью усиления контрактной части.

Миф № 5: Нужно назначить того, кто в компании будет отвечать за работу по CMMI

Такое случается нередко: назначают человека, который для клиента находится на далеко не первом месте по важности. Это и понятно, ценные кадры занимаются «настоящей» работой, и не отвлекаются на менее значимые вещи. Ответственный, как правило, является специалистом в смежных областях, с процессным подходом знаком по- минимуму, авторитет у него не настолько высок, чтобы держать под контролем, а тем более требовать. В этом случае наблюдается парадокс: CMMI и «настоящая работа» не зависят друг от друга, существуют параллельно. Ответственный пытается навязываться занятым важным делом специалистам, даже и тем, которые занимаются не слишком знакомыми ему сферами производства, со своим CMMI, что вызывает у специалистов оправданное сопротивление. Получается, что этот ответственный в какой-то степени отвлекает от плодотворной работы, привнося дополнительные задачи. А ведь они ещё и не согласованы с клиентом! Ситуация не идёт на пользу CMMI, поэтому внедряться модель будет очень медленно и неэффективно.

Но ведь это не просто модель, а модель управления производством ПО. Так что, чем на более высоком уровне находится менеджмент компании, который понимает нужность инженерных и управленческих практик, и считает, что успех в бизнесе прочно с ними связан, тем выше вероятность, что в копании будет успешно внедрена CMMI .

В ISO 9000 особое внимание уделяется management commitment, и заключается это не в том, что менеджмент согласен с необходимостью иметь систему управления качеством, а в том, что этот менеджмент действительно готов и занимается улучшением процесса производства, считая его самым важным условием развития бизнеса. Менеджер, занимающийся системой управления качеством, и требующий такого же подхода от подчинённых, даёт системе возможность жить и совершенствоваться. В этом случае оценивание на уровень CMMI не будет восприниматься как рискованное и дорогое мероприятие.

Подводим итоги. CMMI. Зачем и кому это нужно

• Руководству компании, как маркетинговое условие развития бизнеса при фактическом применении практик модели;
• Руководству компании, чтобы оценить возможную степень доверия субподрядчику;
• Менеджерам всех звеньев в качестве checklist, с целью диагностики рисков и ошибок;
• Техническим специалистам и менеджерам для обеспечения профессионального роста. Это работает при условии веры в то, что предложенные практики не только имеют смысл, но и действуют в конкретных условиях. Условия, при которых модель действительно оправдает вложенные средства:
• Руководство компании понимает, какие именно улучшения процесса смогут обеспечить должный бизнес-эффект;
• Сама компания продаёт не рабочую силу, а solution, и самостоятельно удовлетворяет бизнес — потребности клиентов;
• «Ответственные», внедряющие модель — сами специалисты с широким профессиональным кругозором, не только инженерным, но и управленческим. Этот пункт действует, если они при этом работаю т в команде.
• Модель должна быть понятна целиком, а не только в виде отдельных областей, например, только управления, или только технической области.