Вы тоже хотите в IT? В этой статье я поделюсь, как можно поменять сферу деятельности (или обрести новую сферу вдобавок к уже имеющейся) с науки на аналитику и присоединиться к увлекательному миру IT. Я расскажу про знания и навыки, которые пригодятся начинающему аналитику в первую очередь, а также ключевые ошибки.

Наука — это сфера исследовательской деятельности, направленная на получение новых знаний о природе, обществе и мышлении. Современные методы научных исследований основаны на собирании, описании, анализе, обобщении и объяснении фактов, систематизации полученных знаний. В отличие от прикладных видов деятельности, результат которых известен заранее (результат работника IT‑сферы — программный продукт), научная деятельность — дает начало нового знания. Для ученого крайне важны аналитические способности для получения в конечном итоге этого нового знания. Исследователи используют весь математический и аналитический аппарат, что и современные аналитики сферы IT: бизнес‑аналитики, системные аналитики, и, особенно, data‑аналитики. Наибольшим спросом на рынке труда в целом и рынке IT‑специалистов в частности пользуются специалисты, обладающие знаниями на стыке специальностей и навыков. Например, инженер‑прочнист со знаниями 3D‑моделирования и умениями пользоваться пакетами конечно‑элементного анализа, физик‑ядерщик со знаниями языка программирования С++, исследователь в области экономики со знаниями методов статистики и теории вероятности. Эти правила нам диктует рынок труда, поэтому я расскажу о своем опыте смены сферы деятельности (или обретения новой сферы вдобавок к уже имеющейся), а вы сможете пройти по моим следам, чтобы оценить свои возможности.

О чем еще поговорим:

• Базовое образование аналитика и его роль;

• Ключевые навыки хорошего аналитика (мой чек‑лист);

• Распространенные ошибки начинающего.

Анализ — это один из ключевых методов исследования. Им пользуется каждый уважающий себя ученый. Поэтому у науки и аналитики есть прямая связь. В сферу IT я пришла с базовым инженерным образованием (и половиной аспирантской диссертации). К этому моменту у меня уже был опыт работы в команде, опыт разработки небольшой монолитной информационной системы, понимание требований ГОСТов в части оформления документации и разработки ПО, знания в области сбора и обработки экспериментальных данных. Негусто, но как есть. По моему мнению, ваше образование играет такую же роль, как внешний вид при первой встрече. «Встречают по одежке» — в резюме «одежкой» является строчка об образовании. Каких навыков остро не хватало? Опыта общения с заказчиками. Кажется, ерунда? Но нет, это крайне важный навык, который сбережет ваше время, время команды, избавит от ненужных задач, сбережет нервы и осчастливит самого заказчика. А еще я никогда не проектировала интерфейсы и даже не задумывалась насчет user‑friendly дизайна.

Развиваться мне очень хотелось, поэтому первые несколько месяцев я как губка впитывала каждое слово, не пропускала ни одной встречи с коллегами по команде (тимлид, архитектор, коллеги‑аналитики, дизайнер и т. д.) и задавала вопросы при удобном (и неудобном) случае. А вечерами зависала на разного рода бесплатных курсах по аналитике. (Опять же, будет нелишним прикрепить очередной дипломчик к резюме).

Первое, что нужно понимать начинающему аналитику — цикл разработки программной системы, т. е. как рождается ПО. Анализ требований → Проектирование → Разработка → Тестирование → Поддержка → Анализ требований… и так по кругу. Будет это гибкий подход к разработке, например, Agile, когда за ограниченное время (итерацию), вы с командой проходите по всему циклу и в конце итерации (скажем, 2 недели) выдаете заказчику новую кнопку с классным функционалом. Или это будет более классический Waterfall‑подход, когда цикл разработки занимает год и вы как черепахи ползете от анализа требований к проектированию три месяца… зависит от компании. Конечно, большинство компаний пользуется гибкими методологиями сегодня, а вот моя альма‑матер познакомила меня только с классическим «водопадом». Да‑да, на нем все еще работают НИИ (научно‑исследовательские институты) по государственным контрактам. Ничего плохого в этом нет, просто каждому свое.

Второй момент — монолитная и микросервисная архитектура. Монолитная архитектура — это та, которой меня учили в университете отцы‑основатели эпохи PHP и MySQL. Это традиционная модель разработки ПО, где единая основа кода используется для нескольких различных бизнес‑функций. Все настолько переплетено внутри монолитной архитектуры, что изменения возможны лишь частично и затратно по времени, поскольку даже малые изменения затрагивают большие части кода. Другой подход к архитектуре, с которым я столкнулась на практике, — на основе микросервисов. Он подразумевает, что ПО состоит из небольших независимых компонентов (сервисов). Каждый сервис выполняет свою функцию, в том числе бизнес‑функцию, и общается с другими сервисами через четко прописанные правила. Это изменяемый, масштабируемый подход. Сервис может быть независимо развернут или обновлен по мере необходимости. На практике используются оба. Монолит себя не изжил по причине того, что в нем есть свои преимущества и своя ниша IT‑рынка, например, небольшие информационные системы для малого бизнеса, приложения, которые выполняют простую четко определенную функцию. Микросервисы чаще используются в больших системах со сложным функционалом, с непредсказуемой нагрузкой и на данный момент очень распространены.

Третий пункт сегодняшнего списка — базы данных. Здесь я, к счастью, как рыба в воде. Лично мне пригодились знания реляционных баз, написание разного рода SQL‑запросов (от простых до вложенных), сущности и их атрибуты, построение ER‑диаграмм, нормальные формы (первые три, больше не нужно). SQL — язык оперирования со множествами. Если вы знакомы с теорией множеств в математике, то будет просто. Так, например, оператор INNER JOIN выдаст пересечения множеств данных, а FULL JOIN — их объединение.

Четвертый гость — нотации. Пожалуй, главная нотация для аналитика — это BPMN. Суть не в четком знании, что какой‑то квадратик означает, а в удобном схематичном представлении бизнес‑процесса. BPMN является простой и наглядной нотацией, понятной даже новичку. При постановке задач на разработку очень удобно рисовать BPMN‑диаграммы. Именно поэтому эти диаграммы пользуются популярностью. А вот коллеги‑разработчики любят UML за его универсальность, он совместим с различными языками программирования, и им описывают различные процессы, а не только касаемо бизнеса. Поэтому и аналитику полезно владеть UML.

Пятый — сбор требований. Основные типы требований: функциональные и нефункциональные (неожиданно, правда? ?). К функциональным относят то, что должна уметь система. Пример: перевести деньги другому человеку через приложение банка. К нефункциональным относят технические моменты, например, на каком языке разработать приложение, на каких устройствах оно будет работать и т. д. Но в сборе требований ключевым является общение с заказчиком. Здесь я бы дала практический совет от себя: вся переписка должна идти под контролем лида (руководства). Самое простое, что может сделать заказчик, это прийти к аналитику и сказать: «Хочу вот это». А самое простое, что может в этом случае аналитик — поставить задачу на разработку. Так делать не надо. Задача глобального планирования (и оплаты выполненных работ) не входят в сферу аналитика. Взаимодействуйте с руководителем (тимлидом, проджект‑менеджером, если они у вас есть). И второй совет: всегда имейте письменное согласование требований с заказчиком. Чтобы было чем ответить на: «Мы, вообще‑то, так не договаривались» ?.

Пункт номер шесть — BI‑инструменты. Инструменты составления отчетности. Цифры не всегда наглядны и анализируемы, за визуальную составляющую отвечают графики и диаграммы. Самый простой инструмент аналитики — диаграммы в Excel. Простой инструмент, всегда под рукой. Для более продвинутых есть Power BI, Tableau, Яндекс Datalens, Qlik.

Семь — UI/UX. Проектирование пользовательских интерфейсов. Для интерфейса удобство пользования важно не меньше, чем внешний его вид. Существует отдельная должность дизайнера интерфейсов. Но часто в качестве дизайнера используют (напрягают) аналитика. Кроме того, при наличии в компании дизайнера, аналитик все равно с ним плотно взаимодействует.

Теперь перейдем к выбору компаний и ошибкам новичков. Каждому из нас нормально бояться перемен и вполне естественно, когда не знаешь, с чего начать. При поиске вакансий обращайте внимание на описание обязанностей. Сразу ошибка номер 1 — не пользоваться поисковиком. Читайте, если чего‑то не знаете. А еще следите, чтобы перечень обязанностей не был слишком обширный (и дизайны рисовать, и техническим писателем подрабатывать, и в код залезть, чтобы исправить баг).

Ошибка 2 — хотеть сразу в Яндекс. При слове «работать в IT» в голову приходят Сбер и Яндекс. Компаний много, ищите себе по душе. А если еще предметная область совпадает с вашими желаниями, то это не работа, а праздник какой‑то. Если вы ничего не знаете о компании, то найдите ее в социальных сетях и познакомьтесь поближе с ее ценностями, предметной областью, основными заказчиками и корпоративной культурой.

Ошибка 3 — ответить на все вопросы собеседования, при этом не задать своих. Интересуйтесь: Что за проект? Почему открыли вакансию? Какие возможности роста сотрудника в компании? Испытательный срок?

И вот вы получили свое заветное место и первое время на новом проекте… Не знаете, с чего начать? Несколько советов:

1. Обязательно изучите свой проект и его предметную область. Для этого существует документация, поисковик, артефакты (словарь терминов, описание API, ER‑диаграмма, CJM — путь клиента, в конце концов, тестовый контур, где можно «потыкать» кнопочки);

2. Фиксируйте договоренности после всех митингов. Обсуждайте зону своей ответственности;

3. Расставляйте приоритеты, а также просите помощь тимлида (руководителя) в приоритизации своих задач;

4. Не делайте то, чем заниматься не должны.

Пожалуй, это все, чем я могу коротко поделиться из своего опыта перехода в IT. Прокачивайте себя, будьте уверены в своих силах и успехов!