Тут сложно делить по ролям, т.к. в каждой компании РМ и РО вечно разные задачи выполняют :) Расскажу с точки зрения задач. Если говорить про управление распределённой командой, то разницы никакой. А вот если говорить про сбор требований с заказчика, то, конечно, к нему (заказчику) должен быть доступ.
В нашей компании есть только один свой собственный продукт и соответственно только один РО. Продукт не заказной, пользователей сейчас уже тысячи, к каждому всё равно не поедешь — общение идёт в почтах, форумах, скайпах, телеграмах и прочем.
Некоторые проекты, с которыми мы работаем — заказные, но РО не с нашей стороны. РО часто ездит к заказчику (1-2 раза в неделю, перед сдачей этапов почти каждый день). Но команды всё равно распределённые, так что основная его часть работы с командой всё равно в тех же мессенджерах.
+ У нас есть проекты по тестированию достаточно большие, где у заказчика есть офис и вся их команда сидит в одном месте. Тогда наш лид ездит к клиенту 1-2-3 раза в неделю, а по началу почти всё время работал там. Так мы решаем проблему, чтобы наша команда не потерялась, не оторвалась от общего процесса.
Вообще-то самое главное — это знание и понимание целей пользователя, которые он преследует, используя продукт, и бизнеса, который разработкой продукта хочет достигнуть своих целей.
Да, конечно!!! Именно поэтому владелец магазина и по совместительству главбух и гендир всегда сможет разработать CRM, бух.программу и кассовое приложение значительно «юзабельнее» всяких там проектировщиков!
Видела я результаты такого народного творчества. Так же можно сказать, что у вас «самое главное» — сердце, так что забейте на почки с печенью.
Юзаби́лити, удобство использования (англ. usability — дословно «возможность использования», «способность быть использованным», «полезность»). тут в основном все делают ПО. Для него интерфейс взаимодействия с пользователем — это GUI. Так что тестируется удобство использования (юзабилити) GUI.
ОК. Я разрабатываю новый текстовый редактор. Дизайна понятнее и нагляднее свет не видел! Но это редактор не поддерживает форматы doc, docx, rtf. Как вы думаете, у этого продукта высокое юзабилити? :)
1. Продаж меньше не станет, прямой убыток никто не заметит. Просто поверьте, я уже объясняла заказчику выгоды от автоматизации процедуры, которая занимает 10 минут в день каждым из 4 тысяч сотрудников компании, и показывала в цифрах окупаемость доработки меньше чем за месяц. Это не всегда работает, далеко не с любым заказчиком :)
2. Как-то не хочется голословного обсуждения. По разным решениям реализации мы обычно засекаем скорость выполнения, скорость обучения, % ошибок, затраты методами Хика и Фитса. Пока что я не сталкивалась с равноценными вариантами реализации, но и утверждать, что это невозможно, тоже не буду.
Что-то мне кажется, что разговор не клеится :))) Попробую объяснить с примером:
Заказчик — розничная сеть продуктов питания. Задачи заказчика: товар не теряется, остатки наглядно видны, кассиры могут пользоваться продуктом. Эту задачу, действительно, можно решить сотней путей.
Но теперь давайте посмотрим глазами пользователей, а не заказчиков. Кассиры чаще всего не очень квалифицированный персонал, и им сложно изучать новое ПО. Если артикулы написаны слишком мелко, они их могут не видеть и придётся делать дополнительные телодвижения. Если нельзя удобно пробить 10 одинаковых товаров сразу, они будут тратить время на сканикорвание каждого. Если нельзя просто отменить неподходящую покупку, им будет неловко перед застрявшим в очереди покупателем.
С высоты полёта заказчика эти секунды ничего не стоят, ошибки кассиров скорее всего спишут на квалификацию кассиров, а умножить лишние затраты на реальное количество покупок в день большинство даже не додумается. А вот со стороны пользователя будет либо удовлетворение продуктом, либо недовольство.
Заказчику нужны очень высокоуровневые задачи, и юзабилити пользовательских операций в b2b софте очень редко действительно беспокоит заказчика. Поэтому, когда мы говорим про юзабилити, мы чаще всего говорим про пользователя, а функционал — про заказчика.
Ну, у меня есть ванильный опыт, когда заказчик менял подрядчика по разработке софта из-за жалоб пользователей, и после серьёзных изменений пользователи на нас молились, и заказчик тоже был счастлив. Доля «беспокойных» пользователей никогда не будет неизменной, если всерьёз браться за улучшения и не искать отмазки типа «да они всё равно будут на что-то жаловаться!».
Ну так проблему заказчика обычно можно решить сотней вариантов, и заказчику абсолютно всё равно, каким способом она будет решена. А дизайн всё-таки беспокоит конкретных пользователей продукта.
А вообще, у меня был вот такой реальный случай:
Крупный банковский софт, огромный отдел аналитиков и дизайнеров, я тестирую. Приходит новая фича (с детальным описанием требований, макапами, уже почти разработанная) — конвертация отчётов из одного формата в другой. Мне показалось очень неудобным, как всё это настраивалось, и я решила узнать подробнее, как это будет использоваться — может, проще сразу делать 2 разных формата? Прихожу к пользователям, а они говорят: «да нам вообще текущий формат не нужен, вот мы и попросили возможность конвертировать».
0_o WTF?
Почему этого не узнали аналитики?
Как они потом сказали, «ну клиент попросил, вот мы и придумали, как это сделать»… А оказалось, не нужно никакой конвертации — изначально нужен другой формат, и всё.
Как раз в вашем примеры смешались пункты 4 и 5:
* нельзя, нельзя, нельзя слушаться пользователя! Столько раз я на эти грабли наступала :( Надо выяснять его истинные потребности, а не какие кнопочки он хочет
* как только мы видим противоречие в потребностях разных пользователей — надо выделять разные версии продукта, и проектировать под разных персонажей
Спасибо тем, кто уже ответил за меня :) Действительно, я допускаю, что есть продукты, у которых только один персонаж. А вот если их несколько — надо либо делить продукт, либо предоставлять разным персонажам возможность настраивать продукт под себя.
Ну тут всегда будет вечный спор, и любые крайности плохи.
Я лично видела ребят, которые 37 signals начитались и решили делать «что-нибудь, лишь бы работало», заказчики видели сырой продукт и говорили «простите, но нам от вас ничего не надо, ни сейчас, ни когда вы ошибки исправите», в итоге люди и бренды теряли репутацию.
Идеальных продуктов не бывает, это очень хорошо Влад Головач описал в своей книге. И стремиться за недоступным идеалом — плохо. Но иногда люди, оправдываясь этим подходом, делают полную фигню, портят репутацию и пишут продукт, который потом поддерживать и развивать не получится.
Сравнительные оценки есть в таблице для разных вариантов входных данных. Примерную оценку можно получить и по ним.
Глубину больше двух, к примеру, из приведённых там утилит поддерживает PICT. Но куча исследований, приведённых на том же сайте, показывает как редко встречаются ошибки в комбинации больше чем 2-х параметро, так что дальше pairwise редко кто заходит в покрытии — просто неоправданные затраты.
В нашей компании есть только один свой собственный продукт и соответственно только один РО. Продукт не заказной, пользователей сейчас уже тысячи, к каждому всё равно не поедешь — общение идёт в почтах, форумах, скайпах, телеграмах и прочем.
Некоторые проекты, с которыми мы работаем — заказные, но РО не с нашей стороны. РО часто ездит к заказчику (1-2 раза в неделю, перед сдачей этапов почти каждый день). Но команды всё равно распределённые, так что основная его часть работы с командой всё равно в тех же мессенджерах.
+ У нас есть проекты по тестированию достаточно большие, где у заказчика есть офис и вся их команда сидит в одном месте. Тогда наш лид ездит к клиенту 1-2-3 раза в неделю, а по началу почти всё время работал там. Так мы решаем проблему, чтобы наша команда не потерялась, не оторвалась от общего процесса.
Да, конечно!!! Именно поэтому владелец магазина и по совместительству главбух и гендир всегда сможет разработать CRM, бух.программу и кассовое приложение значительно «юзабельнее» всяких там проектировщиков!
Видела я результаты такого народного творчества. Так же можно сказать, что у вас «самое главное» — сердце, так что забейте на почки с печенью.
ОК. Я разрабатываю новый текстовый редактор. Дизайна понятнее и нагляднее свет не видел! Но это редактор не поддерживает форматы doc, docx, rtf. Как вы думаете, у этого продукта высокое юзабилити? :)
2. Как-то не хочется голословного обсуждения. По разным решениям реализации мы обычно засекаем скорость выполнения, скорость обучения, % ошибок, затраты методами Хика и Фитса. Пока что я не сталкивалась с равноценными вариантами реализации, но и утверждать, что это невозможно, тоже не буду.
Заказчик — розничная сеть продуктов питания. Задачи заказчика: товар не теряется, остатки наглядно видны, кассиры могут пользоваться продуктом. Эту задачу, действительно, можно решить сотней путей.
Но теперь давайте посмотрим глазами пользователей, а не заказчиков. Кассиры чаще всего не очень квалифицированный персонал, и им сложно изучать новое ПО. Если артикулы написаны слишком мелко, они их могут не видеть и придётся делать дополнительные телодвижения. Если нельзя удобно пробить 10 одинаковых товаров сразу, они будут тратить время на сканикорвание каждого. Если нельзя просто отменить неподходящую покупку, им будет неловко перед застрявшим в очереди покупателем.
С высоты полёта заказчика эти секунды ничего не стоят, ошибки кассиров скорее всего спишут на квалификацию кассиров, а умножить лишние затраты на реальное количество покупок в день большинство даже не додумается. А вот со стороны пользователя будет либо удовлетворение продуктом, либо недовольство.
Заказчику нужны очень высокоуровневые задачи, и юзабилити пользовательских операций в b2b софте очень редко действительно беспокоит заказчика. Поэтому, когда мы говорим про юзабилити, мы чаще всего говорим про пользователя, а функционал — про заказчика.
Крупный банковский софт, огромный отдел аналитиков и дизайнеров, я тестирую. Приходит новая фича (с детальным описанием требований, макапами, уже почти разработанная) — конвертация отчётов из одного формата в другой. Мне показалось очень неудобным, как всё это настраивалось, и я решила узнать подробнее, как это будет использоваться — может, проще сразу делать 2 разных формата? Прихожу к пользователям, а они говорят: «да нам вообще текущий формат не нужен, вот мы и попросили возможность конвертировать».
0_o WTF?
Почему этого не узнали аналитики?
Как они потом сказали, «ну клиент попросил, вот мы и придумали, как это сделать»… А оказалось, не нужно никакой конвертации — изначально нужен другой формат, и всё.
* нельзя, нельзя, нельзя слушаться пользователя! Столько раз я на эти грабли наступала :( Надо выяснять его истинные потребности, а не какие кнопочки он хочет
* как только мы видим противоречие в потребностях разных пользователей — надо выделять разные версии продукта, и проектировать под разных персонажей
Я лично видела ребят, которые 37 signals начитались и решили делать «что-нибудь, лишь бы работало», заказчики видели сырой продукт и говорили «простите, но нам от вас ничего не надо, ни сейчас, ни когда вы ошибки исправите», в итоге люди и бренды теряли репутацию.
Идеальных продуктов не бывает, это очень хорошо Влад Головач описал в своей книге. И стремиться за недоступным идеалом — плохо. Но иногда люди, оправдываясь этим подходом, делают полную фигню, портят репутацию и пишут продукт, который потом поддерживать и развивать не получится.
Глубину больше двух, к примеру, из приведённых там утилит поддерживает PICT. Но куча исследований, приведённых на том же сайте, показывает как редко встречаются ошибки в комбинации больше чем 2-х параметро, так что дальше pairwise редко кто заходит в покрытии — просто неоправданные затраты.
www.software-testing.ru/library/testing/general-testing/1559-pairwise-testing-with-pict