Обычно я не успевал отойти дальше полуметра от зала для заседаний, как кто-то из вице-президентов или менеджеров по продукции отводил меня в сторону и говорил что-то вроде: «Отличная презентация, Рич, но есть один момент, который я хотел с тобой обсудить. Мне нужен Арон, чтобы сделать специальное обновление для клиента. Если он сможет закончить к пятнице, то мы закроем сделку». Это было расползание границ проекта в действии.
Конечно, поначалу я старался быть всегда готовым помочь бойскаутом, так что я каким-то образом умудрялся выискивать пути и делать дополнительную работу.
Но в итоге я понял, что такой «коридорный» подход к управлению проектами не сделает мою жизнь ни на каплю лучше. Кроме того, подобные ситуации – это ад для любого программиста. Каждый квартал я докладывал о перечне дел, которыми мы занимались за прошедшее время, – и он не имел практически никакого отношения к заявленным мною целям. Поэтому я начал пытаться получить одобрение поставленных целей у всех присутствующих на заседании, в том числе у СЕО. Согласование со всеми быстро покончило с коридорными разговорами.
В конце концов коллеги из руководящего состава поняли, что на самом деле я не нужен на собраниях. С этого момента большая часть уточнения определения приоритетов для моей команды стала происходить на боулинге, или на игре в гольф, или в баре после работы.
Но однажды утром я пришел в офис и увидел, как мои программисты упорно трудятся над заданием, которого я им не давал.
Независимо от того, в какой очереди находились текущие задания для моей команды, в то время все они уже принадлежали мне. Мои коллеги перестали требовать от меня обновленных отчетов. Они хотели знать, когда новые приоритетные задачи окажутся выполненными. Мои же разработчики, не будучи экспертами по тайм-менеджменту, вернулись к проверенному веками стандарту оценки времени: стали ориентироваться на абстрактные «пару дней».
Когда я слышал от кого-то, что работа над заданием займет «пару дней», я думал: «Отлично, значит, этот сотрудник будет занят пару дней». Через три дня я спрашивал, как идут дела. Обычно в ответ мне раздавалось бодрое «Отлично!». Мне казалось, что все хорошо, пока я не проверял результаты вышеупомянутого двухдневного задания. И тогда я обнаруживал, что данный проект находится ровно в том же состоянии, в котором я его видел в прошлый раз. Обычно это сопровождалось объяснением, что работе помешали неожиданные перерывы, как правило, связанные с возникшей у клиента острой проблемой, которая отвлекла внимание программистов от их проекта на «пару дней».