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

💻 Ребята из компании Andersen создали замечательное видео с примерами собеседований.

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

Всем отличных осенних выходных и хорошего просмотра!🍿

👉🏻 Собеседование на Middle System Analyst
https://www.youtube.com/watch?v=g6QCMC7oUWo&list=PLxGuQSFUcmKGVtwIdJoP51vqGuuPwVkeP&index=7

👉🏻 Собеседование на Senior Business Analyst
https://www.youtube.com/watch?v=5oQoFBDl-Yw&list=PLxGuQSFUcmKGVtwIdJoP51vqGuuPwVkeP&index=6

👉🏻 Собеседование на Middle Business Analyst
https://www.youtube.com/watch?v=4Jx61t9rWAo&list=PLxGuQSFUcmKGVtwIdJoP51vqGuuPwVkeP&index=8

​​Идентификация, аутентификация и авторизация.
👉🏻 Разбираемся в понятиях

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

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

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

📌 Идентификация — происходит, когда субъект заявляет о своей личности, например, с помощью имени пользователя или логина. Распознавание пользователя в системе по его логину и есть идентификация.

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

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

📃 В качестве примера из реальной жизни можно привести проверку документов сотрудником дорожно-патрульной службы (ДПС). Представьте, что вашу машину остановил сотрудник ДПС. Вы представились как Иванов Иван, сотрудник ДПС 👉🏻идентифицировал вас как Иванов Иван. Для 👉🏻аутентификации вы предъявили водительское удостоверение, в котором видно, что Иванов Иван выглядит так же, как и вы. 👉🏻 Авторизацией в данном случае будет то, что сотрудник ДПС отпустит вас, т.е. предоставит право свободного перемещения, если не было выявлено нарушений правил дорожного движения.

Дейлики на удаленке👌😃
#BAmemeRU

​​Верификация и валидация требований

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

👉🏻 Разница между валидацией и верификацией

📌 Валидация: подтверждает, что требование соответствует намерениям заинтересованной стороны.

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

❗️Валидация требований

Валидация подтверждает, что требования соответствуют бизнес требованиям. и позволяет удостовериться в том, что продукт удовлетворяет потребности клиентов (делает все правильно).

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

❗️ Верификация требований

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

1️⃣ Верификация подтверждает, что требования содержат необходимые элементы хорошо написанных требований такие как: Полнота, Корректность, Осуществимость, Необходимость, Назначение приоритетов, Недвусмысленность, Проверяемость
2️⃣ Верификация отвечает на вопрос, правильно ли создается и тестируется ПО и все ли требования учитываются при этом.

Скрам покер. Для чего нужен и что это такое?

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

👉🏻 Сегодня поговорим о том, что же такое скрам покер, в чем его преимущества и риски и, как провести покер планирование на практике.

https://telegra.ph/Skram-poker-10-22

BA & SA митап online
Сегодня в 19.00 (GMT+3)

Интереснейший митап для системных и бизнес аналитиков, который можно посмотреть онлайн!

Эксперты из Andersen, Альфа-Банк и Deutsche Bank TechCentre расскажут вам о развитии проектов, о работе банковских SA и использовании интеграций в FinTech домене.

🗣 Спикеры:
👉🏻 Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке

👉🏻 Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.

👉🏻 Андрей Абразовский - Andersen
История эволюции ФинТех проекта от монолита до микросервисной архитектуры.

Подключайтесь: https://www.youtube.com/watch?v=7k4SPbOdAGM
Ставьте лайки, жмите колокольчик!

​​Как провести хороший онбординг новому сотруднику.
Важные артефакты онбординга.

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

👉🏻 Разберем по пунктам из чего должен состоять ваш идеальный онбординг:

1️⃣ До прихода сотрудника распишите план онбординга.

📌 Определите инструмент в котором план онбординга всегда будет доступен для новых сотрудников.
📌 Добавьте в план онбординга вводные ("read me" пояснения, как применять).
📌 Составьте полный список полезных ссылок и ссылок на сервисы/инструменты к которым сотруднику дадут доступ.
📌 Разделите ваш план онбординга на этапы с определенной длительностью: например первая неделя, 30 дней, 60 дней, 90 дней.
📌 Каждый этап должен включать в себя 1:1 встречи с ответственным в начале этапа .
📌 Каждый этап может включать набор задач для сотрудника и даже ответственных, кто поможет достичь успеха: например назначить того, кто устроит презентацию продукта.
📌 Добавьте к каждому этапу чеклист, чтобы сотрудник мог отметить, что выполнил этап, например понял ценности компании.
📌 Добавьте этап, с заданием найти себе товарища в коллективе.
📌 На каждый этап по необходимости давайте подсказки, полезные ссылки, ответственных людей, чтобы достичь успеха.

2️⃣ Поделитесь планом онбординга с новым сотрудником.

3️⃣ Следите за тем, как сотрудник продвигается по плану.

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

🎉 Всем желаем качественных онбордингов.

Митап идёт прямо сейчас, подключайтесь.

Мы переходим к следующему докладу на нашем митапе. Следующие спикеры:

👉🏻 Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке

👉🏻 Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.

Подключайтесь: https://www.youtube.com/watch?v=7k4SPbOdAGM

Как и обещали, выкладываем презентации наших крутых спикеров с прошедшего митапа в формате PDF📃. А также, если кто то пропустил митап, дублируем ссылку на просмотр:
https://www.youtube.com/watch?v=7k4SPbOdAGM

1️⃣ Андрей Абразовский - Andersen
История эволюции ФинТех проекта от монолита до микросервисной архитектуры.
Видео: минуты с 11.40 до 48.20

2️⃣ Алексей Лобзов - Альфа-Банк
Три факта о работе системного аналитика в Банке
Видео: минуты с 48.30 до 1.25.00

3️⃣ Олег Кармалеев - Deutsche Bank TechCentre
Интеграции: разные виды и их использование в банке.
Видео: минуты с 1.25.20 до 2.00.20

​​Сегодня удивительный день в истории ИТ: День Рождения интернета🎉🎉🎉

🎈 29 октября 1969 года аспирант Калифорнийского университета в Лос-Анджелесе (UCLA) передал текст, состоящий из букв L-O, на удалённый компьютер двоих представителей Стэндфордского университета.

🎈 Двумя представителями Стэндфордского университета были Билл Дювалл и Чарли Клайн, а передаваемые буквы были началом слова «login», однако, компьютер принимающей стороны «завис», не дав закончить передачу всего слова. Позже их компьютеры были соединены с компьютерами в Университете штата Юта и Калифорнийском университете в Санта-Барбара, благодаря чему была создана сеть ARPANET (Сеть агентства передовых исследовательских проектов).

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

💻 Так, многие существующие протоколы Интернета берут начало именно в ARPANET. Например, протокол обратного поиска DNS до сих пор использует доменное имя верхнего уровня «arpa»: чтобы найти записи, относящиеся к IP-адресу 1.2.3.4, надо послать запрос об адресе 4.3.2.1.in-addr.arpa. Основной протокол передачи данных сети Интернет — TCP/IP, тоже берёт начало в ARPANET.

🎈🎈🎈Так что, с Днем Рождения интернета!🎉🎉🎉

​​Врываемся в ноябрь с Global Business Analyst Day!🎉
Всех бизнес-аналитиков с профессиональным праздником!💻🎈

​​📃 Области рисков в бизнес анализе

Говоря про риски, хочется начать с определения термина, предложенного многоуважаемым Карлом Вигерсом. Итак, «риск — это условие, которое может повлечь какие — либо потери или другим способом поставить под угрозу успех проекта. Это условие ещё не породило проблему, и нужно, чтобы оно так и оставалось. 👉🏻 Эти потенциальные проблемы могут оказать неблагоприятное воздействие на стоимость, сроки, технический успех, качество продукта или эффективность работы команды».

Иными словами, риск — это неопределённое условие или событие, которое при наступлении может иметь негативный или позитивный эффект по отношению к бизнес — анализу.

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

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

2️⃣ Scope creep
Неконтролируемое расширение границ решения в силу забывчивости, «передумывания» заказчика, что влечёт за собой увеличение параметров проекта, которое не на руку компании исполнителя.

3️⃣ Ограниченные искусственно сроки на разработку требований
На этапе переговоров, предложили максимально сжатые сроки, дабы проект «выгорел». Как итог - получили риск.

4️⃣ Несогласие со стороны клиента.
Неверно понятые требования — следствие ошибки аналитика.

5️⃣ Неявные, скрытые требования.
Когда есть что — то само собой разумеющееся, а потому не озвучивается и, как следствие, не учитывается аналитиком.

6️⃣ Неверная приоритизация.
Неверная приоритезация может повлечь недовольство со стороны клиента.

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

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

​​Транзитные требования. Что это и как писать👇🏻

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

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

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

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

1️⃣ Исследовать существующую систему чтобы понять, что нужно перевести на новое решение.

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

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

4️⃣ Проработать дизайн (в том числе архитектурный), чтобы можно было выявить основные различия между двумя системами.

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

6️⃣ Предусмотреть варианты управления текущей работой. Возможны варианты: завершение текущих задач в старой системе и инициация всех новых работ в новой системе, приостановка текущих задач до ввода новой системы, преобразование всей работы в период имплементации новой системы и др.

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

📌 Полезные инструменты, используемые при сборе транзитивных требований:

👉🏻 Анализ бизнес-правил: могут быть определены дополнительные бизнес-правила для переноса данных или для управления работой, перенесенной из существующего решения.

👉🏻 Диаграммы потоков данных, моделирование процессов и организационное моделирование.

👉🏻 Моделирование данных для оценки их сопоставимости в старом и новом решениях.

​​❗️ Вы системный аналитик? Тогда для вас новости!

👉🏻 IT компания Andersen запускает программу "SA hiring days! Получи Job Offer в 3 шага!"

👉🏻 Какие этапы?

1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/

2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)

3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!

📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/