Как системному аналитику выбрать крутой проект и не прогадать?
В статье автор, системный аналитик зарплатного проекта в Центре развития финансовых технологий Россельхозбанка, рассказала о:
⁃ как senior или middle аналитику удачно выбрать проект;
⁃ какое будущее на рынке системного анализа;
⁃ с какими проблемами сталкиваются системные аналитики на проектах чаще всего.
https://habr.com/ru/company/rshb/blog/592951/
В статье автор, системный аналитик зарплатного проекта в Центре развития финансовых технологий Россельхозбанка, рассказала о:
⁃ как senior или middle аналитику удачно выбрать проект;
⁃ какое будущее на рынке системного анализа;
⁃ с какими проблемами сталкиваются системные аналитики на проектах чаще всего.
https://habr.com/ru/company/rshb/blog/592951/
Хабр
Как системному аналитику выбрать крутой проект и не прогадать?
Сейчас рынок системного анализа переживает бурный рост и на это есть несколько причин: низкий порог входа (по сравнению с Java-разработчиками, например) несколько хаотичные требования к...
Маленькая шпаргалка для тех, кто хочет освежить память📃
📌 Различия между Use Cases и User Stories
👉🏻 User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
👉🏻 Use Case же больше про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности.
📍 Основные различия:
1️⃣ Требования
Use case — это всегда функциональные требования.
User story может содержать требования и к UI, и к UX, и производительности и т.д.
2️⃣ Формат
Use case имеет четкий формат, а в его основном сценарии действия пользователя сменяются системными.
К User story не такие строгие требования. Заголовок должен отображать суть, а критерии приемки можно описывать как угодно, лишь бы это имело смысл для всех заказчиков.
3️⃣ Фокус
При составлении Use case у нас всегда есть последовательность действий и результат, который ожидает пользователь.
User story — это добавление ценности маленькими порциями и демонстрация результата заказчику.
4️⃣ Масштаб
User story— это, в идеале, наименьшая неделимая задача, которая имеет ценность для пользователя.
Use case может описывать как взаимодействие пользователя с конкретной фичей, так и более глобальный бизнес-процесс.
5️⃣ Готовность к разработке
User story — это небольшое техническое задание.
Use case — это описание взаимодействия, которое может служить частью глобальной спецификации и приложением к ТЗ. Но сам по себе он не является исчерпывающей инструкцией для разработчика.
6️⃣ Кто составляет
Поскольку User story — это атрибут гибких методологий, то и составляет её владелец продукта. Да, конечно, бизнес - аналитики часто этим занимаются, но в этом случае они проксируют владельца продукта, выполняя его обязанности.
Use case — это универсальный инструмент, который не привязан к какой-то методологии. Но для его составления требуются определенные навыки, которые относятся к сфере деятельности бизнес - аналитика или системного аналитика.
📌 Различия между Use Cases и User Stories
👉🏻 User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
👉🏻 Use Case же больше про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности.
📍 Основные различия:
1️⃣ Требования
Use case — это всегда функциональные требования.
User story может содержать требования и к UI, и к UX, и производительности и т.д.
2️⃣ Формат
Use case имеет четкий формат, а в его основном сценарии действия пользователя сменяются системными.
К User story не такие строгие требования. Заголовок должен отображать суть, а критерии приемки можно описывать как угодно, лишь бы это имело смысл для всех заказчиков.
3️⃣ Фокус
При составлении Use case у нас всегда есть последовательность действий и результат, который ожидает пользователь.
User story — это добавление ценности маленькими порциями и демонстрация результата заказчику.
4️⃣ Масштаб
User story— это, в идеале, наименьшая неделимая задача, которая имеет ценность для пользователя.
Use case может описывать как взаимодействие пользователя с конкретной фичей, так и более глобальный бизнес-процесс.
5️⃣ Готовность к разработке
User story — это небольшое техническое задание.
Use case — это описание взаимодействия, которое может служить частью глобальной спецификации и приложением к ТЗ. Но сам по себе он не является исчерпывающей инструкцией для разработчика.
6️⃣ Кто составляет
Поскольку User story — это атрибут гибких методологий, то и составляет её владелец продукта. Да, конечно, бизнес - аналитики часто этим занимаются, но в этом случае они проксируют владельца продукта, выполняя его обязанности.
Use case — это универсальный инструмент, который не привязан к какой-то методологии. Но для его составления требуются определенные навыки, которые относятся к сфере деятельности бизнес - аналитика или системного аналитика.
Начинаем цикл статей по интеграции для системных аналитиков (освежить знания) или тех, кто хочет ими стать😊
Определение интеграции. Общие подходы к интеграции
📌 Интеграция - это установка связей между информационными системами для получения единого информационного пространства и поддержка сквозных бизнес-процессов в рамках этих связей.
☝🏻 Интеграция – это самое узкое место в разработке системы и в большинстве случаев это мера вынужденная, направленная на повышение эффективности бизнес-процессов компании. Вне сомнений легко интегрироваться с крупными продуктами от технологических гигантов таких как Amazon или Microsoft, но если речь идет о мелких системах, особенно устаревших, на которых нет документации, то тут может понадобиться очень много времени на их изучение.
👉🏻 Кроме многочисленных сложностей в интеграции с такими мелкими системами вы можете столкнуться с тем, что в конечном счете интеграция не состоится вовсе. Именно поэтому при оценке проектов закладывается большой объем времени на исследование систем, с которыми будет производится интеграция.
Для того чтобы рассмотреть подходы к интеграции возьмем для примера компанию, включающую в себя следующие информационные компоненты: бухгалтерия, CRM и складская системы.
📃 Далее дадим определение разным подходам к интеграции.
1️⃣ Нет интеграции между системами
Компоненты компании никак не связаны между собой, обмен информацией происходит вручную через флешки, на бумажных носителях или путем отправления файлов работниками отделов друг другу по электронной почте.
2️⃣ Вертикальная интеграция
CRM и складская системы имеют интеграцию с бухгалтерией, в то время как CRM и складская системы между собой никак не связаны. Иными словами можно сказать, что бухгалтерия находится на одном уровне, а CRM и складская система – на втором.
☝🏻 Связь сверху-вниз между уровнями есть, а вот горизонтальных связей внутри отдельного уровня нет.
3️⃣ Интеграция многие ко многим
Каждый информационный компонент компании может обратиться к функционалу любого другого и быть самим использованным любым другим компонентом. Т.е. бухгалтерия, CRM и складская системы связаны между собой напрямую.
☝🏻 Ограничения: все элементы привязаны к функциональности друг, друга. Если поменяем функциональность одной системы, мы потеряем интеграцию.
4️⃣ Горизонтальная интеграция
Подразумевает использование промежуточного (middleware) ПО - сервисной шины.
Основная её функция – создание единого пространства для хранения данных, сервисов, энд-поинтов и т.п., чтобы любое связное с ним приложение могло бы отправить ей и собрать с неё необходимую информацию. Данные на шине всегда находятся в актуальном состоянии. Возвращаясь к нашему примеру, бухгалтерия, CRM и складская системы не обмениваются информацией напрямую, а через посредника – сервисную шину.
❗️ Это самая перспективная и часто используемая интеграция.
Определение интеграции. Общие подходы к интеграции
📌 Интеграция - это установка связей между информационными системами для получения единого информационного пространства и поддержка сквозных бизнес-процессов в рамках этих связей.
☝🏻 Интеграция – это самое узкое место в разработке системы и в большинстве случаев это мера вынужденная, направленная на повышение эффективности бизнес-процессов компании. Вне сомнений легко интегрироваться с крупными продуктами от технологических гигантов таких как Amazon или Microsoft, но если речь идет о мелких системах, особенно устаревших, на которых нет документации, то тут может понадобиться очень много времени на их изучение.
👉🏻 Кроме многочисленных сложностей в интеграции с такими мелкими системами вы можете столкнуться с тем, что в конечном счете интеграция не состоится вовсе. Именно поэтому при оценке проектов закладывается большой объем времени на исследование систем, с которыми будет производится интеграция.
Для того чтобы рассмотреть подходы к интеграции возьмем для примера компанию, включающую в себя следующие информационные компоненты: бухгалтерия, CRM и складская системы.
📃 Далее дадим определение разным подходам к интеграции.
1️⃣ Нет интеграции между системами
Компоненты компании никак не связаны между собой, обмен информацией происходит вручную через флешки, на бумажных носителях или путем отправления файлов работниками отделов друг другу по электронной почте.
2️⃣ Вертикальная интеграция
CRM и складская системы имеют интеграцию с бухгалтерией, в то время как CRM и складская системы между собой никак не связаны. Иными словами можно сказать, что бухгалтерия находится на одном уровне, а CRM и складская система – на втором.
☝🏻 Связь сверху-вниз между уровнями есть, а вот горизонтальных связей внутри отдельного уровня нет.
3️⃣ Интеграция многие ко многим
Каждый информационный компонент компании может обратиться к функционалу любого другого и быть самим использованным любым другим компонентом. Т.е. бухгалтерия, CRM и складская системы связаны между собой напрямую.
☝🏻 Ограничения: все элементы привязаны к функциональности друг, друга. Если поменяем функциональность одной системы, мы потеряем интеграцию.
4️⃣ Горизонтальная интеграция
Подразумевает использование промежуточного (middleware) ПО - сервисной шины.
Основная её функция – создание единого пространства для хранения данных, сервисов, энд-поинтов и т.п., чтобы любое связное с ним приложение могло бы отправить ей и собрать с неё необходимую информацию. Данные на шине всегда находятся в актуальном состоянии. Возвращаясь к нашему примеру, бухгалтерия, CRM и складская системы не обмениваются информацией напрямую, а через посредника – сервисную шину.
❗️ Это самая перспективная и часто используемая интеграция.
Отличная статья о том, как бизнес аналитик (lead BA) сдавал IIBA CBAP сертификацию.
В статье подробно и интересно написано о:
👉🏻 Что такое сертификация IIBA CBAP, и что требуется, чтобы вас к ней допустили
👉🏻 Как проходит экзамен на сертификацию
👉🏻 И, Сергей делится советами, как готовится к этому экзамену.
https://dou.ua/forums/topic/35577/
В статье подробно и интересно написано о:
👉🏻 Что такое сертификация IIBA CBAP, и что требуется, чтобы вас к ней допустили
👉🏻 Как проходит экзамен на сертификацию
👉🏻 И, Сергей делится советами, как готовится к этому экзамену.
https://dou.ua/forums/topic/35577/
DOU
Как бизнес-аналитику сдать IIBA CBAP сертификацию. Советы из опыта
Сергей Губа, Business Analyst, рассказывает, как он получил сертификацию IIBA CBAP от Международного института бизнес-анализа, подготовка к которой заняла около 7 месяцев. В статье он делится лайфхаками, которые помогли упростить процесс подачи заявки, по
Интеграции бояться — в аналитики не идти
Автор статьи описывает из собственного опыта основные важные моменты, на которые нужно обратить внимание при проектировании интеграционного взаимодействия, чтобы не попасть впросак.
https://habr.com/ru/company/maxilect/blog/592533/
Автор статьи описывает из собственного опыта основные важные моменты, на которые нужно обратить внимание при проектировании интеграционного взаимодействия, чтобы не попасть впросак.
https://habr.com/ru/company/maxilect/blog/592533/
Хабр
Интеграции бояться — в аналитики не идти
Подавляющее большинство задач, с которыми мне приходится сталкиваться, – это проектирование интеграционного взаимодействия между системами, так что тема интеграции мне близка. В этой статье хочу...
Сегодня поговорим о такой серьезной теме, как интеграционный анализ.
📌 Этапы интеграционного анализа (Часть 1)
Интеграционный анализ проходит в несколько этапов: предварительное обследование; проектирование и техническая детализация.
1️⃣ Предварительное обследование – создается концепция будущей системы и определяются высокоуровневые нефункциональные требования, например, масштабируемость, устойчивость. Кроме того определяются:
👉🏻 Цели и задачи интеграции – чего хотим достичь и по средством каких манипуляций;
👉🏻 Архитектурный паттерн интеграции (файловый обмен, общая БД, удаленный вызов процедур, обмен сообщениями, интеграция по API);
👉🏻 Источник (мастер) и потребитель информации в интеграции - необходимо исследовать какие данные и возможности каждая система предоставляет. Если нет возможности использовать, например API, для одной из систем, то нужно рассматривать файловый обмен или какой-то другой паттерн.
📍 Файловый обмен – одна система экспотритует файл в папку, а вторая система, имеющая доступ к этой папке, импортирует и парсит файл, таким образом помещая данные свою БД. Популярный формат для обмена JSON, XML. Проблемы паттерна: необходима регулярность и корректность проведения операций экспорта-импорта.
📍 Общая БД – все элементы системы интегрированы с единой БД, т.е. все компоненты работают с едиными данными. Изменения, произведенные в одном из приложений, автоматически отражаются в другом. Используются системы управления БД (СУБД) для поддержания корректности данных.
📍 Удаленный вызов процедур - приложения интегрированы на уровне функций и изменения данных в них происходит тоже посредством вызова функций. Обладает высокой степенью защиты, так как методы разрабатываются таким образом, чтобы не допустить несанкционированного доступа из вне. Проблемы паттерна: каждая из систем самостоятельно заботится о поддержке данных в корректном состоянии, что является довольно сложно задачей.
📍 Обмен сообщениями – асинхронный обмен сообщений посредством шины данных. Асинхронный обмен предполагает, что система не дожидается ответа от шины на отправленный запрос и может дальше продолжать отправлять запросы. Предназначен для интеграции независимых приложений без или с минимальными доработками существующих систем.
📍 Интеграция по API – есть информационная система и сервер и мы обращаемся по запросу на сервер, вызываем определённый метод, а метод в свою очередь возвращает JSON файл. Данный файл далее распаршивается и используется в нашей системе.
2️⃣ Проектирование – заключается в составлении ряда диаграмм для всестороннего описания интеграции.
Используют следующие диаграммы:
📍 Диаграмма потоков данных (data flow diagram DFD) - отображает течение информации в пределах процесса или системы.
📍 Диаграмма объектной модели (entity relationship diagram ERD) - используется при высокоуровневом проектировании баз данных. Описывает сущности БД и связи между ними.
📍 Диаграмма или таблица маппинга данных – определение соответствия данных из одной системы данным из другой системы.
Продолжение в следующем посте...
📌 Этапы интеграционного анализа (Часть 1)
Интеграционный анализ проходит в несколько этапов: предварительное обследование; проектирование и техническая детализация.
1️⃣ Предварительное обследование – создается концепция будущей системы и определяются высокоуровневые нефункциональные требования, например, масштабируемость, устойчивость. Кроме того определяются:
👉🏻 Цели и задачи интеграции – чего хотим достичь и по средством каких манипуляций;
👉🏻 Архитектурный паттерн интеграции (файловый обмен, общая БД, удаленный вызов процедур, обмен сообщениями, интеграция по API);
👉🏻 Источник (мастер) и потребитель информации в интеграции - необходимо исследовать какие данные и возможности каждая система предоставляет. Если нет возможности использовать, например API, для одной из систем, то нужно рассматривать файловый обмен или какой-то другой паттерн.
📍 Файловый обмен – одна система экспотритует файл в папку, а вторая система, имеющая доступ к этой папке, импортирует и парсит файл, таким образом помещая данные свою БД. Популярный формат для обмена JSON, XML. Проблемы паттерна: необходима регулярность и корректность проведения операций экспорта-импорта.
📍 Общая БД – все элементы системы интегрированы с единой БД, т.е. все компоненты работают с едиными данными. Изменения, произведенные в одном из приложений, автоматически отражаются в другом. Используются системы управления БД (СУБД) для поддержания корректности данных.
📍 Удаленный вызов процедур - приложения интегрированы на уровне функций и изменения данных в них происходит тоже посредством вызова функций. Обладает высокой степенью защиты, так как методы разрабатываются таким образом, чтобы не допустить несанкционированного доступа из вне. Проблемы паттерна: каждая из систем самостоятельно заботится о поддержке данных в корректном состоянии, что является довольно сложно задачей.
📍 Обмен сообщениями – асинхронный обмен сообщений посредством шины данных. Асинхронный обмен предполагает, что система не дожидается ответа от шины на отправленный запрос и может дальше продолжать отправлять запросы. Предназначен для интеграции независимых приложений без или с минимальными доработками существующих систем.
📍 Интеграция по API – есть информационная система и сервер и мы обращаемся по запросу на сервер, вызываем определённый метод, а метод в свою очередь возвращает JSON файл. Данный файл далее распаршивается и используется в нашей системе.
2️⃣ Проектирование – заключается в составлении ряда диаграмм для всестороннего описания интеграции.
Используют следующие диаграммы:
📍 Диаграмма потоков данных (data flow diagram DFD) - отображает течение информации в пределах процесса или системы.
📍 Диаграмма объектной модели (entity relationship diagram ERD) - используется при высокоуровневом проектировании баз данных. Описывает сущности БД и связи между ними.
📍 Диаграмма или таблица маппинга данных – определение соответствия данных из одной системы данным из другой системы.
Продолжение в следующем посте...
Этапы интеграционного анализа (Часть 2)
3️⃣ Техническая детализация – предполагает дальнейшую детализацию ранее описанных параметров и представление материала в виде технической спецификации. Ведется по многим направлениям:
3️⃣.1️⃣ Валидация и алгоритмы преобразования информации:
📍 Проверка на существование сущности в системе и обработка кейсов. Например, при файловом обмене проверяем существует ли вообще нудный файл. Другой пример, это как мы будем отрабатывать ошибки.
📍 Целостность информации – например, описывается как будет происходить проверка не произошло ли потери информации в процессе экспорта-импорта.
📍 Активность сущности – например, указывается наиболее актуальная версия файла для использования при интеграции;
📍 Загрузка из нескольких источников – указание потоков данных на диаграмме DFD для использования при интеграции;
📍 Ограничения на уровне алгоритмов – например, JSON файл сформировался на 40 Mb, а наша система может обработать только файл размером в 10 Mb. Что мы будем делать в таком случае.
📍 Тестирование – исключения избыточных проверок. Например, при выборе файла для экспорта необходимо найти оптимальное количество проверок. Возможно, можно ограничиться проверкой на размер и формат файла, и не вести дальнейшую проверку на расширение, темплейт и др. параметры.
3️⃣.2️⃣ Требования к журналированию (логированию) - каким образом будет происходить оставление информационного следа при работе с данным.
Разрабатываются метрики о:
👉🏻 Дате и времени запуска интеграции
👉🏻 Длительности работы системы
👉🏻 Наименование системы
👉🏻 Детализация по каждой системе
3️⃣.3️⃣ Требования к механизму интеграции:
📍 Тип взаимодействия – указывается паттерн файловый обмен, прямое обращение к БД, веб-сервис, интеграционная шина или API;
📍 Настройки подключения – детализируются адрес сервера, параметры авторизации, название метода и параметра;
📍 Триггеры для интеграции – какое условие запуска интеграции; В случае запуска интеграции в ручном режиме кто имеет права запуска интеграции: администратор, пользователь, может ли администратор предоставлять права и т.п.
📍 Расписание запуска – предполагает описание периодичности, интервала подключения, возможности отключения и принудительного запуска;
📍 Источники данных – детализация названия сервера, БД папки, таблицы откуда берутся данные; описание правил использования данных; что делать при недоступности сервера и какое поведение предусмотрено в качестве альтернативного, как быть при обработке ошибок доступа; каким образом будет происходить обработка полученных дубликатов данных и файлов.
3️⃣ Техническая детализация – предполагает дальнейшую детализацию ранее описанных параметров и представление материала в виде технической спецификации. Ведется по многим направлениям:
3️⃣.1️⃣ Валидация и алгоритмы преобразования информации:
📍 Проверка на существование сущности в системе и обработка кейсов. Например, при файловом обмене проверяем существует ли вообще нудный файл. Другой пример, это как мы будем отрабатывать ошибки.
📍 Целостность информации – например, описывается как будет происходить проверка не произошло ли потери информации в процессе экспорта-импорта.
📍 Активность сущности – например, указывается наиболее актуальная версия файла для использования при интеграции;
📍 Загрузка из нескольких источников – указание потоков данных на диаграмме DFD для использования при интеграции;
📍 Ограничения на уровне алгоритмов – например, JSON файл сформировался на 40 Mb, а наша система может обработать только файл размером в 10 Mb. Что мы будем делать в таком случае.
📍 Тестирование – исключения избыточных проверок. Например, при выборе файла для экспорта необходимо найти оптимальное количество проверок. Возможно, можно ограничиться проверкой на размер и формат файла, и не вести дальнейшую проверку на расширение, темплейт и др. параметры.
3️⃣.2️⃣ Требования к журналированию (логированию) - каким образом будет происходить оставление информационного следа при работе с данным.
Разрабатываются метрики о:
👉🏻 Дате и времени запуска интеграции
👉🏻 Длительности работы системы
👉🏻 Наименование системы
👉🏻 Детализация по каждой системе
3️⃣.3️⃣ Требования к механизму интеграции:
📍 Тип взаимодействия – указывается паттерн файловый обмен, прямое обращение к БД, веб-сервис, интеграционная шина или API;
📍 Настройки подключения – детализируются адрес сервера, параметры авторизации, название метода и параметра;
📍 Триггеры для интеграции – какое условие запуска интеграции; В случае запуска интеграции в ручном режиме кто имеет права запуска интеграции: администратор, пользователь, может ли администратор предоставлять права и т.п.
📍 Расписание запуска – предполагает описание периодичности, интервала подключения, возможности отключения и принудительного запуска;
📍 Источники данных – детализация названия сервера, БД папки, таблицы откуда берутся данные; описание правил использования данных; что делать при недоступности сервера и какое поведение предусмотрено в качестве альтернативного, как быть при обработке ошибок доступа; каким образом будет происходить обработка полученных дубликатов данных и файлов.
❤1
В статье собраны многие вопросы, которые могут задать системному аналитику на собеседовании. Проверьте себя, сколько из них знаете вы😊
https://habr.com/ru/post/591057/
https://habr.com/ru/post/591057/
Хабр
Как пройти техническое собеседование на системного аналитика в любой компании (сборник вопросов)
Я проходил технические собеседования на системного аналитика в самых разных компаниях и каждый раз записывал все вопросы. У меня накопилось 120 вопросов. Список вопросов выкладываю в этой статье. Даю...
Туториал для туториалов. Как написать пользовательскую документацию
Статья освещает такие темы, как:
- Что входит в пользовательскую документацию
- Советы и размышления, как написать хорошую пользовательскую документацию.
https://habr.com/ru/post/591101/
Статья освещает такие темы, как:
- Что входит в пользовательскую документацию
- Советы и размышления, как написать хорошую пользовательскую документацию.
https://habr.com/ru/post/591101/
Хабр
Туториал для туториалов. Как написать пользовательскую документацию
Есть устоявшеёся мнение, что для хороших продуктов руководство пользователя не нужно. Очередной холивар на эту тему разгорелся в нашем рабочем чате. Я не до конца согласен с этим утверждением. ...
Вертикальная и горизонтальная нарезка пользовательских историй
📌 Вертикальная нарезка (vertical slicing) – это разбиение пользовательских историй таким образом, что все технические уровни для решения конкретной задачи учтены в сторе и при этом результат выполнения задачи является оконченной рабочей функцией, полезной для пользователя.
☝🏻Говоря по-простому, вертикально нарезанная сторя – это сторя стандартной структуры «Как <роль>, я хочу <функциональность>, чтобы я мог достичь <ценность / результат>» и соответствующая критериям INVEST. 👉🏻 Результат ее реализации – оконченная функциональность имеющая ценность для пользователя.
При обсуждении горизонтального и вертикального срезов часто проводят аналогию с разрезанием торта на куски. Так вот вертикальная нарезка - это все равно, что разрезать торт по вертикали, где каждый кусок представлял бы порцию, взятую от всех коржей по чуть-чуть. Коржи – технические уровни решения задачи (дизайн, база данных, тестирование и т.п.).
📍 Примеры вертикальной нарезки сторей:
➡️ Как пользователь банкомата я хочу снять наличные со своего банковского счета чтобы иметь возможность расплачиваться наличными при покупках;
➡️ Как пользователь банкомата я хочу оплатить счет за коммунальные услуги в банкомате чтобы не ходить в отделение банка для этого.
📌 Горизонтальная нарезка (horizontal slicing) - это декомпозиция работы по техническим уровням, каждый из которых предназначен для решения специалистами узкой специализации, например одну пользовательскую историю для создания веб-службы, другую - для создания таблицы базы данных, третью - для тестирования.
☝🏻 Горизонтальные истории обычно не соответствуют стандартной структуре пользовательской истории и критериям INVEST. Несмотря на то, что мы можем называть эти горизонтальные срезы пользовательскими историями, на самом деле они не могут предоставить ценность конечному потребителю без взаимодействия или интеграции с другими уровнями, компонентами.
👉🏻 Возвращаясь к примеру с тортом, горизонтальная нарезка – нарезка торта по горизонтали, где каждый корж представлял бы техническую специализацию. Мы бы не смогли в полной мере оценить вкус этого торта, так как каждый раз пробовали бы отдельный слой – вот и отсутствие упомянутой выше интеграции между слоями.
📍Примеры горизонтальной нарезки сторей:
➡️ Система должна токенизировать номер кредитной карты;
➡️ Система проверяет кредитный лимит по NFDB;
➡️ Система переводит утвержденные средства в учреждение-получатель.
📌 Вертикальная нарезка (vertical slicing) – это разбиение пользовательских историй таким образом, что все технические уровни для решения конкретной задачи учтены в сторе и при этом результат выполнения задачи является оконченной рабочей функцией, полезной для пользователя.
☝🏻Говоря по-простому, вертикально нарезанная сторя – это сторя стандартной структуры «Как <роль>, я хочу <функциональность>, чтобы я мог достичь <ценность / результат>» и соответствующая критериям INVEST. 👉🏻 Результат ее реализации – оконченная функциональность имеющая ценность для пользователя.
При обсуждении горизонтального и вертикального срезов часто проводят аналогию с разрезанием торта на куски. Так вот вертикальная нарезка - это все равно, что разрезать торт по вертикали, где каждый кусок представлял бы порцию, взятую от всех коржей по чуть-чуть. Коржи – технические уровни решения задачи (дизайн, база данных, тестирование и т.п.).
📍 Примеры вертикальной нарезки сторей:
➡️ Как пользователь банкомата я хочу снять наличные со своего банковского счета чтобы иметь возможность расплачиваться наличными при покупках;
➡️ Как пользователь банкомата я хочу оплатить счет за коммунальные услуги в банкомате чтобы не ходить в отделение банка для этого.
📌 Горизонтальная нарезка (horizontal slicing) - это декомпозиция работы по техническим уровням, каждый из которых предназначен для решения специалистами узкой специализации, например одну пользовательскую историю для создания веб-службы, другую - для создания таблицы базы данных, третью - для тестирования.
☝🏻 Горизонтальные истории обычно не соответствуют стандартной структуре пользовательской истории и критериям INVEST. Несмотря на то, что мы можем называть эти горизонтальные срезы пользовательскими историями, на самом деле они не могут предоставить ценность конечному потребителю без взаимодействия или интеграции с другими уровнями, компонентами.
👉🏻 Возвращаясь к примеру с тортом, горизонтальная нарезка – нарезка торта по горизонтали, где каждый корж представлял бы техническую специализацию. Мы бы не смогли в полной мере оценить вкус этого торта, так как каждый раз пробовали бы отдельный слой – вот и отсутствие упомянутой выше интеграции между слоями.
📍Примеры горизонтальной нарезки сторей:
➡️ Система должна токенизировать номер кредитной карты;
➡️ Система проверяет кредитный лимит по NFDB;
➡️ Система переводит утвержденные средства в учреждение-получатель.
Последнюю рабочую неделю в этом году начинаем с интересной статьи:
☝🏻 Что такое язык Gherkin и для чего он может быть полезен аналитику
Язык Gherkin был разработан как инструмент для написания приемочных автоматизированных тестов в рамках BDD (Behavior-driven development) фрэймворка. Бизнес аналитики переняли Gherkin для написания критериев приемки, чтобы описывать как система должна вести себя в определенных сценариях.
👉🏻 Gherkin - язык, используемый для описания поведения системы. Это простой и понятный бизнесу язык. Кроме того, Gherkin можно интерпретировать с помощью инструмента автоматизации под названием Cucumber и использовать его для проведения автоматизированных тестов. Это связывает требования BA с автоматизированными тестами.
❗️Причины почему Gherkin может быть полезен аналитику:
1️⃣ Gherkin позволяет бизнес-аналитикам документировать приемочные тесты на простом языке, понятном бизнесу. Наличие общего языка для описания критериев приемки способствует коллаборации и общему пониманию выполняемых приемочных тестов.
2️⃣ Gherkin очень структурирован, что помогает писать критерии приемки в хорошо читаемом виде. Это помогает восприятию информации для разработчиков и тестировщиков.
3️⃣ Gherkin помогает описать сложные процессы с витиеватой логикой простым языком. Представьте, что вам нужно описать логику со множеством ЕСЛИ. Gherkin поможет разбить такое описание на каждой ветке деления логики.
4️⃣ Gherkin напрямую связывает критерии приемки с автоматизированными тестами, так как фрэймворк Cucumber понимает критерии написанные на Gherkin. По сути, это означает, что аналитик пишет исполняемую спецификацию. Однако, данный бенефит актуален только в командах где используется BDD и фрэймворк Cucumber.
☝🏻 Gherkin включает в себя 10 ключевых слов: Given, When, Then, And, But, Scenario, Feature, Background, Scenario Outline, Examples.
📃 Вот пример требования, написанного по Gherkin:
Given у пользователя есть счет
And на счету лежит 100 рублей
When пользователь снимает 10 рублей
Then на счету становится 90 рублей
And новая транзакция должна быть записана в БД
Минимальные команды, необходимые для работы бизнес-аналитику, следующие:
✔️ Given - предварительное условие для сценария. Например пользователь вошел в систему, у пользователя есть деньги на счету и т.д.
✔️ When - действие, которое предпримет пользователь. Иными словами это действие, которое приводит к результату. Например, пользователь нажимает кнопку, пользователь выбирает товар и т.д.
✔️ Then - то, что происходит после того, как пользователь совершит это действие. Например, открывается форма для ввода данных, товар добавлен в корзину и т.д.
✔️ And – команда для добавления нескольких условий, когда сценарий более сложный. Его можно использовать вместе с Given, When или Then. Рекомендация - избегать большого количества And поскольку это может указывать на то, что сценарий содержит излишнюю информацию.
☝🏻 Что такое язык Gherkin и для чего он может быть полезен аналитику
Язык Gherkin был разработан как инструмент для написания приемочных автоматизированных тестов в рамках BDD (Behavior-driven development) фрэймворка. Бизнес аналитики переняли Gherkin для написания критериев приемки, чтобы описывать как система должна вести себя в определенных сценариях.
👉🏻 Gherkin - язык, используемый для описания поведения системы. Это простой и понятный бизнесу язык. Кроме того, Gherkin можно интерпретировать с помощью инструмента автоматизации под названием Cucumber и использовать его для проведения автоматизированных тестов. Это связывает требования BA с автоматизированными тестами.
❗️Причины почему Gherkin может быть полезен аналитику:
1️⃣ Gherkin позволяет бизнес-аналитикам документировать приемочные тесты на простом языке, понятном бизнесу. Наличие общего языка для описания критериев приемки способствует коллаборации и общему пониманию выполняемых приемочных тестов.
2️⃣ Gherkin очень структурирован, что помогает писать критерии приемки в хорошо читаемом виде. Это помогает восприятию информации для разработчиков и тестировщиков.
3️⃣ Gherkin помогает описать сложные процессы с витиеватой логикой простым языком. Представьте, что вам нужно описать логику со множеством ЕСЛИ. Gherkin поможет разбить такое описание на каждой ветке деления логики.
4️⃣ Gherkin напрямую связывает критерии приемки с автоматизированными тестами, так как фрэймворк Cucumber понимает критерии написанные на Gherkin. По сути, это означает, что аналитик пишет исполняемую спецификацию. Однако, данный бенефит актуален только в командах где используется BDD и фрэймворк Cucumber.
☝🏻 Gherkin включает в себя 10 ключевых слов: Given, When, Then, And, But, Scenario, Feature, Background, Scenario Outline, Examples.
📃 Вот пример требования, написанного по Gherkin:
Given у пользователя есть счет
And на счету лежит 100 рублей
When пользователь снимает 10 рублей
Then на счету становится 90 рублей
And новая транзакция должна быть записана в БД
Минимальные команды, необходимые для работы бизнес-аналитику, следующие:
✔️ Given - предварительное условие для сценария. Например пользователь вошел в систему, у пользователя есть деньги на счету и т.д.
✔️ When - действие, которое предпримет пользователь. Иными словами это действие, которое приводит к результату. Например, пользователь нажимает кнопку, пользователь выбирает товар и т.д.
✔️ Then - то, что происходит после того, как пользователь совершит это действие. Например, открывается форма для ввода данных, товар добавлен в корзину и т.д.
✔️ And – команда для добавления нескольких условий, когда сценарий более сложный. Его можно использовать вместе с Given, When или Then. Рекомендация - избегать большого количества And поскольку это может указывать на то, что сценарий содержит излишнюю информацию.
Отличная статья, как правильно вести записи, чтобы не упустить важных вещей.
👉🏻 Вы узнаете методики конспектирования митингов и важных коллов.
https://vc.ru/life/315774-kak-vesti-zapisi-chtoby-vse-ponyat-i-zapomnit-chetyre-prostyh-sposoba
👉🏻 Вы узнаете методики конспектирования митингов и важных коллов.
https://vc.ru/life/315774-kak-vesti-zapisi-chtoby-vse-ponyat-i-zapomnit-chetyre-prostyh-sposoba
vc.ru
Как вести записи, чтобы всё понять и запомнить? Четыре простых способа
Методики конспектирования лекций, совещаний и книг в материале издания Reminder.
Воронка извлечения информации. Основные типы вопросов.
👉🏻 Фактически все вопросы можно разделить на открытые и закрытые.
📌Открытые вопросы — вопросы, подразумевающие активную выдачу информации собеседнику. Например: «Опишите, пожалуйста, Ваш процесс закупки»
📌 Закрытые вопросы — вопросы, которые подразумевают краткий односложный ответ - «ДА»/»Нет». Например: «Вы согласны с предложенным подходом?»
Знания данной классификации позволят Вам выстроить коммуникацию правильно в зависимости от стадии коммуникации и ситуации, а главное сделают её эффективной = результативной.
Но важно❗️ В письменной коммуникации упор должен идти на закрытые вопросы, так как в игру вступает фактор усилий, которые должен приложить собеседник, чтобы ответить на Ваши вопросы.
Почему мы начали с типов вопросов? Давайте разбираться вместе.
С типами вопросов неразрывно связана воронка извлечения информации из собеседника. Она применима как в устном, так и в письменном общении.
Давайте разберём подробнее:
➡️ Смысл воронки заключается в том, что сбор информации вы всегда должны начинать с открытых вопросов. Собеседнику необходимо дать возможность выдать максимальное количество информации. Аналитик в свою очередь внимательно слушает рассказ и делает пометки.
➡️ После того как собеседник высказался, а также в процессе для уточнения необходимо сузить поток его сознания закрытыми вопросами.
➡️ Наконец, имея достаточно узкий, а, главное, полезный набор информации аналитик приступает к процессу перефразирования и передаче её обратно собеседнику для подтверждения понимания.
Очень часто, две последние стадии игнорируются. Это в корне неправильно. Если информация не проверена — увеличивается вероятность того, что она воспринята некорректно. Обязательно держим в голове одно из правил требований — корректность.
Даже нарисовав диаграмму по полученной информации и предоставив её собеседнику для подтверждения результатов можно:
1️⃣ Транслировать ваше понимание полученной информации собеседнику;
2️⃣ Дать возможность собеседнику убедиться в том, что вы поняли его правильно.
➡️ Суммируем = подводим итоги. Подвести итог — значит логично завершить встречу с целью повторно провалидировать полученную информацию, а также, чтобы закрепить и зафиксировать ключевые моменты беседы.
Помните и используйте воронку извлечения информации и тогда вероятность того, что вы что-то упустите или поймете некорректно снизится.
👉🏻 Фактически все вопросы можно разделить на открытые и закрытые.
📌Открытые вопросы — вопросы, подразумевающие активную выдачу информации собеседнику. Например: «Опишите, пожалуйста, Ваш процесс закупки»
📌 Закрытые вопросы — вопросы, которые подразумевают краткий односложный ответ - «ДА»/»Нет». Например: «Вы согласны с предложенным подходом?»
Знания данной классификации позволят Вам выстроить коммуникацию правильно в зависимости от стадии коммуникации и ситуации, а главное сделают её эффективной = результативной.
Но важно❗️ В письменной коммуникации упор должен идти на закрытые вопросы, так как в игру вступает фактор усилий, которые должен приложить собеседник, чтобы ответить на Ваши вопросы.
Почему мы начали с типов вопросов? Давайте разбираться вместе.
С типами вопросов неразрывно связана воронка извлечения информации из собеседника. Она применима как в устном, так и в письменном общении.
Давайте разберём подробнее:
➡️ Смысл воронки заключается в том, что сбор информации вы всегда должны начинать с открытых вопросов. Собеседнику необходимо дать возможность выдать максимальное количество информации. Аналитик в свою очередь внимательно слушает рассказ и делает пометки.
➡️ После того как собеседник высказался, а также в процессе для уточнения необходимо сузить поток его сознания закрытыми вопросами.
➡️ Наконец, имея достаточно узкий, а, главное, полезный набор информации аналитик приступает к процессу перефразирования и передаче её обратно собеседнику для подтверждения понимания.
Очень часто, две последние стадии игнорируются. Это в корне неправильно. Если информация не проверена — увеличивается вероятность того, что она воспринята некорректно. Обязательно держим в голове одно из правил требований — корректность.
Даже нарисовав диаграмму по полученной информации и предоставив её собеседнику для подтверждения результатов можно:
1️⃣ Транслировать ваше понимание полученной информации собеседнику;
2️⃣ Дать возможность собеседнику убедиться в том, что вы поняли его правильно.
➡️ Суммируем = подводим итоги. Подвести итог — значит логично завершить встречу с целью повторно провалидировать полученную информацию, а также, чтобы закрепить и зафиксировать ключевые моменты беседы.
Помните и используйте воронку извлечения информации и тогда вероятность того, что вы что-то упустите или поймете некорректно снизится.
Дорогие подписчики!🎉
Наш канал поздравляет вас с Наступающим Новым Годом! 🎄
Хотим пожелать в этом новом году интересных проектов, роста в профессиональном развитии и карьере💻 , внутренней удовлетворенности от того, что вы делаете🌈 , много энергии💥, отличного настроения🌞 и постоянного движения вперед🔥! 🍾
Наш канал поздравляет вас с Наступающим Новым Годом! 🎄
Хотим пожелать в этом новом году интересных проектов, роста в профессиональном развитии и карьере💻 , внутренней удовлетворенности от того, что вы делаете🌈 , много энергии💥, отличного настроения🌞 и постоянного движения вперед🔥! 🍾
Интересная статья про неточности в технической документации.
👉🏻 Возможно в этой статье вы найдете полезные словосочетания, которые сможете использовать в своей работе.
https://habr.com/ru/post/594631/
👉🏻 Возможно в этой статье вы найдете полезные словосочетания, которые сможете использовать в своей работе.
https://habr.com/ru/post/594631/
Хабр
Уж послала, так послала: словосочетания-паразиты в технических текстах
В технических текстах есть целый пласт «устоявшихся словосочетаний», которые по сути являются неправильным или некорректным употреблением слов. Да, это не грубые ошибки, вроде «за ранее» или «по...
Что такое Story points. Зачем и как.
❓ Как можно оценить усилия на выполнение поставленной задачи?
👉🏻 Первое, что может прийти на ум это то, что задачу можно оценить в формате времени: часах, днях, неделях. Эти оценки в первую очередь основаны на личном опыте, предположении или интуиции. Оценивая конкретную задачу, разработчик озвучивает свое предположение, сколько бы ее выполнение заняло у него времени. И как показывает опыт - эти предположения очень редко бывают точными, потому что существует слишком много факторов, которые могут повлиять на срок выполнения задачи
Работая по Agile команды все чаще оценивают задачи в более абстрактной величине называемой story points.
❓ Что такое story point?
👉🏻 Story point — это абстрактная единица измерения, выражающая оценку общих усилий, которые необходимы для полной реализации определенного участка работы (функционала).
Ее ключевой особенностью является то, что она не привязывается к какому-то определенному времени (дни или часы разработки), а использует так называемые относительные единицы, не позволяющие определить точное время, затраченное на реализацию, но при этом помогают быстро и эффективно устанавливать приоритет задач в зависимости от их ложности.
❓Как это работает?
👉🏻 Пользуясь стори поинтами, мы присваиваем каждому элементу (работы) некое количественное значение. Сами по себе эти количественные оценки не важны. Важно то, как оценки разных элементов соотносятся друг с другом. Задача, которой присвоено значение 2, должна быть вдвое больше задачи со значением 1 и соответствовать двум третям задачам со значением 3.
Вместо единицы, двойки и тройки команда могла бы использовать цифры 100, 200 и 300. Тут важно соотношение, а не цифры как таковые.
❓ Что включают в 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
Международная аутсорсинговая 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
📌 Почему важны критерии качества;
📌 Какие критерии качества существуют;
📌 Какие критериям качества уделять больше внимания, и как это определить на практике;
📌 Как улучшить качество требований.
https://www.artofba.com/post/requirements_quality_criteria
ArtofBA
О критериях качества требований ≡ Блог ArtofBA
ВведениеТема критериев качества требований затрагивается во многих статьях и публикациях, но, к сожалению, часто сводится к перечислению критериев и определений к ним. Именно поэтому я бы хотела затронуть более практические аспекты.Поговорим о том, что такое…