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

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

Туториал для туториалов. Как написать пользовательскую документацию

Статья освещает такие темы, как:
- Что входит в пользовательскую документацию
- Советы и размышления, как написать хорошую пользовательскую документацию.

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

​​Вертикальная и горизонтальная нарезка пользовательских историй

📌 Вертикальная нарезка (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 поскольку это может указывать на то, что сценарий содержит излишнюю информацию.

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

https://vc.ru/life/315774-kak-vesti-zapisi-chtoby-vse-ponyat-i-zapomnit-chetyre-prostyh-sposoba

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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