Существует два возражения против любой расширенной программы пилотных проектов:
• Что делать, если закончатся новые идеи?
• Не усложнится ли ещё более сопутствующая деятельность (поддержка продукта, обучение клиентов и т. д.), если мы начнём поставлять не устойчивую продукцию?
Первое возражение имеет смысл лишь в теории. Большинству организаций после десятилетних испытаний новых подходов редко (если вообще) приходится волноваться из-за того, что новые подходы закончатся. Если начать исследовать все хорошие идеи, на которые мы не обращали внимание в шестидесятых, затем перейти к семидесятым и восьмидесятым, то к моменту, когда исследование завершится, пройдёт ещё десятилетие и появятся многочисленные новые идеи.
Что касается проблемы неустойчивых продуктов, то почему бы не признать, что такая проблема существует даже в случае следования жёстким стандартам? Существующая стандартизация привела к документальной стабильности продуктов, но никак не к осмысленной функциональной стабильности. Иначе говоря, стандартизация в основном затронула бумажную работу, связанную с продуктами, но не сами продукты. Если же бумажный вариант проекта немного отличается от стандартного, то серьёзных неудобств это не вызовет.
Одно предостережение по поводу пилотных проектов: не экспериментируйте более чем с одним технологическим аспектом в пределах проекта. Несмотря на все разговоры о важности стандартов, просто удивительно, насколько часто руководители забывают обо всяких стандартах в редких пилотных проектах. Они часто испытывают новые аппаратные средства, новые программы, новые процедуры контроля качества, матричное руководство, а ещё новые методы создания прототипов – и все в одном проекте.
Разумный подход к пилотному проекту – разрешить изменить лишь одну составляющую процесса. В здоровой среде участники проекта поймут, что экспериментировать с одним новым методом в каждом проекте – это нормально, но в целом следует всегда придерживаться стандарта.
Военные игры
[67]
За четыре года существования наших военных манёвров разработчиков мы узнали, что иногда жёсткое состязание, в котором нет проигравших, может стать замечательным источником созидательного беспорядка. Наши игры ориентированы на сообщество разработчиков программного обеспечения, но идею можно применять практически в любой области. Независимо от рода вашей деятельности, возможность испробовать себя в решении специализированных задач и сравнить свои результаты со статистикой производительности коллег может быть весьма интересной. (Конечно же, такой опыт приятен лишь при наличии гарантий конфиденциальности, описанных в главе 8. Вы должны быть уверены, что результаты состязаний не будут использованы против вас.)
Военные манёвры помогают вам оценить свои плюсы и минусы по относительной шкале, помогают организации выявить свои плюсы и минусы в глобальном масштабе. По этим причинам две из наших клиентских компаний разработали программу по ежегодному проведению военных манёвров, чтобы позволить своим сотрудникам измерять рост собственной квалификации с течением времени. Раз в год сотрудники подвергают себя конфиденциальным испытаниям (в чем-то это похоже на медосмотр).
С целью стимуляции творческого беспорядка наиболее эффективная из разновидностей военных игр предлагает участникам объединяться в команды. Ниже приведена одна из формул таких манёвров, которую мы применяли до некоторой степени успешно (и с огромным интересом):
1. Подберите маленький проект по разработке или чётко поставленную задачу; это будет ваш подопытный кролик. Лучший выбор – реальная для вашей организации задача, требующая от одного до двух человеко-месяцев работы. Выбирайте проблему, обладающую новизной, не простую, но при этом широко задействующую рабочие навыки ваших сотрудников.
2. Подготовьте проект обычным образом – опубликуйте техническое задание.
3. Объявите о проведении двадцатичетырехчасового состязания в ближайшие выходные. Постарайтесь объяснить всем, что вы не экономите за счёт выходных своих сотрудников. Объясните, что состязание проводится на выходных, чтобы команды могли свободно чувствовать себя на рабочих местах, а не из соображений экономии на человеческих ресурсах. Предложите участникам объединиться в команды по четыре человека и участвовать в состязании на совершенно добровольной основе.
4. Распространите техническое задание заранее, наряду с правилами и целями состязания.
5. В день состязания только его участники должны присутствовать в офисе. Позаботьтесь, чтобы у них было все необходимое: еда, компьютеры, кушетки, копировальные аппараты, конференц-залы – все что угодно.
6. Все команды должны выполнять одну и ту же работу, причём в отведённое для состязания время.
7. Подготовьте добровольцев, которые будут следить за соблюдением правил, предотвращать фатальные осложнения и устраивать большой шум по поводу каждого промежуточного финиша.
8. Ищите возможности сделать каждого победителем в определённом смысле – по общему времени работы, по надёжности продукта, по оригинальности решений. Создавайте много шума вокруг каждого достижения.
9. Установите победивший продукт или же несколько продуктов-победителей одновременно. Внимательно следите за временем стабильной работы продукта, количеством изъянов, уровнем дружественности продукта к пользователю, стоимостью изменений и любыми другими параметрами, определяющими успех проекта. Сообщайте значимые данные командам.
Когда вы все это успешно осуществите, люди сообщат вам, что это был самый восхитительный и интересный опыт за все время их работы; а это как раз и было вашей целью. Стремитесь к её достижению, даже если поначалу не все получается, как задумано.
Приведём некоторые соображения по поводу опытов вроде проектных состязаний. Во-первых, подобные мероприятия стоят денег. Не надейтесь, что ваши сотрудники, словно под гипнозом, за выходные создадут нечто, что в противном случае пришлось бы оплачивать по полной ставке. Проектное состязание обойдётся вам в несколько раз дороже, чем проведение того же проекта в рабочее время. Во-вторых, не пожалейте времени на подготовку чёткой постановки задачи, на обучение своих ассистентов к этому мероприятию, на создание многочисленных промежуточных финишей. В-третьих, приложите усилия, чтобы соразмерить масштаб проекта с выделенным на его выполнение временем (мало кто получит удовольствие, если все команды окажутся побеждёнными или если состязание закончится через час после начала). Наконец, изыщите возможность щедро потратиться на кормление участников (в одном из состязаний мы заказали пикник-ланч из одного нью-йоркского ресторана, устроили обед с доставкой, а потом, в два часа ночи, затащили всех в китайский квартал перекусить.)
