Стандарты – это хорошо. Слава Богу, у нас есть стандарты, ибо без них мы не могли бы вставить кассету Kodak в фотоаппарат Minolta, штепсель кофеварки не подходил бы к розетке на стене, сигнал, передаваемый местной радиостанцией, не был бы принят вашим приёмником, ваш новый телефонный аппарат не подошёл бы для работы с вашей телефонной компанией, компакт-диски не помещались бы в проигрыватель, факсы невозможно было бы разобрать, размеры одежды и обуви стали бы бессмысленными, новые покрышки не подходили бы к старым автомобилям, а сеть Интернет оставалась бы доступной лишь людям, которые её изобрели.
Такие стандарты полезны, но следует отметить, что великий триумф стандартов в современном мире – это практически всегда успех стандартных интерфейсов. Стандарт на резьбу, на пальчиковую батарейку или кассету с плёнкой содержит много сведений о конечном продукте – о том, как он взаимодействует с другими частями, но ни слова о процессе создания этого продукта. Батарейка имеет тип АА, если отвечает стандарту соответствующего интерфейса (по форме, размеру, отказоустойчивости, электрическим характеристикам и т. д.), независимо от того, создана ли она под водой, роботами или обученными обезьянами. Из успеха стандартов на интерфейсы можно лишь с некоторой натяжкой делать вывод, что процессы тоже следует стандартизировать.
И все же огромной привлекательностью обладает поиск идеального процесса. Работы Хамфри, Полка (Palk) и других представителей SEI вдумчивы, профессиональны, амбициозны и искренни:
Когда мы с Тимом составляли сборник «Software State-of-the-Art: Selected Papers» (Современное программное обеспечение: избранные статьи), Dorset House, 1990, перед нами стояла задача отобрать наиболее значимые работы восьмидесятых. Работа Уоттса Хамфри «Characterizing the Software Process» была среди первых . В тот год в статье для «American Programmer» я задался целью выбрать лучшую из работ, вошедших в сборник. Без тени сомнения из тридцати одной статьи я выбрал статью Хамфри. Воздействие его работы в последующие годы, по моему мнению, подтвердило правильность такого выбора.
Поиск идеальной практики или практики, подходящей на роль таковой, – предприятие полезное. Однако программы, предписывающие использование такой практики, – это нечто совершенно иное.
Парадокс СММ в том, что модернизация процесса – дело хорошее, а вот программы модернизации плохи очень часто, если не всегда. Модернизацией процессов всегда занимаются люди компетентные: они гордятся достигнутым прогрессом, источником которого может быть лишь совершенствование в предметной области. Такого рода низкоуровневое улучшение процесса есть простейшая гигиена для любого интеллектуального труда, но формальная модернизация процесса переносит ответственность с отдельного человека на организацию. Индивидуум может стремиться к достижению, практике, пропаганде качественных навыков, а организация способна лишь наделять их законным статусом. Именно в придании статуса законности кроется опасность.
Чтобы понять проблему такого подхода к модернизации процессов, необходимо отвлечься от проектов, успешно работающих одновременно с повышением уровня процесса, и обратить внимание на проекты, которые испытывают сложности.
Побеждают организации, которые создают продукты, имеющие наибольшую ценность для клиентов. Если организация создаёт продукты, вызывающие лишь зевоту, она проигрывает, даже если создание продуктов очень и очень эффективно. Если проект выполняется со сбоями, но при этом создаётся продукт, имеющий высокую привлекательность, то этот проект следует предпочесть проекту, эффективно создающему ерунду. Процесс ничего не стоит, если применяется в проектах, не достойных существования.
Однажды я читал лекцию о конфликте выгоды и процесса в местном профессиональном обществе. После лекции руководитель отделения по разработке ПО рассказал мне о проекте, завершившемся ранее в том году. В ходе проекта разработчики добавили несколько новых транзакций в онлайновую систему заказов. При установке обновлённой системы они включили счётчики посещений, чтобы узнать, как часто используются новые возможности. Через полгода они сняли показатели счётчиков. Этот руководитель знал, во что обошлось компании создание программного комплекса, и потому смог сопоставить значения счётчика и стоимость и получить стоимость отдельной транзакции за эти шесть месяцев. Стоимость транзакции составила 53 000 долларов! Прибыль от каждого посещения измерялась, вероятно, копейками. Великая ирония в том, что речь идёт о СММ-организации второго уровня, которой через несколько месяцев предстояла оценка на предмет перехода на Уровень 3. Эх, будь они организацией Уровня 3 до начала этого проекта, смогли бы, наверное, сбавить стоимость до 45 000 долларов за транзакцию.
Когда модернизация процесса становится самоцелью («Даёшь Уровень 3 к концу года!»), пугающие проекты откладываются на потом. К сожалению, именно эти пугающие проекты – вероятно, те самые, которые достойны осуществления.
Все проекты, приносящие реальную выгоду, связаны и с реальными рисками. Именно проект, обладающий новизной, новаторскими или изобретательскими нотками, имеет шансы заполучить внимание и финансы покупателя. Возможно даже, что ваш самый знаменитый своим провалом проект – тот, что на год задержался, в три с половиной раза превысил оценочную стоимость, с трудом проходит системные испытания и все ещё требует присутствия инженеров с дефибрилляторами, чтобы дышать, – по-прежнему остаётся лучшим из проектов вашей организации за многие-многие годы.
Один из сильнейших аргументов в пользу СММ – повышение качества и производительности с одновременным снижением рисков (табл. 29.1):
Таблица 29.1. Модель СММ от SEI
Эта таблица предполагает, что ту же работу можно на более высоких уровнях выполнять с меньшим риском. Но есть и другая интерпретация, которая нам кажется более корректной: организации в меньшей степени подвергают себя рискам в «зрелости». Организация, которой предстоит продемонстрировать увеличение уровня СММ, навряд ли станет искать настоящих испытаний.
И раз уж об этом зашла речь, профессионализм в любом случае не является лекарством от рисков…
Предположим, вы работаете в компании средних размеров, которая производит бизнес-приложения для массового рынка. Руководство корпорации полагает, что СММ придумали не в Питсбурге, что это слово Божие. Поэтому они пригласили представителей SEI, чтобы оценить уровень зрелости компании. Оценка завершена, и вас всех собрали в конференц-зале. Главный эксперт SEI вступает на подиум, чтобы объявить результаты исследования. В зале наступает тишина…
«Дамы и господа, у нас есть удивительная новость. Мы завершили оценку и определили ваш уровень по пятиуровневой шкале СММ. Выяснилось, что ваша организация обладает… Уровнем 6! Да-да, Уровнем 6. Мы даже не знали, что такой уровень существует, до того как посетили вашу организацию. Это удивительный день для всех нас. Мы чувствуем себя так, словно открыли новый элемент периодической системы. Вы лучшая из известных человечеству организаций по созданию программного обеспечения. Спасибо, всего хорошего».
Как, хорошая новость? Ну и что теперь с ней делать? Чем сильнее вера в осмысленность оценки, тем более вы склонны приниматься за более сложные задачи. Поднимать планку. Вы можете привлечь своих людей к работе над приложениями, которые более мелкие организации создать не способны. Если вы лучшая из известных человечеству организаций по созданию программного обеспечения, нет смысла давать людям работу, которую способен выполнить средней глупости человек. Лучше пусть конкуренты завидуют вашей способности решать самые сложные задачи. И если время от времени вы терпите поражение, что с того? Когда-то ведь будет и успех, и тогда это точно будет продукт, достойный организации Уровня 6. Если требуется делать рутинную работу, её исполнение можно и заказать. Существует множество просто компетентных организаций, способных делать простую работу.