Who wants to be an analyst, или как я стал аналитиком
- Stsiapan Sazanavets
- 3 июл. 2022 г.
- 13 мин. чтения
Обновлено: 17 окт. 2024 г.
Меня зовут Степан, в сфере 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 вообще отличный инструмент, но сам о нем не знал, пока не увидел у Оли Рапопорт :)
Профессиональные и близкие к ним книги не так скучны, как кажутся. Помню, как мне понравилась Цель Голдратта, не уступающая сюжетом и глубиной приключенческим романам.
Сфера IT подразумевает постоянное развитие. Технологии меняются и количество информации растет в прогрессии. Развиваются инструменты – и мы должны за всем этим успевать. Иначе останемся на бесконечном саппорте древнего ПО, а не на острие индустрии
Бонус! Книги, которые рекомендую изучить в начале пути (и ручаюсь за них, т.к. сам читал)
Андрей Дмитриевич Перерва "Путь аналитика"
Карл Вигерс "Разработка требований к программному обеспечению"
IREB Foundation level Handbook либо Requirements engineering Fundamentals
Software requirements memory jogger
Part 3. Мама, забери меня обратно
Компанию сменил, онбординг прошел, пора начинать работу.
В начале пути всегда страшно (спойлер, страшно всегда, просто меньше). Ментор вечно занят, заказчик давит, PM настаивает на том, что документы должны быть написаны вчера и согласованы позавчера, разработчики дергают каждые 10 минут, 5000 change requests поступило утром голубиной почтой... Список причин для стресса можно продолжать бесконечно, и у каждого из нас он свой, персональный.
Мой первый проект в роли бизнес-аналитика был сложен тем, что до него не было опыта взаимодействия с англоязычными заказчиками и ведения всей документации на английском. После ГОСТов 19/34 с их Пояснительными записками и Программами и методиками испытаний видеть нормальный Vision and scope, SRS или просто проработанную user story по ощущениям похоже на ситуацию, когда ты из отцовского Москвича сел в первую в своей жизни иномарку. Концепция аналогична - те же руль и колеса, но уровень кардинально другой, как и скорости. Приходилось постоянно заглядывать во вкладку браузера с переводчиком (кстати, личный лайфхак, Reverso часто даёт фразы в нужном контексте, что намного полезнее перевода «слов на слово») и пятьсот тысяч раз перечитывать то, что написал. На первое интервью с product owner я пришёл с двумя листами А4, исписанными мелкими почерком. Ожидаемо несколько раз не понял ответа, ограничившись фразой «Ok, I got you», хотя got я в тот момент только то, что нужно срочно поднимать уровень восприятия нейтив-спикеров. Раза 3 запутался в своих же записях и возвращался к пропущенным вопросам, ломая логичное развитие интервью. Но благо, с каждой новой неделей было все легче и легче, адаптация работала - задумывался я о ней или нет. Со страхом быть непонятым и из-за волнения не объяснить свою мысль боролся с помощью визуального контента. Да и вообще, очень помогало не приходить с пустыми руками на созвон - ты всегда демонстрируешь какое-то «домашнее задание» на экране. Это может быть агенда, mind map, схема, прототип или примеры реализации (например, помню, как показывал механизм выделения нескольких писем прямо из gmail). Даже с не самым крутым английским это помогало (и продолжает помогать) донести мысль и получить ценный фидбэк.
Второй «стресс» у меня был связан тем, что никогда до этого не писал подробные User stories, и в целом привык фиксировать требования обычным языком, созваниваясь позже с разработчиком, чтобы пояснить спорные моменты. Invest критерии, definition of ready и definition of done - это что-то на эльфийском, да? Тут на помощь приходили все ресурсы с примерами - от Хабра до институтов бизнес-анализа. В тот момент я ещё не слышал об IREB - их handbook очень просто и понятно разжевывает работу с требованиями, как с одиночными, так и со спецификациями и даёт наводки, куда углубиться. Привитое университетом «не знаешь - гугли» выручало. Хотя сейчас, вспоминая, где я тогда искал примеры, хочется отправить себя «прошлого» на полноценный курс или несколько воркшопов по теме. Тогда я почему-то был уверен, что в интернете полно бесплатной и релевантной информации. Ага (смайлик рукалицо), щас.
Третий страх - ранее невиданные технологии и "тулы". До этого было десктопное приложение и SQL, с чем после нескольких лет справляешься достаточно легко. А тут понеслось, 50 оттенков аутсорса. Разные БД, микросервисная архитектура с кучей API, веб и мобильные приложения, дизайны в Figma, прототипы в Axure, скетчи в Balsamiq…И во всем нужно суметь разобраться, потому что нужно держать материалы в актуальном и согласованном состоянии. Да и просто бывает нужно набросать screenflow, чтобы заказчику проиллюстрировать идеи на очередном созвоне. С моим любопытством разбираться в новом инструменте вроде Figm’ы всегда в удовольствие, лишь бы время было. Радует, что его хватало - сейчас понимаю, что в условиях жесткого дедлайна потратить полдня на обучение - невиданная роскошь.
Иногда закрадывается мысль: «Сотрите мне память, я хочу пережить это все снова». У первого опыта в профессии свой особенный шарм. Да, бывало стрессово. Да, постоянно сомневался в результатах собственной работы. Но мне повезло попасть в окружение, где не боишься задавать вопросы. А когда команда открыта к твоим постоянным «почемучкам», а более опытные коллеги делятся накопленным багажом знаний, чувствуешь, что готов горы свернуть. Что, надеюсь, у меня и получалось.
Part 4. Хто я?
Пока ты новичок в профессии, "экзистенциальные" вопросы в голове возникают редко. У тебя постоянно что-то горит, что-то не успевается, дни забиты нужными и не очень митингами. Таски "нарезаются" менеджером проекта, какие-то задачи для развития ставит ментор. В таком круговороте проходят, наверное, первые пара лет. Работаешь себе и особо не задумываешься ни о своей роли на проектах, ни о роли в команде, ни о том, зачем ты по утрам просыпаешься и подключаешься на дейлик.
Первые вопросы о том, кто я и зачем делаю свою работу, возникали еще во время смены компании и прихода в полноценный бизнес-анализ (про этот момент писал в первой части). Но тогда было не до поисков "смысла жизни", хватало и других, более приоритетных моментов. Сфера наша достаточно обширная, проекты у всех разные, и, самое главное, обязанности на проектах тоже разные. Мне приходилось быть и техническим писателем, и немного дизайнером, и тестировщиком, заниматься системным анализом - и наконец, быть бизнес-аналитиком :) И поскольку круг обязанностей был широк, мне было невероятно сложно объяснить, чем же я занимаюсь на работе. Мама до сих пор, наверное, думает, что я программист.
Так вот, что же я за зверь такой?
Начиная работать как аналитик, я часто использовал фразу "я - это переходник между заказчиком и проектной командой". Поскольку она описывала как раз то, чем я занимался - общался с заказчиком, документировал требования и заводил таски после согласования скоупа работ с командой. Как же я глубоко ошибался и как хорошо, что до меня все-таки дошло, что быть "переходником" - это путь не то, чтобы в никуда, но ведущий к гарантированным проблемам. Понимание стало меняться, когда теоретические знания стали складываться с опытом и магическим образом создавать ясную картинку в голове. Я тогда почувствовал себя как ребенок лет трех, которому удалось правильно соединить детский пазл с большими яркими элементами. Разве что не "угукнул" довольно :)
Раз упомянул про соединение теории с практикой - на этом моменте хочу выразить отдельную благодарность чтениям BABOK внутри BA Unit'а компании, где я работал, без них метаморфозы моего сознания начались бы сильно позже.
Вообще, не очень люблю BABOK. Все, кто меня знает, не раз слышали как я плююсь ядом в его сторону и как меня раздражают философские формулировки и размытые термины оттуда (слушал подкаст от украинских ребят про сертификацию и узнавал себя - кто не слушал, As a User I want to see №41). Но, удивительно, что правильные слова, которые записались глубоко на подкорку и которые лучше всего объяснили мне, в чем суть работы, я нашел именно в BABOK. А прочитанные позднее Agile Extension и IREB Fundamentals лишь укрепили меня в мысли, что это так и есть. Привожу эти слова в качестве иллюстрации
Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders.
The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.
Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders.
Пропустить через себя огромное количество информации, разложить все "по полочкам", определить скоуп и контекст системы/продукта. Докопаться до сути проблемы (без root-cause никак), провести impact анализ. Добиться того, чтобы решение соответствовало нуждам заказчика и реально "решало эту самую проблему". Три больших синих кита нашей работы :)
Правда, собственный опыт и Agile Extension подталкивают меня добавить еще один, четвертый пункт, не менее важный (это не цитата, а моя мысль, но позволю себе ее тоже выделить).
Business analyst is responsible for building and maintaining shared understanding between all (at least most of them) persons involved in the project
Эту часть я люблю, наверное, больше всего. Команда, которая понимает, какие потребности заказчика она решает, и мотивирована выполнять работу качественно и именно так, как заказчику нужно (think as a customer, мое любимое). Заказчик, который четко осознает, какую проблему мы решаем и что команда трудится на его благо не покладая рук.
На мой взгляд, хороший аналитик напоминает иногда семейного психолога. А семья представляет из себя что-то вроде Мистер и Миссис Смит, где с одной стороны заказчик, а с другой - проектная команда, и они время от времени готовы друг друга убить. А ты спокоен, ты готов выслушать обе стороны, проявить эмпатию и задать правильные вопросы. И пока "пациенты" ответят на вопросы, они самостоятельно поймут, в чем проблема, и придут к верному решению. Тому же способствует здоровая дружеская атмосфера на встречах/звонках, разбавленная уместным юмором и дополненная информативными диаграммами и примерами. А также постоянный сбор фидбэка и работа над ошибками. И это все - моя (наша) работа.
И если кто-то говорит, что BA на проекте не нужен/не обязателен - это просто он не работал с хорошим аналитиком в команде.
Есть основания полагать, что я верно выбрал профессию. Потому что могу получать удовольствие от всех ее аспектов: от разнообразия проектов и задач, от общения с реально умными людьми (которые намнооого умнее меня), от креативных активностей в виде создания диаграмм и дизайна продукта, от моментов, когда докопался до сути проблемы и когда заказчик утвердил разработанное командой решение... И, самое главное, когда вижу, что сделал чью-то жизнь лучше, способствуя превращению идеи, возникшей в голове, в нечто материальное.
Comments