Новые лидеры в Menlo должны чувствовать себя в безопасности, поскольку они испытывают свои новые навыки. Если такого чувства нет, то их собственный страх легко перейдет на других, и это приведет к утечке нашей креативности, нашего воображения и радости.
В бизнесе страх может прийти откуда угодно: причиной его становятся конкуренты, скверные работники, плохие дни у хороших работников, экономические потрясения, низкие зарплаты, неоплаченные инвойсы, изменение условий на рынке, вечерние новости, сплетни. Спокойный, думающий лидер может пройти долгий путь в попытке снизить уже возникший страх.
Есть один классический сценарий, который часто повторяется в Menlo, – когда клиент приносит свой страх в помещение. Мы все следуем вековой мантре, сидящей в наших головах: клиент всегда прав.
Но это не так. На самом деле редко когда клиент оказывается прав. Если клиент всегда прав, тогда зачем ему мы? Сказанное особенно верно для таких компаний, как наша, где клиенты просят создать абсолютно новый продукт для их сферы деятельности, в которой они часто выступают экспертами и доминирующими игроками. Они ищут что-то новое, убедительное и конкурентоспособное. Наши трудности редко когда заключаются в том, чтобы придумать что-то инновационное и восхитительное, чаще они сводятся к преодолению сопротивления клиентов к изменениям.
Мы должны бороться за то, что мы считаем правильным, исходя из нашего опыта, таланта и знаний. В таких схватках нужно держаться того, что мы обнаружили при наших наблюдениях и многократном тестировании дизайна. Это конструктивное противостояние является сложным и важным и касается сердца нашей культуры – наших ценностей.
Тем не менее моя команда сознает, что, занимая твердую позицию, мы можем добиться того, что клиент просто уволит нас. А в таком случае он, возможно, даже не оплатит один или несколько счетов. Отстаивание своих убеждений может иметь для нас очень даже реальную стоимость.
В других случаях мы можем отказаться от сотрудничества с клиентом. Для Menlo это вполне реально. Несколько лет назад у нас был серьезный заказчик, с которым мы чувствовали явную культурную несовместимость. Испробовав все возможные подходы, предлагая лучшие, по нашему мнению, пути для клиента, мы – и Menlo, и клиент – в итоге признали свою неспособность соответствовать друг другу и построили продуманный план, чтобы проект не остался без внимания в процессе перехода к новым исполнителям.
Хотя такое решение означало финансовые потери, я считаю его одним из самых важных решений, которые я мог сделать, чтобы поддержать нашу культуру. Это всегда непросто. Это всегда вызывает затруднения. Тут как с увольнением сотрудников: мы должны делать все с сохранением собственного достоинства и уважением к другой стороне. Должен признаться, что наиболее приятным аспектом успешной передачи проекта того клиента из Menlo оказался тот факт, что мы до сих пор поддерживаем дружеские отношения с новыми исполнителями проекта. Они по-прежнему то и дело обращаются к нам за советом.
Наши команды – и моя, и ваша – смотрят и слушают, они наблюдают за своими лидерами на сложных участках пути. Вот место, где резина нашей культуры радости встречается с дорогой.
Глава 9
Прекратите хаос, не допускайте двусмысленности
Сделай простейшие вещи, которые, скорее всего, могут сработать.
Кент Бек,
«Экстремальное программирование»
[37] В моей прежней хаотичной жизни вице-президента в Interface Systems, еще до основания «фабрики Java», меня время от времени приглашали в зал заседаний совета директоров и просили сделать квартальную презентацию о «состоянии дел» в команде исследования и разработок, которой я руководил. Я должен был показать цели прошедших трех месяцев, наш прогресс за этот период, упомянуть, что мы работали над проектами, не входящими в план, показать обновленный план с новыми целями и поделиться своими соображениями о том, как эти цели связаны с остальной деятельностью компании. В конце презентации мои коллеги из руководства компании обычно выказывали некоторое разочарование тем, что моя команда опять сошла с заявленного в предыдущем квартале пути из-за незапланированных задач. Затем они одобряли обновленный план и делали несколько основанных на страхе замечаний о том, как важно придерживаться заданного пути, потому что планы всех их отделов зависели от выполнения поставленных задач моей командой.
Обычно я не успевал отойти дальше полуметра от зала для заседаний, как кто-то из вице-президентов или менеджеров по продукции отводил меня в сторону и говорил что-то вроде: «Отличная презентация, Рич, но есть один момент, который я хотел с тобой обсудить. Мне нужен Арон, чтобы сделать специальное обновление для клиента. Если он сможет закончить к пятнице, то мы закроем сделку». Это было расползание границ проекта в действии.
Конечно, поначалу я старался быть всегда готовым помочь бойскаутом, так что я каким-то образом умудрялся выискивать пути и делать дополнительную работу.
Но в итоге я понял, что такой «коридорный» подход к управлению проектами не сделает мою жизнь ни на каплю лучше. Кроме того, подобные ситуации – это ад для любого программиста. Каждый квартал я докладывал о перечне дел, которыми мы занимались за прошедшее время, – и он не имел практически никакого отношения к заявленным мною целям. Поэтому я начал пытаться получить одобрение поставленных целей у всех присутствующих на заседании, в том числе у СЕО. Согласование со всеми быстро покончило с коридорными разговорами.
В конце концов коллеги из руководящего состава поняли, что на самом деле я не нужен на собраниях. С этого момента большая часть уточнения определения приоритетов для моей команды стала происходить на боулинге, или на игре в гольф, или в баре после работы.
Но однажды утром я пришел в офис и увидел, как мои программисты упорно трудятся над заданием, которого я им не давал.
Независимо от того, в какой очереди находились текущие задания для моей команды, в то время все они уже принадлежали мне. Мои коллеги перестали требовать от меня обновленных отчетов. Они хотели знать, когда новые приоритетные задачи окажутся выполненными. Мои же разработчики, не будучи экспертами по тайм-менеджменту, вернулись к проверенному веками стандарту оценки времени: стали ориентироваться на абстрактные «пару дней».
Когда я слышал от кого-то, что работа над заданием займет «пару дней», я думал: «Отлично, значит, этот сотрудник будет занят пару дней». Через три дня я спрашивал, как идут дела. Обычно в ответ мне раздавалось бодрое «Отлично!». Мне казалось, что все хорошо, пока я не проверял результаты вышеупомянутого двухдневного задания. И тогда я обнаруживал, что данный проект находится ровно в том же состоянии, в котором я его видел в прошлый раз. Обычно это сопровождалось объяснением, что работе помешали неожиданные перерывы, как правило, связанные с возникшей у клиента острой проблемой, которая отвлекла внимание программистов от их проекта на «пару дней».
