Наша главная проблема — прогресс

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

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

Выразив идею столь смело, мы можем достаточно легко собрать перечень способов реализации подобной политики:

· пилотные проекты;

· военные игры;

· мозговые штурмы;

· провокационные курсы;

· обучение, путешествия, конференции, торжества, отдых.

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

Пилотные проекты

Пилотный проект — это такой, в котором вы откладываете в сторону толстый том стандартов и пробуете новый, неизученный метод. Новый метод вам не знаком, поэтому поначалу можно ожидать низкой производительности. Такова цена изменений. Обратная сторона медали — повышение производительности в результате применения нового метода. Кроме того, добавляется ещё эффект Готорна — прирост энергии и интерес, наполняющий людей, когда они изучают что-то новое и непривычное.

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

По нашему опыту пилотные проекты тяготеют к средней производительности, превышающей средние показатели. Это означает, что затраты на проект будут, вероятно, меньше, если вы решите сделать проект пилотным, то есть решите использовать какой-то новый метод.

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

Существует два возражения против любой расширенной программы пилотных проектов:

· Что делать, если закончатся новые идеи?

· Не усложнится ли ещё более сопутствующая деятельность (поддержка продукта, обучение клиентов и т. д.), если мы начнём поставлять не устойчивую продукцию?

Первое возражение имеет смысл лишь в теории. Большинству организаций после десятилетних испытаний новых подходов редко (если вообще) приходится волноваться из-за того, что новые подходы закончатся. Если начать исследовать все хорошие идеи, на которые мы не обращали внимание в шестидесятых, затем перейти к семидесятым и восьмидесятым, то к моменту, когда исследование завершится, пройдёт ещё десятилетие и появятся многочисленные новые идеи.

Что касается проблемы неустойчивых продуктов, то почему бы не признать, что такая проблема существует даже в случае следования жёстким стандартам? Существующая стандартизация привела к документальной стабильности продуктов, но никак не к осмысленной функциональной стабильности. Иначе говоря, стандартизация в основном затронула бумажную работу, связанную с продуктами, но не сами продукты. Если же бумажный вариант проекта немного отличается от стандартного, то серьёзных неудобств это не вызовет.

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

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

Военные игры[67]

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

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

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

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

2. Подготовьте проект обычным образом — опубликуйте техническое задание.

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

4. Распространите техническое задание заранее, наряду с правилами и целями состязания.

5. В день состязания только его участники должны присутствовать в офисе. Позаботьтесь, чтобы у них было все необходимое: еда, компьютеры, кушетки, копировальные аппараты, конференц-залы — все что угодно.

6. Все команды должны выполнять одну и ту же работу, причём в отведённое для состязания время.

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

8. Ищите возможности сделать каждого победителем в определённом смысле — по общему времени работы, по надёжности продукта, по оригинальности решений. Создавайте много шума вокруг каждого достижения.

9. Установите победивший продукт или же несколько продуктов-победителей одновременно. Внимательно следите за временем стабильной работы продукта, количеством изъянов, уровнем дружественности продукта к пользователю, стоимостью изменений и любыми другими параметрами, определяющими успех проекта. Сообщайте значимые данные командам.

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

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

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

«В ходе мероприятия я заметил, как [68] прикорнула на коврике в приёмной. Я знал её много лет и всегда считал немного чопорной. Но с этого момента я стал относиться к ней иначе. Я стал иначе относиться ко всем. Мы прошли через это вместе».

(Из обсуждения состязания)

Мозговой штурм

Мозговой штурм[69] — это структурированный сеанс взаимодействий, ориентированный в целом на возникновение творческих озарений. До шести человек собираются вместе, чтобы сосредоточиться на определённой проблеме. Правила проведения сеанса и уловки ведущего способствуют получению приятного и неорганизованного опыта, который часто приносит действительно ценные плоды.

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

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

· Мышление по аналогии (как эта или похожая проблема решается в природе?)

· Обращение (как мы можем добиться противоположной цели?)

· Погружение (как вы можете спроецировать эту проблему на себя?)