Работа мечты. Как построить компанию, которую любят
Шрифт:
Обычно я не успевал отойти дальше полуметра от зала для заседаний, как кто-то из вице-президентов или менеджеров по продукции отводил меня в сторону и говорил что-то вроде: «Отличная презентация, Рич, но есть один момент, который я хотел с тобой обсудить. Мне нужен Арон, чтобы сделать специальное обновление для клиента. Если он сможет закончить к пятнице, то мы закроем сделку». Это было расползание границ проекта в действии.
Конечно, поначалу я старался быть всегда готовым помочь бойскаутом, так что я каким-то образом умудрялся выискивать пути и делать дополнительную
Но в итоге я понял, что такой «коридорный» подход к управлению проектами не сделает мою жизнь ни на каплю лучше. Кроме того, подобные ситуации – это ад для любого программиста. Каждый квартал я докладывал о перечне дел, которыми мы занимались за прошедшее время, – и он не имел практически никакого отношения к заявленным мною целям. Поэтому я начал пытаться получить одобрение поставленных целей у всех присутствующих на заседании, в том числе у СЕО. Согласование со всеми быстро покончило с коридорными разговорами.
В конце концов коллеги из руководящего состава поняли, что на самом деле я не нужен на собраниях. С этого момента большая часть уточнения определения приоритетов для моей команды стала происходить на боулинге, или на игре в гольф, или в баре после работы.
Но однажды утром я пришел в офис и увидел, как мои программисты упорно трудятся над заданием, которого я им не давал.
Независимо от того, в какой очереди находились текущие задания для моей команды, в то время все они уже принадлежали мне. Мои коллеги перестали требовать от меня обновленных отчетов. Они хотели знать, когда новые приоритетные задачи окажутся выполненными. Мои же разработчики, не будучи экспертами по тайм-менеджменту, вернулись к проверенному веками стандарту оценки времени: стали ориентироваться на абстрактные «пару дней».
Когда я слышал от кого-то, что работа над заданием займет «пару дней», я думал: «Отлично, значит, этот сотрудник будет занят пару дней». Через три дня я спрашивал, как идут дела. Обычно в ответ мне раздавалось бодрое «Отлично!». Мне казалось, что все хорошо, пока я не проверял результаты вышеупомянутого двухдневного задания. И тогда я обнаруживал, что данный проект находится ровно в том же состоянии, в котором я его видел в прошлый раз. Обычно это сопровождалось объяснением, что работе помешали неожиданные перерывы, как правило, связанные с возникшей у клиента острой проблемой, которая отвлекла внимание программистов от их проекта на «пару дней».
Этот цикл повторялся еще два или три раза, пока я не начинал просить более серьезной оценки. И вот тогда я слышал, что работа оказалась более сложной, чем мой разработчик полагал изначально, и что сейчас он лучше понимает проект. Он менял оценочный срок на две недели. Я получал серьезную оценку. Как правило, это сопровождалось еще парой заходов, когда он говорил мне, что ему нужны еще две недели для завершения. В итоге программист приходил к оценке, что его нужно избавить от всего остального на три месяца.
Эта система, возможно, даже имела шанс стать работоспособной, если бы не одна вопиющая проблема: вся прочая часть компании была не одной командой, а скопищем воюющих за землю феодалов. Каждый хозяин своей территории
Ситуация усугублялась проблемами с качеством, которые возникали, когда уставшие программисты начинали «ночные бдения», пытаясь выполнить обязательства. Наша линия поддержки клиентов постоянно трезвонила, сообщая о неполадках, и мне приходилось все чаще бросать команду на борьбу с пожаром. Затем я получал выговор за то, что мои сотрудники выпускают продукцию отвратительного качества. Этот хаос усугублялся неоднозначностью.
Сегодня я с радостью могу сказать, что за всю историю Menlo не было ни одной из этих проблем. И хотя многие из наших посетителей рассказывают о трех сотнях звонков в день на их горячую линию, за всю нашу двенадцатилетнюю историю у нас набралось всего несколько таких обращений. Последний случай на памяти моей команды, когда у клиента произошла срочная проблема в стиле «Бросайте все!», имел место в 2004 году.
Причина, по которой нам удается избегать хаоса в Menlo, проста: наша работа строится на прозрачности, простоте и предсказуемости.
Запишите это
Одним из самых строгих правил в Menlo является запрет на любую работу по проекту клиента до тех пор, пока задание не будет зафиксировано на индексной карточке размером 14 x 22 см. Структура записи проста: на ней есть кодовое имя проекта, серийный номер карточки (начиная с 001) и короткое описание, которое определяет, какой вклад в создание конечного приложения внесет эта работа. На каждой регистрационной карточке должны стоять дата и подпись человека, который ее заполнил.
Оформление регистрационной карточки от руки
Любой член команды может создать карточку. Хотя это бывает нечасто, карточки могут создавать и члены команды, не участвующие в работе по проекту, – и даже клиенты.
Как только карточка написана, она передается менеджеру проекта. У менеджера на столе есть коробка, куда складываются новые карточки. В нашей системе порядковый номер регистрационной карточке присваивает руководитель проекта – такая практика позволяет избежать дубликатов.
Этот простой инструмент не допускает «коридорного» управления проектами. Если новое требование не записано, тогда оно – всего лишь разговор без возможности выполнения. Каждый человек в Menlo, включая наших клиентов, очень четко это понимает.
Никакой работы без оценки
Сам по себе факт, что карточка была написана, не означает, что она когда-нибудь пойдет в работу. Вот почему в нашей, как и в любой другой, культуре важно иметь четкий шаблон принятия решений, позволяющий определить, сколько времени займет каждая задача.