Я работаю аналитиком всю сознательную жизнь около 10 лет. Чуть меньше половины этого времени я обучаю других аналитиков. Активно обучаю. Последние год-полтора я стал замечать среди кандидатов на курсы большой процент людей, не готовых стать аналитиками. Да, именно поэтому мы и проводим входное интервью, чтобы уберечь будущих курсантов от неэффективной траты времени и денег. Лично я отправляю таких неготовых людей доучиваться и считаю, что эта подготовка им пригодится, даже если они пойдут потом не к нам, а в другой учебный центр. Но уже так много раз это делал, что решил упростить всем жизнь и написать эту статью. Надеюсь, она сэкономит время не только мне.
Здесь я буду говорить, в первую очередь, про бизнес-анализ (БА) в ИТ. Но если вы хотите попасть в БА вне ИТ области, то можете просто ослабить требования к себе по второму пункту.
Итак, 5 признаков того, что вы не готовы (пока) стать ИТ бизнес-аналитиком:
- Вы ничего не знаете про бизнес-анализ и бизнес-аналитиков.
- Вы ничего не понимаете в ИТ.
- Вы не умеете моделировать.
- Вы не умеете объяснять.
- Вы не знаете английский.
Ну как, возникло много вопросов? Само собой. Сейчас добавлю деталей, и станет понятнее…
1. Вы ничего не знаете про бизнес-анализ и бизнес-аналитиков (но почему-то уже страстно хотите ими быть).
«Бизнес-аналитик – это… это такой человек… ммм…» (с)
Нет, вы, конечно, что-то слышали, но толком рассказать и объяснить кто такой аналитик вы не можете. Примерно такой уровень осознанности можно наблюдать у детей, когда они хотят стать космонавтами, пожарными или, того и гляди, милиционерами, ничегошеньки не зная о профессии, кроме того, что увидели в фильме, мультике, книжке, на улице. Вы действительно собираетесь потратить свои кровно заработанные деньги и неприличное количество месяцев на то, чтобы выучиться на того, чью роль вы (вообще) не понимаете?.. или понимаете ооооочень смутно.
Мой совет: если уж вы решили освоить какую-то область знаний, то пройдите самыми быстрыми и дешёвыми способами стадию «я не знаю, чего я не знаю» и начинайте полноценное освоение со стадии «я точно знаю, чего я не знаю» (осознанная некомпетентность). А именно: читайте статьи и базовую литературу, смотрите бесплатные онлайн-семинары, хотя бы.
2. Вы ничего не понимаете в ИТ
«ПО – это… это такая штука… ммм..» (с)
Под этим я подразумеваю:
- Не знаете, из чего состоит компьютер и ПО;
- Не знаете, как вообще хотя бы в общих чертах создается это самое ПО;
- Не знаете, что это за таинственное ПО, которое я упомянул уже в трёх пунктах, каким оно бывает и чем друг от друга отличается;
- (я могу продолжать, но, думаю, моя мысль понятна).
Тут важно, что вы должны понимать, как всё устроено, не на уровне опытного водителя автомобиля (это прекрасно! но этого мало…), а на уровне, специалиста, который принимает вашу машину на СТО, когда вы приезжаете туда с поломкой (см. прекрасное сравнение от Германа Шестерова на эту тему в его статье «PM и BA — эти «тонкие» различия…»). Заметьте, не на уровне автомеханика, автослесаря, электрика или кого бы то ни было ещё (но если уже знаете на таком уровне, то вам же лучше!).
3. Вы не умеете моделировать.
«Моделирование? Ну это там самолётики, кораблики.. Нет? Ну, может, тогда с одеждой что-то связанное…» (с)
Под моделированием здесь я подразумеваю построение визуальных моделей, причем знание языка или нотации моделирования (UML, BPMN, ARIS, IDEF, …) не так важно, как само умение строить эти модели в целом (или в сааамом крайнем случае умение правильно читать модели).
Поэтому, если вы в школе, университете или на прошлой работе хотя бы рисовали блок-схемы, чтобы зафиксировать, как правильно рассчитать какую-то формулу, премию, …, это уже неплохо. Но радостно останавливаться на этом, конечно же, не стоит.
Кто-то может со мной поспорить и сказать, что это навык и его легко создать. А я считаю, что, хоть это и навык, с полпинка он не создается, и поэтому, например, на курсы по бизнес-анализу (не по моделированию!) стоит идти уже подготовленным в этом плане. Тем более, сегодня любому человеку доступен океан бесплатной информации по этой и другим нужным темам.
Аналитику постоянно надо что-то моделировать: то AS-IS, то TO-BE, то на бумаге, а то и в специализированном ПО. Причем зачастую аналитик это делает неявно, в голове, не задумываясь (ага, неосознанная компетентность), моделирует он или нет. Ведь моделирование — это один из способов самому разобраться в чем-то. А ещё и другим объяснить это что-то…
4. Вы не умеете объяснять.
«На предыдущей работе я работала с полупроводниками. Полупроводники? А, это… это такая штука… ммм..» (с)
Работа аналитика постоянно связана с объяснением. Причем объяснять аналитику надо так, чтобы его понимали и технари, и не технари, и вообще люди разных сортов, возрастов, взглядов, специальностей, национальностей и вероисповеданий. Так что, если вы не умеете это делать, никакие курсы (а также книги, статьи, вебинары, …) по бизнес-анализу вас этому не научат. Конечно, если только они не содержат в себе материал по этой теме. Много, очень много материала. Я убежден, что любой специалист — а бизнес-аналитик особенно — должен уметь на простом и понятном собеседнику языке объяснять как то, кто он такой и чем занимается, так и любое понятие из его области знаний. Для того, чтобы это делать, надо а) хорошо это всё понимать (см пункты 1 и 2); б) уметь объяснять.
5. Вы не знаете английский.
«Английский? Да, сейчас… Значит, это.. London is the capital of Great Britain…» (с)
Тут, конечно, со мной могут поспорить люди, работающие только на локальный или только на русскоязычный рынок, но кмон, все самые лучшие книги по БА в оригинале сейчас на английском. Да ладно книги: актуальные статьи, форумы, мероприятия, конференции — всё на английском. Хотите быть в теме (а вам придется!)? Ну, вы поняли. Кстати, если говорить про Беларусь, то бОльшая часть компаний, в которых работают ИТ бизнес-аналитики – это аутсорсинг. И заказчики в подавшяющем большинстве случаев разговаривают на английском. А если и не аутсорс, всегда есть шанс, что ваши партнеры или субподрядчики могут быть из других стран.
Программа минимум — знать английский и технический английский на уровне достаточном, чтобы читать и понимать книги, статьи, техническую документацию, письма заказчиков, партнеров, подрядчиков и т.д.. Программа максимум — уметь доносить свои мысли на английском как в письменной, так и в устной форме.
Друзья, не стоит отправляться в отпуск в то место, про которое вы ничего не знаете и к посещению которого вы не готовы. Может, вас там всё удивит, всё понравится и вы здорово отдохнёте, а может, профукаете деньги, время, и, что хуже всего, потеряете желание куда-либо ещё ездить. Может.. а, может, и нет. Готовы рискнуть? Или лучше минимизировать риски, тщательно подготовившись?
Лично я глубоко убежден, что каждый человек при наличии достаточного желания и времени может стать бизнес-аналитиком, так что правильнее будет сказать, что если у вас есть какие-то проблемы из списка выше, то бизнес-анализ — всего лишь ПОКА не для вас…
Работающие аналитики, руководители аналитиков, бывшие аналитики, я бы хотел услышать и ваши мнения. По каким признакам вы решаете, что кандидат на позицию БА вам не подходит? Что из перечисленных выше признаков, может быть, когда-то относилось и к вам? Как вы справились с этой проблемой, как устранили пробел? С какими из приведенных признаков вы не согласны и почему?
Upd. Читайте продолжение в статье: «Как подготовить себя к тому, чтобы стать аналитиком в ИТ?«
—
директор и тренер учебного центра ITMINE, директор UXpresso
Здравствуйте Юрий!
Очень рада появлению этой статьи.
Многие люди сейчас стремятся попасть в ИТ по одной причине — здесь высокие заработные платы и кроме того «Бизнес Анатик» звучит красиво и «по-модному» :)
Я думаю имея правильные критерии отбора студентов, вы лишний раз доказываете высокий уровень ваших курсов.
Спасибо за похвалу.
Я, конечно же, знаю про тотальное желание попасть в ИТ, и я, честно говоря, его поддерживаю. Вопрос в том, что не всем это действительно надо, не все действительно могут и т.д., но то, что возможностей сейчас стало значительно больше, чем лет 10-15 назад — это правда, и ещё больше появится. И это очень круто. Вот я двумя руками (и ногами) за то, чтобы весь этот «поход в ИТ» был как можно более осознанным. Я ведь не назвал статью «5 признаков того, что вы не станете бизнес-аналитиком в ИТ», нет, просто кто-то ещё не готов.. и ему лучше бы об этом знать (:
Юра, спасибо за статью! Напишу с чем согласен, а с чем — нет:
+ Проблема осознанности у людей, куда и зачем они идут — есть. Бывают случаи, когда это по совокупности входных навыков и качеств не мешает расти дальше и в итоге полюбить профессию, но бывают, к сожалению, и иные случаи. Конечно, аналитический подход к определению того, стоит ли и можете ли вы успешно быть аналитиком (такая вот рекурсия) — это хорошо и полезно: взвесить свои входные способности, прикинуть, зачем вам это и т.п.
+ к IT.
- Моделирование считаю, как ты и пометил, именно утилитарным навыком и приобретаемым. Я бы его в топ пять точно не писал. Этому учатся и в частности — этому учим мы :) Это производное от 1) системно-аналитического мышления и способности в голове упорядочить мысли и знания по сабжу и 2) умения доносить инфу.
— Добавил бы пунктом 2 (assuming, что они в порядке приоритета) системно-аналитическое мышление. Считаю критичным для аналитика и слаборазвиваемым за короткие сроки (например, на курсах). Не раз об этом писал в статьях тут — повторяться не буду.
— Умение доносить информацию — согласен на 50%. Это, конечно, не так легко приобретаемо, как моделирование, но и не корневой навык. Это следствие мышления (см. выше) и общекоммуникативных навыков. Если есть картинка в голове + речь / письмо не сбивчивы и не хаотичны + есть некоторые навыки донесения инфы (что нужно, конечно), то будет счастье.
— Да, считаю инглиш условным :) Ты все верно написал, что лучше язык изучить, чтобы не ограничивать свои перспективы. Но а если чётко понимаешь свои перспективы и цели и то, что с английским они связаны не будут? Хуже без него — да. Критичен ли он для БА В ИТ — нет, если (…).
Герыч, а тебе спасибо за комментарий. Конечно, я прочитал его ещё месяц назад (даже больше (: ), но ответить решил только, когда уже написал продолжение статьи.
Ты чертовски прав по поводу мотивации и любви к профессии. Я вот как-то это упустил и в этой статье, и в следующей, как бы предполагая, что это уже есть или где-то появляется на фоне. Но это критично настолько, что и правда стоит об этом отдельно упомянуть.
Что касается твоего предложения добавить «системно-аналтическое мышление» вторым пунктом… вот лично я думаю, что его очень сложно пощупать-проверить и определить его наличие или отсутствие. А вот если человек может объяснять сложные вещи простым языком + умеет моделировать, и это, конечно, не равно «системно-аналитическому мышлению», то я полагаю, что это косвенно означает, что оно у него есть.
Что скажешь?
Ну мы же корневые черты обсуждаем? :) Если B и C — следствие А, то 1) то, что B и C легче проверить, чем A, не означает, что у человека должны быть и человеку нужно прокачивать именно B и С, а не A. 2) Ты написал «косвенно». Т.е. где-то в области кругов Эйлера, B и С могут быть включены в A, но А != B+C.
Че-то занесло… Я бы сказал, что проверка/самопроверка/прокачка образа мышления — это доп. задача, которую надо решить. Сейчас ее каждый пытается решить своими путями и выносит суждение, основываясь на общих впечатлениях о том, как человек размышляет. А если уж говорить о взаимосвязях навыков, то я бы их представил немного по-другому:
1) Умение донести информацию (УДИ) — это системно-аналитическое мышление (САМ) + что-то еще (коммуникативные навыки).
2) Визуальное моделирование — это УДИ + что-то еще (знания и навыки в теории моделирования).
Поэтому я и отписал, что нужно прокачивать САМ. Для УДИ нужно еще и прокачать коммуникативность. Для моделирования — ничего больше не нужно :) (знания и навыки визуализации даются на курсах).
Красиво излагаешь.. да ещё и в логику с математикой затягиваешь (:
Соглашусь с тем, что некоторые вещи «далеко не очевидны», т.к. да, это только мои гипотезы о том, как оно всё работает. Тем не менее, с пунктом 2) не могу согласиться полностью: для меня Визуальное моделирование — это не просто УДИ + что-то ещё, а УДИ + САМ + что-то ещё.. ибо я под Визуальным моделированием имею в виду не просто «картинки рисовать», а с вдумчивым пропусканием этих картинок через себя… В общем, нужно с бокалом чая это дело обсуждать (;
Добрый день!
1. Нуу, как бы да. Всегда прикольно идти в ту сферу, о которой есть хоть малейшее представление.
2. Это да, хотя бы общее представление о сфере, о том, как «это устроено» и сколько это стоит.. а то можно и наобещать Клиенту..
3. Соглашусь с Германом. Описание БП, рисование человечков; ) — вещи наживные, тут главное — спосбность анализа и понимания процессов.. а это уже и требование к пониманию области/сферы Клиента.
4. Эммм, ну для анализа хотя бы понять надо, для начала.. а красиво говорить может ПМ, Сейл.. и да — «говорение» такой же наживной скил, как и моделирование
5. Это пункт универсальный и нужный везде.
6. Отдельно бы добавил коммуникабельность — отличие от «объяснять» — в умении находить общий язык с любым Клиентом, иначе не из чего/кого требования извлечь будет..
7. Стрессоустойчивость.. очень, иногда, грустно/печально, когда ты слышишь, что твоя работа не нужна, да и ее и не видно и т.д. это тоже надо научиться понимать, фильтровать.. иначе сразу возникают проблемы с п.6 ))..
Юра, спасибо за комменты. Отвечаю с задержкой, но.. отвечаю (:
1. Прикольно? (: Имхо, это просто a must…
2. Вот, как я и Герману тоже написал, лично я считаю, что под «уметь строить визуальные модели» кроится гораздо больше, чем просто картинки рисовать. Лично для меня визуальные модели — суть отражения того, как ты думаешь. И если ты просто технически знаешь нотацию UML — это, конечно, мелочно. Мыслите глобальнее! Зная нотация языка (любого), ты можешь изобразить свои мысли или мысли своего собеседника с помощью визуальных моделей, найти там упущения, несоответствия и тд.
4. Важно не просто говорение.. а умение, пропустив через себя, объяснить. Объяснить = донести концепцию, понятие, понимание, … Перед этим надо их понимать. А ещё надо понимать, как это правильно сказать. А ещё надо понимать, как другие люди думают. А ещё надо уметь изменить подход к объяснению, если человек тебя не понимает… м? (:
Про 6 и 7, пожалуй, соглашусь. Правда не готов их в пятёрку добавить, но пункты важные, ага.
Спасибо за статью! Многое спроецировал на себя, так как будучи без пяти минут студентом переводческого факультета, хотел попасть в IT. Помню тогда, пребывая в состоянии неосознанной компетентности, рисовал в голове невероятие «няшные» образы-клише бизнес-аналитика. Это состояние, думаю, у каждого может присутствовать, и это ок, тут главное понимать, идёшь ли ты с этим состоянием дальше, ожидая, подпитывая себя надеждами, что нарисовал в голове правильную картинку, или шаг за шагом рисуешь настоящую реальность. Могу сказать, что почти все пункты, которые описаны в статье, можно поднять на level выше своей проактивностью, если это начало пути (изучив, почитав, пообщаться с экспертами, хорошо постараться закончить, например, курсы). А потом поддерживать и укреплять навыки. И да, если проводить аналогию, то придётся «понять, чем отличатся топливный насос дизельного автомобиля от бензинового, и что пьезо форсунки не для распрыскивания жидкости на лобовое стекло»
Иначе, во время работы, я считаю и знаю, будет очень тяжело (и, между прочим, это тоже ок!)
Быть квинтэссенцией знаний и опыта в своём деле – это, наверное, помогает избежать зафакапленного проекта/контракта, демотивированной команды разработки, недовольных бизнес стейкхолдеров/заказчиков в ~ 95% случаев. Но есть ещё и всё-таки условные 5%.
Когда вы планируйте отправиться в отпуск в Бразилию, вы знаете, что хотите изучить там самые интересные кварталы Рио, вы всегда мечтали посмотреть на трущобы, вы знаете, что это такое, вы смотрели фильмы, discovery и читали новости. Вы готовитесь…изучайте карту, возможные опасности, готовите электрошокер с собой, изучайте технику контактного самбо… Потом приезжайте и не знаете, что делать с мачете в пяти сантиметрах от лица.
Для меня такие серьёзные проблемы закрываются не легко, и не всегда, но бывают и закрываются (хочется верить) с помощью пунктов ниже:
- развивать в себе умение постоянно пробовать новые методы решения/управления, когда первый, второй, третий…раз что-то не получилось (например, начать писать требования более формально, отойти от тонны документации, если это поможет быстрому согласованию)
- брать обратную связь о проделанной работе, признавать ошибки с достоинством (это точки роста, так как сам в текучке, например, по пункту 1 можешь очень долго не продвинуться)
- спрашивать, спрашивать и ещё раз спрашивать, не бояться показаться недалёким (была тут такая замечательная статья про ментора, но в реальности чаще всего ментор не всегда рядом, либо вообще его нет, придётся выведывать информацию)
- не поддаваться эмоциям даже, когда на тебя почти с кулаками летит backend разработчик, потому что ты ему не описал требования по интеграции, а заказчику сдавать проект через два дня, либо бизнес-стейхолдеров уже в сотый раз расширяет скоуп так,что весь проект под угрозой;
- не бояться рутинной работы и в тоже время принимать решения, что процесс ради процесса не будет практиковаться при мне и мной (пункт первый «в стиле эксперименировать» не всегда прокатывает, прислушиваться или следовать академическими практикам тоже нужно, да в конце концов даже после 10 минутной встречи писать MoM в удобном формате (без перфектионизма), либо в понятном UML формате нарисовать схему для ЗЛ, да и если даже с первого взгляда не будет понятно, то объяснить в деталях, показать преимущества, чтобы люди ощутили ценность. Затраченные усилия вернуться)
«Ах, soft skills» — скажете вы!
«Ну да!» — скажу я!
«Эээ…с мачете поможет?» — спросите вы.
«Пока не попробуете, то не узнаете» — отвечу я.
Ха-ха. Это как раз пять признаков, что я смогу стать аналитиком) Потому как всеми перечисленными качествами я обладаю. Хотя так или иначе в своей работе я с этим сталкиваюсь.
Юлия, а кем работаете, если не секрет?
Кстати, если ещё не аналитиком, то вот вам продолжение статьи — «Как подготовить себя к тому, чтобы стать аналитиком в ИТ?«