Наверх

Почему пользователи ненавидят СЭД? от Usability Lab

Архив
Время чтения: 1 минута
29
Почему пользователи ненавидят СЭД? от Usability Lab

Дмитрий Сатин с Андреем Сикорским обсуждают «тихий ужас, который творится в Системах Электронного Документооборота. Программисты создают абстрактные системы для абстрактного пользователя. А реальные пользователи отвечают ненавистью, которую легко понять, если посмотреть на эти системы.»

Дмитрий Сатин с Андреем Сикорским обсуждают «тихий ужас, который творится в Системах Электронного Документооборота. Программисты создают абстрактные системы для абстрактного пользователя. А реальные пользователи отвечают ненавистью, которую легко понять, если посмотреть на эти системы.»

С любезного разрешения авторов переопубликовываю их вебинар. Хочу отметить, что хотя коллеги из Юзабилити Лаб сосредоточились на базовом и довольно узком функционале СЭД (хранение и согласование документов), не углубляясь в тему ECM, их советы и замечания интересны и познавательны. Слайды можно посмотреть отдельно: https://docs.google.com/a/usabilitylab.net/viewer?a=v&pid=explorer&chrome=true&srcid=0B47yubKYMy98N2M0ZTZkNmItY2VlYS00MGM2LTk5M2EtOThkMjMwYjU0MzRj&hl=en.

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 29

В этом вебкасте раздражает отсутствие, мягко говоря, глубины, а также легкомысленный тон, порой неуважительный к работающим с документами профессионалам. И это при том, что сами "знатоки" сумели запутаться даже в таких элементарных понятиях делопроизводства, как "входящие" и "исходящие документы" (не говоря о чем-то более сложном - вроде внутренних документов)...  Ну и зачем Максим выложил эту пародию на Comedy Club?




Вспомнилось бессмертное гоголевское: "Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась. А теперь поди подумай! просто голова даже стала болеть...". Так вот, если бы к незамыленному взору юзабелистов прибавить глубину познаний специалистов-документоведов, да отнять легкомысленности и неуважительности тех же юзабелистов, то сколько бы пользователей избавилось от головной боли? ;)




Веселый тон обсуждения сложных вопросов мной, вообще говоря, приветствуется, но не в данном случае. Говорить можно весело, а вот относиться нужно серьезно.

  В данном вебинаре авторы не являются специалистами в предметной области, и действительно не знают элементарных вещей – например, разницы между исходящими и внутренними документами. Следовательно, никогда не работали с СЭД в реальности. А это вызывает сомнения в их рекомендациях.

Что считаю совершенно недопустимым в их презентации - это показ результат внедрения СЭД : слайд «Весело болтающая по телефону секретарша». Вот это слайд может дискредитировать идею СЭД напрочь, если его увидит кто-нибудь из руководства компании-клиента. Ход мыслей такого начальника: «С какой стати я буду тратить такие деньги чтобы эти фифочки по телефону болтали???» И все труды по пропаганде электронного документооборота отправляются… Очень далеко, в общем.

  Нет бы сказать, что у такой секретарши:

  • Все документы хранятся в идеальном порядке
  • Все поручения начальника  по поиску нужной информации выполняются чуть ли не мгновенно
  • Выполнение всех резолюций и поручений постоянно контролируется.

И такая высококвалифицированная секретарша имеет возможность добросовестно выполнять свою главную обязанность – быть в курсе всего происходящего, а информацию собирает с помощью телефонных звонков.

 Далее. Предложение вводить резолюцию в окне просмотра.

    Мое мнение-делать так не надо.

    В окне просмотра находится либо карточка документа с реквизитами, либо сообщение с поручением. Чтобы выполнить поручение, нужно открыть сам электронный документ.

Даже в электронной почте  письмо нужно открыть, чтобы написать ответ.

 А в СЭД открытие карточки документа является  необходимым действием- системное событие регистрируется- пользователь начал работать с документом. Мне приходилось разбирать инциденты, когда нужно было доказать что пользователь открывал документ и го видел!

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

  Следующее замечание.

 Вопреки мнению авторов вебинара, системы электронного документооборота дают возможность пользователю при отправке на согласование или совместную подготовку писать, что они хотят получить.

А если сотрудник, получив документ на согласование, не знает, что с ним делать – это проблема не СЭД, а квалификации этого специалиста. А если это документ приходит в бумажном виде? Да, его запросто могут куда-то запрятать и… забыть. А вот СЭД забыть не даст!

  Поэтому СЭД ненавидят не все пользователи, а неквалифицированные специалисты. И дело здесь и не в СЭД, и не в интерфейсе….

  Еще немного.

  С чем соглашусь, так это с тем, что плохо обученные пользователи не понимают, зачем нужна СЭД, не умеют ей пользоваться.

Так это проблемы не СЭД, а плохо проведенного внедрения!

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

А делопроизводитель может замещать других сотрудников – если те резко работают с документами.

   Соглашусь и с тем, что в тексте документа нужно отмечать то, что именно нужно проработать. Но это относится к технологиям работы с документами, а не к функциям СЭД!

 ДА, технологиям работы с электронными документами нужно учить, как и быстрочтению, и навыкам слепой печати, и тайм-менеджменту, и навыкам систематизации. Но это не относится к СЭД! Это – работа внедренцев и консультантов, СЭД – это инструмент, которым нужно учиться владеть.

А унас получает как в анекдоте «Вы умеете играть на скрипке?» Не знаю, не пробовал.

  Очень хорошая мысль – Сэд должна быть самообучающей. Только это говорится уже, насколько помню, лет 10(а может и больше), и в тех СЭД, что я видела- такое есть. Стоило из-за этого огород городить?

   В общем, я не нашла чего-либо полезного в этом вебинаре, скорее такое отношение и такой заголовок - вреден, поскольку настраивает против СЭД при и без того сложной атмосфере при внедрении.

Критиковать легче всего, но все-таки нужно заслужить право на критику. Считаю, что авторы вебинара права на критику не имеют в силу слабой подготовки и явно проявляющегося отсутствия опыта.

 Соглашаясь с тезисом, что плохо обученный пользователь ненавидит СЭД, хочу сказать –если не умеете учить пользователей и писать хорошую, удобную документацию – не беритесь за внедрение. Всем лучше будет.

Ivan Steblenko 3 марта 2011

Добрый день, Ольга

Мне кажется, что Вы несколько неверно истолковали смысл данного вебинара. Докладчики ставили целью сказать, что интерфейс для конечного пользователя СЭД временами очень неудобен (что тут отрицать, думаю все с этим сталкивались) и приводят попытки частичного решения этой проблемы с их точки зрения. Там нет идеи, что СЭД - это плохо.

В данном вебинаре авторы не являются специалистами в предметной области, и действительно не знают элементарных вещей – например, разницы между исходящими и внутренними документами. Следовательно, никогда не работали с СЭД в реальности. А это вызывает сомнения в их рекомендациях.

Не имеет значения в контексте данного вебинара, так как здесь разбирается UX, а не архитектура системы.

Что считаю совершенно недопустимым в их презентации - это показ результат внедрения СЭД : слайд «Весело болтающая по телефону секретарша». Вот это слайд может дискредитировать идею СЭД напрочь, если его увидит кто-нибудь из руководства компании-клиента. Ход мыслей такого начальника: «С какой стати я буду тратить такие деньги чтобы эти фифочки по телефону болтали???» И все труды по пропаганде электронного документооборота отправляются… Очень далеко, в общем.

Очень спорный момент. Весело болтающая по телефону секретарша может в этот момент договариваться о крупной сделке. Делать хмурое лицо вовсе необязательно при этом). Считаю, что это не относится не к "+", не к "-" вебинара.

Нет бы сказать, что у такой секретарши:
Очень сухо, не та ЦА. Вебинар для разработчиков.
В окне просмотра находится либо карточка документа с реквизитами, либо сообщение с поручением. Чтобы выполнить поручение, нужно открыть сам электронный документ.
Она и так открыта. Посмотрите на окно, в котором находится действие по вынесению резолюции. Если по Вашему примеру сравнивать с почтой, то можете заметить, что не открывая само письмо, с ним можно делать очень много действий из контекстного меню (сужу по MS Outlook, в других клиентах возможно иначе - если так, то буду рад примерам).
Согласен с Вами в том, что не всегда быстрое действие является полезным и может ввести пользователя в заблуждение. Но докладчики явно обозначили бизнес-процесс, в контексте которого делалось предложение об улучшении интерфейса.
Поэтому СЭД ненавидят не все пользователи, а неквалифицированные специалисты. И дело здесь и не в СЭД, и не в интерфейсе….
Соглашусь отчасти. Предполагаю, что очень сложный и запутанный интерфейс не вызывает у конечного пользователя бурю восторгов). К примеру, очень часто встречаю мнение, что MS SharePoint плох из-за того, что там крайне неудобный интерфейс (разбирать это утверждение и воевать по нему не предлагаю, привожу только в качестве примера).
А если сотрудник будет пользоваться СЭД раз в год написать заявление на отпуск- а нужно ли ему рабочее место СЭД? Это дорогое удовольствие. Заявление на отпуск может и офис-менеджер, или секретарь ввести в систему. Для этого в продвинутых СЭД есть механизм замещения, т.е сотрудник может замещать другого по функциям работы в системе. Например, секретарь может замещать своего начальника по функциям ввода резолюций, если тому нравится писать их на бумаге.
Насколько я понял докладчиков, они это и предложили: выделение отдельного менеджера.
СЭД – это инструмент, которым нужно учиться владеть.
Полностью согласен с Вами.
В общем, я не нашла чего-либо полезного в этом вебинаре, скорее такое отношение и такой заголовок - вреден, поскольку настраивает против СЭД при и без того сложной атмосфере при внедрении.
Просто этот вебинар ориентирован, в основном, на разработчиков. И интересные идеи, по моему мнению, в нем есть.
С большим удовольствием прочитал Ваш отзыв :).
PS. Нет, я не имею никакого отношения к авторам этого вебинара и все вышенаписанное здесь - чистой воды отсебятина.
В данном вебинаре авторы не являются специалистами в предметной области, и действительно не знают элементарных вещей – например, разницы между исходящими и внутренними документами. Следовательно, никогда не работали с СЭД в реальности. А это вызывает сомнения в их рекомендациях. Не имеет значения в контексте данного вебинара, так как здесь разбирается UX, а не архитектура системы.

Добрый день!

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

Что-то у меня цитирование не работает. Поэтому цитировать буду сама.

"Просто этот вебинар ориентирован, в основном, на разработчиков".

     Разработчики делают СЭД по техническому проекту, который пишет или аналитик(вот я,например) или консультант(так было на предыдущей работе). И интерфейс проектируется на стадии технического проекта.Иногда - даже на стадии технического задания.

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

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

И знаю, что читать это будут не только специалисты. но и пользователи. Особеннно те, кому еще предстоит внедрение или развитие СЭД.Поэтому решительно против "Болтающей секретарши"  как результат внедрения.. И так уже сто раз слышала :"А что девочки-то делать будут? Бездельничать?" Поэтому и пишу свое мнение.

Вопрос интерфейса болезненный. Но чем дольше работаю, тем больше убеждаюсь, что удобство  чаще всего -вопрос привычки. Мне вот пришлось раз упражняться в копировании интерфейса досовской программы- в современной СЭД. Вот отказывалиись работать в другом интерфейсе- и все.Хотя не могу сказать, что там было что-то сверхудобное.

   А по поводу авторов- их предложения либо неприменимы, либо уже реализованы. Чего-то нового не увидела.

Название, к сожалению, вводит в заблуждение. Это читается как "ВСЕ пользователи ненавидят СЭД", что неверно.

"


 

Ivan Steblenko 3 марта 2011
При разработке интерфейсов как раз очень важно- технология работы пользователей

Я бы сказал, что крайне важна =)

Иногда требования пользователей приходится игнорировать, така небольшое изменение интерфейса ведет к большому изменению архитектуры
А вот это - крайне плохо. Нельзя, чтобы расположение кнопочек и окошек как-то влияло на бизнес слой приложения. Но, конечно, часто приходится мирится с большим количеством legacy кода.
Разработчики делают СЭД по техническому проекту, который пишет или аналитик(вот я,например) или консультант(так было на предыдущей работе). И интерфейс проектируется на стадии технического проекта.Иногда - даже на стадии технического задания

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

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

Наблюдение: Профессионалы работают в сфере эргономики (наука есть такая), а остальные занимаются модной "юзабилитью"... :)

Ivan Steblenko 3 марта 2011
Наблюдение: Профессионалы работают в сфере эргономики (наука есть такая), а остальные занимаются модной "юзабилитью"... :)

UX говорить моднее ;)

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

Андрей Подкин: Например,если рядового пользователя при создании документа для своих личных внутренних целей заставляют заполнять столько же полей, сколько и делопроизводителя для официального документа, то дело явно в СЭД и в интерфейсе.

Думаю, что это не совсем так. Обязательные для заполнения поля настраиваются, причем их набор, как правило, можно настраивать индивидуально для различных видов документов. Если администратору системы неохота этим заниматься, то это ещё не значит, что интерфейс у СЭД плохой.

Согласна по поводу настройки набора полей. Но вот еще один аспект. 

Если рядовому пользователю нужно создать документ для своих личных внутренних целей - мне не очень понятно, зачем это нужно делать в СЭД? Пусть сделает на личном компьютере и сохранит локально.

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

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

Ольга, если помните, год назад я проводил опрос в «Моем круге» среди коллег по внедрению различных СЭД по инструментам проектирования интерфейсов в том числе и для целей кастомизации GUI. Большинство опрошенных никогда не проводило кастомизацию интерфейса под заказчика. Находится куча поводов отказать, в том числе и унаследованность технологий, не позволяющих менять интерфейсы т.к. придется затрагивать функциональное ядро, а это совсем другие деньги (это не html с cssками подредактировать) и другие бла-бла-бла.

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

Станислав Ким писал: Ну ламеры докладчики в вопросах документооборота
А их познания/рекомендации по части удобного интерфейса СЭД Вас разве впечатлили? :)
...разработчики СЭД никак не хотят думать про юзабельность интерфейсов...
О нет, они об этом думают - но ровно в такой степени, которая оправдана с коммерческой точки зрения. Вы ведь тоже не станете вкладывать большие средства в совершенствование интерфейса, если не будете уверены, что эти затраты гарантированно с лихвой окупятся, правда ведь? Тем более, что представление о замечательно удобном интерфейсе у каждого клиента своё (и оно не единственное и не неизменное - мнение тех, кто в системе реально работает, часто не совпадает с мнением тех, кто писал ТЗ. Кроме того, влияет масса других факторов - степень знакомства с системой, объёмы документопотоков и т.д.)
...просто готовят СЭД-поляну для своего юзабилити-бизнеса
Лучше не скажешь :)
Если рядовому пользователю нужно создать документ для своих личных внутренних целей - мне не очень понятно, зачем это нужно делать в СЭД? Пусть сделает на личном компьютере и сохранит локально.
Я не совсем верно выразился. Документ в конечном счете пригодится в работе, но это какие-то свои личные записки, не предназначенные для официальных действий. Создавать их локально? А зачем тогда мы покупали систему, которая может всё и для всех, а не только для делопроизводителей? ;-)
Обязательные для заполнения поля настраиваются, причем их набор, как правило, можно настраивать индивидуально для различных видов документов.
Но все равно это сложнее, чем создать документ Word в файловой системе.
О нет, они об этом думают - но ровно в такой степени, которая оправдана с коммерческой точки зрения.
Именно! Но Андрей Сикорский продвигает точку зрения, что интерфейс должен строиться на трех составляющих:
  1. Потребности бизнеса.
  2. Потребности рядового пользователя.
  3. (Технические) ограничения.

И ни от одной из составляющих отказаться нельзя (хотя, конечно, приходится идти на компромиссы).

Создавать их локально? А зачем тогда мы покупали систему, которая может всё и для всех, а не только для делопроизводителей? ;-)

Какие задачи вы ставите, сохраняя документ в СЭД?  Основные преимущества проявляются при коллективной работе. Преимущество СЭД вижу в том, что если  основная часть документов хранится в СЭД, тогда и остальные документы нужно создавать там же - удобнее иметь все в одном месте.

СЭД не заменяет офисные приложения, а сохраняет документы, созданные в самых разных приложениях.

По поводу Сикорского: три составляющих интерфейса не только он продвигает.  Все интерфейсы разрабатываются на основании этих принципов.  И СЭд развиваются уже много лет. И пожеланий по совершенствованию интерфейсов высказывалось множество- пользователями, поработавшими в в СЭД. Лучшее оставалось в базовых решениях, поэтому  все эти наезды по поводу ужасных интерфейсов воспринимаю как желание навязать свои услуги. Только как можно прислушиваться к мнению людей, не понимающих последствия своих предложений?


Но Андрей Сикорский продвигает точку зрения, что интерфейс должен строиться на трех составляющих...
Пусть хоть на пяти :))  Если клиент готов платить - он уже и сегодня получает то, что хочет. В противном случае ему остается надеяться и ждать, когда конкуренция заставит производителей самих  "вложиться" в совершенствование интерфейса.
И ни от одной из составляющих отказаться нельзя
Да ну?! Как только разговор переходит на деньги, выясняется, что отказаться можно практически от всего :)
Замечу, что в реальной жизни потребности рядового пользователя, как правило, сколько-нибудь интересны заказчику лишь тогда, когда их удовлетворение выгодно для бизнеса. Соответственно, выделять их отдельно нелогично (Сикорский не предлагает ведь отдельно выделять потребности VIP-ов).
Преимущество СЭД вижу в том, что если  основная часть документов хранится в СЭД, тогда и остальные документы нужно создавать там же - удобнее иметь все в одном месте.
Да, например, для меня именно это и является для меня основным преимуществом.
Лучшее оставалось в базовых решениях, поэтому  все эти наезды по поводу ужасных интерфейсов воспринимаю как желание навязать свои услуги. Только как можно прислушиваться к мнению людей, не понимающих последствия своих предложений?
А почему "не понимающих"? Некоторое время назад мы с Сикорским общались на тему одной задачи (правда, имеющей несколько опосредованное отношение к СЭД). Не скажу за всех своих коллег, но я вполне удовлетворен тем, что и как получилось.
Если клиент готов платить - он уже и сегодня получает то, что хочет.

Наталья, вы же явно лукавите ;-)

Клиентов, которые просят именно то, что хотят, катастрофически мало. Из некоторых чуть ли не клещами приходится вытаскивать реальные потребности.

Как только разговор переходит на деньги, выясняется, что отказаться можно практически от всего :)
Этот пример мне очень нравится. Потому что на практике все обстоит иначе: есть вещи которые высококвалифицированный разработчик не будет делать ни за какие деньги. Точнее будет, но довольно ограниченное время. Потом либо уволится, либо перестанет быть высококвалифицированным.
Замечу, что в реальной жизни потребности рядового пользователя, как правило, сколько-нибудь интересны заказчику лишь тогда, когда их удовлетворение выгодно для бизнеса.
Опять получается какой-то сферический идеальный заказчик в вакууме. Как раз таки в реальной жизни заказчик часто не представляет, какие решения могут повлиять на сопротивление работников внедрению системы. И здесь мы возвращаемся к предыдущему вопросу (про деньги): если ваша цель - однократная продажа, это одно, а если вы хотите получить лояльную компанию-клиента для будущей работы с ними же - это совсем другое.
Сикорский не предлагает ведь отдельно выделять потребности VIP-ов
А почему вы так решили? ;-)
Ivan Steblenko 4 марта 2011

Интересная дискуссия =)

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

Печально, что многие так и думают. На примере многих компаний можно сказать, что классный дизайн должен быть не только для избранных. И эти компании можно назвать: Google, Virgin, Gilette, Apple и т.д. Благодаря дизайну, эти компании создают потрясающие продукты: iPod, который взорвал рынок плееров; Mach3, казалось, что уже и нечего было придумать; Google, ну этим все сказано).

Можно заявить, что это конечно круто, но это все для потребительского рынка, и быть отчасти правым. Но, а как же насчет офисных продуктов? Microsoft, IBM, та же Google, тратит огромные средства для доработки пользовательского интерфейса! И такое не только в офисных продуктах, но и даже в средствах разработки и даже еще в более узких рынках. Как человек, плотно сидящий на игле SharePoint, скажу - сравните интерфейс 2007 и 2010 версий этой платформы. А текущая работа говорит мне, что многие заинтересовались им именно из-за того, что им удобно пользоваться (естественно после некоторых доработок под клиента).

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

Как то я эмоционально ответил =). Кратко, суть в том, что интерфейсы - это далеко не последнее, на что надо обращать внимание, а даже одно из первых.

Этот пример мне очень нравится. Потому что на практике все обстоит иначе: есть вещи которые высококвалифицированный разработчик не будет делать ни за какие деньги. Точнее будет, но довольно ограниченное время. Потом либо уволится, либо перестанет быть высококвалифицированным.
Полностью согласен с Андреем.
PS. Стоимость создания дизайна для бритвы Mach3 составило порядка $70 млн...
Клиентов, которые просят именно то, что хотят, катастрофически мало. Из некоторых чуть ли не клещами приходится вытаскивать реальные потребности.
На что же тогда бизнес-аналитики? ;)
Потому что на практике все обстоит иначе: есть вещи которые высококвалифицированный разработчик не будет делать ни за какие деньги. Точнее будет, но довольно ограниченное время. Потом либо уволится, либо перестанет быть высококвалифицированным.
Андрей, это позиция наемного работника.  И то, справедлива, если есть, куда уйти :)

Андрей Подкин писал: ... есть вещи которые высококвалифицированный разработчик не будет делать ни за какие деньги...

Согласна, есть - в первую очередь он не будет опускаться до выполнения техничесой работы, не соответствующей его квалификации (при условии, что ему есть куда уйти в случае конфликта). В лучшем случае,  он не будет выдавать на-гора откровенную халтуру. В остальном же достойная (с его точки зрения) зарплата снимает все вопросы.
Наталья, вы же явно лукавите ;-) Клиентов, которые просят именно то, что хотят, катастрофически мало.

Нет, не лукавлю - я же не сказала, что они просят то, что для них было бы (с моей или чьей -либо ещё точки зрения) оптимально :) Все поставщики и интеграторы своих клиентов консультируют, однако, в конечном итоге, решение принимает сам клиент. И я бы не сказала, что грамотных клиентов мало - скорее, откровенно безграмотные стали встречаться реже. В конце концов, одних только статей о том, как правильно внедрять СЭД, каждый год публикуются десятки, так что всегда можно опереться на чужой опыт. Случалось мне встречать и таких заказчиков, которым разные юзабилисты и в подмётки не годятся.

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

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

   А просто рассуждения "нравится-не нравится"- очень субьективные, зависит от привычек к определенным интерфейсам(я видела сторонников интерфейсов MS Office, которые терпеть не могут Lotus, и наоборот).

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

Андрей, это позиция наемного работника.
Так они и создают программные продукты вообще-то ;-)

C интересом следил за дискуссией и абсолютно согласен с Ольгой.

Дискуссия ушла куда-то совсем в другую сторону.  Я, вообще-то, за удобный, разработанный в соответствии с эргономикой интерфейс. И это-не абстрактные рассуждения, а текущая работа. Вопрос стоял в том. что об удобстве интерфейса рассуждают люди, не понимающие специфики работы пользователя, поэтому их рекомендации представляются сомнительными.
По существу - все предложения так или иначе или реализованы в разных системах. Если интерфейс рассмотренных докладчиками систем им не понравился, это не дает им право осуждать обобщая все СЭД.
Сейчас модно говорить о сложном просто и доступно, но для этого нужно в совершенстве владеть вопросом, чтобы быть в состоянии донести сложную мысль до слушателя - в докладе кроме ахов и охов, нет ничего. Ну вот не нравится и все, гадко и мерзко. Повторюсь, все (!) услышанные мною предложения я видел в различных "универсальных" системах либо не реализовано из-за ограничений сути процесса, а не прихоти разработчиков.
Вебинар для разработчиков
Если труд претендует на какую-то ценность для разработчиков он должен содержать полный и точный анализ различных систем. А так час разговора ни о чем. Разработчики не воспримут из-за поверхности изложения и не профессионализма докладчиков, а простые пользователи, ненавидящие СЭД, лишь укрепятся в своих заблуждениях и все останутся при своих. Сизифов труд...
Ivan Steblenko 8 марта 2011

Добрый день, Руслан

Если труд претендует на какую-то ценность для разработчиков он должен содержать полный и точный анализ различных систем. А так час разговора ни о чем. Разработчики не воспримут из-за поверхности изложения и не профессионализма докладчиков
Позвольте не согласится с Вашим мнением, и вот почему:
  • по поводу анализа различных систем: штука полезная, но в 1 час вебинара - не влезет, и провести полный и точный различных систем очень сложно и необходимо ли это разработчику? Use case, сценарии использования систем, интерфейсы и пр. - да, будут интересны, но вот, допустим, особенности развертывания системы на многосерверной ферме... разработчику это будет неинтересно. 
  • по поводу разработчиков: скажу как разработчик =), нашел для себя ряд интересных идей и с большим интересом стал просматривать другие вебинары от UsabilityLab.
Если интерфейс рассмотренных докладчиками систем им не понравился, это не дает им право осуждать обобщая все СЭД.
Если не ошибаюсь, там не было слов, что интерфейсы всех СЭД ужасны. Но вот название вебинара - да, несколько не отражает то, о чем рассказывают. Мне кажется, что оно и вводит в заблуждение.
по поводу разработчиков: скажу как разработчик =), нашел для себя ряд интересных идей

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

В окне просмотра находится либо карточка документа с реквизитами, либо сообщение с поручением. Чтобы выполнить поручение, нужно открыть сам электронный документ. Она и так открыта. Посмотрите на окно, в котором находится действие по вынесению резолюции. Если по Вашему примеру сравнивать с почтой, то можете заметить, что не открывая само письмо, с ним можно делать очень много действий из контекстного меню (сужу по MS Outlook, в других клиентах возможно иначе - если так, то буду рад примерам).
 Я говорила не про открытую карточку, а про электронный документ. Прежде ем вывносить резолюцию, нужно хотя б просмотреть электронный документ. Еесли приерживаться аналогии с электронной почтой, электронный документ- это приаттаенны файл.
Повторюсь- получается. что поле в карточке документа провоцирует выносить резолюцию. даже не просмотрев сам документ. Что недопустимо.
Ivan Steblenko 11 марта 2011

Добрый день, Ольга

Может быть, Вы поподробнее изложите. какие именно идеи  оказались для Вас интересными
С удовольствием. Только еще раз повторюсь, что эти идеи показались мне интересными. И мое мнение субъективно и не является единственной истиной =).
  1. "Массовый (казуальный) пользователь из всех корпоративных систем хорошо владеет только почтой", слайд 47
  2. "В идеале пользователь не должен видеть интерфейсы системы, взаимодействую с ней из других офисных систем, которые он хорошо знает.", слайд 51
  3. "В интерфейсах согласования документа должна быть простая возможность обсудить документ с сотрудниками", слайд 53

Возможно, что для кого-то это прописные истины.

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

Добрый день! Спасибо за ответ.

     Такой вопрос. что очень дорогой менеджер не должен тратить свое время  на рассмотрение договоров менее определенной суммы, решается на уровне составления регламентов, а не на уровне техничесуких средств- ему просто такие договора не направляют. Если человек выполняет какое-то действие, он должен нести за это ответственность- в этом смысл визирования договоров. В ситуации "Визирование без рассмотрени текста договора" весь смысл процесса теряется.

Или это можно решить даже не на уровне регламентов-а  поставить в настройках  WORKFLOW  условие, кому направлять договор на рассмотрение, с суммой договора  более миллиона- дорогому менеджеру, менее- его помощнику (или другому менеджеру. "Главному по мелочевке".
 

Ivan Steblenko 11 марта 2011
Такой вопрос. что очень дорогой менеджер не должен тратить свое время  на рассмотрение договоров менее определенной суммы, решается на уровне составления регламентов, а не на уровне техничесуких средств- ему просто такие договора не направляют.

Совершенно согласен =)

Или это можно решить даже не на уровне регламентов-а  поставить в настройках  WORKFLOW  условие, кому направлять договор на рассмотрение, с суммой договора  более миллиона- дорогому менеджеру, менее- его помощнику (или другому менеджеру. "Главному по мелочевке".
И так тоже можно).
Чтобы прокомментировать, или зарегистрируйтесь