На просторах работодателей бывают волшебные вакансии в которых в должность СА входит пресейл, работа с базами данных (Знание SQL), тестирование и даже кодирование.

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

Аналитик должен описывать:
Прецеденты, Функц. треб., Биз. треб., Пользов. треб.

Аналитик НЕ должен описывать :
Нефункц. треб., тестовые сценарии, классы, интерфейсы и реакции системы (кроме Пользов. треб.), модель БД, код и т.п.


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

Архитектор - архитектуру системы, на чем она будет, с какой БД, какими паттернами и проч концепт.

Тим-лид - Описывает КАК ДОЛЖНА РАБОТАТЬ СИСТЕМА что должны накодировать программисты.
Пишет "По нажатию кнопки Создать создается объект документ типа Договор. Сохраняется в БД в таблице Договора. Пользователь может редактировать документ, может не редактировать, у него такие-то инструменты, ограничения документа по следующим атрибутам, если они не заполнены выдается ошибка, редактирование может окончится удалением документа в случае ... И Т.П."

Тестировщики - тест кейсы на основе прецедентов.


ИТОГО:
Аналитик не придумывает какой аллерт должен выскочить при неправильном заполнении полей, если об этом его не попросил Заказчик. Не придумывает типы переменных , длину переменной лучше конечно указывать аналитику. Не придумывает кнопки, их расположение и функционал, интерфейс и прочь кроме указания пожеланий клиента.

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

А уже из п. 2 и 3 тим-лид пишет постановки программистам, а те код.

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

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

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


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

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

Но если человек может делать что-то, о чем не договаривался и не делает, хотя это могло бы помочь команде, то для него это не очень хорошо статегически

Аналитик не придумывает какой аллерт должен выскочить при неправильном заполнении полей, если об этом его не попросил Заказчик  -- а если аналитик продуктовый и заказчика нет? Получается, что "нет системы - нет проблемы"

Как должно быть:
Аналитик - Описывает как хочет работать Заказчик....

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

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

Заказчик может много о чем не попросить и умолчать, потому что сам считает:
1. Ну это же само собой разумеющееся! Все это знают!
2. Ну вы же умные, вам виднее.

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

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

а если аналитик продуктовый и заказчика нет? Получается, что "нет системы - нет проблемы"

Заказчик есть всегда.
нет заказчика, нет проблемы - верно.
В этой роли будут продукт-менеджеры и маркетологи, возможно продуктовый аналитик, но мы говорим за СИСТЕМНОГО АНАЛИТИКА

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

ИМХО

Аналитик не пишет интерфейсы, тем самым не ограничивает программистов.
Аналитик не знает новостей паттернов, СУБД, и прочих фичей программистов.
Аналитик не занимается нефункционалом, он пишет Биз треб - "Система должна открываться за 2 сек макс, в 50 городах страны, 24/7 ", а Архитектор с Тимлидом и ПМ решают на какой СУБД, каким железом и есть ли канал 10 мбит на Камчатке.

И аллерт кстати пишет тим лид, потому что Аналитику побарабату на Шарепоинте или на Е-бизнессьюте будет документооборот писаться, это решают на концептуальном уровне основываясь на инфу аналитика.


Суть в том что, чтобы сделать идеальный продукт, каждый должен быть на волне, Программист, ТимЛид, Архитектор, иначе они устареют.

У программистов есть такое воерие, Отличный программист может стать Архитектором, но через 2-3 года он станет средним программистом. Время идет и знания устаревают!

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

Kavalsky, какую задачу вы решаете?

Что ОБЫЧНО делает системный аналитик и что ему в принципе СТОИТ делать, мы обсуждали сообществом несколько лет назад, результаты зафиксированы тут:
http://ru.wikipedia.org/wiki/Системный_аналитик

Кроме того, есть стандарт профессии от АПКИТ, который достаточно запутанный, но перечень умений и задач там есть, как опорная точка пойдёт.

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

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

Аналитик не пишет интерфейсы, тем самым не ограничивает программистов.

Обычнно да.

Аналитик не знает новостей паттернов, СУБД, и прочих фичей программистов.

Обычно да. Хотя незнание принципов работы СУБД ему может сильно мешать.

Аналитик не занимается нефункционалом, он пишет Биз треб - "Система должна открываться за 2 сек макс, в 50 городах страны, 24/7 ",

Не знаю, что такое «нефункционал». Люди, которые упоминают это слово в гугле, обычно имеют в виду, что что-то не работает.

а Архитектор с Тимлидом и ПМ решают на какой СУБД, каким железом и есть ли канал 10 мбит на Камчатке.

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

И аллерт кстати пишет тим лид,

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

потому что Аналитику побарабату на Шарепоинте или на Е-бизнессьюте будет документооборот писаться, это решают на концептуальном уровне основываясь на инфу аналитика.

Каждый раз, когда кому-то что-то «по барабану» — это звоночек о риске. В системе всё взаимосвязано, и выбор платформы определяет атрибуты качества системы в «design time». Аналитику полезно знать, какими свойствами будет обладать система, обусловленными платформой.

Суть в том что, чтобы сделать идеальный продукт, каждый должен быть на волне, Программист, ТимЛид, Архитектор, иначе они устареют.

Совсем не понял фразу. Не нашёл сказуемого к «Программисту, ТимЛиду, Архитектору».

У программистов есть такое воерие, Отличный программист может стать Архитектором, но через 2-3 года он станет средним программистом. Время идет и знания устаревают!

Каких только воерий нет у программистов!

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

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

Большинство знакомых мне «бизнес-аналитиков» для конкретной компании ценны прежде всего знанием предметной области и платформы, т.к. позволяют быстро придумывать решения 1) полезные заказчику 2) реализуемые не очень дорого.

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

Аналитик не занимается нефункционалом, он пишет Биз треб - "Система должна открываться за 2 сек макс, в 50 городах страны, 24/7 ", а Архитектор с Тимлидом и ПМ решают на какой СУБД, каким железом и есть ли канал 10 мбит на Камчатке.

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

И аллерт кстати пишет тим лид, потому что Аналитику побарабату на Шарепоинте или на Е-бизнессьюте будет документооборот писаться, это решают на концептуальном уровне основываясь на инфу аналитика.

А откуда инфа у аналитика, если ему "побарабану" в каком окружении у клиента будет использоваться продукт?
Откуда тимлиду вообще узнать где и какие алерты должны быть? Непонятно:)

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

Kavalsky, так вопрос был о том, что должен делать аналитик:
1. Вообще, всегда
2. В основном, или
3. В идеальной структуре?

В Лаборатории Касперского, например, организована детальная структура с выделением должностей и отделов, есть такие должности, как:
Менеджер продукта
Маркетинг-менеджер
Менеджер по запуску продукта
Бизнес-аналитик
Менеджер проекта
Тимлид системных аналитиков
Системный аналитик
Проектировщик интерфейсов
Архитектор приложения
Тимлид разработки
Разработчик интерфейса
Разработчик бизнес-логики
Тест-менеджер
Тестировщик
Технический писатель
Локализатор
Инженер по сборке

(Я могу всех не вспомнить, мои бывшие коллеги, которые там ещё работают, меня поправят)

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

Если вопрос про то, какова область ответственности и функции СА в такой высокоспециализированной организационной структуре, то можно посмотреть описание вакансий аналитиков ЛК, если нужно — могу поискать должностные инструкции.

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

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

Пойду читать Путь аналитика и ГОСТ 34, 29 (там своих приколов в должностных обязанностях по-моему)

Как должно быть:

Кому должно???
Работодателю? Так вы ему об этом говорите, а не в форум - здесь он вас не прочитает.

Дети с комплексом Бога, вместо того чтобы придумывать мифические правила, идите лучше в поля поработайте - там вам быстро объяснят, что аналитик должен и не должен, кому и в каких случаях. Не нравится - становитесь руководителями и пишите правила сами.

Кому должно???

Дети с комплексом Бога....

Тяжелый день? Весна прошла мимо?

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