Последнюю рабочую неделю в этом году начинаем с интересной статьи:
☝🏻 Что такое язык 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
ВведениеТема критериев качества требований затрагивается во многих статьях и публикациях, но, к сожалению, часто сводится к перечислению критериев и определений к ним. Именно поэтому я бы хотела затронуть более практические аспекты.Поговорим о том, что такое…
Базовая модель коммуникации в работе аналитика.
📍 Учитывая, что коммуникации занимают иногда 80 процентов рабочего времени аналитика, выстраивать её нужно грамотно, дабы максимизировать эффективность передачи информации. Не будем забывать одна из черт, которыми должен обладать хороший аналитик именно «коммуникативность» (P.S. не путаем с «коммуникабельностью»)). Коммуницировать нужно качественно, без потерь и при этом не затрачивая на это лишнее ресурсы.
👉🏻 Давайте рассмотрим базовую модель коммуникации.
➡️ Есть два участника «Отправитель» и «Получатель», которые обмениваются между собой информацией. Что же происходит дальше?
1️⃣ Отправитель кодирует сообщение, т. е. излагает сообщение на языке, предположительно понятном «Получателю».
На данном этапе не стоит забывать про проактивность. Для того, чтобы коммуникация носила в последующем эффективный характер аналитик должен осуществить кодировку на языке максимально близком «Получателю». Для команды разработки это технический язык в терминах специализации. Для Заказчика это бизнес язык в терминах доменной области бизнеса. Также нужно использовать визуальные средства, с учётом тог, что большинство людей тяжело воспринимают «сухой» текст, а именно схемы, диаграммы, флипчарты и т. д. Само собой, мысль нужно формулировать чётко, лаконично, информативно, логично и последовательно.
2️⃣ С помощью канала сообщение передаётся «Получателю». Устно, по телефону, по почте. В процессе передачи сообщения искажаются каналом коммуникации. Соответственно искажения или шум это все, что может помешать передаче и пониманию сообщения. (например, помехи во время телефонного разговора).
📌 Основная задача аналитика на данном этапе — предупредить, минимизировать возникновение шума. Для этого важно выбрать максимально эффективный канал коммуникации. Сюда же можно отнести совершенствование знание языка аналитиком, проверка телефонной связи перед разговором, выбор и тестирование микрофона для связи по Skype и т.д. Идеально, перед началом коммуникации обдумать спектр помех, и то как можно их минимизировать.
3️⃣ На стороне «Получателя» происходит декодирование информации = преобразование сообщения «Получателем» в понятные ему мысли и идеи. На успешность этого этапа аналитик вряд ли может повлиять, кроме того, как закодировать сообщение таким образом, чтобы максимально облегчить декодировку.
4️⃣ В хорошем процессе коммуникации также присутствует обратная связь. Т.е. обратное сообщение об успешности декодировки и приёма исходного сообщения. (Например, ответ по электронной почте, о том, что сообщение получено)
☝🏻 Важно:
📌 обратная связь должна быть. Аналитик должен простимулировать «Получателя» дать обратную связь;
📌 использование обратной связи помогает скорректировать коммуникацию. Во время устного общения полезно следить за невербаликой (менять тон, темп). После презентации документации требований разработчикам крайне продуктивным является назначение митинга с целью получить обратную связь и оценить восприятие документа командой и, возможно внести правки для улучшения этого самого восприятия.
📍Не стоит забывать, что за все коммуникации на проекте отвечает именно аналитик. Выстраивайте коммуникации правильно!
📍 Учитывая, что коммуникации занимают иногда 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-методологии.
Если вы знаете еще хорошие книги, можете поделиться ими в комментариях.
👉🏻 Если вы хотите пополнить свои знания в сфере 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/
https://habr.com/ru/post/599175/
Хабр
Мозговой штурм не работает. Почему его до сих пор используют?
Давайте представим себе ситуацию: группе экспертов нужно решить сложную задачу. Она необычная и не решается стандартными способами. Одна из самых распространённых методик поиска решения таких задач —...
Сегодня поговорим о такой важном артефакте, как контекстная диаграмма.
👉🏻 Контекстная диаграмма - это диаграмма, которая используется для общего описания системы и описания ее взаимодействия с внешней средой. Диаграмма отображает интерфейс проектируемой системы с внешним миром, а именно, потоки данных между системой и внешними сущностями, с которыми она взаимодействует. Создается в начале проекта и представляет всю систему, как единый процесс.
🖍 Для построения контекстной диаграммы используется в основном нотация IDEF0 и DFD.
🖍 Цели построения диаграммы:
✔️ определить границы системы;
✔️ выявить функциональные требования, основываясь на входящий и исходящих потоках данных.
🖍 Элементы контекстной диаграммы:
✔️ проектируемый объект (система) - отображается в виде круга/овала;
✔️ внешние сущности, взаимодействующие с проектируемым объектом (пользователи, смежные системы) - отображаются в виде прямоугольников;
✔️ потоки данных (исходящие и входящие) - отображаются в виде стрелок.
🖍 Шаги построения диаграммы:
1️⃣ Запишите название проектируемой системы в центре;
2️⃣ Запишите внешние сущности, которые взаимодействуют с проектируемой системой вокруг проектируемой системы;
3️⃣ Укажите входящие и исходящие потоки данных между проектируемой системой и внешними сущностями с помощью стрелок;
3️⃣ Добавьте комментарий к потокам данных: детализируйте входящие и исходящие данные.
🖍 Онлайн-инструменты для создания контекстной диаграммы:
✔️ Google Draw,
✔️ Draw.io,
✔️ Miro.
- Рисунок контекстной диаграммы взят из интернета.
👉🏻 Контекстная диаграмма - это диаграмма, которая используется для общего описания системы и описания ее взаимодействия с внешней средой. Диаграмма отображает интерфейс проектируемой системы с внешним миром, а именно, потоки данных между системой и внешними сущностями, с которыми она взаимодействует. Создается в начале проекта и представляет всю систему, как единый процесс.
🖍 Для построения контекстной диаграммы используется в основном нотация 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 может стать мощным инструментом в арсенале любого БА, позволяя ему предлагать релевантные решения и создавать по-настоящему качественные и успешные продукты.
➡️ 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 может стать мощным инструментом в арсенале любого БА, позволяя ему предлагать релевантные решения и создавать по-настоящему качественные и успешные продукты.
Используете ли Вы Lean Canvas в своей работе?
Anonymous Poll
5%
Да, постоянно
20%
Один-пару раз за свою практику
23%
Нет, но хочу использовать
15%
Нет, мне это не нужно
38%
Нет,я даже не знал(а) про этот инструмент
Маечная система оценок👕. Что это и как
Использование размеров футболок для оценки проектов
👉🏻 В руководстве по 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.
Использование размеров футболок для оценки проектов
👉🏻 В руководстве по 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.
Нужно ли бизнес-аналитику уметь писать код❓
Статья размышление от системного аналитика Ерслана Аймакова.
❓ Один из весьма популярных вопросов у кандидатов на позиции IT-аналитика и у некоторых работодателей – должны ли они ожидать от такого сотрудника умения писать или хотя бы читать программный код на каком-либо языке программирования? По моему скромному мнению, короткий ответ – нет.
☝🏻 В этом месте каждая уважающая себя статья начинает новое предложение с громкого «НО!». Конечно же, умение писать и, соответственно, читать программный код никогда не будет лишним для любого IT-специалиста. Но давайте для начала все-таки разберем навыки, близкие к умению писать код, без которых хорошему аналитику все-же не обойтись:
👉🏻 Умение писать SQL-запросы. Основы искусства обращения к базам данных с помощью «языка» SQL – скилл, необходимый каждому аналитику, поскольку все мы так или иначе работаем с данными, хранимыми и обрабатываемыми посредством той или иной СУБД, и умение эти данные «вытаскивать» необходимо для решения большинства из каждодневных задач, стоящих перед аналитиком. Это еще не программирование, но уже солидный «хард-скилл», повышающий ваши конкурентные преимущества на рынке труда.
👉🏻 Знание API и умение работать с типами данных. На карьерном пути аналитика вам неизбежно придется столкнуться с интеграциями между информационными системами или модулями одной системы, а значит – работать с веб-сервисами – посредниками, передающими информацию от одной системы к другой с помощью сообщений, например, структурированных в виде популярных форматов JSON или XML.
Часто эта информация впоследствии должна быть помещена в базу данных. Сущности в сообщениях или полях базы представляют из себя набор полей, содержащих некие типизированные значения – например, если это числа – тип может быть целочисленным или с плавающей запятой, если это строка – она может иметь ограниченное количество символов, а может вам необходимо передать список из нескольких значений – и на это тоже есть свой тип данных.
В общем, если коротко – без знания типов и форматов данных, а также знание принципов работы API аналитику не обойтись. А обладая этими знаниями, вы можете считать, что находитесь на первом шаге изучения любого языка программирования!
👉🏻 Умение грамотно поставить задачу на разработку. Как аналитик, вы должны уметь поставить грамотную задачу на разработку – то есть, как минимум, расписать алгоритм работы вашей «фичи» - с чего должен начинаться процесс, какими должны быть входные и выходные данные, как должна обрабатываться информация.
Не так важно в каком формате вы это опишете, важно максимально прозрачно описать все шаги алгоритма, используя, к примеру, условия «Если – То – Иначе», описание обработки данных с помощью циклов, или «маппинг данных» - например, в какое поле базы данных мы должны поместить значение, полученное от сервиса-партнера.
➡️Если вы являетесь специалистом, которые умеет составить грамотную постановку задачи, считайте, что вы уже умеете программировать на базовом уровне – дело осталось за малым – начать изучать синтаксис того или иного языка!
📃 В заключение, хочется сказать, что любой опытный бизнес или системный аналитик уже близок к тому, чтобы усвоить какой-либо язык программирования. 💻Хорошим кандидатом для первого языка программирования является Python – изучив его, вы не только существенно повысите свою компетенцию в качестве БА/СА, но и можете продолжить свое развитие в сторону аналитика данных или специалиста в сфере машинного обучения.
Статья размышление от системного аналитика Ерслана Аймакова.
❓ Один из весьма популярных вопросов у кандидатов на позиции IT-аналитика и у некоторых работодателей – должны ли они ожидать от такого сотрудника умения писать или хотя бы читать программный код на каком-либо языке программирования? По моему скромному мнению, короткий ответ – нет.
☝🏻 В этом месте каждая уважающая себя статья начинает новое предложение с громкого «НО!». Конечно же, умение писать и, соответственно, читать программный код никогда не будет лишним для любого IT-специалиста. Но давайте для начала все-таки разберем навыки, близкие к умению писать код, без которых хорошему аналитику все-же не обойтись:
👉🏻 Умение писать SQL-запросы. Основы искусства обращения к базам данных с помощью «языка» SQL – скилл, необходимый каждому аналитику, поскольку все мы так или иначе работаем с данными, хранимыми и обрабатываемыми посредством той или иной СУБД, и умение эти данные «вытаскивать» необходимо для решения большинства из каждодневных задач, стоящих перед аналитиком. Это еще не программирование, но уже солидный «хард-скилл», повышающий ваши конкурентные преимущества на рынке труда.
👉🏻 Знание API и умение работать с типами данных. На карьерном пути аналитика вам неизбежно придется столкнуться с интеграциями между информационными системами или модулями одной системы, а значит – работать с веб-сервисами – посредниками, передающими информацию от одной системы к другой с помощью сообщений, например, структурированных в виде популярных форматов JSON или XML.
Часто эта информация впоследствии должна быть помещена в базу данных. Сущности в сообщениях или полях базы представляют из себя набор полей, содержащих некие типизированные значения – например, если это числа – тип может быть целочисленным или с плавающей запятой, если это строка – она может иметь ограниченное количество символов, а может вам необходимо передать список из нескольких значений – и на это тоже есть свой тип данных.
В общем, если коротко – без знания типов и форматов данных, а также знание принципов работы API аналитику не обойтись. А обладая этими знаниями, вы можете считать, что находитесь на первом шаге изучения любого языка программирования!
👉🏻 Умение грамотно поставить задачу на разработку. Как аналитик, вы должны уметь поставить грамотную задачу на разработку – то есть, как минимум, расписать алгоритм работы вашей «фичи» - с чего должен начинаться процесс, какими должны быть входные и выходные данные, как должна обрабатываться информация.
Не так важно в каком формате вы это опишете, важно максимально прозрачно описать все шаги алгоритма, используя, к примеру, условия «Если – То – Иначе», описание обработки данных с помощью циклов, или «маппинг данных» - например, в какое поле базы данных мы должны поместить значение, полученное от сервиса-партнера.
➡️Если вы являетесь специалистом, которые умеет составить грамотную постановку задачи, считайте, что вы уже умеете программировать на базовом уровне – дело осталось за малым – начать изучать синтаксис того или иного языка!
📃 В заключение, хочется сказать, что любой опытный бизнес или системный аналитик уже близок к тому, чтобы усвоить какой-либо язык программирования. 💻Хорошим кандидатом для первого языка программирования является Python – изучив его, вы не только существенно повысите свою компетенцию в качестве БА/СА, но и можете продолжить свое развитие в сторону аналитика данных или специалиста в сфере машинного обучения.
А как вы думаете, нужно ли бизнес аналитику знать языки программирования?
Anonymous Poll
4%
Да, нужны глубокие знания одного/двух языков
44%
Да, но нужны только поверхностные знания
24%
Нет, это не нужно, но я бы все равно хотел(а) бы уметь кодить
11%
Нет, считаю это совершенно лишним
17%
Хочу просто посмотреть ответы
Интересная статья, как понять и объяснить, что такое RACI матрица простыми словами.☝🏻
https://habr.com/ru/company/timeweb/blog/597281/
https://habr.com/ru/company/timeweb/blog/597281/
Хабр
«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица
Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала...
❗️ Дорогие друзья!
👉🏻 Andersen запускает новый формат встреч - BA Talks!
11 февраля приглашаем в Ивент-пространство "30th Floor" на офлайн-мероприятие, где в уютной и неформальной обстановке мы вместе обсудим актуальные для бизнес-аналитиков темы, послушаем выступления классных спикеров и поделимся своими инсайтами!
Вас ожидают:
📌 доклад от ведущего аналитика и эксперта в домене Healthcare Виталия Бирченко о подготовке к международным конференциям;
📌 доклад от руководителя департамента BA и SA Марии Боярко о том, каким хотят видеть бизнес-аналитика заказчики;
📌 обсуждение тем и нетворкинг с участниками;
📌 интерактив и подарки от Andersen;
📌 угощения и напитки.
🔥 Гарантируем прекрасное настроение и отличную мотивацию для профессионального развития!
📅 Когда: 11 февраля 19:00
🏬 Где: Ивент-пространство "30th Floor" г.Минск, пр-т Победителей 7а, 30-й этаж
✏️ Регистрация тут: https://forms.gle/1BNsLABKD9ZQuQAR6
Советуем поторопиться, ведь количество мест ограничено!
До встречи на BA Talks в Andersen!
👉🏻 Andersen запускает новый формат встреч - BA Talks!
11 февраля приглашаем в Ивент-пространство "30th Floor" на офлайн-мероприятие, где в уютной и неформальной обстановке мы вместе обсудим актуальные для бизнес-аналитиков темы, послушаем выступления классных спикеров и поделимся своими инсайтами!
Вас ожидают:
📌 доклад от ведущего аналитика и эксперта в домене Healthcare Виталия Бирченко о подготовке к международным конференциям;
📌 доклад от руководителя департамента BA и SA Марии Боярко о том, каким хотят видеть бизнес-аналитика заказчики;
📌 обсуждение тем и нетворкинг с участниками;
📌 интерактив и подарки от Andersen;
📌 угощения и напитки.
🔥 Гарантируем прекрасное настроение и отличную мотивацию для профессионального развития!
📅 Когда: 11 февраля 19:00
🏬 Где: Ивент-пространство "30th Floor" г.Минск, пр-т Победителей 7а, 30-й этаж
✏️ Регистрация тут: https://forms.gle/1BNsLABKD9ZQuQAR6
Советуем поторопиться, ведь количество мест ограничено!
До встречи на BA Talks в Andersen!
👍1