Сообщений в теме: 25

[barancev]

И разработчики, и тестировщики часто получают удовольствие от процесса разработки программы, от использования новых технологий, современных инструментов, забывая при этом про результат -- для чего и для кого создаётся программа. Насколько важен для пользователя функционал, ради добавления галочки о котором был на 2 недели задержан релиз? Оценит ли пользователь использованную среду разработки, увеличившую размер дистрибутива в 3 раза? Использует ли пользователь пароль длиной 254 символа?

Читайте в нашей библиотеке новую статью Натальи Руколь "Разработка и пользователи: по одну сторону баррикад", в которой рассказывается о том, что такое ментальная модель пользователя и для чего она нужна.

[rlabs]

Надеюсь, в ходе формирования ментальной модели пользователя метод персон не сводится к модели сферического пользователя в вакууме.

[Clauster]

Пытался оставить комментарий под статьей, но, видимо, не судьба - то заголовок надо обязательно написать, то секретное слово неправильное, а вводить его негде.

По статье:

регулярно тестировать функционал, который никому не нужен, не просто неэффективно, но и по-человечески обидно тратить на это своё время

А зачем такой никому ненужный функционал разрабатывать?
Стоило упомянуть, когда эту ментальную модель надо разрабатывать.

[SALar]

Странно, что Наталья пропустила важнейший этап разработки ПО и сразу перешла к построению ментальной модели. Ибо при пропуске фазы построения концепции (образа продукта/...) построение ментальной модели становится бессмысленной тратой времени ибо проект уже обречен на неудачу. Если же концепция есть, то построение этой модели будет проходить несколько по другому. И бенефиты будут другие.

Вы либо крестик снимите, либо трусы наденьте.

И логично, как заметили коллеги, что влияние ДОЛЖНО оказываться в первую очередь на проектирование и конструирование. Тестирование там в конце очереди.

И еще. Еще раз рекомендую книгу "Психбольница в руках пациентов". Настойчиво.

[Sapiens]

Я или уже гоню или тут все работают по водопаду?
Даже если люди работают по водопаду мало что мешает использовать методики из гибких методологий(заказчик рядом, небольшие итерации).
А статья еще 1 велосипед придуманный заново на мой взгляд. Максимально быстро построенный feedback от заказчика(пользователя), либо тесная коммуникация с ним(доступ к трекеру задач в конце концов) всегда являлось хорошей методикой. Опять же если говорить о тестировании, то хорошим решением проблемы является Context driven testing не в пустой голове QM.
P.S. Извиняюсь за слово велосипед :) Как то грубо получилось кажется

[Clauster]

Максимально быстро построенный feedback от заказчика(пользователя), либо тесная коммуникация с ним(доступ к трекеру задач в конце концов) всегда являлось хорошей методикой.

Методологии здесь не при чем. Допустим, вы разрабатываете ПО для новой модели мобильника...
Даже если есть заказчик, откуда ему знать про нужды конечного пользователя. Психбольницу выше не зря рекомендуют почитать.

[SALar]

Я или уже гоню или тут все работают по водопаду?
Даже если люди работают по водопаду мало что мешает использовать методики из гибких методологий(заказчик рядом, небольшие итерации).

Более половины проектов делаются по водопаду.
Кроме того короткие итерации будучи скрещенными с водопадом дают вполне жизнеспособные гибриды. Есть вещи, которые выбираются один раз. Это:
* Платформа реализации
* Крупноблочная архитектура (клиент-сервер/ трехзвенка/ ...)
* Для чего делается проект
* ... и много еще чего
ментальные карты - очень неплохой артефакт. И и лучше его делать перед первой поставкой. Один раз. Просто IMHO они делаются не совсем так, как описано в статье. Есть повод для дискуссии.

Максимально быстро построенный feedback от заказчика(пользователя), либо тесная коммуникация с ним(доступ к трекеру задач в конце концов) всегда являлось хорошей методикой.

Иногда да, иногда нет. Довольно часто это ведет к краху проекта.

--
Есть искушение при построение логистической системы организовать тесный контакт с пользователями системы. Делать под них интерфейс, планировать фичи в релиз исходя из их пожеланий и т.д. С неизбежностью это приведет к созданию не логистической но учетной системы. И естественно принесет бизнесу кучу убытков.
Для систем бизнес-класса интересы пользователя вторичны. А первичны интересы владельца бизнеса. Который совсем не обязательно является пользователем системы.

[Natalya Rukol]

А зачем такой никому ненужный функционал разрабатывать?

Вопрос хороший. Но зачастую болезненный для многих участников процесса :) Особенно когда речь идёт о тиражном продукте, который много версий подряд содержал оговоренный функционал.

В статье я рассматриваю работу с ММ исключительно со стороны тестирования. Зачастую QC любит обвинять во всём проектирование и разработку, однако начать улучшения можно и с себя. Подтверждено - работает ;)

[Natalya Rukol]

Для систем бизнес-класса интересы пользователя вторичны. А первичны интересы владельца бизнеса. Который совсем не обязательно является пользователем системы.

Если мы не говорим об откатных схемах, то чаще всего это не так. Потому что enterprise-решения призваны автоматизировать какие-либо процессы, т.е. оптимизировать временные затраты пользователей.

[Clauster]

В статье я рассматриваю работу с ММ исключительно со стороны тестирования. Зачастую QC любит обвинять во всём проектирование и разработку, однако начать улучшения можно и с себя. Подтверждено - работает ;)

Тогда ещё вопросы. У тестировщиков своя ММ, у разраработчиков своя ММ, не знаю кто там ещё, допустим у заказчика тоже своя модель. Пусть тестировщик локально в своем процессе получает какие-то бенефиты от ММ, а в целом-то все в проигрыше? И чья в таком случае ММ будет правильной? Разъясните. (вообще я в курсе как бы как оно должно быть, но это мне не кажется ясным из статьи и ваших комментариев)

[SALar]

Для систем бизнес-класса интересы пользователя вторичны. А первичны интересы владельца бизнеса. Который совсем не обязательно является пользователем системы.

Если мы не говорим об откатных схемах, то чаще всего это не так. Потому что enterprise-решения призваны автоматизировать какие-либо процессы, т.е. оптимизировать временные затраты пользователей.

Очень распространенное заблуждение. И одновременно одна из ключевых причин провала проектов по внедрению enterprise-решений. Зря вы вчера на поинтовку не пришли. Там эти вещи разбирались.

[Sapiens]

Clauster

Методологии здесь не при чем. Допустим, вы разрабатываете ПО для новой модели мобильника...
Даже если есть заказчик, откуда ему знать про нужды конечного пользователя. Психбольницу выше не зря рекомендуют почитать.

Нууу мне все таки кажется мы рассматриваем тестирование ПО. Если же вы разрабатываете для пользователей, но заказчик не из них, то есть и вариант альфа-бета тестирования, коим пользуются многие. Кроме этого заказчика в любом случае надо ставить в известность и давать какие то права на выбор тех или иных решений.
Кроме этого при разработке нового мобильника вы при должном финансировании сделаете социалогический опрос как минимум :)

SALar

Крах проекта все равно происходит не по вине пользователей - это логично по крайней мере :) .

[Clauster]

Clauster

Методологии здесь не при чем. Допустим, вы разрабатываете ПО для новой модели мобильника...
Даже если есть заказчик, откуда ему знать про нужды конечного пользователя. Психбольницу выше не зря рекомендуют почитать.

Нууу мне все таки кажется мы рассматриваем тестирование ПО. Если же вы разрабатываете для пользователей, но заказчик не из них, то есть и вариант альфа-бета тестирования, коим пользуются многие. Кроме этого заказчика в любом случае надо ставить в известность и давать какие то права на выбор тех или иных решений.
Кроме этого при разработке нового мобильника вы при должном финансировании сделаете социалогический опрос как минимум :)

А чем ПО в мобильнике не ПО. Ну давайте возьмем для конкретики iPhone. Я, конечно, не знаю, как там все было на самом деле, но сильно сомневаюсь по поводу альфа-бета и соц. опросов. (например, они не сделали ММС и видеосъемку. А в модели 3G нету фронтальной камеры и т.д.). Весь этот фидбэк - довольно субъективен и не дает конкретного ответа на вопрос какой продукт в итоге надо сделать. А соц опрос это вообще что-то непонятное - кого опрашивать - яппи, студентов или чотких пацанов которые будут эти айфоны отжимать? По поводу заказчиков - очень часто бывает, что разработчик сам же и является заказчиком.
Введение персонажей позволяет разрабатывать продукт под конкретного персонажа (не собирательного образа пользователя) и можно уже в самом начале довольно ясно представлять как будет выглядеть конечный продукт.

[Natalya Rukol]

Очень распространенное заблуждение. И одновременно одна из ключевых причин провала проектов по внедрению enterprise-решений. Зря вы вчера на поинтовку не пришли. Там эти вещи разбирались.

Давайте без сферических коней в вакууме, обсуждений ради обсуждений :)
Приведите конкретные примеры из своего опыта? У меня опыт исключительно обратный, как со стороны релиза так и со стороны закупок enterprise-софта.

[Natalya Rukol]

Тогда ещё вопросы. У тестировщиков своя ММ, у разраработчиков своя ММ, не знаю кто там ещё, допустим у заказчика тоже своя модель. Пусть тестировщик локально в своем процессе получает какие-то бенефиты от ММ, а в целом-то все в проигрыше? И чья в таком случае ММ будет правильной? Разъясните. (вообще я в курсе как бы как оно должно быть, но это мне не кажется ясным из статьи и ваших комментариев)

Вы прекрасно понимаете, что ММ у всех участников процесса должна быть одна :) И если Вы работаете в компании, где зрелые процессы и проработка модели делается совместо фичегруппой до начала разработки и актуализируется в процессе - то Вам моя статья не поможет т.к. просто не нужна :)
Если же на фирме этого нет, то поменять это одномоментно и для всех участников малореально. И именно тогда Вы можете начать с себя :)

[Clauster]

Тогда ещё вопросы. У тестировщиков своя ММ, у разраработчиков своя ММ, не знаю кто там ещё, допустим у заказчика тоже своя модель. Пусть тестировщик локально в своем процессе получает какие-то бенефиты от ММ, а в целом-то все в проигрыше? И чья в таком случае ММ будет правильной? Разъясните. (вообще я в курсе как бы как оно должно быть, но это мне не кажется ясным из статьи и ваших комментариев)

Вы прекрасно понимаете, что ММ у всех участников процесса должна быть одна :) И если Вы работаете в компании, где зрелые процессы и проработка модели делается совместо фичегруппой до начала разработки и актуализируется в процессе - то Вам моя статья не поможет т.к. просто не нужна :)
Если же на фирме этого нет, то поменять это одномоментно и для всех участников малореально. И именно тогда Вы можете начать с себя :)

Вот в этом и вопрос, если у тестировщика своя вселенная, а у остальных другая, в чем выгода и как понять, что тестировщик не ошибается в выборе ММ, с учетом того, что

Ответы на эти три, казалось бы, элементарных вопроса, получить не так-то просто, потому что:
* Для получения такой информации, Вам нужна репрезентативная выборка – что отнюдь непросто
* Для получения правильных ответов, Вам нужны правильные вопросы. Пользователь и сам не знает, что и как он использует.

Другими словами я не думаю, что начав с себя, сформировав ММ и работая с ней принесет какие-то бенефиты. Да, тестировщику станет легче, но выиграет ли от этого проект в целом - большой вопрос, шансы, имхо, примерно 50\50.

[rlabs]

Вы прекрасно понимаете, что ММ у всех участников процесса должна быть одна :) И если Вы работаете в компании, где зрелые процессы и проработка модели делается совместо фичегруппой до начала разработки и актуализируется в процессе - то Вам моя статья не поможет т.к. просто не нужна :)
Если же на фирме этого нет, то поменять это одномоментно и для всех участников малореально. И именно тогда Вы можете начать с себя :)

Мне не удалось найти в статье упоминаний о том, что модель должна быть _общая_, и что модель, вообще-то, не одна - для большинства программных продуктов нельзя сформировать "средний профиль пользователя".

Допустим, известно, что каждый участник разработки обязательно использует какую-то модель пользователя, даже если об этом не говорится явно. И в большинстве случаев эти модели различаются. Что происходит, когда тестировщик читает такое наставление "начать с себя"? Ага, он решает, что у него уже есть хорошая модель пользователя, или он сейчас создаст самую лучшую - для себя, потому что все остальные "не понимают и не хотят". И идет дальше по списку - меняет приоритеты багов, игнорирует области продукта, которые в его модели выглядят малозначимыми, и тд и тп. В это время остальная команда, мягко говоря, недоумевает от подобного подхода. Приведет ли такое "пробование" к хорошему результату?

Не думаю, что подавать User-Centered или Task-Centered Design в таком оригинальном представлении очень полезно.

[Natalya Rukol]

rlabs: У каждого участника процесса уже есть модель. Построенная на своём мнении и догадках. И "выкинуть" её из головы невозможно априори.
Но можно улучшить на основе реальных данных, т.е. из первоисточника (Пользователя).

[Alfa]

Может быть кто-то поделиться ссылками на дополнительные источники (книги/статьи) по теме? А то в изначальной статье не очень длинный список литературы.

[Sapiens]

А чем ПО в мобильнике не ПО. Ну давайте возьмем для конкретики iPhone. Я, конечно, не знаю, как там все было на самом деле, но сильно сомневаюсь по поводу альфа-бета и соц. опросов. (например, они не сделали ММС и видеосъемку. А в модели 3G нету фронтальной камеры и т.д.). Весь этот фидбэк - довольно субъективен и не дает конкретного ответа на вопрос какой продукт в итоге надо сделать. А соц опрос это вообще что-то непонятное - кого опрашивать - яппи, студентов или чотких пацанов которые будут эти айфоны отжимать? По поводу заказчиков - очень часто бывает, что разработчик сам же и является заказчиком.
Введение персонажей позволяет разрабатывать продукт под конкретного персонажа (не собирательного образа пользователя) и можно уже в самом начале довольно ясно представлять как будет выглядеть конечный продукт.

ПО в мобильнике тоже ПО естественно. Я кажется пропустил слово ПО в посте :) извиняюсь
Ну давайте вашим примером: Iphone не могли создать вот тупо просто сделаем как хотим. Соц опрос присутствовал в любом случае. Альфа бета можно сказать присутствовала, хоть и не в общепринятом виде. Ведь все таки прошивки на IPhone обновляются как не крути(если я не ошибаюсь то у них уже 3-версия прошивки на данный момент), значит фидбэк обрабатывается. Зря вы так оцениваете соц опросы - это тоже целое искусство и снижение рисков при нем имеется.
Когда заказчиком является сам программист, то еще лучше. Он сделает продукт именно таким каким он хочет его видеть.
Но давайте разделять понятия так, что заказчик это тот, кто платит.