#Ускорение4X. Принцип № 0/3. Системное подчинение

    Напомню, что мы изучаем практику #Ускорение4X.

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

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

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

    Но еще важнее другой, побочный итог — мы убедились, что методика_такая-то — фуфло. Потому что не работает.

    Так часто бывает, например, с внедрением принципов agile, или конкретно методики скрам. Так будет и с методикой #Ускорение4X, если действовать с той же ключевой ошибкой — главной ошибкой внедрения изменений в нашей стране.

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

    Неподчинение


    Итак, вот она, ошибка: системное неподчинение.

    И сразу принцип, о котором публикация: системное подчинение.

    Обратите внимание — не систематическое, а системное. Систематическое — это вроде периодического, т.е. регулярно возникающего.

    Системное неподчинение — это неподчинение, как система, как часть мировоззрения, как одна из ценностей, как повод гордиться собой.

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

    Причем, фильмы-то, в основном, не наши, а страсть к неподчинению наиболее сильна, наоборот — в нас. Об этом, кстати, есть очень хорошая книга — «Русская модель управления» Прохорова (не того, который ё-мобиль делал).

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

    Вы не думали, почему так? Почему законы и правила пишутся именно такими — сложно выполнимыми, а главное — бессмысленными, т.е. их беспрекословное выполнение не приведет ни к чему хорошему?

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

    Тут вы можете возразить — ведь немало законов, правил и изменений, которые вполне успешно внедрены и работают. И в компаниях, и в стране.

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

    Недостающий элемент


    Возьмем простой пример, наглядный почти для всех — правила дорожного движения. Например, правило про пересечение стоп-линии на запрещающий сигнал светофора.

    Я за рулем 10 лет, и помню, что это правило существует давно — оно встречалось в билетах на экзамене. Вроде за него был штраф 100 рублей. Выполнение правила помогает избежать заторов на перекрестке, да и пешеходам комфортнее — машины не стоят на зебре. Это — ожидаемый результат от внедрения правила, или методики.

    Кто помнит, в какой степени это правило выполнялось лет 10 назад? Я помню — ни в какой, или в никакой, не знаю, как правильнее сказать.

    Если бы 10 лет назад кто-то спросил: какова эффективность вот этой маленькой методики — правила про стоп-линию — в деле борьбы с заторами на перекрестках, что бы ему ответили? Эффективность равна нулю, а методика — фуфло, потому что не работает. И руководителя проекта изменений надо выгнать к чертям.

    А что сейчас? Посмотрите сами, на крупных перекрестках. Почти все машины, невзирая на стоимость и самомнение владельцев, останавливаются, как вкопанные. Причем, не на стоп-линии, а за 1-2 метра до нее, на всякий случай.

    Результат есть? Конечно, это видно невооруженным взглядом — заторов на перекрестках стало меньше.

    Что изменилось? Ответ вы знаете — на перекрестках появились камеры, которые автоматически фиксируют пересечение стоп-линии, определяется номер и выписывается штраф.

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

    Но главное — в том, что обеспечив подчинение, человек доказал действенность методики.

    Рассмотрите сами, если хотите, в той же последовательности внедрение эвакуаторов. Да, сразу скажу, я не сторонник и не противник этих правил, мне они интересны, как проекты изменений.

    Методика — фуфло


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

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

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

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

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

    А про теорию ограничений что пишут? Про критическую цепь? Про контроллинг? Про self-management? Про boundary management? Продолжать можно до бесконечности, но смысл один — «методика не рабочая, сырая, не подходит для наших особых условий, это только для стартапов, это не научный подход, бла-бла-бла».

    Как формируется такое мнение — «методика — фуфло»? Рассмотрим обобщенный пример того, как это происходит в бизнесе.

    Вот придумал руководитель изменение. В худшем, но самом простом случае — лишь объявил подчиненным или коллегам — все, теперь вы работаете по такой-то методике. Это может быть скрам, ТОС, Lean, Канбан, Standard Work и т.д… Вот вам ссылка, там написано, что надо делать, жду результатов.

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

    Если руководитель изменений адаптирует методику к своим реалиям, объяснит правила, обеспечит наличие бизнес-процессов и инструкций, то шансы уже выше.

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

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

    А руководитель побежал к выходу черного ящика, и стал ждать результатов. Ждет, ждет, и вот показалась та же голова — вот, говорит, результат.

    Но ведь результат такой же, как вчера?! — говорит руководитель — где изменения?
    А я че — отвечает голова — мы все делали по инструкции.
    Точно? — спрашивает руководитель — доведете меня до ручки, разберу ваш ящик и проверю!
    Точно-точно — кивает голова — ты наш босс, мы тебя уважаем, бла-бла-бла. Метода, наверное, фиговая, новомодная какая-то, подсунули тебе, за лоха держат. Нафига тебе эти глупости, ты у нас сам во всем разберешься, без этой умной хрени.
    Ладно, подумаю еще — говорит усталый, но довольный руководитель.

    И отправляется писать отчет и делать презентацию о том, как он организовал проект изменений по методике agile, с применением концепции fail fast, fail cheap, результатом которой стал однозначный вывод об ущербности методики_такой-то для предприятий_такого-то_профиля.

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

    Да еще статью напиши в журнал про методику_такую-то! — добавляет генерал — чтоб все знали, что нельзя ее применять на предприятиях_такого-то_профиля!

    А в черном ящике голова думает, как снова смыть с задницы следы тонера — бумагой для офисной техники формата А4, 80 г/кв.м., белизна 146 %, с 5-процентным заполнением, не так-то легко подтираться.

    Вот мнение и сформировалось — «методика — фуфло», и оно будет тиражироваться — как минимум, внутри компании. А если у того парня дойдут руки, то и статья выйдет, может даже на Хабре — очередная плаксиво-агрессивная история о том, что методика_такая-то — фуфло.

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

    Примеров подхода "методика_такая-то — фуфло" — масса. Они отличаются двумя характерными свойствами:

    1. Вывод про то, что методика — фуфло;
    2. Неподчинение на элементарном уровне.

    Примеры


    Вот несколько из моей практики, кратенько.

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

    Стали в цехе применять элементарные методы SPC (статистическое управление процессами). Рабочему написали в тех.карте — измеряй каждую десятую деталь. Толковые люди написали — знали, что времени у рабочего — вагон, а измерения сведут брак от фактического процента к вероятному. Но рабочий не измеряет. Ни один рабочий не измеряет. Потому что ни один рабочий не измеряет ). Результат — брак, до 100 % деталей. В итоге решили: «SPC — это для японцев, у нас станки старые, мы уж как-нибудь так… И бракованные детали ведь крутятся».

    В отделе закупок очень известные внедренцы теории ограничений Голдратта внедряли новый бизнес-процесс, по методу «барабан-буфер-канат». Все было автоматизировано, оставалось одно узкое место — решение о количестве заказываемых деталей принимал менеджер. И он принял — покупал 100 штук, когда по методике требовалось 20. Очень известные внедренцы спрашивали — чего ж ты, гадина такая, 100 покупаешь? Я же не дурак — отвечал менеджер — завтра они клиентам понадобятся, а у меня нету. В итоге решили: «Теория ограничений не подходит для нашего предприятия_такого-то_профиля, мы будем составлять план закупок на год».

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

    Возвращаемся к #Ускорению4X


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

    Это — две крайности, в которые нам нельзя залезать. Сделать суррогат из методики #Ускорение4X — сложнее, чем из скрама, например, потому что ожидаемый результат заложен в названии.

    Но сделать «методика — фуфло» — раз плюнуть. Такой результат вообще легко достигается — можно даже публикацию не дочитывать, а сразу минус поставить. Если у вас ровно такой настрой, то за #Ускорение4X лучше не браться вообще.

    А если настрой правильный, то вот вам радостная новость — мы, авторы #Ускорения4X, собаку съели на разборе черных ящиков, и контролю исполнения методики уделяем самое пристальное внимание. Везде, где только можно, мы будем рассказывать о способах контроля — прямых, косвенных, количественных, альтернативных, и т.д. Потому что мы много — очень много раз видели, как сильно влияет неподчинение на проекты изменений. И знаем, что причина провала почти всегда одна и та же.

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

    Самоподчинение


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

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

    Если вам повезло, и внедрять #Ускорение4X вас просто кто-то заставил — отлично, выводите проект в суррогат, или в «методика — фуфло». Мы даже помочь в этом можем — напишем публикацию-проходилку, которая подскажет правильные точки приложения усилий для увода проекта в песок. И не только #Ускорения4X — любого.

    Но если вы сами захотели, инициировали и реализуете проект изменений, то вам придется работать, в первую очередь, с собой. Потому что теперь все зависит от вас — и не единожды, а каждый день, на весь период внедрения. А лучше — на всю жизнь, потому что #Ускорение4X — уже устаревшая методика, с ограниченным спектром действия и не очень высоким результатом — всего лишь ускоряет работу команды в 4 раза.

    О том, как контролировать себя, мы тоже будем писать. Расскажем об инструментах и приемах, которые применяли мы сами. Постараемся поддержать, если сможем. Может, flowcon к тому времени запустим, чтобы вам не возиться с ПО.

    Но главный, все-таки, вы. Если будет успех, то причиной будете вы. Если будет провал, то причиной будете вы.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 25
    • +1
      мы, авторы #Ускорения4X, собаку съели на разборе черных ящиков, и контролю исполнения методики уделяем самое пристальное внимание. Везде, где только можно, мы будем рассказывать о способах контроля — прямых, косвенных, количественных, альтернативных, и т.д.

      Меня терзают смутные сомнения, что в конце будет KPI для программистов.
      Автор, ну скажите, что это не так!
      • +2
        Нет, мы это проходили в другой жизни. Прикольно, но не то.
        • +1
          А там занятная у вас статья, спасибо
          • 0
            Спасибо на добром слове, добрый человек.
      • +1
        Стадии внедрения новой методологии:

        Отрицание
        Гнев
        Торг
        Депрессия
        Принятие

        <:o)
        • 0
          А кто осуществляет этот тотальный контроль?
          Я правильно понимаю, что Вы отказываетесь от такой базовой вещи в скраме, как самоорганизация команд, в пользу «внешнего» (по отношению к команде) управления и контроля?
          Т.е. по сути строится «полицейский» (ну или «детсадовский») недоскрам?

          P.S.
          Я не отрицаю того факта, что даже в IT внедрение Agile и Scrum дается очень и очень непросто. И я вижу 2 составляющих этой проблемы: особенности менталитета и внедрение через ритуалы, а не философию.
          Но если предлагается некая авторская методология, зачем вообще использовать терминологию и роли из скрама? Они же только вводят в заблуждение.
          • 0
            А кто осуществляет этот тотальный контроль?

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

            Я правильно понимаю, что Вы отказываетесь от такой базовой вещи в скраме, как самоорганизация команд

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

            Но если предлагается некая авторская методология, зачем вообще использовать терминологию и роли из скрама?

            Об этом говорилось в прошлой публикации. Авторская методика — это fork scrum, ровно как и написано в оригинальной методике. Часть терминов, ролей, процессов и фишек от скрама остались. Если их переобзывать по-своему, то придется вести таблицу соответствий.
            • 0
              Подождите, «подчинение» не входит в описание роли или круга задач скрам-мастера в Скрам Гайде.
              И скрам-мастер — это все-таки не выборная должность. Откуда у команды понимание, кто сможет построить процесс, о котором команда не имеет четкого понимания?

              Вы озвучили 3 принципа (лично мне их тяжело воспринимать по причине отсутствия сказуемых — только подлежащие и дополнения, приходится восстанавливать из контекста, но это отдельный вопрос).
              Как эти принципы соотносятся со скрам-гайдом?
              • +1

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


                В книге про скрам, того же автора, написано прямо противоположное.


                Книга — первоисточник, оригинал. Скрам гайд — производная, причем низкого качества.


                Увы. #Ускорение4X соотносится со скрам гайдом так же, как скрам соотносится со скрам гайдом — никак. Слова похожи, но не более того.

                • 0
                  Там прямо так и написано — запрещено менять, убирать и добавлять.

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


                  И я думаю, что это как раз вполне естественная реакция на печальный опыт имплементации недоскрамов — когда процесс начинают «адаптировать» до полноценного внедрения и понимания, за счет чего он на самом деле работает:
                  Скрам является:
                  • компактным;
                  • простым для понимания;
                  • трудным для совершенного овладения
                  .


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

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

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

                    Это все равно, что пытаться понять медицину по методичке оказания первой помощи, которую в институте давали. Не помню, как предмет назывался, там еще надо было искусственное дыхание делать манекену.
                    • +1
                      История изложена на scrum.org.
                      Как и предполагалось, основная причина — борьба с недоскрамами (или «дряблыми» скрамами в терминологии авторов, или суррогатами в Вашей термиологии):

                      By early 2009, more organizations were using Agile processes than waterfall processes, and of those employing Agile 84% were using Scrum. However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. Martin Fowler wrote in his blog that he was encountering many instances of «Flaccid Scrum.» Teams were using Scrum vocabulary but weren’t able to create a potentially shippable increment of functionality within a single Sprint.

                      Т.ч. мне не очень понятна Ваша неприязнь к Скрам Гайду (который этот самый фреймворк формализует).
                      • 0
                        Мне ключевой показалась другая фраза:
                        This journey has been shaped by two opposing forces: the desire to do the right thing, and the desire to make money.


                        Значит, в предыдущей статье я был прав наполовину:
                        Корень проблемы кроется в упрощении методики. Кто это упрощение сделал – не знаю. Вероятно, консультанты, которые изучили методику и должны были ее продавать. Продать скрам с ускорением до 4X за короткое время – нельзя, потому что для получения высокого результата невозможно использовать только инструкции из книги – нужно искать пути оптимизации для конкретной команды… Намного проще, с точки зрения бизнеса консультанта, продать инструкцию, научить выполнять эту инструкцию и получить свои деньги


                        Честно, не знал, что и авторы скрама пошли по этому пути.

                        Это и ужасная, и прекрасная новость.

                        Ужас в том, что скоро никто не вспомнит, зачем был создан скрам и в чем его смысл.

                        Прелесть в том, что у нас не осталось конкурентов.

                        мне не очень понятна Ваша неприязнь к Скрам Гайду

                        попробуйте найти в нем раздел про непрерывное совершенствование.
                        • +1
                          Ну вообще мне кажется, что инспекция и адаптация как раз и есть про непрерывное совершенствование. А ревью и ретроспектива — инструменты, используемые для инициирования изменений. Ошибаюсь?
                          С целью улучшения степени прогнозируемости и эффективности управления рисками, Скрам использует итеративный и инкрементальный подход. Процесс эмпирического управления основан на «трех китах»: прозрачности, инспекции и адаптации.

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

                          • –1
                            Ну вообще мне кажется, что инспекция и адаптация как раз и есть про непрерывное совершенствование.

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

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

                            Ладно, чего-то разнылся я. Если у вас получается ускорить разработку в разы, используя скрам гайд — ок, рад за вас. Пишите опыт, с удовольствием почитаю, ибо такого опыта в публичном пространстве практически нет. Одни гайды :)
              • +1
                Добавьте ссылки на предыдущие статьи, чтобы удобнее было ориентироваться
                • 0
                  Учту на будущее. Честно думал, что профиля достаточно.
                  • +1
                    Вы публикуете 3-4 статьи в месяц (усредняя). Если будете продолжать такими темпами — ориентироваться по профилю скоро станет неудобно.
                    • +1
                      Ок, я понял, учту. Спасибо.
                • +1
                  В Википедии есть правило ИВП «Игнорируйте все правила».
                  ru.wikipedia.org/wiki/ВП: ИВП
                  • 0
                    И на это есть ответ в скрам-гайде:
                    Роли, артефакты, правила и события Скрама не подлежат
                    изменению. При внедрении отдельных элементов данного фреймворка, полученный
                    результат не может называться Скрамом.


                    Авторы же не запрещают частичную имплементацию, им просто не нравится, когда ее называют скрамом.
                  • 0

                    Хорошая ссылка, спасибо.


                    В книге про скрам написано примерно то же самое.

                    • +1
                      Спасибо за серию статей, очень интересно знать опыт коллег по счастью/несчастью. У меня есть вопрос насчет системного подчинения — правильно ли я понимаю, что вы имеете ввиду создание механизмов поощрения/порицания, которые воздействуют на объект управления таким образом, что он сам принимает решение о подчинении? (я бы заменил слово на сотрудничество, звучит менее отталкивающе чтоли).

                      Т.е., для примера, с штрафом за заезд за стоп линию — решение о не заезде принимает сам водитель. Он может и заехать, но это ему дороже (негативное подкрепление)?

                      В дальнейших статьях вы поделитесь приемами обеспечения системного подчинения(сотрудничества)?
                      • +1
                        правильно ли я понимаю, что вы имеете ввиду создание механизмов поощрения/порицания, которые воздействуют на объект управления таким образом, что он сам принимает решение о подчинении?


                        Нет. То, что вы описываете — путь системы мотивации. Он тоже вполне себе ничего, некоторым больше нравится.

                        На днях должна следующая публикация серии #Ускорение4X выйти, там будет поподробнее про подчинение.

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