От Лейтенант Ответить на сообщение
К Чобиток Василий
Дата 29.07.2012 00:54:34 Найти в дереве
Рубрики Танки; Версия для печати

Re: С вами...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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