Как происходит при обычной автоматизации? Составляется техническое задание, функциональные требования, архитектура, и куча других бумажек. Описываются все условия, ограничения, алгоритмы работы в зависимости от окружающей среды, внешний вид форм, проверки данных и т.д. Зачастую, оформление и согласование этих бумажек занимает больше времени, чем сама автоматизация.
Появляется проект, план-график, декомпозиция задач, некий руководитель проекта, или даже несколько. Верх берут формальности, т.е. форма, а не содержание.
Понятно, что в некоторых ситуациях именно так и надо действовать. Например, если автоматизацией занимается внешняя компания – она без таких бумажек не выживет, т.к. только и будет гоняться за достижением убегающих требований. Бумажки гарантируют стабильность, прогнозируемость оплат и сдачи работ. Но вот заказчику эти бумажки гарантируют лишь одно – долгий, скучный проект, который не принесет никакой пользы.
В бизнес-программировании такой подход не годится. Напомню, бизнес-программирование – это комплексное изменение, одновременно для процессов, мотивации, целей, системы управления, поддержанное автоматизацией.
Например, решили вы изменить процесс. Не такой, который затрагивает тысячу людей – тут на коленке решение не придумаешь. Процесс, например, касается пяти человек одного отдела. Все эти люди, как и их руководитель, сидят рядом с вами – вот они, на расстоянии вытянутой руки. И вы решили, совместно с ними, изменить процесс. Сели, поговорили, прикинули, подумали, и решили. На изменение процесса у вас ушел, допустим, один день.
В большинстве случаев, после изменения процесса, вам требуется автоматизация – надо внести правки в информационную систему. Если вы скажете – нужно техническое задание, план-график, проект с руководителем, куратором и спонсором, то – все. На этом ваши изменения закончатся. Длинный проект автоматизации, обвешанный формальностями, сведет на нет изменение процесса.
Что особенно важно: изменения в процессах – это эксперименты. Вы, даже будучи умудренным опытом бизнес-программистом, не можете знать наверняка, сработает ваше изменение, или нет. Выбранный метод мог хорошо себя показать в другом процессе, или даже в точно таком же, но в другой компании, но в данном контексте он может оказаться нерабочим.
Раз это эксперимент, у него есть временные границы – сегодня придумали, завтра запустили, неделю смотрим и принимаем решение. Если все хорошо, оставляем. Если нет, думаем дальше – либо отменяем изменение, либо уточняем и улучшаем его.
А что будет с автоматизацией за эту неделю? Если выбран традиционный путь, то за неделю у вас появится только техническое задание, и то в лучшем случае. Соответственно, имплементацию изменений придется делать вручную, без автоматизации. Хорошо, если вы вносите такие изменения, которые не требуют автоматизации – можете проверить «на глазок». А если нет?
Вот тут и нужен принцип быстрой автоматизации. Собственно, его суть заключена в названии – изменения в систему нужно вносить быстро, без согласований и требований, ровно в том объеме, который требуется для проверки основной гипотезы, которую вы выдвинули, меняя процесс.
Не надо сильно заботиться об интерфейсе, проверке вводимых данных, оптимальности кода, структуре данных и прочих столпах «правильной» автоматизации. Ваша задача – быстро поддержать автоматизацией изменения в процессе, чтобы проверить, работают они или нет.
Принцип быстрой автоматизации известен всем программистам. Только они знают его не как принцип, а как великое зло – считается, что такой автоматизацией занимаются неучи, бездари и новички.
Отчасти программисты правы. Но у них – принципиально другой контекст. Обычно ведь как делается. Есть некие «изменяторы» — бизнес-аналитики, пользователи и их руководители. Они чего-то там придумали, и говорят – так, быстро сделай мне форму/поле/окно. Что, как, зачем, почему – не объясняют. Еще добавляют – быстро давай, валенок. Что остается программисту? Если есть возможность, он начнет бухтеть – говорить, что так нельзя, что нужно техническое задание, продуманная архитектура, рефакторинг и т.д. Но, обычно, возможности побухтеть нет, и программист просто делает – быстро, «на коленке», в режиме экстремального программирования.
Ну, вроде, и ладно, черт с ним, так ведь? Я же именно так и предложил – быстро, без заморочек, лишь бы заработало?
Ключевой момент возникает, когда «изменяторы» видят бессмысленность изменений. Бизнес-программист такие изменения просто отменит, и попросит программиста удалить внесенные куски кода. А «изменятор»? Или, точнее, «горе-изменятор»?
Он ничего отменять не будет. Просто оставит, как есть, и, в лучшем случае, просто продолжит вносить изменения. Понимаете? Без отмены предыдущих, будет наворачивать новые, еще и еще.
Здесь есть политический момент, особенно если изменения придумал руководитель отдела. Для него крайне важно не выглядеть глупо, поэтому, какой бы ерунды он не придумал, отменять ее не станет. Более того, если припереть его к стенке, будет защищать свои изменения.
Чаще всего случается так, что внесенными изменениями просто никто не будет пользоваться. Если вы – программист, то вам такая ситуация, возможно, знакома. Попросили, приказали, потребовали сделать какую-то систему, а потом не пользуются. Она даже может быть сделана не «на коленке», а нормально, с соблюдением всех требований и условий «правильной» автоматизации, но все равно – не пользуются. Теперь вы знаете, почему. И почему этот функционал никто не удаляет из системы – тоже теперь знаете.
Так получаются и растут слоеные пироги бессмысленной, лоскутной автоматизации. Программисты посмеиваются, но делают все, что им скажут. Гадость, неоптимальность, кривая структура и архитектура растут, как снежный ком. И чем дальше, тем сложнее будет остановить этот процесс и повернуть его вспять.
Другая проблема – бессмысленность предложенных изменений в целом.
В бизнес-программировании у любых изменений есть цель, которую понимают все участники. Процесс должен стать быстрее, или надежнее, или более контролируемым. Поэтому всегда понятно как назначение изменений, так и критерии оценки их действенности.
Но когда изменения вносятся «просто так», или «чтобы мне удобнее было», или «ну так же правильно!», оценить результат не получается. Поэтому изменения, какими бы они не были бессмысленными, остаются жить – и в процессе, и в автоматизации.
Теперь вы понимаете, в чем проблема – в разрыве между изменением процессов и автоматизацией. Когда одни люди придумывают изменения в процессе, а потом ставят задачи по автоматизации другим людям, не объясняя смысла и сути, получается обычный бардак, не приносящий пользы никому.
По стандартам бизнес-программирования работа идет в одной команде – там присутствуют и люди от процессов, и люди от автоматизации. Еще лучше, когда этой работой руководит один человек – бизнес-программист. Еще лучше, когда он делает автоматизацию сам.
В этом случае понятен и управляем жизненный цикл временных изменений – зачем они делаются, когда начинаются, и, главное, когда и при каких условиях заканчиваются.
Допустим, изменения оказались неправильными – это нормально, ничего плохого в этом нет. Тогда у программистов появляется несвойственная работа – удалять изменения в системе. Они, конечно, иногда такой работой сами занимаются – рефакторингом, например. Но в случае с бизнес-программированием такую работу надо делать периодически.
А если изменения оказались правильными? Тогда в дело вступают все навыки «правильной» автоматизации, которыми так гордятся программисты. Нужно прикинуть архитектуру, структуру данных, алгоритмы, проверку введенных данных, интерфейс и т.д. Но в чем разница, видите?
Разница в форме постановки задачи. Обычно это – техническое задание, то есть некая бумажка. В нашем же случае задание – это прототип. Рабочий, показавший свою полезность и действенность, проверенный, так сказать, в бою. Надо лишь довести его до ума. Согласовывать и обсуждать уже особо ничего не надо – просто бери и сделай систему по правилам и стандартам той среды, в которой создана программа.
Если заниматься быстрым программированием постоянно, то очень быстро приобретется навык – сразу делать так, чтобы потом поменьше исправлять. Тут нам на руку сыграет «правильная лень» программиста – ему неохота будет решать одну и ту же задачу дважды, и он сам придумает, как и прототип быстро сделать, и в законченное решение его превратить с минимальными усилиями. Хотя, в бизнес-программировании, конечно, не бывает законченных решений.
Сейчас стала распространенной такая практика, как прототипирование и моделирование, когда перед началом большого проекта автоматизации быстро, минимальными усилиями, без заморочек с интерфейсом создают некий прообраз будущей системы. Как вы понимаете, это очень похоже на принцип быстрой автоматизации, хотя дело, конечно, не в том, как создан прототип, а в том, как он будет подстраиваться под изменяющуюся среду.
Если прототипирование – это просто маркетинговый ход компании-интегратора, и потом все равно появится большая бумажка, вроде технического задания, то это – просто уловка. Она создает у заказчика иллюзию, что «все будет так, как мне надо», но, увы, в жизни так не будет. Прототип проживет недолго и сгинет в безвестности.
И вы теперь понимаете, почему. Автоматизация – это почти всегда телега, а не лошадь. Лошадь – это изменение процессов, а телега едет следом. Но едет только в том случае, если прицеплена к лошади.
Лошадь повернула, телега – следом. С задержкой, с люфтами и заносами, но повернула. А если лошадь и телега живут каждый своей жизнью, то телегу приходится таскать несчастным программистам. Большой прототип большой системы, созданный перед большим проектом автоматизации – это моментальный снимок, снапшот лошади, запряженной в телегу. Все красиво, все довольны, всем нравится, но проходит день, или неделя, или даже месяц, и лошадь бросает телегу, и идет туда, куда ей надо. А телега – красивая, нарядная, выполненная по всем канонам, остается одиноко стоять в поле.
Поэтому «большим» прототипированием увлекаться не стоит. Равно, как и «большой» автоматизацией. Для того, чтобы начать и выполнить большой проект автоматизации, надо обладать чертовски незаурядным умом, дальновидностью и невероятным талантом в управлении. Если эти слова – про вас, то я вас искренне поздравляю и желаю всяческих успехов.
Остальным же рекомендую пользоваться принципом быстрой автоматизации.
И еще раз напоминаю: автоматизация идет вслед за изменением процессов. Не перед изменением, не вместо изменения, не отдельно от изменений. Изменили процесс, быстро автоматизировали, посмотрели на результат. Годится – быстро доводим до ума. Не годится –выкидываем.
Появляется проект, план-график, декомпозиция задач, некий руководитель проекта, или даже несколько. Верх берут формальности, т.е. форма, а не содержание.
Понятно, что в некоторых ситуациях именно так и надо действовать. Например, если автоматизацией занимается внешняя компания – она без таких бумажек не выживет, т.к. только и будет гоняться за достижением убегающих требований. Бумажки гарантируют стабильность, прогнозируемость оплат и сдачи работ. Но вот заказчику эти бумажки гарантируют лишь одно – долгий, скучный проект, который не принесет никакой пользы.
В бизнес-программировании такой подход не годится. Напомню, бизнес-программирование – это комплексное изменение, одновременно для процессов, мотивации, целей, системы управления, поддержанное автоматизацией.
Например, решили вы изменить процесс. Не такой, который затрагивает тысячу людей – тут на коленке решение не придумаешь. Процесс, например, касается пяти человек одного отдела. Все эти люди, как и их руководитель, сидят рядом с вами – вот они, на расстоянии вытянутой руки. И вы решили, совместно с ними, изменить процесс. Сели, поговорили, прикинули, подумали, и решили. На изменение процесса у вас ушел, допустим, один день.
В большинстве случаев, после изменения процесса, вам требуется автоматизация – надо внести правки в информационную систему. Если вы скажете – нужно техническое задание, план-график, проект с руководителем, куратором и спонсором, то – все. На этом ваши изменения закончатся. Длинный проект автоматизации, обвешанный формальностями, сведет на нет изменение процесса.
Что особенно важно: изменения в процессах – это эксперименты. Вы, даже будучи умудренным опытом бизнес-программистом, не можете знать наверняка, сработает ваше изменение, или нет. Выбранный метод мог хорошо себя показать в другом процессе, или даже в точно таком же, но в другой компании, но в данном контексте он может оказаться нерабочим.
Раз это эксперимент, у него есть временные границы – сегодня придумали, завтра запустили, неделю смотрим и принимаем решение. Если все хорошо, оставляем. Если нет, думаем дальше – либо отменяем изменение, либо уточняем и улучшаем его.
А что будет с автоматизацией за эту неделю? Если выбран традиционный путь, то за неделю у вас появится только техническое задание, и то в лучшем случае. Соответственно, имплементацию изменений придется делать вручную, без автоматизации. Хорошо, если вы вносите такие изменения, которые не требуют автоматизации – можете проверить «на глазок». А если нет?
Вот тут и нужен принцип быстрой автоматизации. Собственно, его суть заключена в названии – изменения в систему нужно вносить быстро, без согласований и требований, ровно в том объеме, который требуется для проверки основной гипотезы, которую вы выдвинули, меняя процесс.
Не надо сильно заботиться об интерфейсе, проверке вводимых данных, оптимальности кода, структуре данных и прочих столпах «правильной» автоматизации. Ваша задача – быстро поддержать автоматизацией изменения в процессе, чтобы проверить, работают они или нет.
Принцип быстрой автоматизации известен всем программистам. Только они знают его не как принцип, а как великое зло – считается, что такой автоматизацией занимаются неучи, бездари и новички.
Отчасти программисты правы. Но у них – принципиально другой контекст. Обычно ведь как делается. Есть некие «изменяторы» — бизнес-аналитики, пользователи и их руководители. Они чего-то там придумали, и говорят – так, быстро сделай мне форму/поле/окно. Что, как, зачем, почему – не объясняют. Еще добавляют – быстро давай, валенок. Что остается программисту? Если есть возможность, он начнет бухтеть – говорить, что так нельзя, что нужно техническое задание, продуманная архитектура, рефакторинг и т.д. Но, обычно, возможности побухтеть нет, и программист просто делает – быстро, «на коленке», в режиме экстремального программирования.
Ну, вроде, и ладно, черт с ним, так ведь? Я же именно так и предложил – быстро, без заморочек, лишь бы заработало?
Ключевой момент возникает, когда «изменяторы» видят бессмысленность изменений. Бизнес-программист такие изменения просто отменит, и попросит программиста удалить внесенные куски кода. А «изменятор»? Или, точнее, «горе-изменятор»?
Он ничего отменять не будет. Просто оставит, как есть, и, в лучшем случае, просто продолжит вносить изменения. Понимаете? Без отмены предыдущих, будет наворачивать новые, еще и еще.
Здесь есть политический момент, особенно если изменения придумал руководитель отдела. Для него крайне важно не выглядеть глупо, поэтому, какой бы ерунды он не придумал, отменять ее не станет. Более того, если припереть его к стенке, будет защищать свои изменения.
Чаще всего случается так, что внесенными изменениями просто никто не будет пользоваться. Если вы – программист, то вам такая ситуация, возможно, знакома. Попросили, приказали, потребовали сделать какую-то систему, а потом не пользуются. Она даже может быть сделана не «на коленке», а нормально, с соблюдением всех требований и условий «правильной» автоматизации, но все равно – не пользуются. Теперь вы знаете, почему. И почему этот функционал никто не удаляет из системы – тоже теперь знаете.
Так получаются и растут слоеные пироги бессмысленной, лоскутной автоматизации. Программисты посмеиваются, но делают все, что им скажут. Гадость, неоптимальность, кривая структура и архитектура растут, как снежный ком. И чем дальше, тем сложнее будет остановить этот процесс и повернуть его вспять.
Другая проблема – бессмысленность предложенных изменений в целом.
В бизнес-программировании у любых изменений есть цель, которую понимают все участники. Процесс должен стать быстрее, или надежнее, или более контролируемым. Поэтому всегда понятно как назначение изменений, так и критерии оценки их действенности.
Но когда изменения вносятся «просто так», или «чтобы мне удобнее было», или «ну так же правильно!», оценить результат не получается. Поэтому изменения, какими бы они не были бессмысленными, остаются жить – и в процессе, и в автоматизации.
Теперь вы понимаете, в чем проблема – в разрыве между изменением процессов и автоматизацией. Когда одни люди придумывают изменения в процессе, а потом ставят задачи по автоматизации другим людям, не объясняя смысла и сути, получается обычный бардак, не приносящий пользы никому.
По стандартам бизнес-программирования работа идет в одной команде – там присутствуют и люди от процессов, и люди от автоматизации. Еще лучше, когда этой работой руководит один человек – бизнес-программист. Еще лучше, когда он делает автоматизацию сам.
В этом случае понятен и управляем жизненный цикл временных изменений – зачем они делаются, когда начинаются, и, главное, когда и при каких условиях заканчиваются.
Допустим, изменения оказались неправильными – это нормально, ничего плохого в этом нет. Тогда у программистов появляется несвойственная работа – удалять изменения в системе. Они, конечно, иногда такой работой сами занимаются – рефакторингом, например. Но в случае с бизнес-программированием такую работу надо делать периодически.
А если изменения оказались правильными? Тогда в дело вступают все навыки «правильной» автоматизации, которыми так гордятся программисты. Нужно прикинуть архитектуру, структуру данных, алгоритмы, проверку введенных данных, интерфейс и т.д. Но в чем разница, видите?
Разница в форме постановки задачи. Обычно это – техническое задание, то есть некая бумажка. В нашем же случае задание – это прототип. Рабочий, показавший свою полезность и действенность, проверенный, так сказать, в бою. Надо лишь довести его до ума. Согласовывать и обсуждать уже особо ничего не надо – просто бери и сделай систему по правилам и стандартам той среды, в которой создана программа.
Если заниматься быстрым программированием постоянно, то очень быстро приобретется навык – сразу делать так, чтобы потом поменьше исправлять. Тут нам на руку сыграет «правильная лень» программиста – ему неохота будет решать одну и ту же задачу дважды, и он сам придумает, как и прототип быстро сделать, и в законченное решение его превратить с минимальными усилиями. Хотя, в бизнес-программировании, конечно, не бывает законченных решений.
Сейчас стала распространенной такая практика, как прототипирование и моделирование, когда перед началом большого проекта автоматизации быстро, минимальными усилиями, без заморочек с интерфейсом создают некий прообраз будущей системы. Как вы понимаете, это очень похоже на принцип быстрой автоматизации, хотя дело, конечно, не в том, как создан прототип, а в том, как он будет подстраиваться под изменяющуюся среду.
Если прототипирование – это просто маркетинговый ход компании-интегратора, и потом все равно появится большая бумажка, вроде технического задания, то это – просто уловка. Она создает у заказчика иллюзию, что «все будет так, как мне надо», но, увы, в жизни так не будет. Прототип проживет недолго и сгинет в безвестности.
И вы теперь понимаете, почему. Автоматизация – это почти всегда телега, а не лошадь. Лошадь – это изменение процессов, а телега едет следом. Но едет только в том случае, если прицеплена к лошади.
Лошадь повернула, телега – следом. С задержкой, с люфтами и заносами, но повернула. А если лошадь и телега живут каждый своей жизнью, то телегу приходится таскать несчастным программистам. Большой прототип большой системы, созданный перед большим проектом автоматизации – это моментальный снимок, снапшот лошади, запряженной в телегу. Все красиво, все довольны, всем нравится, но проходит день, или неделя, или даже месяц, и лошадь бросает телегу, и идет туда, куда ей надо. А телега – красивая, нарядная, выполненная по всем канонам, остается одиноко стоять в поле.
Поэтому «большим» прототипированием увлекаться не стоит. Равно, как и «большой» автоматизацией. Для того, чтобы начать и выполнить большой проект автоматизации, надо обладать чертовски незаурядным умом, дальновидностью и невероятным талантом в управлении. Если эти слова – про вас, то я вас искренне поздравляю и желаю всяческих успехов.
Остальным же рекомендую пользоваться принципом быстрой автоматизации.
И еще раз напоминаю: автоматизация идет вслед за изменением процессов. Не перед изменением, не вместо изменения, не отдельно от изменений. Изменили процесс, быстро автоматизировали, посмотрели на результат. Годится – быстро доводим до ума. Не годится –выкидываем.
