Подборка про пользовательский опыт
#что_почитать
📍Адаптивное интервью пользователей В пятницу, пока мы здесь решали кейс, команда конференции Flow опубликовала видео доклада Дмитрия Сатина на Flow 2023. Этот доклад завершал второй очный день конференции и я немного писала о нем тут. Доклад посвящен одному из кейсов исследования опыта сотрудников бухгалтерии, но я бы посоветовала посмотреть не ради рецептов проведения интервью, их там не так много. Это выступление интересно кейсами и наблюдениями из опыта одного из ведущих UX-экспертов.
📍Have You Considered “Customer Information Needs” In Your Process? (EN) В этой статье автор проанализировал свой опыт ожидания отложенного рейса в аэропорту. Когда все идет по плану, то достаточно информации от служащих аэропорта и табло, потому что нужно только добраться до нужного гейта. Когда что-то меняется, то этот путь уже не работает, информации нужно больше и она должна чаще обновляться. Получить эту информацию проще в приложениях на смартфоне, чем где-то в аэропорту. Время переноса рейсов проще увидеть в приложении или на сайте авиакомпании; погоду проще увидеть за окном или опять же в приложении; в приложениях можно забронировать номер в отеле, если нет желания ночевать в аэропорту. Отсюда вывод — при проектировании процесса важно учитывать, что в успешных и в негативных сценариях потребность в информировании разная.
📍Как появился графический интерфейс пользователя: история в лицах, деталях, фактах и курсорах Большая статья о развития пользовательских интерфейсов с 1945 года и до наших дней. На иллюстрациях можно увидеть первые иконки, изображения первых курсоров, первые версии компьютерной мыши и не только. Как вам такое высказывание из 1968го года: «Если бы у вас, как у работника умственного труда, в офисе был компьютерный дисплей, за которым весь день работал бы компьютер, живущий за вас и мгновенно отвечающий, реагирующий на каждое ваше действие, какую ценность вы бы извлекли?»
#что_почитать
📍Адаптивное интервью пользователей В пятницу, пока мы здесь решали кейс, команда конференции Flow опубликовала видео доклада Дмитрия Сатина на Flow 2023. Этот доклад завершал второй очный день конференции и я немного писала о нем тут. Доклад посвящен одному из кейсов исследования опыта сотрудников бухгалтерии, но я бы посоветовала посмотреть не ради рецептов проведения интервью, их там не так много. Это выступление интересно кейсами и наблюдениями из опыта одного из ведущих UX-экспертов.
📍Have You Considered “Customer Information Needs” In Your Process? (EN) В этой статье автор проанализировал свой опыт ожидания отложенного рейса в аэропорту. Когда все идет по плану, то достаточно информации от служащих аэропорта и табло, потому что нужно только добраться до нужного гейта. Когда что-то меняется, то этот путь уже не работает, информации нужно больше и она должна чаще обновляться. Получить эту информацию проще в приложениях на смартфоне, чем где-то в аэропорту. Время переноса рейсов проще увидеть в приложении или на сайте авиакомпании; погоду проще увидеть за окном или опять же в приложении; в приложениях можно забронировать номер в отеле, если нет желания ночевать в аэропорту. Отсюда вывод — при проектировании процесса важно учитывать, что в успешных и в негативных сценариях потребность в информировании разная.
📍Как появился графический интерфейс пользователя: история в лицах, деталях, фактах и курсорах Большая статья о развития пользовательских интерфейсов с 1945 года и до наших дней. На иллюстрациях можно увидеть первые иконки, изображения первых курсоров, первые версии компьютерной мыши и не только. Как вам такое высказывание из 1968го года: «Если бы у вас, как у работника умственного труда, в офисе был компьютерный дисплей, за которым весь день работал бы компьютер, живущий за вас и мгновенно отвечающий, реагирующий на каждое ваше действие, какую ценность вы бы извлекли?»
👍3
Как можно выбрать одно из двух зол?
#кейс #инструменты
Бывает, что приходится участвовать в выборе из двух вариантов решения:
1) внедрить через месяц «костыльное» решение и со временем переделать,
2) сделать через 6 месяцев, но сразу грамотно.
У меня любой «костыльный» вариант вызывает аллергию, делать и переделывать - это же двойная работа! У тех, кто часто работает с этим на системном уровне, тем более мало радости от идеи пополнить техдолг 🙈 Ситуация начинает выглядеть иначе, если подсчитать стоимость задержки фичи в 6 месяцев (Cost of Delay).
Этот показатель считают как отношение стоимости задержки к общему времени, которое команда потратит на разработку и внедрение фичи. В примере с «костыльным решением» нужно учесть и время на «доведение до ума». Стоимость задержки складывается из нескольких показателей.
📍Упущенного дохода. Это произведение времени ожидания и суммы дохода, которую ожидалось получить в день, неделю или месяц, если бы фича вышла без задержек. Например, если предполагалось что фича принесет 100 тыс. рублей в месяц, то за 6 месяцев всего 600 тыс. дохода будет упущено
📍Дополнительных расходов. Это могут быть дополнительная оплата труда, стоимость поддержки пользователей, штрафы, оплата лицензий и пр. Например, из-за неудобного интерфейса от пользователей поступает больше среднего количества заявок в Колл-центр и Отдел поддержки, компании приходится оплачивать 8 часов внеурочной работы 10 сотрудников в неделю. За 6 месяцев 8 Х 10 Х 26 недель = 2080 рабочих часов придется оплатить
📍Потерянных возможностей. Здесь имеется в виду прогнозная сумма потерь, связанных с утратой доли рынка, потерей лояльности клиентов и т.п.
Складываем все три составляющие и делим на время производства фичи. После подсчета может оказаться, что "костыль" выгоднее, даже с учетом двойного времени на разработку.
Здесь видео Joshua Arnold, где про Cost of Delay рассказано в картинках
#кейс #инструменты
Бывает, что приходится участвовать в выборе из двух вариантов решения:
1) внедрить через месяц «костыльное» решение и со временем переделать,
2) сделать через 6 месяцев, но сразу грамотно.
У меня любой «костыльный» вариант вызывает аллергию, делать и переделывать - это же двойная работа! У тех, кто часто работает с этим на системном уровне, тем более мало радости от идеи пополнить техдолг 🙈 Ситуация начинает выглядеть иначе, если подсчитать стоимость задержки фичи в 6 месяцев (Cost of Delay).
Этот показатель считают как отношение стоимости задержки к общему времени, которое команда потратит на разработку и внедрение фичи. В примере с «костыльным решением» нужно учесть и время на «доведение до ума». Стоимость задержки складывается из нескольких показателей.
📍Упущенного дохода. Это произведение времени ожидания и суммы дохода, которую ожидалось получить в день, неделю или месяц, если бы фича вышла без задержек. Например, если предполагалось что фича принесет 100 тыс. рублей в месяц, то за 6 месяцев всего 600 тыс. дохода будет упущено
📍Дополнительных расходов. Это могут быть дополнительная оплата труда, стоимость поддержки пользователей, штрафы, оплата лицензий и пр. Например, из-за неудобного интерфейса от пользователей поступает больше среднего количества заявок в Колл-центр и Отдел поддержки, компании приходится оплачивать 8 часов внеурочной работы 10 сотрудников в неделю. За 6 месяцев 8 Х 10 Х 26 недель = 2080 рабочих часов придется оплатить
📍Потерянных возможностей. Здесь имеется в виду прогнозная сумма потерь, связанных с утратой доли рынка, потерей лояльности клиентов и т.п.
Складываем все три составляющие и делим на время производства фичи. После подсчета может оказаться, что "костыль" выгоднее, даже с учетом двойного времени на разработку.
Здесь видео Joshua Arnold, где про Cost of Delay рассказано в картинках
Vimeo
Cost of Delay – An Introduction
Cost of Delay is a way of communicating the impact of time on value. Not just how valuable something is, but how urgent it is. The value that we miss out on when…
👍4🔥2
Каркасное проектирование или wireframes
#кейс #инструменты #прототипы
Каркасное представление (чаще называется wireframe) - это скетч, который показывает основную идею экрана и общее расположение элементов. Не предполагается ни динамики, ни отображения внешнего вида элементов. Обычно каркасное представление выполняется в черно-белом варианте. Писала о нем в статье о прототипах
Сделала небольшой пример. Я его сделала в Figma, потому что мне так было удобно. Для аналитика основная ценность вайрфрейма в том, что он не требует знания сложных графических редакторов. Figma подходит только тем, кто в нем часто работает. Проще нарисовать в Miro, Lucidchart, Balsamiq или Draw.io, а еще можно просто на бумаге или на доске в переговорке. На карточках к посту пример и небольшая памятка по использованию вайрфреймов.
В одном из проектов как-то нужно было выбрать какой интервал времени пользователь считает как «круглосуточно», использовать приходилось именно маску чч:мм. Сначала мы спорили с заказчиками пару часов, а потом написали наши варианты на листах бумаги и пошли по коридорам спрашивать коллег об их впечатлениях. Если честно, уже не помню точно, какие версии обсуждали и какую выбрали. Кажется, на одном листе было «с 00:00 по 23:59», а на другом «с 00:00 по 00:00». А вы бы какой выбрали?
#кейс #инструменты #прототипы
Каркасное представление (чаще называется wireframe) - это скетч, который показывает основную идею экрана и общее расположение элементов. Не предполагается ни динамики, ни отображения внешнего вида элементов. Обычно каркасное представление выполняется в черно-белом варианте. Писала о нем в статье о прототипах
Сделала небольшой пример. Я его сделала в Figma, потому что мне так было удобно. Для аналитика основная ценность вайрфрейма в том, что он не требует знания сложных графических редакторов. Figma подходит только тем, кто в нем часто работает. Проще нарисовать в Miro, Lucidchart, Balsamiq или Draw.io, а еще можно просто на бумаге или на доске в переговорке. На карточках к посту пример и небольшая памятка по использованию вайрфреймов.
В одном из проектов как-то нужно было выбрать какой интервал времени пользователь считает как «круглосуточно», использовать приходилось именно маску чч:мм. Сначала мы спорили с заказчиками пару часов, а потом написали наши варианты на листах бумаги и пошли по коридорам спрашивать коллег об их впечатлениях. Если честно, уже не помню точно, какие версии обсуждали и какую выбрали. Кажется, на одном листе было «с 00:00 по 23:59», а на другом «с 00:00 по 00:00». А вы бы какой выбрали?
👍2🔥1
Инженерия требований
Элизабет Халл, Кен Джексон, Джереми Дик. Год издания: 2017
#книжки
Мне в руки попало второе издание 2005 года под названием «Разработка и управление требованиями» (Requirement Engeneering), в заголовке год и название третьего издания, название изменилось в другом переводе. Само по себе это чтение сложно назвать увлекательным — книга составлена в академическом стиле, начинается подробным введением с описанием причин неуспеха проектов и важной роли требований в этом неуспехе. К сегодняшнему дню такие цифры и рассуждения мы уже видели много раз (в частности в книгах и статьях К. Вигерса, один из примеров тут)
О чем книга?
Авторы затрагивают все области разработки требований и управления ими. Отдельное внимание уделено моделированию. Книга структурирована так, чтобы читатель переходил от раздела к разделу и поэтапно изучал работу с требованиями от общего процесса разработки требований к вопросам моделирования, а затем к написанию требований и к управлению ими
Что может быть полезно?
Я бы отметила важный акцент на понимании системной инженерии и инженерии требований как ее части. Здесь под системой имеется в виду не программное обеспечение, а система как совокупность взаимодействующих элементов, в том числе и людей. В этом контексте рассмотрены и понятие «требование», и связь уровней требований с уровнями тестирования, и связи требований между собой. Особенно полезно, что все материалы связаны в единую структуру и получается не описание набора отдельных инструментов, а единая концепция работы с требованиями
Кому может быть полезно?
Начинающим и бизнес-, и системным аналитикам, чтобы познакомиться с инженерией требований. Опытным аналитикам пригодиться как материал, к которому можно обращаться, чтобы «сверить часы»
Элизабет Халл, Кен Джексон, Джереми Дик. Год издания: 2017
#книжки
Мне в руки попало второе издание 2005 года под названием «Разработка и управление требованиями» (Requirement Engeneering), в заголовке год и название третьего издания, название изменилось в другом переводе. Само по себе это чтение сложно назвать увлекательным — книга составлена в академическом стиле, начинается подробным введением с описанием причин неуспеха проектов и важной роли требований в этом неуспехе. К сегодняшнему дню такие цифры и рассуждения мы уже видели много раз (в частности в книгах и статьях К. Вигерса, один из примеров тут)
О чем книга?
Авторы затрагивают все области разработки требований и управления ими. Отдельное внимание уделено моделированию. Книга структурирована так, чтобы читатель переходил от раздела к разделу и поэтапно изучал работу с требованиями от общего процесса разработки требований к вопросам моделирования, а затем к написанию требований и к управлению ими
Что может быть полезно?
Я бы отметила важный акцент на понимании системной инженерии и инженерии требований как ее части. Здесь под системой имеется в виду не программное обеспечение, а система как совокупность взаимодействующих элементов, в том числе и людей. В этом контексте рассмотрены и понятие «требование», и связь уровней требований с уровнями тестирования, и связи требований между собой. Особенно полезно, что все материалы связаны в единую структуру и получается не описание набора отдельных инструментов, а единая концепция работы с требованиями
Кому может быть полезно?
Начинающим и бизнес-, и системным аналитикам, чтобы познакомиться с инженерией требований. Опытным аналитикам пригодиться как материал, к которому можно обращаться, чтобы «сверить часы»
👍4
Слушать активно, а говорить короче
#мысливслух #что_почитать
Недавно в одном из чатов обсуждали почему даже внутри команды важны навыки общения. Кому-то из участников тимлид на 1-to-1 сделал замечание насчет общения в команде. Возник вопрос: «Почему просто не принять во внимание, что в команде есть такой, кто говорит грубо и этого его фишка, а не желание задеть?»
Принять во внимание можно, но до того момента пока потери команды от сложных коммуникаций меньше, чем вклад участника в общий результат. Когда мне приходится пробираться к ответу на уточняющий вопрос через набор неприемлемых для меня комментариев или путанных формулировок, то невольно задумаешься на что потрачено время🤔
Чем проще и яснее получается донести свою мысль и услышать чье-то мнение, тем быстрее и с меньшими рисками можно решить задачу. Приходилось вам провести час на встрече, где все что-то горячо обсуждают, а вы пытаетесь понять о чем вообще речь? Понять не получается, потому что каждый говорит как-будто сам с собой и думает только о том, что он скажет дальше и как бы ему обязательно что-то сказать☺️
На фоне этих грустных мыслей встретилось две статьи в блогах для аналитиков
• Mastering the Art of Communication и
• 10 Simple Hacks to Improve Communication Skills
В статьях несколько советов и самыми удачными мне показались такие
📍Активно слушать. Это не про то, чтобы услышать слова, а еще и постараться понять, что в них вложено. Сколько раз вы ловили себя на мысли, что больше думаете, что скажете дальше, чем вникаете в суть услышанного?
📍В высказываниях не отделять себя от команды. Когда чаще звучит «мы» или «наша команда», чем «я», то создается атмосфера общей работы и уважения к вкладу каждого. Люди часто неосознанно (и осознанно!) исключают других из результата и этот небольшой шаг может привести к недоверию и конфликтам
📍Чем короче, тем лучше. Нужно оценить аудиторию и сформулировать высказывание в понятных ей терминах. Не нужно пытаться донести мысль избыточными пояснениями. Хороший навык общения означает еще и понимать, когда промолчать
А у вас сколько сил и времени уходит на общение в команде?
#мысливслух #что_почитать
Недавно в одном из чатов обсуждали почему даже внутри команды важны навыки общения. Кому-то из участников тимлид на 1-to-1 сделал замечание насчет общения в команде. Возник вопрос: «Почему просто не принять во внимание, что в команде есть такой, кто говорит грубо и этого его фишка, а не желание задеть?»
Принять во внимание можно, но до того момента пока потери команды от сложных коммуникаций меньше, чем вклад участника в общий результат. Когда мне приходится пробираться к ответу на уточняющий вопрос через набор неприемлемых для меня комментариев или путанных формулировок, то невольно задумаешься на что потрачено время
Чем проще и яснее получается донести свою мысль и услышать чье-то мнение, тем быстрее и с меньшими рисками можно решить задачу. Приходилось вам провести час на встрече, где все что-то горячо обсуждают, а вы пытаетесь понять о чем вообще речь? Понять не получается, потому что каждый говорит как-будто сам с собой и думает только о том, что он скажет дальше и как бы ему обязательно что-то сказать
На фоне этих грустных мыслей встретилось две статьи в блогах для аналитиков
• Mastering the Art of Communication и
• 10 Simple Hacks to Improve Communication Skills
В статьях несколько советов и самыми удачными мне показались такие
📍Активно слушать. Это не про то, чтобы услышать слова, а еще и постараться понять, что в них вложено. Сколько раз вы ловили себя на мысли, что больше думаете, что скажете дальше, чем вникаете в суть услышанного?
📍В высказываниях не отделять себя от команды. Когда чаще звучит «мы» или «наша команда», чем «я», то создается атмосфера общей работы и уважения к вкладу каждого. Люди часто неосознанно (и осознанно!) исключают других из результата и этот небольшой шаг может привести к недоверию и конфликтам
📍Чем короче, тем лучше. Нужно оценить аудиторию и сформулировать высказывание в понятных ей терминах. Не нужно пытаться донести мысль избыточными пояснениями. Хороший навык общения означает еще и понимать, когда промолчать
А у вас сколько сил и времени уходит на общение в команде?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🤩1
Зимние аналитические задачи
#мысливслух #истории
Каждый раз в конце зимы девушки в ИТ решают непростую бизнес-аналитическую задачу. Как ограниченными ресурсами устроить праздник бОльшей части команды? Пригождаются и анализ потребностей, и подсчет метрик, и знание логистики 🌱
Когда села за предпраздничный пост, постаралась вспомнить какие поздравления оставили больше всего впечатлений? Пожалуй те, когда впервые пришлось думать как организовать праздник на полной удаленке. Это было сложно, потому что у нас еще мало было опыта. Придумали в Miro доску, на которой каждый открывал свою собственную карточку с пожеланиями. Разобрали пожелания на общем созвоне. Запомнился именно творческий процесс: найти идеи, согласовать между собой, придумать тексты в нужном количестве...
Поделитесь, кто-то сегодня устраивает викторины и конкурсы?🎉
#мысливслух #истории
Каждый раз в конце зимы девушки в ИТ решают непростую бизнес-аналитическую задачу. Как ограниченными ресурсами устроить праздник бОльшей части команды? Пригождаются и анализ потребностей, и подсчет метрик, и знание логистики 🌱
Когда села за предпраздничный пост, постаралась вспомнить какие поздравления оставили больше всего впечатлений? Пожалуй те, когда впервые пришлось думать как организовать праздник на полной удаленке. Это было сложно, потому что у нас еще мало было опыта. Придумали в Miro доску, на которой каждый открывал свою собственную карточку с пожеланиями. Разобрали пожелания на общем созвоне. Запомнился именно творческий процесс: найти идеи, согласовать между собой, придумать тексты в нужном количестве...
Поделитесь, кто-то сегодня устраивает викторины и конкурсы?
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉4🤩1
Подборка про User Story и USM
#что_почитать
📍Confused between theme epic, story and acceptance criteria? (ENG) Статья о том, для чего предназначены разные элементы бэклога. Понравилось, что объяснение дано на примерах, получилось коротко и очень наглядно. Картинка к этому посту взята из текста статьи
📍User Story Mapping – инструкция по применению Статья в блоге ScrumTrek, по дате публикации не слишком новая. Привлекла мое внимание объяснением на простом примере с сайтом магазина цветов
📍User Story Map. Истории нужно рассказывать Решила напомнить о моей статье про USM. В ней короткое описание техники, комментарии к особенностям применения и ссылки на три хорошие статьи по той же теме
#что_почитать
📍Confused between theme epic, story and acceptance criteria? (ENG) Статья о том, для чего предназначены разные элементы бэклога. Понравилось, что объяснение дано на примерах, получилось коротко и очень наглядно. Картинка к этому посту взята из текста статьи
📍User Story Mapping – инструкция по применению Статья в блоге ScrumTrek, по дате публикации не слишком новая. Привлекла мое внимание объяснением на простом примере с сайтом магазина цветов
📍User Story Map. Истории нужно рассказывать Решила напомнить о моей статье про USM. В ней короткое описание техники, комментарии к особенностям применения и ссылки на три хорошие статьи по той же теме
👍1🔥1
Чашки и их свойства в разных системах
#мысливслух
В поезде недавно предложили на выбор два способа подачи кофе 1) в стакане и 2) в обычной чашке. Как думаете, что выбирают чаще?
Вспомнилась недавно прочтенная книга по инженерии требований, где на примере чашки объясняется понятие «система». Чашка как система полна интерфейсов. Есть интерфейсы для заполнения, для держания рукой, для стола. Чтобы система помогала достигать поставленных целей, ее интерфейсы должны учитывать несколько особенностей, без которых не сформулировать требования к системе.
📍Особенности взаимодействия ее компонент. В случае с чашкой объем емкости и размер ручки для ее держания должны соответствовать друг-другу
📍 Особенности взаимодействия с внешними компонентами. Стол на вашей кухне и складной столик в поезде отличаются по свойствам
📍 Включение в общую систему. Среди обычной домашней посуды чашку и мыть проще, и в кофеварку удобнее поставить, а подстаканник выглядит странным сувениром. Те, кто охотно используют его в поездке, не слишком хотят покупать его в каталоге «Товары в дорогу»
📍 Внешние условия. По сравнению с чашкой, стакан в подстаканнике лучше приспособлен к условиям в движущемся вагоне. Ручку можно крепко охватить пальцами, нижняя часть очень устойчивая…
В поездке чаще выбирают вариант подачи с подстаканником, чашка хуже отвечает внешним условиям. Когда ваши пользователи не хотят работать с какой-то фичей, может быть вы предлагаете хрупкую чашку вместо грубой, но более подходящей прочной конструкции?
А если такую конструкцию сфоткать и дополнить пост в экспертном блоге, то все без слов поймут, что вы куда-то ехали поездом и дочитывали книгу о требованиях☺️
#мысливслух
В поезде недавно предложили на выбор два способа подачи кофе 1) в стакане и 2) в обычной чашке. Как думаете, что выбирают чаще?
Вспомнилась недавно прочтенная книга по инженерии требований, где на примере чашки объясняется понятие «система». Чашка как система полна интерфейсов. Есть интерфейсы для заполнения, для держания рукой, для стола. Чтобы система помогала достигать поставленных целей, ее интерфейсы должны учитывать несколько особенностей, без которых не сформулировать требования к системе.
📍Особенности взаимодействия ее компонент. В случае с чашкой объем емкости и размер ручки для ее держания должны соответствовать друг-другу
📍 Особенности взаимодействия с внешними компонентами. Стол на вашей кухне и складной столик в поезде отличаются по свойствам
📍 Включение в общую систему. Среди обычной домашней посуды чашку и мыть проще, и в кофеварку удобнее поставить, а подстаканник выглядит странным сувениром. Те, кто охотно используют его в поездке, не слишком хотят покупать его в каталоге «Товары в дорогу»
📍 Внешние условия. По сравнению с чашкой, стакан в подстаканнике лучше приспособлен к условиям в движущемся вагоне. Ручку можно крепко охватить пальцами, нижняя часть очень устойчивая…
В поездке чаще выбирают вариант подачи с подстаканником, чашка хуже отвечает внешним условиям. Когда ваши пользователи не хотят работать с какой-то фичей, может быть вы предлагаете хрупкую чашку вместо грубой, но более подходящей прочной конструкции?
А если такую конструкцию сфоткать и дополнить пост в экспертном блоге, то все без слов поймут, что вы куда-то ехали поездом и дочитывали книгу о требованиях
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥3😁2
Перезимовали!
#что_почитать #навигация
Как же я рада, что зима уходит! В феврале было сложно собираться с мыслями из-за нехватки солнца и избытка простуд. Картинка к посту в этот раз не от нейросети, а от Исаака Левитана. Называется «Март», 1895 год. Хорошо отражает настроение начала весны, правда?
Собрала здесь материалы февраля и ссылки на навигацию по постам января и декабря,
📍Как аналитику избежать когнитивных искажений?
📍Подборка про пользовательский опыт
📍Cost of Delay. Как можно выбрать одно из двух зол?
📍Каркасное проектирование или wireframes
📍Слушать активно, а говорить короче
🌱Материалы декабря’23
🌱Материалы января
#что_почитать #навигация
Как же я рада, что зима уходит! В феврале было сложно собираться с мыслями из-за нехватки солнца и избытка простуд. Картинка к посту в этот раз не от нейросети, а от Исаака Левитана. Называется «Март», 1895 год. Хорошо отражает настроение начала весны, правда?
Собрала здесь материалы февраля и ссылки на навигацию по постам января и декабря,
📍Как аналитику избежать когнитивных искажений?
📍Подборка про пользовательский опыт
📍Cost of Delay. Как можно выбрать одно из двух зол?
📍Каркасное проектирование или wireframes
📍Слушать активно, а говорить короче
🌱Материалы декабря’23
🌱Материалы января
👍3❤🔥2❤1
Разнообразие начальных событий в BPMN
#кейс
Недавно с менти решали кейс на описание процесса в BPMN. И знаете что оказалось сложным? Мне было тяжело вывести разговор из категорий «правильно — неправильно». Не сразу поняла, что от нотации ожидаются какие-то однозначно принятые обозначения. Тем временем вариантов больше одного.
Всего в BPMN 13 типов событий из них 10 применимы к стартовым. Можно найти полный список в приложении к статье Как начать моделировать бизнес-процессы в BPMN. Легко читаются простое событие, событие-сообщение и событие-таймер. Если начать использовать весь арсенал событий-условий, то не нужно рассчитывать, что схема будет понятна любому. Это мнение вычитала в статье Анатолия Белайчука Главное не результат, главное процесс и полностью согласна 🌱
Кейс. Начать оформление заказа можно из мобильного приложения магазина, а можно с сайта. Все заказы собираются в единую очередь на выполнение и по общим правилам берутся в работу. Для этого кейса выбрали два варианта:
🔸Вариант 1 с простыми событиями
🔸Вариант 2 с комплексным событием, когда процесс стартует при выполнении одного из условий в подписи.
На ваш взгляд, какой проще читается?
#кейс
Недавно с менти решали кейс на описание процесса в BPMN. И знаете что оказалось сложным? Мне было тяжело вывести разговор из категорий «правильно — неправильно». Не сразу поняла, что от нотации ожидаются какие-то однозначно принятые обозначения. Тем временем вариантов больше одного.
Всего в BPMN 13 типов событий из них 10 применимы к стартовым. Можно найти полный список в приложении к статье Как начать моделировать бизнес-процессы в BPMN. Легко читаются простое событие, событие-сообщение и событие-таймер. Если начать использовать весь арсенал событий-условий, то не нужно рассчитывать, что схема будет понятна любому. Это мнение вычитала в статье Анатолия Белайчука Главное не результат, главное процесс и полностью согласна 🌱
Кейс. Начать оформление заказа можно из мобильного приложения магазина, а можно с сайта. Все заказы собираются в единую очередь на выполнение и по общим правилам берутся в работу. Для этого кейса выбрали два варианта:
🔸Вариант 1 с простыми событиями
🔸Вариант 2 с комплексным событием, когда процесс стартует при выполнении одного из условий в подписи.
На ваш взгляд, какой проще читается?
👍4🔥1
Дизайн пользовательского опыта
Джон Уэллен. Год выхода 2021
#книжки
В мой список чтения эта книга попала из продуктовых чатиков, привлекла внимание словами про пользовательский опыт. Оказалось, что есть нюансы перевода. В оригинале название Design for How People Think, так что это про всех людей и их взаимодействие с любыми продуктами, а не только о тех, что нажимают кнопки в наших с вами приложениях.
Впечатление двоякое. Структура изложения вполне адекватная, не встретилось ничего, с чем я была бы несогласна, но и нового как-то очень мало повезло узнать
О чем книга?
Понимание пользовательского опыта разобрано на шесть составляющих и о каждой рассказано с примерами и отсылками к когнитивной психологии. Составляющие такие:
• Внимание и визуальное восприятие
• Навигация
• Язык
• Принятие решений
• Эмоции
• Память
Рассказано о технике исследования пользовательского опыта и о построении решений с учетом этих составляющих опыта.
Что может быть полезно?
Самой полезной выглядит вторая часть, где речь идет о контекстных интервью. Это метод исследования, когда пользователя изучают в его естественной среде, наблюдая за его действиями. В книге детально описаны шаги подготовки к такому интервью и интерпретация результатов.
Еще интересно знакомиться с примерами, некоторые даны в картинках, чтобы можно было оценить как работают внимание, понимание пространства, восприятие терминов, принятие решений. На сайте издательства есть пара разворотов книги, можно посмотреть
Кому может быть полезно?
Аналитикам и продактам, которые делают первые шаги в исследованиях пользовательского опыта и проведении интервью. Вряд ли даст много нового тем, кто уже год или больше интервьюирует и исследует
Джон Уэллен. Год выхода 2021
#книжки
В мой список чтения эта книга попала из продуктовых чатиков, привлекла внимание словами про пользовательский опыт. Оказалось, что есть нюансы перевода. В оригинале название Design for How People Think, так что это про всех людей и их взаимодействие с любыми продуктами, а не только о тех, что нажимают кнопки в наших с вами приложениях.
Впечатление двоякое. Структура изложения вполне адекватная, не встретилось ничего, с чем я была бы несогласна, но и нового как-то очень мало повезло узнать
О чем книга?
Понимание пользовательского опыта разобрано на шесть составляющих и о каждой рассказано с примерами и отсылками к когнитивной психологии. Составляющие такие:
• Внимание и визуальное восприятие
• Навигация
• Язык
• Принятие решений
• Эмоции
• Память
Рассказано о технике исследования пользовательского опыта и о построении решений с учетом этих составляющих опыта.
Что может быть полезно?
Самой полезной выглядит вторая часть, где речь идет о контекстных интервью. Это метод исследования, когда пользователя изучают в его естественной среде, наблюдая за его действиями. В книге детально описаны шаги подготовки к такому интервью и интерпретация результатов.
Еще интересно знакомиться с примерами, некоторые даны в картинках, чтобы можно было оценить как работают внимание, понимание пространства, восприятие терминов, принятие решений. На сайте издательства есть пара разворотов книги, можно посмотреть
Кому может быть полезно?
Аналитикам и продактам, которые делают первые шаги в исследованиях пользовательского опыта и проведении интервью. Вряд ли даст много нового тем, кто уже год или больше интервьюирует и исследует
❤2
Богатыри, цветы и дворцы
#мысливслух #истории
В те далекие времена, когда я работала в заказной разработке, было принято отправлять аналитиков в командировки. Чаще, чтобы изучить заказчика в его собственном офисе, а иногда — познакомиться с сильно распределенной частью команды. Оказаться на проекте с перспективой интересных командировок считалось хорошим опытом.
Однажды, как раз накануне 8го марта, я должна была отправиться в края, где этот день не был выходным. Все предвещало хороший, но непраздничный опыт.
В день перед отъездом сижу за своим столом в офисе и непосредственно посреди списка функциональных требований слышу как меня просят повернуться. Эх, думаю, как я щас повернусь! Вот никак нельзя обойтись без вопросов?! Поворачиваюсь в благородном негодовании весьма занятого человека 🙈
Оказалось, за моей спиной выстроились все парни нашей команды, чтобы меня одну поздравить заранее и я не осталась без праздника! Уже не могу вспомнить сколько именно ребят было в тот момент. Теперь кажется, что их было ровно 33 ИТ-богатыря☺️
8е марта в том году был для меня очень рабочим, зато потом я отвела душу в прогулке по дворцам и паркам Людвигсбурга. Никогда бы не подумала, что и фото пригодятся.
Девушки, сказочного вам настроения, прекрасных цветов, тепла и внимания!💐
#мысливслух #истории
В те далекие времена, когда я работала в заказной разработке, было принято отправлять аналитиков в командировки. Чаще, чтобы изучить заказчика в его собственном офисе, а иногда — познакомиться с сильно распределенной частью команды. Оказаться на проекте с перспективой интересных командировок считалось хорошим опытом.
Однажды, как раз накануне 8го марта, я должна была отправиться в края, где этот день не был выходным. Все предвещало хороший, но непраздничный опыт.
В день перед отъездом сижу за своим столом в офисе и непосредственно посреди списка функциональных требований слышу как меня просят повернуться. Эх, думаю, как я щас повернусь! Вот никак нельзя обойтись без вопросов?! Поворачиваюсь в благородном негодовании весьма занятого человека 🙈
Оказалось, за моей спиной выстроились все парни нашей команды, чтобы меня одну поздравить заранее и я не осталась без праздника! Уже не могу вспомнить сколько именно ребят было в тот момент. Теперь кажется, что их было ровно 33 ИТ-богатыря
8е марта в том году был для меня очень рабочим, зато потом я отвела душу в прогулке по дворцам и паркам Людвигсбурга. Никогда бы не подумала, что и фото пригодятся.
Девушки, сказочного вам настроения, прекрасных цветов, тепла и внимания!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🥰2👍1🔥1😍1
Мозговой штурм (brainstorm) работает или нет?
#что_почитать #мысливслух
Подход мозговых штурмов давно вошел в моду и так же давно под сомнением. Поделюсь статьями с разными точками зрения и своим опытом.
Мозговой штурм возник еще в 1940-х как способ поиска новых идей и решений через генерацию их в группе людей. BABOK выделяет его как одну из техник выявления требований. Список этих техник можно найти в посте тут.
В моем опыте brainstorm выручает, когда нужно собрать точки зрения на будущее решение от разных экспертов в команде. Бывает важно создать у каждого участника понимание причастности к решению, чтобы при реализации не было ощущения работы над чем-то навязанным аналитиком. Очень здорово, когда удается создать атмосферу доверия и общего движения к поиску решения. Это вдохновляет и мне такое нравится. Правда, вопросы все равно могут оставаться. Если вариантов несколько, то кто-то может топить за альтернативный и остаться недовольным выбором, но в любом случае будет проще двигаться дальше, когда у всех участников разработки есть понимание инструментов принятия решений.
Плохо, когда вместо общего творчества встреча превращается в сцену для самопрезентации отдельных участников. Обычно эти участники и без того являются лидерами мнений или претендуют на такую роль, каждая встреча для них — площадка для выступления и демонстрации своего авторитета и экспертности. Как раз это явление скептики и называют среди причин провала мозгового штурма. Кто-то ленится высказать свое мнение, оставляя возможность говорить другим, кто-то просто не успевает высказаться, кто-то боится выглядеть дураком на фоне ярких спикеров.
В статье Мозговой штурм. Почему этот метод на самом деле не работает приведено несколько экспериментов, показавших несостоятельность идеи
📍1951 по 1956 год, исследование Соломона Аша показало, что под влиянием группы люди чаще дают неверные ответы даже на очень простые вопросы
📍1963 год. Исследование Марвина Данетта привело к мысли, что самостоятельно люди с большей вероятностью предлагают те же или лучшие идеи, чем люди в группах
📍2005 год, исследование Грегори Бернса подтвердило результаты прошлого века и показало, что когда человек работает самостоятельно, у него лучше вовлечены доли мозга, отвечающие за принятие решений
А вот здесь в блоге ScrumTrek автор будто попытался дать ответ на сомнения. Говорится, что технику нужно применять как инструмент, чтобы объединить точки зрения разных экспертов, провести более глубокий анализ вопроса и чтобы организовать командную работу. Думаю, это очень похоже и на мой опыт
В статье Проблемы мозговых штурмов интересно мнение автора о проведении мозговых штурмов удаленно и его взгляд на подмеченные проблемы
Социальные свойства человека сильнее самого прекрасного инструмента мыслетворчества. Я, честно говоря, не готова идеализировать ни одну из техник выявления информации. Не помню уже, когда у меня появилась привычка результаты любой из них проверять какими-то другими. Например, решения, выбранные на встрече с командой, переложить на макет и еще раз проверить жизнеспособность через мнение той же команды и пользователей.
Как у вас с мозговыми штурмами? Если проводите, то бывает ли полезно?
#что_почитать #мысливслух
Подход мозговых штурмов давно вошел в моду и так же давно под сомнением. Поделюсь статьями с разными точками зрения и своим опытом.
Мозговой штурм возник еще в 1940-х как способ поиска новых идей и решений через генерацию их в группе людей. BABOK выделяет его как одну из техник выявления требований. Список этих техник можно найти в посте тут.
В моем опыте brainstorm выручает, когда нужно собрать точки зрения на будущее решение от разных экспертов в команде. Бывает важно создать у каждого участника понимание причастности к решению, чтобы при реализации не было ощущения работы над чем-то навязанным аналитиком. Очень здорово, когда удается создать атмосферу доверия и общего движения к поиску решения. Это вдохновляет и мне такое нравится. Правда, вопросы все равно могут оставаться. Если вариантов несколько, то кто-то может топить за альтернативный и остаться недовольным выбором, но в любом случае будет проще двигаться дальше, когда у всех участников разработки есть понимание инструментов принятия решений.
Плохо, когда вместо общего творчества встреча превращается в сцену для самопрезентации отдельных участников. Обычно эти участники и без того являются лидерами мнений или претендуют на такую роль, каждая встреча для них — площадка для выступления и демонстрации своего авторитета и экспертности. Как раз это явление скептики и называют среди причин провала мозгового штурма. Кто-то ленится высказать свое мнение, оставляя возможность говорить другим, кто-то просто не успевает высказаться, кто-то боится выглядеть дураком на фоне ярких спикеров.
В статье Мозговой штурм. Почему этот метод на самом деле не работает приведено несколько экспериментов, показавших несостоятельность идеи
📍1951 по 1956 год, исследование Соломона Аша показало, что под влиянием группы люди чаще дают неверные ответы даже на очень простые вопросы
📍1963 год. Исследование Марвина Данетта привело к мысли, что самостоятельно люди с большей вероятностью предлагают те же или лучшие идеи, чем люди в группах
📍2005 год, исследование Грегори Бернса подтвердило результаты прошлого века и показало, что когда человек работает самостоятельно, у него лучше вовлечены доли мозга, отвечающие за принятие решений
А вот здесь в блоге ScrumTrek автор будто попытался дать ответ на сомнения. Говорится, что технику нужно применять как инструмент, чтобы объединить точки зрения разных экспертов, провести более глубокий анализ вопроса и чтобы организовать командную работу. Думаю, это очень похоже и на мой опыт
В статье Проблемы мозговых штурмов интересно мнение автора о проведении мозговых штурмов удаленно и его взгляд на подмеченные проблемы
Социальные свойства человека сильнее самого прекрасного инструмента мыслетворчества. Я, честно говоря, не готова идеализировать ни одну из техник выявления информации. Не помню уже, когда у меня появилась привычка результаты любой из них проверять какими-то другими. Например, решения, выбранные на встрече с командой, переложить на макет и еще раз проверить жизнеспособность через мнение той же команды и пользователей.
Как у вас с мозговыми штурмами? Если проводите, то бывает ли полезно?