Вначале об аббревиатуре: Capability Maturity Model Integration (CMMI) — модель оценки зрелости компании, основанная на ее производстенном, техническом и управленческом потенциале. Разработана она Software Engineering Institute. Подробно о ней писалось в хабрастатьях: Модель CMMI и Как наша компания получила 3 уровень CMMI.

Будучи «внедренной» в CMMI вот уже 5 лет, я часто сталкиваюсь с запросами и суждениями относительного этого фрэймфорка, которые, в целом, можно свести к следующему «Это конечно хорошо, но невозможно в реальных условиях». Кто-то скептически настроен с самого начала, кто-то разочарован (прежде всего, из-за чрезмерных ожиданий). Я не являюсь ни «апологетом», ни фанатом CMMI, но моя непосредственная работа заключается в поддержании соответствия компании CMMI Level 3. Это требует, прежде всего, очень серьезных моральных усилий. Связано это, на мой взгляд, с распространенностью ряда мифов о CMMI, которые появились в силу логических доводов о пользе модели (которые приводятся во всей «рекламной» литературе), примеров повышения эффективности работы в таких «монстрах» как «Боинг», попыток внедрения в отечественных компаниях (после чего в них «ничего не изменилось»), и опыта работы с индийскими компаниями, которые позиционируют себя как соответствующие CMMI Level 5. И еще с непониманием того, как и когда стоит использовать модель, чтобы она приносила пользу.

В статье я попытаюсь «развенчать» некоторые мифы, развеять скептицизм, и, возможно, мне удастся помочь тем, кто хочет использовать CMMI, но не знает как.

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



Я здесь не собираюсь никого разубеждать. Я хочу поделиться соображениями, почему большинству компаний аджайл действительно не подходит.

Архипенков Сергей — эксперт в управлении разработкой ПО, более 30 лет в разработке ПО, PMP® PMI, вице-президент Гильдии менеджеров программных проектов. Активный «продвигатор» и «задвигатор» теории и практики управления проектами и людьми в проектах по разработке ПО. Активный заседатель программных комитетов. Из последнего — председатель программного комитета конференции «Software Project Managment Conference» (ноябрь, Санкт-Петербург).

Ниже опубликован доклад Сергея с конференции CodeFest, на тему «Теория и практика адаптивного управления проектом».

Странно, но факт

• Абсолютно все стандарты управления проектами и компаниями говорят о необходимости управления рисками. Предлагаются различные модели, инструменты и термины. Каждый ПМ понимает, что это важно. И проходят тренинги. И даже пытаются выполнять такую практику (или процесс) как Risk Management. Но не все (большинство) видят в этом смысл и пользу на практике. В лучшем случае заводят регистры рисков (про которые скоро забывают), в худшем говорят, что управление рисками происходит в ходе ежедневной коммуникации (непонятно, правда, что имеется ввиду под рисками и управлением.
• При наличии на проектах Risk register-а менеджмент компании считает что есть недостаток в про-активном управлении проекта и в коммуникациях с заказчиком, который регулярно жалуется на неожиданные проблемы на проекте.
• Проджект менеджеры и Проектные команды жалуются на большие затраты времени на работу с рисками (и, очевидно, отсутствием эффекта, а то бы не жаловались.

Эти и многие подобные наблюдения были сделаны мной в ходе внедрения системы управления качеством и проведения аудитов процессов в IT компании. В частности, процессов управления проектом. Как и любое нововведение, внедрение правил работы должно сопровождаться обоснованием зачем это нужно. Для этого, в дополненение к навыкам убеждения, необходимы знание теории и практических примеров — как негативных, так и позитивных. На них и основаны мои выводы о секретах эффективного Управления Рисками.

В коммерческой деятельности одним все время что-то нужно от других. В проектном бизнесе вы жаждете втюхать свои услуги. Вам нужно получить прибыль. Заказчику тоже много чего нужно. Но, независимо ни от чего вам нужно продать услуги и получить за них деньги. На каждом этапе вам будут оказывать сопротивление. Сегодня я начну рассказ о том, кто и как будет оказывать вам сопротивление и что вы можете сделать для того, чтобы этому противостоять.

В общих чертах проект в ИТ состоит из следующих этапов. Сначала вы узнаете о потребности кого-то в чем-то (или создаете эту потребность). Потом вы третесь возле заказчика, всячески облизывая его и склоняя в сторону откровенного разговора. Я намеренно выношу за скобки коррупционные сделки и буду рассказывать только о сделках в рамках закона.Когда клиент созревает для встречи, вы устраиваете шоу, в ходе которого продается идея и рисуется картина прекрасной жизни, которая наступит после внедрения вашего решения. Потом контракт и аванс. Потом обследование и долгая нудная работа по проектированию. Потом сдача проектных документов. Потом реализация и запуск решения. Потом ввод в действие. Каждый этап закрывается актом, на основании которого вам на счет падает копейка. Вот такой бизнес. Конечно, я утрирую, и иногда все может быть наоборот. А иногда — и шиворот навыворот.

Итак, займемся классификацией троллей и их приемов. Сегодня — формальный троллинг. В другой раз троллинг очный.