Привет всем!
Меня зовут Анастасия. В роли бизнес-аналитика я оказалась примерно тогда же, когда эта роль появилась в ИТ. Больше 20 лет проектирую функциональность ИТ-систем и процессы. До БА работала в роли тестировщика, а еще раньше - разработчика. Сейчас продолжаю карьеру и занимаюсь менторством. Помогаю аналитикам любого уровня решать их кейсы и расти в профессии. Подробнее по ссылке.
Этот канал - попытка поделиться прочитанным и увиденным в сфере бизнес-анализа в ИТ, чтобы вам было проще ориентироваться в потоках информации.
На аватарке канала изображение от storyset на Freepik
Меня зовут Анастасия. В роли бизнес-аналитика я оказалась примерно тогда же, когда эта роль появилась в ИТ. Больше 20 лет проектирую функциональность ИТ-систем и процессы. До БА работала в роли тестировщика, а еще раньше - разработчика. Сейчас продолжаю карьеру и занимаюсь менторством. Помогаю аналитикам любого уровня решать их кейсы и расти в профессии. Подробнее по ссылке.
Этот канал - попытка поделиться прочитанным и увиденным в сфере бизнес-анализа в ИТ, чтобы вам было проще ориентироваться в потоках информации.
На аватарке канала изображение от storyset на Freepik
❤4
Спринт
Джейк Кнапп, Брейден Ковитц, Джон Зерацки. Год выхода: 2016
Книга долго находилась в моем листе ожидания. Оказалась она в этом листе во времена моего погружения в практики гибкой разработки. Когда добралась до чтения, то обнаружилось, что речь пойдет вовсе не о спринтах как их понимают ИТ-команды в Agile. Здесь термин "продукт" используется в значении "товар, любая услуга", а не в значении "услуга через ИТ-приложение".
О чем книга? О проверке гипотез за 5 рабочих дней по заданному фреймворку под названием "Спринт". Фреймворк строится на использовании прототипов и по сути похож на технику "Волшебник страны ОЗ", в которой доступными средствами за очень короткое время имитируется работа продукта или фичи.
Что может быть полезно? В "Спринте" описаны задачи по дням недели. Не уверена, что в каждом проекте будет просто соблюдать такой хронометраж, но может быть полезна описанная логика движения от формулировки проблем к протестированному решению. Авторы дают рекомендации по выполнению задач каждого дня от организации рабочего места и фасилитации встреч до критериев качества результатов. Приведены конкретные примеры из проектов для медицинской клиники, для робота-дворецкого, для Slack и некоторых других. Прототипы в этих проектах не обязательно веб-приложения или что-то их заменяющее, в книге есть примеры переоборудования помещений, продажи фич через буклет, имитации функций робота…
Кому может быть полезно? Книга может быть интересна, если вы начинаете знакомиться с проверкой гипотез через функциональные прототипы и хотите изучить конкретные случаи применения. "Спринт" вряд ли увлечет тех, кто не погружен в продуктовые исследования или наоборот погружен в них давно и всерьез.
#книжки
Джейк Кнапп, Брейден Ковитц, Джон Зерацки. Год выхода: 2016
Книга долго находилась в моем листе ожидания. Оказалась она в этом листе во времена моего погружения в практики гибкой разработки. Когда добралась до чтения, то обнаружилось, что речь пойдет вовсе не о спринтах как их понимают ИТ-команды в Agile. Здесь термин "продукт" используется в значении "товар, любая услуга", а не в значении "услуга через ИТ-приложение".
О чем книга? О проверке гипотез за 5 рабочих дней по заданному фреймворку под названием "Спринт". Фреймворк строится на использовании прототипов и по сути похож на технику "Волшебник страны ОЗ", в которой доступными средствами за очень короткое время имитируется работа продукта или фичи.
Что может быть полезно? В "Спринте" описаны задачи по дням недели. Не уверена, что в каждом проекте будет просто соблюдать такой хронометраж, но может быть полезна описанная логика движения от формулировки проблем к протестированному решению. Авторы дают рекомендации по выполнению задач каждого дня от организации рабочего места и фасилитации встреч до критериев качества результатов. Приведены конкретные примеры из проектов для медицинской клиники, для робота-дворецкого, для Slack и некоторых других. Прототипы в этих проектах не обязательно веб-приложения или что-то их заменяющее, в книге есть примеры переоборудования помещений, продажи фич через буклет, имитации функций робота…
Кому может быть полезно? Книга может быть интересна, если вы начинаете знакомиться с проверкой гипотез через функциональные прототипы и хотите изучить конкретные случаи применения. "Спринт" вряд ли увлечет тех, кто не погружен в продуктовые исследования или наоборот погружен в них давно и всерьез.
#книжки
👍2❤1
Сколько раз вы слышали или говорили что-то вроде: «Наши заказчики сами не знают, чего хотят»? Действительно ли они не знают? Как найти тех, кто знает? Записала свои мысли и пару советов тут
Дзен | Статьи
Цена термина "заказчик"
Статья автора «ПроБА» в Дзене ✍: Однажды на вебинаре я рассказывала о работе с заинтересованными сторонами (стейкхолдерами) и заметила как сложно слушателям принимать, что заинтересованные стороны -
👍3
Пролистала больше десятка профессиональных блогов. Из кучи контента (советов начинающим, рекламы консалтинга, продвижения курсов) выбрала пару статей, которые показались интересными
#что_почитать
#что_почитать
Дзен | Статьи
Что почитать?
Статья автора «ПроБА» в Дзене ✍: Пролистала больше десятка профессиональных блогов.
👍2
Оффлайн часть конференции Flow Думаю, видео докладов появятся в сети рано или поздно, поэтому не буду пересказывать. Рассказывать о каких-то неудачностях тоже не буду, их и без меня все заметят. Поделюсь самым ценным и неповторимым - впечатлениями.
День первый запомнился двумя докладами о требованиях. Сначала Сергей Нужненко напомнил, что гибкость методологий не отменяет ни требований, ни актуальности инженерии требований. А чуть позже Юрий Куприянов рассказал, что требования настолько плотно связаны с решением, что и требований никаких по сути нет, а есть придумывание решения вместе с заказчиком. Забавно, что я нашла с чем согласиться в обеих точках зрения.
📌То, что уже лет 10 профессионалам интересно обсуждать существуют ли требования, это своего рода признак, что имеется потребность как-то называть и обрабатывать вид информации, которая есть в их работе. Есть продукт, а значит есть и критерии его успеха, и ожидаемые характеристики, даже если они записаны новым способом или не записаны вовсе - это не означает, что их нет.
📌Верно и то, аналитик по сути проектирует решение на уровне, который ему доверила команда. Как сложно критерии успеха полностью “отвязать” от решения знает любой, кто пытался описать взаимодействие пользователя с решением и не использовать фраз вида “пользователь должен войти в систему и нажать кнопку”.
День второй произвел впечатление докладами по UX. День завершал доклад Дмитрия Сатина, в докладе оказался не просто рассказ о методике исследования пользователей, но и тезис Анализ без UX ⇒ Непонятые пользователи ⇒ Большие проблемы, а значит аналитикам нужно уметь исследовать опыт своих пользователей. Тема интересна не только мне, судя по тому, как участники еще почти час после доклада задавали вопросы и не отпускали спикера. Я сформулировала свои соображения, как мне казалось, в остроумный вопрос, но когда смогла добраться до микрофона, Дмитрий уже ответил на столько вопросов и столько информации прозвучало, что сил оставалось только поделиться наблюдением, какие неожиданные результаты получаются из навыков анализа в сочетании с навыками UX. Навык UX помогает видеть как неэффективно выглядят некоторые задачи с точки зрения пользовательского опыта и еще как эта неэффективность в итоге приведет к провалу вместо достижения целей. Когда аналитику поручают задачу, мало кто из руководителей ожидает услышать, что задача не поможет достичь целей и лучше ее не делать…
В общем полезными были эти два дня. #конференции
День первый запомнился двумя докладами о требованиях. Сначала Сергей Нужненко напомнил, что гибкость методологий не отменяет ни требований, ни актуальности инженерии требований. А чуть позже Юрий Куприянов рассказал, что требования настолько плотно связаны с решением, что и требований никаких по сути нет, а есть придумывание решения вместе с заказчиком. Забавно, что я нашла с чем согласиться в обеих точках зрения.
📌То, что уже лет 10 профессионалам интересно обсуждать существуют ли требования, это своего рода признак, что имеется потребность как-то называть и обрабатывать вид информации, которая есть в их работе. Есть продукт, а значит есть и критерии его успеха, и ожидаемые характеристики, даже если они записаны новым способом или не записаны вовсе - это не означает, что их нет.
📌Верно и то, аналитик по сути проектирует решение на уровне, который ему доверила команда. Как сложно критерии успеха полностью “отвязать” от решения знает любой, кто пытался описать взаимодействие пользователя с решением и не использовать фраз вида “пользователь должен войти в систему и нажать кнопку”.
День второй произвел впечатление докладами по UX. День завершал доклад Дмитрия Сатина, в докладе оказался не просто рассказ о методике исследования пользователей, но и тезис Анализ без UX ⇒ Непонятые пользователи ⇒ Большие проблемы, а значит аналитикам нужно уметь исследовать опыт своих пользователей. Тема интересна не только мне, судя по тому, как участники еще почти час после доклада задавали вопросы и не отпускали спикера. Я сформулировала свои соображения, как мне казалось, в остроумный вопрос, но когда смогла добраться до микрофона, Дмитрий уже ответил на столько вопросов и столько информации прозвучало, что сил оставалось только поделиться наблюдением, какие неожиданные результаты получаются из навыков анализа в сочетании с навыками UX. Навык UX помогает видеть как неэффективно выглядят некоторые задачи с точки зрения пользовательского опыта и еще как эта неэффективность в итоге приведет к провалу вместо достижения целей. Когда аналитику поручают задачу, мало кто из руководителей ожидает услышать, что задача не поможет достичь целей и лучше ее не делать…
В общем полезными были эти два дня. #конференции
👍2
BABOK и Инженерия требований
В блоге IIBA встретилась статья о том, что, аналитики работают с требованиями, но не всегда знают, что есть отдельная дисциплина посвященная требованиям. Если читать только BABOK, то можно упустить важные вещи. Прокомментировала от себя и получилось многобукв, поэтому детали пришлось оставить в Дзене
В блоге IIBA встретилась статья о том, что, аналитики работают с требованиями, но не всегда знают, что есть отдельная дисциплина посвященная требованиям. Если читать только BABOK, то можно упустить важные вещи. Прокомментировала от себя и получилось многобукв, поэтому детали пришлось оставить в Дзене
Дзен | Статьи
О паре заблуждений в работе аналитика
Статья автора «ПроБА» в Дзене ✍: Хочу поделиться статьей о заблуждениях в работе аналитика. Добавила немного и от себя (со значком 🔎).
👍2