top of page

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, несколько месяцев усиленной подготовки и немало потраченных нервов, я ушел в другую компанию и полноценный (ура!) бизнес-анализ, о чем расскажу далее.


Подытожить первую часть хочу вот чем:

  1. В начале очень нужен ментор. Без него никак. Информации море, и стоит чуть копнуть - сразу тонешь. Круто, если у ментора все по полочкам и есть (хотя бы какой-то) план, которого вы придерживаетесь. Меня мой первый ментор научил быть дотошным, рисовать IDEF0 диаграммы (и немножко BPMN), и что конечному пользователю нужны максимально подробные инструкции.

  2. Будет много косяков. Сначала - вообще тьма, потом меньше. К этому нужно быть готовым и стараться не воспринимать каждый, как последний (на этом месте работы). К сожалению или к счастью, ошибки - очень действенный механизм мотивации и адаптации, и мы на них нехило так учимся. Здесь под “мы” я имею в виду тех, кто хочет расти, а не просиживать штаны на работе.

  3. По бизнес-анализу очень много информации и теории, в частности. Подходов к требованиям несколько, техник масса, моделей и нотаций тоже хватает. А если в первый год открыть BABOK, то можно и кукухой поехать. Основной совет - узнали что-то новое и сразу применяем, потому что забудется. На практике очень важно иметь общее понимание между командой разработки и заказчиком, а этого можно достигнуть, просто разговаривая с обеими сторонами. Да, занимает много времени, да, не всегда эффективно - зато работает. А используя богатый аналитический инструментарий, мы лишь повышаем качество и скорость своей работы, хотя цель остается прежней.


Part 2. Как развиваться (а главное, зачем)?


Вообще, к мысли, что пора уходить с первой работы, я пришел не сразу. Постоянная жизнь в движении и смена мест были явно по душе, командировки я любил. Но в какой-то момент пришло понимание (у меня часто бывает, что случайно заглянувшая в голову мысль закрепляется в ней надолго), что хочется получать иной опыт, применять английский язык и вообще попробовать уже нарисовать ту самую схемку Chemical tracking system из книги Вигерса, но уже для своего проекта.


В один момент я созрел и уволился. Уходил без оффера на руках, по сути «в никуда», на свой страх и риск.


Оказаться лицом к лицу с рынком было по ощущениям как встретить гопника в темном переулке. Вроде как 5 лет опыта, а релевантного почти нет. Вроде и знаком с типами требований в теории, но работал на практике только с пользовательскими и лишь дорабатывал спеку с функциональными. Вроде и проходил весь жизненный цикл проекта, но чем конкретно занимается аналитик на фазе Presale или Discovery - не так просто ответить. Плюс волнение, которого даже не море, а целый океан, потому что в жизни было «полтора» собеседования, да и то несколько лет назад. Вот и ситуация была как в анекдоте, где посетитель тренажерного зала встречает хулигана. «Могу сделать 5 по 15 приседаний», а вот увернуться от удара - вряд ли.

Курьезов было много. Однажды получил отказ от компании, потому что «не знает, кем хочет быть через 5 лет». Да я в тот момент не знал толком, кто я, не то чтобы понимать, куда развиваться. Хотя тестовое задание по BPMN и знакомство с Camunda позже пригодились. Так что в целом отказали по делу, и за опыт им благодарен :)


Отказов было больше, чем я ожидал. Где-то не проходил из-за отсутствия опыта работы с англоязычным заказчиком, где-то не подходил по имеющимся на тот момент скилам. Однажды повезло попасть на вид собеседования «мясорубка» в одной крупной компании. Это когда тебя 1.5 часа мучают техническими и не очень вопросами, составляя полный профиль твоих знаний, чтобы знать, к какому заказчику можно тебя пристроить. Вышел я оттуда потный, вымотанный и с полной уверенностью, что я проживаю на дне океана и друга моего зовут Патрик. Но позднее по запросу мне дали развернутую обратную связь, да и сам я помечал вопросы, на которые не смог ответить во время собеседования. Этот момент считаю переломным в карьере, поскольку я впервые узнал, насколько широка сфера знаний аналитика и сколько еще предстоит изучить. Кстати, на Хабре есть статья «250 вопросов системному аналитику» - ее очень советую, т.к. многие из них на том собеседовании как раз и спрашивали.


Каково же было мое удивление, когда мне предложили сотрудничать. Пока меня продавали заказчикам, я пообщался с PM и запросил список литературы от уже опытных аналитиков, чтобы понимать, что нужно еще изучить. Прошел несколько внутренних собеседований, понял, что спрашивают и как лучше отвечать. В итоге, правда, попал в совершенно другую компанию, так как не везло - то один заказчик откажется от расширения проектной команды, то другой задаст нестандартный вопрос, от которого я растеряюсь :)


Ещё пара недель прошла в собеседованиях. У меня был план, и я его придерживался: выводы делать после каждого собеседования, записывать вопросы и сохранять тестовые задания для последующего разбора. Чувствовал, что с каждым новым собеседованием становится легче, да и отвечал увереннее. В итоге получил 2 оффера, один из которых принял.

Недавно наткнулся на статью об эффекте Даннинга-Крюгера (картинка выше). Как же это жизненно! На собственной шкуре знаю, что работает все именно так. Хочется верить, что долину отчаяния уже преодолел и иду вверх, потому что момент, когда был получен долгожданный оффер, очень сильно напоминал Пик Глупости с последующим осознанием, какое «поле непаханое» впереди и отчаянием. Оглядываясь на свой путь и видя, сколько ещё предстоит пройти, думаю, что наша сфера не то чтобы бесконечна, но точно расширяется по законам Вселенной :) Если в какой-то момент ты считаешь, что уже все знаешь, вероятнее всего, ты ошибаешься. Но в том и прелесть для человека, открытого к изучению нового.


Напоследок метафора, чтобы лошади из первой части не было скучно. Думаю, что многие сталкивались с вызовом на дом электрика. Как правило, хороший мастер приходит на вызов с ящиком инструментов и самыми часто используемыми мелочами (либо позвонит и спросит, в чем проблема, а потом закупит что нужно заранее). Так и в бизнес-анализе, чем больше опыта у нас, тем больше всего мы с собой приносим на проект и можем использовать для помощи заказчику (и не носимся в панике, потому что на изучение запроса клиента - неделя, а то и меньше).


Стоит развиваться, чтобы быть полезным в любой ситуации, вне зависимости от домена, масштаба и этапа жизненного цикла проекта. Пока опыта нет - с собой у нас только смекалка и умение быстро обучаться, но у этих навыков есть ощутимый предел.


И немного советов в завершение:

  1. Опыт собеседований и опыт работы — это кардинально разные навыки. Каждому, кто в начале пути, советую соглашаться на собеседования и после каждого из них проводить работу над ошибками. Помечать вопросы, искать ответы, просить фидбэк.

  2. Не унывать, если собеседование прошло плохо. «Заваленное» интервью становится козырем в рукаве, как только будет «загуглен» первый вопрос из вызвавших затруднение и найден на него ответ.

  3. Немного иррационального - реально «ваша» компания наймёт вас непременно. Когда ты одинок, чтобы найти пару, нужно ходить на свидания (в данном случае, на собеседования)

  4. Техничный, но неопытный аналитик (на мой взгляд) намного эффективнее в работе, чем опытный, но работающий «как попало» и «как привык»

  5. Хорошая практика - собирать всю полезную инфу в облаке и структурировать ее (например, в notion). Notion вообще отличный инструмент, но сам о нем не знал, пока не увидел у Оли Рапопорт :)