Описание, синхронность и "один-много"

Управление - Бизнес-процессы

20
Продолжаем смотреть на процессы глазами программиста.

Описание процессов

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

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

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

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

Оформление процесса в виде алгоритма – это просто проекция, переложение понятной информации в некий формат. Любая проекция всегда ведет к потере части информации, либо к ее искажению. И красивая схема, и квалиграмма, и текстовое описание, и должностная инструкция – просто проекции.

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

Правило номер 1: не начинайте с описания процесса.

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

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

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

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

Правило номер 2: используйте несколько форматов одновременно.

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

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

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

Главное же – не забывайте о здравом смысле. В бизнес-программировании нет стандартов, строгих правил и законов, кроме одного: должно работать.

Синхронность и асинхронность процессов

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

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

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

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

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

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

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

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

Конечно, юристы могут возмутиться – чего это мы будем оценивать поставщика, если вы там еще четко не решили, будете ли у него заказывать? Что им ответить?

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

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

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

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

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

Типичный пример: «я буду согласовывать только после того, как согласует вот он». Или «я посмотрю на этот договор только после финансистов». Хотя, если верить статистике и здравому смыслу, подобные постановки не имеют под собой оснований, и являются лишь способом переложить ответственность.

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

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

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

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

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

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

Кроме асинхронности, есть еще более мощный метод оптимизации – буферизация процессов. О нем – в другой раз.

Конфликт "один-много"

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

«Один» - это когда действие процесса выполняется над одним объектом. Например, обработка одной заявки на закуп, одного заказа покупателя, одной заявки на расход денег.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что можете сказать об эффективности вашей программы? Ничего. Красивая, внутренне логичная, без явных ошибок. Но ни черта не понятно, работает она в жизни, или нет.

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

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

20

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Alligator84 55 09.10.18 11:28 Сейчас в теме
Отличная статья, но не совсем согласен с пунктом номер 1:
как раз таки требования к функциональности возникает из понимания процесса, процесс обязательно должен быть отражен где-либо, хоть первоначально на обрывке бумаги.
Абсолютно верно, что он не должен быть зацементированным, но лучше когда все участники процесса итеративно его рефакторят.
Т.е. собрались обсудили и переложили штрихами на бумагу (не нужно тратить времени на его графическое представление в ПК);
Переспали с этими мыслями, еще раз пересмотрели логику и когда более менее логично, формируем требования к каждому этапу процесса.
На основании этих требований и приемка, и тесты и, как не печально, разбор полетов.
5. 1c-intelligence 6447 09.10.18 11:57 Сейчас в теме
(1) все правильно пишете. Разумеется, накидать процесс на бумажке - это не "описание процесса".
21. Alligator84 55 09.10.18 14:22 Сейчас в теме
(18)
и вот как раз для исключения подобных ситуаций и нужно понимание всего процесса хотя бы на...читайте (1) для того, чтобы требования к следующему спринту не вступали в противоречия с уже выпущенной функциональностью.
2. pm74 130 09.10.18 11:37 Сейчас в теме
(0)
Поэтому, давайте, погружайте «рисователя» в реальную жизнь, пусть тоже изучает бизнес-программирование.

чаще всего "рисователь" и разработчик - один человек
6. 1c-intelligence 6447 09.10.18 11:58 Сейчас в теме
(2) мы с вами в разном Челябинске живем, похоже.
У нас обычно рисуют специальные люди, типа СМК, которым на все насрать.
8. pm74 130 09.10.18 12:08 Сейчас в теме
(6) бывает и такое "Г" приходится "автоматизировать" , далеко ходить не нужно
возьмем например ндс с авансов по договору комиссии
это имо более подходящая иллюстрация к (3)
3. pm74 130 09.10.18 11:52 Сейчас в теме
Например, тот же закуп. Объективно, снабженцу неудобно подпрыгивать и бежать исполнять каждую заявку, когда она возникла. Ему намного проще взять сразу несколько заявок – штук десять, например, причем сгруппированных по неким признакам. Например, все заявки на штамповки, или на зубодолбежку, или на резину, и выполнить их скопом. Вероятно, там и поставщик будет один и тот же, и документ надо будет оформить один. Получается, в данном случае снабженец работает с «много».

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


не совсем согласен , имо
внутренняя логика и непротиворечивость процесса
, в любом случае должна стоять на 1 месте , все остальное - вопросы "удобного" предоставления информации снабженцу
4. Goleff74 140 09.10.18 11:55 Сейчас в теме
Вот я такой Бэтмен, руковожу отделом/службой/департаментом. Мой здравый смысл решает задачи, в срок, без факапов, все довольны. Через некоторое время я захочу поменять место работы, или занозюсь с кем-нибудь и меня уйдут.
Как в этом случае передавать этот здравый смысл в каком-то стандартизированном виде, чтобы его могли дать преемнику, и он в свою очередь его понял и принял?
7. 1c-intelligence 6447 09.10.18 11:59 Сейчас в теме
(4) передадут описание процесса, которое вы нарисуете после его отладки.
9. Goleff74 140 09.10.18 12:11 Сейчас в теме
(7)
Процесс хорошо. А методологию разработки процессов с использованием "здравого смысла"?
Это получается зависимость компании от личности. Пока она есть - все здорово, но стоит ей уйти, остальные не факт, что смогут продолжить в том же русле. Со здравым смыслом у людей проблемы в общей массе.
11. 1c-intelligence 6447 09.10.18 12:13 Сейчас в теме
(9)
Это получается зависимость компании от личности

я для того и пишу учебник, чтобы ничего ни от кого не зависело.
Любой взял и сделал. Лучше, конечно, если любой - программист.
strange2007; +1 2 Ответить
28. strange2007 131 11.10.18 09:09 Сейчас в теме
(11) Аналогично. Только добавлю, что лучше использовать 2 направления:
1. Максимальное упрощение всех процессов.
2. Максимальное документирование всего. Лекции для ключевых сотрудников предприятия. Периодическое их обучение и экзаменация (конечно же в игровой форме).
10. Alligator84 55 09.10.18 12:11 Сейчас в теме
К сожалению, еще ни в одной компании не встречал описанных процессов, пусть даже неактуальных.
Когда задаю вопрос почему, ответ всегда один - Процессы часто меняются нет смысла описывать.
o.nikolaev; +1 Ответить
12. 1c-intelligence 6447 09.10.18 12:15 Сейчас в теме
(10) вопрос не в самом описании, а в затратах на выполнение этой работы - описания.
Традиционный подход - долгий и дорогой.
Собрать процесс автоматически, по автозадачам, например - быстро и дешево.
13. acanta 45 09.10.18 12:25 Сейчас в теме
(10) не в каждом "описании конфигурации" можно найти описание процесса. Мне встречалось только одно - "ЗИК 7.7". Процесс начинался из переноса начального сальдо и завершался выгрузкой проводок в бухгалтерию. Это описание занимало полторы страницы. Остальное (включая подробности каждого пункта) - все и так прекрасно знали или могли воспроизвести по данным базы.
Прочесть в соотвествующем пункте описания конфигурации кому, когда и сколько начислить премии невозможно. В мануале можно узнать только одно: куда это все записать когда оно уже есть. Или, в случае отсутствия возможностей в программе принять решение (а) отказаться от премирования (б) изменять оклад/применить сдельную оплату
Процесс включает в себя наличие/отсутствие возможностей программы отразить определенный факт.
Возможно я ошиблась в понимании этого термина.
14. awk 688 09.10.18 14:00 Сейчас в теме
Опыт показывает, что:

1. Если не написать описание до разработки, то после его никто не напишет.
2. Если не связать себе руки бумажкой, то после внедрения окажешься виноватым.
acanta; VladimirMelnychenko; +2 Ответить
15. 1c-intelligence 6447 09.10.18 14:04 Сейчас в теме
(14) здесь речь не об автоматизации, а о построении живого человеческого процесса.
Ну и вообще, в бизнес-программировании создание процесса и его автоматизация неразделимы.
17. genayo 09.10.18 14:14 Сейчас в теме
(15) На старте мы должны иметь "черный ящик", зная только что есть на входе, и что должно быть на выходе. На финише мы должны иметь самодокументирующийся процесс, собираемый на основании задач этого процесса, так?
19. 1c-intelligence 6447 09.10.18 14:16 Сейчас в теме
(17) старт может быть разным, в том числе и таким, как вы описали.
Но, обычно, хоть какое-то понимание процесса появляется быстро - вам его за 5 минут устно расскажут.
Самодокументирующийся процесс на выходе - это не идеал. Идеал - работающий процесс. Автодокументирование - это замануха для СМК. Реальным людям он не особо нужен. Так, чтоб не приставали с бумажками.
20. genayo 09.10.18 14:19 Сейчас в теме
(19) Документированный процесс нужен для понимания его сотрудниками, которые начинают работу с процессом. Утверждения/согласования документации не нужны для продуктивной работы, но это требует определённой зрелости организации.
22. 1c-intelligence 6447 09.10.18 14:24 Сейчас в теме
(20) ладно, спорить не буду. Пусть будет документация.
24. genayo 09.10.18 14:42 Сейчас в теме
(22) А как иначе? На словах сотрудники должны друг-другу рассказывать?
16. Alligator84 55 09.10.18 14:04 Сейчас в теме
2. Достаточно утвержденных требований на короткий спринт, чтобы они самые требования не успели "протухнуть". Как показывает практика, громоздкие ТЗ успевают стать неактуальными еще до выпуска первого релиза.
18. genayo 09.10.18 14:15 Сейчас в теме
(16) А если следующий спринт изменяет требования к предыдущему, тогда как?
23. alex_bitti 97 09.10.18 14:39 Сейчас в теме
есть 3 разных профессии: кодер, инженер-программист и разработчик, причем если последние 2 могут в себе объединять обязанности остальных, то первый -кодер, никогда, и последний при этом может быть представлен группой лиц.
раздражает немного когда люди путаются в этих понятих, хотя мне кажется само разделение на исполнителя и "описателя" архитектуры, произошло по вине последних, от чего людям которые фактически не пишут код, кажется что они прекрасно все понимают, хотя это очень часто не так, элементарно как человек может разрабатывать базу данных если не отличает кластерного индекса от некластерного, ну это так из банальных, то есть люди зачастую пишут инструкции без понимания, и когда приходит новый программист он с умиление как на записки юродивого смотрит на документацию, один из перлов слышал совсем недавно. Наш аналитик слава богу не по 1С, сказал естественно без присутствия разработчиков, что оказывается программист не понимает иногда чего он пишет, сам механизм, ему этого и не нужно знать, все знает аналитик, к слову это сугубо ее личное мнение, знает она куда меньше тех людей которые занимались разработкой, хотя и они там пишут что попало
29. strange2007 131 11.10.18 09:21 Сейчас в теме
(23)
что оказывается программист не понимает иногда чего он пишет

Понимаете, многие ведь именно ничего абсолютно не понимают. Просто подумайте, много ли из знакомых программистов понимают как добавление функционала возврата на десятку с МЦ.04 повлияет на самодурство (мотивацию и эффективность) начальника склада? Вот-вот. А там кроме начальника склада под удар попадает вся бухгалтерия, генеральный директор и потом всё спускается на простолюдинов.
Вот и представьте какая пропасть между аналитиками и бездумными программистами. Поэтому зря злитесь на своего аналитика. Скорее всего она права.
30. alex_bitti 97 11.10.18 11:14 Сейчас в теме
(29) опять же есть 2 понятия прикладное программирование и программирование как создание отдельных механизмов и связей, рассуждать что программист повлиял на мотивацию директора создав отдельный механизм, это как обвинять Калашникова конструктора в убийстве миллиарда человек, инженер, конструктор, создает только механизм как им пользоваться решают другие люди, вопрос в том что только они знают что доконца может система, возвращаясь к автомату я о том знании конструктора что пороховые газы способны пробить стену, а аналитики без этого знания. а появиться ему элементарно не от куда, будут пытаться придумать сложный механизм по пробитию стены из рогатки кожурой от орехов, даже иногда выходит им что то придумать но результат это стыд
31. strange2007 131 11.10.18 14:44 Сейчас в теме
(30) Хм, я примерно понимаю про что Вы пишите (ключевое слово - примерно) и именно поэтому немного не соглашусь. Нарисованный Вами программист может хорошо знать устройство автомата и уж точно не будет применять рогатку для пробития стены. Тогда как аналитик знает сколько стен надо пробить и куда они упадут после выстрелов. При этом аналитику не надо знать чем будут пробивать эти стены, а программисты (не всегда) не знают сколько стен пробивать придётся и что будет после этого и что случится когда они упадут. Мне кажется ваш аналитик как раз это и имела в виду - разные уровни абстракции. Очень разные.
32. alex_bitti 97 12.10.18 08:59 Сейчас в теме
(31) глобально может и так, то есть когда работает конвейер каждый выполняет свою работу, я лишь о том модель аналитик-кодер нежизнеспособна, наконец выразил свою мысль) если есть просто исполнитель - кодер и заказчик - аналитик (который сам уже посредник между конечным пользователем и разработчиком), должен быть архитектор, кто на мой взгляд тоже псевдопрограммист, так как не пишет код, значит не может считаться программистом в полном смысле, с каждым годом количество менеджеров увеличивается, а копает Вася как на той картинке))
33. strange2007 131 12.10.18 09:26 Сейчас в теме
(32) Ну Вы уж прям нарисовали картинку "три толстяка". Зря, очень зря. Простите, но за свою карьеру уже не мало видел людей, которые снизу рассуждали о бездарности манагеров, а как забирались чуть выше, так сразу материли работяг за безделье и лень. Работяг, а не себя! Другими словами, попробуйте обладать знаниями аналитика и использовать их в реальности, а потом сравните с текущим мировоззрением. Уверяю, будете очень удивлены.

"аналитик-кодер " Ну не знаю, сколько не видел програмистов, всегда одно и тоже - без аналитика заказчик не может внятно сформулировать хотелки, а программист вообще не знает как правильно делать. К сожалению как раз такие конторы постоянно и выправляю. Каждый год одно и тоже.
34. alex_bitti 97 12.10.18 09:31 Сейчас в теме
(33) ваше предположение было бы верно, но я не снизу)) конечно польщен тем что в рассуждения я беспечен и молод, но это далеко не так)) аналитик - это больше пользователь, который знает пользовательский функционал, под словом пользовательский я первоначальные представления о программировании, то есть использование "Справочники.Номенклатура.НайтиПоКоду()" это пользовательский уровень, программист имеет представление об механизме поиска, индексах задействованных, и стоит ли его применять в данном случае или лучше сделать запрос к справочнику. Про OLAP системы это отдельный разговор
35. strange2007 131 12.10.18 12:27 Сейчас в теме
(34) Упс... простите, если обидел. Значит мы просто чуть-чуть про разное говорим. Предлагаю найти более-менее аксиомы.
Например, я рассматриваю роль "аналитик" в виде человека, который знает бизнес-процессы предприятия, смотрит на них сверху. Он абсолютно не знает программирования и даже системы на которой производится автоматизация. Он оперирует объектами бизнеса, а не объектами учётной системы или понятиями языка программирования. Аналитик хорошо знает все виды учёта и умеет читать (т.е. ему не лень проштудировать консультант+, например, для того, что бы знать, что удерживать с работника можно только в текущем месяце). При этом аналитика внимательно слушают начальники отделов и всякие заместители генерального.
Программист же наоборот отлично знает все тонкости программирования, алгоритмы и прочие непонятности для остальных людей. Как правило программиста не слышат всякие начальники и поэтому постановка задачи от них происходит как общение глухого с немым.
Может я ошибаюсь, но я всегда так представлял эти роли (укрупнённо конечно же)

Примечание: Я не знаю, что такое индексы и ОЛАП системы видел только на картинках, но это не мешает более-менее успешно автоматизировать предприятия разных масштабов. Хотя для души пишу на PureBasic-е и Fasm-е, но в работе это забываю полностью.
25. PLAstic 205 10.10.18 13:10 Сейчас в теме
не забывайте о здравом смысле. В бизнес-программировании нет стандартов, строгих правил и законов, кроме одного: должно работать.

О, я много встречал такого бизнес-программирования! Форматирование максимально сохранено.

Если ВыборкаОрг.ДатаПроверкиПроектов = неопределено Тогда Возврат Ложь;КонецЕсли;
Если Объект.Дата >= ВыборкаОрг.ДатаПроверкиПроектов И ВыборкаОрг.ДатаПроверкиххххххх <> Дата(1, 1, 1) Тогда
	Если Строка(Объект.ВидОперации) = "Товары, услуги, комиссия" ИЛИ Строка(Объект.ВидОперации) = "Услуги" 
		                                ИЛИ Строка(Объект.ВидОперации) = "Услуги xxxxxxxxx" ИЛИ Строка(Объект.ВидОперации) = "Услуги xxxxxxxx" 
										ИЛИ Строка(Объект.ВидОперации) = "Оборудование" ИЛИ Строка(Объект.ВидОперации) = "Объекты xxxxxxxx" Тогда


Круто, что статьи призывающие говнокодить, стали появляться на ИСе и их даже нахваливают. Про TCO мы не будем упоминать, конечно, ибо тогда развалится логика "как угодно, лишь бы работало".
26. 1c-intelligence 6447 10.10.18 13:24 Сейчас в теме
(25) причем тут программирование и код?
27. acanta 45 10.10.18 13:28 Сейчас в теме
(26) ни при чем. Причем тут мозги когда думать некогда.
36. yyv-911 15.10.18 12:06 Сейчас в теме
у нас наверно неправильный смк. Точнее 1 человек.
исполнение процессов спрашивают, помогают. Смотрят эффективность, запускаются процессы корректировки если показатели падают.
А вот с руководителями отделов беда. Им мало что надо. Это простые исполнители.
Фактический смк или отдел развития могут одной мыслью заставить работать остальных по другому.
Пока конечно это в стадии старта. Т.е. все руководители описывают что у них твориться. и пытаемся все измерять.
Посмотрим что выйдет.
Все, почти поголовно, руководители реагируют на события, а не выстраивают систему. Исключения единицы.

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