Дэвид Андерсон - Канбан. Альтернативный путь в Agile
Эффективность поставки
Уравнение, оценивающее эффективность поставки, можно вывести двумя способами. Наиболее простой из них – рассмотреть финансовые и трудовые затраты. Другой метод связан с анализом создаваемой ценности.
Итак, первый вариант – модель на основе затрат. Мы должны учесть общие расходы между релизами. Часто их величина известна – это среднемесячные затраты организации. Если мы выпускаем релиз каждый месяц и ежемесячные затраты составляют 1,3 миллиона долларов, то наши расходы равняются минимум 1,3 миллиона долларов на релиз. В координационные издержки могут быть также включены расходы на физическое производство, печать, рекламу и накладные. Все это легко подсчитать. Предположим, они равняются 200 тысячам долларов. Итак, общая стоимость релиза составляет полтора миллиона.
Мы знаем, что дополнительные накладные расходы на релиз равны 200 тысячам, но какая часть из 1,3 миллиона потрачена на планирование, координацию и поставку продукта? Если у нас есть подходящие данные по учету рабочего времени, то можно посчитать и это. Но даже если их нет, мы все-таки способны сделать близкое к истине предположение. Сколько совещаний, людей? Как долго длились совещания? Включите сюда и число человеко-часов, потраченных на сдачу продукта. Умножьте на часовую ставку. Если результат составил около 300 тысяч долларов, то мы получили величину операционных и координационных издержек релиза на полмиллиона.
Эффективность релиза в процентах = 100 % × (общие затраты – (координационные затраты + операционные затраты)) / общая стоимость программного релиза.
В нашем примере эффективность равна
100 % × (1 500 000 – 500 000) / 1 500 000 = 66,7 %.
Чтобы быть эффективнее, нужно либо увеличить интервал между релизами, либо снизить координационные и операционные издержки. Первый вариант – это стандартный выбор западного бизнеса ХХ века и связан с «эффектом масштаба»: нужно производить большие партии, чтобы амортизировать издержки в долгосрочной перспективе. Второй вариант типичен для японского бизнеса конца ХХ века и компаний, стремящихся к бережливому мышлению. Он борется посредством снижения координационных и операционных расходов за то, чтобы размер партии был эффективен (в нашем случае речь идет об эффективности времени между релизами).
Какая эффективность считается достаточной?
Этот вопрос остается открытым. У всех компаний свои взгляды на достаточные показатели эффективности, и многое зависит от создаваемой ценности.
Формирование каденции поставки
Когда мы осознали, какую ценность будет приносить данная поставка, можно принять оптимальное решение относительно темпов. Если ежемесячный программный релиз будет давать выручку в два миллиона при затратах в полтора, то несложно подсчитать, что наша прибыль составит полмиллиона. Можем переписать уравнение эффективности так:
Эффективность релиза в процентах = 100 % × (1 – ((операционные затраты + координационные затраты) / (прибыль + операционные затраты + координационные затраты))).
В нашем примере показатель эффективности составит
100 % × (1 (500 000 / (500 000 + 500 000))) = 50 %.
А теперь все становится еще сложнее, поскольку подсчет истинной ценности релиза может оказаться почти невозможным. У нас может не появиться заказов по твердым ценам. Мы можем спекулировать на потреблении рынка, изменяя тем самым стоимость товара и прибыль. Мы можем выпускать релизы, которые скажутся на неосязаемых активах – например, изменении идентичности бренда, маркетинговых материалах или пакете устранения ошибок и улучшении потребительских свойств продукта или сайта.
Не легче вычислить, стоит ли во имя эффективности снизить темп и выпускать релизы пореже. Увеличение времени выхода на рынок может негативно сказаться на рыночной доле, цене и прибыли. Идея эффективности релиза не является знанием в области точных наук. Важнее всего то, что вы, команда и организация в целом имеете представление о расходах на релиз – затратах времени и денег – и способны провести рациональную оценку, которая приведет к расчету приемлемой частоты релизов.
Если команде из пятидесяти человек требуется три дня и десять сотрудников для успешной выдачи кода, то стоит ли выпускать релиз каждые десять рабочих дней (то есть две календарные недели)? Ответ, вероятно, отрицательный. Лучше установить месячную каденцию (то есть двадцать рабочих дней). Но в то же время не стоит забывать об особенностях рынка, где гибкость и время выхода на рынок имеют большое значение, а риски в основном гасятся более частыми релизами. Так что игра стоит свеч. Вы должны все взвесить и принять самостоятельное решение.
Увеличение эффективности для ускорения каденции поставок
Вернемся к нашему примеру. Мы пришли к выводу, что десять человек выпускают код за три дня. Из этого мы заключили, что приемлемыми будут ежемесячные релизы. Однако некоторые сотрудники считают, что при улучшении качества кода, управления конфигурациями, инструментов для управления, переноса данных и регулярных репетиций процедур распространения продукта удастся сократить трехдневный срок работы до восьми часов, и тогда внезапно оказывается, что вполне возможна двухнедельная и даже еженедельная каденция. Что вы будете делать?
Я бы предложил начать с консервативного подхода. Согласитесь на ежемесячный релиз. Пусть организация докажет, что может добиться такого уровня надежности. Через несколько месяцев оцените качество кода и учредите программу улучшения управления конфигурациями. Если существуют резервные ресурсы, то привлеките их для создания новых инструментов улучшения переноса данных по схемам в ходе релиза. Наконец, предложите команде репетировать релизы в условиях среды для переноса данных. Возможно, такую среду потребуется приобрести, установить и ввести в эксплуатацию. Все это займет время.
Поставьте перед командой и функциональными менеджерами, отвечающими за выход релизов, задачу сократить операционные и координационные издержки. Если это удается, то рассмотрите ход работы на совещании по анализу операций и согласуйте взаимодействие с другими заинтересованными лицами. Когда вы почувствуете, что ускорение каденции релизов, например до двухнедельной, возможно, – переходите на нее!
Снижение координационных и операционных издержек – это суть бережливого программирования. Здесь устранение неоправданных потерь проявляется наиболее ярко. Благодаря ему мелкие партии становятся эффективными, развивается деловая гибкость. Снижение координационных и операционных издержек меняет правила игры. Однако не стоит сосредоточиваться на них как на самоцели. Не забывайте, что ваша цель – чаще выпускать работающие программы, а следовательно, чаще создавать ценность для клиентов.
Релизы по запросу и по ситуации
У регулярных релизов есть свои преимущества. Приняв обязательства сдавать работу в определенные сроки, например каждую вторую среду, вы даете возможность выстраивать вокруг них рабочее расписание. Это рождает уверенность и может привести к сокращению координационных издержек, поскольку не возникает недопонимания относительно того, когда выпускать релиз и кто должен в этом участвовать. Все это установлено раз и навсегда.
Регулярные релизы также помогают создать доверие. А недостаток предсказуемости его разрушает. Отсутствие релиза в назначенную дату привлекает гораздо больше внимания, чем конкретное содержание этого релиза.
При всех очевидных достоинствах регулярной каденции релиза необходимо отметить, что иногда релизы выпускаются по запросу или по ситуации. При каких обстоятельствах это происходит?
Во-первых, релиз по запросу или по ситуации выпускают, если координационные издержки на него сравнительно невелики. Когда координационные затраты и так небольшие, выгоды от постоянных мероприятий по координации практически нет. Во-вторых, такой релиз оправдан при небольших операционных издержках – например, если распространение кода во многом автоматизировано, а качество обеспечено сразу, еще до поставки. Наконец, это имеет смысл в тех ситуациях, когда релизы выпускаются настолько часто, что не нужно разрабатывать для них специальный шаблон. Новые программы появляются практически друг за другом, и большинству наблюдателей и внешних заинтересованных лиц их поток кажется постоянным – они даже не задумываются над датой выхода следующего релиза. А когда нет ожиданий, нет и разочарований.
Такая почти непрерывная выдача кода полезна для некоторых отраслей. Примеры, известные мне от ранних последователей Канбана, в основном связаны с медиаиндустрией: это, в частности, IPC Media в Лондоне, где используются многочисленные канбан-системы для планирования разработок онлайн-медиа, например mousebreaker.com, невероятно популярной онлайн-игры.
