PM vs BA: из двух зол
«Бизнес-требования, функциональные требования, план аналитики на проекте… Так, что тут у нас есть знакомого?.. А, вот: диаграмма Ганта, управление рисками, постановка задач…»
Вот так, ну или почти так, я чувствовал себя, придя в аналитику из руководства проектами. Мешало это мне или, наоборот, помогало, я расскажу в этой статье.
Два в одном
Начать стоит с 2005 года: примерно тогда я пришел в управление проектами. Правда, проекты были довольно специализированными: тогда я работал в фирме, которая занималась разработкой на платформе 1С. Это была автоматизация бизнес-процессов малых и больших предприятий: от ИП, торгующего бакалеей, до крупного завода кондитерских изделий.
Да-да, та самая пресловутая шоколадно-кондитерская фабрика. Все было: и экскурсия по цехам, где производились вкуснейшие торты, и искренняя благодарность владельцев фабрики, чудесным образом материализовавшаяся в виде полного багажника машины тортов и пирожных… До сих пор вспоминаю те времена с некоторой ностальгией 😜.
Вот то, чем я тогда занимался.
Если быть точным, я руководил отделом разработки 1С. Мы — чем я до сих пор горжусь — смогли в довольно-таки небольшой срок перевести весь учет и производство на фабрике со старой 1С: Предприятие 7.5 на передовую тогда 1С: Предприятие 8.1. Это был отличный опыт и хороший заказчик.
Именно тогда я впервые начал работать с тем, о чем впоследствии прочитал как о процессе сбора и управления требованиями: мы с напарником проводили кучу интервью с владельцами фабрики, управляющими и работниками разного уровня, а вечерами сидели и разбирали свои записи, формируя из них свод стройной документации, описывая, чертя непростые схемы для разработки… Нужно сказать, что это был сложный по уровню, но безумно стимулирующий к развитию проект.
Я на этом проекте, который, к слову, длился почти полтора года (и это только активная разработка, без внедрения и отладки), впервые собрал все требования от и до, задокументировал, описал это в стройное (так мне тогда казалось) техническое задание и руководил его реализацией: составлял диаграмму Гантта, составлял и согласовывал скоуп работ на спринты, курировал всю разработку в отделе, обновлял и писал документацию. Тогда мне казалось, что руководитель проекта — это вот такой универсал, проводник между мирами бизнеса и разработки.
По сути, описать все то, что я тогда делал, можно простыми словами: руководитель проектов и бизнес-аналитик в одном лице.
Это был период, когда приходилось выстраивать процесс разработки и одновременно его документировать, а также управлять всем происходящим: от замены сотрудников на участках разработки до согласования новых фич и механизмов с заказчиком.
После того, как проект перешел из стадии сопровождения в стадию постпроектного обслуживания, я со спокойной душой передал бразды правления ведущему архитектору и по совместительству руководителю отдела 1С разработки. Сам же я переключился на проекты масштабом поменьше: их тоже было много, и они тоже требовали внимания.
Одно из двух
Спустя время я поменял сферу применения, перейдя в веб-студию, которая занималась разработками на 1С: Битрикс.
Уже привычно я взялся за работу: клиент приходил ко мне с бизнес-идеей, которую мы обсуждали, фиксировали, делали мокапы, рисовали схемы, согласовывали, документировали, разрабатывали, внедряли…
Это длилось довольно долго. И в какой-то момент я понял: если хочешь добиться конкретных, качественных результатов, нужно сфокусироваться на чем-то одном: ты либо хорошо работаешь с заказчиком на уровне аналитики, либо хорошо управляешь разработкой.
Выбор был сделан почти сразу: бизнес-аналитика — это именно то, чем я всегда занимался с большим удовольствием и самоотдачей.
Поняв это, я попытался изменить парадигму процесса разработки в отделе. Но выделение отдельной единицы бизнес-аналитика руководство не одобрило, и я решил пойти туда, где я буду востребован как аналитик.
Так я оказался в довольно крупной студии, которая занималась разработкой мобильных и веб-приложений. Были и крупные проекты, но в них я участвовал как руководитель проектов.
Аналитика, аналитика, аналитика… Я, с одобрения начальника пула руководителей проектов, переключился на аналитику практически в чистом виде. Управление командой разработки с меня никто не снимал, но проекты у меня были в первую очередь такие, которые требовали присутствия аналитика.
Это было время активного роста меня как аналитика: тот самый Вигерс, требования, управление требованиями и вся остальная работа аналитика на проекте.
Я — аналитик
Вот к чему я пришел сейчас. Теперь уже целенаправленно сфокусировавшись на аналитической деятельности, я изучаю теорию, применяю ее на практике на проектах, стараюсь активно расти как аналитик. Кажется, это у меня в общем неплохо получается.
Был ли легок переход из управления проектами в аналитику? Однозначного ответа у меня нет.
Безусловно, бэкграунд руководства проектами у меня накопился довольно богатый. Чаще это помогает: я вижу проект глазами руководителя проекта, понимаю свое место в проекте и выдаю тот результат, который ожидает от меня руководитель проекта как от аналитика.
Но были и сложные моменты: коллеги, думаю, до сих пор помнят дейли и митинги, которые я на автомате начинал вести и фасилитировать, спохватившись в процессе и уступая место законному руководителю проектов.
Были и другие попытки влезть в процесс управления. Руководитель проектов во мне не мог уйти на второй план просто так, без боя.
Полная ясность наступила тогда, когда в ходе общения с коллегами (как внутри пула, так и в проекте) мы проговорили функции бизнес-аналитика и руководителя проекта: пазл сложился, и с тех пор я не врывался в не свой монастырь, бодро размахивая уставом проекта.
Если попробовать резюмировать разницу между этими двумя ролями, можно прийти к примерно следующему перечню:
Участки работы руководителя проекта и бизнес-аналитика не противоречат и не взаимоисключают друг друга, но все же есть особенности ключевой роли на каждом участке.
Трудности перехода
Можно ли превратиться из аналитика в руководителя проектов? Да запросто! Стань незаменимым специалистом проекта, бери на себя все больше функций управления, и рано или поздно ты станешь руководителем на проекте. Прокачай — уже целенаправленно, попутно это не получится — скиллы PM, попробуй себя в управлении, и можешь пробовать стажироваться уже как руководитель проекта.
Только имей в виду: разные цели предполагают разную деятельность, и понравится ли это тебе — вопрос сложный. Решать его стоит самому, не полагаясь на чье-то мнение.
Каково же мне все-таки было переходить из руководства проектами в аналитику? Непросто. Это потребовало погружения в совсем другую теорию: нужно знать, понимать и уметь применять совсем другие механизмы, и не надейся, что все получится с первого раза.
Что мною двигало? Желание сфокусироваться на аналитике и подготовке базы для проекта вместо собственно руководства проектом.
Что помогало? Помогали знания о целях бизнес-аналитика и руководителя проектов. Нужно просто следовать им, каждый момент осознавая, что сейчас ты работаешь как аналитик, а не как руководитель этого проекта. Но толковый руководитель проекта всегда найдет способ и время поговорить с тобой и навести порядок в твоих мыслях и действиях, синхронизируя их с общим ходом проекта.
Стажировка — вот, пожалуй, самый комфортный и безболезненный способ понять, живет ли внутри тебя аналитик и готов ли ты выпустить его на волю.
Насколько этот путь — из руководителя проекта в бизнес-аналитика — логичен? Очень хороший вопрос. Ответ на него у каждого свой, и зависит он, как мне кажется, от того, какие функции и роли в проекте тебе комфортнее выполнять. Если тебе ближе аналитика — рано или поздно ты задумаешься о переходе в аналитику. Бывает и наоборот — аналитик понимает, что ему ближе управление проектом в целом, чем фокус на одном конкретном участке, и это тоже логичный путь личного и профессионального роста.
А что, если?..
Пытливый читатель непременно спросит: Денис, а можно ли совместить в одном лице — своём — и руководителя проектов, и бизнес-аналитика? Мой ответ — да, можно. Но есть пара важных оговорок:
- трезво оцени объем работ: а будешь ли ты успевать совмещать эти две непростые роли в одном проекте?
- проект должен быть относительно небольшой как по объему работ, так и по срокам. Иначе велик риск того, что ты просто выдохнешься на полпути и завалишь оба направления.
Есть у такого решения и риски. Это и отношение заказчика (не все понимают такое функциональное совмещение на проекте, и чем грамотнее заказчик, тем неохотнее он идет на такое совмещение), и отношение работодателя (а ты точно не выгоришь, как спичка, не дотянув до законного отпуска?) И самое, на мой взгляд, главное — это отсутствие внутренних ресурсов для роста: поверь, ты будешь настолько загружен проектом, что тебе будет не до развития себя как специалиста. И это ужасно.
В любом случае это та дилемма, которая встанет перед тобой в момент, когда ты решишь стать эдаким универсальным солдатом, PM и бизнес-аналитиком, два в одном: полноценный PM и качественный бизнес-аналитик, или неизбежный компромисс между ними?
Как будет решена эта дилемма, выбор за тобой. Но практика показывает, что безопаснее для проекта и всех его участников разделять эти две роли.
Руководитель проекта, бизнес-аналитик… Такие близкие по духу, но настолько разные по функциям роли! И это — еще один пример того, как важны решения, которые ты принимаешь.