Одушевленные системы и неодушевленные пользователи
#мысливслух #кейс #agile
Субботний опрос я затеяла, чтобы обратить внимание на пару моментов в работе с пользовательскими историями. Как и обещала делюсь мыслями.
📍Я предложила для уже сформулированного свойства решения определить, кто в нем может быть заинтересован и для чего. Получилось, что к следствию нужно придумать причины. На практике это случается, хотя по сути не выглядит нормальным порядком вещей. Обычно именно в таких случаях получаются формулировки с одушевлением систем «Я, как Система хочу, чтобы пользователь указывал логин и пароль, чтобы правильно логировать действия пользователя» или формулировки, где пользователю присваивается неестественное поведение «Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию». Если человек действительно хочет скорее перейти к бронированию, то ввод логина и пароля будет восприниматься как помеха, а не как ожидаемая функция.
📍Как любые другие нефункциональные требования, требования к авторизации относятся к системе в целом. При реализации большинства историй будет важно учесть, что заявленный «кто» должен быть авторизованным пользователем. Получается, что общие характеристики системы так или иначе должны учитываться в критериях приемки любой истории или любая история должна наследоваться от нефункциональной...Может получиться громоздкая и неочевидная структура.
Прежде чем формулировать нефункциональное требование в формате истории я бы посоветовала подумать как эта история будет использоваться командой? Формат отдельной истории для требования к авторизации полезен, только если действительно нужен вашей команде как элемент бэклога. Иначе такое требование лучше не маскировать под историю, а фиксировать вместе с другими нефункциональными требованиями короткой фразой. Например, «Доступ к функциям должен предоставляться на основании ролей пользователей и схемы разграничения прав доступа между ними». Будет достаточно сослаться на это требование из других историй и задач, где необходимо.
Возвращаясь к субботнему опросу скажу так… На мой взгляд, лучше всего показывают контекст требования истории вида «Я, как пользователь хочу иметь Личный кабинет, чтобы хранить данные для автоматического заполнения полей при бронировании» и «Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и перс.данным». При этом с точки зрения планирования разработки эти истории слишком крупные и их придется разбивать на более конкретные. Так что подумайте как такой формат будет работать именно в вашей команде?
#мысливслух #кейс #agile
Субботний опрос я затеяла, чтобы обратить внимание на пару моментов в работе с пользовательскими историями. Как и обещала делюсь мыслями.
📍Я предложила для уже сформулированного свойства решения определить, кто в нем может быть заинтересован и для чего. Получилось, что к следствию нужно придумать причины. На практике это случается, хотя по сути не выглядит нормальным порядком вещей. Обычно именно в таких случаях получаются формулировки с одушевлением систем «Я, как Система хочу, чтобы пользователь указывал логин и пароль, чтобы правильно логировать действия пользователя» или формулировки, где пользователю присваивается неестественное поведение «Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию». Если человек действительно хочет скорее перейти к бронированию, то ввод логина и пароля будет восприниматься как помеха, а не как ожидаемая функция.
📍Как любые другие нефункциональные требования, требования к авторизации относятся к системе в целом. При реализации большинства историй будет важно учесть, что заявленный «кто» должен быть авторизованным пользователем. Получается, что общие характеристики системы так или иначе должны учитываться в критериях приемки любой истории или любая история должна наследоваться от нефункциональной...Может получиться громоздкая и неочевидная структура.
Прежде чем формулировать нефункциональное требование в формате истории я бы посоветовала подумать как эта история будет использоваться командой? Формат отдельной истории для требования к авторизации полезен, только если действительно нужен вашей команде как элемент бэклога. Иначе такое требование лучше не маскировать под историю, а фиксировать вместе с другими нефункциональными требованиями короткой фразой. Например, «Доступ к функциям должен предоставляться на основании ролей пользователей и схемы разграничения прав доступа между ними». Будет достаточно сослаться на это требование из других историй и задач, где необходимо.
Возвращаясь к субботнему опросу скажу так… На мой взгляд, лучше всего показывают контекст требования истории вида «Я, как пользователь хочу иметь Личный кабинет, чтобы хранить данные для автоматического заполнения полей при бронировании» и «Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и перс.данным». При этом с точки зрения планирования разработки эти истории слишком крупные и их придется разбивать на более конкретные. Так что подумайте как такой формат будет работать именно в вашей команде?
Написанное должно быть удобочитаемо
#мысливслух #что_почитать
В русском языке выделяют пять основных стилей:
• научный,
• официально-деловой,
• публицистический,
• разговорный,
• художественный
Как думаете, в каком стиле аналитики пишут свои документы? Наиболее последовательным, логичным и точным считается научный стиль. Его мы легко угадываем по монотонному звучанию, множеству терминов, пассивному залогу, сложным предложениям, обобщающим и вводным словам. Если все это служит, чтобы однозначно, логично и последовательно донести информацию, то в этом нет ничего плохого, хотя читается сложно.
Почему-то аналитики часто начинают смешивать научный стиль с офисно-деловым, самым консервативным. Там много устоявшихся клише, терминологии, отглагольных существительных, сложных предложений, официальных слов, бесконечных названий и аббревиатур. Получается совсем нечитаемые конструкции вида: «По окончании выполнения расчета регистрируется высокоприоритетная заявка». Видимо, авторы хотят таким образом сделать текст более внушительным. В итоге теряется однозначность информации, а чтение и без того сложного текста становится очень затратной задачей. Каждый канцеляризм в тексте превращает его в договор. Никто не любит читать договоры.
Реже бывают случаи, когда спецификации пытаются составлять в публицистическом, художественном или разговорном стиле. Тогда в тексте появляются эвфемизмы, обобщения и лирические отступления. Например, «В этот момент система решает вопрос отображения сообщения об ошибке. Не знаю, есть ли среди пользователей англичане, но сообщение нужно на английском». Предполагаю, что таким образом авторы хотят сделать чтение документа увлекательным. Действительно ли читатели технических документов готовы тратить время на художественные отступления?
Штампы и канцеляризмы из других текстов легко въедаются в стиль, которым пишут аналитики. От этого можно избавиться, если несколько раз вычитывать свои тексты, чтобы убирать из них лишнее, и помнить о целях и читателях.
📍По окончании выполнения расчета регистрируется высокоприоритетная заявка → После расчета система создает заявку с приоритетом «Высокий»
📍На данном этапе разработка приложения идёт по плану. → Разработка приложения идет по плану.
В дополнение хорошая статья про страдательный залог в технической документации
#мысливслух #что_почитать
В русском языке выделяют пять основных стилей:
• научный,
• официально-деловой,
• публицистический,
• разговорный,
• художественный
Как думаете, в каком стиле аналитики пишут свои документы? Наиболее последовательным, логичным и точным считается научный стиль. Его мы легко угадываем по монотонному звучанию, множеству терминов, пассивному залогу, сложным предложениям, обобщающим и вводным словам. Если все это служит, чтобы однозначно, логично и последовательно донести информацию, то в этом нет ничего плохого, хотя читается сложно.
Почему-то аналитики часто начинают смешивать научный стиль с офисно-деловым, самым консервативным. Там много устоявшихся клише, терминологии, отглагольных существительных, сложных предложений, официальных слов, бесконечных названий и аббревиатур. Получается совсем нечитаемые конструкции вида: «По окончании выполнения расчета регистрируется высокоприоритетная заявка». Видимо, авторы хотят таким образом сделать текст более внушительным. В итоге теряется однозначность информации, а чтение и без того сложного текста становится очень затратной задачей. Каждый канцеляризм в тексте превращает его в договор. Никто не любит читать договоры.
Реже бывают случаи, когда спецификации пытаются составлять в публицистическом, художественном или разговорном стиле. Тогда в тексте появляются эвфемизмы, обобщения и лирические отступления. Например, «В этот момент система решает вопрос отображения сообщения об ошибке. Не знаю, есть ли среди пользователей англичане, но сообщение нужно на английском». Предполагаю, что таким образом авторы хотят сделать чтение документа увлекательным. Действительно ли читатели технических документов готовы тратить время на художественные отступления?
Штампы и канцеляризмы из других текстов легко въедаются в стиль, которым пишут аналитики. От этого можно избавиться, если несколько раз вычитывать свои тексты, чтобы убирать из них лишнее, и помнить о целях и читателях.
📍По окончании выполнения расчета регистрируется высокоприоритетная заявка → После расчета система создает заявку с приоритетом «Высокий»
📍На данном этапе разработка приложения идёт по плану. → Разработка приложения идет по плану.
В дополнение хорошая статья про страдательный залог в технической документации
Хабр
«Кто на ком стоял?» Про страдательный залог в технической документации
В технической и пользовательской документации часто встречаются фразы с использованием страдательного залога. Параметры там «задаются», файлы «сохраняются», а программа «запускается». Ох, опасная эта...
🔥2
Иногда лучше потратить немножко времени, чтобы потом его сберечь
#мысливслух #кейс
Неделю назад я поучаствовала в разборе кейса про решение конфликтов. Постановка задачи затянула. Дано: тимлид команды разработки не видит ценности в работе аналитика и ведет разработку сам, без учета результатов анализа. Получается, что аналитик работает сам по себе, никто не ждет результатов его работы, разработка ведется параллельно. Аналитика не привлекают к решению открытых вопросов.
Подумала, что аналитик, особенно БА часто работает под скептическими взглядами «посмотрим, что ты нам скажешь, балабол». Я часто слышу что-то вроде: «И так же понятно, надо делать вот так и так, зачем тратить время на поиск чего-то и на документы». Обычно «так и так» оказывается видением картины с точки зрения ИТ-инженера, не отвечающим потребностям пользователей. Сделанное таким образом в 90% случаев приходится переделывать. При этом ситуация неочевидна для ее активных участников, зато заметно, что пока аналитик проводит какие-то непонятные исследования или проектирование, люди уже «что-то делают». Если в такой ситуации не отстаивать свои границы и не показывать ценность своей работы, то можно оказаться отрезанным от нужной информации и выглядеть странно в глазах команды и заказчиков. Поэтому нужны отличные навыки коммуникации и умение обосновывать ценность своей работы.
В случае с кейсом выводы оказались такими:
🔅Нужно оценить ситуацию с точки зрения влияния на бизнес, трудностей для себя, возможностей решения (например, эскалации или получения информации по задаче из других источников)
🔅Показать тимлиду проблемы с помощью обратной связи. В том числе обратить внимание на нарушение своих границ, в случае, если к вам относятся как к "балаболу"
🔅Оценить реакцию на обратную связь. Если столкнулись с отказом выслушать или неприятием, то пора эскалировать. Если удается донести ценность своей работы, то начинать договариваться о сотрудничестве в рамках общего процесса работы
#мысливслух #кейс
Неделю назад я поучаствовала в разборе кейса про решение конфликтов. Постановка задачи затянула. Дано: тимлид команды разработки не видит ценности в работе аналитика и ведет разработку сам, без учета результатов анализа. Получается, что аналитик работает сам по себе, никто не ждет результатов его работы, разработка ведется параллельно. Аналитика не привлекают к решению открытых вопросов.
Подумала, что аналитик, особенно БА часто работает под скептическими взглядами «посмотрим, что ты нам скажешь, балабол». Я часто слышу что-то вроде: «И так же понятно, надо делать вот так и так, зачем тратить время на поиск чего-то и на документы». Обычно «так и так» оказывается видением картины с точки зрения ИТ-инженера, не отвечающим потребностям пользователей. Сделанное таким образом в 90% случаев приходится переделывать. При этом ситуация неочевидна для ее активных участников, зато заметно, что пока аналитик проводит какие-то непонятные исследования или проектирование, люди уже «что-то делают». Если в такой ситуации не отстаивать свои границы и не показывать ценность своей работы, то можно оказаться отрезанным от нужной информации и выглядеть странно в глазах команды и заказчиков. Поэтому нужны отличные навыки коммуникации и умение обосновывать ценность своей работы.
В случае с кейсом выводы оказались такими:
🔅Нужно оценить ситуацию с точки зрения влияния на бизнес, трудностей для себя, возможностей решения (например, эскалации или получения информации по задаче из других источников)
🔅Показать тимлиду проблемы с помощью обратной связи. В том числе обратить внимание на нарушение своих границ, в случае, если к вам относятся как к "балаболу"
🔅Оценить реакцию на обратную связь. Если столкнулись с отказом выслушать или неприятием, то пора эскалировать. Если удается донести ценность своей работы, то начинать договариваться о сотрудничестве в рамках общего процесса работы
👍3
День рождения в октябре
#что_почитать #мысливслух #субботнее
Сегодня нашему уютному каналу ровно 2 месяца! За месяц нас стало в два раза больше. Стало больше прочтений, больше реакций, пересылок и комментариев. Пока еще я как ребенок радуюсь каждому комментарию и реакции — значит вы читаете и текст откликается.
Должна сказать, что обмен знаниями затягивает. Умение писать совсем легко пока еще не пришло, по-прежнему каждый пост перечитываю и корректирую. Зато стало интересно поделиться чем-то и ждать реакции читателей. Например, особенно интересно было рассказать о подмеченном на Analyst Days-17, причем рассказать сразу нескольким десяткам человек. Кстати, посты с тегом #analyst_days оказались в топ-5 по количеству просмотров.
Посмотрела какие публикации за 30 дней набрали больше просмотров, реакций и пересылок. Получилось так:
📍Очень вредно не ездить на бал, когда ты этого заслуживаешь
📍Итоги кейса про снабжение экспедиции
📍Почему не удалось с первой попытки найти приоритеты?
📍Подборка статей о User Story
📍Analyst Days – 17, день второй
#что_почитать #мысливслух #субботнее
Сегодня нашему уютному каналу ровно 2 месяца! За месяц нас стало в два раза больше. Стало больше прочтений, больше реакций, пересылок и комментариев. Пока еще я как ребенок радуюсь каждому комментарию и реакции — значит вы читаете и текст откликается.
Должна сказать, что обмен знаниями затягивает. Умение писать совсем легко пока еще не пришло, по-прежнему каждый пост перечитываю и корректирую. Зато стало интересно поделиться чем-то и ждать реакции читателей. Например, особенно интересно было рассказать о подмеченном на Analyst Days-17, причем рассказать сразу нескольким десяткам человек. Кстати, посты с тегом #analyst_days оказались в топ-5 по количеству просмотров.
Посмотрела какие публикации за 30 дней набрали больше просмотров, реакций и пересылок. Получилось так:
📍Очень вредно не ездить на бал, когда ты этого заслуживаешь
📍Итоги кейса про снабжение экспедиции
📍Почему не удалось с первой попытки найти приоритеты?
📍Подборка статей о User Story
📍Analyst Days – 17, день второй
🔥4❤1
Чем отличаются критерии приемки и DOD?
#agile
Делюсь еще одним текстом из рассылки от Майка Кона, на этот раз о двух видах критериев. Оригинал на Яндекс Диске
________________________________
Меня постоянно спрашивают в чем разница между Acceptance Criteria и Definition of done.
Я разъясню в двух словах. Acceptance criteria (Критерии приемки) уникальны для каждого элемента бэклога продукта. Какие-то критерии становится приемочными, когда они настолько важны для владельца продукта, что если продукт им не соответствует, то он просто не будет принят. Definition of done универсальны, то есть включают те критерии, которым должны соответствовать практически все элементы бэклога продукта.
Пример. Здесь представлен пример того, как я использую Acceptance criteria и Definition of done прямо сейчас в создании моего видео. Недавно я снял видео на тему разницы между этими понятиями.
Acceptance criteria для этого видео были:
1. Объяснить, что такое Acceptance criteria,
2. Объяснить, что такое Definition of done,
3. Объяснить разницу между ними.
Но каждое мое видео одновременно должно соответствовать моему Definition of done:
1. Видео должно начинаться с короткого вступления
2. Видео должно быть настолько коротким, насколько это возможно, чтобы проявить уважение к затраченному зрителем времени.
3. В видео должно быть напоминанием для зрителей поставить лайк и подписаться.
4. Видео должно иметь обложку, если видео длиннее одной минуты.
5. У видео должно быть короткое описание.
6. Мне нужно добавить ссылки на другие мои видео.
Кто формулирует acceptance criteria? Владелец продукта формулирует Acceptance criteria. В конце концов, именно он принимает продукт (или не принимает). Это не означает, что владелец продукта должен документировать все критерии, вместо этого конкретные критерии выводятся из вышестоящих acceptance criteria.
Кто формулирует definition of done? Definition of done формулируется с согласия всей команды, владельца продукта и Scrum Мастера. Эта формулировка может и должна развиваться со временем. Команда сходится на формулировке definition of done основываясь на общем понимании того, что означает создание высококачественного готового продукта в конкретном контексте.
#agile
Делюсь еще одним текстом из рассылки от Майка Кона, на этот раз о двух видах критериев. Оригинал на Яндекс Диске
________________________________
Меня постоянно спрашивают в чем разница между Acceptance Criteria и Definition of done.
Я разъясню в двух словах. Acceptance criteria (Критерии приемки) уникальны для каждого элемента бэклога продукта. Какие-то критерии становится приемочными, когда они настолько важны для владельца продукта, что если продукт им не соответствует, то он просто не будет принят. Definition of done универсальны, то есть включают те критерии, которым должны соответствовать практически все элементы бэклога продукта.
Пример. Здесь представлен пример того, как я использую Acceptance criteria и Definition of done прямо сейчас в создании моего видео. Недавно я снял видео на тему разницы между этими понятиями.
Acceptance criteria для этого видео были:
1. Объяснить, что такое Acceptance criteria,
2. Объяснить, что такое Definition of done,
3. Объяснить разницу между ними.
Но каждое мое видео одновременно должно соответствовать моему Definition of done:
1. Видео должно начинаться с короткого вступления
2. Видео должно быть настолько коротким, насколько это возможно, чтобы проявить уважение к затраченному зрителем времени.
3. В видео должно быть напоминанием для зрителей поставить лайк и подписаться.
4. Видео должно иметь обложку, если видео длиннее одной минуты.
5. У видео должно быть короткое описание.
6. Мне нужно добавить ссылки на другие мои видео.
Кто формулирует acceptance criteria? Владелец продукта формулирует Acceptance criteria. В конце концов, именно он принимает продукт (или не принимает). Это не означает, что владелец продукта должен документировать все критерии, вместо этого конкретные критерии выводятся из вышестоящих acceptance criteria.
Кто формулирует definition of done? Definition of done формулируется с согласия всей команды, владельца продукта и Scrum Мастера. Эта формулировка может и должна развиваться со временем. Команда сходится на формулировке definition of done основываясь на общем понимании того, что означает создание высококачественного готового продукта в конкретном контексте.
👍4
Интервью на удаленке. Чтобы удалось, надо пробовать и сегодня, и завтра, и послезавтра
#кейс #опыт
Работа бизнес-аналитика до некоторого времени строилась только на очных встречах и бонусом это давало возможность съездить в интересные командировки. Теперь я большинство интервью ставлю он-лайн и в этом формате оказалось тоже много преимуществ. В последнее время занимаюсь исследовательской задачей и провожу серию интервью с пользователями, поэтому вспомнила об этих преимуществах.
🔅 Я не идеальный интервьюер и в разговоре не всегда держу покер-фейс, могу невольно влиять на собеседника то кивком головы, то своими «ага» и «ну да». Ограниченный личный контакт помогает это компенсировать
🔅 Даже интроверты чувствуют себя в безопасности и неплохо общаются, когда сидят в удобном знакомом кресле, а не где-то в переговорке, где будет сложно встать и уйти
🔅 В моем опыте чаще всего те, кто согласился на он-лайн интервью, не возражают против записи встречи, а значит можно сосредоточиться на общении, а не на заметках в блокноте
🔅Мне проще не слишком явно для собеседника заглянуть в список вопросов на соседнем экране. На очной встрече взгляд в список вопросов может вызвать настороженность собеседника отчего он начнет отвечать цитатами из инструкций
🔅В разговоре собеседник легко может показать рабочий экран, если считает это важным. При необходимости я тоже могу наглядно поделиться пользовательским опытом даже если не готовилась специально
🔅 Не нужно искать переговорку и в целом можно поговорить с пользователями из разных офисов и разных городов
Чтобы все это действительно работало именно так, нужно немного подготовиться и выполнить несколько шагов. Нарисовала их на карточках. Надеюсь, пригодится тем, кто пока еще редко интервьюирует 🌱
#кейс #опыт
Работа бизнес-аналитика до некоторого времени строилась только на очных встречах и бонусом это давало возможность съездить в интересные командировки. Теперь я большинство интервью ставлю он-лайн и в этом формате оказалось тоже много преимуществ. В последнее время занимаюсь исследовательской задачей и провожу серию интервью с пользователями, поэтому вспомнила об этих преимуществах.
🔅 Я не идеальный интервьюер и в разговоре не всегда держу покер-фейс, могу невольно влиять на собеседника то кивком головы, то своими «ага» и «ну да». Ограниченный личный контакт помогает это компенсировать
🔅 Даже интроверты чувствуют себя в безопасности и неплохо общаются, когда сидят в удобном знакомом кресле, а не где-то в переговорке, где будет сложно встать и уйти
🔅 В моем опыте чаще всего те, кто согласился на он-лайн интервью, не возражают против записи встречи, а значит можно сосредоточиться на общении, а не на заметках в блокноте
🔅Мне проще не слишком явно для собеседника заглянуть в список вопросов на соседнем экране. На очной встрече взгляд в список вопросов может вызвать настороженность собеседника отчего он начнет отвечать цитатами из инструкций
🔅В разговоре собеседник легко может показать рабочий экран, если считает это важным. При необходимости я тоже могу наглядно поделиться пользовательским опытом даже если не готовилась специально
🔅 Не нужно искать переговорку и в целом можно поговорить с пользователями из разных офисов и разных городов
Чтобы все это действительно работало именно так, нужно немного подготовиться и выполнить несколько шагов. Нарисовала их на карточках. Надеюсь, пригодится тем, кто пока еще редко интервьюирует 🌱
👍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