Как работается БА на удаленке и гибриде?
#мысливслух
Не перестаю радоваться возможности удаленки. Заболела на прошлой неделе. Борьба с вирусом — утомительное занятие, но пока голова работает можно и потрудиться.
Про гибрид. Работаю в гибридном формате, два дня провожу в офисе. В моем случае это удачный вариант. Получается использовать офисное время, чтобы
• подогреть отношения с заинтересованными сторонами и командой всеми техниками вербального общения, которые недоступны удаленно
• получить информацию для анализа уже вне офиса
• надеть что-то офисное, чтобы не слишком запылилось в шкафу
• сделать за день адекватное количество шагов, при этом без каких-то отдельных усилий
Есть нюансы.
📍Мои заинтересованные стороны всю рабочую неделю в офисе, а команде удалось выбрать день недели, когда приезжают 90% участников. Когда таких договоренностей нет, то приезд в офис выглядит какой-то формальностью. Приехал и сидишь в пустом офисе на видеосвязи с остальными. Полезно только офисным кафешкам, у них хоть кто-то купит кофе ☕️
📍На производительность труда и на качество сна могут сильно влиять качели между «уфф, завтра я из дома» и «так, завтра в офис». Нужны те же правила, что и при работе на полной удаленке: одежда и стол для работы, избегать работы на диване, не забывать о физических упражнениях и пр. Эти правила при гибриде нужны даже больше, потому что есть большой соблазн пожалеть себя после суетливого офисного дня😺
📍Обнаружилось забавное явление. Людям все-таки важно общение. Не у всех вне офиса его достаточно, чтобы закрыть все социальные потребности. Кто-то устает быть круглые сутки с детьми или тещей….Коллеги, которые могут пообщаться очно только в наш командно-офисный день, проводят этот день в общении больше, чем в работе. Нужно обсудить разные корпоративные события, выпить кофе вместе, решить пару вопросов с заказчиками и...ух, сколько еще всего! Бывает, что мечтаешь попасть уже домой и спокойно поработать☺️
Удаленка. Был опыт полной удаленки и не только в ковидные времена. От знакомых приходилось слышать вопросы: «Ты же БА! Как же ты будешь проводить интервью онлайн?!» Это оказалось как раз не самым важным. Про интервью на удаленке я писала тут
В полной удаленке для БА особенно важно, чтобы в компании существовала культура 100% удаленки. То есть вся команда удаленно, заказчики тоже выходят на связь удаленно. Чтобы не происходило разделение на «тех кто с нами» и «кто на удаленке». БА лишается возможности работать с информацией, когда все собрались в переговорке, но не сочли нужным подключить БА или подключили из переговорки и не позаботились о качестве связи (а зачем для одного человека?). Так теряется большая часть исследовательской работы.
В соседнем канале Шерлок в IT статья об ожиданиях и реальности удаленной работы.
#мысливслух
Не перестаю радоваться возможности удаленки. Заболела на прошлой неделе. Борьба с вирусом — утомительное занятие, но пока голова работает можно и потрудиться.
Про гибрид. Работаю в гибридном формате, два дня провожу в офисе. В моем случае это удачный вариант. Получается использовать офисное время, чтобы
• подогреть отношения с заинтересованными сторонами и командой всеми техниками вербального общения, которые недоступны удаленно
• получить информацию для анализа уже вне офиса
• надеть что-то офисное, чтобы не слишком запылилось в шкафу
• сделать за день адекватное количество шагов, при этом без каких-то отдельных усилий
Есть нюансы.
📍Мои заинтересованные стороны всю рабочую неделю в офисе, а команде удалось выбрать день недели, когда приезжают 90% участников. Когда таких договоренностей нет, то приезд в офис выглядит какой-то формальностью. Приехал и сидишь в пустом офисе на видеосвязи с остальными. Полезно только офисным кафешкам, у них хоть кто-то купит кофе ☕️
📍На производительность труда и на качество сна могут сильно влиять качели между «уфф, завтра я из дома» и «так, завтра в офис». Нужны те же правила, что и при работе на полной удаленке: одежда и стол для работы, избегать работы на диване, не забывать о физических упражнениях и пр. Эти правила при гибриде нужны даже больше, потому что есть большой соблазн пожалеть себя после суетливого офисного дня
📍Обнаружилось забавное явление. Людям все-таки важно общение. Не у всех вне офиса его достаточно, чтобы закрыть все социальные потребности. Кто-то устает быть круглые сутки с детьми или тещей….Коллеги, которые могут пообщаться очно только в наш командно-офисный день, проводят этот день в общении больше, чем в работе. Нужно обсудить разные корпоративные события, выпить кофе вместе, решить пару вопросов с заказчиками и...ух, сколько еще всего! Бывает, что мечтаешь попасть уже домой и спокойно поработать
Удаленка. Был опыт полной удаленки и не только в ковидные времена. От знакомых приходилось слышать вопросы: «Ты же БА! Как же ты будешь проводить интервью онлайн?!» Это оказалось как раз не самым важным. Про интервью на удаленке я писала тут
В полной удаленке для БА особенно важно, чтобы в компании существовала культура 100% удаленки. То есть вся команда удаленно, заказчики тоже выходят на связь удаленно. Чтобы не происходило разделение на «тех кто с нами» и «кто на удаленке». БА лишается возможности работать с информацией, когда все собрались в переговорке, но не сочли нужным подключить БА или подключили из переговорки и не позаботились о качестве связи (а зачем для одного человека?). Так теряется большая часть исследовательской работы.
В соседнем канале Шерлок в IT статья об ожиданиях и реальности удаленной работы.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍1
Как аналитику избежать когнитивных искажений?
#мысливслух #что_почитать
Сразу отвечу на вопрос в заголовке. Когнитивных искажений не избежать — это свойство человеческого мозга действует на всех. Аналитику важно об этом свойстве помнить и не считать, что какой-то особый амулет полностью гарантирует от искажений в восприятии информации. Есть только хорошие приемы в работе, которые помогают снизить риск ошибки. Грубо говоря, больше шансов компенсировать искажения, если
▫️удается задать себе вопрос: «Не ерунду ли я придумал?»,
▫️есть время построить свое решение через моделирование данных, процессов и интерфейсов на разных уровнях,
▫️получается рассмотреть решение с точек зрения разных заинтересованных сторон.
Со времени появления в 1972 году понятия «когнитивное искажение» их сформулированы уже сотни видов. Когда смотришь на список когнитивных искажений, то вольно или невольно для каждого находишь примеры из собственной жизни. Из того, что я часто встречаю в работе, я выделила такие топ-3 проявления искажений
📌Это же важный дефект/фича/задача! Я недавно попала в забавную ситуацию, когда начала горячо доказывать, что на экране нашего внутрикорпоративного приложения иконка "Поиск" дублирует кнопку "Поиск" и это важно исправить. Опомнилась, когда коллега сказал: "Это здесь уже месяц, кто-то заметил до сегодняшнего дня?"
Не менее семи искажений приводят к переоценке вероятности и значимости частных случаев. Например, эффект фокусировки, когда человек переоценивает важность одного фактора и теряет из виду другие, не менее важные. Приходилось вам обсуждать важность сложных синтетических кейсов, которые пришли в голову кому-то из команды?
📃Помогает немного выдохнуть и оглядеться: "На какое количество пользователей влияет проблема?", "Почему это вообще проблема?", "Кто и при каких обстоятельствах сталкивался с этим в последнее время?" Ленивый мозг и эту информацию может переиначить, лишь бы подтвердить наше ошибочное мнение. Поэтому одного приема недостаточно. Еще можно проверить свое мнение "об других людей". В моем примере с иконкой "Поиск" можно показать экран случайным коллегам и спросить как бы они выполнили поиск.
📌Так будет удобнее пользователям, я же знаю! Участникам многих ИТ-команд, очень свойственно свой опыт работы в системах приравнивать опыту своих пользователей: бухгалтеров, менеджеров, операционистов... Что выглядит странным для ИТ-аналитика, может оказаться вполне адекватным для пользователей, которые годами пользуются этим странным. Нам свойственно характеристики одной группы людей переносить на другие группы, а еще и переоценивать значимость собственного мнения. На это работает не меньше десятка известных искажений.
📃Здесь очень выручают прототипы, хотя бы бумажные. О прототипах есть статья в этом канале
📌Заказчик именно этого хочет! Ух как бывает сложно, когда искажения в решениях заказчика встречаются с искажениями в оценке этих решений аналитиками! Результат известен – неиспользуемые фичи и приложения в вечном занудном развитии, в попытках заплатками прикрыть ошибки в концепции. Даже вспоминать больно🤕
📃Важно мнения всех сторон проверять через интервью, наблюдения, анализ действующих процессов и моделирование ожидаемых процессов и сценариев.
Чем бы вы дополнили этот мой список влияния искажений? Будет интересно, если поделитесь в комментариях своими наблюдениями.
Что почитать и посмотреть:
🗞Статья про ловушки сознания (Хабр)
🗞Статья Как бизнес-аналитику преодолеть групповое мышление? (Дзен)
🗞Статья Темная сторона исследований пользователей: как когнитивные искажения портят результаты (Хабр)
🎥Доклад с ProductCamp 2018 Когнитивные искажения в работе аналитика и продакта (YouTube)
🎥Доклад на Analyst Days – 17 Debugging головного мозга или гон тараканов (YouTube)
#мысливслух #что_почитать
Сразу отвечу на вопрос в заголовке. Когнитивных искажений не избежать — это свойство человеческого мозга действует на всех. Аналитику важно об этом свойстве помнить и не считать, что какой-то особый амулет полностью гарантирует от искажений в восприятии информации. Есть только хорошие приемы в работе, которые помогают снизить риск ошибки. Грубо говоря, больше шансов компенсировать искажения, если
▫️удается задать себе вопрос: «Не ерунду ли я придумал?»,
▫️есть время построить свое решение через моделирование данных, процессов и интерфейсов на разных уровнях,
▫️получается рассмотреть решение с точек зрения разных заинтересованных сторон.
Со времени появления в 1972 году понятия «когнитивное искажение» их сформулированы уже сотни видов. Когда смотришь на список когнитивных искажений, то вольно или невольно для каждого находишь примеры из собственной жизни. Из того, что я часто встречаю в работе, я выделила такие топ-3 проявления искажений
📌Это же важный дефект/фича/задача! Я недавно попала в забавную ситуацию, когда начала горячо доказывать, что на экране нашего внутрикорпоративного приложения иконка "Поиск" дублирует кнопку "Поиск" и это важно исправить. Опомнилась, когда коллега сказал: "Это здесь уже месяц, кто-то заметил до сегодняшнего дня?"
Не менее семи искажений приводят к переоценке вероятности и значимости частных случаев. Например, эффект фокусировки, когда человек переоценивает важность одного фактора и теряет из виду другие, не менее важные. Приходилось вам обсуждать важность сложных синтетических кейсов, которые пришли в голову кому-то из команды?
📃Помогает немного выдохнуть и оглядеться: "На какое количество пользователей влияет проблема?", "Почему это вообще проблема?", "Кто и при каких обстоятельствах сталкивался с этим в последнее время?" Ленивый мозг и эту информацию может переиначить, лишь бы подтвердить наше ошибочное мнение. Поэтому одного приема недостаточно. Еще можно проверить свое мнение "об других людей". В моем примере с иконкой "Поиск" можно показать экран случайным коллегам и спросить как бы они выполнили поиск.
📌Так будет удобнее пользователям, я же знаю! Участникам многих ИТ-команд, очень свойственно свой опыт работы в системах приравнивать опыту своих пользователей: бухгалтеров, менеджеров, операционистов... Что выглядит странным для ИТ-аналитика, может оказаться вполне адекватным для пользователей, которые годами пользуются этим странным. Нам свойственно характеристики одной группы людей переносить на другие группы, а еще и переоценивать значимость собственного мнения. На это работает не меньше десятка известных искажений.
📃Здесь очень выручают прототипы, хотя бы бумажные. О прототипах есть статья в этом канале
📌Заказчик именно этого хочет! Ух как бывает сложно, когда искажения в решениях заказчика встречаются с искажениями в оценке этих решений аналитиками! Результат известен – неиспользуемые фичи и приложения в вечном занудном развитии, в попытках заплатками прикрыть ошибки в концепции. Даже вспоминать больно
📃Важно мнения всех сторон проверять через интервью, наблюдения, анализ действующих процессов и моделирование ожидаемых процессов и сценариев.
Чем бы вы дополнили этот мой список влияния искажений? Будет интересно, если поделитесь в комментариях своими наблюдениями.
Что почитать и посмотреть:
🗞Статья про ловушки сознания (Хабр)
🗞Статья Как бизнес-аналитику преодолеть групповое мышление? (Дзен)
🗞Статья Темная сторона исследований пользователей: как когнитивные искажения портят результаты (Хабр)
🎥Доклад с ProductCamp 2018 Когнитивные искажения в работе аналитика и продакта (YouTube)
🎥Доклад на Analyst Days – 17 Debugging головного мозга или гон тараканов (YouTube)
Please open Telegram to view this post
VIEW IN TELEGRAM
🤩4❤2
Кейс.Подготовка к интервью
#кейс #интервью
На этой неделе снова готовилась к интервью с пользователями. Обычно составляю для себя примерный список вопросов. Пока работала над списком и возникла идея предложить небольшой кейс по составлению вопросов к интервью. Сценарий и варианты вопросов ниже, какие из них вы бы взяли с собой на интервью? Своим мнением поделюсь в комментариях в понедельник.
#кейс #интервью
На этой неделе снова готовилась к интервью с пользователями. Обычно составляю для себя примерный список вопросов. Пока работала над списком и возникла идея предложить небольшой кейс по составлению вопросов к интервью. Сценарий и варианты вопросов ниже, какие из них вы бы взяли с собой на интервью? Своим мнением поделюсь в комментариях в понедельник.
👍2
Нужно уточнить требования к функции выгрузки файла с отчетом. Это управленческий отчет для руководителей вашей компании, содержит данные о выполнении плана сотрудниками.
Какие из этих вопросов вы бы включили в список для интервью с бизнес-заказчиком?
Какие из этих вопросов вы бы включили в список для интервью с бизнес-заказчиком?
Anonymous Poll
70%
Каким ролям должен быть доступен отчет?
19%
Какой из сервисов должен формировать файл?
31%
Каким должно быть название файла с отчетом?
69%
Как файл с отчетом будет использоваться после выгрузки?
13%
Как этот очет повлияет на доход сотрудников?
83%
Как вы сейчас получаете подобный отчет?
20%
Формат файла должен быть pdf, верно?
65%
На каком шаге процесса продаж должен быть доступен файл с отчетом?
78%
Отчет за какой период должен содержаться в файле?
9%
Предложу свой вопрос в комментарии
Подборка про пользовательский опыт
#что_почитать
📍Адаптивное интервью пользователей В пятницу, пока мы здесь решали кейс, команда конференции 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