1987: SEI публикует первую пятиуровневую схему оценки «зрелости программного обеспечения».
1988: Опубликована важнейшая работа Уоттса Хамфри (Watts Humphrey) «Characterizing the Software Process: A Maturity Framework» (Описание процесса разработки программного обеспечения: общая схема зрелости) в журнале IEEE Software за март 1988 года. Проведены и опубликованы первые оценки. Первые свидетельства о существовании СММ (Capability Maturity ModelSM – модели зрелости потенциала).
1989: Создание групп разработки стандартов и первых организаций методологической поддержки. Публикация книги Хамфри «Managing the Software Process» (Управление процессом создания ПО).
1990-е: Распространение СММ в Минобороны США и за пределами ведомства. Создание целевых уровней СММ во многих, если не во всех, крупных организациях, участвующих в разработке ПО.
Ядром СММ является упорядоченное множество ключевых областей процесса (Key Process Areas, KPAs), каждую из которых характеризует определённый отраслевой опыт, связанный с уровнем СММ. Исходя из качества опыта в ключевых областях, шкала делится на пять уровней организационной «зрелости». Переход на уровень определяется не только количеством накопленного опыта, но также порядком накопления этого опыта (скажем, заслугой не является накопление опыта Уровня 4, если организация ещё не достигла Уровня 3).
Стандарты – это хорошо. Слава Богу, у нас есть стандарты, ибо без них мы не могли бы вставить кассету Kodak в фотоаппарат Minolta, штепсель кофеварки не подходил бы к розетке на стене, сигнал, передаваемый местной радиостанцией, не был бы принят вашим приёмником, ваш новый телефонный аппарат не подошёл бы для работы с вашей телефонной компанией, компакт-диски не помещались бы в проигрыватель, факсы невозможно было бы разобрать, размеры одежды и обуви стали бы бессмысленными, новые покрышки не подходили бы к старым автомобилям, а сеть Интернет оставалась бы доступной лишь людям, которые её изобрели.
Такие стандарты полезны, но следует отметить, что великий триумф стандартов в современном мире – это практически всегда успех стандартных интерфейсов. Стандарт на резьбу, на пальчиковую батарейку или кассету с плёнкой содержит много сведений о конечном продукте – о том, как он взаимодействует с другими частями, но ни слова о процессе создания этого продукта. Батарейка имеет тип АА, если отвечает стандарту соответствующего интерфейса (по форме, размеру, отказоустойчивости, электрическим характеристикам и т. д.), независимо от того, создана ли она под водой, роботами или обученными обезьянами. Из успеха стандартов на интерфейсы можно лишь с некоторой натяжкой делать вывод, что процессы тоже следует стандартизировать.
И все же огромной привлекательностью обладает поиск идеального процесса. Работы Хамфри, Полка (Palk) и других представителей SEI вдумчивы, профессиональны, амбициозны и искренни:
Поиск идеальной практики или практики, подходящей на роль таковой, – предприятие полезное. Однако программы, предписывающие использование такой практики, – это нечто совершенно иное.
Парадокс СММ в том, что модернизация процесса – дело хорошее, а вот программы модернизации плохи очень часто, если не всегда. Модернизацией процессов всегда занимаются люди компетентные: они гордятся достигнутым прогрессом, источником которого может быть лишь совершенствование в предметной области. Такого рода низкоуровневое улучшение процесса есть простейшая гигиена для любого интеллектуального труда, но формальная модернизация процесса переносит ответственность с отдельного человека на организацию. Индивидуум может стремиться к достижению, практике, пропаганде качественных навыков, а организация способна лишь наделять их законным статусом. Именно в придании статуса законности кроется опасность.
Чтобы понять проблему такого подхода к модернизации процессов, необходимо отвлечься от проектов, успешно работающих одновременно с повышением уровня процесса, и обратить внимание на проекты, которые испытывают сложности.
Побеждают организации, которые создают продукты, имеющие наибольшую ценность для клиентов. Если организация создаёт продукты, вызывающие лишь зевоту, она проигрывает, даже если создание продуктов очень и очень эффективно. Если проект выполняется со сбоями, но при этом создаётся продукт, имеющий высокую привлекательность, то этот проект следует предпочесть проекту, эффективно создающему ерунду. Процесс ничего не стоит, если применяется в проектах, не достойных существования.
Когда модернизация процесса становится самоцелью («Даёшь Уровень 3 к концу года!»), пугающие проекты откладываются на потом. К сожалению, именно эти пугающие проекты – вероятно, те самые, которые достойны осуществления.
Все проекты, приносящие реальную выгоду, связаны и с реальными рисками. Именно проект, обладающий новизной, новаторскими или изобретательскими нотками, имеет шансы заполучить внимание и финансы покупателя. Возможно даже, что ваш самый знаменитый своим провалом проект – тот, что на год задержался, в три с половиной раза превысил оценочную стоимость, с трудом проходит системные испытания и все ещё требует присутствия инженеров с дефибрилляторами, чтобы дышать, – по-прежнему остаётся лучшим из проектов вашей организации за многие-многие годы.
