Привет читателям!
Собственно, сабж (то бишь, а есть ли разница между руководителями проектов и бизнес-аналитиками и в чем она)? Сразу оговорюсь, что рассматривать роли мы будем в контексте «классической» структуры команд по разработке ПО, фокусируясь, в основном, на разработке ПО под заказ (в продуктовых командах «все сложно», «все depends» и я не берусь с уверенностью судить об их специфике). Также обратите внимание на слово «роли» – в вашей компании и команде их (бизнес-аналитика и руководителя проектов) могут называть хоть «розовыми слониками» – суть задач и зон ответственностей от этого не поменяется. P.S. В статье иногда будут встречаться ссылки на коротенькие и не очень околотематические видеоролики – смело жмякайте, если не боитесь английского языка.
Чем вызвана статья?
- Участившимися мудрыми дискуссиями на данную тему в попытках обнаружить те самые сокровенные отличия между этими «туманными» ролями. Особенно доставляют выводы рода «как мы только что с вами увидели, все сложно, отличия эти субъективны и зависят от контекста». Ну да… в какой-то мере в жизни все зависит от контекста. В «умелых» руках и микроскоп может быть молотком – не факт только, что гвоздь полностью войдет и микроскоп целым останется.
- «Веселыми» кандидатами, идущими собеседоваться «на ПМ или БА мне все равно я все умею».
- Не менее веселыми ресурсными управленцами, затыкающими горящие проектные позиции «универсальными ПМБА», желательно на полставки.
Давайте разберемся… точнее, сформулируем весьма очевидные вещи. Возьмем, например, сервис по техобслуживанию автомобилей. В фирме X работает команда профессионалов и там есть четкое разделение ролей – короче, не дядя Федя “мультитул” из гаража. Помимо, собственно, ремонтников (читай, разработчиков) и иных специалистов, участвующих на тех или иных этапах процесса, может также присутствовать консультант (некое лицо в диапазоне от «симпатичная улыбающаяся девушка, умеющая, максимум, зафиксировать на бумаге, с чем вы, собственно, пожаловали» до «эксперт конкретно в вашей модели автомобиля»), который вас выслушает, поймет вашу боль, предложит решение (либо же тщательно запишет ваши инструкции) и уйдет к ремонтникам объяснять им, куда копать. Если у этих ребят возникнут вопросы по ходу дела или появятся неожиданные проблемы, консультант вам перезвонит и согласует ход действий. Это бизнес-аналитик. Зачастую есть еще и дядька с хлыстом и бутылкой, который следит за тем, что у ремонтников есть инструменты, оборудование, мотивация; что они таки работают и работают в срок, трезвые и весь рабочий день и т.п. Он же, вероятно, повлиял и на то, что консультант вам позвонил и позвонил вовремя. Это есть управленец (менеджер проекта).
Что говорят стандарты (возьмем, например, PMBOK и BABOK):
Бизнес-аналитик – специалист, использующий методы бизнес-анализа для анализа потребностей деятельности организаций с целью определения проблем бизнеса и предложения их решения.
Перевод: человек, который поймет, что у вас не так и чего вы хотите. А еще может сам объяснить, чего вы хотите, если вы еще не дошли до этого сами. Этот же человек потом объяснит конкретным людям, которые будут делать вам хорошо, как сделать это самое хорошо (http://vdownload.eu/watch/4953016-office-space-quot-people-skills-quot.html).
Менеджер проекта – специалист, использующий методы проектного управления для обеспечения соответствия проектной деятельности проектным требованиям. Тут уместным будет привести определение проекта: проект – это уникальный набор скоординированных действий, имеющий начальную и конечную точки и направленный на получение определенного конечного результата в рамках ограничений времени, цены, качества и объема работ.
Перевод: человек, творящий магию для того, чтобы проектные работы выполнялись, при этом еще и в рамках оговоренного времени, цены, качества и были направлены на то, что действительно нужно сделать, чтобы вам было хорошо (https://www.youtube.com/watch?v=GjJCdCXFslY).
Зоны ответственностей и фокуса aka knowledge areas (по тем же самым PMBOK и BABOK):
Бизнес-аналитик:
- Business Analysis Planning and Monitoring (запланировать свою будущую работу в рамках проекта и постоянно следить за тем, что она делается эффективно).
- Enterprise Analysis (изучить вас, понять ваши проблемы и их потенциальные решения).
- Requirements Elicitation (понять в деталях, что вы хотели бы получить в рамках выбранного решения) (https://www.youtube.com/watch?v=evH3bzkKj4c).
- Requirements Analysis (осмыслить на досуге полученную от вас информацию).
- Requirements Management and Communication (записать четко сформулированную суть решения, донести до вас и исполнителей и не дать вам впихнуть в оговоренные деньги / сроки «еще одну мелочь»).
- Solution Assessment and Validation (выбрать наилучшее решение на этапе их сравнения, прикинуть, подойдет ли оно в вашей ситуации, и впоследствии изучить и оценить, насколько оно вам помогает).
Менеджер проекта:
- Project Integration Management (общее планирование и управление ходом проекта) (https://www.youtube.com/watch?v=Sm1VAeCo-Eg).
- Project Scope Management (следить за тем, что по вашему решению ведутся верные и только нужные работы).
- Project Time Management (следить за тем, чтобы все укладывалось в срок).
- Project Cost Management (следить за рамками выделенного бюджета).
- Project Quality Management (следить за качеством работ и обеспечивать надлежащий уровень качества решения).
- Project Human Resource Management (набрать народ в команду, обучить, внимательно следить за каждым в отдельности – в общем, все, что связано с ключевым проектным ресурсом – людьми).
- Project Communications Management (определить, кто и с кем общается на проекте, правильно ли общаются, нужная ли информация и своевременно ли распространяется – все, что связано с обменом проектной информацией).
- Project Risk Management (усердно думать о том, что может «внезапно» пойти не так, и как с этим бороться).
- Project Procurement Management (обеспечение команды всем необходимым извне – столы, стулья, печеньки, компьютеры и т.п.).
- Project Stakeholders Management (понять, кто вообще имеет отношение к проекту с какой-бы то ни было стороны, как они могут «нагадить» (а на самом деле, любое влияние их и на них) и тщательно ими управлять, чтобы проект шел, как задумывалось).
Как видите, «практически идентичные» обязанности… Так где же потенциально пересекающиеся области этих ребят? Вот в этих местах все с виду может быть не так четко, как хотелось бы:
- Scope management. Это страшное слово «scope» фигурирует в детальном описании обязанностей и одного, и другого. Фишка в том, что у БА – это solution scope (границы решения, или «а че ты мне суешь эту функцию в скоуп системы – это, скорее всего, потребует пересмотра проектных параметров – я уточню у ПМ»), а у PM – project scope (границы проектных работ, или «привет, БА, сейчас я прикину с командой как вырастет цена/сроки, какие возникнут риски, как изменится набор и последовательность работ и т.п., если мы скоуп решения увеличим, как клиент хочет»).
- Communication plan. Оба, так или иначе, имеют отношение к продумыванию плана коммуникаций с заинтересованными лицами. Круг заинтересованных лиц в зонах ответственности обеих ролей весьма схож (хоть и есть различия), поэтому этой задачей они должны заниматься совместно.
Иии… больше-то ничего и не нахожу – все остальное так же далеко друг от друга, как, например, написание спецификации и написание исходного кода. Так почему же их пытаются приравнять, взаимозаменить и всячески скомбинировать? Могу лишь предположить следующее:
1) Если условно разделить всю команду на тех, кто умеет / готов общаться в принципе и тех, кто нет, то ПМ с БА вместе займут всю первую категорию. Ну а что кроме общения еще этим ребятам надо?
2) БА как ключевой носитель знаний о решении активно участвует в постановке задач, причем может это делать самостоятельно, несмотря на то, что по своей сути – это работа ПМа.
3) Они оба находятся «подальше» от решения и чуть ближе к заказчику, чем иные роли.
Давайте теперь прикинем ключевые soft skills, необходимые этим ролям. Я специально не фокусируюсь на профессиональных знаниях и навыках (например, для БА это могут быть тех-писательство, визуальное моделирование, прототипирование пользовательских интерфейсов, знание техник и процессов работы с требованиями и т.п.), т.к. они, как следует из областей знаний выше – кардинально разные.
Общие требования:
- Коммуникативность.
- Обучаемость, способность эффективно управлять своим временем / рабочим окружением, стрессоустойчивость и прочие вещи, одинаково важные для всех проектных ролей.
Специфические требования (несомненно, все, что ниже, желательно иметь обеим ролям, но с таким же успехом их желательно иметь и разработчикам, тестировщикам и всем иным участникам проекта):
Бизнес-аналитик:
- Аналитическое мышление (https://www.youtube.com/watch?v=k0xgjUhEG3U).
- Системное мышление, включая умения как вдаваться в детали, так и абстрагироваться на более высокие уровни.
- Техническая грамотность, достаточная для постановки задачи и уразумения «а что же мы вообще тут делаем».
- В некоторых случаях – доменная экспертиза.
Менеджер проекта:
- Навыки решения проблем.
- Навыки управления людьми, организаторские способности, лидерство, влияние (https://www.youtube.com/watch?v=BKorP55Aqvg).
- Широкий кругозор по отношению к разработке ПО и базовые знания сути работ каждой отдельно взятой роли.
Судя по навыкам, это опять же несомненно «взаимозаменяемые» люди.
В качестве выводов, хотелось бы сформулировать следующие советы / призывы:
- Уважаемые будущие специалисты:
Изучите проектную деятельность и зоны ответственности обеих ролей. Определитесь, что вам интересно и что вы умеете («понимать, что нужно клиенту, представлять это в четко оформленном виде и доносить до команды разработки» или «управлять всей командой проекта, следить за бюджетами, сроками и набором работ и нести ответственность за общий результат команды»). Вы практически однозначно не будете подходить под обе роли сразу. Вам также не будут одинаково интересны и комфортны зоны ответственностей и работ обеих ролей сразу.
- Уважаемые ресурсные менеджеры и лица, формирующие проектные команды:
Крайне аккуратно сочетайте обе роли в одном человеке – гарантированно одна из областей будет «страдать». Это разные люди с разными знаниями, образом мышления и даже чертами характера. Почему тогда значительно реже встречается сочетание аналитик-разработчик, аналитик-тестировщик или аналитик-секретарь отдела? Любая литература по анализу требований и проектному управлению даст представление о том, к чему ведет недостаточно уделенное внимание одной или второй области проектных работ.
- Уважаемые читатели, как согласные, так и готовые подискутировать: я буду рад комментариям и мнениям по написанному выше. Несмотря на твердое убеждение в кардинальной разнице между этими областями, я верю, что в некоторых отдельных точках соприкосновения / различия тему можно оспорить и дополнить.
Спасибо за внимание!
Толковая статья, Герман. Понравилось!
Спасибо:)
«Project Stakeholders Management» и «Conduct Stakeholder Analysis» (BABOK v2.0, Chapter 2: Business Analysis Planning & Monitoring) имеют определенные сходства.
Денис, спасибо! Да, это еще одна пересекающаяся область. По памяти, если не ошибаюсь, тут опять же разница между project stakeholders и solution stakeholders. Вряд ли имеет смысл в типовом проекте их четко дифференцировать, но ресурс-менеджер, например — это проектный стейкхолдер, и его «анализировать» аналитику имхо не есть нужно. Я упомянул communication plan — по-хорошему да, надо подняться на уровень выше и пояснить, что вся область идентификации и анализа ЗЛ — это то, где ПМ/БА должны работать совместно.
Над определением project scope БА и ПМ, как правило, работают совместно. Так как ПМ является источником ограничений (время, деньги, человеческие ресурсы), а БА определяет, какой минимальный набор возможностей позволит удовлетворить бизнес-потребности. Т.е. проектный треугольник (время, деньги, качество) и project scope взаимозависимы. На мой взгляд первичен solution/project scope
Денис, ну вот я пытался таки различить project scope и solution scope. Project scope — это скоуп работ, и решения он касается только в части «какой набор работ (задач) необходимо выполнить, чтобы поставить клиенту solution scope». На мой взгляд, solution scope — это входной параметр для задачи ПМа define project scope.
Полностью разделяю изложенный подход. BABOK говорит:
The scope of the solution is usually narrower than the scope of the domain within which it is implemented, and will serve as the basis for the scope of a project to implement that solution or its components.
Процесс определения скоупа решения и скоупа проекта — итеративный. БА говорит, что нужно сделать. ПМ просит изменить скоуп решения, так как скоуп проекта не входит в существующие ограничения. Пока не найдем скоуп решения, устраивающий все заинтересованные стороны будет продолжатся совместная работа.
Замечательная статья! Очень четко все разложено по полочкам.
Еще хотелось бы узнать о том, как видятся роли БА и ПМ в «продуктовой» компании. Есть ли отличия от таких же ролей в аутсорсинговых компаниях?
Спасибо, статья действительно полезная интересная.
С основными тезисами статьи согласна)
Но для полноты картины и из чувства природного противоречия хотелось бы дополнить : )
Существует довольно большое количество проектов (обычно это недолгие небольшие веб или мобильные проекты по разработке ПО), когда иметь у сотрудника легкое раздвоение личности (БА+ПМ) полезнее для проекта, заказчика и команды, чем иметь двоих отдельных сотрудников на проекте (отдельно ПМ, отдельно БА).
Просто потому что overhead за счет дополнительной коммуникации, большего количества точек контакта для команды и заказчика, потери информации при взаимодействии получаются довольно большими во втором случае (по отношению к небольшому объему проекта).
А сложность с точки зрения анализа у таких проектов обычно невысокая, поэтому высококлассный аналитик и не требуется.
Я не говорю о том, что эти две роли схожи, я говорю о том, что в некоторых случаях один человек может выполнять их одновременно на проекте (ведя себя в одних ситуациях, преимущественно как ПМ, в иных — как БА).
Вот это, кстати, интересный вопрос: лучше ли такой подход, чем иметь 2-х людей на ограниченную загрузку, уделяющих каждый внимание конкретно своей области?
Опять же, на проектах минимального размера можно и аналитика-разработчика иметь — зачем объединять аналитика именно с ПМом? Отечественные аутсорсинговые аналитики, по большей части, занимаются аналитикой ближе к системной, так может они все-таки ближе по духу и скиллам к разработчикам? Я все же считаю, что круг обязанностей и фокуса у ПМа и аналитика принципиально разный.
Согласна с тем, что для получения максимальной отдачи (качества) это должны быть разные люди.
НО ситуации сильно разнообразные и зачастую компании не нужны для выполнения её задач высококвалифицированные спецы в этих областях. Достаточно одного человека, который может закрывать оба вопроса на «среднем» уровне, для получения максимальной «прибыли» от работы.
Почему объединяют именно так, а не по-другому? Думаю ответ лежит в «кадрах» и скилах текущей команды и их «занятости», ну и конечно «бюджета на кадры».
Например, команда 1 аналитик 2 разработчика 1 тестер. Аналитик загружен на 50% разработчики на 80-90%, тестер на 70-80%. Предполагаемая загрузка ПМ 30-40%. Логично при наличии способностей объединить аналитика и ПМ.
Если в команде нет разработчика, который может закрыть вопрос анализа, но есть ПМ, который это может сделать, то логично объединить ПМ и аналитика.
Для себя давно сделала вывод, что жизнь быстро изменяется и загруженность определенными работами, зависит от твоих способностей и текущих нужд /возможностей конторы/проекта. Практически во всех конторах есть люди, которые совмещают несколько профессий временно либо постоянно.
Моя статистика: чаще всего встречала ситуации объединения аналитика-разработчика, реже аналитика-ПМ, ещё реже аналитика-тестера.
Хорошая статья, только меня вот что удивило:
2) БА как ключевой носитель знаний о решении активно участвует в постановке задач, причем может это делать самостоятельно, несмотря на то, что по своей сути – это работа ПМа.
С каких пор постановка задач стала работой ПМ?
Юрий, спасибо. Имхо тут зависит от определения процесса «постановка задачи», вопроса «кому» и состава команды. Можете поделиться своими мыслями по этому поводу?
Спасибо за статью!
С трудом дочитал… Учиться, учиться, учиться и еще раз — учиться! И не писать статьи, пока не получишь необходимый объем знаний по предмету, а лучше — сертификат, подтверждающий правильное их усвоение.
Во-первых, зачем понадобилось искажать определения из PMI PMBoK? Еще древний философ Демокрит заметил, что человечество избавилось бы от доброй половины своих проблем, если бы просто научилось однозначно определять значения слов (терминов).
В PMBoK 5-й редакции:
«Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата».
«Руководитель проекта — лицо, назначенное исполняющей организацией руководить командой и отвечающее за достижение целей проекта».
Но, согласитесь, одни только эти (как, впрочем, и другие) определения не приблизят нас к пониманию сути. Я только намекну, что разница в функциях обсуждаемых ролей определяется кардинальной разницей между проектной и функциональной деятельностью, и как следствие, между проектным и функциональным (линейным) менеджментом (теоретические основы которого, как мы все знаем со школы, заложил основатель эконом. теории Адам Смит, введя понятие разделения труда).
PMBoK:
«Управление проектом — это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту.Управление проектом осуществляется посредством надлежащего применения и интеграции логически сгруппированных 47 процессов управления проектом, объединенных в 5 групп
процессов. Эти 5 групп процессов следующие:
•• инициация,
•• планирование,
•• исполнение,
•• мониторинг и контроль,
•• закрытие.»
«Описанные в Руководстве PMBOK® 47 процессов управления проектом разбиты на 10 отдельных областей знаний. Область знаний является всеобъемлющей системой понятий, терминов и действий, составляющих профессиональную область, область управления проектами или область деятельности. Эти 10 областей знаний практически постоянно используются в большинстве проектов. Команды проектов должны по мере необходимости использовать эти 10 областей знаний и другие области знаний для своего конкретного проекта. Области знаний включают в себя: управление интеграцией проекта, управление содержанием проекта, управление сроками проекта, управление стоимостью проекта, управление качеством проекта, управление человеческими ресурсами проекта, управление коммуникациями проекта, управление рисками проекта, управление закупками проекта и управление заинтересованными сторонами проекта. Каждой области знаний посвящен отдельный раздел Руководства PMBOK®.»
Т.е. строго говоря, теоретически, РП (или группа УП) может не знать процессов производства продукта (услуги или результата), применяемых технологий и методологий. Не царское это дело! У него есть 47 процессов, огромный арсенал инструментов и методов, определенных PMBoK, с помощью которых он на ежедневной основе, управляет проектом, уравновешивая конкурирующие ограничения проекта, которые включают в себя, среди прочего: содержание, качество, расписание, бюджет, ресурсы, риски.
Все остальные члены Команды проекта выполняют процессы создания продукта — не процессы управления проектом (которых 47). Естественно, РП может делегировать часть своих функций других членам группы УП. Точно также в небольших проектах РП может выполнять несколько ролей (совмещать), хотя в некоторых случаях это крайне нежелательно. Ну, например, в больших проектах вводятся роли архитекторов (от одного и более во главе с главным архитектором). Интересы РП и архитектора проекта по природе своей суть антагонистичны. Последний тяготеет к поиску наилучшего решения, не учитывая при этом «цену вопроса». РП приходится удерживать проект в рамках определенных ограничений (см. выше).
Исходя из этого, конечно, лучше, когда РП ориентируется в предметной области, в которой предпринимается проект, знает, например, методологию разработки/внедрения информационной системы. И рисков меньше, и самому РП комфортнее в 1000 раз.
Ну, а то, что у нас повсеместно РП фактически осуществляют не проектный, а типичный функциональный менеджмент — это мне известно. Кстати, в Китае в начале этого века был посчитан дефицит профессиональных проектных менеджеров в их народном хозяйстве — 20000 чел.. Тут же была разработана и реализована гос. программа. Результат — налицо. Кстати, план Маршалла по восстановлению послевоенной Европы предполагал обучение 25000 специалистов в США. Экономическое чудо без знаний — утопия.
Гдето так.
Владимир, спасибо за комментарий и за то, что поделились дополнительной информацией. Учиться таки нужно всем — одобряю порыв. Писать или не писать статьи — у нас с вами кардинально разные взгляды на этот счет. Благодарю, конечно, за рекомендацию, но следовать ей не имею никакого желания, и в следующий раз, когда увидите мое имя в авторах статьи, смело пропускайте, чтобы опять не потратить драгоценное время впустую. Также, на главной страничке есть волшебная ссылка «Опубликовать статью» — analyst.by будет очень рад статьям на тему проектного управления.
По теме: я честно ничего не понял из вашего комментария. 2 вопроса. 1) Где вопиющие расхождения с информацией, которую донес я? 2) Каковы (вкратце) ключевые тезисы в вашем комментарии?
Ок, всё супер.
А теперь вопрос: какая разница между Business Analyst и Product Manager?
На работе меня называют product manager. Иногда product owner. Почитал эту статью и теперь мне кажется что меня вполне можно называть BA. Посмотрел один доклад на YouTube — и теперь мне кажется что я проектировщик. ux специалист, ui специалист, проектировщик.. одному мне кажется что это все по большому счёту синонимы? в чем принципиальные отличия? Помогите..)
Станислав, я лично, к сожалению, вряд ли помогу, т.к. в продуктовой разработке (у вас же она, так?) хоть и участвовал, но в рамках процессов и методик типично аутсорсинговой компании. Надеюсь, кто-нибудь из разработки продуктов отзовётся.
Но если порассуждать, а в чем у вас конкретно проблема? Подозреваете, что на вас вешают лишние зоны ответственности? То, что я описал в статье — это не то, как люди обычно работают, а то, что стоило бы, с моей точки, зрения обдумать как дефолтную концепцию на подобного рода проектах. Если мы с вами сейчас придем к тому, что вы таки БА, а не manager / owner, то вряд ли на вас станут меньше работы вешать — и эту статью вы начальству в зубы вряд ли успешно всунете:). Единственное, что я бы однозначно рекомендовал — это четко выяснить свои зоны ответственности и какую работу от вас ждут. Далее уже можете прикинуть, сочетаете ли вы одновременно несколько ролей. И если вам некомфортно или вы видите риски, то можно попробовать подать идею специализацию, т.к. как в статье упомянуто, управленец и непосредственный специалист в одной из областей (требования, в данном случае) — это разные по своей сути работы, требующие входных (и дальнейшей же прокачки) различных навыков и знаний.
Да. У нас продуктовая разработка.
Мне интересен этот момент не с точки зрения моих обязанностей (это бред сказать начальству «я не буду этого делать, потому что моя должность в классическом её понимании не подразумевает подобных обязанностей»), а с точки зрения самоидентификации. Мне просто интересно как меня правильнее называть, учитывая список моих обязанностей.
Станислав, верно подмечено по поводу сходств. Product Manager (PdM) — это и BA, и UX, и много кто ещё. Лично мне очень нравится, когда PdM’а называют «CEO of the Product». Категорически рекомендую к прочтению вот эту книгу — «Inspired: How To Create Products Customers Love» (
http://www.amazon.com/Inspired-Create-Products-Customers-Love/dp/0981690408). Думаю, что для самоидентификации будет очень неплохо.
А вот отличия можно вместе поискать. И призвать для этого ещё других PdM’ов.. и даже статью по этому поводу можно написать. Что скажете?
Ох и сложно же найти эту книгу :(
В русском нет (похоже) её, на ау.бай, оз.бай и на озоне её тоже нет, амазон не хочет доставлять в Беларусь, а айтюнс традиционно не может её найти на беларуском сторе :\ Может подскажите где её найти?
По поводу «отличия вместе поискать и статью написать» — я только за :) Помогу чем смогу.
Я покупал на Киндл себе в цифровом виде с amazon’а.
А вот тут ещё в РФ утвердили проф-стандарт менеджера — http://profstandart.rosmintrud.ru/web/ps877166
Предлагаю ознакомится.
Эта книга уже переведена на русский язык.
Также рекомендую остальную литературу тут:
http://product.vision/books/
Поделитесь ссылкой, где можно скачать в свободном доступе: На крючке. Как создавать продукты хиты. на русском.
Перерыл половину интернета.
Разница существенная.
Бизнес-аналитик создаёт условия для развития предприятия.
Менеджер продукта отвечает за успех продукта на рынке.
Уважаемые коллеги, как я понимаю, главная цель представленных здесь статей, это поделиться своим собственным опытом, а не копирование цитат из «священных» книг, их по мере возможности, мы и так стараемся читать…
Чужой опыт может помогать, а может быть для нас абсолютно не приемлемым и, конечно, будет хорошо, если аргументированно и в рамках конкретного предмета дискуссии высказать свои сомнения. Значительно хуже давать личностные оценки типа: «учиться, учиться и не писать статьи, пока не получишь сертификат…«
Герман поднял вопрос о схожести, различиях и возможности совмещения ролей из-за того, что в IT-проектах это достаточно часто встречается, и постарался аргументировать свою точку зрения, исходя из собственного опыта. И, по моему мнению, самое правильное, поблагодарить его за это. Возможно, его формулировки не столь точны, как в PMBoK, ну и что? Он же не управлению проектами тут нас учит, а своим личным опытом и впечатлениями делится.
Да и «священные» книги PMBoK и BABOK, разве только они одни во всей отрасли »истинное» знание несут? До них никаких методологий и разработок не было и инженерная мысль на месте стояла? Или разработчики ПО, которые работали до эры всеобщей сертификации, введённой уважаемыми американскими институтами (IIBA был организован в 2003 г., думаю, что и PMI тоже примерно в это время) совсем «тёмными лохами» были? Или сертификационные экзамены и упомянутые книги не являются коммерческими продуктами (пусть и очень профессиональными!), т.е. заработком указанных институтов? И что всё это в дальнейшем не подлежит развитию, а следует принимать как религиозную догму, или правила дорожного движения?
Поэтому, ни в коей мере не сомневаясь и не умаляя знаний и эрудиции уважаемого Владимира, я ещё раз скажу СПАСИБО Герману за его статью! Давайте делиться опытом, давайте обсуждать и критиковать не переходя на личности.
Небольшое уточнение.
PMI был образован в 1969 г.
У меня есть подозрение, что IIBA воспользовался техникой бенчмаркинга и удачно использовал многие подходы PMI.
Так и было. Да, и они этого не скрывают.
Вставлю свои пять копеек. Если PM работает с тремя переменными (time, money, scope), то одна из переменных находится в фокусе BA (а именно, scope). Третью переменную будем понимать как объем работ, выполненных с соответствующим качеством, для решения задачи проекта. Именно BA, ответственнен за его наполнение, приоритезацию, дробления на удобоваримые части. Так или иначе, BA транслирует для PM важность тех или иных требований, а в ряде случаев и сроки поставки (например, если речь идет о продуктовой разработке). Соответсвенно, если мы постараемся максимально повысить эффективность компании (отстрелив «лишних» людей) — то можем прийти к выводу: бизнес-аналитик нам отдельно не нужен, нам нужен PM, который будет наделен его ролью. Недавно PMI выпустил книгу «Business analysis for practitioners: a practice guide», которая показывает пересечение ролей на тех или иных этапах работы на проекте. Кроме того, в PMI есть такой человек как Роберт Высоцкий, который долго и упорно развивает тему гибридной роли (http://www.amazon.com/The-Business-Analyst-Project-Manager/dp/0470767448) + PMI обогатился сертификацией по бизнес-анализу. Основная суть изысканий в том, что скрестив две роли можно теоретически получить супермена, который: а) Понимает нужды заказчика и пользователя б) Как аналитик обдумывает проблему с точки зрения реализации проекта в) Такого специалиста можно использовать более эффективно, для него найдется больше работы. С другой стороны, в голове возникает ряд проблем, которые могут возникнуть: а) Если есть много активностей по requirements management — роль PM может выполняться неэффективно. Роли могут начать конфликтовать, когда добрая половина (BA) будет убеждена, что требование/изменение нужно добавить в проект, а темная половина (PM) будет делать все, чтобы job is done был в срок и без лишних затрат. б) На больших проектах есть риск того, что обе роли не смогут быть выполнены эффективно в виду большого количества активностей. Поэтому такая модель больше подходит для небольших проектов. Можно ещё поразмышлять о том, как будут обстоять дела в Scrum, если сделать Product owner/Scrum muster, но лучше в виде отдельной статьи….
Как считаете, насколько оптимален карьерный путь BA -> PM?
Принимая во внимание, что, согласно комментариям, на практике фактически функционал БА часто входит в функционал ПМ, такой путь кажется не только оптимальным, но и естественным.
PM -> BA — это уже какой-то шаг назад :)
Спасибо за статью. Разделение мне кажется правильным и логичным.
Возникло 2 вопроса (я — как раз начинающий БА, в котором намешано функций и тестировщика, и внедренца, и мигратора):
1. «Техническая грамотность, достаточная для постановки задачи и уразумения «а что же мы вообще тут делаем».» — можно об этом поподробнее? Насколько глубоко БА должен знать техническую сторону вопроса во время процесса сбора требований? Если меня засунут в проект по разработке ПО для автомастерской (я утрирую), насколько глубоко я должен знать устройство автомобиля?
Просто мне кажется, что это настолько размытый критерий, что понять, соответствует ли уровень знаний на проекте, особенно заранее, слишком сложно;
2. Статья написана с посылом «здорово, если бы это было так». А все-таки, как оно на самом деле? Востребованы ли в РБ именно чистые БА, описанные в статье? Какие на практике чаще всего «смешения» ролей присутствуют? Я повторюсь — вопрос не теоретический и не про западные реалии, а про наши :)
Тимофей, эта статья уже пылью покрылась, но я попробую вспомнить контекст :)
Насчет технических знаний: критерий, несомненно, размытый, да и не однозначно необходимый — многие не согласны, что это обязаловка для БА. Потребуется это, скорее, при проектировании системы с позиции требований и при общении с командой разработки, а не во время сбора требований. Вы путаете знания домена с техническими знаниями. Если вас засунут в автоматизацию работы СТО, то знания домена на том или ином уровне (в зависимости от рода ваших задач) — это a must. Домен на другой стороне, т.е. на стороне команды разработки, с одной стороны постоянен (т.е. это IT), а с другой — естественно, варьируется в зависимости от применяемых технологий и подходов. Представьте, что вам нужно по факту извлеченных требований в СТО спроектировать с нуля мобильное приложение, допустим, для записи клиентов на диагностику. Нужно ли вам знать детали поведения Android/iOS приложений (адаптация под экраны и разрешения, система уведомлений и типовые сценарии их работы, UI-парадигма и т.п.)? Вообще, многое зависит от типа проекта и степени самостоятельности команды (и, как следствие, ваших обязанностей). Где-то ваши требования остановятся на уровне пользовательских историй (и вам тогда нет необходимости погружаться в технические детали), а где-то от вас будут явно хотеть изучить глубинно какой-нибудь API для интеграции с внешней системой, чтобы вы им предоставили полный data mapping и алгоритм взаимодействия с этой системой (т.е. уклон в бизнес- или в системный анализ — у нас далеко не всегда очерчивается разница между этими вещами). Вот в последнем случае, если вы будете недоуменно качать головой, видя термины XML или REST, то естественно это вам и команде существенно усложнит жизнь. В общем, как видите, ситуативно, но если хотите быть мегаприменимым оллстаром, то эти знания явно не будут лишними.
Понять заранее для кого-то, кто назначает БА на проект, насколько человек прокачан в том или ином стеке технологий для уровня работы с требованиями — естественно сложно. Поэтому делают это обычно «на глаз» или по вопросам «знаком с…? Был опыт работы с…?» Почитайте еще вот это, если раньше не видели (может, прояснит немного): http://itmine.by/system/front_courses/2/programs/ITMINE_BA_courses.pdf
Касательно посыла:
Чистые БА — имеется в виду без шаринга активностей ПМа? Или чисто БА, погруженные в бизнес, а не в IT-решения? Если первое, то да, конечно же есть. Если на проекте есть выделенный ПМ или он требуется в принципе, то и БА не подгружают управленческими активностями. Про смешения: БА+ПМ, БА+тестировщик, БА+ПМ+тестировщик, разработчик, который сам себе и БА, и тестировщик, и погонятель кнутом — такие чаще всего встречал.