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

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

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

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

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

Когда разговор заходит о времени выполнения, полезно привести накопленные данные по предыдущей производительности. В идеале хорошо иметь данные по времени выполнения и инженерному времени. В примере с Microsoft (глава 4) было известно, что время выполнения составляет примерно 125 дней на устранение ошибок первой степени срочности и 155 дней – на ошибки остальных степеней. Главное, что мы можем отсюда почерпнуть, – это наличие двух классов обслуживания. Ошибки первой степени в какой-то форме обрабатывались раньше. Возможно, формальных правил не было, но так уж выходило, что ошибки первой степени устранялись быстрее.

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

Также из предыдущих данных известно, что в среднем инженерная работа занимала 11 дней, а при самом высоком качестве работ – 15. Поэтому мы решили предложить 25-дневное время выполнения, считая с момента выбора элемента из входящей очереди. Больше никаких научных данных не потребовалось. А теперь представьте психологический эффект от этого: в бизнесе привыкли, что работа занимает четыре-пять месяцев, а мы предлагали 25 дней. Разница в том, что мы говорили о 25 днях как о времени выполнения, не учитывая ожидание в очереди, а 155 дней включали и его. Тем не менее это выглядело фантастическим улучшением. Неудивительно, что представители бизнеса согласились.

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

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

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

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