Человеческий фактор: успешные проекты и команды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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