Источник правды: как аналитик учит менеджера и разработчика работать вместе
Гости нового выпуска подкаста «Сушите вёсла» Вероника и Катя — бизнес-аналитики Redmadrobot. Они рассказали об особенностях своей профессии, различиях между видами аналитиков и назвали самый главный скилл, необходимый для достижения успеха.
Добавлю токсичности.
Послушал подкаст.
Они вообще не бизнес аналитики: 80 процентов скорее системные аналитики и только 20 бизнес. Не предпочитают UML, а-ля можно как угодно описывать требования, но для этого и придумали унифицированную спецификацию, чтоб всем было понятно. Конечно можно и текстом описать use case для разработчика, где будет основной правильный сценарий и альтернативные/ошибочные. Системный аналитик это НЕ только меж системное взаимодействие, а вообще про работу системы, например, что по нажатию на эту кнопку происходит вот это. Он как раз в основном общается с разработчиками, в том числе и дизайнерами.
Бизнес аналитики снимают именно текущее состояние и желаемые функции, а не только показатели. Все это желательно фиксировать в популярной нотации. Они больше аудиторы (as is) и консалтинг (to be). И я склоняюсь, что нужно иметь it background, чтоб не наобещать сделать то, что не реально или долго и дорого.
Про бабУк это не книга(book-бук), а аббревиатура также как и PMBOK, который уже пишут во все вакансии на PM - только сдать экзамен гораздо сложнее. На западе и в big 4 очень ценится BABOK именно для бизнес аналитиков. В РФ зачастую в IT нужны просто грамотные техписы, поэтому и такие зарплаты, но современные компании понимают, что системный аналитик сильно сокращает трудозатраты разработчиков. На западе популярен CusDev, поэтому и появился спрос на аналитиков. Действительно мало универсальных аналитиков, которые могут грамотно общаться и с заказчиком и с командой, вот тут как раз образование и background даёт перевес в одну сторону.
Системным аналитиком фрилансером быть сложно, а вот бизнес аналитиком можно оказывать аудит и консалтинг услуги без взаимодействия с командой.
А теперь ‘боль’ - трудно стать product owner без помощника, который будет выдавать результаты (писать скрипты, делать ux макеты) гипотез для анализа. В плане развития - системный аналитик может стать и тех. директором (CTO), а бизнес аналитик стать директором по развитию.
Итого нужно четко понимать кто ты: системный, продуктовый или все таки бизнес аналитик.
На самом деле у нас нет разделения на бизнес-аналитиков и системных аналитиков. У нас в компании мы используем UML (и знаем его), когда он действительно нужен.
Но как показывает практика, во многих кейсах описания требований избыточные схемы могут их только усложнить. Если функционал сложный, то, конечно, мы как аналитики описываем требования в схемах, в том числе используем UML. Тут, главное, без фанатизма, потому что иногда использование нотаций к любым требованиям может их усложнить.
Поэтому хороший аналитик должен понимать, когда стоит использовать нотации, а когда нет. BABOK — это свод знаний, найти можно в виде книги, пересобирается каждый год. Действительно, нужно четко понимать, в какой области ты больше хочешь развиваться, но при этом стараться быть подкованным в любой из областей аналитики, чтобы делать качественный продукт.