Новая статья: Разработка и пользователи: по одну сторону баррикад
#1
Отправлено 21 мая 2009 - 10:59
Читайте в нашей библиотеке новую статью Натальи Руколь "Разработка и пользователи: по одну сторону баррикад", в которой рассказывается о том, что такое ментальная модель пользователя и для чего она нужна.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#2
Отправлено 21 мая 2009 - 13:09
#3
Отправлено 21 мая 2009 - 15:05
По статье:
А зачем такой никому ненужный функционал разрабатывать?регулярно тестировать функционал, который никому не нужен, не просто неэффективно, но и по-человечески обидно тратить на это своё время
Стоило упомянуть, когда эту ментальную модель надо разрабатывать.
#4
Отправлено 22 мая 2009 - 08:30
Вы либо крестик снимите, либо трусы наденьте.
И логично, как заметили коллеги, что влияние ДОЛЖНО оказываться в первую очередь на проектирование и конструирование. Тестирование там в конце очереди.
И еще. Еще раз рекомендую книгу "Психбольница в руках пациентов". Настойчиво.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#5
Отправлено 22 мая 2009 - 09:47
Даже если люди работают по водопаду мало что мешает использовать методики из гибких методологий(заказчик рядом, небольшие итерации).
А статья еще 1 велосипед придуманный заново на мой взгляд. Максимально быстро построенный feedback от заказчика(пользователя), либо тесная коммуникация с ним(доступ к трекеру задач в конце концов) всегда являлось хорошей методикой. Опять же если говорить о тестировании, то хорошим решением проблемы является Context driven testing не в пустой голове QM.
P.S. Извиняюсь за слово велосипед :) Как то грубо получилось кажется
#6
Отправлено 22 мая 2009 - 10:01
Методологии здесь не при чем. Допустим, вы разрабатываете ПО для новой модели мобильника...Максимально быстро построенный feedback от заказчика(пользователя), либо тесная коммуникация с ним(доступ к трекеру задач в конце концов) всегда являлось хорошей методикой.
Даже если есть заказчик, откуда ему знать про нужды конечного пользователя. Психбольницу выше не зря рекомендуют почитать.
#7
Отправлено 22 мая 2009 - 10:03
Более половины проектов делаются по водопаду.Я или уже гоню или тут все работают по водопаду?
Даже если люди работают по водопаду мало что мешает использовать методики из гибких методологий(заказчик рядом, небольшие итерации).
Кроме того короткие итерации будучи скрещенными с водопадом дают вполне жизнеспособные гибриды. Есть вещи, которые выбираются один раз. Это:
* Платформа реализации
* Крупноблочная архитектура (клиент-сервер/ трехзвенка/ ...)
* Для чего делается проект
* ... и много еще чего
ментальные карты - очень неплохой артефакт. И и лучше его делать перед первой поставкой. Один раз. Просто IMHO они делаются не совсем так, как описано в статье. Есть повод для дискуссии.
Иногда да, иногда нет. Довольно часто это ведет к краху проекта.Максимально быстро построенный feedback от заказчика(пользователя), либо тесная коммуникация с ним(доступ к трекеру задач в конце концов) всегда являлось хорошей методикой.
--
Есть искушение при построение логистической системы организовать тесный контакт с пользователями системы. Делать под них интерфейс, планировать фичи в релиз исходя из их пожеланий и т.д. С неизбежностью это приведет к созданию не логистической но учетной системы. И естественно принесет бизнесу кучу убытков.
Для систем бизнес-класса интересы пользователя вторичны. А первичны интересы владельца бизнеса. Который совсем не обязательно является пользователем системы.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#8
Отправлено 22 мая 2009 - 11:31
Вопрос хороший. Но зачастую болезненный для многих участников процесса :) Особенно когда речь идёт о тиражном продукте, который много версий подряд содержал оговоренный функционал.А зачем такой никому ненужный функционал разрабатывать?
В статье я рассматриваю работу с ММ исключительно со стороны тестирования. Зачастую QC любит обвинять во всём проектирование и разработку, однако начать улучшения можно и с себя. Подтверждено - работает ;)
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#9
Отправлено 22 мая 2009 - 11:38
Если мы не говорим об откатных схемах, то чаще всего это не так. Потому что enterprise-решения призваны автоматизировать какие-либо процессы, т.е. оптимизировать временные затраты пользователей.Для систем бизнес-класса интересы пользователя вторичны. А первичны интересы владельца бизнеса. Который совсем не обязательно является пользователем системы.
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#10
Отправлено 22 мая 2009 - 12:02
Тогда ещё вопросы. У тестировщиков своя ММ, у разраработчиков своя ММ, не знаю кто там ещё, допустим у заказчика тоже своя модель. Пусть тестировщик локально в своем процессе получает какие-то бенефиты от ММ, а в целом-то все в проигрыше? И чья в таком случае ММ будет правильной? Разъясните. (вообще я в курсе как бы как оно должно быть, но это мне не кажется ясным из статьи и ваших комментариев)В статье я рассматриваю работу с ММ исключительно со стороны тестирования. Зачастую QC любит обвинять во всём проектирование и разработку, однако начать улучшения можно и с себя. Подтверждено - работает ;)
#11
Отправлено 22 мая 2009 - 12:14
Очень распространенное заблуждение. И одновременно одна из ключевых причин провала проектов по внедрению enterprise-решений. Зря вы вчера на поинтовку не пришли. Там эти вещи разбирались.Если мы не говорим об откатных схемах, то чаще всего это не так. Потому что enterprise-решения призваны автоматизировать какие-либо процессы, т.е. оптимизировать временные затраты пользователей.Для систем бизнес-класса интересы пользователя вторичны. А первичны интересы владельца бизнеса. Который совсем не обязательно является пользователем системы.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#12
Отправлено 22 мая 2009 - 13:09
Нууу мне все таки кажется мы рассматриваем тестирование ПО. Если же вы разрабатываете для пользователей, но заказчик не из них, то есть и вариант альфа-бета тестирования, коим пользуются многие. Кроме этого заказчика в любом случае надо ставить в известность и давать какие то права на выбор тех или иных решений.Методологии здесь не при чем. Допустим, вы разрабатываете ПО для новой модели мобильника...
Даже если есть заказчик, откуда ему знать про нужды конечного пользователя. Психбольницу выше не зря рекомендуют почитать.
Кроме этого при разработке нового мобильника вы при должном финансировании сделаете социалогический опрос как минимум :)
Крах проекта все равно происходит не по вине пользователей - это логично по крайней мере :) .SALar
#13
Отправлено 22 мая 2009 - 14:43
А чем ПО в мобильнике не ПО. Ну давайте возьмем для конкретики iPhone. Я, конечно, не знаю, как там все было на самом деле, но сильно сомневаюсь по поводу альфа-бета и соц. опросов. (например, они не сделали ММС и видеосъемку. А в модели 3G нету фронтальной камеры и т.д.). Весь этот фидбэк - довольно субъективен и не дает конкретного ответа на вопрос какой продукт в итоге надо сделать. А соц опрос это вообще что-то непонятное - кого опрашивать - яппи, студентов или чотких пацанов которые будут эти айфоны отжимать? По поводу заказчиков - очень часто бывает, что разработчик сам же и является заказчиком.Clauster
Нууу мне все таки кажется мы рассматриваем тестирование ПО. Если же вы разрабатываете для пользователей, но заказчик не из них, то есть и вариант альфа-бета тестирования, коим пользуются многие. Кроме этого заказчика в любом случае надо ставить в известность и давать какие то права на выбор тех или иных решений.Методологии здесь не при чем. Допустим, вы разрабатываете ПО для новой модели мобильника...
Даже если есть заказчик, откуда ему знать про нужды конечного пользователя. Психбольницу выше не зря рекомендуют почитать.
Кроме этого при разработке нового мобильника вы при должном финансировании сделаете социалогический опрос как минимум :)
Введение персонажей позволяет разрабатывать продукт под конкретного персонажа (не собирательного образа пользователя) и можно уже в самом начале довольно ясно представлять как будет выглядеть конечный продукт.
#14
Отправлено 22 мая 2009 - 17:35
Давайте без сферических коней в вакууме, обсуждений ради обсуждений :)Очень распространенное заблуждение. И одновременно одна из ключевых причин провала проектов по внедрению enterprise-решений. Зря вы вчера на поинтовку не пришли. Там эти вещи разбирались.
Приведите конкретные примеры из своего опыта? У меня опыт исключительно обратный, как со стороны релиза так и со стороны закупок enterprise-софта.
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#15
Отправлено 22 мая 2009 - 17:40
Вы прекрасно понимаете, что ММ у всех участников процесса должна быть одна :) И если Вы работаете в компании, где зрелые процессы и проработка модели делается совместо фичегруппой до начала разработки и актуализируется в процессе - то Вам моя статья не поможет т.к. просто не нужна :)Тогда ещё вопросы. У тестировщиков своя ММ, у разраработчиков своя ММ, не знаю кто там ещё, допустим у заказчика тоже своя модель. Пусть тестировщик локально в своем процессе получает какие-то бенефиты от ММ, а в целом-то все в проигрыше? И чья в таком случае ММ будет правильной? Разъясните. (вообще я в курсе как бы как оно должно быть, но это мне не кажется ясным из статьи и ваших комментариев)
Если же на фирме этого нет, то поменять это одномоментно и для всех участников малореально. И именно тогда Вы можете начать с себя :)
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#16
Отправлено 23 мая 2009 - 07:58
Вот в этом и вопрос, если у тестировщика своя вселенная, а у остальных другая, в чем выгода и как понять, что тестировщик не ошибается в выборе ММ, с учетом того, чтоВы прекрасно понимаете, что ММ у всех участников процесса должна быть одна :) И если Вы работаете в компании, где зрелые процессы и проработка модели делается совместо фичегруппой до начала разработки и актуализируется в процессе - то Вам моя статья не поможет т.к. просто не нужна :)Тогда ещё вопросы. У тестировщиков своя ММ, у разраработчиков своя ММ, не знаю кто там ещё, допустим у заказчика тоже своя модель. Пусть тестировщик локально в своем процессе получает какие-то бенефиты от ММ, а в целом-то все в проигрыше? И чья в таком случае ММ будет правильной? Разъясните. (вообще я в курсе как бы как оно должно быть, но это мне не кажется ясным из статьи и ваших комментариев)
Если же на фирме этого нет, то поменять это одномоментно и для всех участников малореально. И именно тогда Вы можете начать с себя :)
Другими словами я не думаю, что начав с себя, сформировав ММ и работая с ней принесет какие-то бенефиты. Да, тестировщику станет легче, но выиграет ли от этого проект в целом - большой вопрос, шансы, имхо, примерно 50\50.Ответы на эти три, казалось бы, элементарных вопроса, получить не так-то просто, потому что:
* Для получения такой информации, Вам нужна репрезентативная выборка – что отнюдь непросто
* Для получения правильных ответов, Вам нужны правильные вопросы. Пользователь и сам не знает, что и как он использует.
#17
Отправлено 23 мая 2009 - 11:38
Мне не удалось найти в статье упоминаний о том, что модель должна быть _общая_, и что модель, вообще-то, не одна - для большинства программных продуктов нельзя сформировать "средний профиль пользователя".Вы прекрасно понимаете, что ММ у всех участников процесса должна быть одна :) И если Вы работаете в компании, где зрелые процессы и проработка модели делается совместо фичегруппой до начала разработки и актуализируется в процессе - то Вам моя статья не поможет т.к. просто не нужна :)
Если же на фирме этого нет, то поменять это одномоментно и для всех участников малореально. И именно тогда Вы можете начать с себя :)
Допустим, известно, что каждый участник разработки обязательно использует какую-то модель пользователя, даже если об этом не говорится явно. И в большинстве случаев эти модели различаются. Что происходит, когда тестировщик читает такое наставление "начать с себя"? Ага, он решает, что у него уже есть хорошая модель пользователя, или он сейчас создаст самую лучшую - для себя, потому что все остальные "не понимают и не хотят". И идет дальше по списку - меняет приоритеты багов, игнорирует области продукта, которые в его модели выглядят малозначимыми, и тд и тп. В это время остальная команда, мягко говоря, недоумевает от подобного подхода. Приведет ли такое "пробование" к хорошему результату?
Не думаю, что подавать User-Centered или Task-Centered Design в таком оригинальном представлении очень полезно.
#18
Отправлено 24 мая 2009 - 16:47
Но можно улучшить на основе реальных данных, т.е. из первоисточника (Пользователя).
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#19
Отправлено 25 мая 2009 - 06:55
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#20
Отправлено 25 мая 2009 - 06:57
ПО в мобильнике тоже ПО естественно. Я кажется пропустил слово ПО в посте :) извиняюсьА чем ПО в мобильнике не ПО. Ну давайте возьмем для конкретики iPhone. Я, конечно, не знаю, как там все было на самом деле, но сильно сомневаюсь по поводу альфа-бета и соц. опросов. (например, они не сделали ММС и видеосъемку. А в модели 3G нету фронтальной камеры и т.д.). Весь этот фидбэк - довольно субъективен и не дает конкретного ответа на вопрос какой продукт в итоге надо сделать. А соц опрос это вообще что-то непонятное - кого опрашивать - яппи, студентов или чотких пацанов которые будут эти айфоны отжимать? По поводу заказчиков - очень часто бывает, что разработчик сам же и является заказчиком.
Введение персонажей позволяет разрабатывать продукт под конкретного персонажа (не собирательного образа пользователя) и можно уже в самом начале довольно ясно представлять как будет выглядеть конечный продукт.
Ну давайте вашим примером: Iphone не могли создать вот тупо просто сделаем как хотим. Соц опрос присутствовал в любом случае. Альфа бета можно сказать присутствовала, хоть и не в общепринятом виде. Ведь все таки прошивки на IPhone обновляются как не крути(если я не ошибаюсь то у них уже 3-версия прошивки на данный момент), значит фидбэк обрабатывается. Зря вы так оцениваете соц опросы - это тоже целое искусство и снижение рисков при нем имеется.
Когда заказчиком является сам программист, то еще лучше. Он сделает продукт именно таким каким он хочет его видеть.
Но давайте разделять понятия так, что заказчик это тот, кто платит.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных