Who wants to be an analyst, или как я стал аналитиком
Меня зовут Степан, в сфере IT я уже больше 7 лет, но полноценным бизнес/системным аналитиком работаю где-то половину это времени. Хочу рассказать историю, как я попал в бизнес-анализ, с какими проблемами и приколами сталкивался и за что я люблю эту профессию.
Part 1. Первый опыт и шишки
Я пришел в сферу как практик, не проходя курсы и изучая все самостоятельно - набивая шишки и читая книжки :) Если вы прошли академическое обучение, потом сдали сертификацию и вообще все четко и по плану – это другой путь, со своими «приколами».
Начну с начала, как говорится, - с момента вхождения в профессию и первого (раза) опыта.
Лично у меня все началось с внедрения. Внедрение — это такая работа, когда тебе дают большой (и тупой) напильник, показывают кучу необработанного материала и картинку с “лошадью”. Задача - выпилить лошадь. При том, что заказчик на нее потом залезет и попытается проскакать километров эдак 10. Правда, быстро поймет, что лошадь лишь отдаленно напоминает изначальную задумку, вообще неживая и использовать ее максимально эффективно можно только как вешалку для одежды (прямо как стул в углу комнаты).
Естественно, пока ты молод и зелен, работаешь ты даже не с целой лошадью, а скорее с правым задним копытом или левым ухом, это как повезет. Бывает, что и другие части тела попадаются...
Можно легко догадаться, что лошадки у меня получались то без ноги, то без головы, то без хвоста. Иногда голема удавалось даже оживить - но творения были в лучших хоррор-традициях. Тем не менее, структуру лошади и ее возможности (в моем случае лошадь = ERP-система) я уже знал и даже мог подсказать незадачливому пользователю, что стоять сзади коня не стоит - можно и в лоб получить.
В общем, с бизнес-анализом первое время работа была связана мало и больше похожа на сисадмина/техподдержку/консультанта из магазина в одном флаконе. Но стоит отдать должное: она привила внимание к деталям и научила эмпатии. Без этих навыков сложно быть аналитиком – понять боль стейкхолдера, избежать missed requirements, да и досконально стори не написать.
Однажды я угробил 50000 записей в продакшн базе, которые, (Слава богу, науке и Украине) благодаря крутому коллеге и частичной дубликации данных в двух БД, потом были восстановлены. Помню этот жизненный урок и теперь сначала запускаю все запросы на стейджинг-окружении (а лучше локально или вообще в БД не лезу, по возможности).
В первый раз оптимизировал бизнес с помощью трех галочек согласования документа и нескольких правил. Раздал доступ разным пользователям и обеспечил невозможность нажать одну галочку, если уже нажали другую. Доволен был собой как слон. Пользователи правда все так же распечатывали этот документ и носили на подпись начальникам…
Было весело - мы много летали в командировки, много общались, и по истечении нескольких лет проектная команда ощущалась как семья. Я растил софт скилы, тестировал UI, делал запросы в БД (хехе), много общался с конечными пользователями и даже побывал в телефонной техподдержке. И однажды увидел у коллеги творение Вигерса “Разработка требований к программному обеспечению”. Предо мной открылся портал (в ад) в мир качественных требований и системного подхода к их описанию. До сих пор считаю ее отличным пособием по входу в бизнес-анализ. Но курсы, конечно, лучше :)
Параллельно с чтением Вигерса в свободное время на работе повлялось все больше активностей вроде “посмотреть, как работает начальник отдела, выслушать жалобы (и мат) - все записать и передать разработчикам”. В тот момент я не знал, как правильно назвать мои записки. Это теперь я уже в курсе, что такое single user requirements documented by natural language. Или bugreport (в зависимости от того, как громко матюгался пользователь, озвучивая замечание).
Первые техники сбора требований - интервьюирование и наблюдение - тоже были сразу опробованы на практике, а потом уже подкреплены теорией. Немного позже стало известно, что перед тем, как интервьюировать стейкхолдера, нужно подготовить агенду, набросать вопросы, а лучше прийти с прототипом. А в начале пути ты с максимально учтивым видом заглядываешь в кабинет и такой: “Как у Вас дела? Работает система?” и слушаешь час, как беднягу работа достала, и вообще начальник у него – ***** (цензура не позволяет написать это слово, т.к. многие начальники могут узнать себя). Но после таких разговоров я уходил с четкой мыслью “нужно облегчить ему жизнь” и продолжал читать полезные ресурсы, чтобы понимать, как именно это можно сделать.
Спустя несколько лет работы с ERP, несколько месяцев усиленной подготовки и немало потраченных нервов, я ушел в другую компанию и полноценный (ура!) бизнес-анализ, о чем расскажу далее.
Подытожить первую часть хочу вот чем:
В начале очень нужен ментор. Без него никак. Информации море, и стоит чуть копнуть - сразу тонешь. Круто, если у ментора все по полочкам и есть (хотя бы какой-то) план, которого вы придерживаетесь. Меня мой первый ментор научил быть дотошным, рисовать IDEF0 диаграммы (и немножко BPMN), и что конечному пользователю нужны максимально подробные инструкции.
Будет много косяков. Сначала - вообще тьма, потом меньше. К этому нужно быть готовым и стараться не воспринимать каждый, как последний (на этом месте работы). К сожалению или к счастью, ошибки - очень действенный механизм мотивации и адаптации, и мы на них нехило так учимся. Здесь под “мы” я имею в виду тех, кто хочет расти, а не просиживать штаны на работе.
По бизнес-анализу очень много информации и теории, в частности. Подходов к требованиям несколько, техник масса, моделей и нотаций тоже хватает. А если в первый год открыть BABOK, то можно и кукухой поехать. Основной совет - узнали что-то новое и сразу применяем, потому что забудется. На практике очень важно иметь общее понимание между командой разработки и заказчиком, а этого можно достигнуть, просто разговаривая с обеими сторонами. Да, занимает много времени, да, не всегда эффективно - зато работает. А используя богатый аналитический инструментарий, мы лишь повышаем качество и скорость своей работы, хотя цель остается прежней.
Part 2. Как развиваться (а главное, зачем)?
Вообще, к мысли, что пора уходить с первой работы, я пришел не сразу. Постоянная жизнь в движении и смена мест были явно по душе, командировки я любил. Но в какой-то момент пришло понимание (у меня часто бывает, что случайно заглянувшая в голову мысль закрепляется в ней надолго), что хочется получать иной опыт, применять английский язык и вообще попробовать уже нарисовать ту самую схемку Chemical tracking system из книги Вигерса, но уже для своего проекта.
В один момент я созрел и уволился. Уходил без оффера на руках, по сути «в никуда», на свой страх и риск.
Оказаться лицом к лицу с рынком было по ощущениям как встретить гопника в темном переулке. Вроде как 5 лет опыта, а релевантного почти нет. Вроде и знаком с типами требований в теории, но работал на практике только с пользовательскими и лишь дорабатывал спеку с функциональными. Вроде и проходил весь жизненный цикл проекта, но чем конкретно занимается аналитик на фазе Presale или Discovery - не так просто ответить. Плюс волнение, которого даже не море, а целый океан, потому что в жизни было «полтора» собеседования, да и то несколько лет назад. Вот и ситуация была как в анекдоте, где посетитель тренажерного зала встречает хулигана. «Могу сделать 5 по 15 приседаний», а вот увернуться от удара - вряд ли.
Курьезов было много. Однажды получил отказ от компании, потому что «не знает, кем хочет быть через 5 лет». Да я в тот момент не знал толком, кто я, не то чтобы понимать, куда развиваться. Хотя тестовое задание по BPMN и знакомство с Camunda позже пригодились. Так что в целом отказали по делу, и за опыт им благодарен :)
Отказов было больше, чем я ожидал. Где-то не проходил из-за отсутствия опыта работы с англоязычным заказчиком, где-то не подходил по имеющимся на тот момент скилам. Однажды повезло попасть на вид собеседования «мясорубка» в одной крупной компании. Это когда тебя 1.5 часа мучают техническими и не очень вопросами, составляя полный профиль твоих знаний, чтобы знать, к какому заказчику можно тебя пристроить. Вышел я оттуда потный, вымотанный и с полной уверенностью, что я проживаю на дне океана и друга моего зовут Патрик. Но позднее по запросу мне дали развернутую обратную связь, да и сам я помечал вопросы, на которые не смог ответить во время собеседования. Этот момент считаю переломным в карьере, поскольку я впервые узнал, насколько широка сфера знаний аналитика и сколько еще предстоит изучить. Кстати, на Хабре есть статья «250 вопросов системному аналитику» - ее очень советую, т.к. многие из них на том собеседовании как раз и спрашивали.
Каково же было мое удивление, когда мне предложили сотрудничать. Пока меня продавали заказчикам, я пообщался с PM и запросил список литературы от уже опытных аналитиков, чтобы понимать, что нужно еще изучить. Прошел несколько внутренних собеседований, понял, что спрашивают и как лучше отвечать. В итоге, правда, попал в совершенно другую компанию, так как не везло - то один заказчик откажется от расширения проектной команды, то другой задаст нестандартный вопрос, от которого я растеряюсь :)
Ещё пара недель прошла в собеседованиях. У меня был план, и я его придерживался: выводы делать после каждого собеседования, записывать вопросы и сохранять тестовые задания для последующего разбора. Чувствовал, что с каждым новым собеседованием становится легче, да и отвечал увереннее. В итоге получил 2 оффера, один из которых принял.
Недавно наткнулся на статью об эффекте Даннинга-Крюгера (картинка выше). Как же это жизненно! На собственной шкуре знаю, что работает все именно так. Хочется верить, что долину отчаяния уже преодолел и иду вверх, потому что момент, когда был получен долгожданный оффер, очень сильно напоминал Пик Глупости с последующим осознанием, какое «поле непаханое» впереди и отчаянием. Оглядываясь на свой путь и видя, сколько ещё предстоит пройти, думаю, что наша сфера не то чтобы бесконечна, но точно расширяется по законам Вселенной :) Если в какой-то момент ты считаешь, что уже все знаешь, вероятнее всего, ты ошибаешься. Но в том и прелесть для человека, открытого к изучению нового.
Напоследок метафора, чтобы лошади из первой части не было скучно. Думаю, что многие сталкивались с вызовом на дом электрика. Как правило, хороший мастер приходит на вызов с ящиком инструментов и самыми часто используемыми мелочами (либо позвонит и спросит, в чем проблема, а потом закупит что нужно заранее). Так и в бизнес-анализе, чем больше опыта у нас, тем больше всего мы с собой приносим на проект и можем использовать для помощи заказчику (и не носимся в панике, потому что на изучение запроса клиента - неделя, а то и меньше).
Стоит развиваться, чтобы быть полезным в любой ситуации, вне зависимости от домена, масштаба и этапа жизненного цикла проекта. Пока опыта нет - с собой у нас только смекалка и умение быстро обучаться, но у этих навыков есть ощутимый предел.
И немного советов в завершение:
Опыт собеседований и опыт работы — это кардинально разные навыки. Каждому, кто в начале пути, советую соглашаться на собеседования и после каждого из них проводить работу над ошибками. Помечать вопросы, искать ответы, просить фидбэк.
Не унывать, если собеседование прошло плохо. «Заваленное» интервью становится козырем в рукаве, как только будет «загуглен» первый вопрос из вызвавших затруднение и найден на него ответ.
Немного иррационального - реально «ваша» компания наймёт вас непременно. Когда ты одинок, чтобы найти пару, нужно ходить на свидания (в данном случае, на собеседования)
Техничный, но неопытный аналитик (на мой взгляд) намного эффективнее в работе, чем опытный, но работающий «как попало» и «как привык»
Хорошая практика - собирать всю полезную инфу в облаке и структурировать ее (например, в notion). Notion вообще отличный инструмент, но сам о нем не знал, пока не увидел у Оли Рапопорт :)