Клиентоориентированность
Основная практика 3: управляйте потоком
Это не ошибка? Каким образом мы перескочили с практики «управляйте потоком» к клиентоориентированности? Будьте снисходительны, позвольте мне расширить формулировку этой основной практики, чтобы более полно выразить ее сущность:
ОП3 (расширенная): управляйте потоком, добивайтесь плавности, своевременности и хороших экономических результатов, предугадывая потребности клиента.
В этой главе я рассказываю о потребностях клиента и о том, как их лучше предвидеть. О слаженности рабочего процесса и своевременности говорится в следующей главе «Поток». Читая обе главы, помните о «хороших экономических результатах». Принятие экономических решений является темой главы 15.
При чем здесь клиентоориентированность?
Ориентация на задачу, на роль, на команду, на проект, на компанию, на технологии… список можно продолжать. Есть так много возможностей потерять из виду то, ради чего мы занимаемся этим бизнесом!
На занятиях я всегда даю следующий совет:
Всегда знайте, что вы поставляете, кому и зачем.
Может показаться, что это ясно без слов, но этот совет, видимо, попадает в точку. Слушатели сами говорят мне, что никогда по-настоящему не думали об этом раньше. В своих листках обратной связи они упоминают это как основной результат своего обучения. Это не значит, что концентрация на других вещах и проблемах плоха, но ориентация на потребности клиента помогает увидеть их под нужным ракурсом. Подумайте сами: если вы посмотрите на свое занятие с точки зрения других, то наверняка узнаете что-нибудь новое о том, как это работает.
Удовлетворение гарантировано
Вспомните правило из сценария, открывающего главу 1:
- Разработчики отвечают за выполненные рабочие задачи до тех пор, пока не получат подтверждение пользователя о том, что их разработки доказали свою работоспособность.
Это правило добавлено относительно недавно. Мы довели процесс разработки до такого уровня, что он казался нам достаточно эффективным. Мы собирали требования, создавали новые компоненты, тестировали их и выпускали. Спустя некоторое время мы немного усложнили процесс: добавили на доске столбец, который позволяет отслеживать программные компоненты, выпущенные, но требующие дальнейших шагов по внедрению, прежде чем стать завершенными.
Однако нередко при проведении проверки выяснялось, что мы поставляли программные компоненты, которые никогда не будут использоваться. Программные компоненты, о которых нас просили! Как такое может произойти?
Новое правило было добавлено для того, чтобы решить проблему, которая, как мы думали тогда, была связана с некорректным поведением клиента. Зачем просить то, что не нужно? Почему бы не дать нам знать, когда вы передумали? Однако вскоре стало очевидно, что новое правило меняет поведение обеих сторон. Завершение цикла обратной связи послужило стимулом, чтобы поднять сотрудничество с клиентом (ценность, взятая непосредственно из Манифеста аджайл) на такой уровень, который мы ранее не видели.
Зная, что процесс непременно заканчивается трудным разговором, разработчики и наши внутренние заказчики сделали все, чтобы успешно завершить последние этапы внедрения (уточнение графиков, информирование и обучение сотрудников, очистка статических данных и т.д.). При необходимости эти этапы мы проходили заранее, зачастую совместно. Это, в свою очередь, оказывает влияние на то, как ведутся разработка и специфицирование программного обеспечения. Уже на первом этапе процесса мы смогли изменить подход к приоритизации работ. Сейчас очевидно, что успех зависел от совместных обязательств.
Я не преувеличиваю, когда говорю, что эффект изменения правила превзошел все мои ожидания. Толика скромности тоже не повредит: причина крылась не в плохих клиентах, а в недостаточно эффективных отношениях с ними.
Обзор доски
Правило, прикрепленное (фигурально выражаясь) к крайнему правому столбцу нашей канбан-доски, стало катализатором, клиентоориентированность все же сказалась на всем процессе. Чтобы понять, как подобные трансформации можно сделать стандартными и воспроизводимыми, полезно еще раз внимательно изучить доску, задавая при этом конкретные вопросы. Рассматривая доску, мы будем двигаться справа налево, от одного столбца к другому.
- Чьи потребности исследуются на этой стадии процесса и каким образом? Чьи потребности не исследуются, и какие риски это несет?
- Чему мы учимся на этой стадии из того, что не знали (или не могли знать) раньше? Каким образом работа на этой стадии помогает сфокусироваться на том, что понадобится в будущем?
- Что еще нужно изучить? Как лучше справляться с неопределенностями — двигаться вперед или сделать шаг назад?
Применяя эту логику ко всем этапам процесса вплоть до самого начала, мы ориентируемся уже не на заданные требования, а на удовлетворение потребностей, которые нужно обнаружить и исследовать. Надо не оглядываться назад, оправдываясь и доказывая, что мы делаем программное обеспечение «в соответствии со спецификацией», а смотреть вперед, работая над удовлетворением потребностей, которые пока еще не раскрыты. Мы не особенно надеемся на, казалось бы, безупречный процесс, который сделает нашу работу за нас, а ищем пути более эффективного обучения.
Творческая интеллектуальная работа — это не то, что мы уже знаем. Это (тут я сознательно прибегаю к техническому жаргону) процесс поиска знаний. Используйте канбан-доску для того, чтобы она постоянно напоминала вам о вопросе «Что мы не знаем?».
Предваряющий канбан
Я бы хотел схематично показать один из более сложных вариантов доски, который сам использую для управления своей рабочей загрузкой (рис. 4.1). Его основной отличительной особенностью является наличие трех столбцов под шапкой «Идеи». Обратите внимание на то, что их уменьшающиеся лимиты объемов незавершенной работы наводят на мысль о последовательном исключении.
Такой дизайн полезен, если нужно упорядочить идеи и задачи, которые можно выполнить в будущем, помимо управления текущей рабочей нагрузкой. Ниже я привожу два основных приема, позволяющих эффективно использовать такую доску:
- Научитесь мысленно закрывать крайние левые столбцы до тех пор, пока не придет время пополнить столбцы, расположенные правее, или изменить приоритеты. Вскоре это превратится в привычку. Кроме того, нет никаких сомнений в том, что вы используете систему вытягивания. Если вы хотите пополнить очередь в столбце «Готово», то можете сделать это, используя только относительно небольшое количество рабочих задач (всего пять) в столбце «Приоритет 1», что намного легче, чем рассматривать весь набор идей.
- Сбалансируйте стремление добавить на доску новые идеи с готовностью убрать с нее рабочие задачи, которые с большой вероятностью никогда не дойдут до столбца «Готово». Удаленные рабочие задачи можно поместить в архив, чтобы проанализировать в будущем, или полностью уничтожить (я предпочитаю передвигать отдельные рабочие задачи в область промежуточного хранения «ниже линии» и периодически разбираться с ними).
Понятно, что ограничение зоны незавершенных работ является напоминанием о следовании этим двум правилам. Как только доска начнет заполняться, вы увидите, что занимаетесь исключением рабочих задач из числа приоритетных намного чаще. И это очень полезно и разумно!
В этом варианте доски меня вдохновляет идея сита приоритетов — метод из книги «Персональный канбан». Мой неожиданный переход к этой теме сейчас может показаться странным (мы кратко вернемся к нему в части II), но я использую этот дизайн в качестве модели для предваряющего канбан (Upstream Kanban). Это название ввели для обозначения практики применения системы канбана до процесса поставки. Предваряющий канбан — это организация потребностей и развитие идей таким образом, чтобы всегда имелся хороший выбор по предложениям, когда появляются свободные возможности поставки.
Этот дизайн подкрепляет два принципа, кажется, забытых портфельными менеджерами некоторых наших крупнейших корпораций:
- Мы генерируем больше идей, чем можем использовать — на самом деле, если бы было наоборот, то у нас появилась бы причина бить тревогу. С течением времени мы аккумулируем больше идей, чем можем эффективно использовать.
- Идеи не могут развиваться только за счет своих собственных достоинств — они конкурируют с другими идеями. Более того, в любой момент могут появиться новые идеи, которые вступают в конкуренцию с уже существующими.
Когда рабочие задачи входят в столбец «Готово», происходит нечто странное: эта система имеет очень точно выраженную точку вовлечения. По левую сторону от нее мы были бы счастливы видеть рабочие задачи, сдвинутые назад по срокам или вовсе исключенные из списка. Справа от нее мы видим рабочие задачи, о которых можно сказать следующее: мы считаем, что что-то идет не так, если эти рабочие задачи не выполняются достаточно быстро, и сожалеем о затраченных впустую усилиях, если от задач отказываются, когда они практически готовы.
Как и в процессе поставки, эффективность предваряющего процесса зависит от тех же ценностей, которые мы уже рассматривали:
- Прозрачность: система должна сделать так, чтобы мотивы трудного выбора, который предстоит сделать, были видимыми. Логическое обоснование принятия решения должно быть явным. Решения должны быть в центре циклов обратной связи (например, совещаний, посвященных приоритизации).
- Баланс: объем незавершенных работ в системе контролируется, как с целью надежного поддержания уровня предложения высококачественных идей, так и для своевременного принятия решений. В случае необходимости можно получить дополнительный контроль, распределив незавершенные работы по заказчикам, бюджетной линии, категории риска, стратегической инициативе и т.д.
- Сотрудничество: качественная оценка рабочих задач для дальнейшей разработки делится между их инициаторами и теми, кто будет их выполнять. Вместо создания преждевременного риска в системе все вовлеченные в процесс стороны (которых может быть несколько) не торопятся принимать окончательное решение, пока не наступит нужный момент.
Теперь давайте посмотрим, что к сказанному добавляет клиентоориентированность:
- Чьим потребностям, по нашему мнению, соответствуют эти идеи?
- Достаточно ли быстро мы удовлетворяем потребности?
- Что говорят нам данные? Что говорят нам люди?
- На чем могут основываться эти потребности?
- Какие потребности могут оставаться неудовлетворенными?
- Как мы можем это проверить?
Если резюмировать сказанное: можем ли мы лучше понять, что станет нужным в будущем?
Предугадывание потребностей
Если существует единственная идея, которую я хотел бы донести до вас в этой главе, то она заключается в следующем: перестройте мышление — прекратите делать то, что просят, выполнять запросы, удовлетворять требования и т.д. Переориентируйте процесс на определение и удовлетворение потребностей. Это сдвиг с внутреннего ракурса (что, как нам кажется, мы знаем) на внешний (что еще можно выявить). Это также переход от прошлого (что нам говорили) к будущему (когда будут удовлетворены потребности заказчика).
Этот акцент на будущем хорошо отражен в заключительных словах «Обещания компании Toyota своим клиентам». Я обнаружил их на табличке, прикрепленной на стене позади стола клерка, обслуживающего заказчиков у дилера Toyota недалеко от моего дома:
…заблаговременно предугадывать потребности в мобильности отдельного человека и общества в целом.
Задумайтесь об услугах, которыми вы пользуетесь. Разве вам не понравится, если поставщик этих услуг заблаговременно предугадает ваши потребности? Какие инновации им понадобятся, чтобы сделать это возможным? Можете ли вы перенести такой стиль мышления на свое рабочее пространство?
