​​Воронка извлечения информации. Основные типы вопросов.

👉🏻 Фактически все вопросы можно разделить на открытые и закрытые.

📌Открытые вопросы — вопросы, подразумевающие активную выдачу информации собеседнику. Например: «Опишите, пожалуйста, Ваш процесс закупки»

📌 Закрытые вопросы — вопросы, которые подразумевают краткий односложный ответ - «ДА»/»Нет». Например: «Вы согласны с предложенным подходом?»

Знания данной классификации позволят Вам выстроить коммуникацию правильно в зависимости от стадии коммуникации и ситуации, а главное сделают её эффективной = результативной.

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

Почему мы начали с типов вопросов? Давайте разбираться вместе.
С типами вопросов неразрывно связана воронка извлечения информации из собеседника. Она применима как в устном, так и в письменном общении.

Давайте разберём подробнее:
➡️ Смысл воронки заключается в том, что сбор информации вы всегда должны начинать с открытых вопросов. Собеседнику необходимо дать возможность выдать максимальное количество информации. Аналитик в свою очередь внимательно слушает рассказ и делает пометки.
➡️ После того как собеседник высказался, а также в процессе для уточнения необходимо сузить поток его сознания закрытыми вопросами.
➡️ Наконец, имея достаточно узкий, а, главное, полезный набор информации аналитик приступает к процессу перефразирования и передаче её обратно собеседнику для подтверждения понимания.

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

Даже нарисовав диаграмму по полученной информации и предоставив её собеседнику для подтверждения результатов можно:
1️⃣ Транслировать ваше понимание полученной информации собеседнику;
2️⃣ Дать возможность собеседнику убедиться в том, что вы поняли его правильно.

➡️ Суммируем = подводим итоги. Подвести итог — значит логично завершить встречу с целью повторно провалидировать полученную информацию, а также, чтобы закрепить и зафиксировать ключевые моменты беседы.

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

​​Дорогие подписчики!🎉
Наш канал поздравляет вас с Наступающим Новым Годом! 🎄
Хотим пожелать в этом новом году интересных проектов, роста в профессиональном развитии и карьере💻 , внутренней удовлетворенности от того, что вы делаете🌈 , много энергии💥, отличного настроения🌞 и постоянного движения вперед🔥! 🍾

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

https://habr.com/ru/post/594631/

​​Что такое Story points. Зачем и как.

❓ Как можно оценить усилия на выполнение поставленной задачи?

👉🏻 Первое, что может прийти на ум это то, что задачу можно оценить в формате времени: часах, днях, неделях. Эти оценки в первую очередь основаны на личном опыте, предположении или интуиции. Оценивая конкретную задачу, разработчик озвучивает свое предположение, сколько бы ее выполнение заняло у него времени. И как показывает опыт - эти предположения очень редко бывают точными, потому что существует слишком много факторов, которые могут повлиять на срок выполнения задачи
Работая по Agile команды все чаще оценивают задачи в более абстрактной величине называемой story points.

❓ Что такое story point?

👉🏻 Story point — это абстрактная единица измерения, выражающая оценку общих усилий, которые необходимы для полной реализации определенного участка работы (функционала).
Ее ключевой особенностью является то, что она не привязывается к какому-то определенному времени (дни или часы разработки), а использует так называемые относительные единицы, не позволяющие определить точное время, затраченное на реализацию, но при этом помогают быстро и эффективно устанавливать приоритет задач в зависимости от их ложности.

❓Как это работает?

👉🏻 Пользуясь стори поинтами, мы присваиваем каждому элементу (работы) некое количественное значение. Сами по себе эти количественные оценки не важны. Важно то, как оценки разных элементов соотносятся друг с другом. Задача, которой присвоено значение 2, должна быть вдвое больше задачи со значением 1 и соответствовать двум третям задачам со значением 3.
Вместо единицы, двойки и тройки команда могла бы использовать цифры 100, 200 и 300. Тут важно соотношение, а не цифры как таковые.

❓ Что включают в Story points?

📌 Объем требуемой работы.
📌 Техническую сложность задачи;
📌 Возможные риски и неопределенность в требованиях.

​​🔥 Начался новый год, а значит, пришло время для новых вакансий!

Международная аутсорсинговая IT - компания Andersen в поисках Business Analyst с разговорным английским (В2/С1) для работы над крупным американским и британским проектами!

📌 Над чем предстоит работать?

1️⃣ Заказчик - компания из США, разрабатывающая решения для управления творческими проектами, направленными на оптимизацию и консолидацию процесса создания контента. Проект представляет собой разработку мобильного приложения и web версии для организации работы фотографа.

2️⃣ Заказчик - британская компания, с главным офисом в Лондоне и более чем 60 летним опытом в Fashion индустрии. На сегодняшний день имеет сеть из более чем 300 магазинов модной одежды по всему миру. Приглашаем присоединится к проекту по разработке e-commerce платформы, с помощью которой компания поставляет свои товары в 125 стран, расширяя присутствие на ведущих мировых торговых площадках.

3️⃣ Заказчик - британская компания, которая планирует выйти на лидирующую позицию на мировом рынке в области цифровых платежей. Приглашаем Вас присоединиться к проекту разработки платформы по управлению транзакциями для малого и среднего бизнеса. Одна из задач состоит в том, чтобы полностью переписать существующее решение с использованием современных технологий, микросервисов и подходов на основе AWS Serverless.

4️⃣ Для кандидатов из Украины и Европы.
Заказчик является ведущей международной табачной компанией, штаб-квартира которой находится в Швейцарии. 400 офисов, 27 фабрик, 5 центров исследований и 5 предприятий по переработке табака расположены по всему миру. Проект находится под строгим NDA. Разработке нового продукта - системы дистрибуции товаров. Проект с микросервисной архитектурой, команда разработки более 100 сотрудников.

👉🏻 Чем предстоит заниматься:
- анализировать и документировать бизнес- и технические требования от различных заинтересованных сторон;
- проводить рабочие встречи, совместные сессии по разработке приложений и требований;
- разбивать и декомпозировать бизнес-требования до управляемого уровня и передавать их команде разработчиков;
- создавать и поддерживать документацию по бизнес-требованиям и требованиям к программному обеспечению;
- помогать поддерживать roadmap и проводить соответствующий анализ пробелов;
- проводить анализ и обзор инструментов сторонних производителей;
- тесно сотрудничать с проектными группами и техническими специалистами для обеспечения успешной реализации проекта;
- четко доносить ожидания до членов команды и заинтересованных сторон;
- помогать внедрять лучшие практики анализа продуктов и обеспечивать, чтобы анализ продуктов стал неотъемлемой частью системы предоставления услуг;
- разработка портфеля услуг по анализу продуктов.

👤 Каким мы видим подходящего кандидата:
📍 опыт работы в качестве Business Analyst от 3-х лет;
📍 практический опыт работы в области разработки и/или активации программного обеспечения;
📍 опыт работы в среде Scrum/Agile;
📍 обширные знания о деятельности и методах бизнес-анализа;
📍 сильные аналитические навыки для критической оценки информации из многочисленных источников;
📍 способность определять приоритетность задач/целей;
📍 способность изменять подход в зависимости от меняющихся заинтересованных сторон, условий, обстоятельств и обратной связи;
📍знание инструментов управления требованиями (как минимум JIRA и Confluence);
📍 уровень английского языка - от Upper-Intermediate и выше.

☝🏻 Andersen, как компания, каждому сотруднику дает возможность реализовать свои амбиции в таких направлениях:
- Sharing знаний (программа менторства, участие в образовательных курсах);
- возможность посещать митапы компании по ВА и участвовать в них в качестве спикера
- программа компенсаций профессиональных сертификатов международного уровня, конференций и многое другое
-также у вас будет возможность занять роль Ресурсного менеджера и помогать развиваться группе начинающих ВА/SA.

📞 Контактное лицо:
Лакисова Александра - рекрутер
Скайп live:.cid.9c86f9a0b0c8903
Телеграмм @a-lakisova

Статья про критерии качества требований, из которой вы узнаете:

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

https://www.artofba.com/post/requirements_quality_criteria

​​Базовая модель коммуникации в работе аналитика.

📍 Учитывая, что коммуникации занимают иногда 80 процентов рабочего времени аналитика, выстраивать её нужно грамотно, дабы максимизировать эффективность передачи информации. Не будем забывать одна из черт, которыми должен обладать хороший аналитик именно «коммуникативность» (P.S. не путаем с «коммуникабельностью»)). Коммуницировать нужно качественно, без потерь и при этом не затрачивая на это лишнее ресурсы.

👉🏻 Давайте рассмотрим базовую модель коммуникации.

➡️ Есть два участника «Отправитель» и «Получатель», которые обмениваются между собой информацией. Что же происходит дальше?

1️⃣ Отправитель кодирует сообщение, т. е. излагает сообщение на языке, предположительно понятном «Получателю».

На данном этапе не стоит забывать про проактивность. Для того, чтобы коммуникация носила в последующем эффективный характер аналитик должен осуществить кодировку на языке максимально близком «Получателю». Для команды разработки это технический язык в терминах специализации. Для Заказчика это бизнес язык в терминах доменной области бизнеса. Также нужно использовать визуальные средства, с учётом тог, что большинство людей тяжело воспринимают «сухой» текст, а именно схемы, диаграммы, флипчарты и т. д. Само собой, мысль нужно формулировать чётко, лаконично, информативно, логично и последовательно.

2️⃣ С помощью канала сообщение передаётся «Получателю». Устно, по телефону, по почте. В процессе передачи сообщения искажаются каналом коммуникации. Соответственно искажения или шум это все, что может помешать передаче и пониманию сообщения. (например, помехи во время телефонного разговора).
📌 Основная задача аналитика на данном этапе — предупредить, минимизировать возникновение шума. Для этого важно выбрать максимально эффективный канал коммуникации. Сюда же можно отнести совершенствование знание языка аналитиком, проверка телефонной связи перед разговором, выбор и тестирование микрофона для связи по Skype и т.д. Идеально, перед началом коммуникации обдумать спектр помех, и то как можно их минимизировать.

3️⃣ На стороне «Получателя» происходит декодирование информации = преобразование сообщения «Получателем» в понятные ему мысли и идеи. На успешность этого этапа аналитик вряд ли может повлиять, кроме того, как закодировать сообщение таким образом, чтобы максимально облегчить декодировку.

4️⃣ В хорошем процессе коммуникации также присутствует обратная связь. Т.е. обратное сообщение об успешности декодировки и приёма исходного сообщения. (Например, ответ по электронной почте, о том, что сообщение получено)

☝🏻 Важно:
📌 обратная связь должна быть. Аналитик должен простимулировать «Получателя» дать обратную связь;
📌 использование обратной связи помогает скорректировать коммуникацию. Во время устного общения полезно следить за невербаликой (менять тон, темп). После презентации документации требований разработчикам крайне продуктивным является назначение митинга с целью получить обратную связь и оценить восприятие документа командой и, возможно внести правки для улучшения этого самого восприятия.

📍Не стоит забывать, что за все коммуникации на проекте отвечает именно аналитик. Выстраивайте коммуникации правильно!

​​Топ 6 книг по Agile для бизнес аналитика.

👉🏻 Если вы хотите пополнить свои знания в сфере Agile, то следующие книги точно для вас:

📌 Дженнифер Грин , Эндрю Стеллман-Постигая Agile.Ценности, принципы, методологии.
Эта книга рассказывает о самых популярных agile-методологиях – Scrum, XP (экстремальном программировании), Lean (бережливом программировании) и Канбан. Она познакомит с методами Agile, работающими в повседневной жизни, а также с базовыми ценностями и принципами, которые помогут команде полностью изменить свой подход к работе над проектами. Книга легко читается,отлично подходит для первого знакомства с agile-методологиями.

📌 Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство.
Эта книга -библия в управлении проектами, которую полезно прочитать и бизнес аналитикам тоже. В шестое издание впервые включены указания по применению надлежащих практик управления проектами в гибких (agile) и адаптивных средах.

📌 Роберт Мартин-Чистый Agile. Основы гибкости.
«Чистый Agile» рассказывает, как применять на практике agile разработчикам, тестировщикам, аналитикам, руководителям, менеджерам проектов и клиентам.

📌 Henrik Kniberg.Скрам и XP заметки с передовой.
Классическая книга про опыт одной компании во внедрении Agile процессов. Настолько популярна, что переведена на все языки. Небольшая. Cчитается одним из лучших практических пособий по Scrum в области разработки ПО.

📌 Jeffrey Liker.Dao Toyota. История появления TPS (который потом назвали Lean) на фабриках Тойоты Читается легко и быстро. Рекомендуется к прочтению в качестве художественной литературы.

📌 David Anderson.Kanban. Фундаментальная книга про Kanban от его автора. В Lean/Kanban сообществе ее называют "Библия Kanban”. Книга, которая может дать четкое представление об этой agile-методологии.

Если вы знаете еще хорошие книги, можете поделиться ими в комментариях.

Интересные размышления о мозговом штурме, ☝🏻 полезен ли данный метод или нет.

https://habr.com/ru/post/599175/

Сегодня поговорим о такой важном артефакте, как контекстная диаграмма.

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

🖍 Для построения контекстной диаграммы используется в основном нотация IDEF0 и DFD.

🖍 Цели построения диаграммы:

✔️ определить границы системы;
✔️ выявить функциональные требования, основываясь на входящий и исходящих потоках данных.

🖍 Элементы контекстной диаграммы:

✔️ проектируемый объект (система) - отображается в виде круга/овала;
✔️ внешние сущности, взаимодействующие с проектируемым объектом (пользователи, смежные системы) - отображаются в виде прямоугольников;
✔️ потоки данных (исходящие и входящие) - отображаются в виде стрелок.

🖍 Шаги построения диаграммы:

1️⃣ Запишите название проектируемой системы в центре;
2️⃣ Запишите внешние сущности, которые взаимодействуют с проектируемой системой вокруг проектируемой системы;
3️⃣ Укажите входящие и исходящие потоки данных между проектируемой системой и внешними сущностями с помощью стрелок;
3️⃣ Добавьте комментарий к потокам данных: детализируйте входящие и исходящие данные.

🖍 Онлайн-инструменты для создания контекстной диаграммы:

✔️ Google Draw,
✔️ Draw.io,
✔️ Miro.

- Рисунок контекстной диаграммы взят из интернета.

​​Сегодня мы поговорим про такой интересный и полезный для БА инструмент как Lean Canvas.

➡️ Lean Canvas - это одностраничный шаблон, который кратко описывает бизнес-модель и представляет ключевую информацию о продукте без лишних деталей. Заполнив его, БА и вся команда продукта получают мощный инструмент, который позволяет посмотреть на продукт со всех сторон и перейти от идеи к чёткому плану действий.

📍Шаблон Lean Canvas состоит из 9 блоков. Для заполнения нужно последовательно пройти по каждому блоку, ответив на вопросы. Лучше всего заполнять блоки, собравшись всей командой и устроив мозговой штурм - это займет больше времени, но даст лучший результат.

📎 Содержание шаблона можно менять, но стандартная схема включает следующие блоки:

1️⃣ Целевая аудитория: “Для кого мы создаем свой продукт?”. Модель следует составлять отдельно для каждого сегмента целевой аудитории.
📌 Советы: Избегайте слишком широкого определения ЦА. Выделите “ранних пользователей”, которые первыми получат доступ к продукту и обеспечат быструю обратную связь.

2️⃣ Проблема, которую будет решать продукт: “Какая проблема есть у наших клиентов?”, “Кто сейчас помогает им решать эту проблему?”.
📌 Советы: Найдите альтернативные варианты решения, это не всегда очевидно, но любая проблема, как правило, уже как-то решается. Для анализа используйте подход Jobs To Be Done и инструмент CJM.

3️⃣ Потоки прибыли: “Каким образом продукт будет приносить деньги?”, “Какая модель получения доходов будет использоваться?”.
📌 Советы: Большинство продуктов создается ради прибыли, поэтому ориентируйтесь на особенности своих пользователей, изучите опыт успешных конкурентов.

4️⃣ Решение проблемы: “Как мы будем решать проблему пользователей?”, “Какие функции продукта будут этому способствовать?”.
📌 Советы: Подключите группу тестовых пользователей, проведите исследования, используйте аналитику и проверку гипотез.

5️⃣ Уникальная ценность будущего продукта: “Чем наш продукт будет отличаться от конкурентов?”, “Почему пользователи выберут нас?”. Сформулируйте идею в 1-3 коротких предложениях.
📌 Советы: Проверьте себя на группе тестовых пользователей - действительно ли вы нашли то, что заставит пользователей выбрать вас?

6️⃣ Каналы продвижения: “Как мы будем выстраивать коммуникацию с пользователями?”, “Как они узнают о нашем продукте?”.
📌 Советы: Продумайте, где у вашего продукта наибольшие шансы попасться на глаза будущим пользователям.

7️⃣ Ключевые метрики: “Как мы поймем, что наш продукт успешен?”, “Какими параметрами будет измеряться успех?”.
📌 Советы: Выделите минимальные критерии успеха - тот минимум, который позволит утверждать, что продукт стал успешным.

8️⃣ Структура затрат: “Какие затраты на продукт ожидаются?”, “Сколько денег понадобится для его запуска/развития?”.
📌 Советы: расходы могут быть фиксированными (налоги) или изменяющимися (стоимость материалов или работ) - продумайте каждый тип и определите если не конкретные суммы, то хотя бы статьи будущих расходов.

9️⃣ Скрытое преимущество: “Что позволит нам быть успешнее конкурентов?”, “Каков наш скрытый козырь?”. Это могут быть суперпрофессионалы в вашей команде, продвинутые технологии, большая клиентская база либо уникальные функции.
📌 Советы: Если вы планируете быть первыми на рынке в своем сегменте, не указывайте это как уникальное преимущество. Многие успешные продукты были далеко не первыми в своем деле.

✏️ Составлять Lean Canvas можно на бумаге либо воспользоваться одной из онлайн-программ, таких как Miro, Mural, Canvanizer.

📎 Lean Canvas можно использовать не только для понимания того, какой продукт, зачем и для кого будет создаваться. Он помогает понять, стоит ли вообще создавать продукт и избежать затрат на разработку заведомо ненужного продукта. Для уже созданного продукта этот инструмент поможет провести анализ, чтобы обнаружить потенциальные проблемы и определить будущие шаги.

📍Lean Canvas может стать мощным инструментом в арсенале любого БА, позволяя ему предлагать релевантные решения и создавать по-настоящему качественные и успешные продукты.

​​Маечная система оценок👕. Что это и как
Использование размеров футболок для оценки проектов

👉🏻 В руководстве по Scrum нет официального правила относительно того, как команда должна оценивать и измерять предстоящий объем работ. Можно использовать покер планирование, метод Дельфи, метод функциональных точек или диаграмму Ганта. В одной из статей мы уже рассмотрели наиболее популярную систему оценок задач в Story Points, которая отлично работает на практике.

☝🏻 На этот раз предлагаем вашему вниманию альтернативную технику - оценку задач в размерах футболки (маечную оценку или T-shirt sizes). Популярность данной техники обусловлена скоростью использования (за одну сессию можно оценить 10-15 историй), а также легкостью ее применения.
Для сравнения, при оценке в Story Points используется около 10 значений из последовательности Фибоначчи, это действительно много, и давать такой огромный выбор зачастую бессмысленно. Но все носят футболки, поэтому сотрудникам будет просто понять разницу между размером XS и L.
Использование этих размеров для оценки трудозатрат на инициативы команды — быстрый способ получить представление о том, сколько времени и сил потребуется на разработку без применения сложных расчетов. Посмотрим, как это работает:


👉🏻 В качестве единицы измерения используется размер футболки: S, M, L, XL (если крупный проект, то еще XXS, XS, XXL). При желании можно договориться о соотношении «размеров», например, S это до 2 XS, M это до 2 S и так далее. Команда принимает решение о размере пользовательской истории или функции в ходе совместной открытой дискуссии

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

Присвоение истории размера XXL свидетельствует о том, что на самом деле невозможно оценить задачу, т.к. она нуждается в дальнейшей декомпозиции и уточнении

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

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

Отличная статья для ознакомления с облачными сервисами.

👉🏻 https://habr.com/ru/post/645753/

​​Нужно ли бизнес-аналитику уметь писать код❓
Статья размышление от системного аналитика Ерслана Аймакова.

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

☝🏻 В этом месте каждая уважающая себя статья начинает новое предложение с громкого «НО!». Конечно же, умение писать и, соответственно, читать программный код никогда не будет лишним для любого IT-специалиста. Но давайте для начала все-таки разберем навыки, близкие к умению писать код, без которых хорошему аналитику все-же не обойтись:

👉🏻 Умение писать SQL-запросы. Основы искусства обращения к базам данных с помощью «языка» SQL – скилл, необходимый каждому аналитику, поскольку все мы так или иначе работаем с данными, хранимыми и обрабатываемыми посредством той или иной СУБД, и умение эти данные «вытаскивать» необходимо для решения большинства из каждодневных задач, стоящих перед аналитиком. Это еще не программирование, но уже солидный «хард-скилл», повышающий ваши конкурентные преимущества на рынке труда.

👉🏻 Знание API и умение работать с типами данных. На карьерном пути аналитика вам неизбежно придется столкнуться с интеграциями между информационными системами или модулями одной системы, а значит – работать с веб-сервисами – посредниками, передающими информацию от одной системы к другой с помощью сообщений, например, структурированных в виде популярных форматов JSON или XML.
Часто эта информация впоследствии должна быть помещена в базу данных. Сущности в сообщениях или полях базы представляют из себя набор полей, содержащих некие типизированные значения – например, если это числа – тип может быть целочисленным или с плавающей запятой, если это строка – она может иметь ограниченное количество символов, а может вам необходимо передать список из нескольких значений – и на это тоже есть свой тип данных.
В общем, если коротко – без знания типов и форматов данных, а также знание принципов работы API аналитику не обойтись. А обладая этими знаниями, вы можете считать, что находитесь на первом шаге изучения любого языка программирования!

👉🏻 Умение грамотно поставить задачу на разработку. Как аналитик, вы должны уметь поставить грамотную задачу на разработку – то есть, как минимум, расписать алгоритм работы вашей «фичи» - с чего должен начинаться процесс, какими должны быть входные и выходные данные, как должна обрабатываться информация.
Не так важно в каком формате вы это опишете, важно максимально прозрачно описать все шаги алгоритма, используя, к примеру, условия «Если – То – Иначе», описание обработки данных с помощью циклов, или «маппинг данных» - например, в какое поле базы данных мы должны поместить значение, полученное от сервиса-партнера.
➡️Если вы являетесь специалистом, которые умеет составить грамотную постановку задачи, считайте, что вы уже умеете программировать на базовом уровне – дело осталось за малым – начать изучать синтаксис того или иного языка!

📃 В заключение, хочется сказать, что любой опытный бизнес или системный аналитик уже близок к тому, чтобы усвоить какой-либо язык программирования. 💻Хорошим кандидатом для первого языка программирования является Python – изучив его, вы не только существенно повысите свою компетенцию в качестве БА/СА, но и можете продолжить свое развитие в сторону аналитика данных или специалиста в сфере машинного обучения.

Интересная статья, как понять и объяснить, что такое RACI матрица простыми словами.☝🏻
https://habr.com/ru/company/timeweb/blog/597281/

​​❗️ Дорогие друзья!
👉🏻 Andersen запускает новый формат встреч - BA Talks!

11 февраля приглашаем в Ивент-пространство "30th Floor" на офлайн-мероприятие, где в уютной и неформальной обстановке мы вместе обсудим актуальные для бизнес-аналитиков темы, послушаем выступления классных спикеров и поделимся своими инсайтами!

Вас ожидают:
📌 доклад от ведущего аналитика и эксперта в домене Healthcare Виталия Бирченко о подготовке к международным конференциям;
📌 доклад от руководителя департамента BA и SA Марии Боярко о том, каким хотят видеть бизнес-аналитика заказчики;
📌 обсуждение тем и нетворкинг с участниками;
📌 интерактив и подарки от Andersen;
📌 угощения и напитки.

🔥 Гарантируем прекрасное настроение и отличную мотивацию для профессионального развития!

📅 Когда: 11 февраля 19:00
🏬 Где: Ивент-пространство "30th Floor" г.Минск, пр-т Победителей 7а, 30-й этаж

✏️ Регистрация тут: https://forms.gle/1BNsLABKD9ZQuQAR6

Советуем поторопиться, ведь количество мест ограничено!
До встречи на BA Talks в Andersen!

Статья размышление от проблемах быстрорастущих компаний от бизнес аналитика Дмитрия Агафонцева.
https://telegra.ph/Problemy-bystrorastushchih-kompanij-na-kotorye-chasto-ne-obrashchayut-vnimaniya-02-02

​​Что такое ETL?

Давайте разберёмся с самого начала. ETL — сокращение от Extract, Transform, Load.

➡️ E – extract = добыча данных, извлечение их из какого — либо источника
➡️ T – transform = преобразование данных. После того как прошёл этап и извлечения данных нам нужно их обработать, преобразовать в формат, который нас устроит.
➡️ L load = загрузка данных в целевое хранилище.

А теперь по порядку.
Возникает вопрос - для чего же существует процесс ETL? Какие цели он преследует?
Представьте компанию, которая содержит в себе каталог различных продуктов от разных Поставщиков. Для размещения этих продуктов в каталоге нужно получать различную информацию о них от разных Поставщиков: цена, остатки на складах и т.д. Для такого процесса характерно большое количество интеграций, каждая из которых характеризуется наличием «cобственного» процесса ETL.

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

Также ETL процессы должны отвечать некоторым требованиям бизнеса как то:

1️⃣ Решение по ETL процессам должно быть стандартным = максимально распространённым, чтобы облегчить работу с ним.
2️⃣ Быстрое внедрение новых интеграций. Т.е. изменение формата передачи новых данных не должно приводить к длительным процессам разработки, внедрения и т.д.
3️⃣ Адекватная стоимость. Стоимость разработки, внедрения не должна быть высокой = должна соответствовать формуле «один раз настроили — подняли — внедрили».

Какие технические вопросы могут возникнуть при внедрении процессов ETL?
✏️ Необходимость отслеживать состояние интеграций. Какие процессы сейчас работают, с какой скоростью и т.д.
✏️ Существуют движки для внедрения ETL, но они требуют доработок (админка, роли, логирование…)
✏️ Для построения ETL удобно использовать DAG – directed acyclic graph, который позволяет построить «дерево», у которого много разных ветвлений. Но этот движок требует много дополнительного программного обеспечения.
✏️ Как следствие возникает потребность в привлечении отдельного специалиста, который бы разобрался бы в том как движок работает и устроен, специалиста, который написал бы кучу кода для имплементации бизнес — логики, что является достаточно долгим и дорогостоящим процессом и иногда приводит к переписыванию значительной части кода.
✏️ Для построения ETL процессов часто используются отличные от используемых в компаниях языки программирования, соответственно, уходит время на то, чтобы разобраться с ними.

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