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

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

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

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

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

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

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

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

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

Запишите это

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

Оформление регистрационной карточки от руки

Любой член команды может создать карточку. Хотя это бывает нечасто, карточки могут создавать и члены команды, не участвующие в работе по проекту, – и даже клиенты.

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

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

Никакой работы без оценки

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

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

Объявите о том, что вы делаете и чего вы не делаете

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

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