Представьте, что Вы как бизнес-аналитик успешно завершили очередной проект; подумываете над тем, чтобы сменить бизнес-домен; хотите найти проект, где все будет максимально соответствовать вашим пожеланиям; и самое главное – Ваш ресурсный менеджер предлагает Вам новые проекты и назначает интервью с их менеджерами.
Вы оказываетесь в ситуации, когда у Вас есть альтернативы и все, что Вам остается – это сделать правильный выбор.
Кажется, что выбрать новый проект – проще простого. Но это не совсем так. Перед интервью на проект, о котором знаешь только название фирмы заказчика и направления деятельности компании, написанные на её сайте, сразу возникает масса вопросов и к интервьюерам, и к самому себе:
- К какому домену относится проект? И будет ли мне интересно работать в данной предметной области?
- Что будет представлять собой новый проект? И захочу ли я в нем участвовать?
- Это будет разработка с нуля, доработка коробочного решения или «проект-ремонт», который все никак не прекратится?
- Какая методология используется и, соответственно, как будут выстраиваться проектные процессы? И прочие.
И в итоге я решила систематизировать все возникшие вопросы. И если кто-нибудь из Вас окажется в такой же ситуации, когда есть из чего выбирать, но информации о проектах перед интервью практически нет, то можно воспользоваться получившемся перечнем вопросов.
Итак, приступим.
Вопросы к интервьюерам можно разделить на следующие группы:
1. Вопросы касательно Сути и цели проекта:
1.1. В каком домене предстоит работать?
Данный вопрос уместно задавать, если компания-заказчик занимается целым спектром активностей и до интервью Вы не знаете, в какой именно области понадобятся Ваши навыки.
1.2. Попросить охарактеризовать продукт, разработкой/доработкой которого предстоит заниматься, т.е. попросить провести позиционирование продукта. Для этого можно воспользоваться следующим списком вопросов:
a) Для каких групп пользователей разрабатывается/дорабатывается данный продукт?
Но с этим вопросом нужно быть осторожным, т.к. иногда сам домен однозначно определяет группы пользователей.
b) Это приложение – web/mobile/desktop или все в одном флаконе?
c) Каковы основные (конкурентные или просто отличительные) характеристики данного продукта?
1.3. Какова цель проекта – разработка с нуля, доработка коробочного решения, эволюция существующего продукта? Какие технологии будут использоваться?
2. Вопросы касательно Проектных компонентов (времени и ресурсов) и Проектной методологии:
2.1. На какое время планируется проект? На какое время предполагается участие аналитика в проекте?
Здесь речь идет не о точных сроках начала и конца проекта, а об оценках, полученных из presales документации (предложение на RFP).
Ответ на данный вопрос сразу сформирует у Вас представление о масштабах проекта, периоде Вашей будущей занятости. Т.е. сразу можно будет понять, насколько грандиозен проект :)
2.2. Проект уже стартовал, и туда требуется (дополнительный) аналитик, или проект только будет стартовать?
Думаю, что тут всем понятно, на что это влияет – вероятность вашего активного участия и большого вклада в выстраивании проектных процессов в первом случае не особо велика, но все всегда возможно ;)
2.3. Какой примерный объем ресурсов в целом планируется на проект? Какое количество бизнес-аналитиков планируется? Будет ли команда распределенной, или же все будут работать в одном месте?
Опять же – все эти сведения должны быть в presales документации и проектный менеджер может ввести Вас в курс дела.
2.4. Какой тип проекта по ценовой модели — fixed price или time and material?
Ведь от этого будет зависеть весь процесс планирования и осуществления BA активностей, начиная с выбора подхода к сбору требований, предоставления оценок трудозатрат на каждую BA активность в соответствие с проектным планом и заканчивая выбором подхода к управлению изменениями требований.
2.5. Какова проектная методология — RUP, Agile или некая «волшебная» оптимизированная заказчиком методология?
2.6. Насколько заказчик подготовлен и активен — в вопросах предоставления требований, их рассмотрения и официального подписания, в проведении митингов?
Данный вопрос актуален только, если проект уже идет и у команды есть опыт работы с заказчиком или же в вашей компании были другие проекты с этим заказчиком.
Как уже говорилось выше, ответы на большинство вопросов из данной группы можно почерпнуть из presales документации, но мало кто захочет показать весь документ AS-IS, пока человек не подпишется на проект, поэтому единственный способ узнать все интересующее – задать соответствующие вопросы.
3. Третья группа вопросов будет актуальна только в случае старта проекта с нуля. Здесь стоит остановиться на следующих вопросах:
3.1. Когда предполагается старт?
3.2. Будет ли командировка для изначального выяснения требований или нет? И насколько долгой она будет? Предполагаются ли командировки на протяжении проекта?
3.3. Если командировки планируются, то в каком составе будет представительство от Вашей компании – бизнес-аналитик, системный архитектор и т.д.?
3.4. Будет ли это работа onsite или offsite для бизнес-аналитика в дальнейшем?
Ответы на данные вопросы необходимо знать для того, чтобы правильно спланировать работу перед стартом и на старте проекта – понять, какие документы, презентации готовить, в какие сроки их нужно предоставить, выстроить процесс общения с заказчиком.
4. Ну и последняя группа вопросов к проектному менеджеру – касательно функций или роли бизнес-аналитика на данном конкретном проекте.
Поскольку на разных проектах и в разных доменах роль и функции бизнес-аналитика могут отличаться, то нужно и полезно сразу очертить для себя круг своих будущих основных активностей, особенно в областях, смежных с деятельностью проектного менеджера, координатора, представителя от команды разработчиков и команды тестирования. Для этого можно воспользоваться RACI матрицей (более подробно о ней можно почитать тут ).
Пример RACI матрицы с перечнем смежных и пересекающихся активностей представлен в таблице:
|
Активность |
Бизнес-аналитик |
Проектный менеджер |
Лидер команды разработчиков |
Лидер команды тестирования |
| Оценка трудозатрат на разработку требований |
C |
A |
R |
I |
| Назначение задач на разработку/тестирование требования |
I |
A |
R |
R |
| Планирование требований на релизы |
R |
A |
R |
I |
| Утверждение требований с заказчиком |
C, I, R |
A, R |
I |
I |
| Коммуникация с заказчиком и внутри команды: проведение всех типов совещаний |
R c указанием каких именно |
A, R c указанием каких именно |
R c указанием каких именно |
R с указанием каких именно |
| Продумывание стратегии тестирования |
С |
I |
C |
A, R |
| Координирование проектной команды |
R |
A |
R |
I |
У другого аналитика на другом проекте данная таблица может выглядеть иначе – могут добавиться другие смежные активности, RACI будут стоять в других квадратах, поэтому, на мой взгляд, важно сразу выяснить свои обязанности, чтобы в будущем не возникло ощущения обманутого ожидания.
Что касается вопросов к себе, то, на мой взгляд, здесь достаточно просто определиться со следующим:
- Какие предметные области мне интересны больше всего? В каких из них я бы лучше всего смог/смогла бы проявить себя?
- Какие проекты мне интересны – проекты с нуля или доработки коробочных решений; длительные или краткосрочные проекты?
- Какова моя цель для участия в новом проекте – опыт в новом домене/технологии/методологии, закрепление опыта в домене/ технологии/методологии,+1 проект в резюме или что-то другое?
- Поможет ли данный проект в достижении главной карьерной цели (-ей)?
- По какой методологии мне наиболее комфортно работать? Хотел/хотела бы попробовать работать по новой методологии?
- Готов/готова ли к командировкам/длительному пребыванию на стороне заказчика?
- Какие активности у меня получается выполнять лучше всего, какие хуже всего? Что из того, что я еще не делал/делала в качестве бизнес-аналитика, мне хочется попробовать?
- Другие критерии/пожелания/цели.
В итоге, получив ответы на вопросы по каждому проекту, где Вас интервьюировали, и, соотнеся это с Вашими собственными предпочтениями, желаниями, целями и амбициями, Вы сможете выбрать тот проект, который больше всего вам подходит, ну или тот, что наберет меньше всего «thumb downs» в вашем собственном списке желаний ;)
Автор: Виктория Отставная
Бизнес-аналитик
EPAM Systems
Виктория, спасибо! Крайне познавательно и полезно.
После прочтения сходу возникло несколько вопросов — буду признателен, если поделитесь мнением.
1. Цель проекта. Может добавить в список суппорт продакшн систем?
2. Проектные методологии. Список, конечно, может быть огромен, но интересно, почему сюда включены только 3 категории (RUP, Agile и кастомная методология). Кто-то и по водопадной модели работает:), что также предусматривает свои специфики для аналитика.
3. Вопросы по RACI (что, кстати, для меня лично — наиболее полезная часть статьи; большущий респект и уважение за табличку:)):
1) Оценка затрат на разработку требований. Тут разработка требований имеется в виду или разработка функционала по требованиям? Просто для первого варианта аналитик как consultant немного смущает.
2) Назначение задач на разработку/тестирование требований. В принципе, вопрос тот же. Если семантика именно в работе с требованиями, то опять же — разработчик как responsible person выглядит странно.
3) Планирование требований на релизы. Разработчик точно R, а не C?
4) Координирование проектной команды. Если сюда входят под-команды (аналитики, тестировщики и т.д.), то логичным было бы R, A R, R, R (хотя и это не совсем корректно, учитывая что ответственное лицо в идеале должно быть в единичном экземпляре). Если же это вся проектная команда, то R должно быть у менеджера. Или я чего-то недопонял?
Спасибо за отзыв и вопросы :)
Итак, отвечаю:
1. Да, можно включить. Единственное, что пока не встречала support проектов, где требовался аналитик (комнада тестирования обычно справлялась с support), но, возможно, что для очень больших систем это имеет смысл.
2. Включила наиболее часто встречаемые, т.к. верила и надеялась, что уже никто не использует waterfall :)
3.1. Имелась в виду именно разработка функционала по требованиям.
3.2. Речь именно о разработке и тестировании функционала
3.3. Да, R, как и аналитик=). Как показал опыт, это хорошая практика, когда в распределение требований по релизам сразу подключается разработчик с прдоставлением оценок и видением того, можно или нет с текущими ресурсами сделать определенный функционал. это помогает избежать многоэтапных корректировок планов.
Но как я писала, на разных проектах эта матрица может выглядеть иначе и роль Consulted также вполне подходит вместо R.
3.4. Имелась в виду вся команда. Да, менеджер может быть координатором, но в бОльшем числе случаев в моей практике и наблюдениях эту роль обычно выполнял или аналитик, или dev team leader. Особенно если менеджер работает onsite, а команда offsite или когда менеджер находитя в другой геолокации в отличие от команды. Да и в обычных проектных ситуациях. Но менеджер все равно мониторил ситуацию , т.е. был A.
Но опять же, у другого аналитика может получиться своя RACI матрица :)
Спасибо, Виктория!
Честно говоря, у меня есть собственный список (но я не аналитик ;)), там больше вопросов по процессам, ибо все всегда говорят, что у них Agile, а у многих просто бардак )
Добрый вечер.
Интересно было бы узнать ваш список вопросов по проектным процессам =)
http://www.speedyshare.com/QSQf5/Questions.docx
Моя идея — попробовать определить состояние проекта по таким параметрам, как график, бюджет, количество вакантных мест, качество, процессы тестирования, процессы бизнес-анализа.
Сегодня был на 8-м собеседовании за 2 недели. Проблемы и адекватность процессов (менеджеров) список определяет на ура.
a. Структура управления, роль и адекватность менеджера
i. Структура дев команды
ii. Ответственность за архитектурные решения
iii. Ответственность за staging и CI
iv. Ответственность за codereview
v. Ответственность за estimation & planning
vi. Ответственность за стейджинг
vii. Структура QA команды
viii. Команда автотестеров
b. CommunicationPlan (информационный поток от заказчика к разработчику, задержки)
c. ProjectPlan
i. Фазы, какая сейчас, после какой будет выход в продакшен
ii. Сроки выхода в продакшен, сроки завершения
d. Процессы
i. Процесс заказа – T&M, Fixed Priced, Internal Project, Agile Contract
ii. Процесс сбора требований
1. Заказчик, локация, язык, взаимодействие
2. Артефакты, WIKI
3. Процесс изменения требований
4. SCRUM – используются ли Userstories, кто является ProductOwner’ом, формат UserStories
5. Есть ли бизнес аналитики, квалификация бизнес-аналитиков
6. Фидбэк от заказчика, SCRUM демо
7. Готовность требований к текущей фазе, запас требований
8. BA или заказчик onsite
iii. Software Development Process
1. Багтрекер (если не стандартный, то критерии выбора багтрекера)
2. Обязанности разработчика (конфигурирование серверов, релиз процесс, код ревью, джуниоры)
3. Agile техники – refactoring, TDD, collective code ownership
4. Политика рефакторинга (on developer opinion, each story include special time on refactoring)
5. Процесс распределения тасков (назначение или выбор)
6. Процесс принятие архитектурных решений (TechLead)
7. Процесс тестирования (Test Case or Сheck List)
8. Регрессионное тестирование, цикличность проведения, на одном билде или на разных
9. Smoke test – автоматизация
10. Процесс релиза, как часто релизы
11. Спринт — ретроспективы
12. StaffingRatio, какие планы по набору людей?
13. Технические таски в скоупе, насколько много? Какого плана таски?
14. Простои производства, как часто, какие основные причины, алгоритм устранения
15. Velocity команды? Фокус-фактор?
16. Какие ишью были на последней ретроспективе?
17. Continuous integration, do restrictions hard or soft. Principles of CI configuration (modules or one common project, response time).
18. Planning & estimation
a. Time vs Complexity estimation? Which used? Do used splitting user story on technical tasks?
b. Who is responsible for estimation?
c. Team velocity? Computation algorithm? Definition of Done?
e. Качество
i. Тестирование usability, ответственный за юзабилити, наличие UXна проекте
ii. Примерное количество открытых багов
iii. Используется ли Sonar
iv. Размер проекта, количество деплоемых артефактов, количество строчек в каждом
v. Ведётся ли разработка unit и integration тестов, какое покрытие кода.
vi. Покрытие требований тест кейсами
Здорово! Спасибо большое. Т.к. аналитикам и девелоперам нужно работать вплотную, то знать организацию dev процесса тоже полезно, т.к. можно сделать выводы о том, где и как аналитики и разработчики буду пеерсекаться помимо предоставления эстимаций и планирования релизов
Скажите, пожалуйста, а вы копировали этот список из какого-то документа или статьи? Если статьи, то вы не могли бы дать ссылку на неё? Ну а если документа, то, может, вы хоть в общих чертах готовы описать это в статье?
Юрий, да, вы правы, это мой собственный документ. С удовольствием напишу статью, когда появится немного свободного времени.
Хотел поинтересоваться, как у вас со статьей дела?:) Список действительно очень всеобъемлющий и впечатляющий. Было бы просто супер увидеть пояснения и ваши комментарии к пунктам, если возможно (к чему относитесь с опаской, какие ответы дали бы повод четко сказать нет/да и т.п.).