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

Как дела? Надеюсь, подготовка идёт полным ходом? А то ведь, как говаривал дяденька Брюс Ли, “Preparation for tomorrow is hard work today”. Согласно нашему плану, вы должны были уже как минимум найти «ухо», узнать в подробностях, кто такой бизнес-аналитик, что такое бизнес-анализ и что входит в эту область знаний, провести честную самооценку и протестировать свой уровень английского. Если это так, то я думаю, продолжение сейчас придется как раз кстати. Приготовьте себе чашечку чая или кофе…

Напомню, весь список по подготовке у нас выглядит вот так (как бы на что-то намекая, я вычеркнул первые 5 пунктов):

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

Что ж, давайте рассмотрим в деталях последние четыре шага из списка выше:

6. Получите (базовые) знания по ИТ и разработке программного обеспечения (включая процесс и подходы к разработке ПО).

Этот шаг я бы разбил как минимум на две части:

Первая, скорее, касается компьютерной грамотности. Для её освоения, конечно, в идеале, нужно поучиться на какой-нибудь «айтишной» специальности, а потом поработать в ИТ-компании, чтобы всё прочувствовать на практике, но, к сожалению, не у всех есть такая возможность… поэтому приходится искать обходные пути, которые, конечно же, не дают максимального эффекта, но хоть как-то приближают вас к цели. На самом деле, если вы можете себе это позволить (поучиться на технической специальности + получить практику), то мой вам совет: непременно это сделайте.

Что можно сделать, если времени (или чего там вам не хватает) не так много:

1. Пройти онлайн-курс по основам компьютерной грамотности, программирования и т.д. Неплохим примером может быть бесплатный курс Computer Science от Stanford’а: https://lagunita.stanford.edu/courses/Engineering/CS101/Summer2014/about.
2. Начать осваивать термины и понятия в ИТ. Постепенно, шаг за шагом (а не всё за раз, ибо это бессмысленно). Вот первая версия списка (что уже лучше, чем ничего) того, что вам неплохо бы знать. А вот первая версия списка вопросов (его, конечно, нельзя назвать полным, но он даст вам отличный старт), на которые вам неплохо бы уметь отвечать самостоятельно, не заглядывая в гугл и не дёргая разработчиков.
3. В ИТ есть миллиард сложных тем, в которых может потребоваться разбираться, но одну для будущих аналитиков лично я хотел бы выделить отдельно и предложил бы посвятить ей какое-то время: концепции, на которых основано ООП (объектно-ориентированное программирование). Очень рекомендую разобраться с тем, что это такое, зачем было придумано и какие базовые принципы существуют.

Вторая же часть этого шага больше касается процесса и подходов к разработке ПО. Когда вы станете аналитиком, вы не будете работать в вакууме. Вы будете работать в ИТ-компании, в ИТ-отделе не ИТ-компании, как вольный боец или как-то ещё – не важно. Важно то, что вы будете частью какого-то процесса, кто-то будет вам предоставлять какую-то информацию, данные, задания, а кто-то будет этого ожидать от вас. Я глубоко убежден, что всем участникам процесса полезно (и даже важно) его знать и понимать, то есть представлять большую картину. Конечно, процессы и подходы бывают разными, но у них есть много общего (и именно это общее я и предлагаю вам изучить), и, понимая хотя бы один из них, вам легче будет понять другие и любые их вариации. Это знание необходимо по нескольким причинам:

1. Практически невозможно со 100% вероятностью предсказать, какую именно часть будущего процесса будет захватывать ваша зона ответственности, поэтому неплохо бы вам знать как можно больше про все части.
2. Какую бы часть ваша зона ответственности не захватывала, вы будете гораздо более эффективными, если будете знать, что происходит до того, как вы вступаете в игру (это позволит вам лучше вступать, правильно оговаривая, что должно быть на вашем «входе»), и что будет происходить после (это позволит вам правильнее готовить ваш «выход»).
3. Существующие процессы разработки ПО в каждой конкретной компании могут сильно влиять на то, как именно вам надо будет выполнять свои обязанности как аналитику: на форму документации, её наличие, способы, частоту и формы коммуникации с заинтересованными лицами на проекте, сферу ответственности на проекте и т.д.

Кто-то из вас будет первое время работать на этапе разработки требований и только на нем. Причем на вход к нему будут поступать уже готовые бизнес-требования. А кого-то могут сразу поставить заодно на этап подготовки коммерческого предложения, или вообще отправить к заказчику изучать текущее положение его дел, или поставят на поддержку готового продукта, где надо будет отвечать на поступающие запросы на изменения, вопросы пользователей и т.д.
Кто-то из вас будет работать по классическим моделям, кто-то по гибким методологиям, кто-то по «у нас своя уникальная модель»…
Конечно, вы сможете изучить и изучите все эти особенности, когда устроитесь на работу, для того, чтобы правильно выполнять ваши обязанности, но как вы думаете, сколько у вас займет времени изучить это с нуля, а сколько – обладая знаниями про общие принципы, подходы, процессы и т.д.? Вы уверены, что вам больше нечего будет изучать на своем первом месте работы и от вас не будут хотеть этих знаний «по умолчанию»?
Что почитать о процессах и методологиях разработки ПО:

1. К сожалению, не могу порекомендовать более-менее легковесные книги по методологии Waterfall (если у вас есть идеи на этот счет, напишите, пожалуйста, в комментариях), но советую изучить ее обязательно, как базовую модель, например, по статьям в интернете.
2. Асхат Уразбаев — Краткий обзор методологии Scrum
3. Хенрик Книберг — Scrum и XP. Заметки с передовой (или в оригинале Henrik Kniberg — Scrum And Xp From The Trenches)
4. Короткие и средние по длине статьи в интернете на тему других процессов и методологий разработки ПО, например, RUP.

7. Освойте основы моделирования.

Ещё раз повторю, чтобы вы не теряли время на поиски по предыдущим статьям: под моделированием здесь я подразумеваю построение визуальных моделей, причем знание языка или нотации моделирования (UML, BPMN, ARIS, IDEF, …) не так важно, как само умение строить эти модели в целом (или в са-а-амом крайнем случае – умение правильно читать модели).
Моделирование – это процесс познания непонятных нам понятий (объектов, концепций, процессов, алгоритмов и т.д.) через построение упрощенных образцов изучаемого понятия (моделей). Моделирование – это навык, который существенно упрощает вашу жизнь аналитика, а иногда без него вы вообще не сможете обойтись.
Я предлагаю вам выбрать какой-нибудь язык для изучения (например, UML) и, как минимум, понять, что он из себя представляет, что с помощью него можно делать, какие типы диаграмм можно строить, попробовать читать и строить хотя бы базовые диаграммы. Язык UML в качестве базы хорош также и тем, что в процессе его изучения, вам придется понять, что такое ООП (а про важность понимания этого я уже писал выше).
Если вы решите выбрать для ознакомления UML, я вам предлагаю прочитать
одну (а лучше несколько) из следующих книг:

1. Muska and Lipman — UML for the IT Business Analyst
2. Podeswa H. — UML for the IT Business Analyst (да, это две разные книги)
3. Буч Г., Рамбо Д., Якобсон И. — Язык UML. Руководство пользователя (2-е изд.)

8. Узнайте актуальную ситуацию на рынке труда.

Откройте сайт по поиску работы, актуальный для вашего гео-региона. Например, это может быть http://jobs.tut.by. Может, быть более специализированный ресурс, например, http://dev.by.
Если вы сейчас сами на одном рынке, а метите на другой (например, собираетесь переехать в Штаты («БА=Бизнес-аналитик в Америке») или Голландию «Интервью. Наши в Голландии»), само собой, изучите ситуацию и тут, и там, и, желательно, на соседних рынках.
Выберите 10-15 вакансий и внимательно их разберите: кого именно ищут компании, какие требования предъявляют к кандидатам, какие условия предлагают, чем надо будет заниматься и т.д. Сравните это с тем, что вы уже знаете про бизнес-аналитиков и про себя. Скорректируйте картинку своих знаний (теория vs реальность) и обозначьте для себя точки для развития.
Теперь найдите на этих же сайтах резюме аналитиков – тоже 10-15 будет достаточно. Посмотрите, что они про себя пишут, чего они ищут, какое у них образование и т.д. Это примерный образ тех (не все, конечно), кто будет претендовать на те же вакансии, что и вы. Вам надо как минимум быть не хуже, а лучше, простите, лучше (:
А теперь найдите в профессиональных соц. сетях ещё 10-15 аналитиков с опытом, тех, у которых хорошо заполнен профиль. И уже посмотрите, какой путь они прошли, какое у них образование, сколько и где работали, чем занимались.
Снова скорректируйте картинку своих знаний (теория vs реальность) и обозначьте для себя точки для развития. Найденные профили никуда не девайте, они вам ещё пригодятся.
Где смотреть:

1. http://job.tut.by (http://hh.ru, http://dou.ua) 
2. http://dev.by
3. http://glassdoor.com
4. http://linkedin.com

9. Поговорите с парой живых аналитиков и с парой не-аналитиков.

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

1. в сообществе analyst.by (facebook группа, группа Вконтакте) или в вашем локальном сообществе, если вы не в Беларуси;
2. поиском в LinkedIn, Facebook, Вконтакте;
3. через работающих в ИТ друзей.

Вы ведь и правда немного спешили, когда шли по этим пунктам? То там, то сям пропускали какие-то шаги, особенно, когда было непонятно, надо ли вот прямо это уже знать и на каком уровне, а какие-то вещи вы узнали, но в голове они полностью не закрепились. Это нормально. Вы лучше вспомните себя и свой уровень знаний до того, как вы прошли (выполнили инструкции) хотя бы несколько из этих 10 шагов. Вспомнили? То-то же!

Но это ещё не всё.. прежде, чем двинуться дальше, давайте остановимся и сделаем две важные вещи:
Вещь номер раз – это личный план развития. Как я и написал выше, вы теперь гораздо лучше многое знаете и понимаете, но ещё больше вы теперь (осознанно) не знаете и прекрасно понимаете, что и в бизнес-анализе, и в области процессов и методологий, и в английском, и в моделировании ещё есть куда стремиться.
Кстати, помните, в первой части мы говорили про табличку качеств, знаний и навыков для самооценки и я обещал поделиться своими соображениями? Делюсь (: Вот первая версия такой таблички (кстати, она открыта для комментирования.. специально для того, чтобы довести её до ума краудсорсингом с вашей помощью, так что буду рад, если все читатели этой статьи также посоветуют / откомментируют информацию, которая там содержится). Можете брать её за основу и дополнять своим пониманием реальности.
Так вот, теперь вы гораздо лучше понимаете, куда двигаться и, вероятно, какие шаги для достижения цели надо пройти. Так соберите эти шаги воедино и составьте себе хотя бы примерный план на ближайшие полгода того, как вы будете этого добиваться!
И вещь номер два…
Теперь, узнав всё то, что вы узнали и поняв, сколько ещё предстоит освоить, попробуйте остановиться и честно сами себе ответить на вопрос, подойдет ли это всё вам, так ли вы хотите стать бизнес-аналитиком? То ли это, чем вы хотели заниматься и на освоение чего вы готовы инвестировать свои ресурсы ещё как минимум полгода, а то и больше?
Да (а я надеюсь именно на этот ответ, но готов принять любой)? Тогда двигаемся дальше, нам предстоит ещё столько узнать и столькому научиться… (:

—

Юрий Веденин

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