Пост навеян ретроспективой прошедшего ЛАФ-2012.

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

Этому могут быть три объяснения:
1) работа аналитика выродилось в описание usecase/userstory и проектирование интерфейса, остальное делают разработчики;
2) когда первичные требования сняты, в проектировании реализацию - структуры данных и прочее - нет ничего сложного, берешь и делаешь;
3) все общее, что можно сказать о проектировании, сказано методологами по ООП и другими, остальное зависит от проекта и сплошной креатив - не расскажешь и не обсудишь.
Мне все эти варианты не слишком нравятся, да и не представляются верными.

Поэтому как идея: попробовать перед программой следующего ЛАФ поработать над поиском докладов именно в эту сторону.

А что остальные думают? Было бы интересно услышать/рассказать/обсудить именно проектирование системы?

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

Я сильно соглашусь с Максимом. Он попал в точку ситуации. У меня подобное ощущение тоже складывается. Правда, для себя я это обозначал иначе: переносом акцента на организацию, чем на практику и технологию. Т.е. мысль, что мол вот навыки аналитика они как есть, так и есть. И чего о них рассказывать. Когда уходим в рассуждения о технических вопросах, то тут все сильно зависит от контекста и тоже казалось бы нечего обсуждать - у каждого своя правда, никто не договорится. Но может быть договоримся?

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

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

А может просто сначала опишем критерии  почему я , он , они не занимаются проектированием системы.
1. Не хватает опыта для проектирования всей системы. Говоря понятиями Дениса Иванов и Федора Новикова, часто трудно охватить  и представление использования, и представление структуры, и представление поведения системы.
2. Не дают (сформулировал требования и свободен . Дальше разработчики решают. Можно сказать - организационная часть . В АПКИТ, например разделяют, Системный аналитик и Системный архитектор.
3. Финансовая сторона - мне не платят за доп работу. Это уже нацеленность именно команды на результат. Одному сложновато спроектировать систему.
4. Нет времени еще и на это. Именно в данном проекте. Что-то вроде, надо за 2 неделе написать ТЗ, когда надо новое  и по сути в ТЗ описываешь требования только  для общей архитектуры системы.

На одной посещённой мною конфереции (ProfsoUX) доклады были сгруппированы по трём темам - требования, разработка, тестирование. Возможно, в будущем имеет смысл и на ЛАФ сделать что-то похожее, но перекос, на мой взгляд, всё равно должен быть в сторону требований.

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

Максим, спасибо за актуальную тему.
У меня есть такое мнение на этот счет.

1) работа аналитика выродилось в описание usecase/userstory и проектирование интерфейса, остальное делают разработчики;

Описание это лишь малая часть работы аналитика.
Основные задачи:
 -  построение коммуникаций Заказчик - Разработчик (Заказчик - Система);
 -  управление требованиями;
 -  управление "ожиданиями Заказчика" (в части проектируемых систем).

Не стоит забывать, что есть проекты связанные с внедрением различных систем на интегрированных платформах (1C, Axapta, Oracle, SAP и т.п.), где доля классического или ООП программирования невысока. В таких проектах востребованы сущностные модели и модели прикладного решения.
И здесь нужны очень серьезные знания по текущему или готовому решению, что требует наличия Архитектора решения, который может оценить предлагаемые изменения с точки зрения всей системы (или совокупности систем).

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

Я сторонник "разумной специализации". И для тех проектов про которые я говорил наличие выраженной роли архитектора (ведущего разработчика) очень важно.
В этом случае "сложность" переходит на уровень Архитектора.
Также это позволяет аналитику не особо углубляться в очень уж технические моменты и направлять свои усилия на логический уровень системы и коммуникации с Заказчиком.

А что остальные думают? Было бы интересно услышать/рассказать/обсудить именно проектирование системы?

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

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

Максим, аналитик отвечает за проектирование ВНЕШНИХ свойств системы. Архитектор, разработчик — ВНУТРЕННЕГО устройства.

Внешние свойства описываются логикой взаимодействия, НФТ и пользовательским интерфейсом.

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

Второй необязательной деятельностью является сущностное моделирование.

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

Иногда проектирует ИС как ИС, а не просто ПО, но такое редко кому достаётся по ряду причин.

Резюмируя, типовыми объектами работы аналитика являются, по мере убывания частоты:
1. Внешнее поведение системы
2. Алгоритмы (бизнес-правила)
3. Внешний облик системы
4. Устройство предметной области
5. Процесс, который строится или меняется при создании/доработке этой программной системы
6. Организационно-техническая система (бизнес)

Собственно 1, 3 и 4, 5 — это то, что больше всего обсуждалось на конференции. Всё разумно.

Не было на ЛАФ, да и на других не помню, кроме своего доклада: "Описание инфологической модели. Применимость различных нотаций в зависимости от контекста." Тема сложная, но идет на ура. Только где на нее докладчика найти?

Что касается проектирования системы, то часто аналитик берет на себя описание и/или разработку API. С внешними системами, так это просто раздел 34.602. Но бывает обязательно и внутренние API. Опять же скажу по двум проектам, в которых участвовал  тема очень интересная и весьма сложная.

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

Не было на ЛАФ, да и на других не помню, кроме своего доклада: "Описание инфологической модели. Применимость различных нотаций в зависимости от контекста." Тема сложная, но идет на ура. Только где на нее докладчика найти?

Тема-то какая? Опсание инфологической модели? А насколько устойчив данный термин сейчас? А что значит в различных нотациях, в чем прелесть?

Не было на ЛАФ, да и на других не помню, кроме своего доклада: "Описание инфологической модели. Применимость различных нотаций в зависимости от контекста." Тема сложная, но идет на ура. Только где на нее докладчика найти?

Что касается проектирования системы, то часто аналитик берет на себя описание и/или разработку API. С внешними системами, так это просто раздел 34.602. Но бывает обязательно и внутренние API. Опять же скажу по двум проектам, в которых участвовал  тема очень интересная и весьма сложная.
Такая же тема про нефункциональные требования. Мало кто делает, хотя очень полезно. Вот и докладов нет. Мы просто не доросли.

Ну так и "дорастите" к следующему ЛАФУ - сделайте доклады на эти темы . Тем более есть опыт в проектах.

Все-таки, у нас - сообщество системных аналитиков, а не бизнес-аналитиков. Системный аналитик - он (по классике) стоит после бизнес-аналитика и создает дизайн системы, в рамках верхнеуровневой архитектуры, заданной архитектором. Это к вопросу о понятиях вообще. Если говорить о практике, то, наверное, где-то аналитик выступает именно как бизнес-аналитик, снимает требования в виде usecase/userstory, а дальше все делают разработчики. Но, наверное, не все так - кто-то из аналитиков делает диаграммы классов/ER-диаграммы, описывают поведение объектов системы? И там есть свои проблемы и решения. И хочется к следующему ЛАФу призвать поделиться опытом. Я могу рассказать как делаем мы (я, собственно, весь прошлый год рассказывал это на разных конфах, включая ЛАФ), но мне интересно чужой опыт послушать...

создает дизайн системы, в рамках верхнеуровневой архитектуры, заданной архитектором

Максим, можно ссылку на такое классическое определение? Классическое для какой культуры?

Почему ты считаешь, что разработка use case'ов — это бизнес-анализ?

Все-таки, у нас - сообщество системных аналитиков, а не бизнес-аналитиков.

А я думал что мы "волшебники". Максим я бы не стал так ограничивать границы сообщества.

Все чаще задумываюсь о месте чистого системного аналитика. И прихожу к такому выводу: думаю, что такая профессия себя изживет. Бизнес-аналитики активно осваивают информационные технологие и вникнуть в технические тонкости разрабатываемой системы им уже не сложно. Например,  в нашей компашке смело пишут US и выполняют две функции бизнес и системный анализ. А писать ТЗ с реализацией проще программисту, чем СА вечно пристающий с вопросами к программисту. Т.е. функции СА разделит БА и Разработчик между собой. Да сейчас БА и СА могут позволить только крупные и богатые компании. 

Системный аналитик - он (по классике) стоит...

Для начало с определений можно начать
Максим а можно ссылку на классику
А то на разное ссылаться будем.

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