Доминика Деграндис - Визуализируйте работу

В апреле 2006-го в Corbis появился шотландец из Microsoft. Дэвид Андерсон посещал нас ежемесячно и учил применять теорию ограничений (ТО) в обмен на разрешение написать историю аgile-преобразования Corbis. ТО – способ найти самые важные лимитирующие факторы (ограничения), которые препятствуют достижению цели, а затем систематически совершенствовать их, пока они не перестанут быть лимитирующими. Мы воодушевленно читали его книгу Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results («Гибкое управление в разработке программного продукта: как применить теорию ограничений для бизнес-результатов») и планировали использовать разработку на основе функционала (FDD) – тип аgile-разработки с межфункциональными, коллективными и ограниченными во времени методами создания функций. Как пишет Даррен Дэвис в блоге «Тайная история Канбан», методы Дэвида «…исключали из процесса однозначные расчеты и опирались на конкретные данные, чтобы прогнозировать, когда вероятнее всего будет завершена работа над продуктом» [3] Darren Davis, “The Secret History of Kanban by Darren Davis [Guest Post]”, Northwest Cadence , February 19, 2015, http://blog.nwcadence.com/the-secret-history-of-kanban-by-darren-davis/ . . Дэвид провел с нами обзоры операций и объяснил, насколько важно оценивать прогресс (или его отсутствие). Когда я поняла, что именно нужно анализировать, мой мир изменился. Нытье не помогает, а вот оценка cycle time (времени, требующегося для выполнения работы) и представление этих данных руководству очень даже эффективны. Я смогла повлиять на начальство и получить одобрение на наем новых сотрудников для нашей команды.

Иногда очевидное теряется среди давления и нагрузки корпоративного мира. Мы интуитивно знали, что у нас в работе слишком много проектов. Но это было сложно увидеть, пока мы не принялись подсчитывать реальное время, уходящее на выполнение заданий. И тогда стало очевидно, что дела дольше всего находятся на этапе ожидания , чем на этапе выполнения. Мы ждали утверждений. Ждали, когда другие завершат свои части проекта, чтобы мы приступили к своим (или закончили их). Ждали возможности трудиться, ни на что не отвлекаясь, чтобы доделать наконец собственные задачи. Ждали подходящего дня/недели/месяца. И пока мы ждали, начинали новый проект, потому что, как вы понимаете, загрузка ресурсов – основная цель и нужно быть постоянно чем-то занятым.

Как пишет Кейт Мерфи в статье «Нет времени подумать», «одни из основных жалоб современного общества – чрезмерная занятость, повышенные обязательства и перегруженность работой. Спросите людей на любом социальном мероприятии, как у них дела, и ответ будет неизменным: “Я так занят”, “С ума схожу от работы” или “Сил моих уже нет”. Никто уже не говорит “хорошо”» [4] Kate Murphy, “No Time to Think”, The New York Times , July 25, 2014, http://www.nytimes.com/2014/07/27/sunday-review/notime-to-think.html . . Каждый день я вижу подтверждение этому. Когда выдается спокойная минутка для размышлений – допустим, пока ждешь очередной встречи, – звонит телефон. Для амбициозных личностей, которые стремятся постоянно быть на связи, занятость может перерасти в зависимость. Но занятость не приравнивается к росту, или совершенствованию, или ценности. Часто она означает, что вы взяли на себя столько задач, что не можете ни одну из них выполнить качественно. Иногда прогулка в парке или минутка размышления – оптимальный способ жить сегодняшним днем. Какой ужас: инженер сидит без дела целых пятнадцать минут и просто думает?!

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

В сентябре 2008 года, после восьми лет работы в Corbis, меня, как и еще 41 сотрудника, сократили. Я решила попробовать что-то новое и устроилась в AT&T Mobile в команду управления разработкой. Но отказ от бережливой системы Канбан, которую я помогала создавать в Corbis, и возвращение к каскадному подходу (традиционный метод разработки продукта: нельзя приступить к работе, пока не будут выполнены все предыдущие этапы), когда прогнозы строятся на основе отчета по отработанным часам, стали для меня большим шагом назад. В июле 2010-го я уволилась.

В январе 2011-го Дэвид Андерсон предложил мне заняться разработкой и проведением нового курса для компании David J. Anderson & Associates под названием «Канбан для IT-операций». В то время Европа обгоняла США по популярности Канбан, так что в феврале мои исследования начались с Англии, Швеции и Германии. В марте мы провели первый пробный семинар в Бостоне, где я выступила на DevOpsDays Boston 2011 в Центре исследований и разработок Microsoft в Новой Англии.

Изначально я планировала написать рекомендации для участников семинара, чтобы помочь им спроектировать канбан-доски. Но эти рекомендации переросли в настоящее хранилище информации и здорово сэкономили мне время. Я стала записывать не только все, что узнавала о применении бережливого производства, Канбан и потока в собственной работе, но и выборочные формулы, теории и статистические данные экспертов. К примеру, что такое бережливое производство? Я предпочитаю определение Никласа Модига и Пэра Олстрема. В своей фантастической книге This Is Lean: Resolving the Efficiency Paradox («Это бережливое производство: как разрешить парадокс эффективности») они определили бережливое производство как «стратегию эффективности потока с ключевыми принципами “точно в срок” и визуального менеджмента» [5] Niklas Modig and Pär Åhlström, This is Lean: Resolving the Efficiency Paradox (Stockholm: Rheologica Publishing, 2016), Introduction. .

Итак, что же нам известно? Мы знаем, что к производству предъявляются высокие требования относительно бизнес-ценности, чтобы обеспечить конкурентоспособность. Мы в курсе, что многие организации применяют заторможенные и обременительные стратегии развертывания. Мы также понимаем, что способны достичь максимального результата, если четко видим, что получается, а что нет. Это очевидно, но регулярно игнорируется.