Аналитик-первопроходец: проблемы и решения от Anna Abramova

Аналитик-первопроходец: проблемы и решения

 

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

 

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

 

 

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

Когда аналитика берут на проект, где уже почувствовали, что нужен аналитик, но еще точно не знают зачем, он часто сталкивается с таким положением:

1. уже идет разработка
2. нет ясно сформулированных целей проекта
3. нет четко поставленных аналитику задач
4. между разными заинтересованными лицами есть разногласия в ожиданиях от аналитика
5. у команды нет опыта работы с аналитиком или есть негативный опыт
6. нет достаточной документации для входа в проект
7. новая предметная область.

 Чтобы работать в этой ситуации, предлагаю разделить всю свою деятельность на 3 проекта:

1. стратегический проект: бизнес-анализ с самого начала;
2. тактический проект: системный анализ для поддержки текущей версии продукта;
3. стратегический проект: построение процесса управления требованиями.

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

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

Для построения процесса управления требований нужно в первую очередь:

1. четко определять текущие задачи;
2. согласовать ожидания от аналитика разных заинтересованных лиц в проекте;
3. определить набор и шаблоны необходимых документов;
4. перенаправлять потоки информации между заказчиком и командой разработки через себя;
5. начать строить модель предметной области.

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

 

• Regular Talk - Секционный доклад (40 min)