"Если хотите навредить стране, то должны вкладываться в подготовку IT-специалистов"

Во-во!!! И в космос зачем полетели?!?! Амеров же там не было до нас!!! 

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

ответ на этот вопрос содержится в последнем предложении поста. Это стало возможным, Потому что в ядерном и ракетном проектах мы соревновались с госбюджетом США и победили его, а в электронике нам противостоял бюджет Intel и всего мирового рынка

-----

Если ярость, застилающая глаза, оттого, что в интернете кто-то несогласен с Вами, мешает Вам адекватно воспринимать разницу между кафедрой ВСС Бауманки, ВМК МГУ и прочими "Ай-ти специалистами" из Таганрогского педагогического института , то и хрен с ним, не так ли ? Тем более, что в конце своего гневного опуса, Вы так и указали:

Студентов колледжей так вообще уже не смотрю: пустая трата времени. Да, и кстати, наличие вышки в ИТ -- лишь допуск к собеседованию

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

При поиске и приёме на работу ITшника никому нафиг не нужен его диплом,

Если логика в рассуждениях отсутствует, нафига мне спорить ? Я и не буду больше.

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

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

Дисклеймер:

1. не могу знать и полагаться на ваш (или читателя) уровень знаний/опыт, поэтому некоторые вещи проговариваю, только чтобы обратить на них внимание;
2. отвечаю подробно и с примерами, т.к. предыдущий ответ не вызвал понимания, о каком процессе речь, кто и когда его поломал (простите за длину, но описанная ИТ-кухня может быть интересна людям со стороны);
3. чтобы три раза не "вставать", отвечаю последовательно по трём цитируемым моментам.

"По сути он должен разбираться и там и там.

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

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

Помимо банального дефицита людей, умеющих разбираться (в описанном выше смысле) в устройстве вещей и процессах, а также конструировать специальное описание того, в чём разобрались, есть иной вариант, который может приводить к ошибочному выводу "Попробуй найти ... нормального постановщика ТЗ ", т.е. человека, "который сможет погрузится в бизнес-процесс и написать ТЗ  ..." . Возможная поломанность процесса в описанном вами случае заключается в фундаментальной ошибке подхода, т.е. в том, что "сможет погрузится в бизнес-процесс и написать ТЗ". Этого многие, почему-то, ожидают. Наверное, потому что таким им видится некий процесс или путь, приводящий к решению их проблемы. Но это ожидание в принципе не верно в случае бизнес-процессов или производственных процессов: из этой фундаментальной ошибки и вытекает 70% проваленных ИТ-проектов. Ключевую роль в том, как эта ошибка подхода сказывается дальше, играет то, что мир ИТ очень тесен, особенно -- сообщество аналитиков: некоторой компании скрыть какие-то внутренние косяки организации процесса разработки или заказа практически невозможно.

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

Теперь попробую объяснить иными словами, в каких местах поломан процесс «автоматизации», о чём я говорил в предыдущем ответе. От простого к сложному.

Что есть автоматизация, в чём она заключается и к чему применяется?
По семантике самого слова а. означает "вынести нечто на исполнение на некий автомат". Т.е. была некая совокупность операций, действий, как-то выполняемая по времени и условиям над некими объектами (материальными или информационными). Заметили, что та совокупность действий либо повторяется полностью, либо многие её части повторяются полностью и повторно используются, и входные/выходные параметры, как и другие условия, могут быть точно определены и выведены на интерфейсы. Собственно это и делают -- воплощают автомат: реализуют в нём иным образом операции, приводящие к тем же требуемым ключевым результатам процедуры, этапа или процесса, но другим путём, и их управление выводят на соответствующие интерфейсы.

Интерфейсы определяются преобразованием внешнего языка, используемого оператором, во внутренний язык управляющих команд, которые система управления транслирует в примитивы автомата, физические (напр., поворот шагового двигателя) или логические (ассемблерные инструкции, а дешифратор -- в микрооперации внутри самого процессора ещё и с раскладкой по разным кешам, а тот уже в физические над состояниями регистров и TTL-ключей). Формы внешнего языка определяются исходя из задач и требований к взаимодействию -- т.е. это особенности его реализации, а не само реализуемое взаимодействие (разница как между принципиальной схемой и конкретной разводкой платы). Как эти команды будут доставляться автомату, выбирается при реализации и зависит от задачи и ограничений: от дёргать рычаги и крутить ручки или давить физически размещённые кнопки и тумблеры до опосредованной передачи на исполнение текстов на специализированном языке предметной области, именуемых скриптами, сценариями или программами. Аналогично для интерфейсов выхода: как будет представляться результат, на экране текстами с рисунками, в виде обработанной болванки, отправленным СМС, email или ещё как-то, -- определяется целями и решаемой задачей. Т.е. нужно различать принцип, цели и их реализацию, а также автоматизацию от реализации, как уровень и вид действий.

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

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

Из приведённых понятий бизнес-процесса и автоматизации следуют очевидные вопросы:

1. какая совокупность действий бизнес-процесса переводится на исполнение неким автоматом?
2. в какой форме будет этот автомат?
3. какие требования к интерфейсу такого автомата?
4. какие операторские роли для управления этим автоматом?

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

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

2) "По-старому" после "автоматизации" в принципе быть не может, потому что проблема как раз в том, что "по-старому" не удовлетворяет новым требованиям по разнообразию действий, результатов, производительности, затрат и т.д. Т.е. в любом случае будут новые интерфейсы, новый язык взаимодействия пользователя с системой, другие команды, кнопки, формы и т.д. Да, такой язык и интерфейсы могут по-прежнему использовать элементы прежней системы, в частности, термины, локальный порядок действий, формы подачи сведений, что нормально. Например, в случае автоматизации печатной машинки уже не нужно будет заряжать в автомат бумагу сразу перед набором текста, и после каждой строчки возвращать лист на положение для первого символа строчки, но ввод букв и цифр будет реализован в обязательном порядке. При этом добавятся возможности по сохранению текста, операции Undo/Redo, Copy/Cut/Paste и т.д. А при дальнейшем развитии темы -- кодировки, форматирование, стили, рецензирование, совместное параллельное редактирование, управление версиями, публикация и т.д.

3) Разобраться в существующем бизнес-процессе -- прямая обязанность системного аналитика: в этом состоит начало его работы над проектом. Методам для этого учат как в специализированной ИТ-школе, так и общей (например, как организовывать и проводить интервью, с кем, когда и зачем, как ставить вопросы, как противодействовать саботированию, как фиксировать договорённости и результаты, и т.д. не буду дальше перечислять -- там много действий, этапов и других моментов). Книг на эту тему тоже уйма, но должна быть здоровая практика, чтобы не терять время на неработающие вещи, о которых можно узнать на конференциях и в сообществе, ну или через собственные пробы/ошибки. Если бизнес-процесс не документирован, как это обычно и бывает просто потому что для этого тоже нужен системный аналитик, технический писатель и внутренняя востребованность со стороны руководства и остальных участников, это лишь добавляет сложностей.

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

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

Итак, в виду характера описанных выше изменений и трёх моментов я и говорю, что процесс разработки поломан: вместо того, чтобы реализовывать существующий бизнес-процесс иным образом, т.е. построить иными средствами фактически новый бизнес-процесс с новыми возможностями, удовлетворяющий принципиальным требованиям старого (клиенты должны обслуживаться вовремя в полном объёме), но также и удовлетворяющий новым требованиям (в т.ч. и к средствам/методам реализации, к нагрузке, управляемости, сохранности, возобновляемости и восстанавливаемости от сбоев), системному аналитику навязывается задача воплощения некой автоматизации бизнес-процесса, потому что такой путь видит заказчик в решении его проблемы, вместо существа самой проблемы, которую и должен решать аналитик вместе с заказчиком.

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

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

как в экселе ... И ему нас рать на ограничение архитектуры.

Мой опыт показывает, что если речь о приложении, которое должно бегать на персоналке, то это решаемо и проблемы не в ограничениях архитектуры: я сделал уже 4 таких проекта  от нуля и до внедрения, и спрос на них, почему-то, растёт. Просто нужно реализовывать интерфейсы взаимодействия прямо в Excel или Access -- в них и для них для этого есть все необходимые инструменты (VBA Editor, MS VS Office Tools) и фреймворки (от стандартных элементов форм до полной интеграции с собственными библиотеками, .NET, СУБД или XML), даже если нужно, чтобы это бегало под *nix, Mac и соединялось с MySQL/Oracle или NoSQL-хранилищем и интегрировалось с Java/Perl/Ruby-кодом (SWIG и знание внутренних интерфейсов рулит). Да, и все данные вываливать пользователю сразу тоже совсем не обязательно (т.е. технические ограничения на количество ячеек, точек и рядов в графиках обходятся). С обработкой событий мыши несколько сложнее (потому что это Microsoft, Office и VBA), но с этим тоже можно справиться, если не искать стандартных путей, а честно собирать и управлять сведениями о состоянии процесса ввода.

И есть другой вариант -- системный аналитик должен спросить такого пользователя, что именно должно быть "как в экселе". Обычно, отвечают, что фильтрация, сортировка, пометка различным образом записей для разных целей, быстрое пролистывание, раскладка на листы и сводные отчёты. Это тоже решаемо стандартными способами на фреймворках почти всех модных языков программирования, даже PL и Ada, в т.ч. и с прямым формированием Excel документа (достаточно вариантов и библиотек для этого есть). Даже в случае со смартфонами и планшетами реализация будет сложнее. Т.е. без деталий и специфики не видно никах ограничений архитектуры: кто умеет, тот делает, есть всё необходимое для интеграции (в вашем случае, возможно, кто-то пытается отмазаться от задач, которые не знает чем и как решать). Единственное, за что я бы точно не взялся, так это делать подобные решения на встраиваемых системах.

Все таки ТЗ для кодеров Техническим Проектом зовется.

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

Но если по ГОСТу, то Технический Проект -- это один из этапов хорошо известного плана разработки с выходом одноимённого документа, а также с документами по комплектности, определённой на предыдущих этапах. Эта комплектность и состав самой документации первый раз определяются на этапе технического предложения (тоже имеет на выходе одноимённый документ и ряд других), затем доопределяется на этапе эскизного проекта. А ТЗ -- это лишь один из видов технической документации, которое формируется и постепенно уточняется, начиная с этапа технического предложения, и обычно входит в перечень документации, подлежащей разработке на этапе технического проекта для передачи на технорабочий (если есть) и рабочие проекты. ТЗ для кодеров оно и есть ТЗ для кодеров -- ГОСТ 19.201-78. ЕСПД (по 34-ому говорить не буду).

Так вот ещё одна поломка процесса заключается в том, что типовой процесс разработки, предполагаемый в  описываемом вами случае, если делать по ГОСТ 19, был коряво и давно слизан с предшественника RUPa (Rational Unified Process). Потому запихать в него современные методы разработки и выходную документацию тяжело, но возможно. Однако это будет формированием некой иллюзии о процессе разработки на уровне документации. Например, диаграмму взаимодействия (UML) или варианты применения, либо диаграмму бизнес/системной-архитектуры и оргструктуры, фактически, запихивать по составу и формату документов некуда, разве что в дополнительные документы, не определяемые, но разрешённые ГОСТ 19 в виде расширения (под кодами 90-99). В реале же, делать большую систему под бизнес-процессы без PowerDesigner и его моделей -- настоящий головняк (Aris даже рядом не лежал по широте решаемых вопросов разработки). Эти взаимосвязанные, трассируемые, версионируемые и почти полностью автоматически синхронизируемые модели (чтобы автоматом поддерживать и обеспечивать качество на всех уровнях всей документации с учётом постоянных изменений, вносимых параллельно аналитиками, архитекторами и разработчиками по ходу эволюции системы, вместо"и при этом проверить качество ТехПроекта по этому ТЗ") содержат всю ключевую документацию и по процессу разработки, и по системе (включая требования, бизнес-архитектуру, описание бизнес-процессов на BPMN или других языках, модели БД с серверным кодом, ОО-модели с прикладным кодом, модели развёртывания и т.д.). Но в формат документации ГОСТов те модели, как файлы со специальной структурой, т.е. электронная документация, не укладываются, очевидно, в принципе. А если речь о распределённой веб-системе, так вообще труба. Но частично эти проблемы решает 34-ый и некоторые другие ГОСТы.

С 78 года методология разработки ПО сильно эволюционировала, потому что на практике типовой водопадный метод, применяемый традиционно в обычной инженерии материальных систем, не работает, т.к. с одной стороны имеет место быть значительно бОльшая неопределённость (вызванная фактически отсутствием предваряющих НИР и предпроектных исследований, в отличие от стандартных ОКР/ОТР) и постоянная эволюция разрабатываемой системы, требований и инструментария, а с другой цена сборки управляющей/информационной системы (в переводе на материальные операции -- поиск поставщиков материалов, наладка поставок, их предобработки и контроля, и линии по выпуску продукции, изготовление образца или готового изделия вкупе с контролем качества) существенно ниже и происходит  посредством стандартных автоматов, таких как компиляторы, линковщики, деплоеры, системы автоматического тестирования  и загрузчики приложений в ОС.

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

Знаете, есть такая поговорка: "скажи человеку сто раз что он свинья и на сто первый он хрюкнет".

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

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