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