IE 2018

0. 1c-intelligence 5646 09.10.18 09:37 Сейчас в теме

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

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

Перейти к публикации

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

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

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


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

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

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

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

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

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

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

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


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

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

Вакансии

Программист 1С
Новосибирск
зарплата от 80 000 руб. до 100 000 руб.
Полный день

Системный аналитик
Новосибирск
зарплата от 80 000 руб. до 100 000 руб.
Полный день

Программист 1С
Салехард
зарплата от 80 000 руб. до 200 000 руб.
Полный день

Программист 1С
Казань
Полный день

Программист 1С
Санкт-Петербург
зарплата от 130 000 руб. до 150 000 руб.
Полный день