Мифы о CMMI, или кому и зачем она нужна

    Вначале об аббревиатуре: 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 и, надеюсь, укажут на возможности правильного использования модели.

    Миф 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, являются профессионалами высокого уровня и обладают широким спектром знаний, как инженерных, так и управленческих. При этом они должны работать в команде.
    • Знание модели специалистами в разных областях, будь то технический специалист или менеджер проекта, не должно ограничиваться только узкой процессной областью (например, только технические процессные области, или только управление проектом). Очень желательно знать и понимать можель целиком, включая области управления процессом.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 45

      0
      Хотелось бы более подробного разъяснения, что же такое эта ваша загадочная аббревиатура, а то в вики сплошная реализация:
      Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности.
        +1
        На сколько мне рассказывали в нашей конторе, компания сама не может быть стандартизована по CMMI, стандартизуется отдел или проект. Ну, если все стандартизованы — то да, можно сказать что компания стандартизована, единственное, что на это надо угрохать совсем много денег. Ну и поэтому bodyshop стандартизировать просто не получится, так как такой отдел ничего не производит.

        А вообще, CMMI, PMBOK и другие слова, я согласен, что не на пустом месте родились, просто там все так описано, чтобы консультанты и аудиторы могли заработать денег, а люди просто не понимают и отказываются когда видять, что надо описывать кучу макулатуры.

        Вот конкретно вы, кто поддерживает level 3, можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах, наподобие того, что вы написали про PMP и traceability?

        Кстати вот хороший пример — traceability, что вы привели. Т.е. тупо требуют issue tracker. И вы хорошо это объяснили. Вот если так объяснять все требования, то получается, что не все так и страшно, а очень разумно, и таких описаний не хватает.
          0
          — компания сама не может быть стандартизована по CMMI, стандартизуется отдел или проект.

          Отдел или подразделение — Да. Но не проект. Хотя, если этот проект тянет на подразделение — то можно и так сказать:). В обиходе говорят «компания», имея ввиду, что в рамках этой компании есть подразделение, которое оценено на такой-то уровень. Так вот и у нас: есть bodyshop, который, разумеется, не входил в группу оцениваемых проектов.
          Однако, так как CMMI касается не только проектного управления, но и организационного, то даже при сосуществовании полного цикла оказания услуги и bodyshop есть общие организационные процессы, такие как, например, развитие персонала (в CMMI — Organizational Training).
            0
            — а люди просто не понимают и отказываются когда видять, что надо описывать кучу макулатуры

            Абсолютно с Вами согласна. Как я уже писала, я не фанатка CMMI, очень долго сама пыталась разобраться что к чему :)

            — можете на пальцах объяснить, что положено, или какие именно практики заложены у вас в проектах

            Могу, возможно не все, но вот пару примеров в статье привела. В принципе, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :).
            0
            CMMI — это модель оценки уровня зрелости? Почему был выбран именно CMMI? Во многих методологиях (например, для управления ИТ-инфраструктурами, проектами, офисами управления проектами) есть свои модели оценки зрелости.
            Не шашечки ли это — «уровень зрелости в целом», вместо «уровня зрелости вида деятельности». Это мои личные сомнения, поэтому хотелось бы Вашего комментария.

            Спасибо кстати, стало понятно чуть больше о том, как способствует CMMI зрелости организации, и тому, что она
            1. управляется лучше,
            2. выполняет задачи лучше.

            Но пока не очевидно, что того же нельзя было бы достичь повышая роль и зрелость офиса управления проектами например.
              0
              — Почему был выбран именно 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 подразделением/компанией.
              0
              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.»
                0
                Если же после получения этого лэйбла, Вы все спокойно забудете на ближайшие 3 года, умный клиент раскусит Вас, не сомневайтесь. Подобная же опасность поджидает и те компании, которые, оценив отдельное подразделение (например, офис в одном городе), объявляют, что вся компания имеет такой-то уровень CMMI. Быть оцененным намного проще, чем поддерживать этот статус (или распространить навыки и процесс на другие подразделения).


                Сомневаюсь (работаю в CMMI5 компании).
                  0
                  ну или я неправильно понял назначение CMMI. Слышал мнение что это примерно как перечень инструментария который нужен для работы. Понятно что врачу со стетоскопом доверяеш больше, но гарантий это не дает.
                    0
                    — но гарантий это не дает.

                    Не дает. CMMI говорит о потенциальных возможностях. Но не гарантирует, что каждый проект будет идеальным.
                      0
                      это есть такая грубая поговорка про «прикрывает но не защищает».

                      Собственно я за CMMI так как какая то попытка навести порядок лучше чем отсутвие её. А комент мой первый был о том что вы говорите
                      В статье я попытаюсь «развенчать» некоторые мифы, развеять скептицизм
                      но развенчания второго мифа я так и не увидел. То что фирме было бы лучше еслиб все следовали процессам определенным для получения CMMI5 не означет что они захотят или смогут внедрить их. А без этого так и остается маркетинговый ход потому что без cmmi тупо к проекту не подпускают.
                        0
                        Развенчание второго мифа заключается в том, что как маркетинговый ход это может и не сработать, не стоит на это особенно надеяться.

                        Не сработать может по двум причинам — либо клиент на это «не клюет», либо «клюнул», потом приехал посмотрел своими глазами и разочарованный уехал.
                    0
                    — Сомневаюсь (работаю в CMMI5 компании).
                    Ваше право. Но нут возможны вопросы:
                    а) играет ли этот статус какую-то роль для ваших клиентов? Если нет, то он и не будет пытаться вас «раскусить». (это по поводу маркетинга)
                    б) работали ли Вы в «неCMMI5» компании? И как долго работали там и там? если да, работали и достаточно долго, то тогда действительно интересно услышать Ваше мнение по поводу сравнения этих компаний.
                    в) Вы работаете в том подразделении, которое проходило оценивание? Или, скажем, в другом офисе этой компании (или в другом направлении)? Тоже интересно, есть ли отличия.

                    Ну и, в конце концов, про Level 5. Судя по тому, что я слышала, этому мало кто доверяет. Как сказал один из наших потенциальных клиентов, «я буду работать с Level 3, так как тут меньше шансов фальсификации».
                    +1
                    Интересно было бы видеть реализацию конкретных практик CMM (кто-то выше уже просил).

                    Агитации за советскую власть, т.е., что CMMI полезна, и так много. Жизненных примеров мало.
                      –1
                      реализация это например список правил
                      1)перед началом проекта мы всегда будем проводить тщательный анализ требований
                      2)во время выполнения проекта всегда будем выделять адекватные ресурсы
                      3)после окончания проекта всегда будем корректировать подход с учетом полученых новых данных.
                        0
                        а если вы попробуете почитать пролистать (или даже просмотреть список практик)… то вы найдете там то, о чем просите, например (соответственно с вашими пунктами):
                        1) Requirements Development (вся практика)
                        2) Project Planning -> SP 2.4. Plan for Project Resources
                        3) Causal Analysis and Resolution (но это не обязательно после окончания проекта)
                        там вам и будет список правил :)
                        0
                        Да я, собственно, не агитирую. Более того, мыслью подтолкнувшей меня на написание статьи было «не трогайте CMMI, если Вам это действительно не надо». Кому и зачем надо — я написала. Так же, сделала акцент на том, что применение (реализация конкретных практик) зависит от профессионального кругозора тех кто применяет и от знания всей модели, а не отдельных ее частей.

                        Как я уже ответила уважаемому 1nd1go, который просил больше примеров, Вы наталкиваете меня на мысль о цикле статей «CMMI для чайников» :). Я привела несколько жизненных примеров, когда стоит и когда не стоит применять CMMI, пару примеров реализации практик. Задачей этой статьи не было объяснение большинства практик простыми словами. Те пример, которые я привела, показывают, что это возможно.

                        Востребованность я поняла. Постараюсь оправдать Ваши надежды.
                        +1
                        После прочтения вашей статьи я не стал больше знать про CMMI ни на йоту. Можете какие-нибудь примеры вида: мы начали депремировать уборщицу Клаву за то-то и премировать за это и тараканы в нашей столовой перестали докучать посетителям?
                          0
                          У каждой статьи свой читатель. Значит Вы знаете много. Мой опыт показывает, что далеко не все такие образованные в этом плане.
                          Я пишу статьи чтобы «забэйзлайнить» свои мысли. Возможно, я до Вас еще не доросла.

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

                          Наоборот, я говорю об ошибках, которые совершили мы, поверив в мифы про CMMI.
                            +1
                            Нет. В смысле, я как не знал ничего, так и не стал знать ничего.
                              0
                              В таком случае надо начать и литературы попроще, если вообще есть цель понять.
                                0
                                Там в начале статьи есть ссылки на базовую информацию, о чем уже писали на Хабре
                                  0
                                  Эта информация никак не проясняет. Я пока понимаю суть CMMI только с прикладной точки зрения: это такое заклинание, которое позволяет получать контракты от государства (берём США, например) и от крупных корпораций. На качество итогового продукта (на практике) это влияет мало.

                                  Мой любимый пример: производители тушёнки сертифицированы по ISO9000, однако выпускаемую ими продукцию есть невозможно.
                                    0
                                    Данный пост как раз для этого и написан. У меня опять возникают сомнения в желании понять у комментирующих.
                                      0
                                      Не вижу никакой ясности, а вижу набор стандартных баззвордов: CMMI, ROI итп. Примерно такой же фигнёй любят засыпать неосведомлённого человека евангелисты ERP-систем. Да, на словах оно всё идеально, но на практике… см. пример выше про тушёнку. CMMI не гарантирует качество продукта, оно гарантирует качество процесса. Одно с другим, конечно, связано, но не напрямую. Техпроцесс производства дерьмовой тушёнки идеально соответствует ISO9000, вот только на выходе получается дерьмо.
                                        +1
                                        Я не знаю, что вы читали, но здесь нет ни баззвордов, ни идеальности на словах.

                                        Я не спорю, что проще привести пример с тушенкой, чем написать большой текст. Только в большом тексте и аргументов больше. Если в ответ на них у вас есть только пример с тушенкой, то у меня в третий раз за сегодня возникают сомнения в желании понять этот пост.
                                      +1
                                      Можно наладить суперский процесс производства продукции разных сортов. Даже той тушенки о которой Вы говорите. Процесс гарантирует однородность и повторяемость. Если вся тушенка одинаково «дерьмовая», то производство преуспело в процессе :).

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

                                            Тут всех пугает кажущаяся сложность текста. Поэтому читать стоит людям подкованным в нескольких инженерных и управленческих областях.

                                            И потому же я теперь уже однозначно буду писать «CMMI для чайников» :).
                                +1
                                Начну с начала — CMM возникла как попытка перенести успешный опыт повышения качества шесть-сигма в софтверную индустрию, но понятно что провалилась, ибо процессы неустойчивые сами по себе. На самом деле все забывают сказать что любая оптимизация процессов должна быть объективно полезна для исполнителей, иначе она будет в лучшем случае поддерживаться формально или даже подтасовываться. То есть новые процессы должны быть устойчивыми.

                                Обычно пишут что целей внедрения CMM(I) бывает 2 — требования заказчика или внутренняя потребность формализовать процессы. Фишка в том что полезной она может быть только в случае если сама организация достаточно созрела для оптимизации и ее кадры понимают что делают. Но такой организации как правило уже не нужен костыль в виде формальных правил СММ.

                                В целом же лейбл с уровнем СММ(I) как правило не соответствует действительности.
                                  0
                                  — Фишка в том что полезной она может быть только в случае если сама организация достаточно созрела для оптимизации и ее кадры понимают что делают. Но такой организации как правило уже не нужен костыль в виде формальных правил СММ.

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

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

                                  Все мы ходили в школу, читали учебники в институтах. Сейчас мы их уже, может быть кто-то за редким исключением, не перечитываем. Потому что созрели и поняли, и запомнили. То же и с моделями зрелости, стандартами и т.д.
                                  0
                                  * Не Гербалайф!
                                    0
                                    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 и проводить сбор-анализ-документирование-согласование требований уже не надо. :)
                                      0
                                      план работ должен быть консолидированным. ИМХО, это означает что я могу открыть один документ (файл, проект в проджекте, 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.
                                        0
                                        Теперь стало понятней, спасибо. :)

                                        Я правильно понял вашу мысль, что «избавлением от бюрократии» стало то, что вместо формирования некоего документа по шаблону, вы теперь храните все артефакты относящиеся к планированию проекта в отдельной библиотеке SharePoint?

                                        P.S. CMMI читал. Свой пример про требования хотел пометить тэгом sarcasm, но решил, что и так будет понятно…
                                          0
                                          Я правильно понял вашу мысль
                                          Да :)

                                          пример про требования хотел пометить тэгом sarcasm, но решил, что и так будет понятно
                                          понятно, я на всякий случай расписала
                                      +1
                                      Процесс и инструментарий могут быть нам предложены (или подсмотрены у кого-то). И если он кажется нам тяжеловесным и бюрократичным, мы должны в первую очередь понять назначение процесса или документа, а потом научиться делать так, чтобы назначение выполнялось, но другим путем.

                                      Я подчеркнул главную, на мой взгляд, мысль статьи.
                                      Только я бы сформулировал еще жестче — понять назначение процесса / документа надо в любом случае — кажется он вам тяжеловесным или нет. :) Возможно он вообще не применим к вашему проекту.

                                      В описании CMMI много сказано о том, что нужно делать. Но очень мало написано — зачем это нужно делать. И получаются две крайности:
                                      Умудренные prodject management'ом гуру читают все эти практики по диагонали и думают — «Блин, ну ведь это же очевидные вещи, мы уже давно все так и делаем», потому что уже наступили на все грабли, от которых пытается спасти CMMI.
                                      C другой стороны, начинающий PM читает описания практик, не понимает зачем они нужны, но «раз написано — надо делать». Отсюда и вырастает бюрократия и тяжеловесные процедуры.

                                      Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.
                                      Например, в Project Planning есть такой пункт: SP 2.6 Plan Stakeholder Involvement
                                      Вроде бы написано, что надо делать, но начинающим PMам может быть не очевидно, что будет если этим пунктом пренебречь.
                                        0
                                        Согласна с Вами
                                        Было бы здОрово, если бы кто-нибудь разобрал CMMI практики именно с точки зрения потребностей. Описал — к чему приводит невыполнение той или иной практики.

                                        очень хочу это сделать, я уже выше писала про идею «CMMI для чайников».
                                          0
                                          Жаль что не написали еще. Все руки не доходят?
                                            0
                                            С одной стороны — руки не доходят, с другой — спокойнее стала относиться к непониманию, не задевает, а следовательно нет вдохновения :). К тому же пугает объем работы — Подобное описание означает Краткий курс Software Engineering, Project Management и управление организацией )))
                                            Может, как-нибудь соберусь…
                                        0
                                        Отличная статья! Поражает невежество и, своего рода, потребительский подход комментаторов — всё разжевывать нужно.

                                        Со своей стороны есть несколько комментариев/вопросов.

                                        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 аппрайзал не может быть использован для повышения эффективности аутсорсинговых компаний. Согласен с тем, что это несколько сложнее. Но если заказчик хочет и готов к сотрудничеству в этом направлении, то выстроить процессы может оказаться даже проще, чем для продуктовой компании.
                                          0
                                          Спасибо за понимание :)
                                          Попробую ответить:
                                          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. Но эта модель еще слишком молода, и лично у меня еще не дошли до нее руки.
                                            0
                                            Спасибо за исчерпывающий ответ!

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое