От alexio
К Чобиток Василий
Дата 28.07.2012 11:22:16
Рубрики Танки;

Re: Юзабили

>Это, конечно, не означает, что реализацию доставки задач е-мейлом я считаю верной. Точнее говоря: только е-мейлом. Как один из нескольких вариантов е-мейл не только может, но и должен быть.

Хорошо бы если именно так и было - один из вариантов передачи данных на случай отсутствия связи. Но других вариантов не было. Единственный вариант - эскпорт и некий вид почты.

>Ну, так в БД запись вероятно и делается :)
>Хорошо, сделали запись в БД. Как это может означать, что "боевая задача отправляется в подразделения"?

Сомневаюсь, что в БД что-то пишется. Концепция изолированых клиентов, так сказать (и это при наличии сети). При более грамотном подходе имеем распределенную БД, где данные реплицируются автоматом, а новая запись, созданная штабом, становится доступна клиентам сразу (либо репликацией через избираемый по обстановке канал). Обновление информации на экране клиента может быть реализовано массой способов, от запроса пользователя до циклического опроса автоматом.
От Чобиток Василий
К alexio (28.07.2012 11:22:16)
Дата 28.07.2012 13:30:38

Re: Юзабили

Привет!

>Сомневаюсь, что в БД что-то пишется. Концепция изолированых клиентов, так сказать (и это при наличии сети). При более грамотном подходе имеем распределенную БД, где данные реплицируются автоматом, а новая запись, созданная штабом, становится доступна клиентам сразу (либо репликацией через избираемый по обстановке канал).

А, ну это другое дело :)

Только в данном случае особой разницы между "изолированными клиентами" и "распределенной БД" я не вижу. Если е-мейлы получает, то уже не изолированный; если связь пропала, а локальная копия распределенной БД работоспособна, то клиент становится изолированным :-)

По репликации есть вопросы.
1) БД на разных уровнях и в разных подразделениях не может быть продублированной, если распоряжение предназначено в N-й батальон, то оно и должно быть доставлено командиру (начштаба) N-го батальона и продублировано только в те инстанции, которые обязаны знать о распоряжениях N-му батальону. Т.е. обычная репликация тут не катит, это типичный документооборот с маршрутами прохождения документов.
2) Если распоряжение технически доставлено в нужную локальную БД, это не означает автоматически, что распоряжение было отдано. Получатель распоряжения обязан не только его "открыть на мониторе" (о чем должна сохраниться запись в соответствующих логах), но и вникнув явно подтвердить принятие на исполнение, о чем обратно уходит документ с соответствующим подтверждением.
3) На стороне отдавшего распоряжение должна быть система контроля, которая отслеживает факты как технической доставки, так и доклады о принятии к исполнению. В случае превышения сроков система сигнализирует о проблеме всеми доступными способами.

Здесь бизнес-процесс. И совсем не такой простой как просто репликация данных.

P.S. Система репликации данных для хозяйственных (арбитражных) судов Украины была спроектирована мной и начата разрабатываться в 2000-м. Она до сих пор нормально работает.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От alexio
К Чобиток Василий (28.07.2012 13:30:38)
Дата 29.07.2012 14:16:11

Re: Юзабили

Мне кажется вы зря ударились в детали реализации. Конкретно детали реализации документооборота. Да, в какой-то мере можно применить модель документооборота к военным действиям. Но есть такая общая проблема - адекватность модели. Например на основе моделирования информации была предложена модель реляционной БД. Хотя могли бы каждую запись называть документом и т.д. Но информационная модель более адекватна предметной области построения БД. Поэтому очевидно, что применять одну и ту же модель (например - документооборот) ко всем предметным областям не есть хорошо. Это возможно, но наложит на ограниченного в своих природных возможностях человека дополнительные ограничения. В результате во многих предметных областях созданы свои специфические модели, которые гораздо удобнее для понимания человеком в контексте конкретной предметной области.

Какая конкретно модель лучше подходит для конкретной АСУ - нужно определять на основе анализа гораздо большей информации, чем просто факт передачи команд подразделениям. Ни вы ни я на столько подробно в моделирование боевых действий не вдавались. Потому мы можем предлагать некие подходы, адекватность которых вряд ли сможем обосновать в условиях форума. Потому что для такого обосновани нужно много времени.
От Чобиток Василий
К alexio (29.07.2012 14:16:11)
Дата 29.07.2012 15:37:41

Re: Юзабили

Привет!

Согласен с Вами. Уточню, что, естественно, я не считаю необходимым и правильным строить АСУВ как систему документооборота и на базовом информационном понятии "документ".

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

Пока те, кто имеет отношение к разработке будут повторять "какой документооборот, у нас же маркеры (распределенная БД, шифрованные каналы связи и т.п. - подставить по вкусу)", смешивая непересекающиеся понятия из областей предметной области и технологий, толку не будет.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Лейтенант
К Чобиток Василий (29.07.2012 15:37:41)
Дата 29.07.2012 16:12:23

Re: Юзабили

>Но считаю нужным понимать, что часть информации, которой призвана управлять эта система, это документированная информация. Управлять ей и строить бизнес-процессы нужно соответствующим образом.

В такой формулировке возражений нет. Хотя я сильно подозреваю что из прочтеня Ваших предыддущих постов сделать такие выводы затруднительно.

>Пока те, кто имеет отношение к разработке будут повторять "какой документооборот, у нас же маркеры (распределенная БД, шифрованные каналы связи и т.п. - подставить по вкусу)", смешивая непересекающиеся понятия из областей предметной области и технологий, толку не будет.

Обратное про "у нас же документооборот" также верно.
От Чобиток Василий
К Лейтенант (29.07.2012 16:12:23)
Дата 29.07.2012 17:22:43

Отлично

Привет!
>>Но считаю нужным понимать, что часть информации, которой призвана управлять эта система, это документированная информация. Управлять ей и строить бизнес-процессы нужно соответствующим образом.
>
>В такой формулировке возражений нет. Хотя я сильно подозреваю что из прочтеня Ваших предыддущих постов сделать такие выводы затруднительно.

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

Будем считать это недоразумением из-за недостаточной начальной определенности контекста.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От alexio
К Чобиток Василий (29.07.2012 17:22:43)
Дата 29.07.2012 17:46:22

Приятно видеть умение сторон договориться ! (-)
От Лейтенант
К Чобиток Василий (28.07.2012 13:30:38)
Дата 28.07.2012 13:48:03

Re: Юзабили

>По репликации есть вопросы.
>1) БД на разных уровнях и в разных подразделениях не может быть продублированной, если распоряжение предназначено в N-й батальон, то оно и должно быть доставлено командиру (начштаба) N-го батальона и продублировано только в те инстанции, которые обязаны знать о распоряжениях N-му батальону. Т.е. обычная репликация тут не катит, это типичный документооборот с маршрутами прохождения документов.

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

>2) Если распоряжение технически доставлено в нужную локальную БД, это не означает автоматически, что распоряжение было отдано. Получатель распоряжения обязан не только его "открыть на мониторе" (о чем должна сохраниться запись в соответствующих логах), но и вникнув явно подтвердить принятие на исполнение, о чем обратно уходит документ с соответствующим подтверждением.

Если интерфейс этого делать в стиле классического "документооборота" - это непоправимо убьет общее время реакции системы. Это все равно что управление самолетом в воздухе предствлять в виде бизнес-процесса и организовывать документооборот между командиром экипажа, вторым пилотом и штурманом. Разумеется контроль доставки, контроль исполнения организовывать нужно но совсем другими методами (не требующими дополнительных телодвижений от исполнителей).

>P.S. Система репликации данных для хозяйственных (арбитражных) судов Украины была спроектирована мной и начата разрабатываться в 2000-м. Она до сих пор нормально работает.

Это совсем другая предметная область - суды идут годами, главная забота пользователей системы прикрыть попу. Нынешняя судебная ситема давно уже пережила свою полезность и в данный момент приносит практически только вред. Если так воевать, то вся надежда - чтолько на то что противник еще хуже.
От Чобиток Василий
К Лейтенант (28.07.2012 13:48:03)
Дата 28.07.2012 14:24:35

Re: Юзабили

Привет!
>>По репликации есть вопросы.
>>1) БД на разных уровнях и в разных подразделениях не может быть продублированной, если распоряжение предназначено в N-й батальон, то оно и должно быть доставлено командиру (начштаба) N-го батальона и продублировано только в те инстанции, которые обязаны знать о распоряжениях N-му батальону. Т.е. обычная репликация тут не катит, это типичный документооборот с маршрутами прохождения документов.
>
>С технической точки зрения неграмотное утверждение. Репликация БД бывает не только полная, но и частичная.

Неграмотное прочтение. Я же написал, обычная репликация (обычная, это когда базы просто синхронизируются, т.е. полная - технически самая простая) тут не катит.

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

>>2) Если распоряжение технически доставлено в нужную локальную БД, это не означает автоматически, что распоряжение было отдано. Получатель распоряжения обязан не только его "открыть на мониторе" (о чем должна сохраниться запись в соответствующих логах), но и вникнув явно подтвердить принятие на исполнение, о чем обратно уходит документ с соответствующим подтверждением.
>
>Если интерфейс этого делать в стиле классического "документооборота" - это непоправимо убьет общее время реакции системы.

А не допускайте типичную ошибку типичного посредственного аналитика и не делайте неправильные интерфейсы.

Отдание распоряжений это типичный документооборот по бизнес-процессу. Не можете сделать интерфейс системы, обеспечивающий высокую реакцию - не беритесь ;-)

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

Ну, эту глупость Вы придумали, Вы ее и опровергайте.

>Разумеется контроль доставки, контроль исполнения организовывать нужно но совсем другими методами (не требующими дополнительных телодвижений от исполнителей).

Ага, контроль доставки есть, контроль исполнения тоже... А контроль принятия на(к) исполнение(ю)? Из трех перечисленных контролей этот самый важный, чтоб Вы знали.

Ну, т.е. кликнуть для подтверждения что-то вроде "Ok" по прочтению распоряжения это слишком затратно по телодвижениям для исполнителя?


>>P.S. Система репликации данных для хозяйственных (арбитражных) судов Украины была спроектирована мной и начата разрабатываться в 2000-м. Она до сих пор нормально работает.
>
>Это совсем другая предметная область - суды идут годами, главная забота пользователей системы прикрыть попу.

Понятно. О судебном документообороте Вы знаете ровно столько, сколько я о балете - что он в принципе существует :)

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

Даже автоматизированное управление полем боя, это - документооборот. Будете спорить? Бесполезно - я на документообороте общем, военном, судебном за два десятка лет не одну собаку съел ;-)

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

Угу. Только "гнилость" системы никак не связана с принципами документооборота.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Суровый
К Чобиток Василий (28.07.2012 14:24:35)
Дата 28.07.2012 14:56:31

а могу я как участиник процесса на украине получить доступ к делу электронном

виде? в том числе к аудиозаписям заседаний?

такой usecase ИМХО ближе к военному применению
От Чобиток Василий
К Суровый (28.07.2012 14:56:31)
Дата 28.07.2012 15:06:24

Re: а могу...

Привет!
>виде?

Для всех граждан:
http://reyestr.court.gov.ua/

тут есть нюансы, связанные с техническим обеспечением и исполнительностью на местах, но в общем случае - да.

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

>в том числе к аудиозаписям заседаний?

Да. Только 1) со своим CD и 2) перед началом заседания надо не забыть напомнить уважаемому суду о своем праве на фиксацию аудиозаписи судебного процесса.

Кстати. Системам судебной звукозаписи название "Камертон" дано мной :-)

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Суровый
К Чобиток Василий (28.07.2012 15:06:24)
Дата 28.07.2012 15:30:04

мда. в России такое только в конце 2000х сделали. но что с автономностью?

вот у меня допустим боевой автономный управляющий комплекс типа "Помічник арбітражного керуючого" и я хочу регулярно получать информацию об оперативной обстановке и от суда и от других служб (налоговая, прокуратура и т.п.)
хотя бы чтобы график мероприятий для себя единый видеть
машинно-машинный интерфейс какой нибудь есть? он открыт?
понятно что я наверно уведомления могу подписать на почту
но что мне их - парсить?
От Чобиток Василий
К Суровый (28.07.2012 15:30:04)
Дата 28.07.2012 16:02:43

Re: мда. в...

Привет!
>вот у меня допустим боевой автономный управляющий комплекс типа "Помічник арбітражного керуючого" и я хочу регулярно получать информацию об оперативной обстановке и от суда и от других служб (налоговая, прокуратура и т.п.)
>хотя бы чтобы график мероприятий для себя единый видеть
>машинно-машинный интерфейс какой нибудь есть? он открыт?
>понятно что я наверно уведомления могу подписать на почту
>но что мне их - парсить?

На концептуальном уровне (Концепция, и ТЗ на единую судебную информационную систему), а так же на уровне требований к подсистеме "Центр обмена документами" и ее проработка на уровне архитектуры мной эти вопросы решались лет пять назад и ранее.

Все уперлось в 1) бизнес-интересы отдельных сторон (и гнилость конкретно судебной системы тут не причем), 2) проблемы фундаментального характера на стороне компании-разработчика (директор-гуманитарий за несколько лет наигрался с департаментами юристов, финансистов, экономистов и тут вдруг взялся за департамент разработки - у них началась жопа), 3) отсутствие единого управляющего и координирующего центра автоматизации судебной системы, который мог бы сформулированные мной цели и задачи ставить на исполнение и контроль, и 4) общий управленческий бардак при оранжевой власти.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Лейтенант
К Чобиток Василий (28.07.2012 14:24:35)
Дата 28.07.2012 14:47:13

Не нужно портить слова

У понятия документооборот есть вполне определенные, устоявшиеся значения, а у интерфеса систем документооборота вполне определенные устоявшиеся реализации.

>Неграмотное прочтение. Я же написал, обычная репликация (обычная, это когда базы просто синхронизируются, т.е. полная - технически самая простая) тут не катит.

Нет такого технического термина "обычная репликация". Для вас обычная - полная, а для меня частичная между множеством узлов по сложным правилам.

>>Если интерфейс этого делать в стиле классического "документооборота" - это непоправимо убьет общее время реакции системы.
>
>А не допускайте типичную ошибку типичного посредственного аналитика и не делайте неправильные интерфейсы.

Вот "обычный", пользуясь вашей терминологией, документооборот - это и есть "неправильный интерфейс".

>Отдание распоряжений это типичный документооборот по бизнес-процессу. Не можете сделать интерфейс системы, обеспечивающий высокую реакцию - не беритесь ;-)

Чтобы сделать правильный интерфейс, первое что нужно сделать - это забыть слово "документооборот".

>Ну, т.е. кликнуть для подтверждения что-то вроде "Ok" по прочтению распоряжения это слишком затратно по телодвижениям для исполнителя?

Это бессмыслено. Практика показывает, что если наказывать за то что по "ОК" не щелкнули (или не щелкнули за нормативное время), то будут щелкать сразу же, но не читая. А если не наказывать - вообще не будут щелкать. Проблема с недобросовестностью/безответсвенностью/недостком квалификации/перегрузкой исполнителей так не решается. Это чсито бурократический метод перевешивания ответственности и ничего более.

>>>P.S. Система репликации данных для хозяйственных (арбитражных) судов Украины была спроектирована мной и начата разрабатываться в 2000-м. Она до сих пор нормально работает.

>Угу. Только "гнилость" системы никак не связана с принципами документооборота.

Понятно. Пуговицы вы пришили отлично.

>Даже автоматизированное управление полем боя, это - документооборот. Будете спорить? Бесполезно - я на документообороте общем, военном, судебном за два десятка лет не одну собаку съел ;-)

Можно и систему управления воздушным движением назвать "документообротом". Или многопользовательскую он-лайн игру в "танчики". Но это порча понятий и ничего более.
От Чобиток Василий
К Лейтенант (28.07.2012 14:47:13)
Дата 28.07.2012 15:44:59

Re: Не нужно...

Привет!

>>Отдание распоряжений это типичный документооборот по бизнес-процессу. Не можете сделать интерфейс системы, обеспечивающий высокую реакцию - не беритесь ;-)
>
>Чтобы сделать правильный интерфейс, первое что нужно сделать - это забыть слово "документооборот".

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


>>Ну, т.е. кликнуть для подтверждения что-то вроде "Ok" по прочтению распоряжения это слишком затратно по телодвижениям для исполнителя?
>
>Это бессмыслено. Практика показывает, что если наказывать за то что по "ОК" не щелкнули (или не щелкнули за нормативное время), то будут щелкать сразу же, но не читая. А если не наказывать - вообще не будут щелкать. Проблема с недобросовестностью/безответсвенностью/недостком квалификации/перегрузкой исполнителей так не решается. Это чсито бурократический метод перевешивания ответственности и ничего более.

Это показывает практика систем с дурацким и неправильным интерфейсом. А как она решается в рамках электронной системы передачи распоряжений?

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

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

Это мышление сисадмина из анекдота "с моей стороны все вышло нормально - проблема на вашей стороне".

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

>>>>P.S. Система репликации данных для хозяйственных (арбитражных) судов Украины была спроектирована мной и начата разрабатываться в 2000-м. Она до сих пор нормально работает.
>
>>Угу. Только "гнилость" системы никак не связана с принципами документооборота.
>
>Понятно. Пуговицы вы пришили отлично.

Доооооо!!!! Я должен был всю систему менять. Вы или идеалист или просто клоуном прикидываетесь.

>>Даже автоматизированное управление полем боя, это - документооборот. Будете спорить? Бесполезно - я на документообороте общем, военном, судебном за два десятка лет не одну собаку съел ;-)
>
>Можно и систему управления воздушным движением назвать "документообротом".

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

Вы уверены, что точно знаете, что такое "документ"?

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Лейтенант
К Чобиток Василий (28.07.2012 15:44:59)
Дата 28.07.2012 17:37:56

С вами все ясно

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

Обмен документами только одна из возможных форм передачи распоряжений. Распоряжения также могут предаваться в устной форме или посредством различных условных сигналов (вплоть до тамтамов, дымов от костров и толчков сапогом в плоечо).

>>>Ну, т.е. кликнуть для подтверждения что-то вроде "Ok" по прочтению распоряжения это слишком затратно по телодвижениям для исполнителя?
>>
>>Это бессмыслено. Практика показывает, что если наказывать за то что по "ОК" не щелкнули (или не щелкнули за нормативное время), то будут щелкать сразу же, но не читая. А если не наказывать - вообще не будут щелкать. Проблема с недобросовестностью/безответсвенностью/недостком квалификации/перегрузкой исполнителей так не решается. Это чсито бурократический метод перевешивания ответственности и ничего более.
>
>Это показывает практика систем с дурацким и неправильным интерфейсом.

Тут дело не интерфейсе. Дело в психологии хомо сапиенс.

>Ну, т.е. поставить боевую задачу подразделению электронным путем - по-вашему достаточно сделать запись в БД. Понятно, проехали. Вы, может быть, и знаете понятия, но не понимаете их суть.
Если толковать понятие документ расширительно, к чему Вы имеете склонность, запись (некий набор записей) в БД тоже документ и спорить не о чем.

>Идеальный интерфейс должен быть предельно прост, подсказывать и подталкивать к правильным действиям. Вы же и подобные Вам, обжегшись на кривых реализациях, не хотите понимать простых вещей и отмазыватесь ссылками на бюрократию и прикрывательство жопы...

Вероятность того что за словом "документооборот" последует именно кривая реализация весьма велика. Это очень простая мысль диктуемая накопленным опытом и Вы должны ее понимать. Это я как Вам разработчик ситемы документооборота разаработчику системы документооборота говорю.

>Предельно простой интерфес не должен оперировать понятием "документ".
>Это мышление сисадмина из анекдота "с моей стороны все вышло нормально - проблема на вашей стороне".
В таком случае Ваше мышление - это мышление прапорщика из анекдота "Поезд стой! Раз, два!". Может все таки будем обмениваться более содержательными аргументами?

>Командир обязан знать, что подчиненный получил и понял задачу.
Никакая система докуметооборота (и вообще никакая програмная система) не может гарантировать что подчиненный понял задачу. Равно как и то, что он намерен ее выполнять. Уверенность в том что процесс взаимодействия выдает ожидаемый результ с приемлимой вероятностью достигается совершенно другими методами.

> Доклад подчиненного о получении задачи это обязательная часть постановки боевой задачи. И совсем не потому, что командиру надо прикрыть себе попу, а потому, что он должен быть уверен, что к выполнению его распоряжения приступили. Если выяснится, что в час Ч артиллерия не открыла огонь потому, что два часа назад ее командир не получил распоряжение,

Трындец - это время реакции артилерии два часа. А время реакции артилерии 20 секунд предполагает совершенно другой уровень если хотите "взаимного доверия" элементов цепочки (а заодно и сокращения длинный этой цепочки).

>>>Угу. Только "гнилость" системы никак не связана с принципами документооборота.
>>
>>Понятно. Пуговицы вы пришили отлично.
>
>Доооооо!!!! Я должен был всю систему менять. Вы или идеалист или просто клоуном прикидываетесь.

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

>>Можно и систему управления воздушным движением назвать "документообротом".
>
>Да, можно. Причем большая часть этой системы является типичным документооборотом, чтоб Вы знали. Это я Вам говорю как человек, у которого был подчиненный разработавший и внедривший такую систему. Именно для воздушного движения.

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

>Вы уверены, что точно знаете, что такое "документ"?
Я уверен, что Вы склонны к неоправданно расширительному толкованию этого понятия.

(Примирительно) В принципе есть значительная вероятность что весь спор сводиться исключительно к спору о терминах.
От Чобиток Василий
К Лейтенант (28.07.2012 17:37:56)
Дата 28.07.2012 21:10:12

Re: С вами...

Привет!
>>Первое, что нужно сделать - вникнуть в суть. Если Вы не хотите понимать, что передача распоряжений это обмен документами
>
>Обмен документами только одна из возможных форм передачи распоряжений. Распоряжения также могут предаваться в устной форме или посредством различных условных сигналов (вплоть до тамтамов, дымов от костров и толчков сапогом в плоечо).

Мы же говорим, кажется, о передаче распоряжений в рамках и посредством автоматизированной системы.

Соответственно, что примеры с устными распоряжениями, флажками, между членами экипажа самолета/танка не в тему и привлекаемые в качестве некоего аргумента/примера, выглядят неадекватно моменту.

>>Ну, т.е. поставить боевую задачу подразделению электронным путем - по-вашему достаточно сделать запись в БД. Понятно, проехали. Вы, может быть, и знаете понятия, но не понимаете их суть.
>Если толковать понятие документ расширительно, к чему Вы имеете склонность, запись (некий набор записей) в БД тоже документ и спорить не о чем.

Да, запись в БД тоже документ, Вы начали понимать :)

Только это не я расширительно толкую, это ГОСТ-овское определение документа таково (по-памяти близко к тексту): информация, имеющая самостоятельное значение, зафиксированная на материальном носителе :)

Конкретно этот пост, который Вы читаете - документ. Это неофициальный текстовый электронный документ, зафиксированный на магнитном носителе.

На непонимании фундаментальных принципов делопроизводства и документооборота я ловил бывалых "деловодов".

Она мне: Это не документ!
Я: А что же это такое?
Она: Филькина грамота! Тут нету подписи и печати!
Я: Не позорьтесь! Это служебный документ на стадии проект, не получивший официального статуса.

"Она" - деловод со стажем. Только деловод с процедурным мышлением и всё, что не имеет юридической силы (без подписи и печати) для нее не документ.

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

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

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

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

Но это вовсе не означает, что не надо пытаться сделать правильную постановку задачи, а ориентироваться на говно, т.к. все равно все делают говно.

>>Предельно простой интерфес не должен оперировать понятием "документ".
>>Это мышление сисадмина из анекдота "с моей стороны все вышло нормально - проблема на вашей стороне".
>В таком случае Ваше мышление - это мышление прапорщика из анекдота "Поезд стой! Раз, два!". Может все таки будем обмениваться более содержательными аргументами?

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

>>Командир обязан знать, что подчиненный получил и понял задачу.
>Никакая система докуметооборота (и вообще никакая програмная система) не может гарантировать что подчиненный понял задачу. Равно как и то, что он намерен ее выполнять. Уверенность в том что процесс взаимодействия выдает ожидаемый результ с приемлимой вероятностью достигается совершенно другими методами.

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

Ну, вот такая ситуация, начальник выходит на связь:
- Что по моей задаче, все ли понятно? Как идет подготовка?
- По какой задаче?
- @#$^ %$%%^ мать! Час назад отправлена!
- Ничего не знаю, ничего не получал!
- %^^&е сисадмины! Всех на кукан посажу!!!

Так вот, "не знаю, не получал" - чисто техническая проблема и элементарная и информирование начальника, что задача не получена, это тоже техническая проблема и тоже элементарная.

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

>> Доклад подчиненного о получении задачи это обязательная часть постановки боевой задачи. И совсем не потому, что командиру надо прикрыть себе попу, а потому, что он должен быть уверен, что к выполнению его распоряжения приступили. Если выяснится, что в час Ч артиллерия не открыла огонь потому, что два часа назад ее командир не получил распоряжение,
>
>Трындец - это время реакции артилерии два часа. А время реакции артилерии 20 секунд предполагает совершенно другой уровень если хотите "взаимного доверия" элементов цепочки (а заодно и сокращения длинный этой цепочки).

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

А планирование работы артиллерии за сутки и более Вас еще больше шокирует?

>Я просто констатировал, что внедрение системы документооборота не привело к видимому увеличению эффективности системы арбитражных судов в целом.

Вы про "чо", про Рассею? В Украине это лет 10 система хозяйственных судов. И чтобы видеть как и что изменил электронный документооборот надо просто зайти и походить по хозяйственному суду, а потом по общему, районному или городскому. А еще лучше любой задрипанный общий суд сравнить с Иванофранковским городским или Индустриальным районным Донецка.

Я в этой области больше 10 лет отработал, так что Ваши констатации не аргумент.

>Есть сильные подозрения что попытка внедрить в армии АСУ, основанную на попытке механически перенести существующие регламенты и практики в форму програмного продукта приведет примерно к таким же результатам. Разумеется для разработчика такой путь наименее рискован, когда у заказчика нет ни собственных идей, ни желания что-то существенно менять.

Для разработчика самое простое - Скрам и срать заказчику в мозг все время разработки с никаким итоговым результатом.

Зарубите себе на носу: неудачи программных проектов - неудачи разработчиков, а не заказчиков. Это я Вам говорю не как, как "заказчик", а как разработчик и аналитик, работающий с заказчиком.

Заказчик по определению не умеет разрабатывать программы, не знает процесс разработки, ставить задачи на программирование не обучен. Это задача разработчика правильно вникнуть в предметную область и правильно ее реализовать для заказчика. Современные "разрабы", до...бы, этого не понимают, предметную область оставляют за кадром на заказчике, лепят говно и виноват у них заказчик - "он сам не знает что хочет".


>Я теряюсь в догадках, что же с Вашей точки зрения не является системой документооборота.

Дать гостированное определение "документооборот" или в качестве домашнего задания сами найдете?

>Эдак и любая реализация протокола tcp - документооборот. А что, квитовка получения есть, реквизиты сообшения тоже есть.

Нет. Но аналогию провести можно.

>>Вы уверены, что точно знаете, что такое "документ"?
>Я уверен, что Вы склонны к неоправданно расширительному толкованию этого понятия.

Нет, не склонен, я оперирую понятиями предметной области.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Лейтенант
К Чобиток Василий (28.07.2012 21:10:12)
Дата 29.07.2012 00:54:34

Re: С вами...

>Мы же говорим, кажется, о передаче распоряжений в рамках и посредством автоматизированной системы.

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

>Соответственно, что примеры с устными распоряжениями, флажками, между членами экипажа самолета/танка не в тему и привлекаемые в качестве некоего аргумента/примера, выглядят неадекватно моменту.

Не более чем ваши отсылки к Священным Гостам.

>Только это не я расширительно толкую, это ГОСТ-овское определение документа таково (по-памяти близко к тексту): информация, имеющая самостоятельное значение, зафиксированная на материальном носителе :)

ПОнятие документ в таком виде совершенно не пригодно к практическому использованию. Сферический абстрактный документ в вакууме. Просто неконкретная банальность - дальше можно до посинения филосовско-юридические дискуссии на тему что имеет самостоятельное значение, а что нет и является ли человеческий мозг материальным носителем.
Мне приходилось использовать госты, например оформлять ТЗ в соответствии пресловутым ГОСТ 34 и я прикрасно понимаю какое все ритуальное очковтирательство (я имею в виду не госты вообще, а госты в нашей области).

>Конкретно этот пост, который Вы читаете - документ. Это неофициальный текстовый электронный документ, зафиксированный на магнитном носителе.

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

>На непонимании фундаментальных принципов делопроизводства и документооборота я ловил бывалых "деловодов".

Все кругом лица нетрадиционной сексуальной ориентации, один Вы д'Артаньян на белом верблюде, такие дела.

>"Она" - деловод со стажем. Только деловод с процедурным мышлением и всё, что не имеет юридической силы (без подписи и печати) для нее не документ.

Есть и такое понятие - юридический документ. И что?

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

Нужно делать не систему документооборота, а боевую интегрированную систему управления. И правильно ставить рамки задачи с самого начала.

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

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

>>>Командир обязан знать, что подчиненный получил и понял задачу.

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

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

>Так вот, "не знаю, не получал" - чисто техническая проблема и элементарная и информирование начальника, что задача не получена, это тоже техническая проблема и тоже элементарная.

Да элементарная, банальная, причем бывают случаи когда с ней бороться вообще не нужно и даже вредно, а бывают подходы когда можно вообще избежать ее возникновения путем исключения "человеческого фактора" (или хотя бы смягчит путем частичного исключения).

>Если подчиненный дебил, или начальник дебил - не умеет формулировать задачи, или оба дебилы, что приводит к непониманию задачи, это не проблема системы документооборота. Она только создает возможности и условия в техническом смысле.

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

>>Трындец - это время реакции артилерии два часа. А время реакции артилерии 20 секунд предполагает совершенно другой уровень если хотите "взаимного доверия" элементов цепочки (а заодно и сокращения длинный этой цепочки).
>
>Это не трындец, это планирование операции. Если для Вас работа артиллерии заключается исключительно в ее работе по текущим заявкам, то это точно трындец.

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

>А планирование работы артиллерии за сутки и более Вас еще больше шокирует?
Планирование оно разное бывает.

>Для разработчика самое простое - Скрам и срать заказчику в мозг все время разработки с никаким итоговым результатом.

Не, самое простое - ТЗ, оформленное по ГОСТ 34, на в пяти томах с цветными диаграммами. Оформленое как парвый этап работ с 199 процентной предоплатой. На этом работы и завершаются.

>Зарубите себе на носу: неудачи программных проектов - неудачи разработчиков, а не заказчиков. Это я Вам говорю не как, как "заказчик", а как разработчик и аналитик, работающий с заказчиком.

Зарубите себе на носу - неудачи програмных проектов полностью на совести заказчиков, хотя бы потому, что заказчик выбирает разработчиков, утверждает сроки и бюджет. Это даже если заказчик не выдвигает взаимно противоречивых требований и не навязывает неподходящих технологий и неверных проектных решений (что сплошь и рядом).

>Заказчик по определению не умеет разрабатывать программы, не знает процесс разработки, ставить задачи на программирование не обучен.

К глубокому сожалению, заказчики едвали не в большинстве случаев придерживаются прямо противоположного мнения. Особенно достали персонажи которые "я сам когда-то был программистом и не вижу тут ничего сложного".

> Это задача разработчика правильно вникнуть в предметную область и правильно ее реализовать для заказчика.

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

> Современные "разрабы", до...бы, этого не понимают, предметную область оставляют за кадром на заказчике, лепят говно и виноват у них заказчик - "он сам не знает что хочет".

Да, заказчик должен понимать чего он хочет. Попытки "хотеть за него" заказчик как правило пресекает решительно и беспощадно, как покушение на свой социальный статус и "картину мира". Причины этого лежат в стайно-иерарархической природе человека. Что же до знания предметной области, то это это заказчик должен выбрать исполнителей знающих предметную облать или хотя бы предоставить им время и возможность ее изучить. Но это дорого и в ряде случаев спсобно вскрыть собственную некомпетентность заказчика и постаивть под угрозу его социальный статус, во всяком случае заказчик этого боится.
От Чобиток Василий
К Лейтенант (29.07.2012 00:54:34)
Дата 29.07.2012 03:23:08

Re: С вами...

Привет!
>>Мы же говорим, кажется, о передаче распоряжений в рамках и посредством автоматизированной системы.
>
>В рамках автоматизированной системы распоряжения могут быть переданы, например, в форме цветовой маркировки приортетных целей. Или в форме электрических импулсов на управлящие механизмы наводки.

Ээээ, друг, Вас уже занесло. Разговор начался с этого "Фраза из ТЗ "боевая задача отправляется в подразделения"".

Я все не мог понять, в чем проблема Вашего гона. То артиллерия сию секунду стреляет, то еще чего...

Вы об информационном обеспечении поля боя? Ну так на здоровье! АСУ управления войсками имеют разные уровни. Когда задача отправляется в подразделения речь о маркировке целей и команды на исполнительные механизмы быть не может.

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

Вы не понимаете, что боевой приказ подразделениям, частям и соединениям не ставится маркировкой целей, а боевой приказ в электронном виде является документом?

>Не более чем ваши отсылки к Священным Гостам.

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

>ПОнятие документ в таком виде совершенно не пригодно к практическому использованию.

Более чем пригодно. Я уверен, что Вы даже не сможете доложить принципы и виды классификации документов. Если бы Вы знали и уважали предметную область, вы бы понимали, что глиняный артефакт с надписью древними письменами тоже документ определенного вида. И "квитовка", которую вы упоминали, - документ.

Документы бывают разные и как с ними работать зависит от их классификации.

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

>Мне приходилось использовать госты, например оформлять ТЗ в соответствии пресловутым ГОСТ 34 и я прикрасно понимаю какое все ритуальное очковтирательство (я имею в виду не госты вообще, а госты в нашей области).

Угу, все толковые разработчики при необходимости работать по ГОСТу делают это по ГОСТ 19. И Вам советую. Поймете, что жизнь много проще и прекраснее, а разрабатывать ТЗ на программу по ГОСТ на автоматизированные системы (ориентированный на промышленные АСУ) - глупо, когда есть ГОСТы на программную документацию.

>К глубокому сожалению, заказчики едвали не в большинстве случаев придерживаются прямо противоположного мнения. Особенно достали персонажи которые "я сам когда-то был программистом и не вижу тут ничего сложного".

Да, и я тоже был программистом (я и сейчас много программирую) и не вижу тут ничего сложного :)

Они Вас достали, потому что Вы не умеете с ними работать. Это Ваша проблема. Вам надо расти профессионально. 10 лет назад я тоже работал с заказчиком как М$#%к, теперь так не делаю.

>> Это задача разработчика правильно вникнуть в предметную область и правильно ее реализовать для заказчика.
>
>Для этого нужен вменямый и договороспособный заказчик, что в сущности большая редкость. Обычно требуется кнопка "сделать все", причем вчера и бесплатно. Признаки просветления появляются только после неоднократного результативного наступления на грабли и то не всегда.

И я точно так же думал лет 10 назад :)

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

Ууууу, как все упущено. Вы еще просто очень не зрелы.

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

На самом деле это очень просто, если знать маленькие секреты работы аналитика с заказчиком :)

Почитайте на досуге мои заметки по работе с заказчиком:
http://armor.kiev.ua/wiki/index.php?title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:ArmorAdmin/%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D1%81_%D0%B7%D0%B0%D0%BA%D0%B0%D0%B7%D1%87%D0%B8%D0%BA%D0%BE%D0%BC

Обратите внимание на п. "Задавай правильные вопросы".


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

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

Вы допустили одну большую ошибку.

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

Ошибка в том, что Вы полезли в салупу, а могли бы поинтересоваться моим опытом и наработками. Я всегда делюсь с удовольствием.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Лейтенант
К Чобиток Василий (29.07.2012 03:23:08)
Дата 29.07.2012 15:31:27

Ну-ну

>Вы об информационном обеспечении поля боя? Ну так на здоровье! АСУ управления войсками имеют разные уровни. Когда задача отправляется в подразделения речь о маркировке целей и команды на исполнительные механизмы быть не может.

Раскажите об этом генерал-лейтенанту Хрулеву. Такие эпизоды как пресловутый "звонок по мобильнику" (а это на самом деле случай далеко не единичный) на самом деле не только следвие ошибок в организации управления войсками, но и симптом того, что сами эти принципы не во всем адекватны текущей ситуации. Как и превышения потерь ВВС от огня собственных частей над потерями от огня противника и многое другое, типа постоянного желания иметь персональную "Большую Берту" в каждом взводе и персональное звено истребителей для прикрытия.

>Вы не понимаете, что боевой приказ подразделениям, частям и соединениям не ставится маркировкой целей, а боевой приказ в электронном виде является документом?

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

>>Не более чем ваши отсылки к Священным Гостам.
>
>Понятно. Дальнейшую ерунду можно не читать. Вы из тех разработчиков, о которых я рассказывал. Поэтому у Вас и АСУД с говняными интерфейсами.

О, Вы не только госты наизусть знаете о еще и владеете даром ясновидения. Я конечно иногда перебираю в споре с эмоциями, но до употребления эпитетов типа "говеный" о незнакомом мне предмете я вроде еще не опускался. Да и изначально переходить на личности было не моей инициативой. Вам не стыдно? Впрочем я давно замечал, что у любителей цитировать госты 19 и 34 часто бывают проблемы со стыдом и совестью.

>И Вы, не зная предметную область, явно ее "познали" в общении с "толковым" деловодом от заказчика. На изучение фундаментальных основ забили болт, ни учебников по делопроизводству и документообороту, ни руководящих документов не изучали. А зачем? Ведь в гостах же туфта, а мы, хуле, крутые практики...

Но гост 19 и 34 действительно туфта (точнее превращаются в туфту при попытке руководствоваться ими формально, прямо и буквально).

>>Мне приходилось использовать госты, например оформлять ТЗ в соответствии пресловутым ГОСТ 34 и я прикрасно понимаю какое все ритуальное очковтирательство (я имею в виду не госты вообще, а госты в нашей области).
>
>Угу, все толковые разработчики при необходимости работать по ГОСТу делают это по ГОСТ 19. И Вам советую. Поймете, что жизнь много проще и прекраснее, а разрабатывать ТЗ на программу по ГОСТ на автоматизированные системы (ориентированный на промышленные АСУ) - глупо, когда есть ГОСТы на программную документацию.

По какому госту делать решает заказчик. В данном случае это у заказчика в корпоративной политике было прописано (заказчик очень крупная организация энергетики). С ГОСТ 19 знаком. Проблемы с ним те же.

>>К глубокому сожалению, заказчики едвали не в большинстве случаев придерживаются прямо противоположного мнения. Особенно достали персонажи которые "я сам когда-то был программистом и не вижу тут ничего сложного".
>
>Да, и я тоже был программистом (я и сейчас много программирую) и не вижу тут ничего сложного :)

Я так и подумал.

>Они Вас достали, потому что Вы не умеете с ними работать. Это Ваша проблема. Вам надо расти профессионально. 10 лет назад я тоже работал с заказчиком как М$#%к, теперь так не делаю.

Опять ясновидение, телепатия и постановка диагнозов по фотографии даже без фотографии.

>Да, заказчик думает, что он знает, что он хочет. Вы просто не умете и не знаете как правильно узнавать реальные цели заказчика, а не ту фигню, которую он обычно озвучивает.

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

>На самом деле это очень просто, если знать маленькие секреты работы аналитика с заказчиком :)

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

>Почитайте на досуге мои заметки по работе с заказчиком:
> http://armor.kiev.ua/wiki/index.php?title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:ArmorAdmin/%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D1%81_%D0%B7%D0%B0%D0%BA%D0%B0%D0%B7%D1%87%D0%B8%D0%BA%D0%BE%D0%BC

Прочитал. Смесь правильных, но банальных советов и советов типа "мышки станьте ежиками". Могу разобрать поподробнее. Для затравки:
1) "Говори заказчику правду". Я собственно так стараюсь поступупать, но это далеко не всегда выгодно (иногда до такой степени невыгодно, что, если называть вещи своими именами, я иду на копромиссы с совестью и профессиональной этикой).
Чтобы получить контракт нужно выдвинуть предложение по срокам и бюджету укладывающееся в ожидания заказчика (типично сильно заниженные). Стратегия "главное втянуть заказчика в разарботку, а там сроки и бюджет растянем" вполне работоспобна. Таким образом правду заказчику говорить выгодно, но ровно в таком объеме котjрый он готов принять. Прием мошенников старый как мир - вхождение в доверие путем дозированного раскрытия негативной информации. Этот объем нужно угадать. В случае если ваше правдивое комерческое предлажение в ожидания заказчика не укладывается, он просто выберет другое - укладывающееся, авторы которого не погнушались (или недостаточно профессиональны, чтобы грамотно оценить объем работ).
Если же Вы не располаете полномочиями формулировать условия контракта, то говорить заказчику правду Вам может быть просто запрещено (с санкциями вплоть до увальнения). Даю вводную: на том самом проекте с крупной организацией энергетики предполагалось создание некого програмного комплекса строящегося вокруг использования некого специфичного оборудования. График проекта был согласован с заказчиком и утвержден как приложение к договору. Предполагалось, что до определенного этапа вместо самого оборудования будет использоваться его имитатор, но к моменту ПСИ, естественно, оборудование должно быть поставлено. Я выполнял роль РП на месте (в отдаленном регионе), поставку оборудования взяло на себя мое московское начальство (точнее начальство моего начальства - непосредсвенно топ-менеджер). Разница во времени с Московой, с учетом разницы в режиме работы головного офиса указанной организации энеретики и московского офиса моей компании - 8 часов (то есть напрямую они почти не общаются). В средине проекта мое начальство сообщает мне, что поставка оборудования в срок осуществлена не будет (высшее начальство налажало от жадности) и не будет осуществлена в обозримые сроки вообще, но говорить об этом щаказчику разумеется не надо. При этом мое начальство требует письменного подтверждения что приказ о неразглашении получен, правильно понят и принят к исполнению. Ваши действия в этой ситуации, правдивый Вы наш?

2) "Что хочет Бог Заказчик", "Задавай правильные вопросы". Ну тут у Вас довольно банальные вещи написаны, никаких Америк Вы не открыли. В добавок опущен вопрос, что делать, если заказчик реально испытывает поребность в покупке "на грош пятаков", реально невменяем, испытывает крупный внутрений конфликт интересов или его реальная потребность заключается в провале проекта (иногда все сразу).

Даю вводную: некий очень-очень крупный холдинг, лидер в своей отрасли в мировых масштабах. Холдинг приобретает новую компанию расположенную в неком регионе (назовем ее компания "А"). По сути, одна из двух-трех "регионообразующих" компаний. Вторая "регионобразующая" компания (назовем ее компания "Б") входит в холдинг уже давно. Ит-департамент этой самой второй компании выступает с инициативой внедрить унифицировать ПО с целью сокращения издержек в масштабах холдинга, унификации, оптимизации бла-бла-бла.
И получает добро "сверху", что в первой компании будет в качестве пилотного проекта внедрено некое ПО второй компании,для решения локальных задач учета ТМЦ, разработанное ее постоянным московским заказчиком. По устной договоренности из Москвы присылают команду проекта для внедрения этого ПО (во главе со мной "сейчас больше некого туда послать, это простой и быстрый проект"), причем имеется предварительная договоренность о "развертывании ПО в еще одном новом подразделении компании Б" (в 14-ти других это уже сделано), договоренноть также включает график и бюджет. По прилету оказывается, что хотя о работах договоривались с "Б", контракт должен быть заключен с компанией "А", которая воовсе не является подразделением "Б", а является компанией сравнимых с "А" размеров из смежной отрасли (но плучила от нового общего владельца указания об участии, впрочем неформальные и неконкретные). На первой встрече с представителями "А" выясняется, что им нужно не внедрение ранее упомянутого софта, а обследование всего цикла МТО данной компаниии (с выводом о нецелесообразности замены существующих систем. Московское руководство будучи проинформировано о ситуации дает команду вместо внедрения ПО учета ТМЦ производить обследование цикла МТО, но с соблюдением ранее согласованных с "Б" сроков и бюджета проекта и имеющейся командой (сформированной совсем под другой проект как выяснилось) при этом нужно сохранить добрые отношения с "Б", и полностью удовлетворить "А". "Б" согласны на сроки (неполные две недели) и бюджет (скромный для таких работ, но огромный по равнению с предполагаемыми затратами полрядчика), главное чтобы отчет об обследовании содержал правильные выводы. В "Б" "пожимают плечами", сообщают что не имеют прямого влияния на "А", но настаивают, что обследование должно быть первым этапом внедрения того софта, о котором шла речь первоначально и отчет должен иметь соответсвующее содержание. Я продолжаю заниматься "челночной дипломатией" между офисами "А" и "Б" (два километра пешком, бегом, оплата такси моим руководством не предусмотрена). В подчинии у меня пара узкозаточенныех на развертывание ПО и обучение конечных пользователей-кладовщиков перцев с которыми я познакомился прямо в самолете. Зарплата перцев чуть больше чем у кассирши из московского супермаркета, квалификация чуть лучше чем можно было ожидать за эти-то деньги, но без чудес, но вот мотивация, увы, соответствующая окладу. Особую пикантность ситуации придает то, что совсем недавно подобное обследование в компании "А" проводилось прежним владельцем, причем силами большой и весьма профессиональной команды (как первый этап внедрения одной известной зарубежной ERP-ситемы) в течении нескольких месяцев. Кстати Б само по себе холдинг с предприятими различной специфики раскиданными на территории превышающей территорию Украины как бык овцу. "А" намекает, что отчет с не устаривающими "А" выводами не будет оплачен, как халтурный (а показать для сравнения в случае разброк есть что, мне и показывают отчет "саперов", но "из рук"). Б в свою очередь намекает, что не устраивающий "Б" отчет приведет к тому, что дальнейшее сотрудничество моей компании с "Б" будет поставлено под вопрос. Мое начальство подтверждает указания провести обследовние, получить деньги с Б, согласовать перед предоставлением Б отчет с А (что необходимо отразить в договоре), а также не беспокоить более руководство, занятое ОЧЕНЬ ВАЖНЫМИ ВЕЩАМИ. Ваши действия, "зрелый" Вы наш? Какие вопросы заказчику в даной ситуации должны быть правильными и ктати, кого следует считать заказчиком?

>Видите, Вы утверждали, что мы коллеги по автоматизации документооборота

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

> и тут же продемонстрировали незнание, непонимание и нежелание понимать предметную область.

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

>Специалистов моего уровня в области теории и практики организации документооборота хоть обычного, хоть электронного - единицы. У меня богатый и очень редкий опыт успешной разработки таких систем, причем во всех исполнительских и управленческих ролях, начиная от программиста, заканчивая аналитикой и руководством в решении вопросов на государственном уровне.

Да, от скромности Вы точно не умрете. Вы случайно не член Российской Академии Информатизации? Подобное ЧСВ и бахвальство мне их сильно напоминает :-)

> Ошибка в том, что Вы полезли в салупу,
Не могли бы Вы воздержатся от использования ненормативной лексики. Не самомодерирования для, а исключительно в порядке личного одолжения?
От Чобиток Василий
К Лейтенант (29.07.2012 15:31:27)
Дата 29.07.2012 16:52:00

Re: Ну-ну

Привет!

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

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

>О, Вы не только госты наизусть знаете о еще и владеете даром ясновидения. Я конечно иногда перебираю в споре с эмоциями, но до употребления эпитетов типа "говеный" о незнакомом мне предмете

Извините, если обидел, но Вы сами говорили в подобном ключе об интерфейсе систем делопроизводства. Вот я и решил, что это из личного опыта.

>я вроде еще не опускался. Да и изначально переходить на личности было не моей инициативой. Вам не стыдно? Впрочем я давно замечал, что у любителей цитировать госты 19 и 34 часто бывают проблемы со стыдом и совестью.

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

>Но гост 19 и 34 действительно туфта (точнее превращаются в туфту при попытке руководствоваться ими формально, прямо и буквально).

+100500. Но в предыдущих постах Вы так изложили проблему, как-будто сами пытались ими руководствоваться формально, прямо и буквально.

>По какому госту делать решает заказчик.

Нет :) Это заблуждение. Поверьте мне на слово. Я поработал со многими госзаказчиками, военными и гражданскими, разного уровня, вплоть до министерского.

По какому ГОСТу делать они не решают, а если и решают, то думают, что решают.

>В данном случае это у заказчика в корпоративной политике было прописано (заказчик очень крупная организация энергетики). С ГОСТ 19 знаком. Проблемы с ним те же.

Нету с ним проблем. Никаких. Вам мешают требования к правилам оформления? Это внешнее представление, его элементарно настроить стилями документа.

Вас не устраивают требования к содержанию ТЗ? В ГОСТ 19.201 указано:

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

Нету проблем с ГОСТ 19 :)


>>>К глубокому сожалению, заказчики едвали не в большинстве случаев придерживаются прямо противоположного мнения. Особенно достали персонажи которые "я сам когда-то был программистом и не вижу тут ничего сложного".
>>
>>Да, и я тоже был программистом (я и сейчас много программирую) и не вижу тут ничего сложного :)
>
>Я так и подумал.

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

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

С таким заказчиком просто не надо работать :)

>>На самом деле это очень просто, если знать маленькие секреты работы аналитика с заказчиком :)
>
>Это Вы часом не про откаты?

Нет, это Вы "по фотографии без фотографии" :) Я на основной работе, не считая положенной з/п и премий, ни разу не получил левой копейки, а они были бы, занимайся я "откатами" в ту или иную сторону.

У Вас действительно настолько шаражкина контора, что аналитик кроме своих прямых обязанностей еще занимается финансовыми вопросами во взаимоотношениях "заказчик-разработчик"? Или, просто, как это принято у некоторых, Вы - руководитель, который для экономии на зарплате решаете вопросы бизнес-аналитики?

>Есть такое эмпирическое правило - где госты требуют, там и откаты откатывают (как основная цель заказчика). Или можжет про совместное распитие спиртных напитков с представителем заказчика и употребление ненормативной лексики?

Вот видите, какой к Вас богатый опыт. Откаты, совместное распитие и употребление ненормативной лексики.

Хотел ответить "нет", но таки вспомнил. Было. В Харькове после проведения семинара по системе судебной статистики, проводимого по инициативе USAID, местные судебные власти нас приглашали на торжественный обед, где таки вино наливали.

Вы об этом, или у Вас принято в баньке под водочку и прочие атрибуты?

>>Почитайте на досуге мои заметки по работе с заказчиком:
>> http://armor.kiev.ua/wiki/index.php?title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:ArmorAdmin/%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0_%D1%81_%D0%B7%D0%B0%D0%BA%D0%B0%D0%B7%D1%87%D0%B8%D0%BA%D0%BE%D0%BC
>
>Прочитал. Смесь правильных, но банальных советов и советов типа "мышки станьте ежиками". Могу разобрать поподробнее. Для затравки:
>1) "Говори заказчику правду". Я собственно так стараюсь поступупать, но это далеко не всегда выгодно

Там же написано "Понятное дело, я не за патологическую правдивость...". Так что Вас самому правильные выводы делать ;-)

>Чтобы получить контракт нужно выдвинуть предложение по срокам и бюджету

Вы о работе аналитика или у Вас, опять же, "директор-экономист-финансист-аналитик" в одном флаконе?

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

>Стратегия "главное втянуть заказчика в разарботку, а там сроки и бюджет растянем" вполне работоспобна.

Козлиная эта практика, хоть и работоспособная. Представьте себе, у меня несколько случаев было когда заказ отдавали нам только потому, что я объяснял заказчику в чем его другие кАзлы хотят надуть и, более того, почему и чем именно мы тоже кАзлы!

Вам это трудно понять.


>Если же Вы не располаете полномочиями формулировать условия контракта, то говорить заказчику правду Вам может быть просто запрещено (с санкциями вплоть до увальнения).

А мне насрать. Я думаю выложить у себя историю с финансирование проекта от Еврокомиссии.

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

>Даю вводную:

Простите, все так интересно но запутано, а "А" и "Б" не имеют конкретной морды лица, что пытаться решать Вашу вводную - проявлять непрофессионализм.

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


>Я продемонстрировал нежелание повторять религиозные мантры типа "куст есть совокупность ветвей и лисьтев", которые Вы ошибочно считаете ключом к пониманию предметной области.

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

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

>Считать себя д'Артаньяном, а меня соответсвенно не д'Артаньяном Ваше право, но характеризует это как не д'Артаньяна скорее Вас самого, чем меня.

Тут ничего не понял. Вы просите считать Вас д'Артаньяном? На виконта де Бражелона согласитесь?

>Да, от скромности Вы точно не умрете. Вы случайно не член Российской Академии Информатизации? Подобное ЧСВ и бахвальство мне их сильно напоминает :-)

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

Ну не хотите и не надо, могу не делиться - забот меньше.

>> Ошибка в том, что Вы полезли в салупу,
>Не могли бы Вы воздержатся от использования ненормативной лексики. Не самомодерирования для, а исключительно в порядке личного одолжения?

Я ее не использую, я на ней разговариваю.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Лейтенант
К Чобиток Василий (29.07.2012 16:52:00)
Дата 29.07.2012 18:03:42

Re: Ну-ну

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

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

>Извините, если обидел
Взаимно.

>Нету с ним проблем. Никаких. Вам мешают требования к правилам оформления? Это внешнее представление, его элементарно настроить стилями документа.

Так и было сделано.

>Вас не устраивают требования к содержанию ТЗ? В ГОСТ 19.201 указано:
>"В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них."

Собствено этой фраза и делает все его остальное наполнение избыточным :-)

>С таким заказчиком просто не надо работать :)

"Других Гинденбургов у нас для Вас нет" (с) Если Вы не владелец бизнеса заказчиков Вы как праавило не вольны выбирать. Даже если владелец - не всегда и не во всем вольны.

>У Вас действительно настолько шаражкина контора,
Я в разных конторох работал. Опыта у меня больше 20 лет.

> что аналитик кроме своих прямых обязанностей еще занимается финансовыми вопросами во взаимоотношениях "заказчик-разработчик"?

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

>Вот видите, какой к Вас богатый опыт. Откаты, совместное распитие и употребление ненормативной лексики.

Лично я избегаю. Первого, второго и третьего, хотя для работы это бывает вредно. Без шуток :-(

>Вы об этом, или у Вас принято в баньке под водочку и прочие атрибуты?
"У нас" было много и разных. Вариант что наиболее серьезные решения принимаются именно таким образом, он в общем один из основных на этой планете (в западных компаниях это может быть "гольф и виски", но суть от этого меняется мало).

>>Чтобы получить контракт нужно выдвинуть предложение по срокам и бюджету
>
>Вы о работе аналитика или у Вас, опять же, "директор-экономист-финансист-аналитик" в одном флаконе?

Я о том, что бюдежт и сроки могут быть определены до того как я приступил к работе как аналитик и лично мне как аналитику может очень быстро стать вполне понятно, что бюджет и сроки занижены скажем на порядок.

>Я, как аналитик, всегда говорю правду. И проекты всегда от этого выигрывали, даже тогда, когда директор в ожидании провала уползал под стол и удивлялся, что реакция заказчика обратная от ожидаемой им.

Вам повезло с директором. Большинство знакомых мне управленцев за такое наказали независимо от степени правоты и последующей реакции заказчика. В армии за нарушение прямого приказа в боевой обстановке так и вовсе растрелять могут (даже если события показали что он был трижды неоптимален).

>>Стратегия "главное втянуть заказчика в разарботку, а там сроки и бюджет растянем" вполне работоспобна.
>
>Козлиная эта практика, хоть и работоспособная. Представьте себе, у меня несколько случаев было когда заказ отдавали нам только потому, что я объяснял заказчику в чем его другие кАзлы хотят надуть и, более того, почему и чем именно мы тоже кАзлы!

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

>>Если же Вы не располаете полномочиями формулировать условия контракта, то говорить заказчику правду Вам может быть просто запрещено (с санкциями вплоть до увальнения).
>
>А мне насрать. Я думаю выложить у себя историю с финансирование проекта от Еврокомиссии.
>Я им выложил всю правду-матку не взирая на полномочия. У них челюсти поотвисали. В предыдущие дни их обхажывали лестью и враньем, все сводилось к "дайте бабла, но не спрашивайте как потратим". После беседы со мной они таки решили сотрудничать с нашей организацией.

Вот теперь у меня вопрос "это в какой же Вы шарашкиной конторе работаете"? Серьезные организации ради сиюминутной выгоды норушения корпоративных норм не допускают.

>Послушать Ваше решение и как и почему Вы к нему пришли, да, интересно для общего развития.

Обоим сторонам было заявлено что "я на вашей стороне". Выводы в отчете были составлены таким языком, что каждая из сторон могла при желании трактовать его желаемым для себя образом. Получены подписи под актом приемки и от "А" и от "Б". С эти актом (ну вообще-то он был не один, а целая куча всяких бумажек по каждому шагу работы за подписями всех причастных) я вернулся в москву сдал работу и уволился нафиг, потому что в такие игры я играть не подписывался. Стоило это все в целом мне 6 кило веса и нервов потраченных как за три предыдущих года.

>Поймите, из нас религиозный фанатизм проявляете Вы. Я убежден, что базовые сущности надо понимать, осознавать их суть. Понимание не совместимо с религиозной верой. Вы же с религиозным фанатизмом убеждены, что определение базовых сущностей гостом - религия :)

Я убежден что Ваш выбор базовых сущностей чрезмерно ограничен.

>Я ее не использую, я на ней разговариваю.

Искренне сочуствую.

От Чобиток Василий
К Лейтенант (29.07.2012 18:03:42)
Дата 29.07.2012 19:07:02

Re: Ну-ну

Привет!

>Я в разных конторох работал. Опыта у меня больше 20 лет.

О, коллега, у меня ровно столько же. Так о чем мы спорим? :)

>А Вы десть лет в одной единственной компании работаете?

Чуть больше 10 лет (с небольшим перерывом) я работал на судебную систему в трех разных компаниях (формально - в пяти). Тут целая детективная история. Мне товарищи рекомендовали по ней книгу писать.

Поработал 5 лет в компании Юртех и госпредприятии "Судебный информационный центр" (по факту рождения "Арбитражный..."), ужел за профессиональным ростом, через год попал в крупную компанию "Арт-мастер", для которой через год... Юртех стал заклятым коллегой по рынку - АМ вышел на рынок судебного документооборота. А я в скором времени был вынужден перейти опять же в госконтору "Судебные информационные системы", поглотившую СИЦ, начальником отдела по вопросам развития предприятия. Я стал для А-М заказчиком :)

Потом Юртех был поглощен А-М, потом я ставил задачи своему бывшему начальнику, потом... Мне предложил работать у него нынешний Министр обороны Украины и я даже согласился, но тут WoT...

Много чего интересного :)

>>Вы о работе аналитика или у Вас, опять же, "директор-экономист-финансист-аналитик" в одном флаконе?
>
>Я о том, что бюдежт и сроки могут быть определены до того как я приступил к работе как аналитик и лично мне как аналитику может очень быстро стать вполне понятно, что бюджет и сроки занижены скажем на порядок.

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

>>Я, как аналитик, всегда говорю правду. И проекты всегда от этого выигрывали, даже тогда, когда директор в ожидании провала уползал под стол и удивлялся, что реакция заказчика обратная от ожидаемой им.
>
>Вам повезло с директором. Большинство знакомых мне управленцев за такое наказали независимо от степени правоты и последующей реакции заказчика. В армии за нарушение прямого приказа в боевой обстановке так и вовсе растрелять могут (даже если события показали что он был трижды неоптимален).

Сижу я в кабинете у первой замгендиректорши (вообще толковая и умная женщина), обсуждаем рабочие вопросы. Жара 30 градусов, я в шортах (приличных, чуть ниже колена), летней рубашке с пальмами и в резиновых тапочках (как потом выяснилось российских армейских). Заходит пацанчик из юротдела, одет в строгие черные брюки, туфли, белая рубашка с коротким рукавом. Она его спрашивает: "Ты почему без галстука?!" Мне стало очень стыдно... Но тапочки и шорты в жару я продолжал носить :)

Когда я директору нужнее, чем он мне... Это кому еще повезло? ;-)

>Вот теперь у меня вопрос "это в какой же Вы шарашкиной конторе работаете"? Серьезные организации ради сиюминутной выгоды норушения корпоративных норм не допускают.

Сейчас работаю на wargaming.net. 61% побед в чистом рандоме и в Топ1000 по среднему опыту :-)))))))

Введение с последним апдейтом СТ 10 уровня в том виде как их сделали считаю злом. Это - нарушение не только корпоративной этики, но и корпоративных правил. Меня за это надо расстрелять. Но! Я так думаю и это факт.

Тем не менее, игра все равно классная, играйте в наши танчики.

>>Послушать Ваше решение и как и почему Вы к нему пришли, да, интересно для общего развития.
>
>Обоим сторонам было заявлено что "я на вашей стороне". Выводы в отчете были составлены таким языком, что каждая из сторон могла при желании трактовать его желаемым для себя образом. Получены подписи под актом приемки и от "А" и от "Б". С эти актом (ну вообще-то он был не один, а целая куча всяких бумажек по каждому шагу работы за подписями всех причастных) я вернулся в москву сдал работу и уволился нафиг, потому что в такие игры я играть не подписывался. Стоило это все в целом мне 6 кило веса и нервов потраченных как за три предыдущих года.

А, ну это мудрый выход. Я две стороны обычно так и удовлетворяю :)

А "Паром" - систему передачи судебных решений в единый реестр именно так и сделали. Я, еще будучи в Арт-мстере, вник в крупные проблемы заказчика и сказал им "Вам надо автоматизировать этот процесс и от имени компании предлагаю это сделать просто и быстро". Когда пришел к руководству А-М сказал "Они требуют сделать это, причем сделать именно так и так".

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


>>Поймите, из нас религиозный фанатизм проявляете Вы. Я убежден, что базовые сущности надо понимать, осознавать их суть. Понимание не совместимо с религиозной верой. Вы же с религиозным фанатизмом убеждены, что определение базовых сущностей гостом - религия :)
>
>Я убежден что Ваш выбор базовых сущностей чрезмерно ограничен.

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

>>Я ее не использую, я на ней разговариваю.
>
>Искренне сочуствую.

Это была шутка.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От VD
К Чобиток Василий (29.07.2012 03:23:08)
Дата 29.07.2012 11:31:06

Re: С вами...

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

>Более чем пригодно. Я уверен, что Вы даже не сможете доложить принципы и виды классификации документов. Если бы Вы знали и уважали предметную область, вы бы понимали, что глиняный артефакт с надписью древними письменами тоже документ определенного вида. И "квитовка", которую вы упоминали, - документ.
А разработчики Предатора тоже не доложат. Они оперируют термином "информация", а не документ. Кстати, дайте ссылку на универсальную классификацию "документов", посмеемся вместе с ее практической ценности.

>Документы бывают разные и как с ними работать зависит от их классификации.
В таком случае это понятие не несет полезной информации.

>Они Вас достали, потому что Вы не умеете с ними работать. Это Ваша проблема. Вам надо расти профессионально. 10 лет назад я тоже работал с заказчиком как М$#%к, теперь так не делаю.
Для инновационных проектов надо не на заказчика-исполнителя делиться, а создавать таск-форс из специалистов разного рода. Иначе так и будут по гост'ам друг на друга спихивать.

>Специалистов моего уровня в области теории и практики организации документооборота хоть обычного, хоть электронного - единицы. У меня богатый и очень редкий опыт успешной разработки таких систем, причем во всех исполнительских и управленческих ролях, начиная от программиста, заканчивая аналитикой и руководством в решении вопросов на государственном уровне.
И какое это отношение имеет к нормальной АСУ управления войсками? Особенно той, которая может помочь в реальной войне, когда идут потери, узлы связи и штабы выводятся из строя, противник активно маневрирует? Там просто совсем другие принципы работы,и документооборот в академическом виде занимает по важности далеко не первое место. Вам оппонент правильно сказал, что в первую очередь это NRT распределенная БД. Поэтому и копать надо в сторону протоколов, шифрования, распознавания, ИИ и пр. хайтека.

С уважением к сообществу.
От oleg100
К VD (29.07.2012 11:31:06)
Дата 29.07.2012 13:45:25

Re: :))

"в сторону протоколов, шифрования, распознавания, ИИ и пр. хайтека"
- это все свистки и погремушки не более того. Системный архитектор увязывает это все в систему,, в продукт ечнологический некий - но он существует не сам по себе, не для того чтобы погромче "свистеть и греметь" - а только и исключительно чтобы поддержать "бизнес процесс" обслуживающий предметную задачу - например "взять под контроль населенный пункт", или "зачистить местность от бабаев". И жот тут даже мало будет "системного аналитика", а нужен военный аналог "бизнес аналитика" - иначе все это "протоколы" уйдут в свисток. В-общем - то что я прочитал у Вас - типичная ошибка молодого специалиста которому еще не хватает опыта, хотя знаний может и много. не обижайтесь
От VD
К oleg100 (29.07.2012 13:45:25)
Дата 29.07.2012 17:35:43

Re: :))

Приветствую!
>"в сторону протоколов, шифрования, распознавания, ИИ и пр. хайтека"
>- это все свистки и погремушки не более того. Системный архитектор увязывает это все в систему...
Каким образом наличие некого архитектора противоречит основным технологиям, которые дадут новое качество? Без этих "погремушек" вы просто получите очередную отсталую, как мамонт, ЕСУ ТЗ. История с ТПВ, беспилотниками, ВТО никого ничему не научила даже на ВИФе? Ведь пока Вы тут зажигательно рассказываете абстрактные вещи из учебников, там интегрируют системы ИИ для оперативного управления, а сетецентричность, основанная на _стандартизированных_ (для этого целые комитеты и конференции проходят) реалтайм _протоколах_ обмена боевой _информацией_ (да нет там слова документ нигде) стала вообще общим местом.

С уважением к сообществу.
От Чобиток Василий
К VD (29.07.2012 17:35:43)
Дата 29.07.2012 18:16:41

Re: :))

Привет!
>Приветствую!
>>"в сторону протоколов, шифрования, распознавания, ИИ и пр. хайтека"
>>- это все свистки и погремушки не более того. Системный архитектор увязывает это все в систему...
>Каким образом наличие некого архитектора противоречит основным технологиям, которые дадут новое качество? Без этих "погремушек" вы просто получите очередную отсталую, как мамонт, ЕСУ ТЗ. История с ТПВ, беспилотниками, ВТО никого ничему не научила даже на ВИФе? Ведь пока Вы тут зажигательно рассказываете абстрактные вещи из учебников, там интегрируют системы ИИ для оперативного управления, а сетецентричность, основанная на _стандартизированных_ (для этого целые комитеты и конференции проходят) реалтайм _протоколах_ обмена боевой _информацией_ (да нет там слова документ нигде) стала вообще общим местом.

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

И если у них информационная система разработки... средины 70-х (!!!) достаточно эффективно решает вопросы бизнес-процесса, то она решает эти вопросы до сих пор.

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

Даже был такой смешной случай. Одному американскому представителю показывали работу прототипа системы. На экран выводится сформированный отчет, он смотрит и спрашивает:

- пидиэф?!

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

- Вот?
- пидиэф?
- А! ес, ес, пидиэф!
- Оооооооо!!!!

Это "о" было с таким выражением восторга и счастья, как будто он сейчас получил эротическое наслаждение. Оказывается они только размышляют о том, чтобы все копии судебных документов хранить в PDF, а мы уже типа впередли планеты всей...

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

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

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От VD
К Чобиток Василий (29.07.2012 18:16:41)
Дата 29.07.2012 18:50:09

Re: :))

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

>А Вы говорите технологии. Технологии предоставляют возможности, но нужна определенная зрелость, чтобы понимать, что они вторичны.
А для чего тупые американцы создали DARPA? Как раз для того, чтобы определить какие технологии принесут качественные изменения. И определяют, создавая проектные группы, которые и содержат экспертов в предметной области/областях. Про это сто раз говорено, что надо перенимать передовой опыт организации ОКР, если нет желания тратить деньги впустую.

С уважением к сообществу.
От Суровый
К VD (29.07.2012 18:50:09)
Дата 29.07.2012 22:31:54

Про это джоэл хорошо написал. "огонь и движение" огнём падо-облаков прикрывают

реальное движение вперёд только и всего
От Лейтенант
К Чобиток Василий (29.07.2012 18:16:41)
Дата 29.07.2012 18:22:11

Верным путем идете, товарищ

Выам горят не о конкретных технологиях, а о методических подходах.

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

Верным путем идете, товарищ. Путем Задорнова.
От oleg100
К VD (29.07.2012 17:35:43)
Дата 29.07.2012 18:15:26

Re: :))

я был подписчиком хардкопиз этого журнала с момента его создания
http://www.c4isrjournal.com/story.php?F=magazine
и 15 лет проработал в телекоммуникациях (софт). какбэ в курсе :).
есть профессии в которых легче чем в точных науках мимикрировать, имитировать, выдавать фейк вместо реального результата. Это всяческие гуманитарные типа историков, художников-писателей (а я так вижу!). пример из нашей темы - разного рода аналитики. При отсутствии опыта ума знаний такой "аналитег" вам наваяет бумаг графиков диаграмм а толку ноль. такие спецы дискредитируют профессию и дают повод "твердым профессионалам" считать что они и сами лучше справятся - они же так хорошо знают все про "протоколы", "сетецентризм", "клаудс", "сервера" там :)). А вот подняться на этими "облаками" и суметь увидеть как приложить их к тем же самым старым как век человеческим задачам :)) - вот где мудрость требуется и опыт именно предмета приложения. ДА ладно. Мы ведь все тут хотил чтобы в русской армии современной - и погремушек было в достатке, и чтоб оно еще и работало.. так ведь? :))
От Чобиток Василий
К VD (29.07.2012 11:31:06)
Дата 29.07.2012 13:25:52

Re: С вами...

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

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


>И какое это отношение имеет к нормальной АСУ управления войсками? Особенно той, которая может помочь в реальной войне, когда идут потери, узлы связи и штабы выводятся из строя, противник активно маневрирует? Там просто совсем другие принципы работы,и документооборот в академическом виде занимает по важности далеко не первое место. Вам оппонент правильно сказал, что в первую очередь это NRT распределенная БД. Поэтому и копать надо в сторону протоколов, шифрования, распознавания, ИИ и пр. хайтека.

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

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

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

Эта компания обосралась по-полной. А на фоне другой компании, где всем этим успешно занимались три-четыре "калеки" на старых технологиях но со знанием предметной области, вышел просто эпик-фэйл!


Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От VD
К Чобиток Василий (29.07.2012 13:25:52)
Дата 29.07.2012 17:59:37

Re: С вами...

Приветствую!
>Нихрена из обсуждения не поняли Вы. Применение сущности "документ" никак не противоречит и не заменяет иное информационное обеспечение, как единичных бойцов и единиц техники, так и начальства любого уровня.
Эта сущность противоречит принятой в зарубежной литературе (за отсутствией отечестыенной) терминологии. Везде фигурирует "информация", "данные", "команда". Лучше не тянуть термины из других областей, и не путать таким образом сообщество.

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

>У меня есть прекрасный пример, когда крупнейшая компания вышла на рынок судебного документооборота со всеми новейшими технологиями, людскими, финансовыми и административными возможностями.
А военные эксперты не согласны с вашей точкой зрения. И в один голос говорят о пересмотре алгоритмов штабного управления в свете появления новых возможностей. Что за рубежем, что у нас.

С уважением к сообществу.
От Чобиток Василий
К Чобиток Василий (29.07.2012 13:25:52)
Дата 29.07.2012 15:02:23

Re: С вами...

Привет!

>Эта компания обосралась по-полной. А на фоне другой компании, где всем этим успешно занимались три-четыре "калеки" на старых технологиях но со знанием предметной области, вышел просто эпик-фэйл!

Просто чтобы не быть голословным.

Вот реальный пример:
http://armor.kiev.ua/wiki/Участник:ArmorAdmin/Распределение_судебных_дел

- есть заказчик, который "сам не знает, что хочет", причем не один - Государственная судебная администрация и ее департамент Статистики и делопроизводства; Верховный суд; Высшие суды; все прочие суды; комиссия Верховной рады по борьбе с коррупцией в судебной системе; забугорные добровольные помощники и спонсоры - USAID, Еврокомиссия, какая-то канадская ассоциация чего-то там и пр. и пр.
- есть разные разработчики, которые месяцами делают распределение и сделать не могут. Потому что одни делают в лоб жестко по законам, и по требованиям, которые есть в текущий момент от конкретного суда, куда идет внедрение. А другие делают монструозную универсальную платформу, совершенно не вникая в предметную область.


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

А все, что было нужно - специалисту в области разработки вникнуть в проблему предметной области.

Предложения, заявления, жалобы есть? http://armor.kiev.ua/
От Суровый
К Лейтенант (28.07.2012 17:37:56)
Дата 28.07.2012 18:00:53

понятие "документ" фиксировано законодательством РФ непонятно о чём вы спорите

и квитирование никакой не панадол
если судья принимает по несколько сот решений в день (в РФ, в США, в Украине - везде такое есть),
то вне зависимости от качества квитирования встаёт вопрос о степени доверия вынесенным им решений
От Чобиток Василий
К Суровый (28.07.2012 18:00:53)
Дата 29.07.2012 03:34:57

Оказывается разработчику документооборота это понятие побоку как абстрактное :( (-)
От Суровый
К Лейтенант (28.07.2012 13:48:03)
Дата 28.07.2012 13:49:55

В России арбитражные суды впереди остальной судебной системы

и средний хозяйственный спор тянется много - полгода