Перевод статьи Craig Larman «Larman's Laws of Organizational Behavior» выполнен Лилией Алексеевой (Agile-евангелист, Сбербанк) с разрешения автора.

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

  1. Организации устроены таким образом, чтобы избегать изменений структуры власти, статуса-кво между топ- и средним менеджментом, а также между средним-менеджментом и специалистами.
  2. Первое следствие из п.1 – любая инициатива по изменению будет сведена к переопределению существующей либо к вводу новой терминологии, по сути означающей тоже самое, что и до изменений, но позволяющей поддерживать статус-кво.
  3. Второе следствие из п.1 – любая инициатива по изменению будет высмеяна как «пуристическая», «теоретическая», «излишне революционная» и «требующая приземления на реалии организации», что мешает началу работ по устранению существующих проблем и сохраняет статус-кво руководителей и специалистов.
  4. Культура подчиняется структуре (следует за ней).

Или, культура / поведение / тип мышления определяется организационным дизайном. Если вы действительно хотите изменить культуру, то начать придётся с пересмотра организационной структуры. Другого пути нет.

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

Джон Седдон (прим. ред. – консультант, специалист в области Системного мышления, автор статьи «Против ISO 9000») отметил следующее: «Попытки изменить культуру организации – сплошная глупость, и всегда терпят неудачу. Культура как поведение людей является продуктом системы – только изменив систему, можно способствовать изменению поведения».

PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.
Поделиться с друзьями
-->

Комментарии (4)


  1. cry_san
    31.01.2017 09:17
    +2

    На основе этого опыта я сформулировал Законы

    Это из разряда статей, почему зубная щетка «распушивается», т. е. и так очевидные всем.


    1. Tanner
      31.01.2017 11:37
      +2

      Зато мы узнали, что в Сбербанке есть Agile-евангелист.


  1. taujavarob
    31.01.2017 17:13
    +1

    1)

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

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

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

    2)
    Джон Седдон (прим. ред. – достаточно известный в США адвокат и мыслитель, автор статьи «Против ISO 9000») отметил следующее: «Попытки изменить культуру организации – сплошная глупость, и всегда терпят неудачу. Культура как поведение людей является продуктом системы – только изменив систему, можно способствовать изменению поведения».


    То есть культура организации есть подсистема более старшей системы. Но более старшая система есть подсистема какой-то более старшей системы…

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


    1. rsn81
      31.01.2017 21:38
      -1

      Как это совместить? — ведь любая инициатива по изменению приведёт к вводу новой терминологии, по сути означающей тоже самое.
      Не любая инициатива, а именно что инициатива по изменению терминологии. Как это происходит в диалоге:
      — Помогите нам внедрить Agile.
      — Какие проблемы испытывает ваш бизнес?
      — Что вы?! У нас все нормально.
      — Хм… а зачем вам Agile?
      — Мы хотим быть в современном тренде.
      Иногда это формулируют более честно-цинично: «Как бы нам внедрить Agile так, чтобы ничего сильно не менять?»

      А вот инициатива по изменению компании реально изменяет ее организационную структуру. К примеру, в старой структуре руководитель подразделения не только нанимал и увольнял разработчиков, но и ставил им задачи, то есть руководил центром затрат с собственным бюджетом. А в новой структуре, к примеру, у него остаются только сервисные задачи: нанимать, увольнять и развивать разработчиков — но конкретные задачи разработчикам ставят отныне представители от бизнеса (Product Owner, Business Owners), плюс еще и дают бывшему руководителю обратную связь о том, насколько хороших разработчиков он им поставляет в команды, то… какой новый красивый термин ни придумай (по сути я описал роль Chapter Lead из Spotify), но бывший руководитель не согласится с вами, что суть та же.

      То есть культура организации есть подсистема более старшей системы. Но более старшая система есть подсистема какой-то более старшей системы…

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

      Компании? Среди компаний, занимающихся сходным бизнесом, вы почти всегда встретите один и тот же тип культуры. К примеру, сравните системные интеграторы и компании-разработчики тиражируемых программных продуктов — совершенно разные культуры. Это происходит как раз потому что у них сходное или различное окружение, как вы написали — «высшая система»: государство, отрасль, клиенты, география и т.п. Хотя бывают и исключения, это герои: внутри компании (подразделении) или даже внутри государства (компании) с доминирующими культурами контроля выстраивают оазис совершенно иной культуры.

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