29. Программы модернизации процессов

К оглавлению 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
34 35 36 37 38 39 40 41 42

Те замечательные ребята, что в восьмидесятых познакомили нас с Методологией с большой буквы М, без дела не сидели. Их последнее новшество – Движение За Улучшение Процессов, более современное, более всеобъемлющее, оно лучше, в нем больше лоска, оно ещё более амбициозно… но по сути это все то же старьё. Ваша локальная Программа Модернизации Процессов – все та же Методология, но переродившаяся. На этот раз подход «универсального размера» достиг апогея: один размер теперь подходит не только всем в вашей компании, он ещё и всем во всем мире. Способности вашей организации измеряются в контексте жёсткой модели. Чем точнее вы соответствуете модели, тем выше ваш балл. Чем выше, тем лучше. Самый высокий балл – лучше всего. Если бы все организации получали самые высокие баллы, они все были бы лучшими, и (так уж получается) выполняли бы свою работу абсолютно одинаково – лучшим способом. Лучший – он и в Африке лучший, тут нет разницы между веб-приложениями для Yahoo и подпрограммами учёта пенсий в Aetna. По крайней мере, в теории…

Краткий исторический экскурс

На случай, если последние пятнадцать лет вы прожили на другой планете, мы представляем новейшую хронологию усовершенствования процессов:

1984: Министерство обороны США (U.S. Department of Defense, DoD) создаёт Институт программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги-Меллон. На институт возлагается миссия «создания стандартов совершенства в разработке программного обеспечения».

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 к концу года!»), пугающие проекты откладываются на потом. К сожалению, именно эти пугающие проекты – вероятно, те самые, которые достойны осуществления.

Все проекты, приносящие реальную выгоду, связаны и с реальными рисками. Именно проект, обладающий новизной, новаторскими или изобретательскими нотками, имеет шансы заполучить внимание и финансы покупателя. Возможно даже, что ваш самый знаменитый своим провалом проект – тот, что на год задержался, в три с половиной раза превысил оценочную стоимость, с трудом проходит системные испытания и все ещё требует присутствия инженеров с дефибрилляторами, чтобы дышать, – по-прежнему остаётся лучшим из проектов вашей организации за многие-многие годы.

Один из сильнейших аргументов в пользу СММ – повышение качества и производительности с одновременным снижением рисков (табл. 29.1):

Таблица 29.1. Модель СММ от SEI

Эта таблица предполагает, что ту же работу можно на более высоких уровнях выполнять с меньшим риском. Но есть и другая интерпретация, которая нам кажется более корректной: организации в меньшей степени подвергают себя рискам в «зрелости». Организация, которой предстоит продемонстрировать увеличение уровня СММ, навряд ли станет искать настоящих испытаний.

И раз уж об этом зашла речь, профессионализм в любом случае не является лекарством от рисков…

Новый мировой рекорд во всех категориях

Предположим, вы работаете в компании средних размеров, которая производит бизнес-приложения для массового рынка. Руководство корпорации полагает, что СММ придумали не в Питсбурге, что это слово Божие. Поэтому они пригласили представителей SEI, чтобы оценить уровень зрелости компании. Оценка завершена, и вас всех собрали в конференц-зале. Главный эксперт SEI вступает на подиум, чтобы объявить результаты исследования. В зале наступает тишина…

«Дамы и господа, у нас есть удивительная новость. Мы завершили оценку и определили ваш уровень по пятиуровневой шкале СММ. Выяснилось, что ваша организация обладает… Уровнем 6! Да-да, Уровнем 6. Мы даже не знали, что такой уровень существует, до того как посетили вашу организацию. Это удивительный день для всех нас. Мы чувствуем себя так, словно открыли новый элемент периодической системы. Вы лучшая из известных человечеству организаций по созданию программного обеспечения. Спасибо, всего хорошего».

Как, хорошая новость? Ну и что теперь с ней делать? Чем сильнее вера в осмысленность оценки, тем более вы склонны приниматься за более сложные задачи. Поднимать планку. Вы можете привлечь своих людей к работе над приложениями, которые более мелкие организации создать не способны. Если вы лучшая из известных человечеству организаций по созданию программного обеспечения, нет смысла давать людям работу, которую способен выполнить средней глупости человек. Лучше пусть конкуренты завидуют вашей способности решать самые сложные задачи. И если время от времени вы терпите поражение, что с того? Когда-то ведь будет и успех, и тогда это точно будет продукт, достойный организации Уровня 6. Если требуется делать рутинную работу, её исполнение можно и заказать. Существует множество просто компетентных организаций, способных делать простую работу.

Поднятие планки означает увеличение рисков. Чем больше ваш опыт, тем большим рискам вы подвергаетесь. Глупо поступать иначе.

Чем больше вы совершенствуете свои рабочие методы, тем сложнее будет работа. Это происходит по двум причинам: во-первых, совершенствуя методы, мы, как правило, перекладываем приземлённые задачи на машины (скажем, сегодня SQL-выражения могут генерироваться программами, а раньше этим занимались люди) или вовсе выносим за пределы проекта (так, изобретение электронных таблиц переложило огромный объём работы с разработчиков на деловых людей). Оставшиеся задачи имеют более высокую интеллектуальную насыщенность; они требуют более серьёзного опыта и умений. Настоящий прогресс в модернизации процесса приводит к увеличению потребности в более квалифицированных кадрах.

Вторая причина: модернизированные методы позволяют вам приступать к решению более сложных задач. И вы берётесь за них… если не вмешается Тёмная сторона…

Модернизация процессов: ведёт ли она к Тёмной стороне?

^[79]

«Люк,
[80]прислушайся к своему сердцу. Ты знаешь, сколь великие финансовые выгоды будут твоими, если ты перейдёшь на Уровень 4. (И помни, лишь Императору дозволено быть на Уровне 5.) Сметай преграды на своём пути, Люк. Перейди на Тёмную сторону… Вот план: мы будем давать ход лишь проектам, которые в точности повторяют прошлые. Мы будем работать только в хорошо знакомых областях. Мы создадим процесс, замечательно подходящий для этих идеальных ситуаций. Мы задокументируем все, что движется. Пангалактиче-ская Процесс-Полиция будет совершенно очарована нашей цельной реализацией идеально управляемого процесса разработки программ. Ты получишь обетованный гигантский бонус за модернизацию процесса разработки, и тогда нужно будет действовать быстро. Обналичь этот чек прежде, чем твоя организация отправится к праотцам».
[81]

Организации всего мира вынуждены карабкаться по лестнице СММ. В крайних случаях они изо всех сил стремятся заполучить Уровень+1 к завтрашнему дню, а не то… Это и есть Тёмная Сторона, ибо она соблазняет безопасным поведением и отсутствием риска и, следовательно, низкоприбыльными проектами.

Великое противоречие модернизации процессов

Вам нужна такая квалификация, какую только способна выдержать организация. И нужна она, чтобы приниматься за проекты с повышающимся риском. Ключевые области процесса, обозначенные SEI, будут полезны в накоплении опыта, поскольку определяют набор умений, стремиться к которому должен любой хороший руководитель проектов по разработке ПО. Сосредоточьтесь на умениях, необходимых для ключевых областей процесса (Key Process Areas, KPAs), но делайте все возможное, чтобы предотвратить официальный подсчёт баллов.

Если ваша организация уже находится на Уровне 2 или более высоком, запомните следующее:

Достойные проекты – это те, что перемещают вас ВНИЗ на целый уровень.

Возможно, лишь эти проекты вы можете себе позволить.

30. Как сделать перемены возможными

Эти слова Стив произнёс перед аудиторией ИТ-руководителей, которых его мнение более чем обеспокоило. Поначалу им было удобно ему возражать: «Послушайте, мы ведь создаём системы, которые изменяют привычные людям способы работать и играть. Мы очень стараемся гарантировать, что эти изменения будут к лучшему. Мы объясняем, чем лучше новый способ, иногда даже используем для этого точную логику. С чего бы рациональный человек стал противиться переменам к лучшему?» Стив парировал: «Вы не понимаете. Прощу прощения, но люди действительно искренне ненавидят изменения. В этом-то и проблема: они отвергают любые перемены. Это потому, что они ненавидят перемены». И он привёл очень убедительные примеры. Мало-помалу смысл дошёл до аудитории, так что пришлось приглашать консультантов по кризисным вопросам.

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

А теперь послушаем другого знаменитого системного консультанта

Мы склонны считать, что Макиавелли был циником, но едва ли можно сомневаться, что он воображал себя реалистом. Он не хотел представить человечество в невыгодном свете, но лишь высказать голую правду, какой он её видел. Книгу «Государь» он написал в качестве учебника для юного Лоренцо Медичи, который вступал в права правления городом-государством Флоренция. (Семья Медичи построила закрытую воздушную дорожку над Арно, соединившую родовой замок с правительственным зданием, чтобы подстраховаться на случай покушения. Будете во Флоренции, обязательно взгляните на эту дорожку, она ещё сохранилась.) Целью книги было познакомить молодого наследного принца с реальностью, приятной и не очень.

«Врагами тебе становятся все те, кому на руку прежние порядки, а робкими защитниками – все те, кто может получить выгоду от новых.» Обратите внимание, что уравнение изменений не сбалансировано. Вы рискуете нажить врагов из числа тех, кто овладел старыми способами – ведь вы вынуждаете их снова занять неудобное положение новичков – и получаете лишь малую поддержку от тех, кому перемены выгодны. Почему так? Почему проявляют малодушие те, кто получит больше всего пользы от перемен? Потому что люди ненавидят перемены. Когда мы ступаем на путь перемен, нет гарантий, что все получится. А неопределённость гораздо сильнее, чем потенциальные выгоды.

Классная идея, босс. Займусь немедленно.

Пытаясь исследовать перемены, вы порой выслушиваете весьма разнообразные мнения. Джерри Джонсон (Jerry Johnson) из Института бизнеса Меннингера, предположил, что это разнообразие следует определённому шаблону, который он назвал «Спектром сопротивляемости переменам»:
[83]

Рис. 30.1. Спектр сопротивляемости переменам

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

Взгляните на этот спектр и спросите себя, кто из этих людей – ваши потенциальные враги, а кто – возможные союзники? Очевидно, активно противодействующие опасны, они будут искать способы вернуться к прежнему состоянию любой ценой. Вы можете заключить, что слепо преданные – хорошие ребята, а остальные просто нытики, и что слепо преданные станут союзниками, а остальных можно записать во враги.

Джерри указывает, что подобный взгляд неверен. Так, мы должны осознавать опасность, которую представляют слепо преданные. Они, вероятно, достаточно безобидны и готовы следовать за любой модной идеей. Ими правит мода момента: «Надо перестать использовать этот бухгалтерский пакет, мы и сами не хуже можем сделать системку на базе интранет-сети с применением Java Без Кофеина. Стоп. Не надо без кофеина. Я только что видел на сайте Computing This Nanosecond рекламу Double-Java latte с пенистыми апплетами». Их поддержка улетучится столь же быстро, как появилась, потому что иначе они не смогут последовать за новой модой.

Джонсон утверждает, что верующие, но способные оспорить – единственные разумные союзники любых перемен. Две крайности – слепо преданные и активно противодействующие – настоящие враги. Успех перемен будет зависеть от того, как вы сумеете справиться с верующими, способными подвергать перемены сомнению. Кстати сказать, не рассчитывайте на козыри логики: сохраняющие нейтралитет союзники типа бабушка-надвое-сказала никогда не поддадутся только на рациональное обсуждение того, почему новые способы лучше имеющихся. Вот фраза, которую можно повторять про себя, намереваясь предложить людям перемены:

МАНТРА: Основная реакция на перемены не логическая, но эмоциональная.

Как разработчики систем мы изолировали себя в мире спокойных, ровных, рациональных размышлений. Код или компилируется, или нет. Компилятор не испытывает за нас радости, как и не способен разозлиться. Возможно, поэтому мы склонны считать логику своим главным оружием разрешения диспутов.

Вы можете представить себя за терпеливым объяснением собственному ребёнку: «Я знаю, что ты хочешь велосипед, но сейчас ведь не твой день рождения и не Рождество, а именно эти даты календаря позволяют тебе разумно ожидать подарка. Если ты накопил нужную сумму из денег на карманные расходы, то можешь купить велосипед сам.» И вас может раздражать не-очень-логичный-ответ вроде: «Но я хочу велосипед! Прямо сейчас хочу.»

Когда мы логически аргументируем перемены, одним из подходов является перечисление преимуществ нового мира, избавляющих от недостатков старого. Но задумайтесь: кто способствовал образованию существующей ситуации? Кто хозяева способов, которые мы сейчас используем в работе? Могут ли эти люди принять за оскорбление попытки урезать текущий режим работы? Ещё как могут. Уильям Бриджес (William Bridges) в книге «Managing Transitions» (Управление развитием) советует никогда не принижать значение прежнего пути
[84]. Вместо этого следует воспевать прежние достижения, чтобы способствовать переменам. К примеру:

«Ребята, система CGS проработала четырнадцать лет. По нашим оценкам она идеально справилась более чем с миллионом взлётов и посадок. Аппаратная платформа технически устарела, а кроме того, появилась новая технология удалённого сканирования, преимуществами которой мы можем воспользоваться. Сейчас у нас есть шанс перепланировать и заново выстроить всю систему. Нам нужны вы и ваш опыт, накопленный за годы успешного использования CGS, чтобы этот проект удался».

В целом, может быть, полезно напомнить людям, что любые улучшения подразумевают перемены:

Другая модель изменений

Вот так большинство из нас думает об изменениях (рис. 30.2):

Идея в таком (наивном) представлении – простое видение «лучшего способа» делать что-либо – напрямую меняет старое на новое. «Мы устойчиво работали в старом режиме, но тут на Харви нашло вдохновение, и мы переключились на новый, несомненно, более совершённый во всех отношениях способ вести дела». Если говорить честно, не может быть, чтобы все было так просто. И все совсем не так просто.

Сопоставьте эту наивную модель изменений с подходом к изменениям, предложенным специалистом по семейной терапии, ныне покойной Вирджинией Сатир
[85](рис. 30.3).

Изменение включает как минимум перечисленные стадии. Осмысленные изменения невозможны без двух промежуточных этапов.

В модели Сатир изменение происходит в момент появления внешнего элемента – катализатора изменений. Без катализатора невозможно осознание необходимости изменений. Внешним элементом может быть внешняя сила или же осознание изменений вашего мира.

Внешняя сила: Уоттс Хамфри появляется у вас в офисе и объявляет, что ваше производство находится на Уровне 0. Хмммм.

или

Мир меняется: Квартальные продажи вашего флагманского продукта впервые в истории упали. Ооой.

Пытаясь инициировать изменения, вы столкнётесь прежде всего с Хаосом. Вы это уже проходили – убеждённость в том, что новый инструмент, новый метод, новый подход гораздо хуже, чем прежний. Люди говорят вещи вроде «Если бы только сбросить этот новый балласт, тогда мы, наверное, сможем догнать расписание…» Вы попадаете в провал на кривой обучения, и в этот момент оценка изменений как главного источника проблем может оказаться правильной. Все становится хуже, чем раньше. Отчасти по этой причине реакция на изменения столь эмоциональна. Необходимость оставить подходы и методы, которыми вы давно овладели, и снова стать новичком раздражает и приводит в замешательство. Вряд ли кому-то нравится это ощущение, будто барахтаешься: вы просто знаете, что прежние способы лучше. К сожалению, без перехода через Хаос никак не обойтись и «срезать» не получится.

Преобразующая идея – спасительная соломинка, позволяющая людям в Хаосе надеяться на скорое избавление от страданий. Структурированная сумятица – зачастую лучшее лекарство: «Думаю, мы начинаем вживаться в программирование на C++, но как бы нам каждый день часа в четыре встречаться по поводу определения классов?»

Фаза практики и интеграции находится на подъёме кривой обучения. Вы ещё не совсем освоились, поскольку не имеете достаточного опыта работы с новыми вещами, но соглашаетесь, что эти вещи начинают приносить пользу или по крайней мере дают подобную перспективу.

Новый статус-кво достигается, когда то, что раньше считалось изменением, становится рутиной. Интересное свойство человеческих эмоций: чем больнее переход через Хаос, тем выше субъективная оценка нового статус-кво – конечно, если его удаётся достичь.

Модель Сатир очень важна, потому что показывает, что Хаос есть неотъемлемая составляющая изменений. Используя более наивную двухступенчатую модель, мы не ожидаем хаоса. И когда он наступает, мы ошибочно принимаем его за новый статус кво. И раз новый статус кво кажется столь хаотичным, мы думаем: «Ой-ой, кажется, ошибочка вышла, давайте-ка вернёмся к прежнему варианту». Призыв к возврату обязательно будет услышан чётко и ясно посреди любых амбициозных перемен.

Если же вы ожидаете хаоса, ваши шансы успешно его пережить значительно повышаются.

Безопасность прежде всего

Изменения не могут даже начаться, если люди не чувствуют себя в безопасности. А они чувствуют себя в безопасности, если знают, что не будут унижены или понижены в должности за то, что предложили перемены или попытались перемены пройти. Временная утрата мастерства достаточно сильно стесняет большинство из нас; стоит только в Хаосе появиться очагу паники, и все рванут под защиту прежнего статус-кво.

Наша врождённая боязнь Хаоса помогает объяснить, почему изучать что-либо, будучи ребёнком, настолько проще, чем изучать то же, будучи взрослым.

Сколько раз вы слышали, что какой-то новый метод будет применён потому, что это единственная возможность успеть к жёсткому сроку, и если к сроку не успеть, неприятностей не оберёшься? Первый этап перемен сразу же ставит под вопрос исход предприятия. Детскую склонность бросаться в потенциально опасные предприятия душит страх осмеяния.

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