Законы Лармана об организационном поведении

    Перевод статьи 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.
    ScrumTrek
    47.44
    Мы помогаем компаниям стать крутыми!
    Share post

    Comments 4

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

      Это из разряда статей, почему зубная щетка «распушивается», т. е. и так очевидные всем.
        +2
        Зато мы узнали, что в Сбербанке есть Agile-евангелист.
        +1
        1)
        Первое следствие из п.1 – любая инициатива по изменению будет сведена к переопределению существующей либо к вводу новой терминологии, по сути означающей тоже самое, что и до изменений, но позволяющей поддерживать статус-кво.

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

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

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


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

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

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

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

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

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

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

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

        Only users with full accounts can post comments. Log in, please.