☀️ Кто приходит работать в Системный Анализ? ☀️

В системные аналитики часто приходят из профессий, где уже есть опыт работы с IT-системами или бизнес-процессами.

☀️ Тестировщики, обладая опытом в выявлении ошибок и понимании принципов работы приложений, могут перейти в системный анализ, чтобы предлагать свои идеи и улучшать IT-продукты, а не только проверять готовое. Обычно это происходит, когда хочется роста в карьере, есть много предложений в процессе тестирования, которые с удовольствием используют коллеги-аналитики. Возникает желание попробовать себя с другой стороны, стать более значимой частью процесса разработки, а не только давать подсказки своим коллегам.

☀️ Технические писатели, которые создают документацию и инструкции, также могут стать системными аналитиками. У них как правило уже есть опыт в описании готовых систем. Для перехода нужно научиться собирать и анализировать требования к системе, глубже погрузиться в технические детали, развивать способность объяснять свою точку зрения другим участникам команды. Тесное сотрудничество с командой разработки поможет разобраться, что именно делает аналитик внутри компании. Технический писатель может начать изучать задачи аналитика со стороны и осваивать новые навыки, чтобы перейти на новый уровень.

Продолжение 👇

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

☀️ Ещё один путь в профессию - это рост внутри компании для тех, кому удалось поработать с IT-командой. К примеру, менеджер по работе с клиентами, участвующий в автоматизации бизнес-процессов, может заинтересоваться IT. Работая бок о бок с аналитиками, такой сотрудник получает представление об их работе и может захотеть сам стать частью IT-команды. В компаниях с собственным IT-отделом часто есть возможность для такого внутреннего перехода, особенно, если сотрудник показал свою заинтересованность, и самостоятельно смог освоить компетенции профессии.

Делитесь в комментариях, а откуда вы пришли в системный анализ?

Я пришла из ВУЗа, в процессе обучения по специальности, с пониманием, что писать код это вообще не моё, а вот писать требования к алгоритмам меня вдохновляет!

У программиста результатом работы является код и работающее приложение для пользователей. У тестировщика - тест-кейсы и приложение без багов.

Программисты и тестировщики могут сами все сделать. Ну с project-менеджером, который задач даст. Зачем аналитики? 👀
Знакомо? У кого так было - 👍
Меня это на старте карьеры немного тревожило и беспокоило. Я не понимала ценность в работе, которую буду выполнять.

Роль системного аналитика в разработке программного обеспечения часто остается за кулисами, но ее значение трудно переоценить. Он выполняет ключевую роль в проекте: определяет требования к системе и проектирует технические решения по их реализации.

От результата работы системного аналитика зависят все остальные шаги в проекте - и программирование, и тестирование. Самые дорогие ошибки в проектах бывают именно в результате плохой аналитики, ее отсутствия или из-за непроработанных требований.

Системный аналитик исследует потребности бизнеса и пользователей, анализирует бизнес-процессы, собирает требования и преобразует их в последовательные и структурные постановки задач для команды разработчиков.

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

Аналитик играет ключевую роль во взаимодействии между бизнесом и технической командой - это переводчик с языка бизнеса на язык программистов. Это требует хороших навыков в общении и взаимодействии с людьми.

Системный аналитик не просто собирает требования, он формирует фундамент всего проекта, влияя на его стратегическое направление и гарантируя, что разрабатываемая система будет отвечать как текущим, так и будущим потребностям бизнеса и его пользователей 🚀

Сегодня я хочу дать вам полный состав требований, которые могут быть включены в техническое задание (ТЗ) на разработку программной системы 👇

🟢 Самое важное про бизнес-контекст для ТЗ на разработку программной системы 🟢


🟡 Бизнес-требования:
Для чего нужна система - цель разработки, какие бизнес-задачи она должна решить.

Примеры: для CRM-системы бизнес-требования могут включать повышение удовлетворенности клиентов на 20%, ускорение процесса продаж и снижение времени на ввод данных на 30%.

Источник: заказчик или его представители, влияющие на финансирование проекта.


🟡 Бизнес-правила:
Правила, которые должна соблюдать система, включая законодательные нормы и корпоративные стандарты.

Например, для банковской системы это могут быть требования к безопасности данных и соблюдению нормативов Центрального Банка.

Источник: документы, законы, акты, регламенты, алгоритмы


🟡 Ограничения:
Возможности и бизнес-процессы, которые не будут поддержаны в системе, или будут поддержаны, с ограничениями.

Например, необходимость работы системы только на определенных платформах или невозможность интеграции с устаревшими базами данных.

Источник: заказчик или его представители, влияющие на финансирование проекта.


🟡 Требования пользователей
Цели и задачи, которые пользователь должен иметь возможность выполнять
с помощью системы. Сценарии взаимодействия пользователя с системой.

Например, в системе бронирования отелей это могут быть: возможность оценки отелей пользователями, возможность написания отзыов, возможность редактирования отзывов и другие.

Источник: Будущие или настоящие пользователи, сотрудники организации. Фокус-группа


🟡 User Story — история пользователя.
Могут быть сформулированы как ценность, решаемая проблема или новая возможность. Для формулировки используют шаблон "Я, как пользователь, хочу ______, чтобы _____________".

Пример: "Я, как маркетолог, хочу анализировать историю покупок клиента, чтобы предлагать персонализированные акции".

Источник: требования пользователей.


Сохраняйте и делитесь постом с коллегами-аналитиками 🔥 Продолжение в следующем посте 👇

🟢 Техническая сторона технического задания - самое важное 🟢

🟡 Функциональные требования
Описываются точные функции системы.

Например, для Интернет-магазина это может быть функция "Добавить товар в корзину", "Просмотр истории заказов".

Источники: Формулируются на основании бизнес-требований, бизнес-правил и ограничений, определенных ранее. Дополнительно могут проводиться исследования систем конкурентов и другие технические исследования.


🟡 Use Cases:

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

Источники: Формулируются по каждому функциональному требованию.


🟡 Нефункциональные требования
Определяются требования к качеству работы системы, такие как производительность, безопасность, масштабируемость.

Например, время отклика не более 2 секунд, поддержка одновременной работы 1000 пользователей.

Источники: бизнес-требования, бизнес-правила и ограничения, требования службы безопасности заказчика и другие.


🟡 Требования к архитектуре
Определяют структурные характеристики системы, такие как модульность, расширяемость, интеграция с другими системами. Разрабатываются архитекторами ПО, техническими руководителями, разработчиками и системными аналитиками.

Например: список баз данных, список приложений системы, схема взаимодействия сервисов на сервере.

Источники: все бизнес-, функциональные и нефункциональные требования к системе.



Это основное. Про то, что еще делают аналитики в рамках работы с требованиями к системам можно рассказывать больше и более детально по каждому пункту. А недокументированные системы в которых непонятно как и что сейчас работает - отдельный вид боли.

Аналитики не нужны? Программисты сами? Ну ок 😂

Грейд – это уровень или ступень в системе оценки и классификации должностей в компании. Проще говоря, это как ступеньки лестницы, где каждая следующая ступенька означает более высокий уровень квалификации, ответственности и, как правило, зарплаты.

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


Грейды системных аналитиков:

🟢 Младший системный аналитик (джуниор),
🟢 Системный аналитик (мидл),
🟢 Старший аналитик (сениор),
🟢 Ведущий аналитик / руководитель отдела.


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

Если вы уверены, что в вашей компании уже можете стать старшим аналитиком, то далеко не факт, что при переходе в другую у вас это получится.

Грейд может сохраниться или упасть. Это проблема? Нет. Это скорее всего рост. И я расскажу почему 👀

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

Во время собеседования сами кандидаты объясняли мне причины такого перехода:

🔹 Внутри компании я понимаю, что засиживаюсь. Вижу, что есть друзья, которые младше меня по должности, но при этом знают больше чем я, работают с более интересными задачами.
🔹 В вашей компании более крутые задачи и те навыки, которые я бы хотел больше использовать. Сейчас я их применяю не так часто, как хочется. Мне нравится…. Я вижу свой рост у вас.
🔹 У вас на позицию мидла зарплата выше.
🔹 Я хочу получить опыт работы в большом проекте.
🔹 Я устал и хочу немного отдохнуть (p.s. Такой ответ отпугивает! Не надо так!).

Если сейчас задумываетесь о переменах, то спросите себя в первую очередь “почему я хочу сменить работу?”. Ответьте себе честно. И исходя из этого ищите новые компании и проекты 🤝

Не бойтесь понижений в названии должности, если по факту это рост. Трудовая книжка с красивой историей это хорошо. Но опыт и рост заряжают энергией. И если вы понимаете, что это рост, то это будет очевидно и другим 😉

🟢 Ведущий аналитик / руководитель отдела

Здесь точно пригодится опыт работы от 3-х лет, ну или хотя бы от 2-х. Всё зависит от специалиста.

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

Предполагается наличие опыта сотрудничества с архитекторами, DevOps-инженерами, глубокое знание всех технических моментов связанных с проектированием.

Ведущий системный аналитик больше занимается взглядом на проекты сверху и ревью за своей командой аналитиков. Но в любой момент может включиться в работу, погрузиться глубоко в задачу и сделать всё сам.

Пример вакансии:
Ведущий системный аналитик, Хоум Банк



Куда дальше? 🧐

Как правило переход между руководящими должностями или погружение в технологии. Можно стать архитектором ПО, программистом, CTO (технический директор компании), открыть свой бизнес или уйти в консалтинг. Всё зависит только от вас и ваших амбиций.

Переход между уровнями требует развития технических навыков, получение опыта и непрерывного самообучения. Но… Реальным ключом к быстрому и успешному росту является нечто иное. Об этом поговорим в следующих сериях 😎

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

Приглашаю подробно познакомиться с профессией системного аналитика и пройти собеседование в безопасной обстановке, чтобы понять, на какие моменты в вашей подготовке важно обратить внимание!


📚 Собеседование на системного аналитика: подготовка на практике
📅 21 ноября, 19:00 Мск
🔗 ЗАРЕГИСТРИРОВАТЬСЯ


Что вас ожидает:
🔍 Погружение в профессию системного аналитика: зоны ответственности и ключевые навыки.
📑 Как создавать резюме, привлекающее внимание работодателей.
🕵️‍♀️ Рабочие советы и стратегии для моральной подготовки и успешного прохождения собеседований.
💼 Разбор реальных заданий по системному анализу и их решения.


Что я жду от вас:
✅ Активное участие и готовность к практическим заданиям.
✅ Предварительное осмысление ваших профессиональных целей.
✅ Вовлеченность и настрой на получение знаний.


Этот вебинар прекрасно подойдет бизнес-аналитикам, тестировщикам, техническим писателям и начинающим в IT специалистам, которые хотят стать системными аналитиками.

А для начинающих и опытных аналитиков он поможет понять, каких навыков сейчас не хватает, обновить резюме и проверить свои навыки на практике.

Готовы меняться и расти? Жду вас на следующей неделе онлайн! ❤️️

Что является результатом работы системного аналитика? 🔎

Системный аналитик играет ключевую роль в разработке и поддержке информационных систем. Он как исследователь: много работы по анализу информации, бизнес-процессов, потоков данных, взаимодействия сервисов, много анализа. От его деятельности зависит то, как будет реализована система.

Однако часто возникают вопросы о том, в чём заключается реальный вклад системного аналитика в проекты?

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

Пример:
Для Интернет-магазина он описывает, как покупатель может оформить заказ, как система обрабатывает платежи и как информация о заказе передаётся в службу доставки.

🌟Я хочу рассказать, почему именно документация, создаваемая аналитиком, является ключом успешного проекта, и какие навыки требуются для её эффективного создания и дальнейшего использования командой разработкой.

Документация на разработку программной системы — это не просто набор текстов и диаграмм.

Это фундамент, на котором строится вся работа над IT- проектом. Она помогает команде разработчиков понять задачи и цели проекта, а также является основой для тестирования и поддержки системы после её запуска.

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

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

Сама документация строится не на описании чего-то рабочего, что известно. Всё описывается с нуля, по сути из нашего технического воображения и жизненного опыта. Нам, системным аналитикам нужно придумать что будет в системе и как она будет работать.

На основе интервью с заказчиками и потенциальными пользователями мы должны точно угадать их желания и что нужно получить в конце разработки: как со стороны видимой пользователям, так и со стороны того, что будет внутри - алгоритмы, схемы хранения данных, порядок взаимодействия систем. И все эти ожидания мы фиксируем в документации как результаты анализа и проектирования.

Однако, документация полезна только тогда, когда она применяется правильно. Системный аналитик должен не только уметь создавать документы, описывающие работу системы, но и знать, когда и как их использовать. Это включает в себя умение организовать структуру документов, определение ключевых моментов для фиксации, а также способность адаптировать документацию под меняющиеся требования и условия проекта.

Как у вас на проекте с документацией?
❤️ - есть и всё идеально;
👍 - есть, но нет структуры в ней, требует улучшений,
😱 - нет
Делитесь своими впечатлениями о документации в ваших проектах в комментариях, тема горящая и актуальная! 😃

Люди в IT меняются быстро – теряются знания об IT-продукте. Как узнать о том, почему тот или иной процесс выполняется именно так, без поиска нужного разработчика и доступа к коду? Смотреть в документацию, которую надо создать.

В какой-то момент жизни IT-проекта остро встает вопрос документирования. Например, через 10 лет от момента запуска. Описать неописуемое, запустить процессы анализа и документирования – история внедрения системного аналитика в команду.

Рекомендую к просмотру мое выступление с конференции, где я рассказала о важности ведения проектной документации в компании, о процессе ее внедрения, и как заставить команду разработчиков помогать документировать решения.

🌟 Как мы процесс документирования внедряли

Интервью - это всегда сложно. Но к нему всегда можно подготовиться!

Хочу порекомендовать вам книгу, в которой системным аналитикам, разработчикам и архитекторам можно подсмотреть интересные задачи и расширить свою экспертизу в проектировании систем:

📚 Подготовка к сложному интервью
©️ Алекс Сюй

Наиболее интересные главы:

▫️ Общие принципы прохождения интервью по проектированию IT-систем
▫️ Проектирование хранилища типа «ключ–значение»
▫️ Проектирование системы уведомлений
▫️ Проектирование ленты новостей
▫️ Проектирование YouTube
▫️ Проектирование Google Drive

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

Внутри: архитектурные схемы взаимодействия, картинки, и доступное изложение от автора. Много рекомендаций по дополнительной литературе.

Мой обзор всех глав книги и ссылку на неё можно найти здесь.

#hwGetAnalyst

Доброе утро! ☀️

Конец ноября будет насыщенный и сейчас идет активная подготовка к нему. Следующая неделя начнется с того, что мы будем погружаться в задачу на проектирование интеграций - новый проект в канале! Пора возвращаться к разбору кейсов 😉


По порядку о важном:


🌟 Новый проект с 20 ноября (ПН)
Мы начнем знакомство с новой задачей на проектирование интеграций: логистический сервис, который помогает пользователям рассчитать самую выгодную стоимость отправления груза и оформить заказ в соответствующей компании.


🌟Практический вебинар онлайн 21 ноября (ВТ)
Практический онлайн-вебинар, на котором я расскажу про актуальные требования к системным аналитикам в 2023-2024. А также я проведу для вас тестовое собеседование!
Это отличная возможность попробовать свои силы для действующих системных аналитиков. А для тех, кто только собирается перейти в системный анализ, будет полезно узнать какие навыки предстоит подтянуть, какие знания структурировать, а какие получить.


🌟 До 24 ноября - предзапись на (ПТ)

Мы будем принимать заявки на программу “Системный аналитик: с нуля до опыта работы на проекте” (СА0) на специальных условиях - с бонусным доступом к программе обучения по проектированию (+1 полный проект). Теперь программу можно проходить в удобном темпе. Поступить на неё можно через собеседование.

Проект СА0 создан, чтобы помогать структурировать знания действующим аналитикам и помогать переходить в профессию системного аналитика из смежных и близких к IT-специальностей.


🌟 28 ноября - лайфхаки ChatGPT онлайн (ВТ)
Для тех, кто еще не использует младшего помощника в своей работе, я провожу практическое занятие, на котором покажу связки команд и инструментов, которые помогут системным аналитикам ускорить процесс их работы с помощью искуственного интеллекта.


Все остальные анонсы буду публиковать по мере их появления. На начало декабря готовим практический вебинар по интеграциям. А пока…


Желаю вам отличных выходных! Набираемся сил, чтобы войти в новую неделю полными положительных эмоций и энергии! ❤️

Работа в сфере IT:

😍 ожидание — список задач известен на ближайший спринт, никаких «влетов» от заказчика и внеплановых изменений в требованиях.

🤪 реальность — «спасибо, что живой» в конце каждого проекта.

Ну что, друзья, как там ваш понедельник? 😅😅