Всем привет, с кем-то здесь мы еще не знакомы, исправляюсь: я — Якуб, тимлид отдела системного анализа в KODE.
Сегодня я хочу поделиться своей историей о том, как я попал в Системный анализ ⬇️

Начиналось все далеко не со стажировки. Изначально первую свою работу в IT я получил в роли QA в московской компании, отработал 1.5 года и устал от специфики, стало не интересно. Далее, в той же компании, мне предложили попробовать поработать Системным аналитиком, и меня втянуло. После двух лет работы аналитиком в Москве, я переехал в Калининград и в KODE.

➡️ Чем меня так зацепил системный анализ?

Возможно это связано с тем, что я переходил из роли QA, в которой мне тяжело давалась рутина. Кроме того, перспективы развития меня субъективно не привлекали на тот момент. Тогда руководство предложило мне три направления развития, из которых я выбрал системный анализ. В этой роли я увидел совершенно другой горизонт. В ней намного больше созидательной части и меня это вдохновило. Меня увлек процесс исследования требований, взаимодействие с заказчиками, понимание того, что именно нужно бизнесу и как это реализовать технически. В отличие от тестирования, где ты работаешь уже с готовым продуктом, будучи аналитиком, ты помогаешь его формировать с нуля. Это другой уровень ответственности и вовлеченности. Системный анализ дал мне ту самую искру — возможность постоянно развиваться, решать более сложные задачи и чувствовать свою значимость в команде и проекте.

Мне повезло, что в KODE я нашел команду, с которой мы всегда работаем на одной волне. Здесь я смог не только реализовать свои аналитические навыки, но и попробовать себя в управлении проектами и наставничестве. Со временем я стал тимлидом, и это дало мне новый взгляд на то, как выстраивать процессы, обучать новых аналитиков, делиться опытом и развивать команду.

Ставьте реакции, если пост был интересен.
Делитесь своими историями в комментариях о том, как вы попали в системный анализ! 💛

Самый популярный вопрос в начале карьеры: «Где получить опыт, чтобы меня взяли на работу?» ⁉️
Почти каждый специалист проходит через этот период и наша команда не исключение. Мы проанализировали наш коллективный опыт и подготовили несколько советов:

1️⃣ Ходи на стажировки. Любая стажировка станет важным шагом и ты поработаешь с реальными проектами под руководством экспертов. Они помогут погрузиться в реальную работу аналитика и понять, с какими задачами предстоит работать.

2️⃣ Посещай хакатоны для аналитиков. Это соревнования, в котором команды создают какой-то продукт (мобильное приложение, веб-сервис и т.п.) для решения проблемы, с которой столкнулся заказчик. Сейчас крупные компании, вроде МТС, Сбер или Т-банк, регулярно проводят хакатоны, особенно для студентов. Вы получите опыт, а если займете призовое место, то возможно и денежный приз или приглашение на собеседование. Это также возможность завести полезные знакомства.

3️⃣ Подумай над PET-проектами. PET-проекты – это проекты, которые человек делает для себя в свободное время. Это может быть анализ вымышленной системы или улучшение существующих процессов, будь то на уровне организации данных, автоматизации процессов или разработки документации. Твое умение решать задачи самостоятельно будет цениться работодателем.

4️⃣ Рассмотри для себя курсы. Многие образовательные платформы предлагают различные курсы для аналитиков, с практическими заданиями, которые потом могут встретиться в работе. Советуем ознакомиться с нашей программой Симулятора системного анализа, который симулирует реальную работу аналитика и поможет прокачать твои soft- и hard- скиллы. Симулятор даст вам практический опыт, актуальные навыки и понятные артефакты в портфолио, которые помогут пройти на позицию Junior.

Ставь реакцию, если этот пост был полезен 💚
И оставляй комментарии о своем пути в аналитике, что сейчас делаешь для того, чтобы набраться опыта⬇️

Анализ предметной области — дело непростое и требует особой внимательности. Как ни крути, именно от этого этапа зависит, насколько успешной будет разработка системы в целом. Однако часто можно столкнуться с типичными ошибками, которые мешают добиться нужного результата. Давайте разберемся, какие из них встречаются чаще всего:

1️⃣ Неполный сбор данных: аналитик может не учесть все аспекты предметной области, из-за чего важные детали остаются вне рассмотрения. Это может привести к необходимости корректировать систему на более поздних стадиях разработки.

2️⃣ Игнорирование требований заказчика: при недостаточном взаимодействии с заказчиком аналитик может упустить ключевые требования или неправильно интерпретировать их, что приведет к несоответствию решения ожиданиям.

3️⃣ Неправильное определение границ предметной области: аналитик может задать слишком узкие или слишком широкие границы, что повлияет на объем работы и финальный результат. Важно четко понимать, что включается в предметную область, а что выходит за ее пределы.

4️⃣ Недостаточный анализ нормативной базы: если законодательные и нормативные требования не были учтены на этапе анализа, проект может столкнуться с правовыми проблемами, которые потребуют значительных затрат на исправление.

5️⃣ Отсутствие документирования результатов анализа: если результаты анализа плохо задокументированы или вовсе не задокументированы, это приводит к разночтениям и ошибкам в последующих этапах разработки.

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

Если пост оказался для вас полезным и помог обратить внимание на важные аспекты анализа предметной области — ставьте реакции и делитесь своим мнением в комментариях! 1️⃣

В следующем посте мы подготовим для вас Чек-лист по тому, как анализировать предметную область правильно и без ошибок, не пропустите! 🔜

Когда в команде резко увеличивается число аналитиков, на проекте нередко начинается хаос — каждый работает в том стиле, который ему удобен, и не всегда эти подходы совпадают. Чтобы навести порядок, на помощь приходят оптимизация процессов и четкое распределения зон ответственности.

1️⃣ Первый и самый важный шаг - это унифицирование всех артефактов, с которыми работают аналитики. Это увеличит понятность артефактов, так как мозгу проще понимать структурированную информацию. Можно использовать шаблоны из интернета или при наличии устоявшихся правил на проекте создать свой собственный шаблон. Также, чтобы не забывать важные поинты в своих артефактах, можно включить чек-лист полноты артефактов в свой шаблон.

2️⃣ Далее нужно определить зоны ответственности каждого аналитика. Это можно сделать просто, закрепив фичи за тем аналитиком, который над ними работал. Однако могут возникать ситуации, когда один человек охватил практически все задачи. В таких случаях важно не перегружать его и передать контекст остальным членам команды. Это можно сделать как в письменном виде, так и через созвоны и обсуждения, чтобы равномерно распределить нагрузку.

3️⃣ Передача контекста также нужна, когда аналитик уходит в отпуск, на больничный или покидает проект. Это позволяет увеличить “bus factor” — то есть снизить зависимость проекта от одного человека, чтобы команда могла продолжать работать эффективно.

4️⃣ Когда артефакты унифицированы и фичи распределены, надо наладить процесс кросс-ревью. Для чего вообще нужно кросс-ревью у аналитиков? Кросс-ревью позволяет улучшить качество требований, избежать ошибок и улучшить шаринг контекста внутри команды. На кросс-ревью мы проверяем полноту артефактов, наличие всех крайних кейсов и логику принятых решений.

5️⃣ Чем больше аналитиков в команде, тем сложнее уследить за их состоянием и прогрессом. В таком случае можно назначить лида всей команды или определенного стрима, если в команде идет распределение по стримам. Лидом может стать человек с наибольшим контекстом на проекте либо самый проактивного члена команды. Такой человек будет отвечать за равномерное распределение задач между аналитиками, имплементацию и оптимизацию процессов на проекте, а также следить за состоянием аналитиков на проекте.

Оптимизация процессов - это часто сложно и ресурсозатратно, но результат превосходит все ожидания. Главное - начать и маленькими шажочками идти (а можно и ползти) к желаемому результату💜