Текст книги "Визуализируйте работу"

1.3. Незапланированная работа

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

Джошуа Корман

Деловой центр, США, утро вторника

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

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

Людей оторвали от важной работы. Заминка (незапланированное дело) застала всех врасплох. Это непредусмотренное последствие благих намерений управляющего негативно отразилось на первоочередной задаче, которая теперь отложена из-за помехи. Время, отнятое от работы над изначальным приоритетом, просто вычеркнуто. Это проблема незапланированной работы – она тормозит запланированную, усиливает нестабильность системы и в итоге делает ее менее предсказуемой.

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

Подчеркиваю: я не говорю, что все следует планировать. Это безответственно (возможно, даже неадекватно) – верить, что, намечая сложный проект, вы все сможете предусмотреть. Напротив, мы многого не знаем о том, чего еще не знаем. Иногда приходится резко менять направление, когда по мере работы над проблемами появляется новая информация. Основная ценность гибких методов – умение реагировать на изменения, следуя определенному сценарию. В жизни полно неопределенности. Изменения неизбежны. Это закон (а если точно, второй закон термодинамики).

Почему незапланированная работа так опасна

Незапланированная и срочная работа крадет время у дела, создающего ценность. По данным отчета State of DevOps Report 2016, результативные люди тратят на запланированную работу на 28 % больше времени[22]22
  2016 State of DevOps Report (Portland, OR: Puppet Labs, 2016) 26, https://puppet.com/resources/whitepaper/2016-state-of-devops-report.


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

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

Вы поймете, что незапланированная работа крадет ваше время, если срочные вопросы отвлекают людей от сосредоточенного занятия по созданию ценности. Это может принимать любые формы – от неожиданного инструктажа до сбоя активно используемой программы, который вносит неопределенность и нестабильность в повседневный процесс. Из-за этих заминок какие-то дела займут больше времени, чем ожидалось. Если вы регулярно отстаете от графика, скорее всего, внеплановая ситуация (сбой или стратегическое изменение направления) крадет не только ваше время, но и возможность прогнозировать.

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

Незапланированная работа не только создает собственные проблемы, но и тащит за собой все трудности слишком большого объема WIP: переключение контекста, приостановки и заминки, отложенную работу и рост расходов. Когда внеплановая ситуация (например, устранение неполадок на сайте) прерывает повседневное дело, увеличивается объем задач, ложащихся на ваши плечи. Чем более срочна незапланированная работа, которая прерывает день, тем выше гора частично выполненных дел. Тесная взаимосвязь между внезапными моментами и слишком большим объемом WIP приводит к тому, что массу неожиданных целей становится практически невозможно достичь вовремя. Если вы не будете быстро продвигаться вперед, все запланированные процессы отстанут от сроков. Превышение нагрузки станет естественным и со временем перерастет в дисфункцию и дисбаланс. Вот почему так важно научиться выявлять и как можно раньше и быстрее решать проблемы, которые создает непредсказуемая работа.

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

Делать работу видимой – основной компонент борьбы с расхитителем по имени «Незапланированная работа», а также основной компонент канбан-системы, к которой мы будем возвращаться снова и снова. Карточки отображают информацию, которая традиционно была скрыта. Они живут на канбан-досках, а те отвечают на такие вопросы: «Над чем мы сейчас работаем?», «На каком этапе находится работа?», «Кто чем занимается?» Вся значимая информация наглядно представлена на доске, так что не придется гоняться за сотрудниками с вопросом «Что происходит?» и ждать приукрашенного еженедельного отчета по статусу работы, чтобы получить хоть примерное понимание ситуации.

КЛЮЧЕВЫЕ ВЫВОДЫ

• Незапланированная работа делает систему непредсказуемой.

• Главное – прогнозируемость и ожидание. Незапланированная работа съедает ожидания на завтрак.

• Результативные компании тратят меньше времени на незапланированную работу, чем менее эффективные.

• Иногда выбора нет, нужно все бросить и заняться незапланированной работой.

• Незапланированная работа крадет время у запланированной.

• Незапланированную работу сложно рассмотреть, но можно визуализировать. Канбан помогает бороться с ней и эффективно прогнозировать ее, делая видимой.

• Планируйте незапланированную работу, выделяя «резервные мощности» для таких ситуаций.

1.4. Конфликтующие приоритеты

Сосредоточенность – умение решать, чем вы не будете заниматься.

Джон Кармак

Представьте успешную игровую компанию и комнату, где работает 41 IT-инженер. Они умны. Увлечены. Им хорошо платят. Все цветет и пахнет. Но если приглядеться, вы заметите множество деталей, которые вряд ли вам понравятся.

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

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

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

Однако многие питают ошибочные представления о том, как выглядит прогресс. Команда разработчиков, которые кажутся сверхзанятыми, но при этом не успевают довести до ума те или иные функции продукта, – тревожный признак. Масса проектов, зависающих на уровне 90 %-ной готовности, не приносят компании никакой пользы. Отделу продаж не удастся продать функции продукта, если клиент не сможет ими воспользоваться; функции доступны, только если их получится применить.

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

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

Все мы сталкивались с подобными ситуациями в самых разных контекстах: групповые проекты в средней школе, когда еще никто не знает, как приоритизировать работу; неоправданные дедлайны, назначенные менеджерами, которые требуют, чтобы все было выполнено «еще вчера»; и/или попытки составить список дел таким образом, чтобы решить несколько задач одновременно, занимаясь всем сразу, а не распределяя по их ценности.

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

Почему конфликтующие приоритеты так опасны

Расхититель по имени «Конфликтующие приоритеты» радуется, когда люди сомневаются или не могут договориться, над чем работать.

Допустим, команда трудилась над отчетом и убила на него целую вечность. Отчет не только занял кучу времени, но был завершен на шесть месяцев позже, чем требовало руководство. Допустим, мы проанализировали рабочую загрузку группы и оказалось, что у нее 13 проектов – больше, чем участников. Более того, встречи по обсуждению приоритетов длятся дольше часа и проходят каждую неделю. Если сократить количество задач до семи, к примеру, будет легче сосредоточиться на процессе, а встречи по поводу определения важности проблем станут короче. Сократив WIP, команда сможет эффективнее приоритизировать работу, потому что меньше задач требуют внимания. Если вы вдруг забыли, что слишком большой объем WIP – глава всех расхитителей времени, то напомню: одна из причин слишком большого WIP – отсутствие грамотной очередности.

Если люди не могут эффективно определить приоритеты, они стараются сделать слишком много сразу и каждая задача отнимает больше времени. То есть избыточный объем WIP растягивает время цикла, следовательно, продукт попадет к клиентам с большой задержкой. Довольные клиенты (внутренние или внешние) поднимают нам настроение и радуют кошелек. Чем дольше время цикла, тем позже вы получите критически важную обратную связь о проделанной работе, что, в свою очередь, создает еще больше трещин и расколов, через которые к вам могут просочиться расхитители времени.

Если все задачи одинаково приоритетны, ни одну нельзя назвать реально важной и каждая требует слишком много времени. Как говорит Росс Гарбер: «Многое может быть важным, но самое значимое – лишь одно»[23]23
  Росс Гарбер, цитата из кн.: Gary Keller, The ONE Thing: The Surprisingly Simple Truth Behind Extraordinary Results (London: John Murray, 2013), 19.


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

Вы поймете, что конфликтующие приоритеты крадут ваше время, если слышите от людей примерно следующее:

• «Когда будет выполнена моя задача?»

• «Моя задача приоритетная!»

• «Если мою задачу не выполнить к такому-то сроку, то…»

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

КЛЮЧЕВЫЕ ВЫВОДЫ

• Есть только одна самая важная задача; сообщите людям, в чем она заключается.

• Конфликтующие приоритеты наблюдаются, когда люди не уверены, что считать наивысшим приоритетом. Это приводит к слишком большому WIP, что, в свою очередь, затягивает время цикла.

• Конфликтующие приоритеты, которые конкурируют за одних и тех же людей и ресурсы, тормозят процесс и увеличивают объем частично выполненной работы.

• То, что нам кажется приоритетом, часто противоречит тому, что считают приоритетом другие.

1.5. Заброшенная работа

Отсрочка не приносит счастья.

Уильям Шекспир, «Двенадцатая ночь»

Когда я работала в Corbis, мы использовали приложение по планированию ресурсов предприятия под названием JD Edwards (JDE). Это была старая, кастомизированная и довольно уязвимая версия. Как только JDE переводили в офлайн, чтобы сделать резервное копирование или восстановить базу данных, это влияло на функции выплаты и получения денег, а обновление от вендора сбивало настройки таблиц базы данных. Так что мы, как ни странно, делали то, что и многие IT-магазины, – ставили кратковременные цели и продолжали пользоваться десятилетней неподдерживаемой версией. Что могло случиться? Неавтоматизированный процесс билда и развертывания JDE регулярно переписывал конфигурационные файлы во время развертывания, из-за чего новые заказы просто исчезали. Все боялись трогать сервер JDE, и в результате его оставили в покое примерно лет на десять, пока не сменили на SAP. В некотором смысле устаревший софт похож на старый автомобиль, которому нужно регулярно менять масло и возить на станцию техобслуживания, чтобы он нормально функционировал. Старый софт сам по себе не проблема. А вот если он без сопровождения, если не стал частью автоматизированного билда, тестирования и развертывания, – вот это проблема.

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

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

Если бы меня попросили определить, какая работа самая заброшенная, я бы назвала ту, что связана с улучшением качества, включая отложенное сопровождение, баги, технический долг и код без прокрытия тестами (унаследованная система, по словам Майкла Фезерса[24]24
  Майкл Фезерс – директор компании R7K Research & Conveyance, автор книги «Эффективная работа с унаследованным кодом» (М.: Вильямс, 2016). Прим. ред.


[Закрыть])[25]25
  Michael Feathers, Working Effectively with Legacy Code (Upper Saddle River, NJ: Prentice Hall, 2004), xvi.


[Закрыть]. Время и расходы часто решают все, когда люди торопятся выпроводить продукт в открытый мир («Обойдемся без тестов. Нам нужно отправить продукт. К этому вернемся позже»). Сегодняшняя корпоративная культура, нацеленная на то, чтобы люди были постоянно «заняты», просто абсурдна. Работа не получает должного внимания, когда сотрудники озабочены массой вопросов. Причем показателем продуктивности служит не сама занятость, а созданная ценность.

Две важные области, где процесс буксует, – это работа, ожидающая обратной связи, и работа, признанная важной, но не срочной. Третий фактор – то, что Дональд Рейнертсен[26]26
  Дональд Рейнертсен – консультант по разработке продуктов, автор многих книг в этой области. Прим. ред.


[Закрыть] называет зомби-проектами[27]27
  Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Redondo Beach: Celeritas, 2009), 152.


[Закрыть]. Это задачи с низкой ценностью, едва живые. Они бродят неприкаянно, ждут внимания и не получают ни капли любви. Они изголодались по деньгам, ресурсам и людям.

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

Некоторым людям нелегко убивать проекты – им жаль потраченного времени и денег. Чем больше мы вкладываем, тем сложнее бросить, даже когда более рациональное решение, продиктованное будущей ценностью, принесет больше пользы. Это называется ошибкой невозвратных затрат. В книге The Principles of Product Development Flow («Правила разработки продукта») Дональд Рейнертсен предлагает учитывать лишь инкрементальные инвестиции, необходимые для завершения проекта, и сравнивать их с экономической выгодой[28]28
  Reinertsen, The Principles of Product Development Flow, 47.


[Закрыть]. Выпалывать задачи с низкой ценностью из рабочего потока разумно в тех ситуациях, когда накапливается избыток дел с высокой ценностью. Иными словами, у вас есть полное право убивать зомби-проекты. Если они действительно нужны, легко восстанут из мертвых. То, что важно больше всего, не должно уступать место тому, что значимо меньше всего.

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

Это редко приносит те результаты, на которые надеется компания, особенно когда проблемы, обнаруженные на финальных этапах незавершенных проектов, отвлекают инженеров от новых дел. Так как к очередным задачам приступают намного быстрее, чем успевают доделать частично выполненные прежние, они накапливаются и отнимают больше времени (опять к нам прокрался расхититель по имени «Слишком большой объем WIP»). Метрики времени потока начинают расти. Это как движение в час пик. Когда на автостраду въезжает больше машин, чем съезжает с нее, время в пути увеличивается. И, как пробка на дороге, колоссальное количество последующих заминок, помех и приостановок может окончательно застопорить работу.

Почему заброшенная работа так опасна

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

Заброшенная работа крадет у вас время, если вы откладываете важные задачи, которые в итоге превращаются в чрезвычайную ситуацию. Это как планировать пригласить свою вторую половинку на ужин в честь годовщины, а потом решить, что в этом году можно обойтись и без праздника, в следующем отметив в двойном объеме. Как вы себе это представляете? Если по этому поводу супруга устроит вам головомойку, отложенная работа будет действовать еще жестче.

Полезно знать, как долго дело остается без внимания, чтобы понять соотношение между старой работой (зомби-проектами) и новыми, конкурирующими проектами. Как и все остальные расхитители времени, заброшенная задача получает полную и безраздельную поддержку со стороны слишком большого WIP.

КЛЮЧЕВЫЕ ВЫВОДЫ

• Если не заняться важной заброшенной работой, она вскоре перерастет в чрезвычайную ситуацию.

• Остерегайтесь невидимого технического долга, который накапливается, когда команды отвлекаются на краткосрочные приоритеты.

• Выявите зомби-проекты. Подумайте, какое влияние они оказывают на завершение по-настоящему ценных задач. Либо уделите им внимание, в котором они нуждаются, либо добейте.