Переговоры по внедрению канбана

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

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

WIP‑лимиты

В Дании я познакомился с менеджером по разработке, который рассказал, что у его сотрудников в среднем одновременно находятся в работе семь с половиной задач. Это чересчур много. Сомневаюсь, чтобы кто‑то приветствовал подобную многозадачность. На его месте я бы использовал этот факт для переговоров и начал бы с заявления, что в среднем члены команды вынуждены параллельно выполнять семь с половиной заданий. Я указал бы на то, какое влияние это оказывает на время выполнения и предсказуемость, и пригласил бы коллег и других заинтересованных лиц подумать над тем, каково оптимальное число заданий. Некоторые, возможно, предложили бы одно задание на человека. Вероятно, так и есть, но это слишком агрессивный выбор. Что если задание будет заблокировано? Разве не требуется возможность переключиться на альтернативу? Не исключено, что кто‑то другой высказался бы за два задания одновременно или в пользу трех. Скорее всего, будут предлагаться именно варианты от одного до трех. Если в команде десять разработчиков и вы сможете договориться о двух заданиях, одновременно выполняемых одним человеком, то получаете в итоге WIP‑лимит на команду, равный 20.

Есть и другие варианты. Допустим, вы хотите, чтобы в команде работали попарно. А два задания на пару при общей численности десять программистов соответствуют WIP‑лимиту, равному 10. Возможно также, что вы используете метод более тесного сотрудничества – например, разработку по функционалу или функциональные бригады. В этом случае небольшие группы по пять‑шесть человек работают над одной MMF, пользовательской историей или одним пакетом функций (как в FDD), то есть над тем, что также называется рабочим пакетом главного программиста (CPWP – Chief Programmer Work Package). Команда функциональных разработчиков может договориться и ограничить число CPWP тремя на команду из десяти разработчиков. (CPWP обычно оптимизируется для эффективности разработки на основании архитектурного анализа домена и содержит от 5 до 15 очень детализированных функций.)

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

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

Чтобы успешно взаимодействовать в Канбан‑разработке ПО, правила игры должны быть установлены общим решением всех заинтересованных лиц.

Расстановка приоритетов

Мы хотим договориться и о механизме пополнения очереди. Обычно это достигается решением о проведении регулярного совещания по пополнению системы и определением механизма выбора новых элементов. Разговор можно начать так: «Если нам нужно будет спросить вас: “Какие два элемента вы хотите видеть реализованными через сорок два дня?” – то как часто вы сможете встречаться с нами, чтобы отвечать на этот вопрос? Надеемся, что такие совещания будут занимать не более получаса».

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

Релиз

Затем нужно договориться примерно о том же с партнерами ниже по цепочке. То, какая именно каденция релизов является целесообразной, очень зависит от отрасли или ситуации. Если речь идет о веб‑программах, то их нужно поставлять на группу серверов. Реализация такой программы включает копирование файлов и, возможно, обновление схемы баз данных с последующим переносом данных с одной версии схемы на другую. Для переноса данных, вероятно, понадобится собственный код, а его выполнение может занять некоторое время. Чтобы вычислить общее время реализации, нужно учесть количество серверов и файлов для копирования, время на безопасное закрытие систем и их перезагрузку, на перенос данных и т. д. Иногда это занимает несколько минут, а порой – несколько часов или дней. В других отраслях нередко приходится создавать физические носители – DVD, упаковывать их в коробки и поставлять по физическим каналам, направляя распространителям, дилерам, розничным операторам или уже существующим корпоративным клиентам. Могут быть задействованы и другие виды деятельности – например, печать бумажных инструкций или обучение сотрудников отделов продаж и техподдержки. Иногда для этих людей нужно разрабатывать и отдельную программу обучения.

Например, в 2012 году я принимал участие в релизе первого из обновлений мобильной телефонной сети Sprint PCS. Это обновление на пути к технологии 3G называлось lxRTT. На рынок оно вышло как PCS Vision и включало выпуск примерно 15 новых аппаратов с 16 новыми функциями, которые использовали высокоскоростные возможности передачи данных новой сети. У Sprint в США была розничная сеть, где работали 17 тысяч человек. Примерно столько же было в кол‑центрах, которые занимались технической поддержкой пользователей. И участники розничного канала продаж, и сотрудники техподдержки должны были пройти обучение, чтобы запуск нового сервиса стал эффективнее. Я в шутку предположил, что оптимальнее всего закрыть все на пару дней, вывезти всех на ночь в Канзас‑Сити и арендовать стадион команды «Канзас‑Сити Чифс», на котором и провести двухчасовую презентацию в PowerPoint на больших экранах в обоих концах стадиона. Возможно, это был самый эффективный, но, конечно, неприемлемый способ. Вряд ли клиенты одобрили бы 48‑часовое отсутствие поддержки на время обучения операторов технологии следующего поколения. А двухдневное отсутствие продаж по розничному каналу явно не помогло бы годовому бюджету.

Была разработана программа обучения, проведена подготовка инструкторов. Создали также программу обучения региональных сотрудников розничных продаж и работников кол‑центров. Инструкторы обучали их в течение шести недель в составе небольших групп и в нерабочее время. Расходы на это были огромными: во‑первых, шесть недель – это много, а наиболее эффективно пользоваться полученными знаниями сотрудники могли тоже в течение примерно шести недель. Если бы мы не уложились в окно запуска нового сервиса, то обучение пришлось бы повторить, а запуск отложить как минимум еще на шесть недель.

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

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