analyst.by

Белорусское сообщество бизнес и системных аналитиков

Декабрьская встреча аналитиков. Ретроспектива

Оценить работу сапожника легко: результаты труда можно пощупать, примерить, результативность труда также вполне очевидна, как и эффективность. А теперь скажите: легко ли измерить аналитика? Насколько “осязаемы” результаты его труда? Существуют ли способы, приемы и метрики для этого? Именно эту тему мы и постарались рассмотреть на очередной встрече сообщества analyst.by.

Стоит отметить, что с самого начала доклада Дениса Сыропущинского (“Аналитик: В ширину, высоту и глубину”) дискуссия набрала оборот и не прекращалась вплоть до самого конца встречи. Собственно, и в перерыве между докладом и круглым столом никто не скучал, т.к. тема была затронута весьма актуальная и непростая. Многим опытным аналитикам уже приходилось руководить одним или несколькими менее опытными. И в такой ситуации весьма полезно иметь под рукой удобный инструмент (или набор инструментов) для быстрой и адекватной оценки аналитической работы. Да и самому себя “померять” зачастую весьма полезно. Мы ведь все хотим расти и развиваться в нашей профессии, а для этого нужно иметь возможность сравнить наши способности на разных отрезках времени.

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

Круглый стол был посвящен активностям аналитиков на начальной стадии проекта. Мы постарались выделить те действия и задачи, которые помогут аналитику “стартовать”. На встречу пришли и начинающие аналитики, а также и те, кто хотел бы ими стать, поэтому обсуждение велось в максимально доступной для них форме. Конечно, опытные ВА в порыве креатива иногда забывали, что термины “RFP”, “stakeholder”, “BRD” и т.д. могут быть знакомы не всем, но, по мере возможностей, модератор и другие участники обсуждения старались такие термины прояснять. Хотя, как оказалось в конце встречи, не все решались уточнять неясные моменты в ходе обсуждения. Как только это выяснилось, родился и “совет” на этот счет: не бойтесь прийти на встречу и показаться незнающим чего-то. Во-первых, лучше тут, чем перед заказчиком. Ну и, во-вторых, встречи сообщества всегда проводятся в дружественной и непринужденной атмосфере, поэтому стесняться на них никого не надо.

В ходе обсуждения были выделены вопросы, которые аналитик задает себе (или, во всяком случае, должен задавать) в самом начале:

1. С чего начинать и какими должны быть первые действия аналитика?

2. Откуда и какую информацию брать?

3. Какая информация нужна?

4. Какой подход стоит выбрать?

5. Как организовать процесс анализа?

6. Как идентифицировать всех заинтересованных лиц?

7. Как определить границы проекта?

8. Какие будут ожидания к проекту по качеству?

9. Какие могут возникнуть проблемы на протяжении всего проекта?

Мы начали с первого вопроса и попробовали продвинуться до последнего.

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

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

Первоначальную информацию о проекте и о том, с кем следует контактировать по проектным вопросам, как правило, можно узнать у проектного менеджера, sales-команды, или из таких документов, как: Request For Proposal (RFP), Request For Information (RFI), Request For Quote (RFQ), Business Requirements Document (BRD) при их наличии.

После получения исходной информации и контактов заказчика, аналитику необходимо проделать следующие действия:

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

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

○     определить зоны ответственности — для того, чтобы задавать правильные вопросы и получать на них правильные ответы, аналитик должен понимать имеет ли тот или иной человек полномочия отвечать на тот или иной вопрос. Зоны ответственности можно определить, задавая такие вопросы, как: “кто будет проводить приемку проекта?”; “кто ответственный за принятие решение по проектным требованиям”; “кто является ответственным за бюджет проекта?”; “кто будет использовать готовое решением в повседневной работе?” и т.д. Зоны ответственности необходимо зафиксировать в Stakeholder-матрице — это позволит определить источник(и) требований.

○     определить источники требований

- Определить выгоду (value), которую принесет успешное завершение проекта для каждого отдельно взятого заинтересованного лица на проекте.

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

- Изучить контекст:

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

○     составить список вопросов, которые появились после первоначального изучения контекста проекта

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

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

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

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

- Верифицировать решение с проектным менеджером и вашей командой — определить, может ли предложенное решение быть разработано известными методами и средствами и не выйдет ли предложенное решение за рамки проекта (бюджет, сроки и т.д.)

- Формализовать все данные и задокументировать их. Результатом документации может стать  Vision & Scope document, высокоуровневые Use Cases или User Stories, прототип решения, матрица функциональных возможностей (feature matrix), глоссарий.

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

- Обновить план аналитических и проектных активностей.

Конечно, это далеко не полный список активностей, и многое зависит от особенностей проекта. Но ведь никто и не говорил, что будет легко ;)

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

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

В целом встреча сообщества оказалось весьма живой и позитивной. С нетерпением ждем следующей.

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

 


15 Декабря, 2011


Добавить комментарий
Также Вы можете войти используя: Facebook Google