Когда все идет легко, то меня это напрягает. Значит я стою на месте, и не развивюсь. В этот момент я говорю себе - пора 🚀 И начинаются удивительные приключения... Так я уже почти 2 года непрерывно чувствую себя тупой. И страшно, и интересно 🤔

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

Знаете, иногда в шкафу есть старые вещи. Какие-то мы вообще не носим, потому что они вышли из моды, не очень нравятся, но занимают место. А какие-то уже старые и стёртые до дыр, но любимые и удобные. Шкаф захламлен привычным. И на внутренний вопрос "А могу ли я купить новую красивую одежду?" я раньше отвечала себе "Ну у меня же полно старых вещей, полный гардероб, не надо пока, всё есть. Потом куплю". Знакомо?

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

Помните кайф, когда покупаешь новые красивые вещи? И чтобы все помещалось в шкафу, я периодически собираю часть старых вещей и выбрасываю. А 3 раза жизнь заставила оказаться в ситуациях, когда старых вещей больше нет, и весь гардероб приходилось собирать с нуля. В этот момент жизнь подталкивала менять всё принудительно, было сложно. Но я оглядываюсь и говорю этим ситуациям спасибо!

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

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

Если всё идёт легко, то скорее всего ты стоишь на месте. Но если трудно, если нужно преодолеть сложности, то поздравляю! Ты на пути к росту, и я уверена, что ты справишься. Ты силен и готов к вызовам!

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

Не бойся меняться и расти! Всё получится! 🔝

Какие установки и привычки вы меняете сегодня? К чему идете? Делитесь в комментариях! 👇

Друзья, всем привет! ✌️
Меня зовут Нина и я бизнес-аналитик команды GetAnalyst 🥷🌪

Сегодня хочу поговорить об этапах разработки продукта в IT-компании и рассказать про свой опыт работы аналитиком в нескольких крупных проектах по разработке софта. #expertGetAnalyst

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

1️⃣ Сбор и анализ требований;
2️⃣ Документирование требований;
3️⃣ Проектирование архитектуры решения;
4️⃣ Разработка системы;
5️⃣ Тестирование созданной системы;
6️⃣ Внедрение и перевод в поддержку и развитие.


В зависимости от типа задачи и правил, принятых внутри компании, некоторые этапы могут:

🔸 сливаться в один;
Например, сбор и анализ требований идёт в параллель с их документированием.

🔸 выпадать из цикла разработки, потому что в нём нет необходимости.
Например, при рефакторинге системы не всегда нужен этап аналитики, а при работе с данными – этап тестирования.

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

Далее расскажу про два кейса участия аналитика в разработке ПО из своей жизни, пристёгивайтесь.


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

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

Именно поэтому задача аналитика была:

🔹 собрать требования с заказчика;
🔹 описать техническую документацию;
🔹 разработать прототипы с низкой и средней точностью.

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

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


2️⃣ В другой компании я тоже не была просто бизнес-аналитиком. Скорее это была фулстек позиция, где ты и бизнес-, и системный, и ещё немного дата-аналитик.

В мои обязанности, помимо работы с требованиями, входило:

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


☝️Короче говоря, аналитик – это универсальный IT-специалист, которому необходимо иметь множество навыков в разных сферах IT. Особенно если ты работаешь в РФ.

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

🔸 сферы деятельности компании;
🔸 грейдной сетки (то есть уровня аналитика);
🔸 типа задачи, которую отдают в отдел разработки.

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

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

Например, я, как бизнес-аналитик, не могу ограничиться только софт-скиллами и хард скилами работы с требованиями. После погружения в системную архитектуру (хвала GetAnalyst!🖤) и дизайн я стала передавать более качественные требования к разработке (в том числе к интеграции), а анализ представленного интерфейса теперь основывается не только на «паучьем чутье», но и на знаниях UX/UI-правил проектирования.

Подвожу итог.

Друзья, если вы ещё не испугались того, что аналитик – это не только «многоденег», но и:

💥 нон-стоп учёба;
💥 постоянное присутствие в проекте на всех этапах разработки;
💥 страховка бизнеса от возможных рисков;
💥 высокая ответственность

и всё ещё хотите ступить на этот путь воина 🥷, то вы настоящие смельчаки, а ещё невероятно амбициозные ребята!

У таких крутых специалистов обязательно всё получится, особенно с командой GetAnalyst во главе с Екатериной Ананьевой 🚀

А сейчас представьте ребёнка. Возраст не важен.

И вот, этот маленький человек, хочет научиться рисовать ракету, и кота заодно. Он пробует сам. У него может даже что-то выходит, но не так, как хочется. Чтобы улучшить результат, он идёт учиться в художественный класс. Там, скорее всего, у него не получается с первого раза. Ситуация повторяется второй, третий раз.
Уже может и мысли такие: это не моё — лучше мяч пойду попинаю.

В этот момент важно, чтобы ребёнка поддержали: родители, бабушки и дедушки, сёстры или братья, друзья.

Мы все так устроены. Нас пугают перемены. И если с первых попыток, что-то не получается, решаем, что это не наше. И почему-то мы думаем, что у ребёнка весь мир впереди, а у взрослых всё гораздо сложнее. Нам труднее идти в новое. Это отнимает много энергии и сил.

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

В каждом из нас есть тот самый любопытный ребёнок, который хочет учиться, познавать мир. Поддержите его!
Неужели вы бы сказали своему ребёнку при первых попытках его в каком-то деле: «У тебя не получится», «Не берись», «Это не твоё». Вряд ли.

Эти фразы-сорняки нужно убрать и в отношении себя!
Ведь кто, если не мы сами, в первую очередь должны поверить в себя и свои начинания?

Переменам необходимо давать шанс. Они могут открыть новую интересную страницу жизни.

Так произошло со мной ни раз. Мне было страшно делать первые шаги в неизвестность. Но благодаря поддержке и вере окружения, близких, я в сегодняшнем дне. Каждый день я открываю глаза, смотрю за окно, и говорю себе: “Это правда моя жизнь? Спасибо, что не испугалась делать смелые шаги!”.

И у тебя получится. Я в тебя верю ❤️

Среди нас есть герои ⚡️

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

⚡️ Пришел в IT с нуля, на аналитика, учился на ходу.
И сейчас, когда хочется сменить работу - страшно. Не хватает знаний и опыта. Системные аналитики самоучки, которые смогли! Но каждая задача привносит немного стресса и переживаний в жизнь.

⚡️ Тестировщики, технические писатели и специалисты тех поддержки, кто видел как работают аналитики, часто им помогает, и чувствует в себе желание расти в этом направлении, но не знает как это сделать.

⚡️Бизнес-аналитики, кто понимает, что способен на большее, и готов разобраться с секретным языком программистов.

Есть и другие. И все вы Герои! Один раз получилось, а значит и всё остальное получится, в любом случае!


Сегодня я хочу анонсировать события:

⚡️🗓 22 июня в 19:00 Мск я проведу открытый вебинар, где покажу, как работают системные аналитики. В прямом эфире увидите подход к анализу проектов с нуля до задач на разработчиков.

⚡️🗓 С сегодняшнего дня и до 21 июня 23:59 Мск открыта предзапись на курс “Системный аналитик: с нуля до опыта работы на проекте”. Это практическая программа, которая поможет начать карьеру в системном анализе и структурировать знания действующим IT-специалистам. По анкете предзаписи действует скидка на обучение.

Почему я люблю эту программу еще больше сейчас? Я обновила ее и расширила в очередной раз. Еще больше погружения в технические детали, защита проекта на всех тарифах в конце обучения, проектный опыт в резюме и нахождение в комьюнити экспертов - действующих системных аналитиков! До 20 человек в потоке, с которыми постоянно будут взаимодействовать 5 кураторов и я.


Смелые шаги важны. И я хочу, чтобы были уверенны в них!

Не бойтесь идти вперед. Все возможно! ❤️

Хола, друзья! ✌️#hardGetAnalyst

Сегодня хотим рассказать вам про типы требований к программному обеспечению (ПО), с которыми на постоянной основе работают бизнес- и системные аналитики 🥷🦸‍♂️🦹


Существует множество классификаций требований (по Вигерсу и Битти, BABOK и другие), поэтому сегодня мы расскажем о каждом из типов, которые встречаются в работе аналитика.

🔹 Бизнес-требования, которые отражают ожидания бизнеса к продукту. Такие требования располагаются на верхушке айсберга и преследуют улучшение показателей бизнеса – выручки, оборотов, притока клиентов и так далее.

Например:
Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.


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

Например:
Как пользователь приложения Get Analyst, я хочу видеть познавательный контент на тему анализа в IT, в одном месте, чтобы процесс обучения был ещё удобнее.


🔹 Функциональные требования, которые описывают возможности, которые должен содержать IT-продукт. Такие требования возникают после проработки бизнес- и пользовательских требований и именно этот тип требований необходимо передавать в разработку.

Например:
Необходимо реализовать своевременную интеграцию контента сообщества GetAnalyst с различных платформ в приложение.


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

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


🔹 Требования переходного периода, которые содержат требования к процессу работы системы в период, пока планируемое изменение не станет доступным для пользователей. Иными словами, требования переходного периода – это как «подстелить соломку» перед выходом проектируемого изменения в общий доступ. Эти требования ближе к функциональным требованиям и чаще всего их не выделяют в отдельный тип, а формулируют, как требования к первой итерации* продукта.

Например:
Пока двухфакторная аутентификация недоступна, необходимо авторизовать пользователя в приложении по номеру телефона и паролю.


🤪🤪 куда так много требований

Ну как, держитесь ещё? Завтра и послезавтра хотим подробнее рассказать вам про два самых популярных типа требований в работе аналитика: бизнес-требования и функциональные требования.

А в конце будет классный КВИЗ, где вы сможете закрепить свои знания (кажется, вы их любите. Мы тоже!💥).
Признавайтесь, ждёте? 😉

👋 Продолжаем тему требований к ПО и сегодня поговорим про бизнес-требования.

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

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


Рассмотрим на следующем примере:

🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.

В этом бизнес-требовании представлена информация об интересах бизнеса в решении. Иными словами, бизнес хочет, чтобы:

☝️ комьюинити аналитиков в сообществе расширялось;
✌️ узнаваемость бренда повышалась.


Для достижения этих целей можно придумать множество концепций решения.

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


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


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

Например:
🔸 повысить количество студентов на курсе на 13% засчёт увеличения узнаваемости бренда
🔸 увеличить количество положительных отзывов на 20% о бренде на популярных платформах
и так далее.

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

Куда расти и что еще стоит изучить по системному анализу? 🚀

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

💥 СРОЧНЫЙ МЕМ на тему коммуникаций с заказчиком 💥

Всем отличного настроения! 🖤
Скоро продолжим разбираться с типами требований к ПО 😊

#GAhahaha

А вот и мыыыы👋

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

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

Вот так просто? Ну да 😊

❗️Функциональные требования определяют, что должны спроектировать разработчики, но не то, как именно они должны это спроектировать.
Очень важно, чтобы формулировка требования не содержала конкретное техническое решение.

Например:
🔹 Система должна получить информацию о clientId, clientFIO, clientNumber, clientLogin, clientPassword из POST-метода системы партнёра и сформировать личный кабинет клиенту с помощью метода CreateLK.

Глядя на такое требование вы не только ограничиваете разработчика, но и предлагаете не оптимальное решение (не надо так). Ведь скорее всего для создания личного кабинета достаточно меньшего количества полей. Оставьте конкретную реализацию команде разработки.

☝️Задача аналитика – обозначить конечную цель, ресурсы для её достижения, а также факторы, которые влияют на проектируемый процесс. А задача разработчика – определить лучший способ достижения этой цели и спроектировать обозначенную возможность в соотношении цена / качество.

Таков путь 🥷

А теперь разберём наш пример с приложением GetAnalyst.
В прошлый раз мы получили следующее требование от заказчика:

🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.

В ответ мы, как аналитики, предложили множество вариантов для достижения этой бизнес-цели. И конечный выбор пал на приложение. А какие конкретно функции мы ожидаем в этом приложении? Идём к заказчику 🏃‍♀️🏃‍♂️

Один из самых популярных способов формулирования функциональных требований – это проектирование вопросов по CRUD-модели:

🔹 Create: Можно ли в приложении вести свой блог и создавать записи? Или создавать комментарии под записями? А есть ли у пользователя личный кабинет с персональной информацией? Закрыли функциональное требование на создание данных.

🔹 Read: Можно ли читать записи? Кстати, а откуда эти записи появляются? Закрываем требование по чтению данных и тут же по интеграции с другими платформами.

🔹 Update: Можно ли изменять созданные записи, комментарии или реакции? Как насчёт возможности менять свой ответ в викторинах? А редактирование данных в личном кабинете? Получили требования к изменению данных.

🔹 Delete: Можно ли удалять комментарии? А удалить свой личный кабинет? То есть узнали про возможность удаления данных.
И так далее.

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

Полученный ответ формулируется в виде утверждения со словами «должен», «должна» или «необходимо» + глагол + ожидаемый результат.

Например:
🔸 В системе должна быть возможность создать личный кабинет в приложении с указанием персональных данных.

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

‼️ Функциональные требования напрямую связаны с другими типами требованиями. Ведь если спроектировать ПО, которое не представляет ценности для бизнеса (бизнес-требования) и пользователей (пользовательские требования), то ресурс на разработку был затрачен зря – такой продукт будет не нужен.