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