analyst.by

Белорусское сообщество бизнес и системных аналитиков

Как подготовить себя к тому, чтобы стать аналитиком в ИТ?

Вы прочитали мою предыдущую статью («5 признаков того, что вы не готовы стать бизнес-аналитиком в ИТ») и вас совсем не расстроило (ну если только немного;) наличие у вас каких-то признаков, или даже наоборот – теперь вы еще больше хотите двигаться дальше и закрывать пробелы в знаниях? Или совсем не читали предыдущую статью, а просто случайно увидели текущую? В любом случае, вы наверняка хотите узнать, с чего же начать, чтобы подготовить себя к курсам / стажировке или любому другому формальному обучению. Об этом и пойдет речь далее.

В зависимости от той позиции, с какой вы начинаете (то есть от того, что вы уже знаете и умеете на данный момент), у вас может уйти на это всё от недели-двух до нескольких лет. Да-да, я не оговорился – до нескольких лет…  усиленного изучения и освоения нового. Для сокращения этого срока вам, конечно, ооочень пригодится ваша мотивация и способность учиться.

Чтобы было проще начинать, я разбил это «с чего начать» на некоторое количество шагов. Хорошая новость заключается в том, что вы можете выполнять их именно в приведенной последовательности, можете в какой-то своей, а можете вообще пробовать всё делать в параллель, главное – пройти все шаги. Чуть менее хорошая новость заключается в количестве пунктов. Но вас же уже не запугать, не так ли? Итак, поехали.

  1. Найдите того, кому вы всё, что узнаете и освоите дальше, будете рассказывать и объяснять («ухо»).
  2. Узнайте, кто такой бизнес-аналитик. В подробностях!
  3. Узнайте, что вообще такое бизнес-анализ и что входит в эту область знаний.
  4. Проведите честную самооценку по качествам, знаниям и навыкам, необходимым бизнес-аналитику, составьте план развития и начните его выполнять.
  5. Протестируйте свой уровень английского, составьте план по его повышению и начните его выполнять.
  6. Получите (базовые) знания по ИТ и разработке ПО (включая процесс и подходы разработки ПО).
  7. Освойте визуальное моделирование хотя бы на базовом уровне.
  8. Узнайте актуальную ситуацию на рынке труда.
  9. Поговорите с парой живых аналитиков и с парой не-аналитиков (но тоже живых), чтобы проверить все ваши предположения и планы.

 

А теперь давайте рассмотрим первые 5 из них (оставшиеся 4 рассмотрим в следующей статье):

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

Да, назовем этого человека «ухо». Это может быть муж, жена, коллега, брат, сестра, друг, подруга, однокурсник, сосед – да, собственно, кто угодно. Этот человек должен хотеть вам помочь и у него должно быть достаточно времени для вас и терпения, чтобы это делать. Его главная помощь будет заключаться в том, чтобы пытаться понимать то, что вы будете ему объяснять, и задавать вопросы, когда действительно непонятно.
Если вдруг так случилось, что вы никого не можете рядом найти, напоминаю, что мы живем в век ИТ, и вы можете воспользоваться скайпом, вайбером, whatsapp и т.д. для этого.. Если вы интровертный интроверт и удаленно никак, то заведите себе утку и объясняйте всё ей.
Это необходимо по двум причинам:

  1. Вы значительно лучше запомните и поймете материал, пока будете рассказывать / объяснять
  2. Вы будете прокачивать свой навык объяснения, который так нужен бизнес-аналитику

 

2. Узнайте, кто такой бизнес-аналитик. В подробностях!
Чем он занимается, зачем в этом замечательном мире существует, какие аналитики бывают, чем отличаются друг от друга, чем отличается от других ролей в разработке ПО (проектный менеджер, тестировщик, программист, продавец, продуктовый менеджер, …), какими качествами должен обладать, какие достоинства и недостатки есть у профессии, как выглядит карьерный путь, сколько аналитики зарабатывают. Познакомьтесь с одним-двумя аналитиками. Причем лучше, если они будут из разных компаний. Сводите их на обед или хотя бы на кофе и за полчаса-час расспросите про их работу, про то, что им в ней нравится, что нет, про то, как они стали аналитиками и т.д.
Когда вы всё это сделаете, вспомните предыдущий пункт и попробуйте объяснить вашему «уху», кто такой аналитик и, например, почему круто им быть.

Что почитать, чтобы все-таки узнать, кто такой аналитик (еще раз обращаю внимание, что это не заменит живого общения с представителями сей прекрасной профессии):

 

3. Узнайте, что вообще такое бизнес-анализ и что входит в эту область знаний.
Этот пункт – чуть проще  предыдущего, но, тем не менее, имеет смысл на нем остановится и копнуть чуть глубже. В частности, неплохо бы узнать, из каких частей/разделов состоит сфера “бизнес-анализ”, что хотя бы примерно находится внутри каждого раздела и как эта область знаний коррелирует с другими областями знаний в разработке ПО (в какую входит, с какими пересекается).

Что почитать о бизнес-анализе:

  • Бизнес-анализ, статья в Википедии
  • Business Analysis Body of Knowledge (BABOK) by the IIBA: Introduction, 2.1, 2.2, 2.4
  • Карл Вигерс, «Разработка требований к ПО»: часть 1, глава 1, «Разработка и управление требованиями»

 

4. Проведите честную самооценку по качествам, знаниям и навыкам.
К этому моменту вы уже знаете, кто такой аналитик и какими качествами он должен обладать, что должен знать и что должен уметь. Составьте собственный список на основе изученного материала, разбитый по этим 3-м категориям: качества, знания, навыки. Для каждого пункта списка выставьте значение по 6-балльной шкале, где 0 – полное отсутствие, а 5 – идеальное проявление (лучше и быть не может) того, как должен быть «прокачан» этот пункт у начинающего аналитика. Сделали? А теперь попробуйте сами себя честно оценить по каждому пункту. Честно! А какой смысл самим себе врать? Кстати, недооценивать себя тоже не стоит. Ну, если сильно переживаете за способность себя оценить, можно обратиться к коллеге, другу, жене, профессионалу, в конце концов, за помощью.


Если вы дочитали до этого места и по какой-то причине не можете составить такую табличку сами (я имею в виду колонку «параметр для оценки»), это, конечно, не очень хорошо, но я тут не для того, чтобы вас демотивировать. Тем более, вы можете захотеть просто себя перепроверить, так что я вам предлагаю составить её настолько полно, насколько сможете сами, а я в следующей части статьи поделюсь своими соображениями на счет этой таблички.
Что почитать по теме:

 

5. Протестируйте свой уровень английского, составьте план по его повышению и начните его выполнять.
Попробуйте прочитать главу из книги Вигерса на английском. Поняли больше 90%? Шикарно! Нет? Ноги в руки и на курсы, а лучше к репетитору. С репетитором протестируйте ваш словарный запас, вашу способность понимать устную и письменную речь, вашу способность писать на английском и говорить на английском. И потом вместе с репетитором составьте план вашего развития. Задача №1 (если она ещё не выполнена): уметь читать на английском нетехнические и технические тексты и понимать их практически без словаря. Задача №2: уметь вступать на английском в переписку.
Добавьте в таблицу выше английский язык и также выставьте для него «желаемый» и «фактический» уровни.

Что почитать по теме:

 

Предлагаю тут пока приостановиться. Этих пяти пунктов вам должно хватить на первое время, а я пока допишу оставшиеся четыре. Как видите, не всё так сложно, если начать раскладывать по полочкам. Нужны мотивация, упорство и время.
Я буду рад услышать обратную связь на то, с чего я предложил начать, и, конечно же, ваши вопросы. Может, подскажете ещё толковых источников по каждому из пунктов? Пожелания по продолжению тоже принимаются.

 

Upd [21.11.2016]. А вот и продолжение статьи.

 


Юрий Веденин

директор и тренер учебного центра ITMINE, директор UXpresso

 


24 Октября, 2016


Комментарии к “Как подготовить себя к тому, чтобы стать аналитиком в ИТ?”
  1. Юрий, спасибо за статью! Давно в прошлой жизни общалась со многими желающими стать БА, видно эта тема все еще актуальна. 

    Видно вы уделяете очень много внимания скилам и подготовке. Я бы к людям задающимся вопросом — хочу стать аналитиком, подходила бы с начала с вопросом «почему? — the magic WHY question» Этот вопрос кстати является ключевым началом любого анализа. Если человек не знает почему он хочет быть аналитиком, все скилы, подготовки и книжки ему пользы не принесут. Знаю по себе :)

    The WHY может быть — мне кажется это круто, хочу в командировки ездить. или «Маша сказала что это легкая и крутая работа». Также, часто помогает в the WHY question выяснить, что же человек любит делать и почему он думает что эта работа ему подойдет. Например, на этом этапе часто выясняется, что человек не любит писать документы. Даже если он выучит моделирование, быть аналитиком и не любить писать документы будет сложно. Я за то, чтобы люди свою работу любили, и тогда недостаток скилов в какой-то области не помеха — это все при желании можно развить. А без мотивации и любви к своему делу это будет сделать сложно.

    • Евгения, вам большое спасибо за похвалу и особенно за развёрнутый комментарий! Вы абсолютно правы. Я как будто неосознанно упустил это из виду, посчитав, что оно как бэ и так понятно (: Но факт остаётся фактом — упустил ооочень важную вещь, без которой это всё даже и начинаться не должно. Кстати, когда-то давно здесь же на форуме нашего сообщества, мы подымали такой вопрос («Почему это круто быть бизнес-аналитиком..» или что-то типа того). И я как-то уже не раз на него ссылался, так что надо будет просто поднять эту информацию, слегка освежить и тоже, наверное, оформить в виде статьи или чего-то такого.
      Что касается того, чему мы уделяем внимание, то вы правы, после того, как решен вопрос с мотивацией («я хочу стать аналитиком, потому что [вставить нужное], и я точно знаю, кто это такой…»), после того, как понятны вопросы соответствия качеств (не скиллов), которые прокачиваются ооочень долго (или не прокачиваются вовсе?), мы переходим к знаниям и навыкам. И именно на них я и делал упор в статье. 

      • Юрий, спасибо за ответ! Я очень часто и в работе моей теперешней, и в жизни слышу — ну почему это уже понятно давно, надо теперь разобраться что и как. И, опять же, из опыта часто выясняется, когда немного копнуть в the why, очень многое проясняется. Например, как может человек действительно знать почему он хочет стать БА, когда имеет мало понятия что БА профессия из себя представляет? 

         

  2. Ахахаха, Юра, ты молодец!=)) По-хорошему статью можно было назвать «5 признаков того, что вы не готовы стать аналитиком: практическое приложение». По сути, ты предлагаешь людям стать аналитиками, чтобы стать аналитиками. В итоге можно в каком-то приближении примерить на себя эту роль еще задолго до всех этих ваших курсов. Да еще и в таком экскурсионном лайт-режиме. Отличная статья!

    • Быстрый ответ на твой комментарий «не, ну а чо?» (: 
      Да, ты прав, я практически за learning by doing. Не полностью, конечно, но, тем не менее. Если кто-то с помощью этой подготовки подготовится настолько, что потом сам сможет пойти на стажировку или устроиться сразу на работу без всех этих ваших курсов, то и хорошо. Если этот кто-то с помощью этой подготовки подготовиться так, что потом у него хоть насколько-то повысится продуктивность прохождения курсов, то тоже хорошо. Ну, вот как-то так (:  

  3. Так, надо еще какой-то конструктив принести. Ок, вот что я скажу, не совсем по теме статьи, но в глобальные задачи (облегчить жизнь потенциальным курсантам и себе) попадает на 100%. Мне кажется, что тему различий между бизнес-анализом, бизнес-аналитикой и прочими блаблабла-аналитиками надо раскрыть на табличке и прибить ее прямо над хедером сайта. По моим ощущениям, даже работающие в IT далеко не всегда представляют это. Ну а неайтишники даже название роли правильно запомнить не могут зачастую. Как-то так.

    • Я что-то не замечал такого повального «непонимания», но.. у меня проф-деформация, и я это понимаю. Вот прям для этой задачки, если она имеет место быть, я бы предложил всё-таки немного другое решение: поручить распространение этих «тайных» знаний всем аналитикам нашего сообщества (: да и не только нашего.. но нашего в первую очередь (:

  4.   Юрий, прежде всего, спасибо Вам за то, что Вы делаете. 
      Минимально поделюсь своим опытом, возможно, в чём-то пригодится.
      В общем, уперся в потолок на работе, вырос до предела и стало неинтересно. Сел и составил список: что нравится, что не нравится и какие знания хочу преобретать. Поинвестигейтил и выбор пал на БА в ит. Немедленно сел изучать тему. Через пол года приняли на работу. До сих пор не понимаю, как проскочил. За плечами были: курсы, вигерс, статьи, вебинары. Ну и рвение, кто еще согласится с хорошего поста уходить на зп меньшую в 3-4 раза.
      Поставили сразу на очень большой и сложный проект.
    С чем столкнулся:
    1.После обучения и поднятой информации, написание документов стало панацеей. Остальные компетенции БА отсеялись на второй план. Проблема наблюдалась у всей группы при дальнейшем общении с теми, кто пробился. Прочитал Психбольница в руках пациентов и понял, что нужно было начинать с этой книги, а не с Вигерса. 
    2.На практике, всё чему учился, не соответствует действительности. Все книги и курсы отражают идеального БА.  Половина изученного материала была понята не с той стороны. Остальная половина вообще жестко деформирована на практике.
    2.1.Как выяснилось, у многих компаний нет корпоративной этики в документах и разработке. Так называемый «херак-херак и в продакшн». Беда для новичка. Сваливается задача, ищешь шаблоны и как это делать. Все шаблоны из учебников не подходят. Разработчики не любят читать либо шаблон не подходит под их понимание.
    2.2.Отсутствие технического бэкраунда. Первый месяц не понимаешь, что говорят: сип, прокси, мержить, гибернейт…Знакомство с ребятами и расстрел вопросами. Приходит понимание кто и чем занимается, и на кого вешать таски.
    2.3.Прототипирование. Невозможно рисовать морду большой сложной программы без технического бэкграунда. Периодически тыкают этим в лицо. Сильно демотивирует делать что-либо. Решение: sql девлопер, смотрю какие поля в базе и, на основании этого, рисую в акжуре. Неплохо понимать, что ребята могут использовать повторно. Знать библиотеку.
    3.Тестирование. Без нормальных документов невозможно обеспечить качество. Обучился на тестирование веб приложений. Плюсы: большее понимание, как работает веб. Минусы: скинули на плечи тестирование.
    4.Очно обучил несколько сотен пользователей. Тут проблем не возникло.
    5.Подготовка артефактов для нового релиза. Извращенные документы, которые понятны заказчику.
    6.Обоснование присутствия БА на проекте. Сильно демотивирует. Как разгребать и сводить в минимальные таблицы сотни-тысячи страниц замудрёных постановлений и законодательство – никто не хочет. Как решать вопросы с заказчиком – адекватно ни у кого не получится. Но, как только необходимо всю проделанную работу передать в разработку без конкретных указаний кому, что и как делать – сразу вопросы к отсутствию тех бэка у БА.
    Итого за 7 месяцев:
    •Понимание кто и что делает; джира; конфлуэнс; акжур; общее понимание как что работает; HTML5; CSS; консоль; начало курса на джавараш для понимания принципа ОО языков; желание изучить ООП, UML, SQL…
    •Как надо правильно!? Ни одного хорошего документа, только безобразные гибриды. Нет системного подхода. Понимание, если одного поставят на проект, не смогу выдать что-то дельное…Я безнадёжен, Карл :)
    •Лёгкое уныние. Никто не хочет делать правильно и внедрять новый единый стиль и этику. Большая загрузка, не остается времени на прокачку. Как в таких условиях вырасти профессионально, а не винегретом, который потом никому не нужен? 
    Выводы: хорошему БА очень нужен технический бэкграунд. Нельзя браться за всё – не сделаешь ничего. Наверное, чтобы стать настоящим крепким БА джуном, человеку без опыта в ИТ, надо года 1,5-2 усиленной работы.

  5. Вводная: Судя по вашему рассказу в компании нет практики, культуры или возможности прикрепить вас к ментору, который бы первое время вас направлял и помогал (это идеально было бы для начала). Вас просто сразу кинули в гущу событий. Но раз 7 месяцев уже прошло, то значит вы уже втянулись  не утонули. Теперь можно попробовать осознать, что идет не так и как с этим быть дальше.
    Ну что поделать, и такое бывает, и со мной было.
    Так вот при всей вашей фрустрации от сложности проекта, для вас только плюс быть на сложном проекте, где требуется много разных знаний и сильно прокачаться, так как чем больше вы сейчас узнаете, тем профессиональней вы станете, тем весомей будет ваш опыт, тем легче будет в будущем.
     
    1. В ИТ основной аутпут БА это требования (Спеки или пользовательские истории). Очень часто в ИТ БА активность подогревается ввиду необходимости обеспечения команды работой. Нет требований — команда подвисает. Другой вопрос чего вам не хватает? Ведь от вас зависит какие техники анализа вы выберете для выполнения ваших задач. Если нет в вашей фирме или проекте, какой-то принятой практики, то БА сами определяют какие техники выбрать для выполнения определенных задач. Ну конечно помним про здравый смысл, эффективность и время для выполнения задачи.

    2.
    Сложно комментировать, но могу сказать, что во многих компаниях, и даже часто в пределах одной компании, подходы к бизнес-анализу и документам расходятся. Тут все зависит от требований, профессионализма, целей людей конкретного проекта, отдела. Имея опыт работы в разных фирмах (продуктовая, аутсорс, выделенные команды) подходы в документировании часто различаются. И я как аналитик шлифую свои практики и шаблоны документов каждый раз под команду, конечно какие-то вещи неизменны, но когда приходишь в новую команду или проект есть пару особенностей, которые влияют на выбор подхода в работе:
    2.1. Новый проект — можно предложить свои правила, техники и работы аналитики, шаблоны документов если нет принятых в компании, но будьте готовы все аргументировать.
    2. 2. Существующий проект- зависит был аналитик или нет
    2.2.А БА был на проекте — значит анализируем как все было устроено, и пытаемся улучшить если есть необходимость
    2.2.B Не было БА никогда на проекте. Всегда кто-то из команды или клиентов писал требования — тут стоит оценить качество, шаблоны и подходы — если видите что все не годиться, смело ставьте вопрос ребром, что такое качество требований нужно повышать и предлагайте свои решения. Но не забудьте о том, что есть команда, которой тоже нужно будет привыкнуть к вашим требованиям, поэтому советуйтесь и показывайте команде свои идеи и примеры, решайте вместе. Обучайте клиентов, повышайте культуру работы над требованиями. Ведь в конце концов, команда по вашим требованиям будут реализовывать, а клиент апрувить.
    2.1 Создавайте свою «этику», разрабатывайте свои шаблоны под нужды проекта. Инициатива наказуема. Тем более много готового уже наработано, стоит только взять и адаптировать для проекта.
    2.2 Знакомься с командой. Не стесняйся задавать вопросы кто и что делает, спрашивай что почитать для развития, попроси тех лида дать тебе вводную. Ты же еще не волшебник, а только учишься. Узнай процесс работы самой команды, кто и что делает, какими тулами работает. Изучи свой домен разработки и команды.
    2.3 То что тыкают в лицо это плохо, попроси разрешения поставить себе базу и обоснуй надобностью. Изучи основные таблицы из которых нужно будет брать данные и минимальные запросы. Я считаю что с базой нужно уметь работать и жаль, что на курсах БА нет вводной по базам. Нужно быть гибким и подстраиваться под проект, это очень важно. Мне в свое время пришлось поставить Intellij IDEA, IBM DB2, Bitbucket, Teamcity, Sourcetree, WINSCP и другие тулы и начать делать вещи вообще не типичные для БА. Но такова реальность, не всегда можно сказать — я это не умею и не готов учиться. Лучше сказать — я попробую разобраться. А сложного ничего нет.
    Пусть расскажут тебе ребята, что полезно знать, ты ведь поймешь, но тебя нужно ввести в курс дела. Организуй с ними митинг и пусть они расскажут, что ты должен знать. Создай список и с ними согласуй.
    3. Свой продукт, который ты описывал в требованиях хорошо тестировать, хуже стать тестировщиком. Но UAT делать всегда нужно, это в норме. Другой вопрос сколько по времени это занимает, и какое погружение в это нужно. Но сделай так, чтобы тебя не сделали постоянным тестировщиком.
    4.  Весомый плюс для тебя.
    5. Даже интересно, что там за документы такие.
    6. Для этого мы и нужны тоже. Но у тебя же есть свое мнение так? Напоминай о нем.
     
    Выводы:
    У тебя идет все хорошо, многому учишься и задаешь правильные вопросы.

    • Создавай свои документы и стандарты, которые можешь представить потом и поделиться с другими в компании. Не нужно никого ждать, но желательно иметь поддержку и тех кто готов помогать.
    • Открыто говори о проблемах. Я обычно создаю презентацию с пунктами проблем и решений, делюсь с командой или клиентом. Можно проблемы выносить на ретроспективы.
    • Было бы неплохо найти ментора БА, который бы направлял, идеально если есть такой в компании.

    По поводу технического бэкграунда: да БА было бы хорошо знать многие технические вещи, но тоже зависит от проекта и команды, не всегда это так. Но лучше быть технически прокачанным.
    Время прокачки скорее зависит от конкретного человека и сложности проекта и сколько времени уделяешь для развития.
     
    Удачи!
     
     

Добавить комментарий
Также Вы можете войти используя: Facebook Google