Вначале об аббревиатуре: Capability Maturity Model Integration (CMMI) — модель оценки зрелости компании, основанная на ее производстенном, техническом и управленческом потенциале. Разработана она Software Engineering Institute. Подробно о ней писалось в хабрастатьях: Модель CMMI и Как наша компания получила 3 уровень CMMI.
Будучи «внедренной» в CMMI вот уже 5 лет, я часто сталкиваюсь с запросами и суждениями относительного этого фрэймфорка, которые, в целом, можно свести к следующему «Это конечно хорошо, но невозможно в реальных условиях». Кто-то скептически настроен с самого начала, кто-то разочарован (прежде всего, из-за чрезмерных ожиданий). Я не являюсь ни «апологетом», ни фанатом CMMI, но моя непосредственная работа заключается в поддержании соответствия компании CMMI Level 3. Это требует, прежде всего, очень серьезных моральных усилий. Связано это, на мой взгляд, с распространенностью ряда мифов о CMMI, которые появились в силу логических доводов о пользе модели (которые приводятся во всей «рекламной» литературе), примеров повышения эффективности работы в таких «монстрах» как «Боинг», попыток внедрения в отечественных компаниях (после чего в них «ничего не изменилось»), и опыта работы с индийскими компаниями, которые позиционируют себя как соответствующие CMMI Level 5. И еще с непониманием того, как и когда стоит использовать модель, чтобы она приносила пользу.
В статье я попытаюсь «развенчать» некоторые мифы, развеять скептицизм, и, возможно, мне удастся помочь тем, кто хочет использовать CMMI, но не знает как.
Для тех, кто ничего не знает о CMMI, я обычно представляю его следующим образом.
Junior программист обладает какими-то базовыми навыками. Чтоб стать Mid-ом, то есть перейти на следующий профессиональный уровень, он должен обрести определенные навыки, изучить некоторые инженерные практики. На этом уровне и доверия к программеру будет больше, и зарплата, соответственно. Та же схема применима и к организациям. Выполнение определенных практик на уровне компании ведет к повышению так называемого maturity уровня (уровня зрелости), а следовательно, и доверия со стороны клиентов и партнеров.
Перейдем, пожалуй, к мифам, которые раскрывают причины сопротивления CMMI и, надеюсь, укажут на возможности правильного использования модели.
Результаты анализа данных о прошедших (с 2006 г.) оцениваниях относительно модели CMMI, опубликованные SEI в сентябре 2011, показывают, что 66% оцениваний проведены в компаниях категории «1-100 человек», при этом внутри этой категории главные подкатегории «25 и менее» и «26-50».
Однако, надо понимать, что удовольствие это дорогое, поэтому пойти на официальное оценивание может только та компания, у которой есть эти, относительно свободные, деньги. И те, кому это действительно нужно. Логично предположить, что сумма «на CMMI» для больших компаний будет не такой пугающей, как для маленьких. Но нужно ли им это?
Прежде всего, надо понимать, что CMMI – это модель управления производством/услугой, она ориентирована на повышение эффективности процесса. То есть, она нужна тем, кто управляет процессом работы, делая его более эффективным в плане удовлетворения бизнес потребностей клиента и снижения себестоимости производства.
Обратимся же теперь к особенностям бизнеса относительно крупных компаний на украинском и, я думаю, российском рынках. Есть организации (особенно характерно для отечественного outsource-а), которые продают людей во власть заграничного клиента – в IT организацию, которая и управляет процессом работы (мы называем это Bodyshop), но не решения (solution), услуги удовлетворяющий бизнес цели клиента. Я ни в коем случае не хочу сказать, что компании первого типа – плохие, это просто разные подходы к ведению бизнеса. Но если мы не управляем процессом, нужно очень хорошо подумать, будет ли CMMI экономически выгодным вложением капитала. Скорее всего, в такой компании просто не будет возможности применить то, что требует и рекомендует CMMI. Хотя, в образовательном плане не помешает.
При этом, небольшие компании, которые занимаются полным циклом предоставления услуги клиенту, отвечая за процесс, управляя процессом работы, должны (я намеренно употребляю это слово) обратить внимание на CMMI. Почему должны? Потому что это сборник уроков, которые извлекли из своих ошибок огромное количество компаний по всему миру. (Кстати, изменение версий модели – это добавление новых уроков, учитывая новые тенденции и реалии в мире производства программного продукта.) Это глобальный Lessons Learnt. Неужели мы такие уж особенные, что для нас это не актуально?
«Обратить внимание» можно формально, через официальное оценивание с занесением в регистр SEI, (дороже) и неформально, с помощью консультантов (дешевле) или самостоятельно (еще дешевле). Однако, надо понимать, что корректность понимания, серьезность отношения и ROI прямо пропорциональны стоимости (чаще всего).
Тут все просто, учитывая предыдущий тезис. Если Ваш бизнес – чистый bodyshop, то для Ваших потенциальных клиентов наличие сертификации не имеет особого значения. Разве что, они ищут таких людей, которые уже работали в «системе», или покупаю «систему» целиком, вместе с управлением.
Если бизнес ориентируется на продажу самостоятельных решений, то лейбл «rated at CMMI level …» действительно может сыграть на руку, так как ожидается что в этой компании умеют управлять процессом и могут предоставить лучшее качество в меньшие сроки, соответственно за меньшие деньги. И клиенту будет меньше мороки, не придется вмешиваться и нервничать. Часто такие клиенты организовывают тендеры, выставляя условием наличие официально подтвержденного соответствия определенному уровню зрелости по модели CMMI (как в уже указанной мной хабрастатье). Это IT компании, которые ищут субподрядчиков, а не дешевую рабочую силу, или организации, которые сами не занимаются производством ПО (банки и пр.)
Очень полезен CMMI статус, также, в случае, если Вы выходите на рынок со своим продуктом.
Пока мы говорим про лейбл, про статус, которым можно похвастаться перед заказчиками и коллегами. Если же после получения этого лэйбла, Вы все спокойно забудете на ближайшие 3 года, умный клиент раскусит Вас, не сомневайтесь. Подобная же опасность поджидает и те компании, которые, оценив отдельное подразделение (например, офис в одном городе), объявляют, что вся компания имеет такой-то уровень CMMI. Быть оцененным намного проще, чем поддерживать этот статус (или распространить навыки и процесс на другие подразделения).
Веду я вот к чему: если Вам действительно нужен CMMI в маркетинговых целях, то есть если Ваш заказчик ждет от вас «работу по CMMI», постарайтесь, все-таки применять те практики, которые там описаны.
Конечно, тут могут быть возражения: а что, если мы – мелкий бизнес (фриланс), мы продаем полное решение, мы хотим работать «по-правильному», но «заказчик нам не дает»? Ну, тут два варианты: либо вы неправильно работаете с заказчиком, либо пытаетесь применять «правила» слишком буквально, без тэйлоринга под Ваши конкретные условия. И на клиентов фриланса, наверное, никогда не подействует маркетинговое слово CMMI. (Хотя, я могу ошибаться.)
Модель не дает предписаний, как Вы должны работать, она не говорит, какие документы и процессы у Вас должны быть. Модель рекомендует действия (а не заполнение документов) в рамках обычных инженерных практик, которые должны быть произведены, чтобы гарантировать качество продукта и услуги.
Тут я хочу опять обратиться к бизнес-моделям. Удовлетворить клиента при продаже рабочей силы, можно без CMMI, просто хорошо выполняя свою работу в соответствии с установленным клиентом процессом. Кстати, клиентский процесс может быть очень бюрократичным, но так как Вы выполняете то, что Вам говорят, но не управляете процессом, то можете даже и не знать об этой бюрократии.
А вот в случае с полным циклом работ на нашей стороне, практики, указанные в CMMI, просто незаменимы. Хотя бы как chеcklist, то есть очень легковесный вариант . Но! В процессе производства мы должны постоянно убеждаться, что то, что мы делаем, соответствует бизнес потребности клиента в этом продукте или услуге, что мы не отклоняемся от этих потребностей. Это требует CMMI. Наше дело – придумать, как мы будем это делать – тяжеловесно и бюрократично или с использованием наиболее подходящего инструментария, который облегчит нашу работу и предотвратит ошибки в процессе. CMMI требует постоянно обмениваться знаниями, учиться на своих ошибках, и делать это через анализ как результатов работы, так и процесса. Мы принимаем решение об уровне формальности.
По опыту, могу заметить, что уровень бюрократичности, формальности и тяжеловесности обратно пропорционален реальному уровню профессионализма людей, которые устанавливают процесс. Это не потому, что умным людям не надо ничего записывать. Скорее, в силу оптимизации работы с документами и данными: вместо трех документов можно создать один, но построить процесс так, что он будет использоваться 3-мя людьми, или в 3 под-процессах.
Приведу пару примеров, с которыми мы сталкивались (и сталкиваемся), связанные с бюрократией, а так же варианты оптимизации работы. Эти примеры иллюстрируют, что тяжеловесность создаем мы, а не CMMI:
Процесс и инструментарий могут быть нам предложены (или подсмотрены у кого-то). И если он кажется нам тяжеловесным и бюрократичным, мы должны в первую очередь понять назначение процесса или документа, а потом научиться делать так, чтобы назначение выполнялось, но другим путем. Очень редко неприменимо назначение, цель практик CMMI, но могут быть неприменимы (и неприемлемы) процедуры и документы, которые мы используем (но это уже не от CMMI зависит).
На эту тему есть уже много информации, например Scrum and CMMI – Does it fit together?, на конференции Agileee в этом году этой теме был посвящен доклад.
Суть сводится к тому, что CMMI не привязана ни к каким методологиям ведения проекта, ни к каким SDLC, она привязана, как я уже и говорила, к инженерным и управленческим практикам. А эти практики одинаковы, как в водопадной модели разработки, так и в итеративных; как в RUP, так и в Agile методологиях. В последней версии модели в каждом разделе специально выделено, как эта практика применяется c помощью Agile методов (доклад, на который я ссылаюсь, в сущности, — пересказ CMMI книги). Обратите внимание, что CMMI говорит «что» делать, а Agile практики отвечают на вопрос «как».
Тут, наверное, стоит отметить, что этот миф питается разного рода спекуляциями на Agile Manifesto. В манифесте используется слово «over», когда говорится о коммуникациях и процессах, рабочем продукте и документации и пр. «Over», но не «instead». Из практики (и из Agile Manifesto): несмотря на все желание быть Agile и работать с заказчиком ну очень близко, наша компания, обжегшись, все же взялась за усиление контрактной составляющей сотрудничества.
Еще один скользкий момент – передача знаний. Сторонники Agile объясняют, что передача знаний происходит при личном общении и в процессе работы. CMMI требует «Collect Process Related experience». И цель тут – повторяемось лучших практик независимо он того, успел ли их носитель передать их устно, в процессе работы, своему преемнику или нет. Скажу честно, организация Knowledge Management у нас страдает. И заметна человекозависимость в успехе/неудаче.
NB! Говоря о человеконезависимости, я не в коем случае не посягаю на авторские права, личный опыт каждого отдельного человека, не ставлю под сомнение важность и ценность каждого отдельного индивидуума, не говорю о необходимости системы, в которой каждый человек – винтик. Речь идет только о передаче знаний об ошибках и рисках, зарекомендовавших себя способах их избежать, о лучших практиках, которые можно использовать от проекта к проекту, от команды к команде (то есть, если в них разные люди). Буду рада, если кто-то поделится опытом организации эффективной, простой и используемой базы знаний.
В качестве вывода могу сказать, что CMMI нацелена не только на успешное выполнение проекта (т.е. нужна проектным менеджерам и лидам команд), но и на обеспечение непрерывности бизнеса (то есть нужна руководителям организаций, как в нашем случае с контрактами и человекозависимостью).
Обычно для этого выделяют кого-то не очень важного для заказчика (чтобы не отвлекать ценные кадры от «настоящей» работы). В лучшем случае этот кто-то — специалист в парочке смежных областей, совсем не обязательно знаком с процессным подходом, и не всегда обладает достаточным авторитетом, чтобы что-то требовать и контролировать. Получается, что CMMI и «бизнес», или «работа», существуют параллельно. «Ответственный» постоянно навязывается всем остальным – очень, между прочим, занятым людям, в том числе из незнакомых ему областей производства, – со «своим CMMI». Вполне естественно, что CMMI вызывает сопротивление благодаря этому «дилетанту-теоретику, который мешает продуктивной работе, добавляя лишние задачи (что несогласованно с клиентом!), которые есть возможность делать только в нерабочее время». Такая ситуация всегда будет работать против CMMI: внедряться он будет долго и неэффективно.
Как я уже упоминала раньше, CMMI это модель управления производством программного обеспечения. Чем выше уровень менеджмента, который понимает необходимость требуемых моделью практик и ассоциирует с ними успех бизнеса, тем больше шансов, что CMMI будет применяться. Чем более эти люди профессиональны в нашей индустрии и сами следуют лучшим практикам управления (все это есть в модели: применимо как для управления проектами, так управления организацией, подразделением, account¬-ом), тем больше шансов, что CMMI будет применяться эффективно.
В серии ISO 9000 первоочередное внимание уделяется так называемому management commitment (в CMMI это тоже есть, но не столь ярко выражено). Этот commitment заключается не в согласии менеджмента, что «нам нужна система управления качеством», а в его готовности сделать ставку на улучшение процесса производства, как главное условия роста своего бизнеса. Когда менеджмент работает в системе управления качеством, требует того же от своих подчиненных, эта система будет жива, будет совершенствоваться, и прохождение оценивания на уровень CMMI будет наименее болезненным, рискованным и дорогим.
Вкратце, можно резюмировать, что CMMI нужна:
Руководству компании в целях обеспечения непрерывности бизнеса;
CMMI будет оправдывать ожидания (и затраченные средства), если:
Будучи «внедренной» в CMMI вот уже 5 лет, я часто сталкиваюсь с запросами и суждениями относительного этого фрэймфорка, которые, в целом, можно свести к следующему «Это конечно хорошо, но невозможно в реальных условиях». Кто-то скептически настроен с самого начала, кто-то разочарован (прежде всего, из-за чрезмерных ожиданий). Я не являюсь ни «апологетом», ни фанатом CMMI, но моя непосредственная работа заключается в поддержании соответствия компании CMMI Level 3. Это требует, прежде всего, очень серьезных моральных усилий. Связано это, на мой взгляд, с распространенностью ряда мифов о CMMI, которые появились в силу логических доводов о пользе модели (которые приводятся во всей «рекламной» литературе), примеров повышения эффективности работы в таких «монстрах» как «Боинг», попыток внедрения в отечественных компаниях (после чего в них «ничего не изменилось»), и опыта работы с индийскими компаниями, которые позиционируют себя как соответствующие CMMI Level 5. И еще с непониманием того, как и когда стоит использовать модель, чтобы она приносила пользу.
В статье я попытаюсь «развенчать» некоторые мифы, развеять скептицизм, и, возможно, мне удастся помочь тем, кто хочет использовать CMMI, но не знает как.
Для тех, кто ничего не знает о CMMI, я обычно представляю его следующим образом.
Junior программист обладает какими-то базовыми навыками. Чтоб стать Mid-ом, то есть перейти на следующий профессиональный уровень, он должен обрести определенные навыки, изучить некоторые инженерные практики. На этом уровне и доверия к программеру будет больше, и зарплата, соответственно. Та же схема применима и к организациям. Выполнение определенных практик на уровне компании ведет к повышению так называемого maturity уровня (уровня зрелости), а следовательно, и доверия со стороны клиентов и партнеров.
Перейдем, пожалуй, к мифам, которые раскрывают причины сопротивления CMMI и, надеюсь, укажут на возможности правильного использования модели.
Миф 1: СMMI применим только в крупных компаниях
Результаты анализа данных о прошедших (с 2006 г.) оцениваниях относительно модели CMMI, опубликованные SEI в сентябре 2011, показывают, что 66% оцениваний проведены в компаниях категории «1-100 человек», при этом внутри этой категории главные подкатегории «25 и менее» и «26-50».
Однако, надо понимать, что удовольствие это дорогое, поэтому пойти на официальное оценивание может только та компания, у которой есть эти, относительно свободные, деньги. И те, кому это действительно нужно. Логично предположить, что сумма «на CMMI» для больших компаний будет не такой пугающей, как для маленьких. Но нужно ли им это?
Прежде всего, надо понимать, что CMMI – это модель управления производством/услугой, она ориентирована на повышение эффективности процесса. То есть, она нужна тем, кто управляет процессом работы, делая его более эффективным в плане удовлетворения бизнес потребностей клиента и снижения себестоимости производства.
Обратимся же теперь к особенностям бизнеса относительно крупных компаний на украинском и, я думаю, российском рынках. Есть организации (особенно характерно для отечественного outsource-а), которые продают людей во власть заграничного клиента – в IT организацию, которая и управляет процессом работы (мы называем это Bodyshop), но не решения (solution), услуги удовлетворяющий бизнес цели клиента. Я ни в коем случае не хочу сказать, что компании первого типа – плохие, это просто разные подходы к ведению бизнеса. Но если мы не управляем процессом, нужно очень хорошо подумать, будет ли CMMI экономически выгодным вложением капитала. Скорее всего, в такой компании просто не будет возможности применить то, что требует и рекомендует CMMI. Хотя, в образовательном плане не помешает.
При этом, небольшие компании, которые занимаются полным циклом предоставления услуги клиенту, отвечая за процесс, управляя процессом работы, должны (я намеренно употребляю это слово) обратить внимание на CMMI. Почему должны? Потому что это сборник уроков, которые извлекли из своих ошибок огромное количество компаний по всему миру. (Кстати, изменение версий модели – это добавление новых уроков, учитывая новые тенденции и реалии в мире производства программного продукта.) Это глобальный Lessons Learnt. Неужели мы такие уж особенные, что для нас это не актуально?
«Обратить внимание» можно формально, через официальное оценивание с занесением в регистр SEI, (дороже) и неформально, с помощью консультантов (дешевле) или самостоятельно (еще дешевле). Однако, надо понимать, что корректность понимания, серьезность отношения и ROI прямо пропорциональны стоимости (чаще всего).
Миф 2: CMMI – это только эффектный и эффективный маркетинговый ход
Тут все просто, учитывая предыдущий тезис. Если Ваш бизнес – чистый bodyshop, то для Ваших потенциальных клиентов наличие сертификации не имеет особого значения. Разве что, они ищут таких людей, которые уже работали в «системе», или покупаю «систему» целиком, вместе с управлением.
Если бизнес ориентируется на продажу самостоятельных решений, то лейбл «rated at CMMI level …» действительно может сыграть на руку, так как ожидается что в этой компании умеют управлять процессом и могут предоставить лучшее качество в меньшие сроки, соответственно за меньшие деньги. И клиенту будет меньше мороки, не придется вмешиваться и нервничать. Часто такие клиенты организовывают тендеры, выставляя условием наличие официально подтвержденного соответствия определенному уровню зрелости по модели CMMI (как в уже указанной мной хабрастатье). Это IT компании, которые ищут субподрядчиков, а не дешевую рабочую силу, или организации, которые сами не занимаются производством ПО (банки и пр.)
Очень полезен CMMI статус, также, в случае, если Вы выходите на рынок со своим продуктом.
Пока мы говорим про лейбл, про статус, которым можно похвастаться перед заказчиками и коллегами. Если же после получения этого лэйбла, Вы все спокойно забудете на ближайшие 3 года, умный клиент раскусит Вас, не сомневайтесь. Подобная же опасность поджидает и те компании, которые, оценив отдельное подразделение (например, офис в одном городе), объявляют, что вся компания имеет такой-то уровень CMMI. Быть оцененным намного проще, чем поддерживать этот статус (или распространить навыки и процесс на другие подразделения).
Веду я вот к чему: если Вам действительно нужен CMMI в маркетинговых целях, то есть если Ваш заказчик ждет от вас «работу по CMMI», постарайтесь, все-таки применять те практики, которые там описаны.
Конечно, тут могут быть возражения: а что, если мы – мелкий бизнес (фриланс), мы продаем полное решение, мы хотим работать «по-правильному», но «заказчик нам не дает»? Ну, тут два варианты: либо вы неправильно работаете с заказчиком, либо пытаетесь применять «правила» слишком буквально, без тэйлоринга под Ваши конкретные условия. И на клиентов фриланса, наверное, никогда не подействует маркетинговое слово CMMI. (Хотя, я могу ошибаться.)
Миф 3: CMMI – это бюрократия и тяжеловесные процедуры
Модель не дает предписаний, как Вы должны работать, она не говорит, какие документы и процессы у Вас должны быть. Модель рекомендует действия (а не заполнение документов) в рамках обычных инженерных практик, которые должны быть произведены, чтобы гарантировать качество продукта и услуги.
Тут я хочу опять обратиться к бизнес-моделям. Удовлетворить клиента при продаже рабочей силы, можно без CMMI, просто хорошо выполняя свою работу в соответствии с установленным клиентом процессом. Кстати, клиентский процесс может быть очень бюрократичным, но так как Вы выполняете то, что Вам говорят, но не управляете процессом, то можете даже и не знать об этой бюрократии.
А вот в случае с полным циклом работ на нашей стороне, практики, указанные в CMMI, просто незаменимы. Хотя бы как chеcklist, то есть очень легковесный вариант . Но! В процессе производства мы должны постоянно убеждаться, что то, что мы делаем, соответствует бизнес потребности клиента в этом продукте или услуге, что мы не отклоняемся от этих потребностей. Это требует CMMI. Наше дело – придумать, как мы будем это делать – тяжеловесно и бюрократично или с использованием наиболее подходящего инструментария, который облегчит нашу работу и предотвратит ошибки в процессе. CMMI требует постоянно обмениваться знаниями, учиться на своих ошибках, и делать это через анализ как результатов работы, так и процесса. Мы принимаем решение об уровне формальности.
По опыту, могу заметить, что уровень бюрократичности, формальности и тяжеловесности обратно пропорционален реальному уровню профессионализма людей, которые устанавливают процесс. Это не потому, что умным людям не надо ничего записывать. Скорее, в силу оптимизации работы с документами и данными: вместо трех документов можно создать один, но построить процесс так, что он будет использоваться 3-мя людьми, или в 3 под-процессах.
Приведу пару примеров, с которыми мы сталкивались (и сталкиваемся), связанные с бюрократией, а так же варианты оптимизации работы. Эти примеры иллюстрируют, что тяжеловесность создаем мы, а не CMMI:
- CMMI требует наличие планов работ, при чем они должны быть «консолидированными». Мы создали шаблон Project Management Plan (PMP), который менеджеры должны были писать, а все остальные – читать. Мы же создали процесс Планирование Проекта, в ходе которого создается план. В результате, наши PMP создавались к концу проекта, и никто никогда их не читал. Тем не менее, вся информация, которую должен содержать этот документ, уже обязательно где-то есть к началу проекта: обычно в письмах, в инструментах, картинках и т.д. Наличие регистра информации со ссылками на источники этой информации вполне решает проблему наличия PMP, то есть удовлетворяет требования CMMI, и никакой бюрократии.
- СMMI требует поддержания traceability между бизнес потребностями клиента и финальным продуктом через все промежуточные этапы (спецификации, тестовая документация и пр.) Мы создаем или настраиваем инструмент – excel-таблица, багтрекер, или что-то еще, что по сути является матрицей, которая позволяет прослеживать превращение требований в продукт и его элементы (Requirements Traceability Matrix).
Процесс и инструментарий могут быть нам предложены (или подсмотрены у кого-то). И если он кажется нам тяжеловесным и бюрократичным, мы должны в первую очередь понять назначение процесса или документа, а потом научиться делать так, чтобы назначение выполнялось, но другим путем. Очень редко неприменимо назначение, цель практик CMMI, но могут быть неприменимы (и неприемлемы) процедуры и документы, которые мы используем (но это уже не от CMMI зависит).
Миф 4: CMMI неприменим в Agile-проектах.
На эту тему есть уже много информации, например Scrum and CMMI – Does it fit together?, на конференции Agileee в этом году этой теме был посвящен доклад.
Суть сводится к тому, что CMMI не привязана ни к каким методологиям ведения проекта, ни к каким SDLC, она привязана, как я уже и говорила, к инженерным и управленческим практикам. А эти практики одинаковы, как в водопадной модели разработки, так и в итеративных; как в RUP, так и в Agile методологиях. В последней версии модели в каждом разделе специально выделено, как эта практика применяется c помощью Agile методов (доклад, на который я ссылаюсь, в сущности, — пересказ CMMI книги). Обратите внимание, что CMMI говорит «что» делать, а Agile практики отвечают на вопрос «как».
Тут, наверное, стоит отметить, что этот миф питается разного рода спекуляциями на Agile Manifesto. В манифесте используется слово «over», когда говорится о коммуникациях и процессах, рабочем продукте и документации и пр. «Over», но не «instead». Из практики (и из Agile Manifesto): несмотря на все желание быть Agile и работать с заказчиком ну очень близко, наша компания, обжегшись, все же взялась за усиление контрактной составляющей сотрудничества.
Еще один скользкий момент – передача знаний. Сторонники Agile объясняют, что передача знаний происходит при личном общении и в процессе работы. CMMI требует «Collect Process Related experience». И цель тут – повторяемось лучших практик независимо он того, успел ли их носитель передать их устно, в процессе работы, своему преемнику или нет. Скажу честно, организация Knowledge Management у нас страдает. И заметна человекозависимость в успехе/неудаче.
NB! Говоря о человеконезависимости, я не в коем случае не посягаю на авторские права, личный опыт каждого отдельного человека, не ставлю под сомнение важность и ценность каждого отдельного индивидуума, не говорю о необходимости системы, в которой каждый человек – винтик. Речь идет только о передаче знаний об ошибках и рисках, зарекомендовавших себя способах их избежать, о лучших практиках, которые можно использовать от проекта к проекту, от команды к команде (то есть, если в них разные люди). Буду рада, если кто-то поделится опытом организации эффективной, простой и используемой базы знаний.
В качестве вывода могу сказать, что CMMI нацелена не только на успешное выполнение проекта (т.е. нужна проектным менеджерам и лидам команд), но и на обеспечение непрерывности бизнеса (то есть нужна руководителям организаций, как в нашем случае с контрактами и человекозависимостью).
Миф 5: Давайте назначим кого-нибудь, кто будет отвечать за CMMI
Обычно для этого выделяют кого-то не очень важного для заказчика (чтобы не отвлекать ценные кадры от «настоящей» работы). В лучшем случае этот кто-то — специалист в парочке смежных областей, совсем не обязательно знаком с процессным подходом, и не всегда обладает достаточным авторитетом, чтобы что-то требовать и контролировать. Получается, что CMMI и «бизнес», или «работа», существуют параллельно. «Ответственный» постоянно навязывается всем остальным – очень, между прочим, занятым людям, в том числе из незнакомых ему областей производства, – со «своим CMMI». Вполне естественно, что CMMI вызывает сопротивление благодаря этому «дилетанту-теоретику, который мешает продуктивной работе, добавляя лишние задачи (что несогласованно с клиентом!), которые есть возможность делать только в нерабочее время». Такая ситуация всегда будет работать против CMMI: внедряться он будет долго и неэффективно.
Как я уже упоминала раньше, CMMI это модель управления производством программного обеспечения. Чем выше уровень менеджмента, который понимает необходимость требуемых моделью практик и ассоциирует с ними успех бизнеса, тем больше шансов, что CMMI будет применяться. Чем более эти люди профессиональны в нашей индустрии и сами следуют лучшим практикам управления (все это есть в модели: применимо как для управления проектами, так управления организацией, подразделением, account¬-ом), тем больше шансов, что CMMI будет применяться эффективно.
В серии ISO 9000 первоочередное внимание уделяется так называемому management commitment (в CMMI это тоже есть, но не столь ярко выражено). Этот commitment заключается не в согласии менеджмента, что «нам нужна система управления качеством», а в его готовности сделать ставку на улучшение процесса производства, как главное условия роста своего бизнеса. Когда менеджмент работает в системе управления качеством, требует того же от своих подчиненных, эта система будет жива, будет совершенствоваться, и прохождение оценивания на уровень CMMI будет наименее болезненным, рискованным и дорогим.
Итог: Кому и зачем нужна CMMI?
Вкратце, можно резюмировать, что CMMI нужна:
Руководству компании в целях обеспечения непрерывности бизнеса;
- Руководству компании в целях развития бизнеса (маркетинг) при условии фактического применения практик CMMI;
- Руководству компании для оценки возможности доверия суб-подрядчику;
- Менеджерам разных уровней (включая lead-ов команд), как checklist для ранней идентификации ошибок и рисков, их смягчения и предотвращения;
- Менеджерам разных уровней, а также, возможно, техническим специалистам, для профессионального роста и развития в ходе разработки и оптимизации процесса (в случае, если искренне поверите, что все, что написано в модели имеет смысл и применимо);
CMMI будет оправдывать ожидания (и затраченные средства), если:
- Компания продает solution, управляет процессом удовлетворения бизнес потребностей клиента.
- На уровне руководства разных уровней есть понимание какие улучшения процесса к какому бизнес-эффекту приведут (чем крепче причинно-следственные связи и специфичнее ожидаемый эффект, тем гарантированнее успех). То есть бизнес и улучшение процесса (CMMI) неразделимы.
- Специалисты, которые занимаются внедрением CMMI, являются профессионалами высокого уровня и обладают широким спектром знаний, как инженерных, так и управленческих. При этом они должны работать в команде.
- Знание модели специалистами в разных областях, будь то технический специалист или менеджер проекта, не должно ограничиваться только узкой процессной областью (например, только технические процессные области, или только управление проектом). Очень желательно знать и понимать можель целиком, включая области управления процессом.
