Непрерывное Улучшение

“Мы закончили внедрение бережливого подхода.” “Мы закончили внедрение LeSS.” Требует ли это объяснения? Кажется, что нет.

В бережливом мышлении и LeSS есть только непрерывное улучшение на пути к совершенству. Но есть принципиально другое мышление и поведение, которое существует в виде больших партий и контролируемых изменений в традиционной модели. Как можно почувствовать разницу? Например:

  • Вы устранили губительную кадровую политику сложного персонального рейтинга сотрудников при полугодовой аттестации? Отлично. Можете далее вообще отменить эту аттестацию?
  • Вы упразднили должность руководителя проекта/программы в продуктовой группе? Здорово. Готовы следом упразднить Проектный Офис?
  • Вы сократили ваше общее время сборки — включая все тесты — с двух часов до одного? Отлично. Можете стремиться к сборке за одну секунду?

Как показывают эти примеры, область экспериментов по улучшению и изменению не ограничена только Командами. Непрерывное эволюционное улучшение в LeSS распространяется на всю систему, разрушая все организационные препятствия на пути к идеальному потоку поставки ценности, месяц за месяцем, месяц за месяцем.

И тут нет инициатив, группы или менеджеров по изменениям. В LeSS изменения это статус-кво.

Задайте чёткое направление

Организации являются запутанными чудесным образом системами, в которых невозможно управлять всем и знать всё.

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

Прояснение и достижение соглашения о чётком направлении творит чудеса в согласованности между собой ежедневных решений. Успешные продуктовые группы, с которыми мы работали, обладали видением совершенства — недостижимая цель, где каждый шаг на пути к ней являлся улучшением. Как это можно использовать? Люди обсуждают и оценивают решения, основываясь на том, приблизят ли они их к видению совершенства.

Для примера, классическое бережливое видение совершенства точно-в-срок системы Toyota - в тот момент, когда клиент покупает один автомобиль, в тот же момент производится ещё один автомобиль. Это видение совершенства следует за идеалом “потока в один элемент”, в котором производственная система настроена на обработку небольших партий, состоящих в идеальном случае из одного элемента. Этот идеал возможно никогда не будет достигнут, но в Toyota он является руководством для непрерывного улучшения их производственной системы на протяжении десятилетий.

Видение совершенства, которое мы иногда используем в LeSS:

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

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

Экспериментируйте

Высокая цель, состоящая в обязательности улучшений, может отпугнуть людей экспериментировать. Что, если улучшение… не? Канейоши Кусуноки (Kaneyoshi Kusunoki), ученик Тайити Оно и исполнительный вице-президент в Toyota, сказал о кайдзен и его поддержке на уровне менеджмента:

Определяющая характеристика корпоративной культуры в Toyota - это то, что менеджеры не будут ругать вас за проявление инициативы, за то, что вы рискнули и провалились. Скорее, они отчитают вас за то, что вы не пытались попробовать что-то новое, что вы не попытались рискнуть. Лидеры здесь не для того, чтобы осуждать. Они для того, чтобы поддерживать людей. Вот что я постоянно пытался сделать. Пробы и ошибки - вот о чём всё это! [SF09]

Развитие навыков решения проблем через множество экспериментов является центром бережливого мышления. Плохим экспериментом является только тот, который не был проведён!

Настоящая мера успеха - это количество экспериментов, которые можно провести за 24 часа. — Томас Эдисон

Сосредоточьтесь на проблеме, а не на инструменте.

“Мы начинаем внедрять гибкие методологии. Какой инструмент мы должны купить для гибкого управления проектами?” Мы часто слышим такой вопрос; наше предложение всегда остаётся одним и тем же — и мы его озвучиваем даже для очень масштабных внедрений: “Избегайте любых специализированных инструментов для гибкой разработки первые несколько лет после начала внедрения. Будьте проще. Используйте стены или в самых запутанных решениях простые таблицы или вики.” Почему?

Проблемы из-за слабости системы не могут быть решены с помощью процессов или инструментов. Ещё хуже, если пытаясь применить быстрое решение системных проблем с помощью инструментов, то создаётся иллюзия контроля или изменений, но не настоящих улучшений… Директор спрашивает: “Какой прогресс нашей Agile-трансформации?” Менеджер по Agile-изменениям: “Мы установили , и три проекта его используют. Приходите посмотреть на диаграммы сгорания задач...”

Избегайте соблазна использовать “инструментов гибкого менеджмента” первые несколько лет после начала внедрения гибкой или бережливой разработки, чтобы фокус людей был на том, на чём должен: на системе. Устранение всех костылей и иллюзорных решений на скорую руку, может привести к тому — чисто теоретически — что люди столкнутся с важными, но трудными проблемами: компетенциями сотрудников, взаимоотношениями, ограничениями организационной структуры, иллюзией командования и контроля, и так далее.

Если вы автоматизируете беспорядок, то вы получите автоматизированный беспорядок. — неизвестный автор

Мы не утверждаем, что инструменты для гибкого управления плохие или хорошие. Мы говорим в первую очередь о фокусе на важных вещах и предотвращении дисфункций, которые сопровождают инструменты управленческой отчётности.

Через лет? Предпочтите свободные инструменты, чтобы снизить стоимость экспериментов и количество барьеров при отказе от них. Мы несколько раз слышали следующее: “Мы не можем перестать использовать (или процесс) X, потому что мы слишком много в него вложили.”

Мы видели успешное внедрение масштабируемого Скрама в распределённых продуктовых группах из тысячи человек с несколькими Excel-таблицами для Бэклога Продукта и диаграммой Сгорания Релиза. Действительно, им почти наверняка будет от этого только лучше; это держит внимание команды в большей степени на улучшении системы.

Инструменты для гибкого управления, которые мы видели, фокусируются на отслеживании и отображении индивидуальных или командных задач в Бэклоге Спринта для менеджеров — почти противоположность принципам гибкой разработки. В Скраме, задачи команд (Бэклог Спринта) создаются командами, чтобы помочь им в самоорганизации - а не для предоставления отчётности кому-либо. Хорошо известный исследователь команд Ричард Хакман объясняет “В самоорганизованных командах ответственность за отслеживание прогресса делегирована напрямую командам” [Hackman02]. Поскольку команда самоорганизованная, она не отслеживается и не проверяется; такие инструменты представляют собой скользкий путь, который может укрепить традиционную культуру командования и контроля, а не культуру самоуправления.

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

В итоге, эти инструменты оптимизированы для отчётности - не для успеха, улучшений, или лучшего потока ценности. Какую значимую проблему они решают?

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.