Тяп-ляп и в продакшн? Почему бы и нет

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

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

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

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

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

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

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

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

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

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

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

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

    Отчасти программисты правы. Но у них – принципиально другой контекст. Обычно ведь как делается. Есть некие «изменяторы» — бизнес-аналитики, пользователи и их руководители. Они чего-то там придумали, и говорят – так, быстро сделай мне форму/поле/окно. Что, как, зачем, почему – не объясняют. Еще добавляют – быстро давай, валенок. Что остается программисту? Если есть возможность, он начнет бухтеть – говорить, что так нельзя, что нужно техническое задание, продуманная архитектура, рефакторинг и т.д. Но, обычно, возможности побухтеть нет, и программист просто делает – быстро, «на коленке», в режиме экстремального программирования.

    Ну, вроде, и ладно, черт с ним, так ведь? Я же именно так и предложил – быстро, без заморочек, лишь бы заработало?

    Ключевой момент возникает, когда «изменяторы» видят бессмысленность изменений. Бизнес-программист такие изменения просто отменит, и попросит программиста удалить внесенные куски кода. А «изменятор»? Или, точнее, «горе-изменятор»?

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

    Здесь есть политический момент, особенно если изменения придумал руководитель отдела. Для него крайне важно не выглядеть глупо, поэтому, какой бы ерунды он не придумал, отменять ее не станет. Более того, если припереть его к стенке, будет защищать свои изменения.

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

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

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

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

    Но когда изменения вносятся «просто так», или «чтобы мне удобнее было», или «ну так же правильно!», оценить результат не получается. Поэтому изменения, какими бы они не были бессмысленными, остаются жить – и в процессе, и в автоматизации.

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

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

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

    Допустим, изменения оказались неправильными – это нормально, ничего плохого в этом нет. Тогда у программистов появляется несвойственная работа – удалять изменения в системе. Они, конечно, иногда такой работой сами занимаются – рефакторингом, например. Но в случае с бизнес-программированием такую работу надо делать периодически.

    А если изменения оказались правильными? Тогда в дело вступают все навыки «правильной» автоматизации, которыми так гордятся программисты. Нужно прикинуть архитектуру, структуру данных, алгоритмы, проверку введенных данных, интерфейс и т.д. Но в чем разница, видите?

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

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

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

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

    И вы теперь понимаете, почему. Автоматизация – это почти всегда телега, а не лошадь. Лошадь – это изменение процессов, а телега едет следом. Но едет только в том случае, если прицеплена к лошади.

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

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

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

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

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

      +15
      Одной из самых частых причин графомании некоторые исследователи называют гиперкомпенсацию комплекса неполноценности, а часть случаев — выражением бредовой или сверхценной идеи идентификации себя с выдающимся писателем…
      Графомания встречается при некоторых формах шизофрении, паранойе, маниакальном и гипоманиакальном состояниях, и при других психических расстройствах. При синдроме психического автоматизма (Кандинского — Клерамбо) больные могут говорить, что их вынуждают много писа́ть некие внешние силы. Графоманические тенденции нередки у сутяжных психопатов (при параноидном расстройстве личности).
      Вики.
        0
          –2

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

            0
            С радостью бы пообщался, но я где-то на третьем вашем комментарии перестал понимать, о чем вы говорите и причем тут я.
            Удачи.
        0
        Есть такое понятие — стоимость ошибки.
        — иногда стоимость ошибки не видна сразу;
        — иногда стоимость ошибки специально скрывается, чтобы попробовать изменение;
        — и в любом из таких случаев — стоимость ошибки ложиться не на «бизнес-программиста», а на владельца;
        — учитывая сложность производств, сложность ИТ, сложность процессов, некий «пропагандон» даром убеждения или иными мотивами, может добиться со стороны decision maker нужного ему решения, но ту надо понимать, что всем чем рискует тот самый бизнес-программист. так это своим местом, а вот владельцы рискуют серьезными средствами; т.о. — только прототипирование, только pre-prod, только анализ, никаких таких кавалерийских наскоков в духе илона_маска (если за вами не стоит наса, прав-во сша и деньги инвесторов);
        — и наконец, автоматизация это всегда сопутствующее (если мы не про бизнес в ит), а не основное средство производства, имеет вторичные половые финансовые признаки (попробуйте пожалуйста оспорить с цифрами на примере нефтегаза), поэтому, ставить во главу угла мифического бизнес-программера — мифически глупо. Как-бы не было обидно бизнес-програмеру.
          0
          По-моему во главу ставят не бизнес-программиста, а изменения процесса. И изменять советуют понемного, чтобы цену ошибки снизить. Для производства и заводских процессов (сталелитейного например) нужнен уже жестко зарегламентированный фронт работ. Здесь про небольшие изменения.
            0
            Да много всяких понятий есть.
            Во главу угла ставятся реальные, быстрые и полезные изменения. Если перечисленные вами термины как-то помогают этой цели достигать — прекрасно.
            0
            А что мешает пробовать сначала на тестовой системе?
              0
              а смысл? Бизнес-процесс изменен в реальной жизни, а работать люди будут в тестовой системе? Зачем?
                0
                Для проверки.
                Изменили попробовал, поправили, ещё раз проверили.
                Если понравилось переносим в рабочую систему.
                Не нужно откатывать из рабочей не понравившиеся изменения.
                  0
                  А с данными как быть?
                    0
                    Так тестовая же система — не замена рабочей.
                      0
                      Ну. Чтобы проверить качество изменения процесса, поддержанного автоматизацией, нужно выполнять измененный процесс, поддержанный автоматизацией. При использовании тестовой системой вы не можете этого делать — данных или нет, или они не актуальны.
                      В результате вы не можете протестировать свой процесс. И просто становитесь в очередь на автоматизацию. Гипотеза, выдвинутая при изменении процесса, будет проверена черт знает когда. И будет ли вообще. И изменений не будет.
                        +1
                        Ну, почему так однозначно?
                        Никто же не мешает поддерживать актуальность тестовой системы, хоть ежедневно.
              +3
              автор изобретает свой правильный срам?
                –3
                правильный скрам я изобрел два года назад. Статья не об этом.
                  0
                  Более правильный чем был придуман до вас?
                  Не тот ли где вы описывали поминутную тарификацию для программистов?
                    0
                    как я понял, в статье излагается подход a la agile, только в применении к бизнес-процессам: выкатывай рано и небольшими порциями, лажай быстро, чтобы, в случае необходимости, быстро откатить. как оно называется — дело десятое.
                  0
                  Серия мелких «улучшений» общей системы с гораздо большей вероятностью ухудшит функционирование всей системы, чем даст улучшение… По большей части такие обсуждения приводят к автоматизации текущего бардака. Какая цель «комплексных изменений»? Не думаю, что именно в этом…
                  Что можно улучшить в небольшой части системы? Как изменения полей, форм и отчетов улучшат работу системы? Никак, можно только объявить, что вот такого отчета больше не будет по причине его ненужности, а вместо вот этих 2 форм будет одна общая.
                  При этом еще будет масса возражения — как это без отчета, мы его всегда печатаем и подшиваем. На вопрос — какие управленческие решения принимаются на основании данных этого отчета пожимают плечами… какие решения, его нужно подшить и все.
                  Более того, обсуждение изменений с небольшим коллективом допускается только в форме объявления изменений, что теперь будет вот так. Ни одна часть системы не видит работы системы как целого, на это нужно смотреть только со стороны. Более того, по причине контринтуитивности изменения будут казаться нелогичными и ухудшающими работу этого отдела, поэтому будет сопротивление.
                  Для реального улучшения системы необходимо системное мышление, которое вряд ли можно найти среди рядовых исполнителей или даже руководителей… остаётся только надеяться, что «бизнес-программист» им обладает, что тоже сомнительно, особенно если он вырос на бизнес-проектах 1С.
                    0
                    Ключевые изменения — в процессе, то есть в жизни. Автоматизация особой роли не играет, лишь вспомогательную.
                      +1
                      Да, нужно пересмотреть принципы управления и наладить информационные потоки.
                      Без всякой автоматизации. Информационная система это вспомогательный инструмент.
                      Только когда станут понятны информационные потоки внутри предприятия, можно идти по детализации глубже — до отчетов и форм. А набор полей — вообще чисто технический вопрос…
                      И очевидно, что нет смысла обсуждать информационные потоки с рядовыми исполнителями.
                        0
                        а с кем надо обсуждать?
                          +1
                          Должен быть эксперт или группа экспертов, владеющих системным мышлением.
                          Они изучают конкретное предприятие и формируют проект изменений в принципах управления и информационных потоках (это обычно выполняется в рамках отдельного договора, не включающего в себя внедрение).
                          Дальше подключается владелец предприятия и высшее руководство, их нужно убедить в преимуществах новых подходов в управлении… и тут возможны варианты, если владелец не готов на изменения, то проект на этом завершается… если он готов, то дальше начинается работа с замдиректорами
                          Те, которые встают в жесткую оппозицию — должны быть понижены в должности или уволены, иначе вместо внедрения будет постоянное бодание с ними.
                          Работа с высшим руководством только выглядит как обсуждение, но на самом деле им не является — это объяснение новых подходов в управлении.
                          А в подразделениях можно обсуждать мелкие детали информационных потоков (формы, отчеты, поля)
                    0
                    В большинстве случаев, после изменения процесса, вам требуется автоматизация – надо внести правки в информационную систему. Если вы скажете – нужно техническое задание, план-график, проект с руководителем, куратором и спонсором, то – все.

                    Ёклмн… Если вы официальный работник фирмы, вы руководитель ИТ-отдела, и вы предлагаете изменения, то ТЗ пишете вы подчиненным. А не кто-то вам.

                      0
                      Вот тут и нужен принцип быстрой автоматизации.

                      Для этих целей и придумали Скрам.
                        0
                        скрам вроде придумали для выполнения проектов.

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

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