‼️Актуальный вопрос для собеседований на системного и бизнес-аналитика ‼️

Чем же отличаются User Story от Use Case?

1️⃣ Текстовый (или в виде таблицы) сценарий User Story воспринимается проще, чем Use Case в UML. Если человек до этого не работал с UML-диаграммой, ему может быть сложно и непонятно

2️⃣ User Story формируется быстрее, тогда как на Use Case нужно закладывать больше времени на разработку. Больше подходит под проекты, где необходимо подробно сформулировать требования

3️⃣ User Story подразумевает дальнейшую детализацию процессов, чтобы подробно разобраться во взаимодействии пользователя с системой.
Use Case изначально подробен и не требует дополнительной документации и детализации

4️⃣ User Story подходит для разработки поведенческих сценариев тестирования программы и методики приемочных испытаний (ПМИ)

5️⃣ Пользовательские сценарии Use Case показывают нефункциональные требования с точным заданием значений нужных показателей. Например: время отклика на событие.

6️⃣ Use Case объединяет функциональные требования по контексту.

На самом деле обе схемы работы с требованиями могут прекрасно дополнять другу друга в одном проекте.

Например, из пользовательской истории User Story можно составить несколько сценариев Use Cases и наоборот.

Всё зависит от задач и бюджета заказчика 💰

Я выбрала карьеру в IT после 9 класса и начала движение в этом направлении. Мое поступление в университет было не по выбору родителей, а по собственному осознанному желанию.

Уже на тот момент я понимала, что "корочка" о высшем мне не пригодится. Но боялась это признать.

Знания в универсистете - огонь 🔥 Я училась на системном анализе и на бизнес-информатике. Были предметы, за которые до сих пор благодарю преподавателей:

✔️ написание ТЗ
✔️ UML
✔️ проектирование БД, SQL
✔️ принципы ООП
✔️ программирование Java, JavaScript, C#, Delphi (Pascal)
✔️ разработка сайтов
✔️ деловое общение

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

Спустя два красных диплома и годы работы до меня дошла мысль: а можно было идти по простому пути, зачем я выбрала сложно? 😬

В 17 лет, когда я поступала в университет, друзья из IT мне говорили:

▫️ Можно научиться программировать, поработать где-то бесплатно и пойти после этого на работу с высокой ЗП
▫️ У меня есть диплом. Как видишь, я его забираю из университета спустя два года, потому что до этого было лень за ним ехать
▫️ Зачем тебе сложный ВУЗ? Ты же уже работаешь. Тебе надо что попроще, только нужных знаний, а в универ заезжать экзамены сдать

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

"Опытный наставник быстрее приводит к результату" - эта фраза нужна была мне в 17 лет. И опытный наставник.

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

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

Друзья, у кого-нибудь хоть раз реально просили диплом при устройстве на работу?
Да - 👍 и делитесь в комментариях где
Нет - 🔥

В этом подкасте рассказала про высшее образование и свой диплом. История искусств - one love 😅👇

Про высшее образование для начинающих в IT: надо или нет?

📕 Диплом — полезная штука. Уменьшает количество вопросов на собеседовании. Оправдывает, когда устраиваешься на работу без опыта в 19-24 года

📚 Знания — есть полезные предметы. Не во всех ВУЗах, не ото всех преподавателей дождешься структурированной информации без воды и крутой практики, но все же свои 20% полезных предметов я нашла

📝 Я выпускалась с дипломом по выбранной мною теме, а не моим научным руководителем. Это было круто. Я на инициативе сама работала над ним и меня не надо было пинать

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

Что было полезно, а что не очень? Ответ в подкасте 👩‍💻
P.S. История искусств 100%

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

1️⃣ Когда нужны аналитики, а ты не можешь найти их. Хочу клонировать себя
2️⃣ Опытом важно делиться - не хочу быть жадной, большое желание отдавать
3️⃣ У меня не было наставника в системном анализе, когда я начинала. У меня есть возможность дать это другим

P.S. Смотрите хэштег #getanalyst_знакомство
Я хочу собирать лучших системных и бизнес-аналитиков в GetAnalyst ♥️

🔥 Стартуем продуктивный 2023 🔥

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

💥 Проекты с нуля, стартапы
💥 Подключение в развивающиеся проекты (развитие работающего ПО)
💥 Участие в продуктовой разработке (пример: amazon, tinkoff, yandex...)
💥 Внедрение CRM, ERP
💥 Интеграции
💥 Пре-сэилы - анализ предметной области, выявление проблем и подготовка презентаций

За каждым кейсом скрывается тонна "подводных камней", с которыми можно встретиться. Как с точки зрения бизнес-анализа, так и со стороны проектирования, то есть системного анализа и архитектуры.

Даю 100% гарантии - чем больше предметных областей удалось разобрать, тем лучше!

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

Опыт работы на проектах и какие задачи на них выполнялись - это то, на что в первую очередь смотрять в вашем резюме 📑

Доверие людям - одна из важных составляющих моей жизни

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

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

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

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

Был у меня случай, когда я переучила тестировщика с гуманитарным образованием в системного аналитика. И когда помогала junior-разработчикам разобраться с правильными подходами к дизайну REST API - один из навыков опытных аналитиков и программистов.

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

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

За 2022 с GetAnalyst больше 30 бизнес-аналитиков перешли в системный анализ. Со мной в аналитику переходили и специалисты тех. поддержки, и тех. писатели. И меня очень воодушевляют отзывы про то, что я дарю веру в себя, люди успешно меняют работу, увеличивают доход и идут к новым вершинам!

Спасибо вам за доверие ♥️ Растем дальше! 🚀

Я держу обещания. Напоминаю про одно из них 🙃

Бесплатный вебинар
📹 Основы ООП - пишем код в прямом эфире
🗓 11 января 2023, 19:00 (Мск)

Регистрацию завтра откроем! 😉

Включайте уведомления и добавляйте канал в закрепленные, чтобы не пропустить 📌

Как разговаривать с разработчиками на одном языке? Можно поставить себя на место разработчика и написать немного кода, чтобы понять о чем они там на своем "птичьем" поют 🙂

Бесплатный вебинар уже завтра!
🚀 Основы ООП для аналитиков - пишем код в прямом эфире
🗓 11 января (ср), 19:00 (Мск)
🔗Регистрация здесь

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

Подключаться с компьютера - будем программировать!
До встречи в прямом эфире! 😉

Доброе утро!

Вы вчера задавали очень крутые вопросы на вебинаре! Разобрали даже больше, чем я планировала 💥

Нам удалось освоить все базовые принципы ООП и понять, как они влияют на работу аналитика. А еще и код написали!

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

🚀 5 лайфхаков для создания цепляющего резюме
🗓 18 января, 19:00 (Мск)

Готовимся активно участвовать! 😉

Хочу поделиться с вами своей историей: как системный анализ и работа в IT повлияли на мою жизнь 🌴

Я всегда мечтала путешествовать. Когда мне было 19, мне казалось, что отпуск 1-2 раза в год за границей - предел мечтаний! И я откладывала ЗП на это редкое удовольствие. Каждый раз ревела, когда уезжала из долгожданной поездки.

Как-то я увидела фотографии подруги, которая побывала в США. Еще до этого мне про Route 66 рассказывали. И мысли были "Ну лет в 30 я точно накоплю и отправлюсь туда в отпуск!". Я была младшим системным аналитиком и очно учлась в ВУЗе.

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

Так появилась цель получить заветное путешествие в США.

Уже через 6 месяцев после появления этой идеи о США я впервые оказалась во Флориде и Калифорнии!

А потом через 2 месяца после возвращения была на выходных в Вене. А еще через 2 выходные в Сочи. Потом выходные в Испании. Да и ЗП росла, что выходные где-то за границей уже были стабильно раз в 4-8 недель. И отпуск в США раз в пол года без отрыва от производства - еще до пандемии я начинала работать удаленно.

Позже я придумала новую цель и накопила на учебу в США. После завершения магистратуры в РФ сразу отправилась туда с удаленной работой старшим системным аналитиком в Москве. Опять же, до пандемии, когда это еще не стало обычным делом))

А сегодняшний день я просто не могла представить. Мне меньше 30, я живу в Калифорнии и у меня бизнес, который работает по всему миру, и команды в разных часовых поясах. Много бывших коллег и друзей из IT сейчас живет не в России.

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

P.S. Моя мотивационная картинка на 2023 - буду учиться одновременно с вами и двигаться к новым целям 🚀

Когда я получаю новые знания, то потом приходится делать ошибки, чтобы реально понять то, чему я научилась 🪲

И вот с какими ошиками я сталкивалась, когда только начинала работать аналитиком.

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

Длинные письма по результатам переговоров или их отсуствие
Если мы с заказчиком внесли уточнения в требования в процессе разработки, когда уже ТЗ и договор были подписаны, то правки нужно было фиксировать не только в задачах Jira. Нужно было еще и отправлять письма.
Слишком длинные письма - не читают, и потом на приемке их приходится искать и зачитывать их вслух. Отсутствие письма по уточнениям на приемке как-то обернулось "мы этого не обсуждали, почему не как по ТЗ?".

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


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

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

Что стоит проверять?

✔️ Описали ли вы ограничения по доступности функциональности? Какие роли имеют к ней доступ?

✔️ Вы описали сущность в системе. Например "Заказ". Что с ней можно сделать? Прогнали CRUD-модель (create, read, update, delete), чтобы описать все бизнес- и функциональные требования?

✔️ Вы описываете Use Case (пользовательский сценарий).
- Вы проверили возможные альтернативные сценарии, которые могут быть на каждом из шагов?
- Для клиента - вы указали методы API, которые должны вызываться?
- Для сервера - вы указали откуда брать данные из БД?

✔️ При постановке задачи на дизайнера вы сообщили ему о том, что необходимо отрисовать состояния, когда на экране возникли ошибки или нужно поменять статус (состояние)?

✔️ При проектировании интеграций вы открыли Postman, чтобы убедиться в том, что внешняя система работает корректно в тесте и на продакшн, как вы ожидаете по документации?

✔️ Форма ввода данных. Где делать проверки введенных данных? На сервере перед сохранением в БД точно. А нужно ли дублировать какие-то проверки на клиенте? Как обрабатывать ошибки валидации? Подсвечивать поля красным?

✔️ Вы проектируете БД. В одном заказе может быть много товаров. Один товар может быть во многих заказах. Связь сущностей товар-заказ "многие-ко-многим". Вы поняли почему так? А знаете как избавиться от этой связи? 😉

Это, и даже больше, возможно разобрать и запомнить только на практике! Делайте скриншот, чтобы не потерять этот мини-чеклист 📷