#Ускорение4X. Принцип № 0/1. Изменяемая среда

    Итак, мы хотим ускорить разработку в 4 раза. Нет, мы не хотим, мы уже ускорили. Вы хотите.
    Серебряной пули, ускоряющей в 4 раза, нет. Есть целая обойма пуль разного калибра, типа, убойной силы и применимости в конкретной ситуации.

    Я просто расскажу вам, как это делали мы. Какие нашли решения, фишки, подходы, философию. Нужно это вам или нет – решайте сами. Мы не навязываем. Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре. Тут же разработчики опытом обмениваются? Все спрашивающим будем ссылки давать.

    На высшую истину и полное раскрытие темы не претендуем, спорить ни с кем не собираемся, мы этот путь прошли. Хотите – тоже проходите.

    Если согласны – под кат.

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

    Подходы – это базовые принципы, применяя которые, можно найти решения. Применяя подходы, решения можно внедрить. Подходы + решения дают 4X.

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

    Все, хватит ходить вокруг да около, все всё поняли, погнали к делу.

    Главное, что надо сделать для ускорения 4X – создать изменяемую среду в своей команде. Сразу скажу – если у вас нет команды, вы один, то считайте командой себя. Часть принципов окажутся для вас неприменимыми, часть – наоборот, будут более эффективными.

    Часто спрашивают – а если у нас удаленная команда? А это то, что надо. У нас тоже была и есть удаленная команда. Но мы иногда встречаемся. Классический скрам говорит, что встречаться надо каждый день, но у нас не классический скрам, а «немецкий». Ну, надо было как-то назвать наш fork.

    Если вы с командой не встречаетесь, то считайте себя одиночкой+, т.к. некоторые методы командной работы для вас применимы – есть же скайп, например.

    Изменяемая среда – это отсутствие формальных, утвержденных алгоритмов работы. Только временные, которые иногда живут один день, иногда один час.

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

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

    Теперь надо переключить программистов в другой режим – отладку. Только отлаживать надо не код, а работу команды.

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

    Важно, что в режиме отладки все понимают – это временно. Цель – как раз создать алгоритм, но работающий и проверенный, вместо никакого.

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

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

    В том, что они не программисты. А значит, они не понимают, что такое отладка и зачем она нужна. Они пишут снапшот – снимок реальности «как есть», который устаревает через минуту. И им, в общем-то, насрать, будет он работать или нет.

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

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

    Ну да и хрен с ними, у нас своих дел полно.

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

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

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

    Если скрам-мастер решил, что с этой минуты мы не отвечает на телефонные звонки – значит, мы не отвечаем на телефонные звонки. Никто, никому, никогда. Пока не поступит новая инструкция.

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

    Написали вы кусок, запустили, увидели ошибку, исправили в исходнике, запустили снова, а хром вам говорит – «эээ, неее, мы так не договаривались, я не буду тебе каждую минуту перезапускать отладку, давай по бизнес-процессу, не чаще раза в час, и вообще согласуй с Сергеем Брином». Бред? Бред.

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

    Ладно внешние – везде полно бюрократов. Но и внутренние сопротивляются.

    Представьте, как изменится скорость отладки, если вы для теста объявляете в коде переменную, присваиваете ей значение, запускаете отладчик, доходите до этой строчки и видите, что значение не присвоилось. Почему? Открываете консоль, а там написано: «не удалось присвоить значение переменной qty1, потому что она не хочет».

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

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

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

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

    Всех с наступающим Новым Годом!
    Поделиться публикацией

    Комментарии 23

      0
      TL;DR
      Команда должна стать средой исполнения – гибкой, адаптивной, не возражающей.

      Тут завуалированное требование «будь послушным».

      А представьте, если бы возражал? Как изменилась бы скорость вашей работы?
      Скорость бы уменьшилась. Однако люди возражают по разным причинам. Выяснение причины может увеличить качество работы. Или вопрос качества тут не интересен?
        0
        Про возражения будет отдельная публикация.
        0
        всё вроде бы здорово, не пойму как членов команды премировать или наказывать. Как отслеживать работу отдельного члена команды. Мне кажется, что метод будет работать только для тех кому интересно и кто сам себя приучил.
          0
          Как отслеживать работу отдельного члена команды

          об этом будет отдельная публикация.
          как членов команды премировать или наказывать

          об этом тоже.

          Всю методику буду по частям публиковать, чтобы не было простыни.
          0
          Мои поздравления. Вам удалось собрать команду.
            0
            Думаю, не собрать, а создать. Это был целенаправленный процесс, превращение коллектива в команду.
            Об этом будет отдельная публикация.
            0
            LOL, хотите чтобы люди и коллективы были как Crome, как программы, будете их запускать, останавливать, подвешивать в отладчике
            Это, батенька, профдеформация
              0
              были как Crome, как программы, будете их запускать, останавливать, подвешивать в отладчике

              нет, люди — это люди. Объяснение в таких терминах, из моей практики, понятнее программистам. Менеджерам по-другому понятнее, чернокнижникам — в терминах цикла Деминга, и т.д.
              Это просто форма подачи одной и той же информации.
              0
              но тогда это ничего не значит
                0
                вы про что?
                +1
                Я просто расскажу вам, как это делали мы.

                Извиняюсь за назойливость, но опять повторю свой вопрос — на командах какого размера, каких проектах и за какое время было достигнуто 4x?
                Команда должна стать средой исполнения – гибкой, адаптивной, не возражающей.

                Я бы сказал, что это несколько противоречит «самоорганизующейся команде» и «доверительным отношениям» из Agile. Я правильно понимаю, что залог успеха — всесилие скрам-мастера?
                Раньше была добротная статья про измерения, есть критерии успеха для этого базового принципа?
                  0

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

                    +1
                    У меня 3 вопроса, признаю, что 2 последних могут быть отражены в последующих статьях. А что с первым про контекст организации?
                    Вот придет СберТеч с командой в 6 тыс. человек. Им тоже будет 4x?
                      0
                      У нас была команда 5 человек. Скрам рекомендует до 9 человек, насколько я помню.

                      Если придет сбер с 6 тыс.человек, то они поделятся на небольшие команды, и получат суммарное ускорение БОЛЬШЕ, чем в 4 раза, по сравнению с тем, что есть у них сейчас. Потенциал ускорения взаимодействующих команд в разы выше, чем одной команды, и тем более одного человека.

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

                      Наберитесь терпения, дружище.

                      Без обид, но именно про такие расспросы написано в начале статьи: «Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре».

                      Это не про то, что мы чего-то там про себя думаем. Мы — программисты, и не любим делать одну работу много раз.
                        +1
                        Спасибо!
                        Не сочтите за придирки, но до 9-ти человек — это все-таки рекомендуемый размер скрам-команд, а не скрама вообще. При больших командах уже требуются какие-то методики масштабирования скрама (тот же nexus, хоть я его и не люблю), но это офф-топик.
                        По поводу мало-изученности agile/scrum для больших команд не соглашусь, есть же целое направление agile for enterprise со своей спецификой, но это опять же офф-топик.
                        Запасусь терпением и буду ждать дальнейших статей :-)
                          0
                          По поводу мало-изученности agile/scrum для больших команд не соглашусь

                          не для больших команд, а для большого количества команд. Если точнее, то — для управления границами, будь то команды, отделы, функции, бизнес-процессы, цели и т.д. Но это тоже оффтоп.
                  0
                  Отладчик хрома ведь не возражает против кода, который вы в нем дебажите? А представьте, если бы возражал?
                  Написали вы кусок, запустили, увидели ошибку, исправили в исходнике, запустили снова, а хром вам говорит – "эээ, неее, мы так не договаривались"

                  Отладчик Хрома написан и работает в соотвествии со строгими правилами. Как минимум спецификация JavaScript и спецификация V8. Если вы попробуете выполнить код на C++ или подсунете неверный байт-код, он, представьте себе, так и скажет — "мы так не договаривались".

                    0
                    так и скажет — «мы так не договаривались».

                    наверное, все-таки, скажет что-то типа «Uncaught SyntaxError: Unexpected identifier» или «Uncaught SyntaxError: Unexpected token :».

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

                    Да и вообще не важно это, вроде. Вы же поняли, о чем абзац. Пусть и не идеальная аналогия подобрана.
                      0
                      Ну можно ajax-запросы на другой домен взять. Я о том, что совет неправильный, причем даже ваша аналогия это показывает.
                    0

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

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

                      Быстрая разработка — это вы про экстремальное программирование? Не могу уловить коннотацию.
                        –1
                        Это я про резко сократившиеся сроки. Либо у вас раньше было все неоптимально организовано, а сейчас стало нормально как у всех, либо раньше было нормально, а сейчас стало хуже качество, за счет того, что вы убрали часть нужных мероприятий. Причем возможно вы еще не дошли до момента когда появятся последствия, а возможно вам это не грозит потому что у вас приложения маленькие. В любом случае ваш кейс для большинства неприемлем.
                          +1
                          В любом случае ваш кейс для большинства неприемлем.

                          Хм, ладно.
                          На высшую истину и полное раскрытие темы не претендуем, спорить ни с кем не собираемся, мы этот путь прошли. Хотите – тоже проходите.

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

                    Самое читаемое