Наткнулась еще на одну подобного рода вакансию. Меня сначала это объявление возмутило - они в названии вакансии так и указали "Программист, бизнес аналитик (IT)":

Западная компания, поставщик высококачественного электрооборудования для строительства и промышленности открывает вакансию «Программиста (Бизнес - аналитика)»

Требования к кандидатам:
Высшее профессиональное образование
Опыт работы в сфере информационных технологий не менее 3-х лет
Знание SQL, OLAP
Владение СУБД, системами построения отчетности Reporting Services
Владение принципами работы ERP-систем
Владение основами теории организации

Основные обязанности:
Разработка, построение и внедрение максимально эффективной системы отчетности, отвечающей потребностям пользователей и бизнеса
Сопровождение системы отчетности компании
Моделирование и анализ бизнес-процессов, их оптимизация
Участие в составлении бюджетов компании, анализ проблемных мест в бизнесе, подготовка рекомендаций для принятия управленческих решений
Участие в поддержке ERP-системы iScala

Наткнулась еще на одну подобного рода вакансию. Меня сначала это объявление возмутило - они в названии вакансии так и указали "Программист, бизнес аналитик (IT)":

А потом?

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

Если речь идет именно о разработке состава отчетов, тогда, может, еще не все так плохо. Но почему тогда они написали, что им нужен "программист, бизнес аналитик"?

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

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

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

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

Умение программировать ... служит своего рода ограничением при формировании требований

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

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

<...>Получается, что для разработки Help очень неплохо знать UML :-), а для написания ТЗ по ГОСТ 19 или 34 нужно уметь литературно редактировать текст Ниже оригинал объявления ...<...>

ЕСПД (которую, скорее всего, имели в виду)  - это не только ТЗ/ЧТЗ/ЭП/ТП, но и различные руководства. В т.ч. пользователя, администратора, системного программиста, программиста. Содержание у них - IMHO вполне здравое. И чтобы удобоваримо написать такое - нужно иметь порядок в голове и уметь принять сторону пользователя. Или, что страшнее, вжиться в роль администратора, а то и самого программиста. В общем, Станиславский отдыхает . Так вот, надо рассказать этому пользователю-администратору-программисту, как ему удовлетворить его потребности при помощи существующей, великой, могучей, до конца не познанной системы, созданной, чтобы получить просветления, а не ради удовлетворения земных нужд. Причём лучше описать языком Пришвина и снабдить занимательными цветными картинками а-ля "Мурзилка".

Некоторые системы обладают большой сложностью, естественной и/или наведённой. Чтобы написать руководство по такой системе, нужно обладать высокой квалификацией. В т.ч. побывать в роли пользователя, администратора, разработчика. Что в этом удивительного? Хорошее руководство написать непросто. Особенно если кто-то в жизненном цикле ПО до тех. писателя сделал свою работу... не очень хорошо. Особенно - если системный аналитик и дизайнер UI.

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

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

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

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

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

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

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

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

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

Опытный разработчик обычно хорошо разбирается в предметной области.

Agile методы так и работают: выделенных аналитиков, как правило, нет, и выявлением требований занимается вся команда

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