И снова здравствуйте, коллеги и друзья!
В далёком 2011 году мы стартовали цикл статей для начинающих бизнес-аналитиков. В первых трех очерках мы успели рассказать вам о следующем:
2. Как создать резюме и найти работу?
Так уж выстроились планеты, что на этом наш цикл на время оборвался. И вот, спустя 3 года (за которые мы, как и вы, наши любимые читатели, стали чуточку мудрее и опытнее), учитывая постоянно растущий спрос на аналитиков в отечественных компаниях, мы решили продолжить цикл советов и рекомендаций для начинающих аналитиков и перейти к следующей категории: принятый на работу, но не осознающий в полной мере, что ему делать дальше, специалист. У авторов на пару есть весьма обширный опыт не только прохождения обучения в свое время, но и «натаскивания» молодых специалистов (несколько десятков проведённых индивидуальных стажировок и ряд массовых обучающих курсов), поэтому мы верим, что нам есть, чем поделиться и что посоветовать в этом плане.
Итак, вы – Business Analyst Trainee или Junior Business Analyst в фирме вашей мечты. Ваша цель на данный момент – успешно пройти испытательный срок, причём не просто «пройти», а извлечь из него максимум знаний и навыков, чтобы в будущем «наносить» заинтересованным лицам как можно больше пользы на реальных проектах и как следствие (хоть тут и не прямая зависимость), повышать свое ЧСВ и благосостояние. Возможны два варианта вашей работы на испытательном сроке: под чутким руководством ментора и без него. К сожалению, исходя из наших наблюдений, аналитики чаще попадают в ситуацию, когда ментора им не выделяют, и приходится держаться на плаву самостоятельно. Но рассмотрим для начала оптимистичный вариант.
Итак, на начальном этапе вам могут назначить ментора – более опытного бизнес-аналитика или менеджера, который станет вашем наставником, будет отвечать за ваше обучение и делиться с вами навыками / знаниями / опытом. Он же будет оценивать результаты вашего обучения / работы по окончании испытательного срока.
Для начала вам нужно убедиться в том, что вы знаете и понимаете следующее:
- Кто ваш ментор(ы)? Весьма вероятно, вашим ментором будет тот самый человек, к которому вас приведёт сотрудник отдела кадров в ваш первый день работы.
- Какие у вашего ментора ожидания / планы? Планирует ли он обучать вас 3 месяца на тестовом проекте или на реальном? Какой формат взаимодействия с вами он ожидает – вашу полную самостоятельность с небольшим контролем с его стороны или работу по плану ментора с детальными проверками и обсуждением всех ваших ошибок? Сколько у ментора времени на вас? Как вы будете общаться и взаимодействовать? Будут ли у вас еженедельные / ежемесячные progress meetings (встречи по обсуждению вашего прогресса)?
- По каким критериям ментор будет оценивать вас по истечении испытательного срока? По сути, чего вы должны достичь за отведенный вам срок и чему у вас есть перспектива научиться?
Сразу поясним: данные вопросы следует решать проактивно: ваша задача как аналитика – прояснить до степени кристально ясного понимания, что ожидает вас и чего ожидают от вас.
Независимо от ответов на вопросы выше, любой ментор (в идеальной картине мира) ожидает от вас следующее:
- Более-менее развитое умение получать задачи:
В простом варианте это означает, что если вы сделаете что-то не так, не тогда или не то, что было нужно, в первую очередь – это ваша вина. В любой ситуации вы должны чётко понимать, 1) что конкретно ментор хочет от вас (задокументировать требования к системе X), 2) к какому сроку (к дате Y либо же в течение Z дней), 3) в каком виде нужно представить результат (спецификация требований по произвольно выбранному вами шаблону). Также желательно понимать 4) зачем вы делаете ту или иную задачу, так как это поможет вам в выполнении задачи и прибавит мотивации (согласитесь, вы с большей охотой будете изучать предметную область того проекта, на который вас планируют привлечь в будущем).
Также есть методика анализа причин, по которым человек может не выполнять задачи (обычно этим пользуются лица, ставящие задачи, но вы также можете это спроецировать на себя и проактивно устранить первые 3 причины):
1) Вы не знаете, что конкретно нужно сделать (не понимаете суть задачи или понимаете ее по-своему).
2) Вы не умеете / не знаете как выполнять задачу (нет знаний / навыков / опыта в данной сфере).
3) Вы не можете выполнить задачу (нет физических / социальных / этических / психологических возможностей) или у вас нет средств для выполнения задачи (например, нет рабочего места, доступа к нужной информации и т.д.).
4) Вы не хотите выполнять задачу (нет желания / мотивации).
- Инициативность:
1) Если вы (внезапно) закончили задачу и ментор еще не поставил вам новую – узнайте у него, что вам делать дальше. Поверьте, подобная проактивность ценится очень весомо. Верно и обратное: будете сидеть и «простаивать», пока к вам не подойдут – значительно уроните себя в глазах ваших наставников. 2) Если вы видите, как усложнить / расширить / сделать по-иному вашу текущую задачу и извлечь из неё больше пользы – упомяните это ментору. 3) Если вы не уверены в своём прогрессе – предложите ментору провести внеплановый progress meeting.
- Вопросы:
Ментор прекрасно осознаёт, что у вас будут возникать вопросы, особенно на начальном этапе работы. Поэтому задавайте вопросы и не бойтесь показаться глупым. В конце концов, будет гораздо хуже, если из-за того, что вы побоитесь что-либо уточнить у ментора, вы неверно выполните поставленную задачу. Это совет по умолчанию, но имейте в виду и обратное: если вы будете постоянно забрасывать вопросами ментора, крайне загруженного проектными работами или еще двадцатью стажерами, реакция может быть противоположной. Поэтому если есть возможность самостоятельно разобраться с проблемой с минимальными усилиями – сделайте это.
- Адекватное отношение к критике:
Вероятнее всего, подготовленные вами артефакты будут проверяться ментором. Поэтому будьте готовы к потоку исправлений и комментариев, и учитесь воспринимать их адекватно. Безусловно, эго и самолюбие – это наше всё, но критика – это проявление желания вашего ментора сделать ваши артефакты (и вас как аналитика) лучше. Поэтому не стоит вступать в ожесточённые споры и дискуссии с ментором. Хотя, конечно, если дискуссия имеет цель лучше понять критику ‒ в ней таки может быть смысл.
- Способность самостоятельно анализировать результаты вашей работы и исправлять недостатки:
Если ментор попросил вас что-либо исправить, крайне важно (мы бы подчеркнули эти слова двумя линиями, если бы могли) исправить это с первого раза и стараться не повторять подобных ошибок в будущем. Ничто так не демотивирует наставника вкладывать в вас силы, как повторение ошибок, особенно механически глупых (например, вставка подписи в письмо или актуальность оглавления в документе). Тут поможет практика чеклистов – напишите список того, что вы должны выполнять или учитывать при подготовке очередного артефакта (например, проверять в документе орфографию), и постоянно «сверяйтесь» с этим списком. Так, через какое-то время его пункты войдут для вас в привычку. Чеклист стоит обновлять по мере усвоения одних пунктов и появления других.
- Записывайте:
На начальных этапах работы вы будете невероятно перегружены новой для вас информацией, так что не стоит полагаться на свою память. Опытный ментор, видя вас при получении инструкций без средств фиксирования информации, практически с гарантированной вероятностью определит, уловите вы все инструкции и нюансы задачи или нет. Например, записывайте в личный файл (MS Word, One Note, Evernote, ежедневник) все необходимые для работы ссылки и пароли (корпоративный портал, сайт для отчётности, хранилище шаблонов документов, корпоративное wiki и т.д.), детали поставленных задач, допущенные ошибки и др.
В целом, со всем перечисленным выше важно «не переборщить», так как зачастую ментор занимается вами совершенно безвозмездно, параллельно с текущими проектами. Поэтому цените время вашего ментора, наблюдайте за его реакцией и корректируйте соответствующим образом своё взаимодействие с ним. P.S. Все вышеупомянутое, кстати, абсолютно применимо для сотрудников любого уровня при получении и выполнении любого рода задач.
Рассмотрим другую ситуацию – работа без ментора. В этой ситуации вас, скорее всего, сразу подключат к реальному проекту. Что посоветовать… Не отчаивайтесь – тяжело будет, скорее всего, лишь поначалу. На проекте, в первую очередь, нужно: 1) чётко изучить и понять области ответственности и ожидания от БА в компании; 2) озвучить менеджеру проекта риски, связанные с вашей неопытностью, но при этом пояснить, что вы «will do your best», как говорится; 3) получить / изучить шаблоны артефактов, которые вам предстоит готовить. Дополнительными советами о том, как органично войти в свой первый проект, мы поделимся в следующей статье. Здесь же расскажем о том, к кому обращаться за помощью, если ментора у вас нет либо у него недостаточно времени на ваше обучение:
- Центр компетенции / обучения аналитиков:
Если таковой имеется, «достаньте из-под земли» его руководителя и попросите у него помощи. Обязательно узнайте следующее: 1) возможно ли найти и назначить вам ментора из аналитиков компании; 2) есть ли корпоративная база знаний или рекомендуемые к изучению материалы по бизнес-анализу; 3) имеются ли шаблоны документов и иных артефактов, рекомендуемые или же принятые к обязательному использованию 4) где можно найти описание обязанностей и зон ответственности аналитиков в компании; 5) есть ли в компании система квалификации, которая будет определять ваш рост, и проводится ли формальное периодическое подтверждение / повышение квалификации; 6) как между собой взаимодействуют аналитики центра компетенций (вероятно, в наличии есть периодические встречи с докладами и обменом опытом или хотя бы Skype-чат для вопросов и обсуждений – наверное, излишне говорить, что в эту существующую инфраструктуру вам надо тем или иным образом внедриться :)).
После знакомства с аналитиками в вашей фирме у вас появится возможность консультироваться с ними по профессиональным вопросам. Безусловный плюс здесь в том, что вы сможете прямо делиться вашими проблемами на проекте и показывать результаты вашей работы, а также получать ответы с учётом специфики работы в вашей конкретной компании.
- Другие аналитики в компании (или люди, занимающиеся подобными задачи):
Если в компании нет специализированного центра компетенции по бизнес-анализу, не отчаивайтесь: наверняка есть бизнес-аналитики на других проектах либо люди, которые выполняли / выполняют эти задачи. Найдите их и действуйте согласно описанному в предыдущем пункте.
- Analyst.by – форум и группа в Facebook:
Вы всегда можете задать ваши вопросы более опытным аналитикам посредством форума и группы analyst.by в Facebook. Минус тут в том, что не имея права разглашать конфиденциальную информацию, вам нужно будет более абстрактно формулировать вопросы. Вы также можете попробовать обратиться на форуме или в группе с просьбой о частичном менторстве со стороны более старших коллег – возможно, и такой вариант сработает (хинт: коллеги любят светлое и нефильтрованное чешское :)).
- Коллеги по команде (не аналитики):
Часто происходит так, что помощь приходит от тех, от кого её не ожидаешь. Так, например, менеджер проекта может помочь в понимании проектных процессов и подскажет, к кому идти за советом в каждом конкретном случае. От тестировщиков можно получить весьма дельные советы и рекомендации по качеству ваших артефактов и услышать занятные истории о функциональности продукта. Разработчик разъяснит технические детали системы и предоставит свой взгляд на задокументированные вами требования.
Подытожить все вышесказанное хотелось бы следующим: помните, как оно было – сначала вы работаете «на зачётку», а потом уже она работает на вас? Так и здесь: транслируйте скромность, смирение, искреннее стремление научиться, приоритет опыта и знаний перед деньгами, благодарность за вкладываемые силы, доброжелательность и инициативность – и старшие коллеги к вам также отнесутся с искренним энтузиазмом, стараясь передать вам накопленный опыт и знания.В следующей статье мы поделимся с вами практическими советами о том, как успешно войти в первый / новый для вас проект и избежать наиболее распространённых ошибок.
P.S. Уважаемые молодые (и чуть-чуть постарше) аналитики. Что бы вы хотели увидеть в данном цикле статей? Какие вопросы вас волнуют? Есть ли вас опыт, который подтверждает / противоречит изложенному в статьях? Чем бы вы дополнили каждую из статей? Мы будем очень благодарны комментариям по этим вопросам к данной статье (за это вам будет куча плюсиков в карму и лучи добра :)). Cпасибо!
Прывiтанне! Артыкул актуальны для мяне: супала шмат. Базавыя веды пасля курсау аказалiсь не актуальным, бо падыход iншы. Патрэбна састауляць ТЗ — зразумелае, дакладнае, каб прам адразу кодзiць. Прыкладау няма, калег прафiсiяналау няма. Заувагi былi на спосабу прадстаулення iнфармацыi. Актуальны запрос — больше схем. А як алгарытмы з варыянтами сцэнарыяу i матэматычнымi праверкамi пiсаць мне пакуль невядома. Буду удзячна за прыклады у лiтаратуры. Светлае нефiльтраванае — прам як патрабаваннi з якiмi cутыкаюсь….)
Виктория, здравствуйте! Спасибо за отзыв. По вашей теме: каковы требования к схемам? Схемы для чего? В какой нотации? Собственно, а зачем?:) Если ответ на все — так надо и остальное неважно, то (опять уточните эти вопросы и не уходите, пока не получите ответы) UML вам в руки. Могу отдельно потом отписать, где и что почитать.
Дакуменцiрую патрабаваннi для мастера разлiкау. Сцэнарыяу набора параметрау, алгарытмау разлiкау шмат. Адпаведна апiсаннi цяжкiя для успрымання: абмежаваннi, апiсанне алгарытмау, прыарытэтау, формул… Цяжка успрымаць iнфармацыю. Натацыя — прабачце, даступная visio. ) Аб’яднаць вялiкiя масiвы дадзеных з дапамогай схем — мая актуальная задача. Двайны дзякуй! )
Ну… это вообще отдельная точечная большая тема, но если вкратце, то нужно осознавать, что у визуальных моделей — очень ограниченная смысловая нагрузка (на то они моделями и зовутся). Все аспекты требований вы на паре схем не покроете. Если вы хотите показать сценарий алгоритма — это одна схема. Акцент на взаимодействии между участниками — чуть другая. Структура некой системы (компоненты и связи) — это совсем другой взгляд. На ограничения, формулы и иную статическую информацию — я вообще не уверен, имеет ли смысл это схемами показывать. Большие массивы данных — это бы уточнить, не совсем понял…
В Visio вы можете практически на всех известных нотациях «рисовать». В общем, уточните те вопросы, которые я в первом комментарии перечислил — это должно помочь. В минимальном варианте, разрисуйте сценарии (варианты использования, алгоритмы вычислений) с помощью UML Sequence или UML Activity диаграмм.
нужно осознавать, что у визуальных моделей — очень ограниченная смысловая нагрузка
Герман, а как тогда относиться к подходу MDA (Model Driven Architecture) и разве идея языка UML у его основателей не для того, чтобы разработку ПО на уровне моделей производить? А по поводу таких вещей как ограничения для них в рамках UML специальная нотация OCL имеется, решающие правила тоже очень хорошо и наглядно моделируются, с формулами (алгоритмы их расчёта) тоже не проблема, да и текстовые примечания всегда в самой модели к конкретному элементу привязать не проблема. Как правило (за исключением отдельных исключений), визуальная модель (чертёж, сделанный соответствующим специалистом) легче воспринимается (тоже соответствующим специалистом), чем аналогичное текстовое описание.
Николай, я не совсем то пытался донести. 1) Ограниченный смысл несет каждая из моделей в отдельности, т.к. изображает именно те свойства объекта моделирования, на которых мы акцентируем внимание. Набор моделей в сумме может давать вполне себе разносторонний взгляд на предмет моделирования. 2) OCL — нечто новое для меня, спасибо, ушел читать:)
Ну тут я полностью согласен! Каждая отдельная диаграмма несёт лишь ограниченное представление о предмете моделирования. Отдельные диаграммы группируются в модели. Набор диаграмм, относящийся к предметной области составляют domain model (машино-независимая CIM-модель), далее создаётся набор диаграмм анализа application model (или платформо-независимая PIM-модель или модель анализа), далее проектировщик создаёт комплект диаграмм, который называется design model (платформо-зависимая PSM модель или модель проектирования). Модели проектирования PSM используют для автоматической генерации кода. Полный процесс разработки на основе визуальных моделей достаточно сложный.
Дзякуй за тлумачэннi. Я iнтуiтыуна разумела, што немагчыма аб’днаць неаб’ядноуваемае — розную па сэнсу iнфармацыю. Не хапала экспертнай ацэнкi. I UML мне у дапамогу! )
Отличная статья, спасибо!
«Вам нужно убедиться в том, что вы знаете и понимаете следующее: … Какие у вашего ментора ожидания / планы?»
1. Многие начинающие специалисты не знают, как подойти к этому вопросу. Кто-то боится, кто-то стесняется, кто-то считает, что достаточно «делать что говорят». Но поверьте, лучше перебороть себя, чем в конце испытательного выяснить, что в отношении вас были ожидания, о которых вы даже не подозревали.
2. Иногда у ментора тоже отсутствует четкий план (например, менторством человек не занимается на постоянной основе). Но есть достаточно большая вероятность, что такие вопросы помогут ему задуматься о плане и ожиданиях.
Если вы (внезапно) закончили задачу и ментор еще не поставил вам новую – узнайте у него, что вам делать дальше.
Очень часто вижу, как человек сидит и ждет, «пока его вызовут». Вы уже не на уроке в школе! Ваше будущее зависит только от вас.
Безусловно, не надо быть дятлом, пытающимся задолбать слона, но инициативность — это качество, которое нужно аналитику постоянно.
1. Многие начинающие специалисты не знают, как подойти к этому вопросу. Кто-то боится, кто-то стесняется, кто-то считает, что достаточно «делать что говорят». Но поверьте, лучше перебороть себя, чем в конце испытательного выяснить, что в отношении вас были ожидания, о которых вы даже не подозревали.
Вот у меня случилась такая ситуация: делала все что говорили, когда задачу заканчивала, сразу спрашивала есть ли замечания/комментарии к выполненной задачи и просила следующую задачу. Что в итоге — я все равно не оправдала ожиданий.
Как понять, какие на возложены ожидания от меня? Какими уточняющими вопросами это можно выяснить или есть еще какие способы?
Уважаемый читатель, а можете для начала уточнить, как вы поняли то, что не оправдали ожиданий (с вами не продлили контракт, не подняли зп, не утвердили более высокую квалификацию)?
Узнать об ожиданиях просто — спросить, что вам нужно сделать, чтобы [успешно пройти испытательный срок / получить надбавку к зп / повысить квалификацию]? В идеале, вам стоит попросить ментора проводить периодические встречи по обсуждению вашего прогресса и оценке того, насколько вы близки к вашей цели.
Также учтите, что помимо результатов выполнения задач, есть 1) ваши личные качества (умение общаться с людьми, скорость работы), о которых ментор может вам не сообщить в комментариях к конкретной задаче 2) стандарты/регламенты в компании (к примеру, для повышения квалификации вы должны поработать на 2 проектах в разных доменных областях), которые часто не связаны с вашим уровнем профессионализма.
Всегда есть вероятность ситуации, что вы / мы ожиданий не оправдаем — вдруг у компании была четкая нацеленность взять по конкурсу одного из 20 стажеров. Такую ситуацию вам вряд ли честно объяснят, а оценивать уже будут явно по сравнению с другими. Также, то, что вы перечислили — это же не единственные критерии оценки. Вы могли не подойти в команду / компанию по сотне дополнительных причин.
Что могло бы помочь заранее: обсуждение прогресса (инициативно выяснить, какие есть претензии, что желательно бы доработать и не являются ли замеченные проблемы барьером для дальнейшего трудоустройства).
Что крайне важно сделать после: вы написали, что не оправдали ожиданий. Выяснено ли, в чем конкретно?
Денис, спасибо! Очевидно, рекомендации в статье подкрепляют твой личный опыт обучения аналитиков :)
1. Если вам назначили ментора, то слушайтесь его: он сделает из вас человека бизнес-аналитика.
2. Если вам не назначили ментора, то добейтесь, чтобы его назначили и см. п.1.
:)
А если серьезно, то совет неплохой. Но не хватает второй части совета: что делать, если с ментором не повезло?
Андрей, спасибо! Частных случаев «негодности ментора» может быть очень много, так что да, вполне себе тема для ещё одной статьи. В общем же случае, если с ментором не повезло, то можно считать, что его нет, и следовать советам во второй части статьи (найти альтернативного ментора :))
Ещё не плохо быть уверенным, что человек, к которому вы обращаетесь за помощью, компетентен. В первой компанию я пришел фактически с нулевым опытом в БА (но был большой опыт в разработке сайтов). Меня сразу же кинули на реальный проект. Ментора никакого не было, остался один бизнес-аналитик со своими проектами и проблемами (1 год опыта вроде на тот момент) и менеджер проектов (пол года тестировщик и пол года менеджер проектов). Они мне многого насоветовали))
Как хорошо что я сразу пошел проходить курсы по БА и начал много читать по теме. По мере прохождения курсов и изучения материалов у меня не раз возникал большой Facepalm по советам менеджера проектов и второго аналитика. Менеджер проекта мое первое в жизни сырое ТЗ прочитал и пропустил на продакшн без каких либо вопросов. А там была огромная куча косяков (скрытые, неописанные, неточные требования и т.д. и т.п.). По мере прохождения курсов благо удалось почти все исправить и снизить риски на проекте до минимума. В процессе работы второго бизнес-аналитика уволили, набирали других, я стал независим от PM, сам вел свои проекты, переработал все шаблоны документов, а потом и вовсе перешел в компанию моей мечты с опытными коллегами бизнес-аналитиками и менеджерами проектов).
Всем новичкам компетентных менторов и счастья в новом году!)
Что бы вы хотели увидеть в данном цикле статей? Какие вопросы вас волнуют?
Я писала название темы уже в «запросить статью», повторю и здесь. Интересует тема »технического бэкграунда» для молодых специалистов . Хотя, на аналист.бай в основном, как мне показалось, аналитики — бывшие разработчики, некоторые приходят в анализ из других областей, а для «разговора на одном языке» нужен минимальный набор общедевелоперских знаний. На что в работе обратить внимание аналитику, если технического бэкграунда нету? Возможно, профессиональные аналитики с большим стажем замечали у новичков «типичные» ошибки , связанные с отсутствием опыта разработки?
Елена, да, идея для статьи отличная. Если вкратце (мысли «на коленке»):
1. Получите этот самый минимальный тех. бэкграунд. С помощью друзей-разработчиков (или сами, на основе книг «для чайников») изучите на базовом уровне какое-либо средство разработки для той области, в которой вы предполагаете наиболее плотно работать (например, веб: для примера возьмите PHP, который для полноценного минимального приложения с работой с базами данных потянет за собой и HTML c СSS и JS и СУБД а-ля MySQL). Нужен только базовый уровень и способность вами написать минимальное приложение, имеющее вертикально все необходимые уровни (фасад, логика, БД).
2. В процессе изучения (и еще и работы), когда цепляетесь за любой незнакомый термин, ищите и изучайте. Суть — в доскональном понимании того, что это, зачем это и как это работает. Запоминать все эти вещи не надо.
3. Есть вот такой чеклист: http://analyst.by/forum/materialy-saita/kurs-molodogo-ba#post-7381. Можно (пока терпения хватит) и его читануть.
Уведомление: Как стать UX-специалистом: часть 3 | UX Experience