Анализ, Пример, Теория

Гибкость, которая не разрушает компании

Недавно Ed Brimmer, консультант по управлению производительностью, еще раз ясно выразил мысль о том, что гибкость (Agile) на уровне организации — далеко не очевидное свойство, требующее отдельной экспертизы.

Пока не наступит день, когда Agile получит твердую основу (backbone), он будет только уничтожать компании. Гибкость может случиться там и тогда, когда власть и контроль предоставляются работникам. Если компания не делает это, она не является гибкой (Agile).

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

Эд Бриммер

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

  • Есть ли у вас модель, раскрывающая суть Гибкого Преобразования как методологии, которую можно с одинаковым успехом применять и к командам, и к подразделениям, и к предприятиям?
  • Согласно этой модели, что лежит в основе успеха Agile как методологии развития? Какую основную проблему призван решить данный подход?
  • Почему работа с видением служит первостепенно важным компонентом в успехе Гибкого развития предприятия? Как это увидеть в вашей модели?
  • Что кроме видения определяет успех Гибкости в преобразованиях?
  • Как определить важные проблемы, которые потенциально могут повлиять на успех Гибкого пути развития в конкретном случае? Нарушение каких принципов из Вашей модели ведет к этому?
  • Какой именно стратегии соответствует Agile? Как вы определяете в рамках своей модели предприятия, что Гибкость как методология нужна (либо не нужна) в вашей конкретной ситуации, для конкретного подразделения или этапа в развитии предприятия? Решение о выборе Гибкости в качестве инструмента также нуждается в прозрачности.

Небольшой эксперимент показал, что эти вопросы оказались непростыми даже для достаточно опытных людей. Обсуждение темы сразу делает очевидным тот факт, что без опоры на определенную парадигму и методологию мышления рассуждения на тему «истинной гибкости» не ведут к практически значимым результатам.

Давайте разберемся в том, что такое Гибкость (Agile), почему эта идея за много лет не привела к однозначно ассоциируемой с ней практике, и как шаблон оркестровки может внести свою лепту в обсуждение данной темы.

Что такое гибкость (Agile)?

Начнем со статьи в Википедии.

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля[1]. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

Википедия

Очень важный пункт, на котором следует остановиться сразу: в первом же абзаце статьи уже кроется что-то, уводящее в сторону. Как мы увидим далее,

Agile, к неудовольству многих истинных инженеров, — это не методология, это — идеология. Гибкость — это идея о том, почему следует идти определенным путем гибкости и о том, что мотивирует это делать, а не описание какого-то определенного метода или методики, полностью готовой к проведению экспериментов.

Сергей Тузик

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

С чего же начался Agile? Та же статья в Википедии сообщает нам общеизвестную историю.

… Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.

Agile Manifesto разработан и принят 11—13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.

Основные идеи:

  • люди и взаимодействие важнее процессов и инструментов;
  • работающий продукт важнее исчерпывающей документации;
  • сотрудничество с заказчиком важнее согласования условий контракта;
  • готовность к изменениям важнее следования первоначальному плану.

Принципы, которые разъясняет Agile Manifesto[3]:

  • удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
  • приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
  • частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
  • тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
  • проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
  • рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
  • работающее программное обеспечение — лучший измеритель прогресса;
  • спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
  • постоянное внимание улучшению технического мастерства и удобному дизайну;
  • простота — искусство не делать лишней работы;
  • лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
  • постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.[4]

Закрепим еще раз: Agile — это идеология с четко выраженными четырьмя идеями. Следующий за идеями список — это не методы работы, а принципы, которые по мнению разработчиков Manifesto соответствуют этим идеям. Эта простая мысль написана во многих местах прямым текстом. Для ее понимания не нужны метафоры и другие сложные приемы образного мышления.

Что может быть не так с внедрением Гибкой разработки?

Практики в ответ на данный вопрос могут рассказать много историй, которые дадут понять: всё может пойти не так. Но наше дело не собирать яркие анекдоты, а понять коренные существенные моменты.

Начнем с терминологии. Стоит говорить о внедрении идеи гибкой разработки, а не об использовании Agile-методики. В этом нехитром моменте уже кроется часть случаев, когда что-то пошло не так на идейном уровне.

Не секрет, что многие инженеры исповедуют инженерное мышление, основанное на знании технологий, методик, лучших практик и подобных им вещей. Что станут делать хорошие инженеры, когда будут слышать много разговоров о том, что «Идея Agile хороша, но она не работает на практике. Гибкие методологии принуждают использовать странные нелогичные ритуалы, которые только отнимают время. Есть много версий как делать Agile и даже консультанты в них путаются» ?

Можете не сомневаться, что хороший инженер в данной ситауации скажет: «Дайте мне исходники и не мешайте. Если вам нужно — разберемся, заставим эту штуку работать.» Они возьмут 4 идеи и 12 принципов из Agile Manifesto и начнут думать о том, как это реализовать.

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

Дело реализации идей и принципов гибкости очень не тривиально. Именно поэтому известно только небольшое количество достаточно успешных практик по внедрению гибкости в разработку продуктов.

Недавно услышал отличную метафору о том, что «Agile очень похож на религию«. Ведь у них можно заметить много общего:

  • и в религии, и в Agile есть четкий список заповедей;
  • очень мало людей понимает суть заповедей непосредственно, поэтому они предпочитают разучить определенные рекомендованные ритуалы, надеясь на то, что вера в них и регулярная практика приблизят к пониманию сути;
  • иногда находятся энтузиасты, которые вместо попыток понять суть изначальных идей через долгую ритуальную практику пробуют принести свои идеи, пытаясь подменить ими суть. Так получаются ереси, которые в подавляющем числе случаев носят деструктивный характер.
  • Отличить ересь от истинной религии проще всего по результатам их применения. Сравните: «По плодам их узнаете их» и «Работающее программное обеспечение — лучший измеритель прогресса«.

Как же достичь истинной гибкости?

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

1. К какой стороне предприятия в первую очередь относится Гибкость (Agile)?

Horizons

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

2. К каким сторонам корпоративного доверия может иметь отношение гибкость?

Trusted_relations

  • Внутри домена доверительных отношений труднее четко определиться со позиционированием фокуса второго уровня для гибкости;
  • Тройка поддоменов с указанием их приоритетности, с моей точки зрения, выглядит так: 1. Культура, 2. Стратегия, 3. Структура.
  • Культура и стратегия — основные по важности области для проявления гибкости на предприятии.
  • Гибкость на уровне структуры — это применение одной из выбранных методологий с четким следованием соответствующим процессам и ритуалам.
  • Гибкость на уровне стратегии — это экспертиза, позволяющая изменять ритуалы и процессы, как минимум, без ущерба для результативности, а в идеале — с повышением продуктивности.

3. Какой тип стратегии лучше всего соответствует гибкости (Agile)?

Strategy

  • Классическая стратегия основана на планировании и не предоставляет достаточной свободы для гибкости;
  • Адаптивная стратегия — самый очевидный кандидат для соответствия гибкости (Agile);
  • Стратегия формирования — чуть более сложный вариант для гибкости, который переводит ее на уровень культуры и экосистемы.

Что делать, чтобы быть гибким?

Вы прочитали все предыдущее, но остался вопрос «И что с этим всем делать?» Спешу подтвердить — да, там ничего не написано на тему «Что с этим делать и как». Так и задумывалось. Там написано о том, как это можно понимать.

Более того, большинство инженеров после публикации Agile Manifesto находились в таком же состоянии: идея хороша, но вот что делать не понятно. Все-таки стратегическое и инженерное мышления отличаются. Хоть у инженеров и есть свое, инженерно-стратегическое мышление, построение подходящей культуры и выработка поддерживающей ее стратегии — это не инженерная дисциплина. Не нужно «инженерам по духу» на профессиональном уровне браться за толкование религий. Обычно получается деструктивная ересь, которая работает только на уровне небольших команд, и в которых личный авторитет лидера означает больше любых стратегий и культур.

И все же. Как быть гибким? Каким таким магическим образом эта гибкость приводит к повышению производительности?

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

По моему мнению, Гибкость, заложенная в Manifesto, предполагает двухуровневую архитектуру. Верхний уровень отвечает за весь проект, всю команду, всю компанию — за ту сущность, гибкостью которой мы хотим управлять.

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

Рассмотрим ниже пример из книги «Оркестровка предприятия», основанный на разборе методологии «Джазового процесса«, созданной и описанной Адрианом Чо (Пользуясь случаем, хочу еще раз выразить признательность Ардите Карай (Ardita Karaj) за рекомендацию познакомиться с этой методологией).

Методология «Джазового процесса» — результат работы Адриана Чо как опытного практика. Схема-шаблон для метода исполнения «джазового процесса» и его 14 основных принципов хорошо заточены на классическое исполнение (которое соответствует классической стратегии, базирующейся на планировании и последовательном исполнении процесса). Но именно благодаря этому, шаблон джазового процесса является примером «инженерной ереси в Agile», искажающей адаптивный характер гибкости и приводящей к очевидному противоречию между исходной идеей и предлагаемым инструментом. (Не может классический цикл НОРД (OODA) служить правильной основой для адаптивного процесса. Там используются разные типы мышления = разные картины мира. Точка.)

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

Jazz_process

На схеме мы видим:

  • два уровня деятельности: командный и личный уровень каждого эксперта в этой команде;
  • 14 важных принципов «джазового процесса», распределенных по уровням и их основным доменам;
  • 7 основных этапов основного цикла данного процесса.

Как работает эта схема (номера пунктов совпадают с номерами этапов):

1. Все начинается на уровне видения, основной миссии, основного бизнес-направления команды (проекта, компании). Ключевое предположение — на втором уровне (эксперты — участники команды) никаких других миссий и видений нет, основное желание — общий успех в выбранном направлении (между прочим, именно на этом этапе можно проверить, не пора ли для повышения гибкости разделить компанию на независимые части. Если такого единства в видении большой картины мира нет, то Гибкость начнет пропадать прямо здесь, на первом этапе).
Одна из идей Manifesto косвенно на это указывает: у участников нет других значимых самостоятельных целей, кроме совместного успеха в рамках команды / проекта / компании:

сотрудничество с заказчиком важнее согласования условий контракта;

2. После формулирования общей миссии и общего видения направления движения следующий этап — формирование доверительного пространства для превращения идей о необходимых изменениях в возможности.

люди и взаимодействие важнее процессов и инструментов;

3. Доверительное взаимодействие предполагает работу не только на командном, но и на личном уровне. Именно здесь проявляется вовлеченность, которая так важна для гибкости на уровне идей и поиска стратегии для их реализации.

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

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

5. Каждый эксперт работает локально, поэтому появление общей документации в данный момент невозможно: формирование общего взгляда на все происходящее абсолютно противоречит сути этой фазы процесса. Поэтому никто и не пытается делать невозможное. Лучшим описанием для изменений, запланированных и выполненных каждым экспертом будет не документация, а результат его работы, который можно оценить по его действующей функциональности («по плодам их»).

работающий продукт важнее исчерпывающей документации;

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

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

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

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

готовность к изменениям важнее следования первоначальному плану

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

Ретроспектива — очень подходящее время для того, чтобы зафиксировать в виде документации (которая часто страдает в гибких процессах) общее экспертное понимание команды об уроках, выученных во время данной итерации. Здесь каждый из экспертов может сравнить коллективное мнение о проекте с тем подходом, который он применял самостоятельно для своей части задач.

Что же можно сказать в конце?

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

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

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

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

Главное — почувствуйте дух идеи гибкости и попробуйте поработать с этой идеей как с идеей, используя некую парадигму в качестве инструмента.

Не получается пока? Ничего. Есть альтернативный способ — выбрать одну из давно существующих конфессий гибкости, разучить для начала предлагаемые ей ритуалы, обязательно попрактиковаться на реальных случаях.

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

Гибкость, которая не разрушает компании: 1 комментарий

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s