Глава 9 Прекратите хаос, не допускайте двусмысленности

Глава 9

Прекратите хаос, не допускайте двусмысленности

Сделай простейшие вещи, которые, скорее всего, могут сработать.

Кент Бек,

«Экстремальное программирование»[37]

В моей прежней хаотичной жизни вице-президента в Interface Systems, еще до основания «фабрики Java», меня время от времени приглашали в зал заседаний совета директоров и просили сделать квартальную презентацию о «состоянии дел» в команде исследования и разработок, которой я руководил. Я должен был показать цели прошедших трех месяцев, наш прогресс за этот период, упомянуть, что мы работали над проектами, не входящими в план, показать обновленный план с новыми целями и поделиться своими соображениями о том, как эти цели связаны с остальной деятельностью компании. В конце презентации мои коллеги из руководства компании обычно выказывали некоторое разочарование тем, что моя команда опять сошла с заявленного в предыдущем квартале пути из-за незапланированных задач. Затем они одобряли обновленный план и делали несколько основанных на страхе замечаний о том, как важно придерживаться заданного пути, потому что планы всех их отделов зависели от выполнения поставленных задач моей командой.

Обычно я не успевал отойти дальше полуметра от зала для заседаний, как кто-то из вице-президентов или менеджеров по продукции отводил меня в сторону и говорил что-то вроде: «Отличная презентация, Рич, но есть один момент, который я хотел с тобой обсудить. Мне нужен Арон, чтобы сделать специальное обновление для клиента. Если он сможет закончить к пятнице, то мы закроем сделку». Это было расползание границ проекта в действии.

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

Но в итоге я понял, что такой «коридорный» подход к управлению проектами не сделает мою жизнь ни на каплю лучше. Кроме того, подобные ситуации – это ад для любого программиста. Каждый квартал я докладывал о перечне дел, которыми мы занимались за прошедшее время, – и он не имел практически никакого отношения к заявленным мною целям. Поэтому я начал пытаться получить одобрение поставленных целей у всех присутствующих на заседании, в том числе у СЕО. Согласование со всеми быстро покончило с коридорными разговорами.

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

Но однажды утром я пришел в офис и увидел, как мои программисты упорно трудятся над заданием, которого я им не давал.

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

Когда я слышал от кого-то, что работа над заданием займет «пару дней», я думал: «Отлично, значит, этот сотрудник будет занят пару дней». Через три дня я спрашивал, как идут дела. Обычно в ответ мне раздавалось бодрое «Отлично!». Мне казалось, что все хорошо, пока я не проверял результаты вышеупомянутого двухдневного задания. И тогда я обнаруживал, что данный проект находится ровно в том же состоянии, в котором я его видел в прошлый раз. Обычно это сопровождалось объяснением, что работе помешали неожиданные перерывы, как правило, связанные с возникшей у клиента острой проблемой, которая отвлекла внимание программистов от их проекта на «пару дней».

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

Эта система, возможно, даже имела шанс стать работоспособной, если бы не одна вопиющая проблема: вся прочая часть компании была не одной командой, а скопищем воюющих за землю феодалов. Каждый хозяин своей территории по-настоящему заботился только о том, чтобы его проекты были вовремя завершены. Я мало что мог сделать для внесения ясности, потому что никто на самом деле не знал, что происходит, – даже я.

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

Сегодня я с радостью могу сказать, что за всю историю Menlo не было ни одной из этих проблем. И хотя многие из наших посетителей рассказывают о трех сотнях звонков в день на их горячую линию, за всю нашу двенадцатилетнюю историю у нас набралось всего несколько таких обращений. Последний случай на памяти моей команды, когда у клиента произошла срочная проблема в стиле «Бросайте все!», имел место в 2004 году.

Причина, по которой нам удается избегать хаоса в Menlo, проста: наша работа строится на прозрачности, простоте и предсказуемости.

Данный текст является ознакомительным фрагментом.