Больше болтать с пользователями, не рассуждать только в терминах сколько времени на что потребуется если у людей есть более важные критерии.
Пользователи — тоже люди. И странно предполагать что только вне работы они совершают импульсивные покупки, ценят дизайнерские вещи, выбирают не только головой но и сердцем, а, придя на работу, становятся роботами, прущимися от того что что-то стало на 10% быстрее.
Существует интерфейсная форма, которая выполняет функции А и Б. Функция Б используется в 100 раз реже, чем функция А. Соласно некоторому эксперименту, если функцию Б вынести в отдельную сервисную форму, время затрачиваемое на выполнение функции А уменьшится на 10 процентов.
Вынесли, сделали всё технологично и удобно. Но работа остановилась из за иррациональных требований пользователей. Им категорически не понравилось.
Это один пример исключительной ситуации в общем-то налаженном процессе разработки. Но эти исключения сами по себе уже являются системой.
Внимание вопрос: какие мероприятия необходимы, какие элементы процесса разработки добавить для учета данных ситуаций или где об этом можно почитать?
Я бы сказал что в UI хороший подход — try & discard. Mockups работают далеко не всегда, потому что многие люди не могут оценить тупой прототип, нужен почти полностью работающий прототип. Выход — не дизайнить интерфейс на бумажке до посинения, заимплементировать если кажется что понятно что делать, поиграться, потом или оставить или поправить или выкинуть.
Здравствуйте, grosborn, Вы писали:
G>Существует интерфейсная форма, которая выполняет функции А и Б. Функция Б используется в 100 раз реже, чем функция А. Соласно некоторому эксперименту, если функцию Б вынести в отдельную сервисную форму, время затрачиваемое на выполнение функции А уменьшится на 10 процентов. G>Вынесли, сделали всё технологично и удобно. Но работа остановилась из за иррациональных требований пользователей. Им категорически не понравилось.
Когда вы с новой версией меняете интерфейс уже работающей программы, вы обязательно сталкиваетесь с сопротивлением пользователей — причем с сопротивлением практически любым изменениям кроме тех что очевидно "спрямляют углы" существующего интерфейса. Просто потому, что они "уже так привыкли".
То что "встала работа" — означает, что были проблемы с переходом к новой версии интерфейса. Либо прототип нового интерфейса не был показан реальным пользователям, либо не был ими воспринят, или же не была проведена тестовая эксплуатация новой версии...
> Больше болтать с пользователями, не рассуждать только в терминах сколько времени на что потребуется если у людей есть более важные критерии.
> Я бы сказал что в UI хороший подход — try & discard. Mockups работают далеко не всегда, потому что многие люди не могут оценить тупой прототип, нужен почти полностью работающий прототип. Выход — не дизайнить интерфейс на бумажке до посинения, заимплементировать если кажется что понятно что делать, поиграться, потом или оставить или поправить или выкинуть.
Немножко поясню процесс разработки:
Делается прототип. Если он показал свое удобство, делается конечный вариант. Конечный вариант делается уже с учетом самых разных ситуаций эксплуатации. То есть он получается в принципе уже рабочим. Дальше идет осторожная обкатка на некоторой группе пользователей на реальных данных и при этом фиксируются все замечания и действия пользователя. Это дает некоторую "шлифовку" форм, даже появляется некоторая новая функциональность формы, увеличивающая её удобство и скорость работы. Редко приводит к откату.
Далее идет выпуск в работу — на конечных пользователей.
После некоторого периода эксплуатации может накопиться некоторое количество замечаний, пожеланий, требований, сравнений. Соответственно, возникает возможность создания Версии II формы (функции).
Создание следующей версии — повторение цикла разработки, от прототипа, с учетом всех накопленных знаний, что позволяет перепроектировать форму, при необходимости.
В результате возможность отката есть только на этапе проектирования, а конечные пользователи не могут try & discard, поскольку им приходит готовая форма, вероятность discard этой формы по объективным причинам крайне мала и даже если происходит, цикл discard занимает месяцы.
Делать для массы конечных пользователей try — нереально.
Чего хочется: найти способы работы с возражениями пользователей (в справку?), учет возможных возражений пользователей при проектировке интерфейса. Вот какой-то такой методики не хватает. Чего-то сделать, что бы пользователи воспринимали изменения, а не противвились им.
> Когда вы с новой версией меняете интерфейс уже работающей программы, вы обязательно сталкиваетесь с сопротивлением пользователей — причем с сопротивлением практически любым изменениям кроме тех что очевидно "спрямляют углы" существующего интерфейса. Просто потому, что они "уже так привыкли". > > То что "встала работа" — означает, что были проблемы с переходом к новой версии интерфейса. Либо прототип нового интерфейса не был показан реальным пользователям, либо не был ими воспринят, или же не была проведена тестовая эксплуатация новой версии
Я не спец в корпоративном ПО, могу попасть пальцем в небо. На основани ваших пояснений многое не ясно, в частности, пишет ли ваша фирма ПО для сторонней конторы или для себя (есть разница)? Имхо, проблема организационная. Нужна "демпфирующая прослойка" м-ду конечными пользователями и разработчиками. Будь то полчеловека или целая "комиссия". Пусть она решает эти проблемы. Пусть несет ответственность "за базар" перед вами и отдувается перед юзерами. Если заказчик сторонний, то за это может отвечать его подразделение.
Второе. Изменения UI мало кого радуют на самом деле. Это часто воспринимается как игры разработчиков, которым делать нечего или даже которым лишь бы бабки вытянуть. А людям "надо работать", и пусть все кнопки остаются на привычных местах. Люди ведь официально изучают работу с системой, тратят время и умственную энергию. Вдруг переделки! Они же не "компьютерщики". Многим реально надо переучиваться, они не хватают это на лету как программеры. Не исключено, что от каких-то улучшений надо действительно отказыватсья.
Может быть, предварительная моральная подготовка юзеров может помочь. Если человеку заранее объяснить, что это круто, сделано для него, то он воспримет нормально, это будет для человека логично. Что-то типа рекламы с человеческим уклоном. Люди ее нормально едят. А не так, когда непонятные (непредсказуемые, а следовательно нелогичные) изменения вдруг валятся на голову.
Из ваших пояснений не ясно, насколько продумано и ситемно вводятся изменения. То ли изменился некий "сквозной" принцип работы юзера (ну как внедрение "риббона" от Микрософт во всем МС Офисе сразу)? Делается ли это редко, с мажорной версией? То ли вы можете вдруг передизайнить несколько отдельных форм в очередном релизе? Может здесь нужна система?
Микрософт ведь про свой "риббон" никого из конечных пользователей не спрашивал. Обкатал на группе и внедрил. Очень часто и такое поведение правильно, если делается не каждые полгода. У моего родственника внедрили новую складскую систему вместо старой на DOSе. Было много бурчания поначалу. Но внедрили новую, а теперь радуются уже ей. Мнение некоторых юзеров приходится игнорировать, это неизбежно. А фигли делать? Прогресс!
> На основани ваших пояснений многое не ясно, в частности, пишет ли ваша фирма ПО для сторонней конторы или для себя (есть разница)? Имхо, проблема организационная. Нужна "демпфирующая прослойка" м-ду конечными пользователями и разработчиками. Будь то полчеловека или целая "комиссия". Пусть она решает эти проблемы. Пусть несет ответственность "за базар" перед вами и отдувается перед юзерами. Если заказчик сторонний, то за это может отвечать его подразделение.
Есть три группы потребителей, в соответствии с их количеством по возрастанию:
"Свои" пользователи.
Пользователи с которыми ведется индивидуальная работа.
Сторонние пользователи, от которых разработчик хорошо изолирован.
С первой и второй группой ещё можно работать напрямую, помогать им, да и то — трудно. А с третьей взаимодействие может быть только техническое, посредством исходящих каналов: документацией, справкой, работой форм (подсказки), почтовой рассылкой и уведомлениями (неэффективно).
Обратные каналы: мониторинг использования того или иного функционала, feedback.
> Второе. Изменения UI мало кого радуют на самом деле. Это часто воспринимается как игры разработчиков, которым делать нечего или даже которым лишь бы бабки вытянуть. А людям "надо работать", и пусть все кнопки остаются на привычных местах. Люди ведь официально изучают работу с системой, тратят время и умственную энергию. Вдруг переделки! Они же не "компьютерщики". Многим реально надо переучиваться, они не хватают это на лету как программеры. Не исключено, что от каких-то улучшений надо действительно отказыватсья.
Это очень даже понятно. В идеале — сделал программу и на десять лет. Так вот нет же, приходится бороться за новых потребителей и предупреждать уход старых. Если не вносить изменения, не развивать, то всё будет ещё хуже, чем даже при неудачном процессе развития. Мы даже насущные вещи не ставим достаточно долго, то есть тормозим развитие.
> Может быть, предварительная моральная подготовка юзеров может помочь. Если человеку заранее объяснить, что это круто, сделано для него, то он воспримет нормально, это будет для человека логично. Что-то типа рекламы с человеческим уклоном. Люди ее нормально едят. А не так, когда непонятные (непредсказуемые, а следовательно нелогичные) изменения вдруг валятся на голову.
Моральная подготовка достаточно неэффективна. Вот внесли изменения в релизе, сделали специальный попап. А отказы по этому изменению начинают приходить когда уже десять релизов прошло, кто-то там вышел из отпуска, кто-то эту кнопку не нажимал и тд.
У меня есть мысль, что нужно создать какой-то свод формальных правил, как изменять нельзя и как изменять можно. Ну типа нельзя одновременно менять и название кнопки, и передвигать её на другое место. Но можно что-то одно из перечисленного. А второе — через какой-то промежуток времени.
Но для создания такого свода правил статистики явно недостаточно.
> Из ваших пояснений не ясно, насколько продумано и ситемно вводятся изменения. То ли изменился некий "сквозной" принцип работы юзера (ну как внедрение "риббона" от Микрософт во всем МС Офисе сразу)? Делается ли это редко, с мажорной версией? То ли вы можете вдруг передизайнить несколько отдельных форм в очередном релизе? Может здесь нужна система?
Вообще-то некоторые изменения для конечного пользователя как снег на голову. В самый непоходящий момент Недостатки в нашей работе есть, но они объективно не настолько критичны, как это может показаться некоторым пользователям.
> А фигли делать? Прогресс!
Всё бы ничего, если бы мы могли проводить эксперименты на кроликах. В действительности приходится это делать на живых людях.
— При внесении изменений недовольные всегда найдутся. Контакт с недовольными — забота не разработчика.
— Может быть, иногда стоит избегать изменений, направленных на 10% повышением производительности. Вероятно граница должна быть повыше.
— Вариантов переделки UI, форм — множество. Все в 1-ю очереедь зависит от workflow. Если он не меняется, то в большинстве случаев лучше и не трогать. Общий закон, касающийся изменений в кнопках, вывести скорее всего будет сложно.
— Изменения не должны быть частыми (и ругать будут реже заодно). Если одна и та же форма меняется раз в квартал без просьб с "той" стороны — это перебор, имхо.
Только больше болтать, понимать самим что им на самом деле нужно (а это не всегда то что они именно говорят). Можно показывать прототипы существующим клиентам.
А чтобы не противились — нужно продавать изменения. Не просто "мы тут что-то сделали, должно быть лучше", а "мы сделали так, теперь вы сможете делать удобнее вот это и вот это".
Здравствуйте, grosborn, Вы писали:
G>Я кажется вас понял. Но это скорее моё неумение хорошо пояснить ситуацию, а не формальный подход к разработке.
Конкретно надо рассказывать что было, что сделали со скриншотами, сценариями вашими мнениями, и мнениями пользователей. Тогда и получите конкретный ответ, а так совет остаётся в силе.
Недостатки в нашей работе есть, но они объективно не настолько критичны, как это может показаться некоторым пользователям.