Соглашение о моделировании состоит из четырех частей - метамодель, модель атрибутов объектов и отношений, паттерны проектирования, визуальный стиль оформления. В этом тексте я разбираю метамодель.
Программа - совокупность связанных проектов со своими целевыми системами, у которых есть общие практики жизненных циклов. Эти практики реализуются разделяемыми, в общем пользовании, орг.способностями программы. За счет разделения орг.способностей между проектами программа получает экономические эффекты.
Зачем нужно системное мышление?
Единственный способ изменить будущее - сделать что-то сейчас. Иногда надо сделать что-то настолько большое, что для этого надо звать очень много людей разных специальностей, каждый из которых будет заниматься своей небольшой частью. И тогда стоит задача координации текущих действий и построения общей логики объединения результатов работ. Системное мышление на базе системной инженерии (т.н. системноинженерное мышление) предлагает отработанные на тысячах крупных проектов технологии такой координации, комплексирования и проверки результатов работ. Весь системный подход можно выразить компактной схемой:
- модели действий и результатов действий (что делаем?) - модели знаний и технологий (как и почему действия приведут к результату?) - модели целеполагания (какой измененный кусок мира мы хотим видеть и почему мы его хотим изменить?) - модели измененного куска мира (что мы изменяем в мире, какие новые объекты появляются, что они делают и как они взаимодействуют с миром?) - модели организации (у кого какие ресурсы, полномочия, обязательства?)
Эти блоки соединены цепочками реализации:
Пакет работ-Практика-Дисциплина-Цель
Координация через практику и дисциплину практики, координация на основе знаний. Здесь находятся практики индуктивного вывода и прогнозирования. Условно, если мы будем соблюдать эту практику, то достигнем цели. Условно первый и второй квадранты Кеневин.
Координация через значимые факты и дисциплину. Подведение фактов под теорию. Здесь находятся практики абдукции, условно второй и третий квадранты Кеневин.
Координация почти однозначной причинно-следственной связи. “Если у меня будет дом, то моя жизнь улучшится”, “если у меня будет машина, я буду быстрее добираться куда мне надо”. При этом система может быть частью орг. звена, например, машина является частью домохозяйства, производственная линия является частью цеха. Первый квадрант Кеневин.
Координация факт-ориентированной причинно-следственной связи изменения мира. То же, что и предыдущее, но причинно-следственная связь задается дисциплиной практики. Например, “правильное питание и комплекс упражнений в 80% случаев приводят к заметному росту мышечной массы и увеличению силы”. Второй квадрант Кеневин.
Модели действий и результатов действий, уровень абстракции М0-М1
Пакет работ (work package). 4Д-индивид, который состоит из орг. звена (business actor), инструментов, которое использует это орг. звено, в момент применения практики (practice) в фиксированном контексте применения практики. Особенностью пакета работ является его предсказуемость - постоянство состава орг. звена, постоянство инструментов, соблюдение дисциплины (discipline) практики, постоянство контекста. Здесь же допускается наибольшее количество ошибок, т.к. в проектном управлении вместо этих принципов часто используют эмпирики типа 8/80. На пакетах работ основаны оценки работ, по которым орг. звенья дают обязательства и координируют работы.
Предмет поставки (deliverable). 4Д-индивид либо описание целевой, обеспечивающей, использующей системы либо системы в операционном окружении. Для использующей системы и систем в операционном окружении только описание, менять их полномочий у команды программы нет. Предмет поставки определен методом работ. Методы работ определяются в зависимости от рисков отклонений производимого элемента системы (equipment) от спецификаций. Более подробно смотри доклад Филиппа Дельгядо
Пакет работ исполняется орг. звеном. У любого пакета работ есть ответственное за его выполнение орг. звено (accountable).
Пакет работ как самый конкретный объект реализует практику как менее конкретный объект. Пакет работ исполняется в соответствии с практикой, следует ее дисциплине и использует технологии практики.
Пакет работ имеет отношение доступа к предмету поставки, “пишет” в предмет поставки. Это означает, что в ходе пакета работ создается, изменяется либо уничтожается какой-то системный элемент либо описание.
Предмет поставки реализует физический объект практики. Физический объект практики определен в рамках онтики практики как класс, а при исполнении пакета работ люди оперируют индивидами. Отношение реализации показывает, что индивид предмета поставки и есть физический объект, определенный практикой. Если вы кидаете конкретную бутылку и пытаетесь рассчитать ее траекторию с помощью ньютоновской физики, вы должны отождествить конкретную бутылку с понятием “физическое тело” из ньютоновской механики, и после этого вы можете применить к ней три закона механики Ньютона и рассчитать траекторию.
Предмет поставки реализует рабочий продукт, артефакт практики. Если практика прикладная, например, управление проектами, то роспись денежных средств на работы, которую вы сделали с бригадиром на стройке дома отождествляется для вас с рабочим продуктом “бюджет проекта”. И тогда вы можете применять к этой росписи практики планирования, прогнозирования, контроля.
Предмет поставки реализует системный элемент. Означает, что в результате выполнения пакета работ должен появиться системный элемент.
На практике в проектном управлении используется три типа разбиения работ, см. “Продукт-ориентированные ИСР. Почему они лучше других?” Из них два основаны на разбиении предметов поставки, один на разбиении пакетов работ. Эти типы ИСР/WBS равноправно могут использоваться для основанной на фактах координации рабочих групп. Проблемы такой координации описаны в “Как управление по контрольным точкам влияет на восприятие успешности проекта”.
Модели знаний и технологий
Практика (practice). Класс действий, при которых стейкхолдер видит определенные практикой объекты и оперируют с ними в соответствии с дисциплиной практики. При этом появляются рабочие продукты практики.
Физический объект (physical object). Часть мира, 4Д-индивид, который выделяет стейкхолдер и работает с ним по определенным дисциплиной практики правилам, паттернам внимания и действий. Например, конкретный автомобиль.
Информационный объект (information object). Концепт, понятие. Часть нейронной сетки стейкхолдера, которая моделирует поведение физического объекта. Например, “личный транспорт”, простое понятие в моей голове, которое представляет сложную систему автомобиля в составе еще более сложной системы городского дорожного движения. Но я могу использовать простой концепт личного транспорта, чтобы оценить время, за которое я доберусь в место назначения. При этом я отвязываюсь от того, на каком автомобиле я поеду, если, допустим, я поеду на такси.
Дисциплина (discipline). Связанный набор микротеорий и понятий, который позволяет предсказывать состояние мира с какой-то достаточной для практических целей точностью и достоверностью.
Отношения:
Стейкхолдер назначается на практику. Т.е., стейкхолдер с инструментами в момент исполнения практики и практика есть один и тот же 4Д-индивид. Мы различаем практику сантехнического ремонта, сантехника, который ставит ванную, или пакет работ по установке ванной как разные объекты 1-го класса, но при этом должны понимать, что это один и тот же 4Д-индивид. Подробнее можно почитать в http://sdu2020.blogspot.com/2018/06/4_10.html (Перевод Roles: A Four-Dimensional Analysis by Matthew West, 2008).
Практика имеет отношения доступа к объектам и рабочим продуктам. Смысл в том, что при организации работ мы отслеживаем не людей, а рабочие продукты, которые выражают альфы, alpha, информационные объекты, либо физические объекты. Именно они являются единицами логистики работ. Стейкхолдеры выделяют объекты на фоне остального мира и что-то с ними делают.
Практика [более конкретная] реализует дисциплину [более абстрактная]. Дисциплина позволяет переносить знания между разными контекстами. Практика всегда привязана к конкретному контексту, и часто привязана к исполнителям. Например, финансовый учет или управление проектами в конкретной компании учитывает конкретные обстоятельства, цели и участников практики. Но если руководитель проекта знает дисциплину проектного управления, то легко сориентируется в деталях реализации, т.к. привяжет информационные объект практики к конкретным рабочим продуктам и будет понимать, что ними делать.
Дисциплина [более конкретная] реализует цель [более абстрактная]. Цель находится в возможном мире будущего, дисциплина существует прямо сейчас как разделяемое знание стейкхолдеров. И то и то представлено нейронными сетками стейкхолдеров, но дисциплина может лежать в основе действий (discipline is actionable). Эта связь подразумевает, что следование дисциплине приближает нас к цели.
Модели целеполагания
Интерес (concern). В полном соответствии с онтикой онтологизации.
Оценка интереса (assessment). В полном соответствии с онтикой онтологизации.
Цель (goal). Желаемое состояние мира, 4Д-индивид либо 3Д-индивид, событие, в возможном мире.
Требование (requirement). Факт, правдивость которого мы требуем для цели. Цель описана в требованиях. Требования исполнены, т.е., факты правдивы, означает, что цель достигнута. Требования, как и другие факты, имеют смысл только для определенных стейкхолдеров. Требования как факты проверяются на истинность в заранее определенных 4Д-местах мира, которые называются интерфейсами. Проверка требований происходит в соответствии с дисциплиной. Например, есть USB-интерфейс как заранее заданная часть мира, в которой мы проверяем выполнение “мышкой” требований к ней. При этом в месте подключения “мышки” есть несколько интерфейсов - сигнальный (протокол USB), тепловой (дисциплина теплотехники), электрический (дисциплина электротехники), химический (дисциплина химии) и другие. В каждой из этих дисциплин есть свои объекты, для каждого объекта можно указать факт и установить для этого факта модальность долженствования, тогда это станет требованием. Это первое ключевое отличие требования от архитектуры - исполнение требования проверяется в строго заданных частях мира, на интерфейсах. Второе отличие требований от архитектуры - это то, что требование выражается как факт в объектах дисциплины практики, в то время как архитектура - это факт, выраженный в предметной области целевой системы. Сравните, “Низкоплан нормальной аэродинамической схемы, со стреловидным крылом и однокилевым оперением. Два турбовентиляторных двигателя.” (описание архитектуры в фактах предметной области самолета) и “Максимальное количество пассажиров (в одноклассовой конфигурации): от 250 до 330, экономичность выше аналогов, багажное отделение на 45% больше, чем в Боинг 767, салон на 40 см шире”. Архитектура - это, как и требования, факты, разделяемые командой. Но это факты, учитывающие и проект и компетенции команды, в то время как требования относятся только к системе.
Модели измененного куска мира и модели организации
Все в соответствии с онтикой онтологизации и соглашением о моделировании.
Интерфейсы - части мира, в которых доказывается выполнение требований.
Архитектура предприятия — набор компактных представлений организации, каждое из которых содержит минимум элементов. Этот набор представлен набором моделей ArchiMate: - бизнес контекст с панелью показателей предприятия, - операционный контекст с панелью показателей подразделения, - концепция автоматизации деятельности с панелью отчетности, - модели жизненного цикла продукции и сервисов, - модели оргструктур.
Этот набор представлений создается для каждого имеющего ценность сочетания заинтересованных сторон, целей, ситуаций.
Если вы замечаете, что:
Принятие решений, особенно коллективных, затягивается Решения оказываются недостаточно детализированными для непосредственного исполнения Информация о том, как работает предприятие, разрознена и неполна для принятия решений ... то практика архитектуры предприятия — для вас.
Практика архитектуры предприятия позволяет руководству компании делать ключевые стратегические выборы в 3-5 раз быстрее, если сравнивать со скоростью принятия решений с использованием распространенных сейчас практик управления. При этом качество принимаемых решений не снижается.
Как практика архитектуры предприятия справляется с проблемами:
Модель архитектуры предприятия объединяет точки зрения различных специалистов в одном месте, и вы можете разносторонне обсуждать различные аспекты решений, меняя темы прямо в ходе встречи. Это позволяет сократить сроки принятия решений. Неочевидный плюс: сами решения после этого оказываются достаточно детальными и проработаными, так что людям проще их исполнить, чем объяснить, почему их исполнить не получится. Модель архитектуры предприятия позволяет быстро перестраивать бизнес в условиях неопределенности, т.к. в ней отражены связи между критическими элементами организации. За счет сквозных связей между процессами, людьми, ИТ-системами и данными позволит менеджеру быстро найти места, которые могут заблокировать орг. изменение, и подготовить план реагирования. Бизнес-аудиты и проверки комплаенса проводить будет проще: в организации всегда будут существовать множество различных моделей - для операционного учета, финансовые, ИТ-инфраструктуры и многие другие. Модель архитектуры предприятия позволяет объединять все эти разношерстные представления в единую связанную структуру. Пример: https://blog.leanix.net/en/gdpr-eu-compliance
Как происходит создание модели предприятия?
Технологии для внедрения - структурированные интервью и рабочие встречи для сбора знаний. Мы проведем семантический анализ переписки и корпоративных баз данных, чтобы выявить ключевые понятия, с которыми работают сотрудники организации. Для архитектурного проектирования мы используем ArchiMate с соглашением о моделировании SysArchi. В ArchiMate мы картируем ключевые практики и ИТ-решения, указываем связи между процессами, людьми, данными и ИТ-системами.
План внедрения на первые 3 недели:
1. Определить цели на первые 3 недели работы и критерии успеха. 2. Знакомство команды внедрения и команды заказчика. 3. Запуск моделирования архитектуры предприятия на стратегическом уровне, заполнение модели стратегическими вводными и планами. 4. Каскадирование стратегии и многоуровневое и межфункциональное планирование первого шага реализации стратегии. 5. Ежедневные планерки у генерального директора по ходу планирования стратегии. 6. Запуск реализации стратегии и выявление корпоративного словаря и архитектуры предприятия с помощью анализа моделей жизненного цикла продуктов и сервисов 7. Связывание модели архитектуры предприятия с планами реализации стратегических проектов, корректировка хода проекта
Риски внедрения
Ключевой риск - высокая когнитивная сложность создаваемых моделей. Руководство не захочет разбираться с семантикой моделей и откажется от внедрения со словами “слишком сложно и медленно”. Поэтому начальный набор моделей архитектуры предприятия в ArchiMate создают консультанты. Они учат заказчика пользоваться этими моделями при принятии решений. После начального периода обучениязаказчик может использовать модели архитектуры предприятия для того, чтобы принимать стратегические решения. Затем консультанты обучают специалистов заказчика улучшать существующие модели и создавать новые.
Модели архитектуры предприятия в ArchiMate преобразуются в структурированный текст на естественном языке, текстовую документацию. Так заказчик постепенно осваивает новую практику целенаправленного улучшения архитектуры предприятия.
1. Невозможность правильно посчитать экономику 2. Неспособность видеть очереди 3. Поклонение эффективности 4. Неприятие вариативности 5. Поклонение соответствию 6. Узаконивание крупных партий 7. Недоиспользование управленческого ритма 8. Управление сроками, а не очередями 9. Отсутствие ограничений на незавершенную работу 10. Отсутствие гибкости 11. Управление потоком на неэкономической основе 12. Централизованный контроль Только 15% разработчиков продуктов знают стоимость задержки своих проектов. Чтобы делать экономически обоснованные выборы, нужно понимать связь между прокси-переменными и прибылью на жизненном цикле.
Возможные решения этих проблем:
1. Экономика 2. Очереди 3. Вариативность 4. Размер партии 5. Ограничения на незавершенную работу 6. Управленческие ритмы, синхронность и контроль потока 7. Быстрая обратная связь 8. Децентрализованный контроль
Источники идей:
- Бережливое производство - Экономика - Теория массового обслуживания - Статистика - Интернет - Операционные системы - Теория автоматического управления - Маневренная война
175 принципов, быстрая реализация которых дает 5-10 кратные улучшения в отдельных частях процесса разработки.
Экономические принципы
Вы можете не замечать экономику, но не избежите ее влияния. Единственная цель изменения процесса разработки - увеличить прибыль. Люди в одном проекте оценивают стоимость его задержки от 1 до 50 единиц, почти два порядка разницы.
E1: Принцип количественной экономической оценки всего проекта: выбирайте действия на основе их общего экономического эффекта.
Сколько стоит устранить все дефекты в лаборатории и только потом выпустить документацию и сколько стоит выпустить документацию сейчас и быстро найти все ошибки в документации прямо на производстве? Нужно считать деньги, а не пытаться найти универсальный философский ответ на эти вопросы.
E2: Принцип взаимосвязанных переменных: нельзя просто изменить одну вещь.
Все взаимосвязано, поэтому изменения различных переменных надо отражать по одной шкале. Это деньги (хотя главное время, но про это позже).
E3: Принцип количественной оценки стоимости задержки (Cost of Delay): если вы можете перевести в цифры только одну переменную, считайте стоимость задержки.
Когда вы добавляете буфер проекта, сколько он стоит? Экономика проекта почти полностью определяется стоимостью очередей. Стоимость задержки можно считать не только для окончания проекта, но и для других вех проекта.
E4: Принцип экономической добавленной пользы (Value-Added): стоимость, добавленная действием, равна разнице в экономической пользе рабочего продукта до и после действия.
Нельзя просто брать концепцию добавленной пользы из бережливого производства. Клиент не является единственным стейкхолдером, который определяет добавленную пользу. Пример клинических испытаний фармацевтической компании как покупка информации о потенциальной успешности новой молекулы. Или решение о том, как должен работать отдел проектирования - с 80% загрузкой и очередью 2 недели или 90% загрузкой и очередью 4 недели? Ответить можно только если сравнивать прибыль на жизненном цикле.
E5: Принцип бездействия: следите за рабочими продуктами, а не за работниками.
В разработке основные потери сосредоточены в очередях рабочих продуктов.
E6: Принцип U-кривой: важные выборы скорее всего оптимальны в некотором достаточно широком диапазоне.
10% ошибка в определении оптимального размера партии приводит всего к 2-3% разницы стоимости.
E7: Принцип несовершенства: даже несовершенные ответы улучшают принятие решений.
Главное - найти ключевые рычаги влияния на прибыль, а не посчитать с точностью до копейки.
E8: Принцип маленьких решений: влияйте на множество маленьких решений.
Не надо пытаться правильно принимать небольшое количество ключевых решений. Сделайте децентрализацию и принимайте кучу маленьких правильных решений. Темная сторона принципа Паретто - возможности 80% случаев вообще не используются. Пример завода с очередью 100 дней и аналогичного бережливого производства с 2 днями. 98 дней приходят не из 3 месячных очередей, они приходят из 98 8-ми часовых задержек.
E9: Принцип постоянных экономически обоснованных выборов (Economic Trade-offs): экономические выборы нужно делать постоянно.
Решения принимаются не в гейтах и контрольных точках, они должны приниматься постоянно на основе экономики. В этом отличие от производства, в котором мир предсказуем и поэтому можно сделать хорошие планы, а любое отклонение от плана будет идти по не оптимальному маршруту. В разработке мы получаем сигналы от рынка и процесса проектирования, их глупо игнорировать. Например, в плане мы считали, что функционал программы будут использовать 50% потребителей, а его разработка займет 2 недели. В ходе работы выяснилось, что это 1% и 2 месяца, экономика изменилась в 200 раз, план стал не адекватен реальности.
E10: Первый принцип ускользающих возможностей: большинство экономических выборов приносят пользу только если их делать быстро.
Мы должны быстро измерять пользу принимаемых решений и сокращать срок принятия решений. Поэтому надо децентрализовать принятие решений.
E11: Принцип разукрупнения решений: внутри каждого плохого выбора есть хороший выбор.
Крупные решения можно разбить на мелкие, у каждого из которых будет своя экономика. Например, одна компания хотела отдать на субподряд критическую разработку, т.к. у нее не было ресурсов для ее проектирования. Внутренняя разработка была плохим выбором. Но и отдавать критическую разработку на сторону тоже было плохим решением. Но можно было пойти по среднему пути. Отдать разработку на сторону, но выделить одного инженера досконально отслеживать ее ход, чтобы в нужный момент забрать разработку внутрь. Поэтому разбивайте свой крупный выбор на мелкие и считайте экономику каждого мелкого выбора отдельно.
E12: Принцип раннего сбора урожая: создайте систему сбора ранних дешевых возможностей.
Одна организация создала процесс покупки времени цикла. У каждого инженера есть возможность сократить расписание на 4 недели за 500 долларов/неделю. У менеджеров этот лимит выше.
Когда инженер выбрал лимит, его решения проверяются, и если все в порядке, то ему даются еще 4 недели. Такая система позволяет дешево покупать время на критическом пути.
E13: Первый принцип принятия решений: создайте правила принятия решений, чтобы распределить принятие решений.
Если большинство (80% Паретто) выгодных решений находятся на нижних уровнях организации, то нам надо дать полномочия по принятию таких решений вниз. Чтобы это сделать, надо создать правила принятия решений. Пример Боинга 777, когда инженерам разрешили увеличивать стоимость узла на 600 долларов, если они могут снизить вес узла на 1 кг. Так 5,000 инженеров Боинга стали принимать хорошие решения. Их менеджеры проверяли принятые решения и если что могли их отменить.
E14: Первый принцип рынка: убедитесь, что лицо, принимающее решение, чувствует выгоды и цену решения.
Сейчас большинство разработчиков изолированы от цены принимаемых решений. Например, приоритетные запросы руководителей стоят им ровно столько же, сколько обычные. В результате громкий голос становится полезным преимуществом, а если бы приоритет был гораздо дороже, как это и бывает в реальной жизни, то крикуны бы еще подумали, стоит ли лезть вперед. Современные организации похожи на плановые экономики 20-го века, ресурсы распределяются бесконечно мудрым центром. В теории такой центр знает все обстоятельства каждого выбора. В результате интриги, лоббирование и политика вместо нормальных экономически обоснованных нужд. Например, одна организация за премиальный быстрый сервис требует 125% обычной цены. И это заставляет менеджеров проекта включать голову, когда они запрашивают приоритетное обслуживание.
E15: Первый принцип оптимального времени для принятия решения: у каждого решения есть свое оптимальное время принятия.
Принимать решения слишком рано и слишком поздно плохо. Например, когда вы покупаете авиабилеты сильно заранее, вы пропускаете скидку на них. Если покупаете билеты в последний момент, вы купите их за любые деньги, потому что вам надо улететь любой ценой. Авиакомпании знают про это и играют на ценах. Цветные декоративные вставки для телефонов позволяют менять цвет на популярный сразу перед запуском.
E16: Принцип маржинальной экономики: всегда сравнивайте маржинальную стоимость и маржинальную пользу.
Разработчики продуктов редко обращают внимание на маржинальную стоимость и пользу. Например, есть проект с двумя функциональностями в разработке, каждая из которых готова на 80%. Одна идет по графику, другая отстает, над какой нужно работать? Большинство станет работать над отстающей от графика, потому что план надо выполнять. Правильный ответ - надо работать над той, которая принесет больше денег. Забавно, что чаще всего это функциональность, которая не отстает от графика. А отстающая скорее всего уже исчерпала все возможности дешевых улучшений.
E17: Принцип безвозвратных затрат (Sunk Cost): убирайте из рассмотрения уже затраченные деньги.
Например, у вас есть проект средней прибыльности, который готов на 90%. И тут у вас появляется высокоприбыльный проект. Нужно ли его ставить в приоритет? Правильный ответ можно получить только если сравнить прибыльность оставшихся по первому проекту затрат. И тогда получится, что высокоприбыльный проект можно ставить в приоритет только если он даст денег в 10 раз больше.
E18: Принцип покупки информации: цена информации равна ожидаемой экономической выгоде.
Информация уменьшает неопределенность. Например, справедливая цена лотерейного билета на 1,000,000 с вероятностью выигрыша 1 к 1,000,000 равна 1 доллару. Теперь я вам даю 100% информацию о первой цифре выигрыша. Это повышает вероятность выигрыша в 10 раз и повышает ценность билета до 10 долларов. Сколько можно заплатить за такую информацию? Не больше 9 долларов. Поэтому рационально тратить деньги в разработке даже если это не приводит к появлению новых функций.
E19: Принцип покупки страховки: не платите за страховку больше, чем ожидаемая потеря.
Если вы разрабатываете несколько вариантов изделия, чтобы снизить риски неудачи, то вероятность неудачи падает по экспоненте. Если вероятность провала 1 варианта равна 10%, то 2 параллельных решения дадут вам вероятность провала 1%.
E20: Принцип торговца газетами: высокая вероятность провала не означает, что вы сделали плохой выбор.
Продавец газет получает 50 центов за проданную газету и теряет 25 на непроданной. Сколько он должен заказать газет? Оптимальный выбор - это когда газет не хватает в 1/3 случаев. В случаях сильной несимметричности выбора оптимальное решение может выглядеть на удивление плохим. В разработке ассиметрия выбора очень высока и поэтому 96% неудач в проектах разработки новых продуктов не говорит о низкой квалификации менеджеров по продукту, оно говорит нам о несимметричности выборов.
E21: Принцип “как мы на этом заработаем”: чтобы влиять на экономические решения, говорите языком денег.
Когда я слышу, что менеджеры медленно принимают решения, скорее всего, эти решения просто плохо обоснованы с экономической точки зрения. Обычно менеджеры решают очень быстро, если решения хорошо посчитаны.
Принципы систем массового обслуживания (Queueing)
Не спеша поспешай.
Латинская поговорка.
Q1: Принцип невидимости запасов: запасы в процессе разработки не видны физически и финансово.
На производстве мы видим товарные запасы, они отражены в финансовой отчетности. Если мы сократим товарный запас на 10 миллионов, финансовый директор счастлив, так как появились деньги. Если вы спросите финансового директора о том, какие у вас запасы в разработке (DIP, design-in-progress), то он посмотрит на вас с удивлением. Он скажет, что таких показателей в финансовой отчетности нет. Мы и сами можем пройтись по отделу разработки и попробовать найти эти запасы. Но эти запасы по сути информация в головах людей и она скрыта от нас. Как сказал инженер Hewlett Packard: "Наши запасы - это биты на дисках. А диски у нас очень большие!" Но то, что вы не видите запасов еще не значит, что их нет. Вам надо моделировать запасы в разработке, чтобы управлять ими. Иначе вы будете ощущать последствия недостаточного уровня управления запасами в разработке - увеличенным временем цикла, задержками в обратной связи, постоянно меняющимися приоритетами и накладными расходами на отчетность.
Q2: Принцип потерь в СМО: очереди являются корневыми причинами большинства экономических потерь в разработке продуктов.
Очереди в разработке приносят гораздо больше ущерба, чем очереди в производстве. В первую очередь потому что очереди в разработке намного больше очередей в производстве. Цикл разработки в среднем гораздо длиннее, чем производственный цикл. А во-вторых, они невидимы, их никто не замечает, и они принимают форму множества издержек.
Некоторые компании думают, что очереди, которые не находятся на критическом пути, ничего не стоят. Но если вы посмотрите на рисунок, то поймете ошибочность этого мнения. Например, очереди задач на некритическом пути повышают накладные расходы.
Q3: Принцип уровня загрузки ресурсов в СМО: с ростом загрузки ресурса длина очередей возрастает по экспоненте.
Самый главный фактор, который определяет длину очередей - это загрузка ресурса. 13 лет я веду занятия в Калтехе и мои исследования показывают, что разработчики работают с загрузкой, близкой к 98,5%. Какие есть последствия такой загрузки? Простое эмпирическое правило говорит нам, что каждый раз, когда мы уменьшаем свободные резервы ресурса в два раза, мы удваиваем очередь. Перешли от загрузки 60% к загрузке 80%, удвоили очередь, от 80 к 90 еще удвоили, от 90 к 95 еще удвоили.
Если мы знаем загрузку ресурсы, то можем предсказать: - какой процент назначаемых на ресурс работ будет ожидать своей очереди; - средняя длина очереди; - среднее количество рабочих продуктов в системе; - доля ожидания во времени цикла рабочих продуктов в очереди; - отношение времени ожидания к времени добавления пользы.
Эти формулы можно использовать и в обратном направлении, например, с помощью длины очередей посчитать загрузку ресурса. Это нужно потому, что даже самые лучшие оценщики могут легко ошибиться на 10% когда они говорят про запросы и на 10% свою способность выполнять работу. Если эти ошибки сложатся, то у вас будет интервал от 55 до 95%, а это различие в очередях в 25 раз. И хотя загрузка ресурса напрямую определяет экономику процесса разработки, практичнее измерять длину очередей и объем незавершенной работы.
Q4: Принцип состояний СМО с длинными очередями: большая часть ущерба от очередей приносится состояниями с высокими очередями.
На рисунке показана вероятность состояний с высокими очередями для ресурса, работающего с загрузкой 75%. Состояния с высокими очередями сильно задерживают прохождение работы через ресурс.
Помните, что задержка для очереди из двух элементов стоит в два раза дороже. Поэтому задержка в очереди из 10 элементов с вероятностью всего 1.4% намного серьезнее, чем кажется, если смотреть только на процент.
Q5: Принцип вариативности в СМО: вариативность увеличивает очереди линейно.
Вариативность тоже влияет на очереди, но намного меньше, чем загрузка ресурса. Выражение, показанное на рисунке, известно как Allen-Cuneen heavy traffic approximation formula.
Эта формула подходит для процесса разработки, который почти всегда работает с высоким уровнем загрузки. Формула показывает, что длина очередей пропорциональна среднему квадратов вариативности прибытия и коэффициенту вариации процесса обслуживания. Другими словами, запомните, что очереди линейно зависят от вариативности. И даже если у вас будет идеально предсказуемый процесс обслуживания, у вас все равно будут очереди из-за вариативности процесса прибытия. Поэтому не надо думать, что регламентацией процесса и идеальной повторяемостью по CMMI 5 вы сможете убрать очереди. Это невозможно с математической точки зрения.
Q6: Принцип усиления вариативности: работа с высокой загрузкой увеличивает вариативность.
Изменение в загрузке при 95% занятости в 25 раз больше влияет на вариативность, чем изменение в загрузке при 75% занятости. Поэтому руководители, которые выбирают работу подразделения при высоких уровнях загрузки, создают очень высокую непредсказуемость и потери от очередей. Нужно понимать, что вариативность - это самострел.
Q7: Принцип структуры СМО: обслуживайте накопленный спрос надежными высокопроизводительными узлами обслуживания.
Думаю, большинство встречались с этими схемами обслуживания при регистрации в аэропортах. Скорость обслуживания у разных структур СМО разная. Если у вас есть одна очередь к узлу обслуживания, то одна плохая работа тормозит прохождение всей очереди. У схем с параллельной обработкой такой проблемы нет. В разработке же часто встречается ситуация, когда работы обрабатываются последовательно и одна сложная задача тормозит весь процесс разработки.
Q8: Принцип связанных очередей: смежные очереди видят вариативность прибытий и обслуживания в зависимости от загрузки.
Поведение смежных очередей нам интересно потому, что процесс отбытий одной очереди становится процессом прибытий другой очереди. В зависимости от длины очереди в обработке, результирующий паттерн очереди будет похож либо на паттерн прибытий либо на паттерн обслуживания. Например, хайвей Лос-Анжелеса. Светофоры придерживают машины на въезде и впускают их строгими регулярными порциями. Таким образом система борется с волнами прибытий, когда большая порция машин пытается въехать на хайвей и тормозит весь поток. При этом возникают волны, т.к. машины на хайвее тормозят, пропуская въезжающий поток, и это торможение распространяется дальше.
Другой пример снижения вариативности из организации дорожного движения - это то, как правильно организовывать дорожные работы. Если перегородить одну полосу 4-х полосной дороги только в месте ремонта, то машины будут перестраиваться в месте сужения и возникнет турбулентность, которая приведет к снижению скорости потока. Поэтому правильно будет перегородить эту полосу примерно в 1,5-2,0 км. до участка ремонта, чтобы машины смогли перестроиться в свободные ряды. Таким образом мы переносим турбулентность подальше от места сужения и меньше влияем на пропускную способность.
Итак, чем больше мы загружаем ресурс, тем больше мы платим за очереди и тем меньше платим за избыточную мощность ресурса. Наши экономические выборы диктуются оптимальным соотношением этих двух затрат.
Q9: Принцип оптимизации длины очереди: оптимальная длина очереди есть предмет экономического выбора.
Запомните - оптимальная длина очереди есть экономический выбор. Нельзя говорить, что очереди всегда зло. Когда экономические условия меняются, оптимальный размер очереди тоже изменится. Следствия из формулы. Длину очереди можно сократить в два раза, если убрать всю вариативность из процесса обслуживания либо добавить 10% мощности ресурса для системы, которая работает при 90% загрузке. На практике работа с резервной емкостью ресурса намного лучше, чем улучшение повторяемости.
Q10: Принцип дисциплины управления очередями (принцип систем массового обслуживания): стоимость очереди зависит от очередности обработки элементов очереди.
Когда мы делаем экономический выбор при работе с очередями, нам надо не уменьшить длину очереди, нам надо уменьшить стоимость очереди, а это совсем другая задача. Если стоимость задержки задач и длительность из обработки в очереди разная, как бывает в разработке, то обычный принцип FIFO не лучшее решение. Нам нужна дисциплина работы с очередями (queueing discipline). Например, из двух задач с одинаковым сроком исполнения надо выбирать ту, стоимость задержки которой выше. Если стоимость задержки одинаковая, то надо вначале взять ту, которую сделать быстрее.
Теперь понятно, как надо расставлять приоритеты?
Обращайте внимание на среднюю длину очередей! Пример пункта скорой помощи - кто получает приоритет в обслуживании.
Q11: Принцип накопленного потока: используйте диаграмму CFD для отслеживания очередей.
По горизонтальной оси время, по вертикальной накопленное количество. Расстояние по вертикали показывает работу, которая пришла и еще не ушла, или, другими словами, моментальный размер очереди. Горизонтальное расстояние между приходами и уходами показывает время цикла.
CFD позволяет увидеть проблемы с обслуживанием заранее и вовремя принять решение еще до того, как очередь выйдет из-под контроля.
Q12: Формула Литтла: время ожидания = длина очереди/время обработки.
Аналогия с бассейном, в который вода втекает и вытекает.
Когда мы начинаем работать с очередями, люди быстро выучивают, что очереди это плохо и начинают говорить: "У нас нет очередей, мы работаем над всем". Тогда вы просто замеряете всю работу в системе, вне зависимости от того, стоит она в очереди или над ней работают, и по этой формуле считаете время цикла и время завершения работы.
Например, у вас 50 проектов, вы делаете 10 проектов в год, тогда в среднем вы делаете один проект 5 лет. Если лаборатория проводит 50 испытаний и завершает 10 испытаний за неделю, то в график проекта на тест надо закладывать 5 недель.
Особое внимание надо уделять очередям на критическом пути проекта, потому что они приводят к сдвигу даты завершения. Чтобы измерить время, которое проводит задача в очередях, надо поставить ей красный флаг, прогнать ее в приоритете через процесс, полученное время цикла и будет временем исполнения процесса. Сравните его в общим временем цикла, которое вы посчитали по закону Литтла, и получите время простоя в очередях. Например, отдел по таймшитам тратит на процесс 40 часов в неделю и выполняет 10 задач, значит задача в среднем занимает 4 часа. Среднее время цикла по таймшитам 40 часов. Значит задачи в среднем стоят в очереди 90%.
Q13: Первый принцип контроля длины очередей: не контролируйте уровень загрузки ресурса, контролируйте длину очередей.
Загрузка ресурса практически бесполезна при оценке процесса разработки. Помните крутой подъем на кривой зависимости длины очередей от загрузки? Небольшие изменения в загрузке хорошо заметны по длине очередей. Такой принцип используется в супермаркетах - если длина очереди превышает порог, обычно три человека, то работники торгового зала садятся за кассы. Это очень эффективный способ разгрузки мест с высокой неравномерностью работ.
Q14: Второй принцип контроля длины очередей: не контролируйте время цикла, контролируйте длину очереди.
Время цикла - запаздывающий индикатор, потому что время цикла нельзя замерить пока работа не будет завершена. Посмотрите на CFD линии досмотра в аэропорте после прилета рейса.
В момент времени 21 к очереди 100 человек присоединяются 400 пассажиров прибывшего рейса. Только в момент времени 41 мы замечаем удвоившееся время цикла.
Q15: Принцип рассеяния: со временем очереди случайным образом серьезно выходят из-под контроля и остаются в таких состояниях долгое время.
Большинство специалистов, которые владеют сейчас статистическим мышлением, работают со статистикой случайных величин. А для работы с очередями нам потребуется статистика последовательностей случайных величин. И здесь чутье даже натренированных людей дает сбои. Приведу классический пример с честной монетой, которую подбрасывают 1,000 раз. Каждый раз при броске когда мы получаем орел мы прибавляем 1, когда получаем решку, вычитаем 1. Сумму накопленным итогом по исходам строим в виде графика.
Результат обычно поражает. Никакого приближения к среднему, никаких колебаний вокруг нуля. Статистически говоря, есть всего 50% вероятность, что за 50 бросков кривая хотя бы раз пересечет ось Y. У этой кривой биномиальное распределение, центральная предельная теорема.
Ключевой вывод - даже чисто статистический повторяемый процесс подбрасывания монеты выходит со временем из-под контроля. Что уж говорить о процессе разработки, который легко входит в дорогое состояние высокой загрузки.
Q16: Принцип вмешательства: нельзя полагаться на то, что случайность, которая создала очередь, ее же устранит без вмешательства.
Случайный переход в состояние с высокими очередями приводит к серьезным экономическим потерям. Но как выйти из такого состояния? Представьте, что вы ушли на 10 единиц вверх. Чтобы исправить ситуацию, вам нужно, чтобы подряд выпало 10 решек. Вероятность такого события примерно 0,1%. При этом пятиминутная задержка очереди из 20 задач равна 100-минутной задержке единичной задачи. И мы сейчас показали, что такие состояния имеют тенденцию сохраняться, если ничего не делать. Поэтому очереди надо разгребать и делать это быстро.
Обычные места возникновения очередей: - Маркетинг - Аналитики - Отдел проектирования (САПР) - Закупки, особенно когда закупки для нужд разработки идут по стандартным процедурам - Прототипирование - Тестирование и испытания - Защиты у руководства - Изготовление оснастки - Узкие специалисты
Принципы вариативности
Мы не можем добавить пользу без увеличения вариативности, но мы можем увеличить вариативность и не принести пользу.
Нет более недооцененной концепции в разработке, чем вариативность. Из-за того, что вариативность иногда приводит к плохим ситуациям, некоторые делают ошибочный вывод, что от нее надо всегда избавляться. Это подается под разными соусами: с первого раза правильно, ноль дефектов, повторяемость, модели зрелости процессов, 6 сигма. Величина вариативности значит намного меньше, чем экономическая цена вариативности. Экономическая цена вариативности определяется функцией выплат. Понимать эту формулу очень важно, т.к. увеличить прибыльность процесса можно гораздо более простыми способами, чем снижение вариативности. Продуктовая разработка приносит пользу за счет того, что она производит новые рецепты и информацию о продуктах. Если мы во второй раз выпустили тот же самый чертеж, то никакой новой информации он не несет, пользы от этого нет. Есть четыре принципа, которые определяют экономику продуктовой разработки.
V1: Принцип выгодной вариативности: вариативность может принести экономическую пользу.
На рисунке показаны три сценария разработки. Каждый стоит 15,000 долларов вложений в него. Путь А имеет вероятность успеха 50% и принесет 100,000 долларов сбережений если будет удачным. Путь В 90% и 20,000, пусть С 100% и 16,000. Какой выбор будет экономически правильным? Путь А, с ожидаемой выгодой 35,000 долларов. Но какой из выборов наименее вариативный? У пути С нулевая вариативность, но экономический эффект всего 1,000 долларов. Экономика каждого выбора состоит из двух факторов - функции вероятности и функции выплат.
Мы не можем принимать хорошие экономические решения, если будем обращать внимание только на вероятности. НО это ровно та штука, которую мы делаем, когда убираем вариативность.
Не все виды функций выплат связывают увеличение вариативности с увеличением экономической пользы. Выбор одного варианта из трех известен под названием суда Бернулли, и он укажет нам на более общую функцию. Вариант А имел высокую ассиметричность функции выплат и поэтому был предпочтительным. Обратимся к логике расчета цены опционов, модели Блэка-Шоулза. Функция выплат опциона ассиметрична относительно цены актива.
Перемножаем распределение вероятности цены актива на ассиметричную функцию выплат, то мы получим распределение ожидаемых выплат.
Разница между правой и левой частью и есть обоснование самого существования опционов. Чем выше вариативность, тем более полезны опционы.
Почему это важно для продуктовой разработки? Потому что цена успеха в разработке гораздо выше стоимости разработки. Я впервые описал это в принципе газетчика. Когда есть ассиметрия выбора, высокая вариативность создает экономическую выгоду.
V3: Принцип оптимальной вариативности: вариативность не надо сводить ни к минимуму ни увеличивать до предела.
Польза получается не из самой вариативности, а из-за ассиметрии преобразования этой вариативности в функцию выплат. Вариативность сама по себе ни плоха ни хороша. Отличие продуктовой разработки от опционов в том, что у продуктовой разработки неограниченный предел расходов и ограниченный предел роста, это полная противоположность опционам. Мы можем бесконечно вкладывать в разработку, а рост ограничен тем функционалом, который востребован рынком. Поэтому функция выплат для разработки выглядит скорее так:
Резкое изменение производной функции выплат служит сигналом остановки для поиска вариативности.
Например, если мы добавим функциональность с высокой вариативностью, но низкой маржинальностью, мы только навредим проекту. Поэтому не путайте поиск экономической выгоды с поиском вариативности.
V4: Принцип оптимального уровня неудач: 50% уровень неудач обычно оптимален для получения новой информации.
В 1928 году Хартли первым предположил, что количество информации, которую мы можем получить из события, выражается логарифмической функцией вероятности события. Событие с высокой вероятностью содержит мало информации. Мы можем это использовать при составлении планов тестирования. Тест может пройти или провалиться, а средняя информация от тестирования есть функция непрохождения тестирования. Программисты узнают в этом алгоритм бинарного поиска.
К сожалению, большинство разработчиков нацелены на гораздо более высокий процент прохождения тестов, поэтому они получают намного меньше информации на затраченные на тестирование деньги. И слишком высокий и слишком низкий уровень прохождения тестов дает нам меньше информации, чем мы могли бы получить. Фармацевтические компании недаром определяют LD50 (летальная доза для 50% подопытных животных) для новых лекарств. Т.е., нас должен удивлять как успех так и неудача теста. К сожалению, большинство компаний любят докладывать об успехах испытаний и не документируют неудачные испытания. И поэтому повторяют одни и те же ошибки. Повторять уже сделанные ошибки - это потери, новую информацию дают только новые ошибки. Лучше заплатить 1 доллар, чтобы узнать, в каком из двух конвертов лежит 100 долларов, чем в каком из них лежит 5 долларов. Поэтому не переупрощайте принципы работы с вариативностью до "празднуйте ошибки" или "избегайте ошибок". Количество ошибок есть предмет экономического выбора.
Семь принципов снижения вариативности.
V5: Принцип складывания вариативности: общая вариативность уменьшается, когда вы комбинируете несвязанные между собой случайные задачи.
Если мы сложим две случайные переменные, то коэффициент вариации суммарной переменной будет 71% от коэффициентов вариации любой отдельной переменной. Если у нас есть 9 проектов и 9 производственных технологов, то мы можем либо выделить по одному технологу на проект. Это хороший выход, если колебания в потребностях низкие. Либо мы можем создать ресурсный пул и сгладить все колебания потребностей в ресурсах. Это хорошее решение, если есть большие колебания в потребностях. Общий пул технологов снизит вариативность примерно в три раза, сократит очереди и улучшит экономику проектов. Примерно тот же эффект работает когда мы оцениваем трудоемкость проекта. Если в проекте у нас 1,000 задач и у нас есть 1,000 оценок, то каждая из оценок сильно варьируется, но суммарная оценка получится очень точной. Мусор на входе, качественный продукт на выходе. Зато если мы попытаемся составить расписание проекта на низком уровне детализации, то получим очень некачественный график. Надо наоборот, оценивать много мелких задач, а в график включать крупные задачи, получившиеся из объединенных мелких.
V6: Принцип краткосрочных прогнозов: сложность прогнозирования падает по экспоненте по мере уменьшения горизонта планирования.
Ошибки прогнозирования есть главный источник вариативности в продуктовой разработке. Мы можем уменьшить вариативность за счет сокращения горизонта прогнозирования. Когда я служил на подводной лодке неопределенность цели была равна квадрату времени с момента ее последнего обнаружения (площадь круга пропорциональна квадрату расстояния). У рынка намного больше степеней свободы, поэтому прогнозы быстро становятся неактуальными. Прогнозирование на 2 года вперед будет не в 2 раза сложнее прогнозирования на 1 год, а в 10 раз сложнее. Ирония заключается в том, что большинство компаний пытаются уменьшить вариативность за счет тщательного планирования. Такой подход сдвигает горизонт планирования дальше, тем самым приводя к увеличению неопределенности. Скоро такие компании обнаруживают, что единственный человек, который может прозревать через туман будущего - это генеральный директор. Но если все решения принимает генеральный директор, то решения принимаются еще медленнее. Самый лучший способ снизить неопределенность - это сократить горизонт планирования. Поэтому-то и нужно уменьшать размер партии и сокращать объем проекта. Меньший объем проекта означает сокращение сроков реализации, а сокращение сроков реализации дальше сокращает горизонт планирования и уменьшает риски. Уменьшение рисков означает меньшую вовлеченность топ-менеджеров и собственников, а это еще сокращает время на принятие решений. Это положительная обратная связь.
Большие очереди увеличивают горизонт планирования и ухудшают качество прогнозов. Уменьшайте размер партии и длину очередей и вы уменьшите риски проектов.
V7: Принцип маленьких экспериментов: много небольших экспериментов дадут меньший разброс, чем один большой.
Статистика учит нас, что полезно разбивать крупный риск на множество мелких. Интуитивно мы ошибочно думаем, что ничего не меняется и общий риск остается таким же большим. Вернемся к примеру V1. Если нам интересна технология А, но мы не хотим подвергаться риску 50% потери 15,000 долларов? Как можно построить выбор, чтобы уменьшить риск? Такой выбор в статистике называется схемой Бернулли. Когда мы проводим последовательность испытаний Бернулли, то получающееся распределение результатов называется биноминальным распределением. Как меняется среднее и вариация биноминального распределения в том случае, когда мы делим эксперимент на большое количество испытаний? Среднее растет быстрее, чем вариативность. Поэтому когда мы увеличиваем количество испытаний, мы уменьшаем вариативность. Коэффициент вариации уменьшается пропорционально корню квадратному из количества испытаний. Например, если мы поставим 1 доллар на "орла", то у нас 50% проигрыша. А если мы разделим ставку на 4, то вероятность проиграть все за 4 броска будет равна 1/16=6.25%. В продуктовой разработке это дает экономически однозначный ответ на вопрос запускать продукт с 10 крупными доработками или выпускать доработки по отдельности. Выпуск доработок по отдельности имеет намного больше экономического смысла.
V8: Принцип повторений: повторения уменьшают вариативность.
Эффект от разбиения на маленькие задачи не ограничивается только статистикой. Когда у нас есть много маленьких повторяемых задач у нас появляется экономический стимул оптимизировать их исполнение. Например, когда разработка программного обеспечения перешла на ежедневные билды и тестирование, то появился стимул стандартизовать процесс. Когда вы делает чекин кода 1 раз в год, зачем вкладывать усилия и время в оптимизацию этого процесса? Поэтому и надо уменьшать размер партии и добиваться повторяемости процесса.
V9: Принцип повторного использования: повторное использование уменьшает вариативность.
Повторное использование - это один из самых редко используемых способов уменьшить вариативность. Повторное использование важное по двум причинам. Первая - оно устраняет вариативность по срокам исполнения. Второе - повторное использование уменьшает загрузку ресурса. А мы уже говорили, что уменьшение загрузки ресурса уменьшает вариативность. Повторное использование должно быть обосновано экономически. Например, более высокая вариативность новой технологии может с лихвой перекрываться выгодами ее использования.
V10: Принцип отрицательного коварианта: мы можем уменьшить вариативность применяя эффект противовеса.
Пример парусной лодки, которая может перевернуться от порыва сильного ветра. Уменьшение парусов приведет к снижению скорости. Поэтому команда лодки переходит на сторону, противоположную давлению ветра, уравновешивая его. Например, в разработке мы можем натренировать разработчиков проводить тестирование, и тогда они смогут помогать тестировщикам в период пиковых нагрузок.
V11: Принцип буфера: буферы обменивают деньги на уменьшение вариативности.
Мы можем изолировать проект от вариативности с использованием буфера. Разработчики используют буферы, чтобы избежать срыва сроков.
Допустим, у исходного расписания есть 50% вероятности завершиться за 12 месяцев. Чтобы точно уложиться в срок, мы даем 90% оценку в 15 месяцев. Проектный буфер 3 месяца стоит нам всей заштрихованной области. Фактически, мы превращаем случайное опережение графика в гарантированное отставание. Так что обычно использование буферов является плохой идеей.
Уменьшение экономических последствий вариативности.
V12: Принцип последствий вариативности: снижение последствий вариативности обычно лучший способ снижения ее стоимости.
Например, мы можем быстро отказаться от неудачной ветки разработки. Если функционал гораздо сложнее реализовать, чем мы думали, то мы можем отказаться от его разработки. И наоборот, если разработка функционала идет намного легче, чем мы планировали, мы можем сделать гораздо больше, чем запланировали.
В продуктовой разработке правая часть вариативности "хорошая", левая "плохая", а в бережливом производстве обе части "плохие". Допустим, программист при разработке решения для протокола передачи данных сделал неудачное допущение. Если это допущение выявится при ночном билде, экономические последствия этой ошибки будут намного меньше, чем если бы он ждал 30 дней, потому что за 30 дней программист может написать много неправильного кода.
V13: Принцип нелинейности: работайте в зоне линейных характеристик.
Лодка обладает естественной стабильностью в определенных границах крена и тангажа. Если крен будет слишком большой, то лодка перевернется. Это и есть выход за границы линейного поведения системы. У многих систем есть такие границы работы, за которые лучше не заходить. Типичный пример такого нелинейного поведения можно найти в задержках проекта. Небольшие задержки легко компенсировать дополнительными усилиями в маркетинге и продажах. Но чем больше задержки, тем серьезнее их последствия. Мы обсудим как справляться с такими ситуациями в разделе, посвященному заторам.
V14: Принцип подмены вариативности: заменяйте дорогую вариативность дешевой.
Например, задержка запуска завода может стоить намного дороже, чем низкий объем выпускаемой продукции в первые 30 дней. Мы подменяем дорогую вариативность сроков дешевой вариативностью выпуска. В разработке мы платим сверх тарифа за перевозку, чтобы получить нужное оборудование пораньше, т.к. задержка проекта стоит нам больше отклонения от бюджета.
V15: Принцип скорости итераций: обычно лучше увеличивать скорость итераций, чем улучшать уровень дефектов.
Если стоимость ускорения итераций сравнима со стоимостью снижения уровня дефектов, то математически лучше ускорять итерации. Сравните снижение уровня дефектов с 2% до 1% и сокращение цикла с 2 недель до 1 недели. 2 итерации с 2% дефектов в каждой дадут качество в 25 раз выше, чем одна итерация с 1% дефектов (работает, если дефектов менее 50%). Обычно ускорение итераций еще и дешевле, чем снижение уровня дефектов. В большинстве процессов разработки скорость итерации определяется длиной очередей, поэтому их сокращение приносит огромные выгоды.
V16: Принцип замены вариативности: переместите вариативность туда, где ее стоимость будет наименьшей.
Узкое вариативное место - это посадочные полосы в загруженных аэропортах. Чтобы эффективно использовать этот ресурс, у нас должна быть очередь самолетов, заходящих на посадку. Но заставлять самолеты кружить над аэродромом в ожидании посадки дорого. Поэтому мы замедляем скорость самолетов в пути, варьируя таким образом загрузку посадочной полосы, и это обходится нам очень дешево. Но есть и еще более дешевый способ управления загрузкой. Мы можем держать запас самолетов на земле в ожидании отлета и варьировать загрузку посадочной полосы, задерживая время их вылета. Так мы откладываем вариативность в самое дешевое место процесса. То же применимо к продуктовой разработке. Если у нас есть загруженный проектами пайплайн, то запуск еще одного проекта приведет к тому, что проект будет 2 года медленно ползти к завершению. И наши маркетинговые исследования устареют на 2 года, инвестиции в проект могут быть потеряны. Поэтому мы придерживаем проект и не запускаем его. Другой пример - работа над багами. Мы не исправляем все баги, а ограничиваем количество, над которым будем работать. Если мы будем исправлять все баги, мы будем делать это медленно, и скорее всего будем много работать над исправлением старых неактуальных багов.
Экономические решения должны поддерживаться экономическими ожиданиями. Экономические ожидания определяются функцией выплат. В продуктовой разработке функция выплат обычно ассиметрична. Когда вы думаете о вариативности, не думайте о ее величине, думайте о ее стоимости. Основной способ борьбы с высокой стоимостью вариативности - снижение размера партии.
Принципы размера партии
Не заходите в воду обеими ногами.
Шарль де Голль
Если спросить типичного разработчика о размере его партии, то он скорее всего удивленно спросит: "Что ты имеешь в виду под размером партии и почему это тебя интересует?" Разработчики просто не думают в терминах размера партии и не до конца используют один из самых важных инструментов для улучшения. Параллельная разработка, быстрое прототипирование, гибкие методы разработки - это все примеры уменьшения размера партии. Но т.к. разработчики не понимают лежащих в основе этих практик механизмов, они не могут применить эти принципы шире. В этой главе мы соберем материалы, убедительно доказывающие пользу уменьшения размера партии.
B1: Принцип управления очередями с помощью размера партии: уменьшение размера партии уменьшает время цикла.
На рисунке показана CFD процесса с равномерным прибытием и обработкой малыми и крупными партиями.
Закрашенная область - размер очереди. Как видите, она пропорциональна размеру партии. И из формулы Литтла напрямую ясно, что средний размер очереди определяет среднее время цикла. Это, в свою очередь, означает, что можно уменьшить время цикла, уменьшая размер партии. Мы уже говорили об уменьшении времени цикла с помощью изменения средней скорости прибытия и отбытия, но с переходом на меньшие партии мы сокращаем время цикла без изменения спроса или производительности ресурса. Это важно, т.к. изменение спроса или добавление мощности ресурса может дорого обойтись.
B2: Принцип вариативности размера партии: уменьшение размера партии уменьшает вариативность потока.
У больших партий по умолчанию большая вариативность и это вызывает периодические перегрузки. Например, ресторан спокойно обрабатывает постоянно приходящие группы людей, которые состоят из 3-4 человек, но автобус с 80 пассажирами перегрузит процесс. Иногда снижение вариативности от уменьшения размера партии может полностью убрать очереди. Например, если отдел 100 человек отправлять обедать в одно время, то там будут очереди и у вас возникнет желание увеличить производительность столовой. А если вы будете отправлять на обед двумя партиями в 11:30 и в 12:00, то вы уменьшите вариативность в прибытиях. Уменьшение размера партии один из самых дешевых, простых и мощных способов уменьшения вариативности в очередях.
B3: Принцип зависимости обратной связи от размера партии: уменьшение размера партии ускоряет обратную связь.
Этот эффект особенно важен в разработке, т.к. обратная связь поступает постоянно и она очень важна с экономической точки зрения. Мы постоянно пробуем новые штуки и подвергаем себя риску.Нам нужна обратная связь, чтобы контролировать последствия ошибок в ходе экспериментов и стоимость вариативности. В продуктовой разработке последствия ошибок обычно возрастают по экспоненте, быстрая обратная связь важна еще и поэтому. Это происходит потому, что принятое инженерное решение влечет за собой принятие других, связанных с ним инженерных решений. Поэтому если мы не заметим ошибку вовремя, то нам придется пересматривать сотни решений потом. Если мы задерживаем обратную связь, то доработки обходятся намного дороже.
B4: Принцип зависимости рисков от размера партии: уменьшение размера партии уменьшает риски.
Снижение риска происходит по трем причинам. Первая - уменьшение длины очередей, в результате уменьшение времени цикла, меньше рисков изменения рынка или технологий (см. V6). Второе - разбиение крупной партии на мелкие снижает риск ошибки (см. V7). Третьей - маленькие партии ускоряют получение обратной связи, это снижает последствия ошибок. Не случайно пакетные посылки в Интернете такие маленькие. Если вы будете посылать 10-мегабайтный файл по каналу с частотой ошибок 1 на миллион. У вас в среднем будет 10 ошибок на передачу. Шанс того, что пакет будет передан без ошибок 1 к 22,026. А если мы разобьем этот пакет на 10,000 частей по 1,000 байт в каждом, то вероятность порчи единичного пакета составит 1 к 1,000. Накладные расходы такой организации всего 0,1%. Другими словами, если не разбивать крупные пакеты, то накладные расходы будут в 22 млн. раз больше.
B5: Принцип накладных расходов, связанных с размером партии: накладные расходы снижаются с размером партии.
Это кажется неправильным, т.к. мы все привыкли к эффекту масштаба. Ведь накладные издержки связаны с каждой транзакцией. Но мы просто не привыкли к тому, насколько можно снизить издержки часто повторяющихся транзакции. Рассмотрим для примера отладку багов крупными партиями. Если у нас есть 300 открытых багов в системе, то если мы находим баг 301, то нам надо проверить, а не завели ли мы его в систему раньше, и не создадим ли мы дубликат. Если у нас 30 багов, то задача становится намного проще. По закрытию багов надо отчитываться, а отчитываться по 300 багам намного дороже, чем по 30. Вдобавок очередь из 300 багов двигается намного медленнее, баги дольше висят в системе, поэтому каждый баг в среднем появляется в 10 раз большем количестве отчетов. Напомню, ровно то же самое происходило когда мы переходили на бережливое производство. Все тоже были очень удивлены, что производство малыми партиями обходится дешевле производства крупными партиями.
B6: Принцип эффективности, связанной с размером партии: крупные партии уменьшают эффективность.
Разработчики считают, что длительные периоды беспрерывной работы улучшают эффективность инженеров. Это справедливо для отдельного инженера, но проблема в том, что они почти всегда работают в командах. Например, производственный отдел может потребовать, чтобы разработчики завершили и выпустили все чертежи, прежде чем сдать их на проверку в производственный отдел. Им кажется, что проверить сразу 200 чертежей за одно совещание это самый эффективный расход времени. Но какой будет системный эффект такого решения? Если инженеры заложили неверное предположение в начале разработки, то это предположение закрадется во все 200 чертежей. Проблемы во всех 200 чертежах будут обнаружены в один момент. Инженеры будут исправлять все 200 чертежей, а производство проверять, все ли исправили. Эффективность крупной партии была полной иллюзией. Если бы инженеры сделали 20 чертежей и отослали их на проверку, то ошибку бы обнаружили гораздо раньше, переработок было бы гораздо меньше. Другой пример из области программирования. Если в билде есть много новых строчек кода, то отлаживать надо их все. Сложность отладки растет как 2 в степени N, N - количество изменяемых вещей. Поэтому вся эффективность, накопленная непрерывностью работы, будет утеряна на отладке гораздо более сложной доработки. Кроме того, инженеры гораздо лучше работают с задачами, которые они делали недавно. Инженерная работа настолько сложная, что она быстро теряет свежесть. Если вы дадите программисту обратную связь по его коду в течение 24 часов, то он точно вспомнит, что он делал. Если вы дадите ему точно такую же обратную связь через 3 месяца, то он с трудом вспомнит свою же работу.
B7: Принцип связи психологии разработки с размером партии: крупные партии неизбежно снижают мотивацию и чувство срочности.
Крупные партии снижают мотивацию двумя путями. Во-первых, они размывают ответственность. Если я лично должен поставить программный модуль в течение следующих 5 дней, то мне некуда скрыться. Если мне нужно поставить один из 100 программных модулей к точке интеграции, которая будет через 100 дней, то у меня не будет такой срочности. Даже если я буду отставать от графика скорее всего другие отстают так же, а то и хуже, чем я. Когда есть 100 модулей, которые идут одним пакетом, то скорее всего я не один буду испытывать проблемы, поэтому у меня нет стимулов спешить. Во-вторых, крупные партии демотивируют задержкой обратной связи. Инженеров очень заряжает быстрая обратная связь по их работе, особенно если что-то получается. У нас появляется чувство причинно-следственной связи между действиями и результатом и мы начинаем работать лучше. Так из жертв бюрократической системы мы становимся активными участниками процесса. Даже когда обратная связь говорит нам, что наша идея неудачная, все равно это лучше, т.к. мы можем быстро остановить работы по неудачной ветке разработок.
B8: Принцип сдвига сроков, связанный с размером партии: крупные партии вызывают экспоненциальный рост стоимости и сроков.
Если я вас все еще не убедил в том, что маленькие партии обеспечивают экономику лучше, чем крупные, то убедитесь в этом сами на своих данных. Посмотрите на проекты, которые вы делали последние 10 лет и сделайте простую регрессию между плановой длительностью и срывом сроков. Вы получите примерно такой график:
Первое что вас удивит в нем - это необычно высокий процент срывов для длительных проектов. Одна компания сказала, что эти данные лучше всего аппроксимируются степенной зависимостью с показателем степени 4. Это означает, что проект с длительностью 2 года подвергается риску срыва сроков в 16 раз больше, чем проект длительностью 1 год.
B9: Принцип спирали смерти, связанный с размером партии: крупные партии приводят к дальнейшему увеличению размера партии.
Крупный проект начинает жить своей жизнью. Все участники такого проекта понимают, что они обречены, но ни у кого не хватает силы воли остановиться. В конце концов когда топ-менеджменту 4 года подряд говорили, что проект будет успешным, для руководителей среднего звена очень сложно будет встать и сказать, что проект на самом деле провальный. Если мы крупно вложились в какое-то направление, то мы начинаем оправдывать эти вложения, некорректно интерпретируем данные и демонстрируем различные когнитивные искажения. Дела становятся совсем плохими, когда проект приобретает статус слишком важного, чтобы быть неуспешным. И тогда все руководители начинают делать все возможное, чтобы их не обвинили в провале "золотого" проекта. Под этот проект начинает заказываться любое оборудование, в него включаются все инженерные задумки, его бюджет и сроки все растут и растут, и проект начинает поглощать все имеющиеся ресурсы. Это настоящая "черная дыра разработки". Так крупные партии вызывают еще более крупные партии. Тесты объединяются в крупные связки, эти связки получают высокий приоритет и надолго занимают испытательные лаборатории. Другие инженеры видят это и понимают, что для того, чтобы их продукция встала на испытательные стенды, им тоже надо объединять тесты в связки и выбивать на них высокий приоритет. Ситуация для каждого участника процесса ухудшается с каждым днем.
B10: Принцип наименьшего общего делителя размера партии: вся партия ограничена худшим элементом.
Если предыдущих 9 пунктов было недостаточно, вот еще один. Если вы берете 8 обычных тестов и добавляете к ним 2 теста, связанных с безопасностью, то вы вынуждены работать со всеми 10 тестами по самым сложным процедурам. Мы не можем начинать следующую задачу пока не закончим тестирование всех элементов. Тем самым мы удлинили критический путь проекта на 8 задач и ничего за это не получили.
Какая математика стоит за оптимальным размером партии?
B11: Принцип экономики размера партии: оптимальный размер партии описывается U-кривой.
Оптимальный размер партии определяется балансом стоимости транзакции и задержки.
В этой функции нет крутых ступенек, она непрерывная. Это означает, что мы можем подбирать оптимальный размер партии.
В этом серьезное отличие от того, как мы управляем ресурсами. Ресурсы мы добавляем чаще всего довольно большими ступеньками, например, покупаем еще один тестовый стенд, сервер или нанимаем человека. Кроме того, мы можем вернуть старый размер партии, если нам не понравился новый, с ресурсами так не получится. Это важно, если нам надо постраиваться под меняющиеся условия. И, как мы помним, U-кривая оптимизации позволяет нам спокойно относиться к ошибкам, т.к. они нам обходятся недорого.
B12: Принцип низких транзакционных издержек: снижение стоимости транзакции на партию снижает общую стоимость.
Основной подконтрольный вам фактор, который позволяет уменьшить размер партии - это стоимость транзакции. Блестящая находка японских производителей было выявление того факта, что "постоянные издержки" вовсе не являются постоянными. В то время как на американских заводах штампы меняли 24 часа, на японских научились менять меньше чем за 10 минут. Автоматизация тестирования позволяет снизить размер партии в тестировании в десятки раз. Нам нужно вкладывать время и деньги в снижение размера партии, чтобы получить экономическую отдачу. Если мы внимательно посмотрим на формулу полной стоимости, то заметим интересную вещь - чем больше мы снижаем стоимость транзакции, тем меньше оптимальный размер партии.
B13: Принцип внешних издержек размера партии: сокращение размера партии экономит намного больше, чем вам кажется.
Затраты на тестирование и отладку растут экспоненциально с ростом размера партии. Издержки на хранение запасов в разработке растут быстрее роста запасов. Мы это уже обсуждали, когда говорили, что возможности быстро пропадают, если ими не пользоваться. На практике это означает, что скорее всего мы сильно переоцениваем оптимальный размер партии и нам надо постоянно проверять наши предположения по этому поводу. Один производитель принтеров после сокращения объемов партии обнаружил, что экономия была в два раза больше, чем они ожидали. Поэтому надо сокращать и измерять, сокращать и измерять. Полезная эвристика заключается в том, что надо оптимальный размер партии 70% от расчетного значения. Если вы ошибетесь, то это вам будет стоить максимум 8% общих затрат. Обычно этот риск можно принять.
B14: Принцип упаковки размера партии: маленькие партии позволяют точнее настраивать загрузку ресурсов.
Думайте об этом как о заполнении банки камнями и песком. Даже если банка целиком заполнена камнями и вы не можете положить туда больше ни одного камня, туда все равно можно досыпать песка.
B15: Принцип мобильности: слабая взаимосвязь между подсистемами продукта позволяет уменьшить размер партии.
Чтобы уменьшить размер партии, нам надо развязать их, уменьшить их взаимосвязь. Если мы хотим тестировать систему до того, как она полностью спроектирована, нам надо проектировать систему особым образом. Чем менее жесткий дизайн системы, тем больше у нас возможностей по организации работ. Этот принцип показывает очень важную взаимосвязь архитектуры системы и организации работ. Как только разработчики понимают пользу малых партий, они начинают проектировать систему так, что ее можно было бы производить и испытывать малыми партиями. Они создают слабо связанную архитектуру со стабильными интерфейсами и тем самым менеджеры могут организовывать параллельную работу над несколькими подсистемами и быть уверенными в том, что подсистемы можно будет успешно интегрировать. Повторное использование подсистем играет важную роль в обеспечении стабильности интерфейсов. На практике успешное повторное использование чаще достигается в случае небольших модулей, а не крупных подсистем. Проще повторно использовать конденсатор, чем микросхему. Повторное использование приносит большую пользу. Уже разработанные системы определены, протестированы, их не надо проектировать. Иногда правильно будет повторно использовать не сам дизайн, а логику построения подсистемы. Одна телеком компания сократила сроки разработки в 30 раз за счет создания базы существующих дизайнов и процесса выбора подходящего.
B16: Принцип транспортных партий: самая важная партия - это транспортная партия.
В производстве мы разделяем производственные партии, в которых происходит технологический передел от транспортных партий, которыми материалы доставляются к месту передела. Мы будем называть это производственными партиями и транспортными партиями. Надо понимать, что решения по определению оптимального размера производственной и транспортной партии - это два различных решения. Решение по размеру производственной партии определяется временем организации производства. Решение по размеру транспортной партии определяется постоянными затратами на транспортировку. Например, даже если у нас есть пакет тестирования из 1,000 тестов (производственная партия), мы все равно можем передавать результаты испытаний по мере готовности (транспортная партия). Когда мы уменьшаем размеры транспортных партий, мы обеспечиваем перекрытие и наложение задач, что сокращает время цикла. Кроме того, уменьшение размера транспортных партии ускоряет цикл обратной связи, а это очень важно для продуктовой разработки.
B17: Принцип близости: близкое размещение позволяет уменьшать размер партии.
Часто стоимость транзакции определяется расстоянием. В производстве это часто используется, и это применимо и к продуктовой разработке. Когда мы размещаем команды в одной комнате, мы уменьшаем размер партии. Распределенные команды общаются крупными партиями, общение асинхронное, они не могут помогать друг другу разгребать накопившиеся очереди.
B18: Принцип продолжительности рабочего цикла: короткие рабочие циклы сокращают очереди.
Когда мы уменьшаем количество функционала, мы можем быстрее выпускать продукт и быстрее получать обратную связь от рынка. Кроме того, короткие прогоны позволяют нам чередовать сложные задачи с большой вариативностью с легкими задачами с низкой вариативностью. Так мы боремся с возникновением очередей.
B19: Принцип инфраструктуры: хорошая инфраструктура позволяет уменьшать размер партии.
Хорошая инфраструктура означает снижение транзакционных издержек. Автоматизация тестов позволяет перейти на ежедневное тестирование. Ежедневное тестирование позволяет уменьшить размер партии. Если у нас есть испытательные стенды для подсистем, мы можем двигать их разработку не привязываясь к ходу работ по основной системе. Большинство компаний считают, что системное тестирование гораздо эффективнее тестирования подсистем, вдобавок еще и дешевле. Но это не так, потому что тестирование лежит на критическом пути и происходит в конце разработки, когда стоимость задержки самая высокая (максимальный штат, идут маркетинговые расходы и прочее). Поэтому когда вы обосновываете вложения в инфраструктуру, рассматривайте издержки на всем жизненном цикле.
B20: Принцип содержимого партии: ставьте в приоритет то, что добавляет ценность дешевле всего.
Надо аккуратно решать, что должно пойти в работу. Например, мы проектируем автомобиль с вечным двигателем. Проектирование вечного двигателя (Модуль 1) стоит 5 млн. с шансом на успех 5%. Проектирование остальной машины (Модуль 2) стоит 100 млн. с шансами на успех 100%. В какой последовательности надо организовать разработку?
Если мы вначале будет разрабатывать Модуль 1, а потом Модуль 2, то ожидаемая стоимость разработки будет 10 млн., если наоборот, то 105 млн. Правильная очередность уменьшает риски вложений. Идея простая. План проекта должен составляться исходя из логики создания максимума пользы минимумом средств. И помните, что уменьшение риска - это лучший способ увеличить ценность проекта.
B21: Первый принцип размера партии: вначале уменьшайте размер партии, а потом работайте с узкими местами.
TPS добился 100-кратного снижения времени цикла не за счет того, что Тойота фокусировалась на узких местах и добавляла туда дополнительные ресурсы, как это рекомендует Голдратт. Они снижали размер партии. Вернемся к примеру со столовой. Мы могли бы удвоить размер столовой, это была бы работа с узкими местами. Но мы раздвинули обеденные часы, это работа с размером партии. К сожалению, узкие места - это интуитивно понятная концепция. Гораздо понятнее объяснять очереди с помощью узких мест, а не с помощью размера партии. Очереди в разработке стохастические, а не детерминированные. Иногда они есть, иногда их нет. А если узкое место существует не всегда, то вам будет трудно убедить начальство, что у вас есть узкое место. Возьмем историю из голдраттовской "Цели". В реальности никто не привязывается к самому медленному участнику похода. У вас всегда есть авангард, который быстро двигается и готовит место привала, и основная группа. Вы разбиваете крупную партию на две части, а не используете DRB.
B22: Принцип изменяющегося размера партии: приспосабливайте размер партии к меняющимся условиям.
Польза быстрой обратной связи гораздо важнее в начале разработке. А стоимость транзакций растет по мере завершения разработки. Поэтому оптимальный размер партии для начала проекта будет отличаться от оптимального размера партии для конца проекта. На практике это означает, что даже частота собраний может значительно варьироваться в зависимости от стадии, в которой находится продукт.
Где обычно можно найти большие партии?
Объем работ проекта (scope of work). Финансирование проекта. Фазы проекта. Определение требований.
Планирование проекта. Тестирование. Капитальные расходы. Выпуск чертежей. Защиты проектной документации Выпуски рабочей документации. Исследования рынка.
Принципы ограничения WIP
Тойота ограничивает максимальный объем незавершенного производства и тем самым обеспечивает маленькое время цикла на своих заводах. Как мы в Интернете обеспечиваем согласованный обмен данными между самым медленным и самым быстрым компьютером? Мы ограничиваем объем WIP. Уменьшение размера партии не решает фундаментальную проблему вариативности потока. Изменения размера партии работают слишком медленно, чтобы их можно было использовать для управления быстро изменяющимся потоком в разработке. Однако эти краткие периоды изменчивости гораздо более важны, чем нам кажется. Как было показано в Q15 такие вариации накапливаются в серьезные очереди. Эти вариации надо ограничивать и делается это с помощью WIP лимитов. Основные принципы этой главы опираются на протоколы Интернета, где есть высокая вариативность и непредсказуемость трафика. Нам нужно перестать думать о задачах в терминах сроков исполнения и начать думать в терминах WIP лимитов. Сейчас только 2% разработчиков так думают, надо вырасти в 50 раз.
W1: Принцип ограничения WIP: ограничивайте WIP, чтобы управлять временем цикла и потоком.
Мы указывали, что состояние очередей с большими очередями возникает редко, но длится долго. Такие состояния приносят непропорционально большие убытки. Поэтому встает естественный вопрос - а что такого сделать, чтобы предотвратить такие состояния? Самый простой способ - это не принимать новые заявки, когда очередь становится большой. Такая система массового обслуживания называется M/M/1/k, где k - это лимит на количество задач в системе. Когда мы ограничиваем WIP, то создаем один положительный эффект и два отрицательных. Мы уменьшаем время цикла; мы навсегда отказываемся от потенциально полезного спроса; и мы бесповоротно снижаем загрузку мощностей, т.к. отказываемся от спроса в период заторов.
Посчитаем суммарный эффект и получим, что даже для WIP лимита равного удвоенной средней загрузке с консервативными оценками о задержках, стоимости ресурса и стоимостью утраченных возможностей выгоды от ограничения WIP в 10 раз превышают потери.
W2: Принцип согласования скоростей: ограничения WIP заставляют выравнивать скорости.
WIP лимиты - это самый простой способ согласовать скорости взаимодействующих процессов. Между двумя взаимодействующими процессами есть резерв работы, который пополняется втекающими задачами и опустошается забираемыми задачами. Поэтому когда вы ограничиваете объем этого резерва, вы заставляете процессы забора синхронизироваться с процессами пополнения. Этот принцип лежит в основе современного телекома. В сети с переключением пакетов мы устанавливаем ограничение на количество неподтвержденных пакетов между передатчиком и приемником в любой момент времени. Передатчик не может послать пакетов больше, чем приемник сможет принять. Так мы согласовываем скорость приема и передачи между компьютерами с различием в быстродействии сотни миллионов раз по каналам с непредсказуемой загрузкой.
W3: Принцип общего ограничения системы: используйте общие ограничения для предсказуемых и постоянных узких мест.
В теории ограничения Голдратта мы заставляем всю систему работать со скоростью работы узкого звена. Фактически, мы ставим WIP лимит на количество задач, которое находится до узкого звена. Это очень привлекательная концепция, но отсутствие локальных WIP лимитов приводит к двум недостаткам. Если узкое место в процессе возникает случайно, то система не получит сигнала обратной связи пока общее узкое место не истощит весь буфер. Второе - когда производительность узкого места упадет, перед ним будет скапливаться незавершенная работа. Представим, что узкое место остановилось. Т.к. остальные процессы перед ним все еще будут работать, то перед узким местом скопится огромный запас незавершенного производства. Когда узкое место восстановит работу, то у него будет огромная очередь, а предыдущие звенья процесса будут простаивать. У самой простой канбан системы Тойоты нет этих недостатков.
W4: Принцип локальных ограничений системы: по возможности ограничивайте резервы незавершенной работы локально.
Канбан систему Тойоты называют вытягивающей системой, хотя полезнее называть ее системой, которая локально ограничивает незавершенное производство. Простой производственный канбан может установить ограничение на 30 сборочных единиц между двумя процессами. Единицы будут укладываться на палетты, 6 паллет по 5 единиц на каждой. Последующий процесс опустошает палетт и возвращает пустой палетт предыдушему процессу. Предыдущий процесс не может работать если у него нет свободных мест на палетте. Так в процессе никогда не будет больше 30 единиц. Если на все процессы общей производственной системе наложены локальные лимиты, то у вас есть лимиты и на общее количество работы в системе. Если общее количество работы ограничено, то в соответствии с формулой Литтла, время цикла тоже ограничено. Так ограничение на количество незавершенной работы ограничивает время цикла. Канбан система не делает никаких предположений по тому, где же расположены узкие места. Как только в процессе появляется узкое место, оно тут же начинает посылать сигналы предыдущим процессам. Как только процессы заполняет все свободные палетты, он перестает отсылать пустые предыдущему процессу и останавливает его работу. Поэтому когда происходит блокирование работы, то все рабочие центры прекращают работать на своему максимальном уровне незавершенного производства. Как только блокировка убирается, ритмичный процесс восстанавливается. Это хорошо подходит к стохастическим процессам разработки. Скорость обратной связи процесса с локальными ограничениями тоже впечатляет. Вариативность в производительности быстро приводит к появлению сигнала обратной связи. Допустим, размер канбана равен 6, а время такта 1 минута, тогда в среднем сигнал обратной связи появится за 3 минуты. Сравните это с обычной MRP, которой для такого же сигнала потребуется около 20 часов. Канбан в 400 раз чувствительнее MRP к возникающим очередям. Канбан быстрее ТОС системы. Допустим, узкое место по ТОС ускорилось. В канбане предыдущие процессы тоже быстро наберут скорость. В ТОС процессы после узкого места ускорятся, но предыдущие процессы не синхронизированы с новой скоростью работы узкого места, им надо адаптироваться к нему, это приводит к задержкам и когда они перестроятся на новую скорость, то узкое место уже может опять уронить производительность, и система расбалансируется. Такие качели производительности возникают при остановке узкого места. Когда узкое место останавливается, то перед ним возникает запас незавершенного производства. Пока оно вырабатывает его до уровня пополнения, предыдущие процессы не работают. Потом они запускаются, но т.к. они стояли пустые, им надо время на восстановление, поэтому пока они разгонятся, узкое место может полностью переработать все свои запасы и снова остановиться. Такие "волны" в производстве могут продолжаться довольно долго. Тойота еще улучшила стабильность своих процессов, натренировав сотрудников выполнять работы на соседних станциях. Поэтому когда в одном месте появляется избыточная мощность, она тут же перебрасывается на предыдущий процесс. Такой же подход можно применить и в продуктовой разработке.
W5: Принцип расстыковки размера партии: используйте диапазон WIP вместо фиксированных значений, чтобы не связывать размеры партий соседних процессов.
Когда мы ограничиваем размер резерва WIP, то связываем скорость прибытий и отбытий. Таким образом связываются и размеры партий и время прибытий и отбытий в этих процессах. Это похоже на стыковку рейсов в аэропортах. Но у разных процессов могут быть разные экономически обоснованные размеры партий, поэтому такая связь нежелательна. Чтобы избежать этой проблемы, канбан разрешает межпроцессным резервам WIP меняться в диапазоне от нуля до предельного. Так мы можем рассинхронизировать прибытия и отбытия в процессах.
Реагирование на возникающие очереди.
Искусство управления очередями не в том, чтобы отслеживать их возникновение и устанавливать лимиты. Искусство в том, что же делать, когда мы достигаем лимитов. В этом разделе мы покажем 9 приемов работы с превышением лимитов WIP. Первые три направлены на спрос. Следующие пять на предложение. И последний направлен на микс работ.
W6: Принцип блокировки потребностей: заблокируйте весь спрос, когда WIP достигает верхнего предела.
Это самый простой способ - просто прекратите принимать заявки когда спрос превышает WIP лимит. Это принцип работы наземной телефонной линии - когда все коммутаторы заняты, вы не можете набрать номер и слышите отбой. Блокировку можно сделать двумя способами. Первый - просто отклонять приходящую работу. Это может казаться экстремальным подходом, но помните, что состояние с высокими очередями приносит невероятные убытки и его надо избегать всеми силами. Второй способ - это задерживать работу в предыдущих процессах. Это не уменьшает спрос, это просто сдвигает очередь в другое место. Если разные очереди имеют для вас разную стоимость задержки, это снижает ваши издержки. Этот метод использует TPS.
W7: Принцип очистки WIP: когда WIP приближается к пределу, избавляйтесь от низкоприбыльных проектов.
При высоких WIP длинные очереди. Длинные очереди вызывают большую стоимость задержки, возрастает стоимость хранения. В таких условиях логично избавляться от задач, держать которые было разумно при низкой стоимости очереди, но неразумно теперь, когда стоимость хранения возросла.
Думайте об этом как о больнице, которая обслуживает в первую очередь тяжелых больных. При этом важно не учитывать понесенные затраты, а считать только маржинальную экономику проектов. Вместо того, чтобы закрывать проекты, компании часто оставляют их полуживыми. Так и появляются проекты-зомби. Зомби убивают поток, поэтому вам надо убить их.
W8: Принцип гибких требований: контролируйте WIP урезая требования.
Стоимость реализации требований растет в периоды заторов, поэтому в такие моменты надо урезать требования с недостаточным экономическим обоснованием. Реализация требования блокирует остальную работу и вам надо считать стоимость таких задержек. Когда вы снимаете такие требования, сразу наступает облегчение, т.к. вы уже работаете на крутом участке кривой "загрузка ресурса - длина очереди". Лучше всего заранее определять, какие требования можно снять или ослабить в случае возникновения заторов. Когда мы заранее определяем список требований, которые мы можем снять, нам проще принимать решения в периоды заторов и нам проще структурировать архитектуру продукта так, чтобы снятие требований было простым. Можно ослабить требования к себестоимости продукта в производстве и произвести первые экземпляры с помощью неэффективного производственного процесса. Но чтобы разработчики чувствовали не только выгоды, но и цену такого решения, надо чтобы бюджет пилотного запуска висел на разработчиках. Эти три принципа - блокировка потребностей, очистка WIP и урезание требований, могут быть очень быстро реализованы. Применение остальных принципов гораздо сложнее.
W9: Принцип вытягивания ресурсов: быстро привлекайте дополнительные ресурсы к образующимся очередям.
При высоких уровнях загрузки очереди могут расти гораздо быстрее, чем мы их сокращаем, и поэтому ресурсы надо привлекать очень быстро. Представьте загруженную 4-х полосную дорогу, одну полосу которой перекрыли на 10 минут. При этом образуется пробка на 40 минут. Все потому, что на высоких уровнях загрузки очередь возникает намного быстрее, чем мы можем с ней справляться. Т.к. кривая при высоких уровнях загрузки очень крутая, то вам потребуется на удивление мало ресурсов, чтобы сократить очереди. Даже если вы добавите к эксперту с высокой загрузкой ресурс, у которого производительность всего 20% от производительности эксперта, это все равно даст очень значительный эффект по снижению очередей.
W10: Принцип временно задействованных ресурсов: используйте временные ресурсы для задач с высокой вариативностью.
На рисунке показана типовая ситуация в которой работники на неполную ставку могут резко увеличить производительность процесса. Такой выход подходит для задач с высокой вариативностью, которые лежат на критическом пути важной программы. Дополнительный плюс такого варианта заключается в том, что вам не нужно обучать людей и вводить в курс дела, ведь они уже работают на программе.
W11: Принцип Царь-пушки: развивайте людей с глубокой экспертизой в одной области и широкой во многих.
Когда морпехи готовили атаку, они полагались на самые большие 16-дюймовые пушки линкоров. Такие пушки были редким и ценным ресурсом. В разработке тоже встречаются специалисты, способные решить практически любую проблему. Это те 10% людей, которые решают 90% самых сложных задач. Они идеальны для избавления нарождающихся очередей. Но чтобы "большие пушки" могли решать проблемы, их нельзя загружать полностью, они должны быть способны быстро реагировать и приходить на помощь. Нам надо избавиться от такого подхода. "Большие пушки" не есть замена множества маленьких, у них свои задачи.
W12: Принцип ресурсов T-Shaped: развивайте людей с глубокой экспертизой в одной области и широким кругозором.
Специалистов широкого профиля легко бросить на задачи, которые больше всего нуждаются в поддержке. Это так называемые T-люди. Вам надо нанимать людей, которые хотят иметь Т-экспертизу. Обычно из ВУЗов мы получаем I-инженеров, надо инвестировать в развитие их навыков, надо иметь программы мотивации, которые поощряют людей расширять компетенцию.
W13: Принцип перекрытия навыков: тренируйте людей исполнять процессы смежников.
Быстро T-людей не создашь, зато можно быстро натренировать людей помогать смежникам. Это особо важно, т.к. именно от смежников приходит первый сигнал о возникновении очередей. Программистов можно обучить проводить тестирование.
W14: Принцип замены микса задач: меняйте микс задач в предшествующих процессах для регулировки очереди
Один из наименее очевидных способов борьбы с очередями заключается в том, что вам надо задерживать задачи, которые ухудшат состояние очереди.
Посмотрите на рисунок. Когда очереди небольшие, мы работаем над подсистемами В либо Е, у которых малое время проектирования и длительное тестирование. Когда очереди длинные, мы должны работать на подсистемой С с длительным временем проектирования и коротким тестированием. Мы можем это сделать за счет простой классификации задач по их влиянию на очереди. Например, "высокая", "средняя" и "низкая" потребность в тестировании. Это похоже на принцип V10, использующий отрицательную ковариацию.
Примеры ограничения WIP
- Количество разработанного, но не протестированного кода - Ограничение глубины планирования 60 днями - Ограничение количества проектов в пайаплайне
W15: Принцип старения: следите за большими отклонениями.
Среднее значение обманчиво. Сроки исполнения некоторых задач сильно превышают среднее значение. Мы можем обнаружить такие задачи, анализируя отчеты по времени исполнения задач. Такой анализ называется учетом сроков закрытия задач (aging analysis). Небольшие срывы сроков не так критичны, как серьезные. Если задача сильно отстает от запланированной даты завершения, значит с ее выполнением возникли серьезные проблемы.
W16: Принцип передачи вверх по инстанции: создайте процесс оповещения руководства о проблемах с серьезными запаздываниями.
Мало просто выявлять задачи с серьезными задержками, надо что-то с этим делать. Самый простой способ - доводить до руководства список задач, которые висят в очереди больше определенного количества дней, например, 2 недель. Такой подход позволит реализовать вам управление по исключениям. Либо вы можете автоматизировать процесс, и повышать приоритет задачи, если она висит в системе больше определенного количества времени. Задержка даже задач с низким приоритетом может вам дорого обойтись. Единственный момент, про который я хочу напомнить вам, заключается в том, что вы всегда должны руководствоваться экономическими критериями при выставлении приоритета по задачам.
W17: Принцип прогрессивного регулирования количества запросов: активнее регулируйте поток по мере приближения к границе.
Это методы из управления Интернет трафиком. Random early deletion и Random early marking. Вы начинаете регулировать до заполнения буфера. Например, вы можете ужесточать критерии одобрения проектов по мере увеличения загрузки.
W18: Принцип различных уровней сервиса: обеспечьте разные уровни обслуживания для разных потоков работ.
Обслуживание для работ с высокой стоимостью задержки должно быть лучше. Для каждого класса обслуживания мы указываем процент выделения ресурсов на эти задачи и WIP лимиты. Это позволяет на гарантировать время цикла для задач этого класса даже если эти задачи используют один и тот же ресурс.
W19: Принцип адаптивных ограничений WIP: подстраивайте WIP лимиты под меняющуюся производительность ресурса.
В Интернете у нас есть "окно передачи". Размер окна передачи определяет количество пакетов, которые могут передаваться в системе одновременно. Передатчик постоянно проверяет ширину канала, линейно изменяя величину окна. Если начинаются затруднения с передачей данных, то скорость падает обратно. Этот метод называется AIMD. В продуктовой разработке мы можем плавно поднимать WIP лимиты если задачи быстро выполняются, и уменьшать WIP лимиты, если скорость работы падает.
W20: Принцип контроля расширения: предотвращайте бесконтрольное расширение работы.
Недостаточно контролировать прибытия, надо еще контролировать разрастание объемов принятых задач. Некоторые задачи в разработке ведут себя как идеальный газ, заполняя все доступное время. К таким задачам относится, например, разработка концепции продукта. Операционные системы так справляются с этой проблемой. Там тоже может прийти задача с бесконечным временем исполнения, и в момент приема мы не можем ее определить. Поэтому мы ставим предел тому, сколько может исполняться любая задача. Второй способ борьбы с такими задачами - это останавливать исполнение в точке, когда польза от выполнения задачи начинает резко убывать. Мы можем сказать, что должна быть минимальная скорость продвижения по задаче.
W21: Принцип критической очереди: ограничивайте WIP в той части системы, где самые дорогие очереди.
После того, как мы установили локальные WIP лимиты, мы должны постараться снизить до минимума WIP в тех частях системы, где очереди обходятся дороже всего. Пример аэропорта, где есть неопределенность в доступности ВПП. Есть несколько резервов незавершенной работы - самолеты, ждущие взлета, самолеты в полете, самолеты, кружащие над аэродромом в ожидании посадки. Самый дешевый способ - это заставить самолет ждать вылета. В продуктовой разработке мы тоже можем не запускать проекты, потому что после запуска они начнут поглощать ресурсы, размывать стратегию, увеличивать накладные расходы. Мы можем дождаться момента, когда проекты смогут быстро пройти через пайплайн. Точно так же имеет смысл работать только над свежими багами.
W22: Принцип нарастающего сокращения: маленькие ограничения WIP накапливаются.
Один из наиболее хорошо работающих методов постоянно снижающегося WIP - это постоянное небольшое превышение скорости отбытий над скоростью прибытий. Если мы последовательно завершаем задач больше, чем к нам приходит, то мы сокращаем очередь. Суммарный эффект может быть огромным. Одна инжиниринговая компания отслеживала и уменьшала WIP. В результате за несколько лет она сократила сроки исполнения своих R&D проектов с 220 до 30 дней. Они достигли этого за счет того, что сделали WIP видимым и последовательно сокращали его.
W23: Принцип визуализации WIP: делайте WIP постоянно видимой.
Нам нужны физические маркеры информации, с которой мы работаем. Обычно это разноцветные стикеры. Менее 1% разработчиков продуктов понимают ценность снижения WIP. Как только мы понимаем, что ограничивая WIP мы уменьшаем время цикла, мы в корне меняем свое мышление. Высокая загрузка пайплайна - это плохо. WIP лимиты удерживают систему от попадания в состояние с длинными очередями. Для этого мы можем предвидеть и выстраивать инфраструктуру и бороться с возникающими проблемами. Думайте про это как про постройку и эксплуатацию дороги. Вы не можете строить дорогу с 20 полосами, которая справится с любым трафиком с учетом поломок и аварий, это экономически нецелесообразно. Вам нужны процессы быстрого реагирования на заторы и дорожные ситуации, нужно реактивное реагирование.
Принципы контроля потока
Все могут быть капитанами в спокойном море.
WIP лимиты не гарантируют, что мы выберем точку с максимальным проходом работы. Они не гарантируют, что мы обрабатываем задачи в оптимальной последовательности. Почему текущему процессу нужна альтернатива? Потому что он очень чувствителен к вариативности. За 100 лет в телекоме были изобретены способы работы, которые эффективно справляются с непредсказуемой и меняющейся загрузкой.
Заторы.
Затор - это состояние системы, которое характеризуется одновременно высокой загрузкой и низкой производительностью. Затор может наступать медленно, но чаще всего это полная неожиданность для всех. Представим дорогу. Поток на дороге выражается количеством машин в час. Его можно разложить на две переменные - плотность потока (машин на милю) и скорость потока (миль в час).
Следующий рисунок показывает поведение прохода в зависимости от скорости. Плотность потока падает линейной с ростом скорости.
Чем выше скорость, тем большую дистанцию держат водители. Эта кривая показывает, что пропускная способность минимальна как при высокой так и при низких скоростях. Для одной и той же пропускной способности есть две точки, в которой ее можно получить - с правой и с левой части распределения. Левая точка, с низкой скоростью, нестабильная, а правая точка, с высокой скоростью, стабильная. Стабильность рабочей точки определяется петлей обратной связи, в левой части она положительная, в правой отрицательная:
На левой части плотность увеличивается и скорость падает, поток замедляется. Это провоцирует дальнейшее увеличение плотности. Поэтому система быстро сдвигается влево и оказывается в состоянии серьезного затора. Многие эмпирические исследования транспортных потоков не могут собрать достаточно фактов об этом состоянии потому что они переходные. В правой части работает петля отрицательной обратной связи - когда плотность растет, скорость падает, это увеличивает поток, увеличенный поток снижает плотность, противодействуя исходному увеличению плотности. Продуктовая разработка тоже страдает от заторов. Когда мы заталкиваем в пайплайн разработки слишком много проектов, мы создаем очереди. Очереди создают ситуацию, когда разработчики вынуждены переключаться между задачами, сидеть на совещаниях, отчитываться и проталкивать свои задачи через смежников. Это приводит к тому, что они создают меньше добавленной пользы для продукта. Увеличение нагрузки привело к снижению полезного результата, а не к увеличению. Что происходит дальше? Маркетинг начинает страдать от замедлившейся разработки, и они увеличивают поток запросов на разработку. Они рассуждают так: "Хорошо, этот проект опаздывает. Тогда надо добавить в него еще функциональности, чтобы продажи от него увеличились." Так постепенно проект оказывается далеко на левой части кривой.
F1: Принцип образования дорожного затора: когда загрузка становится слишком высокой, мы увидим внезапное и катастрофичное падение результативности.
Происходит это так - вы ставите задачу, от исполнителя долго нет ответа, вы ставите ее повторно, потом звоните исполнителю. И так делают все, кто хотят от него выполнения своих задач. В результате исполнитель вместо того, чтобы закрывать задачи, отвечает на звонки и письма, а дело почти не движется. Заторы опасны своей непредсказуемостью. В один момент все еще работает, а в следующий система намертво падает. Если у системы есть положительная обратная связь, то нам надо выбирать точку работы с запасом, чтобы система не оказалась вдруг в состоянии затора.
F2: Принцип пиковой пропускной способности: контролируйте загрузку, чтобы поддерживать высокую пропускную способность в системах, склонных к заторам.
В системах с выраженным пиком пропускной способности у нас есть стимул работать в районе этого пика. На примере дороги мы видим, что мы можем увеличить пропускную способность дороги в пять раз, если увеличим скорость движения с 5 до 45 миль/час. С учетом сказанного раньше, дорога должна работать не на самом пике пропускной способности, у нее должен быть запас. И рабочая точка должна выбираться справа. Как поддерживать работу системы в выбранной рабочей точке? Мы можем контролировать скорость либо загруженность. На практике проще контролировать загруженность. И именно так управляются эффективные дорожные системы. На хайвее Лос-Анджелеса светофоры регулируют въезд машин на трассу. Мы также можем контролировать запуск проектов разработки.
F3: Принцип видимости затора: стройте прогнозы ожидаемой скорости потока, чтобы видеть заторы.
Без измерений мы вообще не можем сказать, есть затор или нет. А т.к. всего 2% разработчиков измеряют очереди, то большинство разработчиков даже сказать не может, есть у них затор в работах или нет. Информация не видна, поэтому если вы не делаете визуализацию, то вы не увидите, где работа стоит. Обычная канбан доска помогает узнавать, где у вас очереди, но длина очереди не самый лучший способ узнавать о заторах. Лучше выдавать пользователям прогноз по дате закрытия задачи. Ожидаемая дата закрытия задачи может рассчитываться по закону Литтла, вы просто делите WIP на текущую скорость закрытия задач. Прогноз по дате исполнения задачи позволяет пользователям принимать рациональные решения. Возьмем для примера uTorrent. Эта программа сообщает не только оставшийся объем закачки, но в первую очередь сколько еще вам ждать, пока раздача закачается. Аналогично поступает Яндекс Навигатор, который говорит вам, что вы доедете до места назначения через 15 минут, а не только показывает дистанцию 1,2 км.
F4: Принцип повышения оплаты при заторах: используйте повышение цены, чтобы регулировать загрузку перегруженного работой ресурса.
Лицо, принимающее решение, должно чувствовать на себе как плюсы, так и минусы своего решения. Это первый принцип рынка Е14. Когда проект ставит задачу ресурсу, то экономическая стоимость использования ресурса зависит от его загрузки. Поэтому ЛПР должен понимать, что он загружает дефицитный ресурс. Самый элегантный способ заставить его почувствовать это - повышать цену за использование ресурса в период высоких загрузок. Этот принцип широко используется в других отраслях. Цены на гостиницы и самолеты варьируются в зависимости от их загрузки. За счет даже небольших изменений загрузки очереди на использование ресурса и время цикла резко сокращается, т.к. при высокой загрузке ресурс работает на крутом участке кривой. Обычно я рекомендую повышать цену на 20-50% в период высокой загрузки. Это не требует большого сдвига в мышлении, руководители проектов привыкли доплачивать за срочность и мы просто применяем принцип, по которому они работают с внешними ресурсами, ко внутренним ресурсам.
F5: Принцип периодической повторной синхронизации: используйте регулярный управленческий ритм, чтобы ограничить накопление вариации.
Пример автобусного маршрута, в котором один автобус начинает отставать от графика потому что набирает и высаживает выше нормы, в результате его догоняет второй автобус и они ходят парами. Выход - синхронизировать интервалы движения при каждом возвращении в парк. Важно различать такую синхронизацию и корректировку при выходе за допустимые пределы. Когда мы повторно синхронизируемся, мы возвращаемся в центр контрольного диапазона, а не просто возвращаемся процесс в контрольные границы. Вернусь к примеру с монетой и диффузией среднего. Если я начинаю игру с 5 долларами, выигрываю 1 и проигрываю 1, то как мне избежать банкротства? Возможно, мне потребует дополнительный капитал, когда я проиграю 4 и у меня останется 1. Если возьму в долг 1 доллар, то есть 50% вероятность того, что мне нужно будет взять в долг еще раз. Если же я возьму в долг 4, то есть шанс всего 1/32, что мне потребуется брать в долг еще раз. Поэтому если очередь задач выросла, то вам надо очищать ее до целевого значения, тогда есть намного меньший шанс, что очередь опять станет длинной. Так мы боремся с заторами. Конечно, когда автобус стоит, то это неэффективно, ведь его задача перевозить пассажиров. Но как это часто бывает, локально оптимальное решение неоптимально на системном уровне.
F6: Принцип запаса по мощности для обеспечения управленческого ритма: обеспечивайте достаточный запас по производительности, чтобы обеспечить управленческий ритм.
Надо понимать, что мы можем повторно синхронизироваться с помощью управленческого ритма только если у нас есть запас по производительности ресурса. Такой запас позволяет нам синхронизироваться в условиях нестабильности. Вернемся к примеру с автобусами. Их расписание должно предусматривать достаточные периоды стоянок на конечных остановках, чтобы компенсировать отклонения от расписания. Другими словами, нам нужно больше автобусов на маршруте, чтобы часть из них просто ждала своей очереди отъехать. Поэтому более предсказуемый и качественный сервис для пассажиров оплачивается оператором маршрута. В продуктовой разработке если мы хотим укладываться в расписание, нам нужен запас по ресурсам, чтобы справляться с отклонениями от запланированных длительностей работ. Это экономический выбор. Мы должны сравнивать стоимость избыточных ресурсов и влияние накопленных отклонений.
F7: Принцип надежности управленческого ритма: используйте управленческий ритм, чтобы сделать предсказуемым время ожидания.
Управленческий ритм делает время ожидания короче и более предсказуемым. Если автобусы отходят строго по расписанию каждые 15 минут, то нам не нужно ждать его отправки, мы точно его знаем. Поэтому наша 10-минутная поездка займет ровно 10 минут. Если мы не знаем времени отправки, то можем ждать до 15 минут, и в результате поездка займет от 10 до 25 минут. Если у нас есть управленческий ритм, то если мы пропустили автобус, мы точно знаем сколько ждать следующего. Если у нас нет ритма, то мы можем только гадать в определенных пределах. В продуктовой разработке календарь продуктовых выпусков может быть асинхронный, когда мы выпускаем продукт в тот момент, когда он готов, либо мы выпускаем продукт раз в 6 месяцев. Поэтому если хорошая идея не была реализована в этом выпуске, она будет реализована 6 месяцев позже. Вся деятельность организации крутится вокруг этого управленческого ритма. Если выпуски асинхронные, то вам надо решать куда засунуть ваш новый прекрасный функционал - в текущий продукт или в следующий. Но вы же не знаете, когда будет следующий, поэтому не рискуете и добавляете его в текущий выпуск. Это сдвигает сроки выпуска текущего продукта и он работает как магнит для всех доработок и идей, которые есть в компании.
F8: Принцип перехода к малым партиям за счет управленческого ритма: используйте регулярный управленческий ритм, чтобы перейти к малым партиям.
Если вы задаете управленческий ритм, то рабочие продукты тоже начинают двигаться ритмично. Если вы проверяете и устраиваете защиту чертежей раз в неделю, вы автоматом переходите к недельному размеру рабочей партии. Регулярный управленческий ритм снижает накладные расходы. Нам достаточно один раз организовать собрание по защите чертежей и дальше мы можем просто работать. Управленческий ритм снижает накладные расходы и уменьшает размер партии.
F9: Принцип последовательных цепочек собраний: составьте расписание с частыми собраниями с использованием предсказуемого управленческого ритма.
Короткие и частые собрания, которые мы проводим по плану, дают нам все преимущества малых партий. Если мы часто синхронизируемся, нам просто некогда сильно отклониться от общего курса. Если же мы встречаемся редко и не по плану, нам очень легко уйти в сторону. Нам надо рассчитать экономически обоснованную частоту и продолжительность собраний. Чтобы частые короткие собрания имели экономический смысл нам надо снижать накладные расходы. Для этого нам надо размещать команду в одном помещении. Из нашего опыта команды, которые встречаются каждый день, тратят на это не больше времени, чем команды, которые встречаются раз в неделю. Если очные встречи невозможны, устраивайте телеконференции. Если есть 4 часовое еженедельное совещание, разбейте его на 4 части и зовите участников только на ту часть, которая касается их. Замечание для тех, кто думает, что асинхронные совещания обеспечивают более быстрое реагирование, чем синхронные. Это было бы правдой, если бы люди сидели без дела и ждали когда же соберут совещание. Но люди обычно очень заняты и стоит больших трудов синхронизировать их календари. Например, для принятия срочного решения потребуется три дня, чтобы собрать всех ЛПР в одном кабинете. Ваше время реагирования будет 72 часа. Если у вас есть ежедневное совещание, то время реагирования уменьшается до 24 часов. Типы управленческих ритмов (cadence): - ритм запуска продуктов - ритм (дневного) тестирования - циклы (ежемесячного) протипирования - проверка продуктового портфеля - статус программы - доступ к ресурсам (пример специалиста по закупкам, который был выделен на 10% на проект и сидел с 9 до 10 в инженерном отделе, решал задачи конкретного проекта) - собрания по проекту - защиты проектной документации (пример critical design review, который проводился еженедельно) - производство прототипов деталей - визиты поставщиков - перерывы на кофе (пример Хьюлетт-Паккард, когда инженеры встречались во время общего перерыва на кофе, к сожалению, от этой практики отказались) Синхронизацию стоит отличать от управленческого ритма. Управленческий ритм задает регулярные временные интервалы событий. Синхронизация приводит к тому, что в один момент времени происходит несколько событий. Мы можем синхронизироваться ритмично и асинхронно. Например, если у нас есть интеграция подсистем, то это может быть либо одна контрольная точка, когда все подсистемы готовы либо серия регулярных интеграций. Синхронизация дает экономический эффект когда нам выгодно обрабатывать несколько задач одновременно. Может работать экономика масштаба. Синхронизация широко используется в электронике из-за разных задержек распространения сигналов по разным цепям. В целом асинхронные процессы быстрее, а синхронные стабильнее.
F10: Принцип запаса по мощности для синхронизации: оставляйте достаточный запас по мощности, если хотите ввести синхронизацию.
Синхронизация, точно так же как и управленческий ритм, требует запаса по мощности. Наше расписание будет определяться самым медленным прибытием. Думайте об этом как о региональных авиарейсах, которые привозят пассажиров в авиахаб для межконтинентального перелета. Между рейсами должно быть достаточно времени на стыковку и отклонения во времени прилета разных рейсов, чтобы все успели пересесть.
F11: Принцип синхронизации в среде с несколькими проектами: используйте экономику масштаба, синхронизируя работы нескольких проектов.
Пример из полупроводниковой промышленности, когда на одной пластине размещаются прототипы нескольких продуктов разных проектов. Другой пример - это защиты проектной документации. Переход с защиты раз в 8 недель на раз в 2 недели. Вместо 4-часовой защиты раз в 8 недель стала 1-часовая защита раз в 2 недели. При этом защищались 4 проекта за один раз, потому что собирать всех ЛПР накладно.
F12: Принцип межфункциональной синхронизации: используйте синхронизированные события, чтобы облегчить межфункциональные выборы.
Компания разрешила асинхронные асинхронный процесс инженерных изменений. Они думали, что процесс ускорится, но на деле все выглядело так:
Когда они увидели, к чему привело это решение, они реализовали синхронный процесс согласования инженерного изменения. Еженедельные совещания комитета по управлению изменениями. Время согласования сократилось с 40 до 5 дней.
F13: Принцип синхронизации очередей: чтобы уменьшить очереди, синхронизируйте размер партии и тайминг смежных процессов.
Когда мы синхронизируем тайминг и размер партии смежных процессов, то мы делаем ресурс доступным ровно в тот момент, когда он востребован. Это приводит к резкому сокращению очередей.
Очереди сократились в 7 раз без изменения мощности ресурса и размера партии.
F14: Принцип гармоник: вкладывайте управленческие ритмы друг в друга.
Принцип широко используется в финансовой отчетности. Есть недельные, месячные, квартальные и годовые отчеты. Это позволяет объединить ритмы очень разных длительностей. Можно применять для тестирования. Расстановка приоритетов. Не пытайтесь создать сложны алгоритмы расстановки приоритетов, которые работают на очень неточных входных данных. Помните, что расстановка приоритетов важна только когда у вас длинные очереди. Если вы быстро решаете проблемы, то приоритеты вам не нужны. Хорошим образцом для расстановки приоритетов может служить операционная комната в отделении скорой помощи. Не все поступившие больные и раненые имеют одинаковую стоимость задержки. Первыми обрабатывают тяжелых больных.
F15: Принцип составления расписаний SJF: когда стоимость задержки однородная, вначале выполняйте самые короткие задачи.
Сравните площадь черной области для варианта с выбором вначале короткого проекта, а потом длинного и обратного варианта. Очевидно, что оптимально вначале делать короткий проект.
F16: Принцип составления расписаний HDCF: когда длительность задач одинаковая, вначале выполняйте задачи с высокой стоимостью задержки.
Аналогично, черная область показывает экономическую стоимость задержки.
F17: Принцип составления расписаний WSJF: когда стоимость задержки и длительность разная, используйте WSJF.
Weighted shortest job first. Первой выполняется задача с наибольшей взвешенной стоимостью задержки.
Принцип расстановки по FIFO опасен тем, что у задач неодинаковая стоимость задержки. Это используется в методе критической цепи, когда приоритет отдается проектам с наименьшим оставшимся буфером. В теории расписаний это называется MSTF (minimum slack time first). MSTF обеспечивает наилучшее соблюдение расписаний. Но MSTF не учитывает различие в стоимости задержек проектов. Когда вы отдаете ресурс проекту, вы блокируете его для других проектов. Поэтому когда вы принимаете решение какому проекту отдать ресурс, вы должны учитывать стоимость и выгоды решения.
F18: Принцип локальных приоритетов: приоритеты всегда локальные.
Если вы расставите приоритеты проектов и назначите высокий приоритет всем задачам высокоприоритетного проекта, то неважная задача этого проекта получит приоритет выше важной задачи низкоприоритетного проекта. Поэтому для эффективной расстановки приоритетов по задачам вам нужно децентрализовать контроль.
F19: Принцип карусели: когда длительность неизвестна, делите ресурс по времени.
Если мы не знаем на какое время задача заблокирует ресурс, у нас есть риск, что длительная задача надолго отложит выполнение остальной работы. А если задачу невозможно выполнить вообще? Нам надо защитить себя от таких ситуаций. В операционных системах никакой задаче не дают занимать процессор больше определенного времени. Так же и в разработке, вы должны определить кванты выделения ресурсов. Решение по поводу кванта ключевое. Если вы выберете слишком большой квант, система будет вести себя как FIFO. Если слишком маленький, то из-за частого переключения контекстов будут высокие накладные расходы. Эвристика здесь простая - 80% задач должна проходить с первого раза. Например, выделенный специалист по закупкам должен решать 80% задач проекта за свое посещение. Если среднее время выполнения проектной задачи 30 минут, то смысла приходить на 15 минут каждый день нет никакого.
F20: Принцип "бросай все и делай это": прерывайте исполнение текущей задачи только тогда, когда стоимость переключения между задачами низкая.
Надо различать перенос приоритетной работы в начало очереди и прерывание исполнения текущей задачи для исполнения приоритетной работы. Высвобождение ресурса для приоритетной работы дает наименьшее время цикла, но обычно это неэффективная практика, так как приводит к неэффективному использованию узкого места. Обычно вполне достаточно ставить задачу в начало очереди. Тогда задача не ждет в очереди, а это обычно составляет большую часть времени цикла. Но она ждет освобождения ресурса от предыдущей задачи. Если у вас малые партии, то остаточное время, когда доделывается текущая задача, обычно небольшое. Но вы можете высвобождать ресурс от выполнения текущей задачи, если переключение между задачами дешевое и быстрое.
F21: Принцип согласования работ: используйте последовательность, чтобы сопоставить задачи правильным ресурсам.
Например, если есть очередь задач на расчет механических нагрузок, в которой есть типовые задачи и есть очень сложные задачи на расчет вибрационных нагрузок. Сложные задачи может сделать только самый квалифицированный специалист. Если сложных задач нет, то специалист занимается типовыми задачами, но если в очереди задач появляется расчет вибрационных нагрузок, то мы не загружаем специалиста типовыми задачами, а отдаем ему сложную задачу.
Принципы сетевой организации продуктовой разработки.
F22: Принцип подгонки маршрутов: выбирайте и адаптируйте практики для той задачи, которую вы выполняете.
Слишком часто в продуктовой разработке мы задаем жесткую карту процессов, обязательную для любых проектов. На самом деле надо выполнять только те практики, которые добавляют экономическую пользу проекту. Допустим, у вас есть рискованное решение пользовательского интерфейса. Когда его надо протестировать? Чем раньше тем лучше. Общее правило заключается в том, что чем раньше и чем дешевле вы убираете риски проекта, тем лучше. Жесткая последовательность процессов хорошо работает для физических объектов на производстве, но глупо применять ее в разработке, где вы работаете в основном с информацией. Проект нужно разбирать на пакеты работ и пускать каждый пакет по своему маршруту. Например, сложная сборка с длительной наработкой на отказ должна быть поставлена на тест как можно раньше. Ее тестирование может начаться еще до начала разработки остальных модулей. Одна компания разбила свой метод разработки на 250 типовых модулей. Оказалось, что каждый конкретный проект применял 50-60 модулей. Это означает, что при типовой методологии 75% метода пустая трата времени и денег. Мы должны вводить стандарты не для практик верхнего уровня, наоборот, это то место, где нам нужна наибольшая гибкость решений. Нам надо вводить стандарты для отдельных типовых практик нижнего уровня. Тогда мы сможем выбирать те практики, которые полезны для конкретного проекта и исполнять их в экономически обоснованном объеме.
F23: Принцип гибких маршрутов: маршрутизируйте работу так, как выгодно конкретно сейчас.
Простая аналогия - пробки на МКАД и ТТК могут возникнуть и исчезнуть очень быстро, поэтому оптимальный маршрут меняется. Лучший путь можно определить только на короткий промежуток. В продуктовой разработке тоже бывают заторы и оптимальный маршрут меняется. Меняйте планы на более экономически эффективные, меняйте тестовые лаборатории, исполнителей, ищите подрядчиков.
F24: Принцип альтернативных маршрутов: разрабатывайте и поддерживайте альтернативные маршруты вокруг ресурсов с потенциальными задержками.
Чтобы у вас была гибкость в принятии решений, вам надо готовить запасные планы для случаев, когда ресурсы входят в состояние затора. Распространенная ошибка заключается в том, что альтернативный путь используется только для сглаживания пиковых потребностей. Правильно постоянно поддерживать на альтернативном маршруте небольшой поток работ даже если загрузка основного ресурса не составляет 100%. Это будет вашей страховкой на случай риска, если вам вдруг потребуется запасной путь. Для каких узлов нужны запасные пути? Обычно это просто сказать, наблюдая за местами возникновения очередей.
F25: Принцип гибких ресурсов: используйте гибкие ресурсы, чтобы сглаживать вариации.
Применение гибких ресурсов объяснялось ранее. Пример почты, которая использует студентов и домохозяек, чтобы разносить новогоднюю почту.
F26: Принцип позднего связывания: чем позже мы связываем ресурсы с назначениями, тем плавнее идет работа.
Чем раньше мы назначаем задачу на определенный ресурс, тем больше отклонений накапливается к моменту исполнения задачи. Чем ближе к моменту исполнения задачи мы делаем назначение, тем понятнее требования к квалификации, готовность ресурса к выполнению задачи и прочие факторы.
F27: Принцип локальной прозрачности: делайте задачи и назначения прозрачными для смежных процессов.
В классической теории расписаний задача появляется из ниоткуда, мы ничего о ней не знаем пока не начинаем ее исполнять. На деле когда задача завершается смежным процессом, мы можем готовиться к ее выполнению на нашем участке - освобождать нужные ресурсы, изучать технологию, планировать работу. Проще всего это делать с помощью досок канбан.
F28: Принцип заранее спланированной гибкости: чтобы быстро реагировать, вкладывайтесь в подготовку.
Гибкость - это не только настрой ума, но и результат предварительного планирования и заранее подготовленных решений. Мы не просто решаем, что отказываемся от каких-то требований, мы заранее их классифицируем (например, с помощью MoSCoW). Если мы хотим привлечь подрядчиков, то надо держать их в курсе хода нашего проекта. Например, на военных кораблях нет пожарной бригады, роль пожарных там выполняют обычные матросы. Но их обучают, регулярно тренируют и готовят к выполнению этой роли.
F29: Принцип централизации ресурсов: при правильном использовании централизованные ресурсы могут уменьшить очереди.
Централизованные ресурсы помогают справиться с вариативностью загрузки.
Вы не должны загружать централизованные ресурсы до высоких уровней, иначе они не смогут реагировать на запросы. Поэтому ни в коем случае не вводите KPI по эффективности централизованных ресурсов, это приведет к их неэффективности.
F30: Принцип приведения потока в порядок: уменьшайте вариативность перед узким местом.
Множество разработчиков считают, что узкие места определяют производительность системы. Считать, что скорость процесса определяется скоростью самого медленного звена очень привлекательно. Оптимизация экономики процесса задача куда более сложная, чем максимизация прибыли. Экономика узкого места определяется длиной очереди. Но и размер этой очереди определяется не только скоростью работы узкого места. В принципе Q5 я указывал, что скорость очереди определяется четырьмя факторами - средней скоростью работы узкого места, его загрузкой, вариативностью процесса, вариативностью прибытий. Вариативность прибытий зависит от вариативности предыдущего процесса. Это означает, что мы можем изменить очередь узкого места не меняя его производительность. Это достигается за счет стандартизации потока, см. Q8. Это похоже на ламинарный поток в физике, мы хотим именно этого.
Принципы быстрой обратной связи
В левой части функции выплат быстрая обратная связь уменьшает потери, в правой части увеличивает доходы. В чем смысл системы контроля? Во влиянии на прокси-переменные, которые заметно влияют на экономику.
Например, если вы выбираете, на что повлиять - на расходы на разработку, размер очереди или время цикла, что вы выберете? Расходы на разработку влияют на экономику проекта слабее всего. Размер очереди лучше времени цикла потому что это опережающий показатель.
FF1: Принцип максимального влияния на экономику: обращайте внимание на параметры процессов и проектов, которые больше всего влияют на экономику предприятия.
Если 10% увеличение расходов на разработку стоит нам 1% прибыли, а 10% увеличение стоимости продукции стоит 50% прибыли, то надо фокусироваться на контроля стоимости единицы продукции, а не контроле расходов.
FF2: Принцип эффективного контроля: контролируйте параметры, которые сильно влияют на экономику и которые можно эффективно контролировать.
Средняя цена продажи почти всегда сильно влияет на прибыльность проекта, но на нее сложно влиять. Как влиять на среднюю цену продажи, см. учебник "Ценовое преимущество" Завады. А вот на себестоимость изделия вы повлиять можете, и она влияет на прибыльность почти так же сильно, как и цена продажи. Делайте анализ чувствительности экономической модели проекта, чтобы понять какие у вас критические факторы успеха.
FF3: Принцип опережающих индикаторов: выбирайте переменные, которые предсказывают поведение системы в будущем.
Опережающие индикаторы помогают нам реагировать на проблемы, которые еще не наступили. Стоимость корректировки еще не слишком высокая. Например, один крайне опытный руководитель проекта говорил, что он больше внимания обращает на даты начала задач, чем на даты окончания. В чем была логика? Он сказал, что в его организации есть очень значимая взаимосвязь между тем, вовремя ли была начата задача и правильный ли ресурс был на нее назначен и своевременным окончанием задачи. И наоборот, задачи, которые начинались с запозданием либо с неправильным ресурсом, отставали от графика. Он использовал эту связь чтобы вовремя реагировать на проблемы. Например, поменять приоритеты, поменять исполнителя, изменить ограничения проекта.
FF4: Принцип сбалансированных заданных режимов: устанавливайте минные растяжки в точках нулевой экономической пользы.
Нельзя просто игнорировать превышение расходов на разработку даже если они слабо влияют на прибыльность проекта. Вам все равно нужны контрольные точки, когда вы скажете, что дальнейший рост расходов неприемлем. Надо контролировать переменные со слабыми экономическими зависимостями, если их изменение превышает определенный порог.
Компании допускают три критические ошибки: - контролируют прокси-переменные без учета их влияния на экономику; - ранжируют эти переменные по значимости, например, говорят, что расписание важнее расходов. Это означает, что небольшой сдвиг расписания важнее значительного перерасхода бюджета, что не имеет экономического смысла. У переменных нет приоритетов, у них есть передаточные функции. - они контролируют процентные отклонения этих переменных, а не экономические последствия. Например, одна компания установила предел задержки расписания 4 недели, но т.к. стоимость задержки проектов различалась в десятки раз, смысла в таких границах показателя не было.
FF5: Принцип движущейся цели: знайте, когда надо устанавливать динамические цели.
Многие компании создают экономически опасные системы показателей, т.к. не понимают различий между статическими и динамическими целями. Довольно часто системы показателей настроены на минимизацию отклонений от заранее установленной неизменной цели. Разработчики предполагают, что выполнение плана всегда хорошо, а отклонение от плана всегда плохо. Если вы ставили цель в условиях значительной неопределенности, то такой подход может быть для вас губительным. Возьмите в качестве примера системы наведения межконтинентальных баллистических ракет и ракет воздух-воздух. В первом случае цели неподвижные и вам нужно попасть в них очень точно, а во втором точность должна быть достаточной, но зато цель активно маневрирует. В разработке нам надо постоянно снижать разницу между текущим состоянием и наилучшим с экономической точки зрения состоянием.
FF6: Принцип оппортунизма 1: эксплуатируйте незапланированные экономические возможности.
Когда вы сфокусированы на уменьшение отклонений от плана, вы рассматриваете только риски проекта. Но в разработке не все отклонения плохие. Иногда мы наоборот, должны стараться еще сильнее отклониться от плана, если мы на этом заработаем. К примеру, встроенные в машины МР3 проигрыватели появились только несколько лет спустя после того, как они появились на рынке. Соглашусь, что добавить МР3 проигрыватель в машину может быть сложно, но насколько сложно было добавить штекер для подключения внешнего плеера? Подозреваю, не очень сложно и не так уж дорого, но никто этого не сделал. Продавцы автомобильных аксессуаров подсуетились куда раньше, чем сами автопроизводители. Все выполняли изначальный план. Помните, что обратная связь улучшает прибыль двумя способами - уменьшая расходы и увеличивая доходы.
FF7: Принцип обратной связи, направленный на снижение длины очереди: быстрая обратная связь помогает убирать очереди.
Процесс с быстрой обратной связь уменьшает количество незавершенной работы.
Это самовоспроизводящийся процесс.
FF8: Принцип быстрого обучения: используйте обратную связь, чтобы ускорить обучение и сделать его эффективнее.
История с соревнованием новозеландской и американской яхт. Команда Новой Зеландии сделала две яхты, вносила небольшие изменения в конструкцию одной и сравнивала их в открытом море. Американская команда использовала симуляции и динамическую трубу. В результате команда НЗ сделала кучу маленьких усовершенствований, которые были заметны только при реальном сравнении яхт. И они выиграли. Вот как важно вкладываться в создание хорошей тестовой среды.
FF9: Принцип бессмысленных измерений: не все то, что измеряется, исполняется.
Когда я ходил в бизнес-школу, профессора учили меня: "Что измеряется, то исполняется". Потом я стал обращать внимание на то, что же происходило на самом деле. И мне пришла в голову аналогия с весами для похудения. Если вы заведете весы и будете вставать на них каждый день, далеко не факт, что вы похудеете. Выбор показателя - важное дело, но это не все дело.
FF10: Первый принцип гибкости: нам не нужен план на длительный срок если у нас малый радиус поворота.
Танкеры идут в тумане очень медленно потому что им требуется много времени на остановку. Катер может ездить в тумане почти так же быстро, как и без тумана. В разработке то же самое. Мегапроектами сложно управлять потому что они очень большие. История с В-1. Чтобы перенаправлять программы, нужен достаточный запас по свободным ресурсам, поэтому организации со 100% загрузкой имеют малую маневренность.
FF11: Принцип организации обратной связи по размеру партии: малые партии приводят к быстрой обратной связи.
При прочих равных процесс с малыми партиями быстрее реагирует на изменения. Разработка невозможна без принятия рисков, поэтому нам надо уметь быстро останавливать неудачные ветки разработки.
FF12: Принцип отношения сигнал-к-шуму: чтобы обнаруживать слабые сигналы, надо снижать уровень шума.
Когда вы снижаете размер партии, вы усиливаете влияние шума. Каждый раз, когда мы уменьшаем партию в два раза, мы усиливаем вариативность на 40%. Например, если вам надо определить, фальшивая у вас монета или честная, и вы подбрасываете ее в воздух. Если у вас есть 100 бросков, вы можете сказать наверняка, а если вы подбрасываете 2 раза, то шансов ошибиться очень много. Поэтому когда создаете тестовую среду, очень аккуратно согласовывайте условия тестирования.
FF13: Второй принцип принятия решений: контролируй не принятие решения, а экономическую логику принятия решения.
Вернемся к примеру с Боингом-777. Вес воздушного судна - критический фактор успеха программы. Означает ли это, что руководитель программы должен участвовать в принятии каждого из тысяч решений по весу? Нет, ему достаточно задать ключевой принцип, по которому эти решения должны приниматься. А вот если только руководство понимает логику принятия решений, то что должны сказать инженеры? Что это с виду странное решение в силу непонятных нам причин лучшее для нашей компании, но объяснения почему оно лучшее имеют мистическую и эзотеричную природу? Если у вас нет четких прописанных правил принятия решений, то у вас в компании развивается магическая культура, и каждый начинает считать, что решения можно принимать не основываясь на фактах и анализе.
FF14: Принцип локальности обратной связи: при любой возможности делайте обратную связь локальной.
Локальная обратная связь работает быстрее общей. Сравните быстродействие локальных лимитов WIP с общим ограничением ТОС. Мы разбирали этот пример ранее и увидели, что канбан реагирует быстрее ТОС. Это пример того, как локальная обратная связь уменьшает накопление отклонений. Но это не единственная проблема, т.к. общая обратная связь может привести к нестабильному поведению системы. Когда мне было 18 лет, я встал за штурвал авианосца. И понял, что рулить им намного сложнее, потому что время от момента поворота штурвала до смены курса проходит очень много. В результате крупные корабли могут ходить по морю зигзагами, если за рулем стоит новичок.
FF15: Принцип предохранительного клапана: устанавливайте четкий заранее определенный предохранительный клапан.
Настройка предохранительного клапана дело тонкое. Если поставить порог открытия и закрытия слишком близко, то клапан будет часто включаться и выключаться. Если порог слишком низкий, то система будет зря терять давление. Пример такого клапана - это отказ от требований или функциональности системы. Но убирать функциональность или требования надо не по одному, а сразу группой, чтобы откорректировать ход проекта так, чтобы не пришлось убирать требования еще и на следующей неделе.
FF16: Принцип множественных контрольных цепей: вставляйте петли быстрой обратной связи внутрь медленных петель.
Медленные петли обратной связи нужны для оптимизации всего процесса, петли быстрой обратной связи нужны для сглаживания вариаций. Например, у нас есть централизованный ресурс для быстрого реагирования. Мы принимаем решение по его распределению каждые 24 часа. А раз в квартал определяем сколько человек нужно уволить, а сколько нанять в этот отдел.
FF17: Принцип контролируемых отклонений: удерживайте отклонения в контрольных границах.
Поведение системы в контрольных границах предсказуемое. Вне этих пределов оно может стать нестабильным. Если очередь в отдел тестирования короткая, то его работа не вносит непредсказуемых задержек в проекты разработки. Но если очередь вырастает, то начинаются разборки кто будет тестироваться первым, инженеры увеличивают объем тестируемых партий, в результате процесс тестирования входит в состояние затора. Поэтому и нужны WIP лимиты, которые с помощью отрицательной обратной связи ограничивают загрузку отдела.
FF18: Принцип упреждающего управления: заранее предупреждайте о прибытии большого количества работы для уменьшения очередей.
За счет упреждающего управления вы снижаете случайность прибытий. Это использование принципа отрицательной ковариации. Например, если мы ожидаем, что скоро в отдел тестирования прибудет большое количество тестовых образцов. Понятно, что вырастет дорогая очередь, поэтому для руководителя отдела тестирования логично будет взять переработки и сработать текущую очередь заданий до нуля, чтобы уменьшить стоимость очередей. Аналогично поступают сети быстрого питания перед обедом. Они нарабатывают запас ходовых блюд, чтобы быстрее обслуживать приходящий поток. Вопрос - какую информацию передавать смежным процессам дальше по цепочке? Ответ - информацию с наибольшей экономической ценностью. Допустим, у вас есть 100 чертежей деталей. Из них только 10 будет очень сложно изготовить, остальные типовые. На этих 10 чертежах есть всего десяток атрибутов, которые и определяют сложность изготовления. Эти параметры и нужно определить в начале разработки и заранее передать производственному отделу, чтобы они готовили процесс к изготовлению партии. Помните, что информация должна течь в обоих направлениях.
FF19: Принцип совместного размещения: когда люди сидят вместе, это улучшает почти все аспекты общения.
Очное общение самое быстрое и точное. Когда люди сидят за соседними столами, им легче общаться и в таком общении используется принцип малых партий. Падает стоимость общения, ускоряется обратная связь. За последние 20 лет я опросил тысячи разработчиков, работали ли они в командах, где инженеры, маркетинг и производство сидели на расстоянии 15 метров друг от друга. Тем кто имел такой опыт я задавал следующий вопрос: "Если бы скорость разработки была важна, посадили ли бы вы людей вместе?" Только один разработчик сказал, что он бы все равно работал в одиночестве. Он объяснил это так: "Другие слишком много знали бы о том, чем я занимаюсь". К сожалению, большинство менеджеров и инженеров никогда не работали в близко размещенных командах и они не понимают, что отказываются от простого и мощного инструмента улучшения производительности команды. Если у вас есть возможность разместить команду в одном месте, сражайтесь за нее, результат себя оправдает.
FF20: Принцип расширения полномочий при организации обратной связи: быстрая обратная связь дает ощущение контроля.
Мозг человека строит причинно-следственные связи в том случае, когда между событием и последствием проходит немного времени. Если мы нажимаем на кнопку и загорается свет, то в следующий раз мы тоже будем жать на кнопку. Если же свет загорится только через 5 секунд после нажатия, мы будем думать, что причина была в другом. Когда люди видят, что их действия влекут последствия, они начинают менять свое поведение. Если вы дадите им возможность контролировать поведение системы, они будут брать на себя ответственность и управлять ей. Вместо того, чтобы быть жертвой монолитной системы они становятся хозяевами в своей предметной области. Быстрая обратная связь дает людям чувство контроля и это только усиливает их желание что-то менять.
FF21: Принцип “не спеши выполнять указания начальства”: большие очереди не создают ощущения срочности задачи.
Быстрая связь создает чувство важности и срочности происходящего, медленная обратная связь действует обратно. А длинные очереди замедляют обратную связь. В длинных очередях проходит много времени от момента, когда задача была поставлена до момента, когда она была выполнена. В результате мы видим, что мы сделали работу, но ее результат никому не нужен, и отсюда делаем вывод, что можно и не торопиться. Экспедирование задач ухудшает ситуацию. Потому что экспедитор перемещает задачу с срывающимся дедлайном вперед по очереди. А т.к. близкий дедлайн является пропуском в мир приоритетного обслуживания, то зачем торопиться? Можно опаздывать и нас протолкнут те, кому эта задача нужна выполненной. Когда мы работаем с малыми очередями, задачи чаще всего обрабатываются по принципу FIFO. Между постановкой задачи и началом работ по ней проходит совсем немного времени и это повышает чувство срочности, мы торопимся показать по ней результат.
FF22: Принцип усиления: человеческий фактор усиливает большие отклонения.
Небольшие отклонения мотивируют людей придерживаться плана, а на большие отклонения люди реагируют по принципу: "Мы все равно опаздываем, так что зачем спешить". Поэтому небольшие отклонения позволяют повышать эффективность, люди работают лучше и эффективнее, а большие отклонения их совершенно демотивируют. Если у инженера есть три задачи по трем проектам. Два проекта лишь немного отстают от графика и один проект идет с серьезным опозданием. Над какими задачами он будет трудиться больше? Конечно над первыми двумя, ведь если он сделает два проекта из трех, то его не уволят за завал одного, который и так серьезно отставал. А если он будет больше работать над сильно отстающим, то два других отстанут еще больше, и это вызывает у инженера серьезный дискомфорт. Такое решение не имеет ничего общего с экономикой, оно чисто психологическое. Отсюда вывод - не допускайте серьезных отклонений от оптимальной рабочей точки. Система расбалансируется и ее производительность резко падает.
FF23: Принцип перекрывающихся измерений: чтобы поведение людей было согласованным, вознаграждайте людей за работу других.
Некоторые организации создают четкие зоны ответственности подразделений. Здесь и за это отвечаем мы, тут и за то отвечают другие. Показатели эффективности в таких компаниях отвечают принципу МЕСЕ (взаимоисключающие и совместно исчерпывающие). Это элегантно выглядит, но в основе такого управления лежит плохое понимание психологии организации. В системах с участием человека полезно вознаграждать людей за то, что им неподконтрольно. Одна фирма вознаграждает партнеров за их личный вклад, результат филиала и общий результат всей фирмы. При такой организации партнеры активно поддерживают друг друга. Вопрос баланса личных и общих целей деликатный, они не должны перевешивать друг друга.
FF24: Принцип внимания: время ценится больше, чем деньги.
Хотя эта книга вся крутится вокруг экономики, лично я не верю, что деньги - это самое главное. Самое ценное всегда время. Наша организация перекодирует наши ценности в денежное выражение, что мы считаем важным, на то и тратим деньги. Посвятить личное время какому-то проекту - это самый эффективный способ показать его значимость. Это верно как на работе, так и в воспитании детей. Если мы хотим показать значимость вопроса, мы должны потратить на него время. Если вопрос обсуждается в начале каждого совещания, то организация будет считать его важным. Если вы ставите его в конец повестки и говорите об этом изредка, то это автоматически считается неважным.
Так какие же показатели важны для разработки?
DIP turns = DIP/revenue (оборачиваемость дизайна в работе) Design-in-process inventory (DIP) равен суммарным инвестициям в незавершенный дизайн. Самый практичный способ померить его это сложить весь освоенный объем проекта на отчетную дату. Быстрая оценка объема работ:
Принципы децентрализации
Военные столетиями добивались правильного баланса централизации и децентрализации. Они понимают преимущества и недостатки децентрализации и проверили свои идеи в бою. Когда их идеи не работали, они погибали. Поэтому современная армия демонстрирует передовые модели распределенных организаций с централизованным контролем. Это противоречит убеждениям, заложенным Голливудом, что армия и флот - это организации с беспрекословным подчинением и односторонним потоком приказов и распоряжений. В реальности армия сильно полагается на инициативу подчиненных. Задача армейских подразделений - реагировать на меняющуюся обстановку, а не следовать плану. Современные морпехи смотрят на театр военных действий как на место, где сторона, лучше другой использующая неопределенность, выигрывает. Разработчики продуктов точно также как и морпехи готовят планы своих действий. Отличия в другом. Разработчики отслеживают исполнение планов и следят за отклонениями. Они тратят усилия и деньги на корректировку отклонений. Они считают любое отклонение от плана плохим. Морпехи же считают, что поле битвы предоставляет как внезапные препятствия, так и незапланированные возможности. У морпехов всегда есть резерв, который они могут использовать, чтобы реализовать эту возможность. Морпехи верят, что план был наилучшим на тот момент, когда его готовили, но если они узнают что-то важное в ходе действий, то будут действовать по-другому даже если в плане этого не было. Т.к. действовать в таких ситуациях надо быстро, они отдают полномочия действовать вниз. Они бы рассмеялись над попытками разработчиков справиться с неопределенностью с помощью еще более подробных планов. Защита и нападение организованы по разному. Главное для атакующих - создать концентрацию на участке прорыва 3 к 1. Обороняющиеся вынуждены держать больший периметр, они распыляют свои силы. Поэтому придумали решение строить оборону слабым кольцом, чтобы только задержать наступление на время подтягивания резервов к месту прорыва. Атакующие создают видимость атаки по многим направлениям. Такие боевые действия называются маневренной войной. Ни 100% централизация ни 100% децентрализация не являются ответом на вызовы современной организации. Ответ как всегда будет сложным.
D1: Второй принцип ускользающих возможностей: децентрализуйте контроль для проблем и возможностей, которые быстро стареют.
Некоторые проблемы и возможности быстро портятся. Возможности исчезают, а проблемы резко ухудшаются. Примером такой проблемы может быть пожар, пока он небольшой, его легко потушить, но если пламя разгорелось, то погасить его сложно. И есть проблемы, которые ухудшившись до определенного предела дальше уже не нарастают. Примером может служить вложение в акции. Если вы вложили 1,000 долларов и они подешевели на 90%, то максимум, что вы можете еще потерять - это еще 100 долларов. Возможности тоже могут быстро исчезать. Например, IBM запоздала с выпуском 4-дюймовых дискет и проиграла конкуренцию Sony и HP с дисками 3,5 дюйма. Чтобы вовремя решать скоропортящиеся проблемы и получать быстро исчезающие выгоды, надо отдавать полномочия действовать вниз, и располагать резервами, которые позволяют быстро действовать. Вернемся к примеру с пожарами. Мы размещаем огнетушители и разрешаем людям ими пользоваться не спрашивая разрешения, мы обучаем людей основам тушения пожаров и регулярно проводим учебные эвакуации.
D2: Принцип масштаба: централизуйте контроль для решения проблем, которые возникают редко, для крупных проблем или у них есть эффект масштаба.
Если пожар большой, огнетушители вам не помогут, вам нужен пожарный расчет, машина и много воды. Мы не можем держать небольшой пожарный гидрант у каждого дома, нам не хватит мощности для тушения пожара. Мы организуем городскую службу тушения пожаров с несколькими расчетами. Мы понимаем, что у работы по тушению пожаров высокая стоимость задержки и поэтому даем им приоритет при проезде. В продуктовой разработке мы концентрируем экспертов в центральном офисе, а не раздаем их по программам. Этим мы добиваемся быстрого реагирования и как побочный эффект имеем согласованное применение практик между программами. Это хорошо работает в продажах и закупках, где важны личные отношения и связи. Централизованный и правильно мотивированный офис обычно легко обставляет проектные команды.
D3: Принцип многоуровневого контроля: подстраивайте схему контроля по мере появления информации.
Есть два подхода к контролю в условиях неопределенности. Подход 1.Медицинская сортировка по уровню тяжести больного или раненого. Некоторые умрут, что бы вы не делали, они не получают помощи. Некоторые будут жить даже если им не оказать помощь, они тоже не получают помощь. Драгоценные ресурсы расходуются на тех, чьи жизнь и здоровье зависит от получения помощи. Выделите классы обслуживания и присвойте их задачам. Обрабатывайте очередь в зависимости от классов задач. Если задача висит в очереди давно, повышайте ее класс обслуживания. Управляйте очередями, но не задачами. Если проблема не решена в течении определенного срока, пересылайте ее руководству. Так вы отсеиваете задачи, которые непосильны локальным ресурсам и требуют применения крупнокалиберной артиллерии.
D4: Принцип оппортунизма - 2: приспосабливай план к незапланированным препятствиям и возможностям.
В принципе FF5 мы сделали различие между динамическими и статическими целями. Мы сосредотачиваемся на соответствии плану если цели статичные. Если цели динамичные, мы постоянно адаптируемся. Мы пытаемся сделать лучшие возможные выборы в свете поступающей информации. Никакой план не выдерживает столкновения с битвой. Военные планирует не для того, чтобы потом исполнить план, они планируют для того, чтобы поддерживать согласованность. План создает базис синхронизации сложных изменений. Если мы хотим перенести вторжение на 1 день, то нужно перенести сроки тысячи мероприятий, которые обеспечивают это вторжение. У них у всех разные сроки подготовки и исполнения и вам надо быстро все пересогласовать. Для этого и нужен план. В продуктовой разработке мы все время получаем новую информацию по востребованности того или иного функционала и стоимости и сложности его разработки и тестирования. Глупо игнорировать эту информацию и придерживаться решений, если они перестали быть обоснованными.
D5: Принцип виртуальной централизации: будьте готовы стянуть распределенные команды в центр.
В некоторых случаях неэффективно держать централизованные ресурсы все время. И тогда вы отдаете их на места. Но будьте готовы быстро стянуть их обратно в центр, если это будет нужно. В продуктовой разработке для решения серьезных проблем программы вы можете собрать группу наиболее опытных и эффективных людей, которые быстро справятся с проблемой и уйдут обратно на места.
D6: Принцип неэффективности: неэффективность децентрализации может окупать пользу, которую приносит быстрое реагирование.
В тех случаях, когда скорость ответа важна, мы можем быть готовы потерять эффективность централизованных ресурсов, но получить быстрое реагирование на проблемы. Например, если скорая приезжает в среднем за 9 минут, то пациент в состоянии клинической смерти погибнет, если никто не сделает ему искусственное дыхание и массаж сердца. Поэтому не считайте по умолчанию, что на первом месте всегда эффективность. Используйте экономику, чтобы получить ответы на вопросы.
Темная сторона децентрализации - несогласованность. Если локальные игроки делают локально обоснованные выборы, на системном уровне вы все равно можете иметь огромные проблемы. Как это делают морпехи?
D7: Принцип согласованности: согласованность приносит больше выгод, чем локальное совершенство. "Один варвар может побить одного римского легионера, но римский легион всегда побьет варварскую армию". Сила римской армии была в согласованности действий и концентрации ресурсов на узком участке. В продуктовой разработке нам не нужно получить преимущество в 1% по 15 функциям, нам нужно получить 15% улучшение ключевой функции, и тогда это будет конкурентным преимуществом продукта. Иногда надо концентрировать все ресурсы на нескольких ключевых задачах и это повлияет на восприятие успешности проекта и продукта.
D8: Принцип боевого приказа: укажите конечное состояние, его назначение и минимально возможные ограничения.
В армии есть понятие боевого приказа (mission order). Люди, не знакомые с маневренной войной, часто думают, что боевой приказ указывает подразделению что делать, когда это делать, какими силами решать задачу, и каким замыслом операции надо руководствоваться. Это кажется довольно логичным, но боевые приказы работают ровно противоположным образом. Боевой приказ определяет намерение командования, замысел операции. Он не сильно ограничивает способ исполнения замысла. Замысел всегда больше чем результат конкретной битвы. Приказ сообщает почему операция производится, но не как или что надо сделать. Морпехи считают, что без боевого приказа указания неполны, т.к. вы не можете понять, зачем их отдают. Когда намерение ясно, вы можете выбрать средства и способы исполнения задачи. Намерение командования устойчиво и не подвержено постоянным изменениям, в отличие от текущих планов. Миссия проекта должна четко указывать почему выполняется проект, но не как и то надо в нем сделать.
D9: Принцип границ: установите четкие роли и границы.
Посмотрите, как дети гоняют футбол во дворе. Главное для них ударить по мячу, но проблема в том, что после того, как по мячу ударят, его некому ловить, потому что все пытаются бить по мячу. Военные работают не так. Они устанавливают четкие роли и ответственность в совместной деятельности. Нельзя допускать ни чрезмерного перекрытия зон ответственности ни больших областей, за которые никто не отвечает. В продуктовой разработке плохо определенные роли приведут к большому количеству уточнений, запросов и собраний. Если решение принимают два человека, то процесс принятия решения будет намного быстрее и проще, чем если определять цвет будет комиссия из 20 человек. Руководствуйтесь фразой, которую я однажды слышал: "Если об этом болит твоя голова, то я даже беспокоиться не буду".
D10: Принцип основных усилий: определите основную задачу и подчините ей все остальные.
Маркетинговые исследования показывают, что только небольшое количество характеристик продукта имеют решающее значение. Из 200 фич от 4 до 6 будут учитываться при принятии решений. Все остальные 195 должны быть подчинены этим 5 критичным.
D11: Принцип динамической согласованности: основное направление может быстро поменяться, если изменились условия.
Не игнорируйте поступающую информацию, не привязывайтесь к принятым решениям и сделанным вложениям. Считайте деньги.
D12: Второй принцип гибкости: развивайте способность быстро менять фокус.
Цикл OODA Бойда. F-86 против Миг-15, победы 10 к 1 за счет лучшего обзора из кокпита.
В продуктовой разработке для быстрой смены курса нам нужны хорошо сыгранные маленькие команды (Скрам), а не большие организации. У них должен быть резерв по мощности, вы не сможете выжать из людей больше, если они уже впахивают по 80 часов в неделю. Надо правильно проектировать архитектуру, обеспечивать разбиение структуры продукта на части, которые можно разрабатывать независимо.
D13: Принцип координации среди коллег: тактическая координация должна быть локальной.
Морпехи поддерживают согласованность в распределенной организации за счет постоянного личного общения. Т.к. они воспитаны одной школой и часто общаются друг с другом, они понимают, чего можно ждать от товарищей и верят в них. Эта вера не слепая, а основана на свидетельствах и фактах. Общение у морпехов отнюдь не иерархичное, у них очень много горизонтальных прямых связей. Например, морпех, который запросил огневую или воздушную поддержку, общается напрямую с исполнителем, а не идет по всей цепочке командования.
И это очень отличается от типичной иерархичной организации продуктовой разработки с детальными планами и проектными офисами и запросами, отчетами и другими вещами, сильно замедляющими работу.
D14: Принцип гибкости в планах: используйте простые модульные планы.
Все вышесказанное не означает, что планов нет вообще. Все, что можно запланировать, планируется. Например, есть планы коммуникации - на каких частотах, какие запасные каналы будут, позывные и прочее. Тщательно планируется загрузка транспорта и порядок высадки. Планы состоят из простых модулей, которые собираются в последовательности. Это приводит к тому, что можно составить множество различных планов из этих модулей. Такая модульность обеспечивает быстрое реагирование на меняющиеся обстоятельства и при этом поддерживается согласованность.
D15: Принцип тактических резервов: выделите часть резервов на места.
Резервы должны быть на каждом управленческом уровне, иначе как реагировать на изменения? В продуктовой разработке эти резервы - это располагаемое рабочее время у ресурсов и бюджеты. Это похоже на организацию памяти персональных компьютеров - есть кэш процессора, оперативная память и жесткий диск.
D16: Принцип раннего боевого контакта: столкнитесь с проблемой как можно раньше и плотнее.
Чтобы справиться с рисками проекта разработки надо не только оценить их во время планирования. Надо экспериментально проверять концепцию продукта. Ничто не заменит раннего рыночного тестирования. Обычное проектирование сверху вниз сталкивается с проблемами слишком поздно.
D17: Принцип децентрализации информации: чтобы распределить принятие решений, распространяйте информацию как можно шире.
У морпехов стандарт коммуникации подразумевает понимание замысла командования на два уровня вверх от твоего. В коммерческих компаниях мы скрываем информацию и не даем ему никому. Потому то децентрализация и не работает. Если хотите, чтобы проект быстро двигался, распространяйте всю важную информацию всем, кому она может понадобиться.
D18: Принцип частоты отклика: мы не можем реагировать быстрее, чем нам позволяет наша частотная характеристика.
В продуктовой разработке нам надо повышать скорость принятия решений. Нам надо уменьшать количество вовлеченных людей и уровней руководства. Нам нельзя упираться в ограниченную пропускную способность топ-менеджмента и надо принимать большинство решений внизу организационной иерархии. Нам нужно спустить вниз полномочия, информацию и дать возможность практиковаться в принятии решений. Без практики принятия решений и неизбежных ошибок низы не примут передаваемой им ответственности. Теория автоматического управления говорит нам, что скорость регулирования не может быть быстрее, чем позволяет частотная характеристика обратной связи.
D19: Принцип качества сервиса: когда время отклика важно, измеряйте время отклика.
Если задача, которую выполняет группа поддержки лежит на критическом пути, то задержка в ее ответе стоит очень дорого. Но при этом часто бывает, что группам поддержки ставят KPI по эффективности, а не по задержке ответов. Поэтому тщательно думайте при выборе показателей. Можно создавать соглашения об уровне сервиса.
D20: Второй принцип рынка: используйте внутренние и внешние рынки для децентрализации контроля.
Сегодня продуктовые организации платят за премиальный сервис только при покупках на внешних рынках. Внутренние премиальные сервисы обходятся им столько же, сколько обычные. Не обязательно использовать для этого деньги, это могут быть любое ограниченное количество знаков. Одна компания использовала для этого кофейные кружки. За каждой кружкой могла быть закреплена задача, которая получала приоритет в обработке. Т.к. кружек было мало, приоритетных задач тоже было мало.
D21: Принцип восстанавливающейся инициативы: взращивание инициативы побуждает нас проявлять инициативу.
Морпехи считают инициативу самым главным лидерским качеством. Для них безынициативность более опасное явление, чем неудачное решение. Чем чаще вы довзоляете инициативу, тем чаще люди ее проявляют.
D22: Принцип очного общения: используйте скорость и плотность личного общения.
См. Брюса Тулгана "Все начальники делают это".
D23: Принцип доверия: доверие появляется только в результате опыта общения.
Распределенные команды построены на доверии. Доверие должно быть вертикальным и горизонтальным. Теория социальных ожиданий. Малые партии позволяют испытать процесс и людей много раз, это улучшает доверие.
Selected Bibliography For readers who wish to acquire a deeper understanding of the science underlying this book, I recommend the following references. Most of these books are textbooks and will require slow, methodical reading. Computer Operating Systems Silberschatz, Abraham, Peter Baer Galvin, and Greg Gagne. Operating Systems Concepts. New York: John Wiley & Sons, 2008. Tanenbaum, Andrew S. Modern Operating Systems. Englewood Cliffs, NJ: Prentice Hall, 2007. Control Engineering Nise, Norman S. Control Systems Engineering. New York: John Wiley & Sons, 2004. Ogata, Katsuhiko. Modern Control Engineering. Englewood Cliffs, NJ: Prentice-Hall, 2001. Data Communications Networks Comer, Douglas E. Internetworking with TCP/IP Volume I: Principles, Protocols and Architectures. Upper Saddle River, NJ: Prentice Hall, 2005. Kurose, James F., and Keith W. Ross. Computer Networking: A Top-Down Approach. Boston: Addison-Wesley Publishing Co., 2008. Peterson, Larry L., and Bruce S. Davie. Computer Networks: A Systems Approach. New York: Elsevier, 2007. Finance and Economics Luenberger, David G. Investment Science. New York: Oxford University Press, 1998. Information Theory Pierce, John R. An Introduction to Information Theory: Symbols, Signals & Noise. New York: Dover, 1980. Shannon, Claude E., and Warren Weaver. The Mathematical Theory of Communications. University of Illinois Press, 1963. Maneuver Warfare Coram, Robert. Boyd: The Fighter Pilot Who Changed the Art of War. New York: Little Brown & Co., 2002. Isely, Jeter A., and Philip A. Crowl. The U.S. Marines and Amphibious War: Its Theory and Its Practice in the Pacific. Princeton: Princeton University Press, 1951. Lind, William S. Maneuver Warfare Handbook. Boulder: Westview Press, 1985. Marine Corps Doctrinal Publication 1, Warfighting. Secretary of the Navy, 1996. Marine Corps Doctrinal Publication 1–3, Tactics. Secretary of the Navy, 1997. Marine Corps Doctrinal Publication 6, Command and Control. Secretary of the Navy, 1997. Manufacturing Hopp, Wallace J., and Mark L. Spearman. Factory Physics. New York: Irwin/McGraw-Hill, 2007. Monden, Yasuhiro. Toyota Production System: An Integrated Approach to Just-in-Time. Engineering & Management Press, 1998. Ohno, Taiichi. The Toyota Production System: Beyond Large-Scale Production. Cambridge, MA: Productivity Press, 1988. Shingo, Shigeo. A Study of the Toyota Production System. Cambridge, MA: Productivity Press, 1989. Operations Research Conway, Richard W., William L. Maxwell, and Louis W. Miller. Theory of Scheduling. Mineola, NY: Dover, 1967. Hillier, Frederick S., and Gerald J. Lieberman. Introduction to Operations Research. New York: McGraw-Hill, 2007. Taha, Hamdy A. Operations Research: An Introduction. New York: Macmillan Publishing Co., 2006. Probability and Statistics Allen, Arnold O. Probability, Statistics and Queueing Theory: With Computer Science Applications. New York: Academic Press, 1978. Feller, William. An Introduction to Probability Theory and Its Applications: Volume I. New York: John Wiley & Sons, 1968. Hogg, Robert V., and Elliot A. Tanis. Probability and Statistical Inference. New York: Macmillan Publishing Co., 1983. Larsen, Richard J., and Morris L. Marx. An Introduction to Mathematical Statistics and Its Applications. Upper Saddle River, NJ: Prentice Hall, 2005. Pfeiffer, Paul E. Concepts of Probability Theory. New York: Dover, 1978. Ross, Sheldon M. Introduction to Probability Models. New York: Elsevier, 2007. Trivedi, Kishor S. Probability & Statistics with Reliability, Queuing, and Computer Science Applications. New Dehli: Prentice-Hall of India, 2001. Walpole, Ronald E., Raymond H. Myers, Sharon L. Myers, and Keying Ye. Probability & Statistics for Engineers and Scientists. Upper Saddle River, NJ: Prentice Hall, 2002. Queueing Theory Gross, Donald, John F. Shortle, James M. Thompson, and Carl M. Harris. Fundamentals of Queueing Theory. New York: John Wiley & Sons, 2008. Hall, Randolph W. Queueing Methods for Services and Manufacturing. Englewood Cliffs, NJ: Prentice Hall, 1991. Kleinrock, Leonard. Queueing Systems Volume I: Theory. New York: John Wiley & Sons, 1975. Kleinrock, Leonard. Queueing Systems Volume II: Computer Applications. New York: John Wiley & Sons, 1976. Morse, Philip M. Queues, Inventories, and Maintenance: The Analysis of Operational Systems with Variable Demand and Supply. New York: John Wiley & Sons, 1958. Saaty, Thomas L. Elements of Queueing Theory with Applications. New York: Dover, 1983.
