Руководство программиста по взлому кода «Вдвое больше работы, вдвое быстрее»

У теоретического менеджмента полно дедушек. Я читал работы Деминга, Голдратта, Оно и Друкера. Я слышал об Акоффе и Джуране. Я наслаждался гуманным и внимательным отношением в каждой книге, которую я читал. Никогда не было так: «Эксплуатировать людей до изнеможения». Питер Друкер в своем «Преподобном Эде Менеджмента» даже указал нам, менеджерам 21-го века, что нам следует делать:

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

Через двадцать лет в 21 веке, насколько мы близки к достижению этой амбициозной цели в мире разработки программного обеспечения? Я вижу, что мы далеки от этого. Давайте посмотрим, где мы находимся, какие у нас есть проблемы и что мы можем с ними сделать.

Изучение широко распространенного подхода к эффективности разработки программного обеспечения

"Искусство делать в два раза больше работы за половину времени" – это подзаголовок "Scrum". книга Джеффа Сазерленда, соавтора этого фреймворка. Мне нравится этот подзаголовок, так как он наглядно показывает, насколько эффективнее мы можем стать в наших усилиях по программированию. Однако не все так безоблачно. Первая проблема, с которой мы здесь сталкиваемся, заключается в том, что нам сложно понять, что такое эффективность в нашей работе. Следующая сложная проблема заключается в том, чтобы понять, станем ли мы со временем более эффективными.

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

Вернемся к нашему вопросу. Практики Scrum предлагают стори-поинты в качестве измерения задачи. Существует определение с веб-сайта scrum.org:< /p><цитата>

Story Point – это относительная единица измерения, которая определяется и используется отдельными Scrum-командами для предоставления относительной оценки усилий по выполнению требований.

Story Point — это величина сложности, связанная с эталонной задачей. Мы с вами чувствуем, сколько сил нам потребовалось для реализации этой не очень сложной задачи. Если я скажу вам, что новая работа будет стоить три очка истории, я скажу, что она будет в три раза сложнее, чем предыдущая. Это мое предположение, и кто знает, насколько это будет сложно.

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

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

Определение объекта измерения

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

На моем нынешнем месте мы используем три разных уровня:

User-valuable feature:
 ⎿ Its slice for the engineering team's convenience:
   ⎿ The specific task inside a slice (e.g., back-end task).

Нам нужно, чтобы корректировка имела следующие характеристики:

1. Имеет время начала и время завершения;
2. Происходит регулярно.

Итак, здесь мы определяем "эту большую часть работы". Назовем это действием в последующей части статьи. Не все действия одинаковы. В приведенном выше примере я продемонстрировал три типа.

Нам нужно, чтобы действия происходили регулярно.

Это требование исходит из того факта, что вы не можете быть максимально эффективными с самого начала, но со временем можете стать более эффективными. Это не недостаток описанного подхода. Так работает Scrum, так работает Toyota Production System, так работает наука. Нам нужна повторяемость, чтобы обнаруживать текущее состояние и постоянно улучшать его.

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

Подводя итог, мы имеем действие как сущность для измерения.

Как измерить действие?

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

• Сколько времени ушло на завершение эпика?
• От начала до завершения нам потребовалось 39 дней.

Замечательно.

Есть ли что-то еще, что мы получаем?

Второе требование к нашему действию, регулярность, дает нам столько, что в это трудно поверить. Прежде всего, мы получаем поток действий своего рода. Вот определение потока из книги Даниэля Ваканти Actionable Agile Metrics for Predictability": р><цитата>

Проще говоря, поток – это движение и доставка ценности для клиента в рамках процесса.

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

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

Я могу вас заинтриговать, если вы думаете, что это все, что у нас есть. Мы в самом начале. Еще одно сокровище, которое дает нам поток, — это след, который он оставляет с течением времени. Эта трассировка позволяет нам лучше понять систему. Мы можем зафиксировать это, используя несколько диаграмм. Одним из них является диаграмма рассеяния времени цикла.

Восторг заключается в том, что он показывает, "как мы здесь работаем". Это не требует ничего от вашего процесса, никакой конкретной методологии. Вы хотите зафиксировать процесс чистки зубов, используя диаграмму рассеивания времени цикла? Просто сделай это. Хотите ли вы того же для домов, построенных в вашем районе? Абсолютно хорошо. Хотите отслеживать жизненный цикл разработки, включая эксперименты A/B, проводимые после разработки новых функций? Пожалуйста, начните и сделайте.

На картинке вы также можете увидеть линии процентилей, подписанные 50%, 70%, 85% и 95% справа. Что они имеют в виду? С левой стороны – дни. Вы можете прочитать 85% и 16 дней следующим образом:

Для 85 % элементов, поступивших в нашу систему за рассматриваемый период, уход из нее занял 16 дней или меньше.

Я уже второй раз использую слово "система" в этом разделе. Что это означает? Давайте определим это следующим образом для этой истории:

Система — это нечто, выполняющее определенные действия.

Одним из таких действий в приведенном выше примере системы строительства домов является строительство дома. Создание одного километра дороги здесь не считается действием. Это другой вид действия и другая система. Однако конкретного разделения нет, но мы хотим, чтобы наши дома были похожи, как и чистка зубов, и разработка программного обеспечения с A/B-тестами. Для чего-то достаточно необычного мы можем придумать другую систему.

Еще одно важное преимущество

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

Есть ли в этой логике что-то, что ведет нас в ловушку? Давайте посмотрим поближе.

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

Давайте взглянем на следующую мудрость программирования Дональда Кнута (или Тони Хоара):< /p><цитата>

Преждевременная оптимизация — корень всех зол.

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

Заставьте это работать, сделайте это правильно, сделайте это быстро.

Пример с установкой библиотек показывает, что поговорка имеет отношение к коду, а также к команде разработчиков! Какую тайну мы встречаем здесь! Это не тайна, а атрибут системы. Есть по крайней мере две причины, по которым мы не должны сразу приступать к усовершенствованиям с первой попытки.

Статистическая причина не сразу переходить к усовершенствованию

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

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

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

Теория ограничений: причина не сразу приступать к усовершенствованию

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

• 6 подвалов,
• 24 набора стен,
• 52 крыши.

Сколько домов мы можем построить в год? Вы можете ответить шесть, но я предлагаю говорить не больше шести. Строительный процесс у нас последовательный: фундамент → стены → крыша. Завершение последнего, шестого дома может отстать к концу года.

Если мы увеличим количество возводимых стен или возводимых крыш, изменит ли это возможности всей нашей компании? Будем производить больше, чем упомянутое «не более шести»? Нет, подвал по-прежнему ограничивает нас.

Цифры, приведенные выше, основаны на опыте этой поверхностной компании. У нас нет такого опыта после реализации первой пользовательской истории. Нам еще предстоит определить ограничение нашей системы построения пользовательских историй, поскольку мы не знаем, как долго длится каждое поддействие. Считайте, что обеспечение качества является частью нашего процесса разработки пользовательских историй. Тестирование пользовательской истории длится четыре часа. В целом разработка пользовательской истории длится пять рабочих дней. Допустим, в году 250 рабочих дней. Вы ожидаете, что в конце у вас будет 50 пользовательских историй или 730? Как и с домами и подвалами, максимум 50 в год. Нам нужно собрать статистику, чтобы понять форму нашего действия и его наименее продуктивную часть.

Сколько полных действий достаточно для начала улучшений?

Чтобы быть полностью уверенным, я предлагаю иметь ∞ количество завершенных действий на этом этапе. Имея это точное число, вы можете быть на 100% уверены, что улучшать в первую очередь.🥁

Для тех, кто не знаком с миром чистой математики, давайте рассмотрим следующие мысли. Вот ссылка из книги "Actionable Agile Metrics for Predictability" со ссылкой на "Как измерить что угодно":

Например, Дуглас Хаббард (чья книга «Как измерять что угодно» указана в библиографии) советует своим клиентам свое «Правило пяти»: Правило пяти — есть 93,75% вероятность того, что медиана совокупности находится между наименьшим и наибольшим значениями в любой случайной выборке из пяти человек из этой совокупности.

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

:::

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

С чего начать улучшение?

Если мы предпримем элементарное действие, например, включим телевизор, нажав кнопку на нем, мы сможем представить его как единое целое. Чтобы сократить количество движений и общее время, купите себе кликер и держите его в одном месте возле дивана. В этом примере первое действие может занять около 20 секунд, а второе... одну секунду. Мои поздравления! Вы сократили 95% ранее необходимого времени и по-прежнему получаете то же значение. Какое фантастическое устранение отходов!

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

1. Анализ,
2. Разработка,
3. Тестирование,
4. Готово.

С чего начать?

В бережливом производстве процесс создания или действие, как оно названо в этой статье, состоит из поддействий трех видов:

• Действия с добавленной стоимостью;
• Необходимые действия, не добавляющие ценности;
• Отходы.

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

В бережливом производстве потери (или муда) известны и определены создателем производственной системы Toyota Тайити Оно. По крайней мере, они определены для компании Toyota, производителя автомобилей. В других отраслях есть свои варианты. Вот наш, созданный Мэри и Томом Поппендикс в книге "Lean Software Development":

1. Частично выполненная работа,
2. Дополнительные процессы,
3. Дополнительные функции,
4. Переключение между задачами,
5. Ожидание
6. Движение,
7. Дефекты.

Или эти? Из книги "Внедрение бережливой разработки ПО" тех же авторов:

1. Частично выполненная работа,
2. Дополнительные функции,
3. Повторное обучение,
4. Ненужные передачи,
5. Переключение между задачами,
6. Задержки,
7. Дефекты.

По крайней мере, инженеры-программисты теперь могут двигаться!😅

Как эти столпы могли так сильно измениться всего за несколько лет в нашей отрасли? Я вижу ответ в невозможности иметь достаточный список отходов на все времена. Даже Toyota в какой-то момент придумала восьмую трату.

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

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

Это цитата из книги «Эффект маховика ценности" Дэвида Андерсона и Марка Макканна & Майкл О’Райли. Ух ты, какая поездка!

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

Пересмотр рабочего процесса разработки пользовательских историй

Позвольте мне напомнить вам о рабочем процессе, который у нас был:

1. Анализ,
2. Разработка,
3. Тестирование,
4. Готово.

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

1. Анализ активен,
2. Анализ завершен,
3. Разработка активна,
4. Разработка завершена,
5. Тестирование,
6. Готово.

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

Время цикла системы – 9,37 дня. Это утверждение означает, что задача достигает стадии Активен анализ, проходит через все последующие этапы и переходит из состояния Тестирование в состояние Готово, а затем в среднем этот путь занимает 9,37 дня. Этапы со словом «Активен» в названии, похоже, приносят пользу результату, так же как и Тестирование. Стадии, оканчивающиеся на «Готово», — это очереди, ожидание и ничего полезного. Если мы отметим их соответствующим образом с помощью диаграммы эффективности потока, мы увидим, что в среднем только 40 % времени, потраченного на одну пользовательскую историю, являются ценными.

В эту диаграмму мы также включаем отслеживаемое заблокированное время и странные задачи, которые все время находились на этапах «Готово». Если их исключить, эффективность потока для этого демонстрационного примера будет около 50%.

Решение проблемы пустой траты времени

Поскольку у нас слишком мало информации о демонстрационном наборе данных, конкретных рекомендаций, например: "Дайте команде E более качественные компьютеры", не будет. Впрочем, в вашем случае хватило бы мыслей, чтобы навеять собственные. Наименее продуктивной частью нашего процесса является этап Готовый анализ. Мы даже не можем назвать это так, поскольку оно описывает ожидание. Тем не менее, это занимает почти 29% каждой задачи. В чем тут может быть причина?

Фаза активной разработки не кажется медленной и требует меньше времени, чем активная часть анализа. Глядя на средний WIP, мы выделим проблему: аналитический отдел может одновременно обрабатывать больше пользовательских историй.

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

Прежде чем предлагать решение, проведите анализ первопричин: используйте пять почему, fishbone или что-то еще.

Проверка успешности примененного изменения

Допустим, мы решили проблему из предыдущего раздела. Как мы можем быть уверены, что предложенное изменение сработало? Нам нужно снова собрать данные. Вы помните Правило пяти из приведенного выше? Мы можем использовать его и здесь. Теперь наша система настроена. Измерим еще раз.

В своей работе я использую два инструмента для измерения результатов эксперимента:

1. Сводная блок-схема,
2. Линия тренда на диаграмме рассеяния времени цикла.

Вы видите голубую область Готового анализа? Ожидайте, что со временем он станет как минимум тоньше, а в лучшем случае исчезнет.

Посмотрите на зеленую пунктирную линию на этой уже знакомой диаграмме. Он показывает тенденцию времени цикла 85% за последние N дней. Я использую 30 вместо N, так как он достаточно стабилен, чтобы продемонстрировать изменения. Если найденное решение устраняет достаточно глубокую первопричину, ожидайте, что эта линия сократится примерно на 30 % до 11 дней.

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

Дальнейшие шаги

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

Тем не менее, я не уверен, что здесь это необходимо. Представьте себе, что вы используете программное обеспечение, которое получает новые функции каждые два дня. Рынок может быть к этому не готов. Рынок становится ограничением для нашей системы. Это открытие не означает, что мы всегда ограничены в своих улучшениях. Обычно у нас есть несколько систем разработки, создающих ценность, и наши функции занимают больше девяти дней. По моему опыту, взгляд с высоты птичьего полета на товары, срок действия которых составляет шесть месяцев, выявил только 30% времени добавления ценности. Более подробная картина задач внутри 30% снова продемонстрировала точные 30% добавленного времени. Выяснилось, что за все 180 дней было только 16 дней деятельности с добавленной стоимостью. Виден потенциал 11-кратного улучшения.

Кратко о подходе

:::подсказка

1. Откройте для себя свою систему,
2. Обнаружить его ограничение,
3. Устраняйте отходы, пока они не перестанут быть ограничением,
4. Повторить.

:::

Действенные вопросы

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

1. Не лишит ли это удовольствия от программирования?
2. Разработка программного обеспечения настолько непредсказуема и креативна. О какой работе над его эффективностью можно говорить?!

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

Зачем вам раньше понадобились онлайн-инструменты для программирования мобов? Стать быстрее? Но что тогда было быстрее? Зачем вам нужен этап явного проектирования программного обеспечения? Ага! Наша команда разработчиков обременена ошибками, поэтому пользовательские истории ждут до 30% своего жизненного цикла, пока разработчики не исправят ошибки. Почему бы нам не предотвратить их?

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

Да, создание программного обеспечения действительно непредсказуемо и не является рутиной. Однако так ли это бесконечно непредсказуемо? Будет ли года достаточно, чтобы выполнить любую из задач, которые вы видите в своем бэклоге? А десять лет? Неужели природа их вариаций настолько неуловима, что мы ничего не можем с этим поделать? Существование диаграммы рассеяния времени цикла показывает нам, что существует предел вариативности разработки программного обеспечения. Вы можете указать, что некоторые задачи требуют быстрого исправления текстовой константы, а другие требуют нескольких дней исследования. Я бы согласился с этим, но я также хотел бы спросить вас: «Является ли существование этих задач результатом неизбежной природы программного обеспечения или это результат используемой вами архитектуры программного обеспечения? Разве большой ком грязи в процессах причина такого бардака?"

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

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

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

Как избегать очевидных и неправильных шагов

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

Открытие места для начала

Более века назад Фредерик Тейлор начал свою работу над тем, что сейчас известно как научный менеджмент. Он смотрел на своих коллег и искал для них более эффективные методы выполнения своей работы:

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

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

Вы помните мой пример с товарами сроком на шесть месяцев или 180 дней? Если я успешно устраню трату времени на внутренние предметы, где работают инженеры, я сэкономлю 38 дней и у меня останется 142 дня на большой предмет. Если я сделаю то же самое для внешней части, где работает вся команда, я сэкономлю 126 дней и получу 54 дня для того же большого элемента. Мучить разработчиков сверхурочными работами и кроватями в офисе нет смысла, если вы хотите выиграть по-крупному. Взгляните на процесс создания ценности с высоты птичьего полета и углубитесь в него только после того, как вы выйдете за пределы возможностей для улучшения на этом уровне.