Интервью на удаленке. Чтобы удалось, надо пробовать и сегодня, и завтра, и послезавтра
#кейс #опыт
Работа бизнес-аналитика до некоторого времени строилась только на очных встречах и бонусом это давало возможность съездить в интересные командировки. Теперь я большинство интервью ставлю он-лайн и в этом формате оказалось тоже много преимуществ. В последнее время занимаюсь исследовательской задачей и провожу серию интервью с пользователями, поэтому вспомнила об этих преимуществах.
🔅 Я не идеальный интервьюер и в разговоре не всегда держу покер-фейс, могу невольно влиять на собеседника то кивком головы, то своими «ага» и «ну да». Ограниченный личный контакт помогает это компенсировать
🔅 Даже интроверты чувствуют себя в безопасности и неплохо общаются, когда сидят в удобном знакомом кресле, а не где-то в переговорке, где будет сложно встать и уйти
🔅 В моем опыте чаще всего те, кто согласился на он-лайн интервью, не возражают против записи встречи, а значит можно сосредоточиться на общении, а не на заметках в блокноте
🔅Мне проще не слишком явно для собеседника заглянуть в список вопросов на соседнем экране. На очной встрече взгляд в список вопросов может вызвать настороженность собеседника отчего он начнет отвечать цитатами из инструкций
🔅В разговоре собеседник легко может показать рабочий экран, если считает это важным. При необходимости я тоже могу наглядно поделиться пользовательским опытом даже если не готовилась специально
🔅 Не нужно искать переговорку и в целом можно поговорить с пользователями из разных офисов и разных городов
Чтобы все это действительно работало именно так, нужно немного подготовиться и выполнить несколько шагов. Нарисовала их на карточках. Надеюсь, пригодится тем, кто пока еще редко интервьюирует 🌱
#кейс #опыт
Работа бизнес-аналитика до некоторого времени строилась только на очных встречах и бонусом это давало возможность съездить в интересные командировки. Теперь я большинство интервью ставлю он-лайн и в этом формате оказалось тоже много преимуществ. В последнее время занимаюсь исследовательской задачей и провожу серию интервью с пользователями, поэтому вспомнила об этих преимуществах.
🔅 Я не идеальный интервьюер и в разговоре не всегда держу покер-фейс, могу невольно влиять на собеседника то кивком головы, то своими «ага» и «ну да». Ограниченный личный контакт помогает это компенсировать
🔅 Даже интроверты чувствуют себя в безопасности и неплохо общаются, когда сидят в удобном знакомом кресле, а не где-то в переговорке, где будет сложно встать и уйти
🔅 В моем опыте чаще всего те, кто согласился на он-лайн интервью, не возражают против записи встречи, а значит можно сосредоточиться на общении, а не на заметках в блокноте
🔅Мне проще не слишком явно для собеседника заглянуть в список вопросов на соседнем экране. На очной встрече взгляд в список вопросов может вызвать настороженность собеседника отчего он начнет отвечать цитатами из инструкций
🔅В разговоре собеседник легко может показать рабочий экран, если считает это важным. При необходимости я тоже могу наглядно поделиться пользовательским опытом даже если не готовилась специально
🔅 Не нужно искать переговорку и в целом можно поговорить с пользователями из разных офисов и разных городов
Чтобы все это действительно работало именно так, нужно немного подготовиться и выполнить несколько шагов. Нарисовала их на карточках. Надеюсь, пригодится тем, кто пока еще редко интервьюирует 🌱
👍7🔥1
Какие вопросы?
#кейс #интервью
Задавать вопросы — это основной способ сбора информации и один из важных навыков аналитика. Существуют разные виды вопросов. Наиболее простая классификация выделяет вопросы: закрытые и открытые. Открытые вопросы начинаются с вопросительных слов: "кто", "что", "где", "когда", "как", "почему". Они помогают получить развёрнутые ответы и новые знания, в отличие от закрытых вопросов, на которые можно получить только односложный ответ (Да или Нет). Чем больше открытых вопросов будет задано в интервью, тем больше информации можно получить.
Это выглядит совершенно базовым знанием (а так и есть), при этом знать и иметь навык совсем не одно и то же. Когда вы сидите перед респондентом и у вас несколько секунд, чтобы сформулировать вопрос, легко ли вам выбрать именно открытый вопрос? Я знаю за собой такую черту — я быстро сбиваюсь на закрытые вопросы, если я устала, волнуюсь или что-то отвлекло. Это потому, что навык открытых вопросов даже за 6 лет применения еще не стал совсем базовым в моей голове. В ИТ очень долго было принято задавать закрытые вопросы, чтобы быстрее подтвердить ожидаемое решение и заказчик «не придумал лишнего». Это приемлемо, если вам нужно подтвердить уже обсужденные договоренности, но совсем не годится для понимания контекста задачи и потребностей заинтересованных сторон.
Чтобы сформировать навык можно потренироваться закрытые вопросы переформулировать в открытые.
🔸Закрытый вопрос: Должен ли пользователь вводить пароль?
🔸 Открытый вопрос: Как пользователю будет предоставляться доступ к данным?
Может быть много вариантов открытых вопросов для одного и того же закрытого. Давайте потренируемся? Переформулируйте вопрос, чтобы придать ему открытость: Должна ли система автоматически сохранять результаты работы пользователя каждые 15 минут?
Напишите в комментариях вашу версию открытого вопроса и/или поставьте лайк понравившейся версии. Завтра подсчитаем лайки и выберем Топ-3 варианта👍
#кейс #интервью
Задавать вопросы — это основной способ сбора информации и один из важных навыков аналитика. Существуют разные виды вопросов. Наиболее простая классификация выделяет вопросы: закрытые и открытые. Открытые вопросы начинаются с вопросительных слов: "кто", "что", "где", "когда", "как", "почему". Они помогают получить развёрнутые ответы и новые знания, в отличие от закрытых вопросов, на которые можно получить только односложный ответ (Да или Нет). Чем больше открытых вопросов будет задано в интервью, тем больше информации можно получить.
Это выглядит совершенно базовым знанием (а так и есть), при этом знать и иметь навык совсем не одно и то же. Когда вы сидите перед респондентом и у вас несколько секунд, чтобы сформулировать вопрос, легко ли вам выбрать именно открытый вопрос? Я знаю за собой такую черту — я быстро сбиваюсь на закрытые вопросы, если я устала, волнуюсь или что-то отвлекло. Это потому, что навык открытых вопросов даже за 6 лет применения еще не стал совсем базовым в моей голове. В ИТ очень долго было принято задавать закрытые вопросы, чтобы быстрее подтвердить ожидаемое решение и заказчик «не придумал лишнего». Это приемлемо, если вам нужно подтвердить уже обсужденные договоренности, но совсем не годится для понимания контекста задачи и потребностей заинтересованных сторон.
Чтобы сформировать навык можно потренироваться закрытые вопросы переформулировать в открытые.
🔸Закрытый вопрос: Должен ли пользователь вводить пароль?
🔸 Открытый вопрос: Как пользователю будет предоставляться доступ к данным?
Может быть много вариантов открытых вопросов для одного и того же закрытого. Давайте потренируемся? Переформулируйте вопрос, чтобы придать ему открытость: Должна ли система автоматически сохранять результаты работы пользователя каждые 15 минут?
Напишите в комментариях вашу версию открытого вопроса и/или поставьте лайк понравившейся версии. Завтра подсчитаем лайки и выберем Топ-3 варианта
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Открытые вопросы
#кейс #что_почитать #субботнее #интервью
Подведем итоги вчерашнего кейса. Тут я должна признаться, что задачка взята из книги Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения»
❓Автор предлагает переформулировать вопрос «Должна ли система автоматически сохранять результаты работы пользователя каждые 15 минут?» в «Что пользователи будут делать, если система "упадет" во время их работы в ней?» В таком типе вопросов я вижу нюанс из-за которого не назвала бы их универсальными. Вопросы вида «Что будут делать» и «Как должно работать» вынуждают собеседника проектировать решение и/или строить предположения о будущем. Не всегда респондент имеет достаточно насмотренности или экспертизы в ИТ-решениях, чтобы сказать что-то действительно отвечающее его реальным потребностям. Часто в ответ вам предложат решение, не потому, что оно хорошо отвечает задачам пользователей, а просто говорящий где-то его видел и считает интересным. В итоге аналитик рискует потратить время на разбор этой информации или пойти по ложному пути.
🔅 В комментариях таких вариантов оказалось большинство. Они вполне применимы с условием, что вы имеете представление о знаниях собеседника, сможете дальше развить разговор и объективно проверить результаты:
• Как часто должна система сохранять результаты работы?
• Как система должна вести себя в отношении возможной потери результатов работы пользователя в случае сбоя или ошибки?
• Кто должен выполнять сохранение результатов работы пользователя, учитывая возможность нештатных ситуаций?
• Как на ваш взгляд должны сохраняться введенные данные?
❓Когда разбирала варианты ответов, вспомнила еще одну книгу: Синди Альварес «Как создать продукт, который купят». В этой книге есть пример, в котором автор проговорила с респондентом как важна для него безопасность данных. А после
Если вам почему-то нужно спросить об ожиданиях или намерениях собеседника, то нужно помнить, что его реальное поведение и контекст задачи могут в реальности отличаться от ожиданий.
🔅Вас может подвести формулировка «Достаточно ли, чтобы каждые 15 минут в системе сохранялись результаты вашей работы?». Не только потому, что по сути она закрытая и наводит на конкретный вариант решения, но и потому, что ответ чаще всего будет из области предположений и ожиданий.
❓Ваша задача на интервью понять особенности деятельности собеседника, его реальное поведение и контекст задачи. Ожидания и понимание решения он скорее всего постарается вам сообщить и без дополнительных вопросов. Поэтому в общем случае лучше спросить о том, с чем он реально сталкивается, а не о том, что он собирается делать или думает, что ему нужно делать. Мой вариант такой переформулировки: «Как вы действуете, если во время работы пропадает доступ к данным? Как происходит процесс ввода информации?»
🔅В комментариях были похожие формулировки и они набрали больше лайков (хотя там есть про ожидания, лучше спросить «как вы действуете, когда...»): Какую часть информации вы готовы потерять в случае сбоя при длительном редактировании документа? какие ваши ожидания, если вы начали редактировать документ, сделали перерыв на обед, и потом вернулись к редактированию?
#кейс #что_почитать #субботнее #интервью
Подведем итоги вчерашнего кейса. Тут я должна признаться, что задачка взята из книги Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения»
❓Автор предлагает переформулировать вопрос «Должна ли система автоматически сохранять результаты работы пользователя каждые 15 минут?» в «Что пользователи будут делать, если система "упадет" во время их работы в ней?» В таком типе вопросов я вижу нюанс из-за которого не назвала бы их универсальными. Вопросы вида «Что будут делать» и «Как должно работать» вынуждают собеседника проектировать решение и/или строить предположения о будущем. Не всегда респондент имеет достаточно насмотренности или экспертизы в ИТ-решениях, чтобы сказать что-то действительно отвечающее его реальным потребностям. Часто в ответ вам предложат решение, не потому, что оно хорошо отвечает задачам пользователей, а просто говорящий где-то его видел и считает интересным. В итоге аналитик рискует потратить время на разбор этой информации или пойти по ложному пути.
🔅 В комментариях таких вариантов оказалось большинство. Они вполне применимы с условием, что вы имеете представление о знаниях собеседника, сможете дальше развить разговор и объективно проверить результаты:
• Как часто должна система сохранять результаты работы?
• Как система должна вести себя в отношении возможной потери результатов работы пользователя в случае сбоя или ошибки?
• Кто должен выполнять сохранение результатов работы пользователя, учитывая возможность нештатных ситуаций?
• Как на ваш взгляд должны сохраняться введенные данные?
❓Когда разбирала варианты ответов, вспомнила еще одну книгу: Синди Альварес «Как создать продукт, который купят». В этой книге есть пример, в котором автор проговорила с респондентом как важна для него безопасность данных. А после
предложила ему $50, если он напишет девичью фамилии своей матери и номер карты социального страхования. Не раздумывая, тот достал шариковую ручку и потянулся к листу бумаги.
Если вам почему-то нужно спросить об ожиданиях или намерениях собеседника, то нужно помнить, что его реальное поведение и контекст задачи могут в реальности отличаться от ожиданий.
🔅Вас может подвести формулировка «Достаточно ли, чтобы каждые 15 минут в системе сохранялись результаты вашей работы?». Не только потому, что по сути она закрытая и наводит на конкретный вариант решения, но и потому, что ответ чаще всего будет из области предположений и ожиданий.
❓Ваша задача на интервью понять особенности деятельности собеседника, его реальное поведение и контекст задачи. Ожидания и понимание решения он скорее всего постарается вам сообщить и без дополнительных вопросов. Поэтому в общем случае лучше спросить о том, с чем он реально сталкивается, а не о том, что он собирается делать или думает, что ему нужно делать. Мой вариант такой переформулировки: «Как вы действуете, если во время работы пропадает доступ к данным? Как происходит процесс ввода информации?»
🔅В комментариях были похожие формулировки и они набрали больше лайков (хотя там есть про ожидания, лучше спросить «как вы действуете, когда...»): Какую часть информации вы готовы потерять в случае сбоя при длительном редактировании документа? какие ваши ожидания, если вы начали редактировать документ, сделали перерыв на обед, и потом вернулись к редактированию?
👍3❤1
Действие и его отмена
#кейс #мысливслух
По мотивам кейса про открытые вопросы, где мы обсуждали вопрос про автосохранение данных, вспомнила еще один.
Недавно видела систему, где автосохранение работает, но не реализована отмена изменений. То есть пользователь не может нажать Ctrl+Z или вернуться к предыдущей версии документа, если что-то изменил ошибочно. Любое изменение будет автоматически сохранено. Нажал случайно кнопку и….изменения применены без возможности «откатиться». Исправить ситуацию можно только если получится вспомнить «как было». Чтобы удобнее было вспомнить, пользователи хранят много экземпляров одного и того же документа.
Задумалась, какая ошибка могла привести к такому результату? Я не знакома с авторами фичи, поэтому остается предполагать, что
📍Работа началась с дизайна на основании слов пользователей, а не с проектирования функций. Дизайнер предложил интерфейс, знакомый ему по Figma, отмену изменений не описал в дизайне или посчитал «само-собой разумеющимся». Аналитик не посмотрел как работают аналогичные подходы;
📍При работе с заинтересованными сторонами и при проектировании аналитик упустил сценарий с отменой действия, требования были неполными. При согласовании этот момент потерялся, так как согласователям сложно было в куче слов на куче страниц понять, что там есть;
📍Нужный сценарий был заложен, но с низким приоритетом. Реализацию отложили, запустились без нее, ведь фокус был именно на сроках запуска. Теперь задача уже потерялась в бэклоге.
Это я к тому, что, хотя не каждое решение зависит именно от аналитика, все же его экспертность решает многое в работе наших пользователей (а иногда эти пользователи - мы сами). На всякий случай внесите в ваш чек-лист вопросов для интервью не нуждается ли действие в возможности его отменить?
Хорошего всем понедельника и отличной недели!😉
#кейс #мысливслух
По мотивам кейса про открытые вопросы, где мы обсуждали вопрос про автосохранение данных, вспомнила еще один.
Недавно видела систему, где автосохранение работает, но не реализована отмена изменений. То есть пользователь не может нажать Ctrl+Z или вернуться к предыдущей версии документа, если что-то изменил ошибочно. Любое изменение будет автоматически сохранено. Нажал случайно кнопку и….изменения применены без возможности «откатиться». Исправить ситуацию можно только если получится вспомнить «как было». Чтобы удобнее было вспомнить, пользователи хранят много экземпляров одного и того же документа.
Задумалась, какая ошибка могла привести к такому результату? Я не знакома с авторами фичи, поэтому остается предполагать, что
📍Работа началась с дизайна на основании слов пользователей, а не с проектирования функций. Дизайнер предложил интерфейс, знакомый ему по Figma, отмену изменений не описал в дизайне или посчитал «само-собой разумеющимся». Аналитик не посмотрел как работают аналогичные подходы;
📍При работе с заинтересованными сторонами и при проектировании аналитик упустил сценарий с отменой действия, требования были неполными. При согласовании этот момент потерялся, так как согласователям сложно было в куче слов на куче страниц понять, что там есть;
📍Нужный сценарий был заложен, но с низким приоритетом. Реализацию отложили, запустились без нее, ведь фокус был именно на сроках запуска. Теперь задача уже потерялась в бэклоге.
Это я к тому, что, хотя не каждое решение зависит именно от аналитика, все же его экспертность решает многое в работе наших пользователей (а иногда эти пользователи - мы сами). На всякий случай внесите в ваш чек-лист вопросов для интервью не нуждается ли действие в возможности его отменить?
Хорошего всем понедельника и отличной недели!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Полезности и интересности
#что_почитать
🗃В первой части этой подборки статьи о конкретных инструментах анализа, только поэтому они встретились в этом списке
📍Power of wireframes (EN) статья про то, чем полезны простые наброски элементов интерфейса. Есть пример, рассказ об уровнях детализации и о чем стоит подумать, когда начинаешь их рисовать
📍What is data mapping? (EN) если коротко, то Data Mapping – это инструмент для описания в одной таблице объектов данных из разных источников с разными потребителями и разными правилами обработки. В статье есть пример и рассуждения, чем такая карта полезна для проектирования моделей данных
📍Use Cases and Scenarios (EN) само по себе описание вариантов использования сложно назвать чем-то новым, понравилось, что в статье есть пример, а это может быть полезно
🗃Еще пара статей на тему использования ИИ. Не уверена, что очень полезно, но может быть интересно
📍Эра ИИ и генеративного дизайна в интерфейсах. Что нас ждёт? эта статья на Хабре понравилась описанием вариантов использования генеративного дизайна и списком ссылок на инструменты дизайна с ИИ в завершении
📍Prompt Structure in Conversations with Generative AI (EN) в Norman Nielsen Group провели дневниковое иcследование с 18 пользователями (то есть в течении двух недель участники записывали свои действия и наблюдения при использовании ИИ-чатботов), проанализировали 400+ запросов к ChatGPT 4.0, Bard, and Bing Chat, провели глубинные интервью с 14 участниками. В этой статье выводы о структуре запросов и поведении пользователей
#что_почитать
🗃В первой части этой подборки статьи о конкретных инструментах анализа, только поэтому они встретились в этом списке
📍Power of wireframes (EN) статья про то, чем полезны простые наброски элементов интерфейса. Есть пример, рассказ об уровнях детализации и о чем стоит подумать, когда начинаешь их рисовать
📍What is data mapping? (EN) если коротко, то Data Mapping – это инструмент для описания в одной таблице объектов данных из разных источников с разными потребителями и разными правилами обработки. В статье есть пример и рассуждения, чем такая карта полезна для проектирования моделей данных
📍Use Cases and Scenarios (EN) само по себе описание вариантов использования сложно назвать чем-то новым, понравилось, что в статье есть пример, а это может быть полезно
🗃Еще пара статей на тему использования ИИ. Не уверена, что очень полезно, но может быть интересно
📍Эра ИИ и генеративного дизайна в интерфейсах. Что нас ждёт? эта статья на Хабре понравилась описанием вариантов использования генеративного дизайна и списком ссылок на инструменты дизайна с ИИ в завершении
📍Prompt Structure in Conversations with Generative AI (EN) в Norman Nielsen Group провели дневниковое иcследование с 18 пользователями (то есть в течении двух недель участники записывали свои действия и наблюдения при использовании ИИ-чатботов), проанализировали 400+ запросов к ChatGPT 4.0, Bard, and Bing Chat, провели глубинные интервью с 14 участниками. В этой статье выводы о структуре запросов и поведении пользователей
👍2
Как я растила деревья в PlantUML
#кейс #что_почитать
На этой неделе мне понадобилось построить графически иерархию из нескольких десятков узлов и я решила посмотреть на PlantUML. Не то чтобы я совсем не знала об этом инструменте, но видела до этого только в чужих руках, а своими попробовала буквально вчера. Делюсь впечатлениями.
🔅Первое радостное открытие, что это не только про UML. Можно строить MindMap, деревья в формате диаграммы WBS, диаграммы Ганта и кое что еще
🔅Действительно можно не заморачиваться выравниванием стрелочек, типовые диаграммы отрисовываются и выравниваются вполне прилично
🔅Можно унести в файле, интегрировать подход в разные инструменты. Например, построить контроль версии в GitHub в случае командного использования
🔅Освоить можно действительно быстро (мне хватило 20-30 мин, чтобы получить первые результаты), особенно, если вы знакомы с Markdown или HTML. Народ много пишет статей и приводит примеры. Мне пригодилась эта статья на Хабре и очень пригодились материалы тьюториалов и форума тут
Оценила и недостатки:
🙅Не подойдет для сложных, нетиповых диаграмм (например, некоторых архитектурных). Я попробовала нарисовать перекрестные стрелки между узлами двух разных уровней иерархии и оказалось, что это неудобно и некрасиво делается
🙅Как и в любом коде имеется изрядная чувствительность к ошибкам, которые плагин в Confluence не очень хорошо умеет подсвечивать. Лишние пробелы, забытые точки с запятой, незакрытые тэги и фигурные скобки… «бумага» это все терпит, а тут придется отлаживать. Если работать в плагине для Confluence, то сообщение об ошибке вы увидите только нажав «Сохранить» и это весьма затратно и неудобно.
В итоге я построила пару MindMap и WBS диаграмму из трех десятков узлов, пришлось прописать стили, чтобы добиться желаемого внешнего вида элементов, но все получилось сравнительно быстро для первого опыта. В целом PlantUML мне показался очень удобным инструментом для многоуровневых и при этом типовых схем (особенно, если вам нужно работать с ними не только в Confluence). Не могу посоветовать для сложных схем, так как есть ограничения. А еще словила порцию вежливого негатива от коллег, соответственно человеческой природе сопротивляющихся новому, и подумала, что если задаться целью внедрить новую технику в команде, то нужно готовить красивые примеры и веские аргументы😶🌫️
#кейс #что_почитать
На этой неделе мне понадобилось построить графически иерархию из нескольких десятков узлов и я решила посмотреть на PlantUML. Не то чтобы я совсем не знала об этом инструменте, но видела до этого только в чужих руках, а своими попробовала буквально вчера. Делюсь впечатлениями.
🔅Первое радостное открытие, что это не только про UML. Можно строить MindMap, деревья в формате диаграммы WBS, диаграммы Ганта и кое что еще
🔅Действительно можно не заморачиваться выравниванием стрелочек, типовые диаграммы отрисовываются и выравниваются вполне прилично
🔅Можно унести в файле, интегрировать подход в разные инструменты. Например, построить контроль версии в GitHub в случае командного использования
🔅Освоить можно действительно быстро (мне хватило 20-30 мин, чтобы получить первые результаты), особенно, если вы знакомы с Markdown или HTML. Народ много пишет статей и приводит примеры. Мне пригодилась эта статья на Хабре и очень пригодились материалы тьюториалов и форума тут
Оценила и недостатки:
🙅Не подойдет для сложных, нетиповых диаграмм (например, некоторых архитектурных). Я попробовала нарисовать перекрестные стрелки между узлами двух разных уровней иерархии и оказалось, что это неудобно и некрасиво делается
🙅Как и в любом коде имеется изрядная чувствительность к ошибкам, которые плагин в Confluence не очень хорошо умеет подсвечивать. Лишние пробелы, забытые точки с запятой, незакрытые тэги и фигурные скобки… «бумага» это все терпит, а тут придется отлаживать. Если работать в плагине для Confluence, то сообщение об ошибке вы увидите только нажав «Сохранить» и это весьма затратно и неудобно.
В итоге я построила пару MindMap и WBS диаграмму из трех десятков узлов, пришлось прописать стили, чтобы добиться желаемого внешнего вида элементов, но все получилось сравнительно быстро для первого опыта. В целом PlantUML мне показался очень удобным инструментом для многоуровневых и при этом типовых схем (особенно, если вам нужно работать с ними не только в Confluence). Не могу посоветовать для сложных схем, так как есть ограничения. А еще словила порцию вежливого негатива от коллег, соответственно человеческой природе сопротивляющихся новому, и подумала, что если задаться целью внедрить новую технику в команде, то нужно готовить красивые примеры и веские аргументы
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Про процессы
#мысливслух
В прошлые выходные я оказалась на трибуне дворца спорта «Мегаспорт» на туре Гран-при России по фигурному катанию. Меня туда привели «за компанию», не могу сказать, что я фанат и знаток фигурного катания. Как у бизнес-аналитика у меня есть привычка наблюдать процессы, где бы я ни оказалась. Я, честное слово, больше наблюдала за работой операторов, тренеров, заливкой льда и прочим, чем за спортсменами.
📍Заметила, что у каждого участника процесса своя функция и видно как она важна. Например, отдельный человек открывает фигуристам перед выступлением дверцу в бортике. По сути это действие показывает спортсмену нужный момент выхода на лед, если служащий не проследит за временем и ситуацией на люду, то спортсмен может, например, наехать на игрушку-подарок и получить травму. При этом, когда спортсмен покидает лед после выступления, за дверцу отвечает еще один служащий.
📍Удивительная слаженность действий и очередность выполнения задач. В примере с открыванием дверок в бортиках работают двое, потому что, когда одно выступление завершено почти сразу начинается следующее и бегать от бортика к бортику слишком накладно. Эти двое смотрят на время, друг на друга, и работают синхронно. Машины для заливки льда тоже движутся синхронно с одной скоростью и так, чтобы первая проехавшая машина оставляла полосу для заливки следующей машине. В это время мероприятия вне льда рассчитаны так, чтобы занять не больше и не меньше, чем минимальное время нужное для застывания льда. По аналогии с ИТ-командой придет ли кому-то в голову: «Чтобы побыстрее закончить давайте мы тут пока покатаемся, а техдолг про заливку льда закроем в следующем году»?
📍На льду фигурист сам принимает решения и отвечает за результат. Если ошибся, то сам решает повторить элемент или нет. Представьте, если бы за ним по льду бежал менеджер со словами: «Срочная задача, нужно еще пару прыжков срочно сделать!»
Кажется, людям ИТ нужно заниматься спортом не только для здоровья, но и для понимания механизмов работы команды :)
#мысливслух
В прошлые выходные я оказалась на трибуне дворца спорта «Мегаспорт» на туре Гран-при России по фигурному катанию. Меня туда привели «за компанию», не могу сказать, что я фанат и знаток фигурного катания. Как у бизнес-аналитика у меня есть привычка наблюдать процессы, где бы я ни оказалась. Я, честное слово, больше наблюдала за работой операторов, тренеров, заливкой льда и прочим, чем за спортсменами.
📍Заметила, что у каждого участника процесса своя функция и видно как она важна. Например, отдельный человек открывает фигуристам перед выступлением дверцу в бортике. По сути это действие показывает спортсмену нужный момент выхода на лед, если служащий не проследит за временем и ситуацией на люду, то спортсмен может, например, наехать на игрушку-подарок и получить травму. При этом, когда спортсмен покидает лед после выступления, за дверцу отвечает еще один служащий.
📍Удивительная слаженность действий и очередность выполнения задач. В примере с открыванием дверок в бортиках работают двое, потому что, когда одно выступление завершено почти сразу начинается следующее и бегать от бортика к бортику слишком накладно. Эти двое смотрят на время, друг на друга, и работают синхронно. Машины для заливки льда тоже движутся синхронно с одной скоростью и так, чтобы первая проехавшая машина оставляла полосу для заливки следующей машине. В это время мероприятия вне льда рассчитаны так, чтобы занять не больше и не меньше, чем минимальное время нужное для застывания льда. По аналогии с ИТ-командой придет ли кому-то в голову: «Чтобы побыстрее закончить давайте мы тут пока покатаемся, а техдолг про заливку льда закроем в следующем году»?
📍На льду фигурист сам принимает решения и отвечает за результат. Если ошибся, то сам решает повторить элемент или нет. Представьте, если бы за ним по льду бежал менеджер со словами: «Срочная задача, нужно еще пару прыжков срочно сделать!»
Кажется, людям ИТ нужно заниматься спортом не только для здоровья, но и для понимания механизмов работы команды :)
👍8
Вы думаете, это так просто – любить людей?
#интервью #мысливслух
Недавно закончила исследовательскую задачу, в которой провела 5 интервью. Тема интервьюирования просто неисчерпаемая, правда? 100500 нюансов, потому что это про людей, а они полны сюрпризов. Я уже написала про открытые вопросы и про интервью на удаленке, теперь хочу поделиться мыслями про выбор респондентов.
🔸Когда нужно выбрать респондентов одной конкретной роли в рабочем процессе и в компании есть система, которая поддерживает этот процесс, то, казалось бы, достаточно взять список пользователей, выбрать тех, что с одноименной ролью и вот они те, с кем нужно поговорить. Не тут-то было… Роль в реальном процессе совсем не обязательно совпадает с ролью пользователя в системе. Когда выходишь на связь людьми из списка пользователей, можно услышать, что «мне доступ дали, чтобы статусы отмечать/просто посмотреть, я не знаю, что вам рассказать»…
🔸Нетворкинг решает. Через список пользователей слово за слово можно выспросить контактные данные тех, кто действительно может ответить на вопросы. Еще можно поспрашивать коллег и через несколько рукопожатий добраться до нужных участников процесса. Так получается точнее и быстрее.
🔅Пока проводила интервью в очередной раз убедилась, что в любой команде встречаются этакие «дежурные представители пользователей», то есть признанные эксперты или менеджеры, которых всегда предлагают для интервью про пользовательский опыт. Их легко узнать по фразам, похожим на цитаты из регламентов, частым отсылкам к мнению руководства, большому количеству общих ответов, на вполне конкретные вопросы… Поговорить полезно, но скорее всего многие детали будут упущены.
🔅Интереснее всего с реальными пользователями, которые отвлеклись от своего пользовательского опыта, только, чтобы, собственно, вам о нем рассказать. До таких респондентов бывает сложно добраться. Зато из интервью вы наверняка узнаете, что все работает совсем не так как предполагалось при проектировании процесса и заодно поймете как так вышло, что его роль в системе не совпала с ролью в процессе☺️
#интервью #мысливслух
Недавно закончила исследовательскую задачу, в которой провела 5 интервью. Тема интервьюирования просто неисчерпаемая, правда? 100500 нюансов, потому что это про людей, а они полны сюрпризов. Я уже написала про открытые вопросы и про интервью на удаленке, теперь хочу поделиться мыслями про выбор респондентов.
🔸Когда нужно выбрать респондентов одной конкретной роли в рабочем процессе и в компании есть система, которая поддерживает этот процесс, то, казалось бы, достаточно взять список пользователей, выбрать тех, что с одноименной ролью и вот они те, с кем нужно поговорить. Не тут-то было… Роль в реальном процессе совсем не обязательно совпадает с ролью пользователя в системе. Когда выходишь на связь людьми из списка пользователей, можно услышать, что «мне доступ дали, чтобы статусы отмечать/просто посмотреть, я не знаю, что вам рассказать»…
🔸Нетворкинг решает. Через список пользователей слово за слово можно выспросить контактные данные тех, кто действительно может ответить на вопросы. Еще можно поспрашивать коллег и через несколько рукопожатий добраться до нужных участников процесса. Так получается точнее и быстрее.
🔅Пока проводила интервью в очередной раз убедилась, что в любой команде встречаются этакие «дежурные представители пользователей», то есть признанные эксперты или менеджеры, которых всегда предлагают для интервью про пользовательский опыт. Их легко узнать по фразам, похожим на цитаты из регламентов, частым отсылкам к мнению руководства, большому количеству общих ответов, на вполне конкретные вопросы… Поговорить полезно, но скорее всего многие детали будут упущены.
🔅Интереснее всего с реальными пользователями, которые отвлеклись от своего пользовательского опыта, только, чтобы, собственно, вам о нем рассказать. До таких респондентов бывает сложно добраться. Зато из интервью вы наверняка узнаете, что все работает совсем не так как предполагалось при проектировании процесса и заодно поймете как так вышло, что его роль в системе не совпала с ролью в процессе
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Согласовывать или договариваться?
#что_почитать #кейс
В поисках интересностей в профессиональных блогах набрела на статью с советами по согласованию требований How to Get Meaningful Sign-Off on Requirements? От названия я немного заскучала и хотела пройти мимо, но советы оказались дельными и мне есть чем дополнить.
1️⃣ Относитесь к согласованию как к заключению соглашения о возможностях решения и его месте в процессах заинтересованных сторон.
Самая первая задача в моей карьере была про подготовку огромного документа с названием Описание программного обеспечения, который был увесистой частью комплекта документации по ГОСТ 34. Согласование выглядело как спортивный и азартный процесс хождения по кабинетам с бумажным документом. Учесть комментарий, означало найти надпись карандашом на странице документа, внести изменение, перепечатать все (разбивка на страницы ведь тоже съехала при этом) и снова нести документ куда-то. Мне тогда казалось, что на это ушла вечность, на самом деле эта вечность длилась около полугода. Помню, что на финальном этапе мы все так замучились, что я ходила только с титульным листом от документа и просила каждого подписанта оставить на нем свой росчерк, какой документ я к этому приложу было на моей совести.
Процесс подписания за 20 лет изменился, а вот элемент полного доверия со стороны подписантов остался. Если по процессу требуется подпись под документом, то подписанты вынуждены смириться, что чего-то могли в тексте не понять или пропустить, и в итоге им придется рассчитывать исключительно на совесть и порядочность исполнителя. Они будут долго и придирчиво оставлять комментарии, пока либо не устанут, либо не решат вам доверять. Много ли так можно узнать об их ожиданиях от решения? Не нужно ли сразу заняться вопросами доверия? Альтернативный подход в паре пунктов ниже.
2️⃣ По возможности поэтапно согласовывайте материалы разного уровня: общую концепцию, границы изменений или конкретные варианты использования и т.п.
Работа над поиском и проектированием решения имеет свою этапность. Чаще всего я двигаюсь от общего к частному и на каждом шаге стараюсь получать обратную связь и договариваться с заинтересованными. Например, как только появляется представление о границах решения — можно обсудить и согласовать общее понимание этих границ. Так можно начать управлять ожиданиями стейкхолдеров, чтобы на этапе детального описания не столкнуться с завышенными ожиданиями. Кроме того, уход в детализацию при ошибках на концептуальном уровне — это гарантия будущих переделок, заплаток и изменений в последнюю секунду перед ПРОМ.
3️⃣ Адаптируйте материалы под аудиторию. Чтобы прийти к соглашению, может понадобиться объяснить наглядно.
Далеко не все заинтересованные стороны готовы прочитывать детальные требования. В своих недавних задачах я стала использовать любые наглядные материалы, которые могут помочь донести детальную информацию — интерактивные доски со стикерами, презентации, прототипы. Приходится потратить дополнительное время, но это как правило дешевле для команды, чем изменения «по живому» за день до внедрения или еще спринт после него.
Здесь я напомню о том, с чего начинала, - полезно держать фокус на общем понимании и соглашении о возможностях решения, если для этого нужно уместить ваши варианты использования на доску со стикерами, то почему бы и нет? Если подпись на документе тоже нужна, то вам проще будет ее получить после такого соглашения💁♀️
#что_почитать #кейс
В поисках интересностей в профессиональных блогах набрела на статью с советами по согласованию требований How to Get Meaningful Sign-Off on Requirements? От названия я немного заскучала и хотела пройти мимо, но советы оказались дельными и мне есть чем дополнить.
1️⃣ Относитесь к согласованию как к заключению соглашения о возможностях решения и его месте в процессах заинтересованных сторон.
Самая первая задача в моей карьере была про подготовку огромного документа с названием Описание программного обеспечения, который был увесистой частью комплекта документации по ГОСТ 34. Согласование выглядело как спортивный и азартный процесс хождения по кабинетам с бумажным документом. Учесть комментарий, означало найти надпись карандашом на странице документа, внести изменение, перепечатать все (разбивка на страницы ведь тоже съехала при этом) и снова нести документ куда-то. Мне тогда казалось, что на это ушла вечность, на самом деле эта вечность длилась около полугода. Помню, что на финальном этапе мы все так замучились, что я ходила только с титульным листом от документа и просила каждого подписанта оставить на нем свой росчерк, какой документ я к этому приложу было на моей совести.
Процесс подписания за 20 лет изменился, а вот элемент полного доверия со стороны подписантов остался. Если по процессу требуется подпись под документом, то подписанты вынуждены смириться, что чего-то могли в тексте не понять или пропустить, и в итоге им придется рассчитывать исключительно на совесть и порядочность исполнителя. Они будут долго и придирчиво оставлять комментарии, пока либо не устанут, либо не решат вам доверять. Много ли так можно узнать об их ожиданиях от решения? Не нужно ли сразу заняться вопросами доверия? Альтернативный подход в паре пунктов ниже.
2️⃣ По возможности поэтапно согласовывайте материалы разного уровня: общую концепцию, границы изменений или конкретные варианты использования и т.п.
Работа над поиском и проектированием решения имеет свою этапность. Чаще всего я двигаюсь от общего к частному и на каждом шаге стараюсь получать обратную связь и договариваться с заинтересованными. Например, как только появляется представление о границах решения — можно обсудить и согласовать общее понимание этих границ. Так можно начать управлять ожиданиями стейкхолдеров, чтобы на этапе детального описания не столкнуться с завышенными ожиданиями. Кроме того, уход в детализацию при ошибках на концептуальном уровне — это гарантия будущих переделок, заплаток и изменений в последнюю секунду перед ПРОМ.
3️⃣ Адаптируйте материалы под аудиторию. Чтобы прийти к соглашению, может понадобиться объяснить наглядно.
Далеко не все заинтересованные стороны готовы прочитывать детальные требования. В своих недавних задачах я стала использовать любые наглядные материалы, которые могут помочь донести детальную информацию — интерактивные доски со стикерами, презентации, прототипы. Приходится потратить дополнительное время, но это как правило дешевле для команды, чем изменения «по живому» за день до внедрения или еще спринт после него.
Здесь я напомню о том, с чего начинала, - полезно держать фокус на общем понимании и соглашении о возможностях решения, если для этого нужно уместить ваши варианты использования на доску со стикерами, то почему бы и нет? Если подпись на документе тоже нужна, то вам проще будет ее получить после такого соглашения💁♀️
🔥2👍1
User Story Map. Истории нужно рассказывать
#что_почитать #кейс
Из любопытства я поискала на hh объявления с аббревиатурой USM (User Story Map). Поделюсь наблюдением за формулировками:
• Бизнес-аналитик должен знать USM как принцип дизайн-мышления, а в соседней вакансии как «построение моделей и алгоритмов»
• Продуктовый дизайнер должен понимать как метод исследований
• Аналитик в отделе маркетинга должен владеть USM для планирования задач
• Менеджер продукта должен понимать USM как ключевой артефакт продукта
• Еще один системный аналитик Middle должен знать USM как метод декомпозиции задач
выглядит так будто наниматели не определились, что это такое.
Открыла книгу Джеффа Паттона «Пользовательские истории. Искусство гибкой разработки ПО», из которой когда-то узнала об этих картах, и на первых же страницах в предисловии Мартина Фаулера выбрала формулировку, которая мне ближе:
Эта техника задумана для коммуникации между всеми участниками продукта, для выработки единого понимания ими функций и задач по разработке продукта. Честно говоря, мне только однажды повезло применять карту историй по ее прямому назначению. Для предварительной оценки трудозатрат нужно было увидеть общую картину продукта. Это было важно, чтобы принять решение запускать продукт в разработку или нет. В том числе понять, нужно ли инвестировать время в выявление детальных требований. Для такой задачи как раз хорошо подошла карта пользовательских историй, которую мы построили за 2 трехчасовые встречи с представителями заинтересованных сторон. Этого было достаточно, чтобы понять стоимость разработки и отказаться от продукта 😊
Авторы книг и статей советуют составлять User Story Map на общих встречах (story-writing workshops) с участием команды, владельца продукта и представителей других заинтересованных сторон. В реальности, ее редко применяют именно так, отсюда и различия в формулировках вакансий:
• где-то сначала заводят задачи в Jira и уже после этого представляют их в виде карты,
• где-то карту составляет аналитик на свое усмотрение по информации от заказчика,
• где-то карту используют только дизайнеры, чтобы упорядочить информацию от заинтересованных сторон.
Если коротко, то карта составляется в несколько шагов:
📍Определить название и цели процесса
📍Выделить роли участников
📍Определить верхнеуровнево шаги процесса или задачи пользователя, нужные для достижения цели. Разместить их на карточках горизонтально слева направо в порядке выполнения от начала к завершению
📍Определить истории в рамках каждого шага. Разместить их на карточках вертикально под каждым шагом.
📍При необходимости определить задачи, необходимые для разработки историй (необходимость зависит от целей составления карты).
📍Расставить приоритеты ранжированием (например, методом MoSCoW)
Книга Джеффа Паттона о User Story Mapping вышла в 2014 году и с тех пор написано много инструкций и примеров применения. Выбрала три статьи
🔖Статья от Майка Кона с детальным описанием построения User Story Map. Работа с картой описана по шагам с примерами в картинках и рекомендациями к применению (ENG)
🔖Статья 8 шагов, чтобы построить карту пользовательских историй. Еще одно короткое пошаговое описание. Здесь гораздо меньше деталей, чем у Кона, но как памятка вполне подойдет (ENG)
🔖Как сторимэп помогает не завязнуть в разработке нового продукта на годы. Кейс от «Додо пицца», опубликованный в 2017 году. Очень понравился примерами и фото
#что_почитать #кейс
Из любопытства я поискала на hh объявления с аббревиатурой USM (User Story Map). Поделюсь наблюдением за формулировками:
• Бизнес-аналитик должен знать USM как принцип дизайн-мышления, а в соседней вакансии как «построение моделей и алгоритмов»
• Продуктовый дизайнер должен понимать как метод исследований
• Аналитик в отделе маркетинга должен владеть USM для планирования задач
• Менеджер продукта должен понимать USM как ключевой артефакт продукта
• Еще один системный аналитик Middle должен знать USM как метод декомпозиции задач
выглядит так будто наниматели не определились, что это такое.
Открыла книгу Джеффа Паттона «Пользовательские истории. Искусство гибкой разработки ПО», из которой когда-то узнала об этих картах, и на первых же страницах в предисловии Мартина Фаулера выбрала формулировку, которая мне ближе:
Построение карт историй (story mapping) — это техника, позволяющая увидеть цельную картину, чего не удастся сделать с помощью простого набора историй.
Эта техника задумана для коммуникации между всеми участниками продукта, для выработки единого понимания ими функций и задач по разработке продукта. Честно говоря, мне только однажды повезло применять карту историй по ее прямому назначению. Для предварительной оценки трудозатрат нужно было увидеть общую картину продукта. Это было важно, чтобы принять решение запускать продукт в разработку или нет. В том числе понять, нужно ли инвестировать время в выявление детальных требований. Для такой задачи как раз хорошо подошла карта пользовательских историй, которую мы построили за 2 трехчасовые встречи с представителями заинтересованных сторон. Этого было достаточно, чтобы понять стоимость разработки и отказаться от продукта 😊
Авторы книг и статей советуют составлять User Story Map на общих встречах (story-writing workshops) с участием команды, владельца продукта и представителей других заинтересованных сторон. В реальности, ее редко применяют именно так, отсюда и различия в формулировках вакансий:
• где-то сначала заводят задачи в Jira и уже после этого представляют их в виде карты,
• где-то карту составляет аналитик на свое усмотрение по информации от заказчика,
• где-то карту используют только дизайнеры, чтобы упорядочить информацию от заинтересованных сторон.
Если коротко, то карта составляется в несколько шагов:
📍Определить название и цели процесса
📍Выделить роли участников
📍Определить верхнеуровнево шаги процесса или задачи пользователя, нужные для достижения цели. Разместить их на карточках горизонтально слева направо в порядке выполнения от начала к завершению
📍Определить истории в рамках каждого шага. Разместить их на карточках вертикально под каждым шагом.
📍При необходимости определить задачи, необходимые для разработки историй (необходимость зависит от целей составления карты).
📍Расставить приоритеты ранжированием (например, методом MoSCoW)
Книга Джеффа Паттона о User Story Mapping вышла в 2014 году и с тех пор написано много инструкций и примеров применения. Выбрала три статьи
🔖Статья от Майка Кона с детальным описанием построения User Story Map. Работа с картой описана по шагам с примерами в картинках и рекомендациями к применению (ENG)
🔖Статья 8 шагов, чтобы построить карту пользовательских историй. Еще одно короткое пошаговое описание. Здесь гораздо меньше деталей, чем у Кона, но как памятка вполне подойдет (ENG)
🔖Как сторимэп помогает не завязнуть в разработке нового продукта на годы. Кейс от «Додо пицца», опубликованный в 2017 году. Очень понравился примерами и фото
Mountaingoatsoftware
How to Create a Story Map When Writing User Stories - Mountain Goat Software
Story maps help to create a shared understanding of the product, visualize user needs, and elicit user story ideas. Discover how to create your own.
👍7🔥3
Что здесь интересного?
#дайджест #что_почитать
Хочу поприветствовать всех новых участников! Спасибо вам за интерес к публикациям!
Со времени создания канала публикаций собралось 65 и я решила сделать подборку-навигацию того, что у нас здесь есть 🌱
📚О книгах
📍«Спринт» Джейк Кнапп, Брейден Ковитц, Джон Зерацки
📍«Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач» Итан Расиел
📍«Психбольница в руках пациентов» Алан Купер
📃Статьи
📍Собаки разговаривают, но только с теми кто умеет слушать
📍Как бизнес-аналитику преодолевать групповое мышление?
📍Масштабируемая структура требований
📍Бэклог не может содержать все подряд
📍Согласовывать или договариваться?
🗞Подборки
📍Что почитать про Process Mining & Task Mining?
📍Статьи про UI, про Демо и про требования
📍Подборка статей о User Story
📍«Да», «Нет» и «Зачем» не говорить?
📍Полезности и интересности
⚙️Инструменты
📍Может ли Agile-коуч писать плохие пользовательские истории?
📍Чем отличаются критерии приемки и DOD?
📍Интервью на удаленке. Чтобы удалось, надо пробовать и сегодня, и завтра, и послезавтра
📍Как я растила деревья в PlantUML
📍User Story Map. Истории нужно рассказывать
👷Кейсы
📍Как я искала сложности и что из этого вышло
📍Почему не удалось с первой попытки найти приоритеты?
📍Итоги кейса про снабжение экспедиции
📍Пользовательские истории и нефункциональные требования
📍Какие вопросы?
✍️Мысли вслух
📍Что важнее цель или средства?
📍Научит ли эксперт по бизнес-анализу аналитике?
📍Очень вредно не ездить на бал, когда ты этого заслуживаешь
📍Иногда лучше потратить немножко времени, чтобы потом его сберечь
📍Про процессы
#дайджест #что_почитать
Хочу поприветствовать всех новых участников! Спасибо вам за интерес к публикациям!
Со времени создания канала публикаций собралось 65 и я решила сделать подборку-навигацию того, что у нас здесь есть 🌱
📚О книгах
📍«Спринт» Джейк Кнапп, Брейден Ковитц, Джон Зерацки
📍«Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач» Итан Расиел
📍«Психбольница в руках пациентов» Алан Купер
📃Статьи
📍Собаки разговаривают, но только с теми кто умеет слушать
📍Как бизнес-аналитику преодолевать групповое мышление?
📍Масштабируемая структура требований
📍Бэклог не может содержать все подряд
📍Согласовывать или договариваться?
🗞Подборки
📍Что почитать про Process Mining & Task Mining?
📍Статьи про UI, про Демо и про требования
📍Подборка статей о User Story
📍«Да», «Нет» и «Зачем» не говорить?
📍Полезности и интересности
⚙️Инструменты
📍Может ли Agile-коуч писать плохие пользовательские истории?
📍Чем отличаются критерии приемки и DOD?
📍Интервью на удаленке. Чтобы удалось, надо пробовать и сегодня, и завтра, и послезавтра
📍Как я растила деревья в PlantUML
📍User Story Map. Истории нужно рассказывать
👷Кейсы
📍Как я искала сложности и что из этого вышло
📍Почему не удалось с первой попытки найти приоритеты?
📍Итоги кейса про снабжение экспедиции
📍Пользовательские истории и нефункциональные требования
📍Какие вопросы?
✍️Мысли вслух
📍Что важнее цель или средства?
📍Научит ли эксперт по бизнес-анализу аналитике?
📍Очень вредно не ездить на бал, когда ты этого заслуживаешь
📍Иногда лучше потратить немножко времени, чтобы потом его сберечь
📍Про процессы
👍2🔥1🤩1
Пользовательское тестирование в инженерии требований
#что_почитать #статьи
В журнале IREB (International Requirements Engineering Board) встретилась статья, которая говорит, что работать над требованиями через пользовательский опыт — это хорошая практика. Делюсь обзором статьи The Potential of User Tests for Requirements Engineering
Тесты с пользователями можно проводить на разных этапах разработки и с разными целями:
• выявления требований на этапе работы с идеей,
• валидации требований на этапе разработки,
• перепроверки соответствия рынку (product market fit) перед внедрением.
Тестирование можно организовывать как с конечными (end-user) так и с внутренними (internal) пользователями.
🔅Конечные пользователи - это потенциальные клиенты еще не знакомые с приложением. Эта категория пользователей поможет увидеть упущенные варианты использования приложения. Можно понять как и какие задачи пользователи собираются решать с помощью приложения, увидеть за какие фичи они готовы платить больше, а чем вряд ли будут пользоваться.
Тесты с конечными пользователями могут быть в виде опроса, интервью, тестирования вайрфреймов (wireframes), тестирования прототипов. Важно, что они проводятся на этапе, когда изменения требований не требуют больших затрат.
🔅Внутренние пользователи набираются из тех, кто уже вовлечен в продукт: разработчики, тестировщики, менеджеры, дизайнеры, инвесторы… Тестирование их опыта может быть источником новых требований и средством валидации требований. Но есть нюанс. Эта категория пользователей не может «развидеть» все, что они уже знают о продукте, и только предполагают, что могут мыслить как конечный пользователь, хотя это не так. Поэтому позже лучше еще раз повести тестирование с конечными пользователями.
Тесты с внутренними пользователями могут быть в виде тестирования вайрфреймов или прототипов, а еще в виде проверки, что разрабатываемое покрывает все запланированные пользовательские истории. Это помогает выстроить общее понимание внутри продуктовой команды и валидировать приложение не только на предмет потребностей пользователей, но и с точки зрения технической реализации.
🔅MVP - minimum viable product (минимальный жизнеспособный продукт). Как только первая базовая жизнеспособная версия готова, то рекомендуется провести тестирование с конечными пользователями. Так можно понять насколько приложение понятно пользователям и отвечает их требованиям. На этом этапе еще есть возможность доработать приложение для лучшего соответствия рынку.
В целом результаты пользовательского тестирования могут послужить аргументацией в пользу тех или иных требований при разногласиях внутри команды. Без привлечения внутренних и конечных пользователей требования оказываются не полными.
От себя дополню, что уже комментировала кейс, где требования выявлялись через тестирование пользователей. В кейсе это был единственно возможный прием, потому что среди пользователей были служебные собаки. А еще рассказывала и свой кейс про пользовательское тестирование🗃
#что_почитать #статьи
В журнале IREB (International Requirements Engineering Board) встретилась статья, которая говорит, что работать над требованиями через пользовательский опыт — это хорошая практика. Делюсь обзором статьи The Potential of User Tests for Requirements Engineering
Тесты с пользователями можно проводить на разных этапах разработки и с разными целями:
• выявления требований на этапе работы с идеей,
• валидации требований на этапе разработки,
• перепроверки соответствия рынку (product market fit) перед внедрением.
Тестирование можно организовывать как с конечными (end-user) так и с внутренними (internal) пользователями.
🔅Конечные пользователи - это потенциальные клиенты еще не знакомые с приложением. Эта категория пользователей поможет увидеть упущенные варианты использования приложения. Можно понять как и какие задачи пользователи собираются решать с помощью приложения, увидеть за какие фичи они готовы платить больше, а чем вряд ли будут пользоваться.
Тесты с конечными пользователями могут быть в виде опроса, интервью, тестирования вайрфреймов (wireframes), тестирования прототипов. Важно, что они проводятся на этапе, когда изменения требований не требуют больших затрат.
🔅Внутренние пользователи набираются из тех, кто уже вовлечен в продукт: разработчики, тестировщики, менеджеры, дизайнеры, инвесторы… Тестирование их опыта может быть источником новых требований и средством валидации требований. Но есть нюанс. Эта категория пользователей не может «развидеть» все, что они уже знают о продукте, и только предполагают, что могут мыслить как конечный пользователь, хотя это не так. Поэтому позже лучше еще раз повести тестирование с конечными пользователями.
Тесты с внутренними пользователями могут быть в виде тестирования вайрфреймов или прототипов, а еще в виде проверки, что разрабатываемое покрывает все запланированные пользовательские истории. Это помогает выстроить общее понимание внутри продуктовой команды и валидировать приложение не только на предмет потребностей пользователей, но и с точки зрения технической реализации.
🔅MVP - minimum viable product (минимальный жизнеспособный продукт). Как только первая базовая жизнеспособная версия готова, то рекомендуется провести тестирование с конечными пользователями. Так можно понять насколько приложение понятно пользователям и отвечает их требованиям. На этом этапе еще есть возможность доработать приложение для лучшего соответствия рынку.
В целом результаты пользовательского тестирования могут послужить аргументацией в пользу тех или иных требований при разногласиях внутри команды. Без привлечения внутренних и конечных пользователей требования оказываются не полными.
От себя дополню, что уже комментировала кейс, где требования выявлялись через тестирование пользователей. В кейсе это был единственно возможный прием, потому что среди пользователей были служебные собаки. А еще рассказывала и свой кейс про пользовательское тестирование🗃
Источник требований — это не обязательно люди
#мысливслух #инструменты
В одной их команд моя работа началась с запроса: «Зачем тебе так много времени на функциональные требования? Вон тебе наши менеджеры — проговори с ними и все». Это запомнилось, видимо, от изрядной обиды за мою роль в команде. Спрашивается зачем вам БА, если есть такие чудесные менеджеры, которые уже все знают? Неужели только, чтобы спросить и записать? 🤷♀️
Во многих командах живет представление, что источником требований могут быть только люди. Причем эти люди обязаны обладать достаточными знаниями, чтобы однозначно и непротиворечиво выдать всю информацию, важную для успеха фичи или продукта. Из этой точки зрения формируется целый набор взаимных претензий между командами разработки и представителями бизнес-пользователей. «Сами не знают, чего хотят», «все меняют в последний момент» - это со стороны разработки. «Отвлекают своими вопросами», «делают вообще не то, не понятно как объяснять» - со стороны других заинтересованных сторон 🤽♀️
На самом деле при формировании функциональных требований и выборе решения можно опираться на разные источники: документы, системы, исследования, эксперименты… На одном из занятий с менти мы составили памятку с техниками выявления требований из стандарта BABOK. Поделюсь здесь 🎁
Напишите, какие из техник вы чаще всего применяете? Какие из них вызывают вопросы?
#мысливслух #инструменты
В одной их команд моя работа началась с запроса: «Зачем тебе так много времени на функциональные требования? Вон тебе наши менеджеры — проговори с ними и все». Это запомнилось, видимо, от изрядной обиды за мою роль в команде. Спрашивается зачем вам БА, если есть такие чудесные менеджеры, которые уже все знают? Неужели только, чтобы спросить и записать? 🤷♀️
Во многих командах живет представление, что источником требований могут быть только люди. Причем эти люди обязаны обладать достаточными знаниями, чтобы однозначно и непротиворечиво выдать всю информацию, важную для успеха фичи или продукта. Из этой точки зрения формируется целый набор взаимных претензий между командами разработки и представителями бизнес-пользователей. «Сами не знают, чего хотят», «все меняют в последний момент» - это со стороны разработки. «Отвлекают своими вопросами», «делают вообще не то, не понятно как объяснять» - со стороны других заинтересованных сторон 🤽♀️
На самом деле при формировании функциональных требований и выборе решения можно опираться на разные источники: документы, системы, исследования, эксперименты… На одном из занятий с менти мы составили памятку с техниками выявления требований из стандарта BABOK. Поделюсь здесь 🎁
Напишите, какие из техник вы чаще всего применяете? Какие из них вызывают вопросы?
👍2❤1
Сколько тонн клевера от каждой курицы несушки будет засыпано в инкубаторы после обмолота зяби?
#мысливслух
Мой папа любит вспоминать ту часть своего детства, которую он провел в деревне. Это было в начале 1960х, в одном их тех мест, где обувь носили только в холода, зимой забирали поросят в дом, а всяких базовых ценностей не то что не хватало, а вообще вряд ли кто-то знал об их существовании в пирамиде Маслоу 😉
Недавно мы рассуждали как мне сложно понять чувства человека, который в холодное время года сидит в своем теплом доме и понимает, что сам успел запастись дровами и теперь может топить печь. Печь он сложил тоже сам.
Могут аналитики похвастаться таким точным пониманием результата? Особенно сложно с этим в найме. Результат часто не зависит от ваших усилий. Бывает кто-то затеял заведомо провальный проект, вы построили клиентский путь как никогда в жизни, но ни один клиент по нему так и не прошел. Если проект удачный, то как измерить именно ваш вклад в этот общий командный успех? Сколько тонн клевера от каждой курицы-несушки будет засыпано в инкубаторы именно от вашей работы?
Этот канал, помогает мне делать тот вид задач, где почти мгновенно можно видеть результат. Есть реакции под текстом, значит удалось рассказать что-то полезное или эмоционально задеть чей-то опыт. И успех и неуспех всегда мои. От этого легко находить мотивацию для новых задач.
Менторство из того же сорта задач. Это не выглядит как на картинке из мультика "Возвращение блудного попугая", где попугай Кеша ловко забросал словами неподготовленную публику. Например, недавно помогала коллеге-аналитику составить резюме. Он больше 10 лет работал в одной и той же компании, подзабыл как делается резюме и расстраивался, что никто не зовет на собесы. Мы долго разбирались с текстами, через пару дней еще раз вычитывали результат. Когда я узнала, что его уже позвали на два собеса, — это ощущалось как те дрова в печке в начале моего текста☺️
А как у вас с мотивацией? Что вы делаете, чтобы понимать результаты своей работы в офисе или вне его?
#мысливслух
Мой папа любит вспоминать ту часть своего детства, которую он провел в деревне. Это было в начале 1960х, в одном их тех мест, где обувь носили только в холода, зимой забирали поросят в дом, а всяких базовых ценностей не то что не хватало, а вообще вряд ли кто-то знал об их существовании в пирамиде Маслоу 😉
Недавно мы рассуждали как мне сложно понять чувства человека, который в холодное время года сидит в своем теплом доме и понимает, что сам успел запастись дровами и теперь может топить печь. Печь он сложил тоже сам.
Могут аналитики похвастаться таким точным пониманием результата? Особенно сложно с этим в найме. Результат часто не зависит от ваших усилий. Бывает кто-то затеял заведомо провальный проект, вы построили клиентский путь как никогда в жизни, но ни один клиент по нему так и не прошел. Если проект удачный, то как измерить именно ваш вклад в этот общий командный успех? Сколько тонн клевера от каждой курицы-несушки будет засыпано в инкубаторы именно от вашей работы?
Этот канал, помогает мне делать тот вид задач, где почти мгновенно можно видеть результат. Есть реакции под текстом, значит удалось рассказать что-то полезное или эмоционально задеть чей-то опыт. И успех и неуспех всегда мои. От этого легко находить мотивацию для новых задач.
Менторство из того же сорта задач. Это не выглядит как на картинке из мультика "Возвращение блудного попугая", где попугай Кеша ловко забросал словами неподготовленную публику. Например, недавно помогала коллеге-аналитику составить резюме. Он больше 10 лет работал в одной и той же компании, подзабыл как делается резюме и расстраивался, что никто не зовет на собесы. Мы долго разбирались с текстами, через пару дней еще раз вычитывали результат. Когда я узнала, что его уже позвали на два собеса, — это ощущалось как те дрова в печке в начале моего текста
А как у вас с мотивацией? Что вы делаете, чтобы понимать результаты своей работы в офисе или вне его?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4🔥2
Про текст в интерфейсе
#субботнее #мысливслух #конференции
Сегодня я слушаю он-лайн конференцию UX-Марафон #33. Основная тема - работа UX-редакторов. Я никогда не работала с такими специалистами и стало интересно послушать об их работе.
В моем опыте в основном приложения для внутренних операционных процессов компаний (например, управление поставщиками, CRM, системы учета оборудования). Обычно для таких систем не слишком большое значение придается голосу, каким они общаются со своими пользователями. Чаще всего этот голос — это голос аналитика. Вернее, уже давно стали собирать метрики клиентской удовлетворенности не только для клиентских (внешних) приложений, но и для операционных (внутренних), при этом вопросы этой удовлетворенности чаще всего в руках аналитиков, а не UX-специалистов.
UX-редакторы отвечают за понятные тексты на экране и, судя по докладам, речь может идти о любых текстах от FAQ до названий полей и кнопок. Работают в том числе над текстами для чат-ботов и голосовых ботов. Участвуют в вопросах локализации, когда нужно не просто перевести текст, но и вписать в контекст приложения. Кто-то из докладчиков говорил, что его работа только про понятность и удобство, а не про привлечение клиентов, а кто-то следом начинал расcказывать про свою роль в привлечении. Видимо, в любой роли есть свои нюансы 😉
Работа с текстом это про то, чтобы понимать свою аудиторию и контекст, а не просто поправить буквы. В тех докладах, что я послушала, внимание привлекли рекомендации из доклада "Как проверять тексты без исследований: ОКР-ный список редактора"
🔅Текст должен учитывать контекст и эмоции. В каком состоянии пользователь может прийти к тому шагу, где он читает текст. Нужно успокаивать или можно шутить? Например, если не прошла оплата товара, уместно ли в сообщении об ошибке написать что-то вроде «Упс, ваши деньги не ушли!»
🔅Текст должен быть универсальным, то есть учитывать все ситуации, которые могут привести пользователя к этому тексту. Например, не спешите писать «Деньги вернулись на карту» сразу после оформления возврата. Срок перевода в некоторых банках составляет до 5 дней и сразу после возврата пользователь денег на карте пользователь не увидит.
🔅Текст должен быть понятным. Из текста должно быть ясно, что произошло. В одном из докладов прозвучал критерий: «Текст должен быть понятен ученикам 7-8 класса средней школы». В моей практике однажды было сообщение, которое использовали как заглушку, забыли исправить и в итоге на ПРОМ пользователь увидел фразу: «Система не знает, что дальше делать». Слова простые, но ясности никакой.
🔅Текст должен учитывать тональность. В приложении и в компании в целом может быть принят формальный, дружелюбный, панибратский тон. Чаще всего приложения стараются общаться с нами в спокойно-дружелюбном тоне.
🔅Все элементы текста должны быть логически связаны. Заголовки, подзаголовки, элементы списка должны быть логически связаны. Например, в этом тексте я несколько раз поправила названия в списке, потому что некоторые оказались про важность чего-то в тексте, а некоторые про «делайте так». Пришлось выбирать между логикой перечисления рекомендаций и инструкции к действию.
🔅Текст должен быть грамотным. Оставлю этот пункт без комментариев 😊
В комментариях поделюсь примером. Добавляйте свои, если у вас есть «любимые» или «наболевшие» примеры😊
#субботнее #мысливслух #конференции
Сегодня я слушаю он-лайн конференцию UX-Марафон #33. Основная тема - работа UX-редакторов. Я никогда не работала с такими специалистами и стало интересно послушать об их работе.
В моем опыте в основном приложения для внутренних операционных процессов компаний (например, управление поставщиками, CRM, системы учета оборудования). Обычно для таких систем не слишком большое значение придается голосу, каким они общаются со своими пользователями. Чаще всего этот голос — это голос аналитика. Вернее, уже давно стали собирать метрики клиентской удовлетворенности не только для клиентских (внешних) приложений, но и для операционных (внутренних), при этом вопросы этой удовлетворенности чаще всего в руках аналитиков, а не UX-специалистов.
UX-редакторы отвечают за понятные тексты на экране и, судя по докладам, речь может идти о любых текстах от FAQ до названий полей и кнопок. Работают в том числе над текстами для чат-ботов и голосовых ботов. Участвуют в вопросах локализации, когда нужно не просто перевести текст, но и вписать в контекст приложения. Кто-то из докладчиков говорил, что его работа только про понятность и удобство, а не про привлечение клиентов, а кто-то следом начинал расcказывать про свою роль в привлечении. Видимо, в любой роли есть свои нюансы 😉
Работа с текстом это про то, чтобы понимать свою аудиторию и контекст, а не просто поправить буквы. В тех докладах, что я послушала, внимание привлекли рекомендации из доклада "Как проверять тексты без исследований: ОКР-ный список редактора"
🔅Текст должен учитывать контекст и эмоции. В каком состоянии пользователь может прийти к тому шагу, где он читает текст. Нужно успокаивать или можно шутить? Например, если не прошла оплата товара, уместно ли в сообщении об ошибке написать что-то вроде «Упс, ваши деньги не ушли!»
🔅Текст должен быть универсальным, то есть учитывать все ситуации, которые могут привести пользователя к этому тексту. Например, не спешите писать «Деньги вернулись на карту» сразу после оформления возврата. Срок перевода в некоторых банках составляет до 5 дней и сразу после возврата пользователь денег на карте пользователь не увидит.
🔅Текст должен быть понятным. Из текста должно быть ясно, что произошло. В одном из докладов прозвучал критерий: «Текст должен быть понятен ученикам 7-8 класса средней школы». В моей практике однажды было сообщение, которое использовали как заглушку, забыли исправить и в итоге на ПРОМ пользователь увидел фразу: «Система не знает, что дальше делать». Слова простые, но ясности никакой.
🔅Текст должен учитывать тональность. В приложении и в компании в целом может быть принят формальный, дружелюбный, панибратский тон. Чаще всего приложения стараются общаться с нами в спокойно-дружелюбном тоне.
🔅Все элементы текста должны быть логически связаны. Заголовки, подзаголовки, элементы списка должны быть логически связаны. Например, в этом тексте я несколько раз поправила названия в списке, потому что некоторые оказались про важность чего-то в тексте, а некоторые про «делайте так». Пришлось выбирать между логикой перечисления рекомендаций и инструкции к действию.
🔅Текст должен быть грамотным. Оставлю этот пункт без комментариев 😊
В комментариях поделюсь примером. Добавляйте свои, если у вас есть «любимые» или «наболевшие» примеры
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Новые темы неплохо начинать именно с понедельника☕️ Стало интересно написать о мифах про работу бизнес-аналитика в ИТ. Каждый миф хочу разобрать отдельно. Чтобы это адекватно выглядело в формате Телеграмм, сделаю отдельный пост для каждого. Получится сериал из нескольких эпизодов.
👍2
#1 Миф о работе бизнес-аналитика. Не нужны знания о программировании
#мысливслух #мифы
Если полистать вакансии, то для роли БА даже без совмещения с системным анализом, наниматели часто ожидают как минимум понимание ИТ-архитектуры и процессов разработки. Зачем это?
📍Приходится разбираться в преимуществах и ограничениях систем, которые служат для автоматизации процессов. Невозможно предложить процессные и функциональные решения без понимания, на чем они строятся. Можно уточнить у разработчиков, но как много вопросов в день они готовы обработать?
📍Нужно обрисовать образ результата коллегам, которые применяют знания о системах и алгоритмах для решения любых задач. Их система аргументации и приоритетов построена на этих знаниях. Без минимальных знаний ИТ-архитектуры сложно понять, зачем вас просят изменить требование, потому что «у нас сервис отправки получает только мета-данные и не видит весь текст сообщения»
Из нужных знаний я бы выделила:
🔅Принципы работы с данными. Не нужно уметь создавать базы данных, но обязательно понимать как данные организуются и как хранятся. Уметь моделировать данные на концептуальном и логическом уровне. Этот навык поможет правильно выделять объекты предметной области и связи между ними
🔅Основы архитектуры. Нужно понимать какими способами системы могут взаимодействовать между собой. Это поможет сформулировать требования так, чтобы вас поняли, и читать документацию без переводчика. Еще такое знание помогает быстрее понимать ограничения для бизнес-процессов
🔅Процесс разработки. Речь именно о производстве: написании кода, контроле версии, сборке и установке релиза, тестировании и работе с багами. Так вы будете быстрее понимать, почему вчера можно было «быстренько изменить», а сегодня уже поздно; почему «у нас монолит, мы не можем ничего выпилить из релиза»
#мысливслух #мифы
Если полистать вакансии, то для роли БА даже без совмещения с системным анализом, наниматели часто ожидают как минимум понимание ИТ-архитектуры и процессов разработки. Зачем это?
📍Приходится разбираться в преимуществах и ограничениях систем, которые служат для автоматизации процессов. Невозможно предложить процессные и функциональные решения без понимания, на чем они строятся. Можно уточнить у разработчиков, но как много вопросов в день они готовы обработать?
📍Нужно обрисовать образ результата коллегам, которые применяют знания о системах и алгоритмах для решения любых задач. Их система аргументации и приоритетов построена на этих знаниях. Без минимальных знаний ИТ-архитектуры сложно понять, зачем вас просят изменить требование, потому что «у нас сервис отправки получает только мета-данные и не видит весь текст сообщения»
Из нужных знаний я бы выделила:
🔅Принципы работы с данными. Не нужно уметь создавать базы данных, но обязательно понимать как данные организуются и как хранятся. Уметь моделировать данные на концептуальном и логическом уровне. Этот навык поможет правильно выделять объекты предметной области и связи между ними
🔅Основы архитектуры. Нужно понимать какими способами системы могут взаимодействовать между собой. Это поможет сформулировать требования так, чтобы вас поняли, и читать документацию без переводчика. Еще такое знание помогает быстрее понимать ограничения для бизнес-процессов
🔅Процесс разработки. Речь именно о производстве: написании кода, контроле версии, сборке и установке релиза, тестировании и работе с багами. Так вы будете быстрее понимать, почему вчера можно было «быстренько изменить», а сегодня уже поздно; почему «у нас монолит, мы не можем ничего выпилить из релиза»
❤4🔥3