Принцип быстрой автоматизации

29.10.18

Управление проектом

Как выполняется автоматизация в бизнес-программировании?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    2993    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4104    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3443    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

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

20.12.2023    3324    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15057    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6170    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5231    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5799    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. itriot11 95 29.10.18 12:22 Сейчас в теме
Надеюсь, благодаря таким статьям, нас собеседованиях меня перестанут считать "неучем, бездарем и новичком", но бизнес-программистом)))
2. 1c-intelligence 12825 29.10.18 12:23 Сейчас в теме
(1) благодаря статьям - нет. Только практика.
3. itriot11 95 29.10.18 12:27 Сейчас в теме
(2) увы, пока многим командам известна практика только через ТЗ.
4. 1c-intelligence 12825 29.10.18 12:28 Сейчас в теме
(3) это потому, что они работают только с автоматизацией. Когда они попробуют взяться за задачу шире - например, менять и процесс, и его автоматизацию - про ТЗ быстро забудут.
5. itriot11 95 29.10.18 12:33 Сейчас в теме
(4)
например, менять и процесс, и его автоматизацию

и когда об этом начинаешь говорить, то морщат нос в непонимании.
Когда они попробуют

- вот именно в этом для меня ценность данной статьи
6. 1c-intelligence 12825 29.10.18 12:38 Сейчас в теме
(5) правильно, потому что никто не знает, кто такие бизнес-программисты. И не узнают, и не поймут, пока мы об этом будем просто разговаривать. Надо делать, и на практических примерах объяснять.
7. itriot11 95 29.10.18 12:44 Сейчас в теме
(6) напомни, пожалуйста, термин "бизнес-программист" твой или заимствован где-то? Вроде первое, но не помню в какой статье была об этом речь.
8. 1c-intelligence 12825 29.10.18 12:49 Сейчас в теме
9. genayo 29.10.18 12:54 Сейчас в теме
Автоматизация итеративный процесс, и с этой точки зрения жесткое ТЗ, конечно, вредно. Но жесткое ТЗ нужно, если Заказчик и Исполнитель не уверены в квалификации и честности друг-друга.
10. itriot11 95 29.10.18 13:03 Сейчас в теме
(9) ТЗ может быть и чаще всего должно. Но работа над ним не должна ограничивать начало работ над автоматизацией, тем более когда она потенциально полезна.
11. TopZlodey 13 29.10.18 14:52 Сейчас в теме
(10) Тут вы правы, даже был у меня схожий пример, когда была скажем так относительно "небольшая" автоматизация производства и тз писалось руководством компании, которое к сожалению абсолютно не понимало специфику своего производства и как реально работают люди!)
Директору все естественно нравилось в его плане, руководителям нравились их задумки, но ровно до тех пор пока не начались пробные полеты с сотрудниками и не выяснилось что персонал у них так не работает, а вся топорность продуманного плана не позволяет в принципе нормально выполнять свою работу...
19. AlexCherdakov 21 08.11.18 06:28 Сейчас в теме
(11) и так у нас в 99.(9)% случаев...
12. itriot11 95 29.10.18 15:08 Сейчас в теме
(10) Тут я пропустил слово "очевидно" перед "полезно". А таковой автоматизация может стать только после того, как будет озвучена ее цель для всех участников хеппенинга.
13. yyv-911 29.10.18 16:40 Сейчас в теме
эдак получается я бизнес-программист. ))) то то я себя программистом не считаю...

если серьезно то такой подход свойственен одиночкам. Объяснить программистам нафига нужно, то или иное изменение - это огромная проблема.
Есть другая проблема. Это объяснения бизнесу что прототип нужно довести до логического конца. И здесь ещё больше проблем.

Дорого. Очень дорого получается.
14. user598655_ilia-bers 30.10.18 10:08 Сейчас в теме
Работал в такой шараге, где бизнес процессы менялись на ходу 2 раза в неделю для эксперимента, для того чтобы быстро закрыть косяки руководства, бухии, торговиков и т. д. В результате 95 % работы в мусор, все эти нововведения потом никому не нужны и никто не пользуется, и как то само пришло, что если что-то кому-то нужно так срочно, что аж кушать не может, то отодвигаем на пару месяцев, если после этого кто-то про это вспомнит, то можно и подумать о реализации.
15. itriot11 95 30.10.18 10:43 Сейчас в теме
(14) любопытно было бы взглянуть на такие бизнес процессы,которые можно менять дважды в неделю.
никому не нужны и никто не пользуется

Пробовали показать собственникам, на что уходят ИХ ресурсы?
кому-то нужно так срочно, что аж кушать не может

Вот в таких случаях нужно ТЗ оформленное ручками инициатора и согласованное со всеми заинтересованными. Так скажем, эта бумажка и работа с ней заменяет плату. Иначе пользователи могут разбаловаться, начинают считать ИТ-отдел персональной обслугой. Конечно, речь идет не о ТЗ по ГОСТу, скорее описание функциональных требований. Но требования к их глубине и объему можно регулировать, тем самым вполне "законно" влияя на градус накала новатора)
16. Silenser 610 30.10.18 14:37 Сейчас в теме
Изменили процесс, быстро автоматизировали, посмотрели на результат. Годится – быстро доводим до ума. Не годится –выкидываем.

Если не ошибаюсь, этот метод называют Fail Fast Fail Cheap.
17. 1c-intelligence 12825 30.10.18 14:42 Сейчас в теме
(16) верно. Только это не метод, а принцип - универсальный, применимый хоть к чему. В данном случае использован, как основа хоть немного прикладного метода.
18. pm74 201 30.10.18 19:52 Сейчас в теме
(0) пожалуй соглашусь со всем кроме удаления изменений
Оставьте свое сообщение