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

Хороший вопрос.

Волнует, куда развиваться  дальше. Уходить глубоко в предметную область одного Достаточно Большого Проекта или, наоборот, лучше поработать понемногу на нескольких разноплановых проектах.

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

Волнует, как планировать сроки согласования документов.

Волнует, стоит ли пытаться развиваться в сторону англоязычных проектов (язык пока pre-Intermediate). Тут и  на русском то иногда призадумаешься правильно ли понял заказачика. А если ещё и чужой язык будет?

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

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

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

а ещё волнует, что уроды все курилки во внуково сломали

а ещё волнует, что уроды все курилки во внуково сломали

это насильственное оздоровление населения, которое об этом не просило.

1. Коммуникации внутри команды и между командой и заказчиком.
Актуальность: в моей практике большинство крупных ошибок имели корни в недопонимании между заказчиками и аналитиками или менеждерами групп разработки.

2. Выявление и спецификация нефункциональных требований.
Актуальность: готовых техник выявления НФТ очень мало, в среднем у аналитиков меньше практики с НФТ, чем с ФТ.

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

4. Выбор направления для развития; как выбрать метод самообучения.
Актуальность: нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!

2. Выявление и спецификация нефункциональных требований.
Актуальность: готовых техник выявления НФТ очень мало, в среднем у аналитиков меньше практики с НФТ, чем с ФТ.

Многие группы НФТ давно уже превратились в самостоятельные дисциплины, с собственными специалистами: информационная безопасность, производительность, юзабилити.

Многие группы НФТ давно уже превратились в самостоятельные дисциплины, с собственными специалистами: информационная безопасность, производительность, юзабилити.

Гриша, эти дисциплины изучают методы обеспечения этих аспектов качества, а не задания требования к ним.

Гриша, эти дисциплины изучают методы обеспечения этих аспектов качества, а не задания требования к ним.

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

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

И что из этого следует?

И что из этого следует?

Цитата:

Актуальность: готовых техник выявления НФТ очень мало, в среднем у аналитиков меньше практики с НФТ, чем с ФТ.

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

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

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

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

Зачем изучать основы, если можно дать примеры и правила формулирования этих требований?

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

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

Есть еще вариант - доучить аналитика в части usability (30-40 часов вполне, думаю, достаточно).

Зачем изучать основы, если можно дать примеры и правила формулирования этих требований?

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

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

Например, я выступаю на конференции и рассказываю о том, насколько важно удобство инструментов управления требованиями для разных участников разных процессов, а ко мне потом подходят и говорят: "ну так всё, о чём вы рассказывали, наша система умеет делать, в чём проблема?"

Может тебе тоже стоит начать с требований к пригодности? Ты, насколько я помню, тоже рассказывал про интерфейсные РЕШЕНИЯ, а не про требования к пригодности, которые они обеспечивают.

Может тебе тоже стоит начать с требований к пригодности? Ты, насколько я помню, тоже рассказывал про интерфейсные РЕШЕНИЯ, а не про требования к пригодности, которые они обеспечивают.

Наверное, стоит. Я, честно говоря, ещё даже не знаю, что такое требования к пригодности. Пригодность - это что-то из стандарта ISO9126? Если да, то как оно называется в оригинале?