Interface prototyping (rus), Requirement management (rus)

Психбольница в руках пациентов

Начал читать эту книгу, сначала плевался.. Плевался до 71-й станицы, потом у меня открылись глаза, это потрясающе..

Я сейчас разрабатываю Систему1, опирающуюся на уже реализованную Систему2. Чтобы понять Систему2 я ломал мозг дня 2, если не больше, и то не без посторонней помощи.. ТЗ на систему 1 надо завершить к концу января. Я прямо напарываюсь на то, о чём пишет Алан Купер: Если срок сдачи объекта – первое июня (я: считай, февраля), то наступление июня не всегда означает, что здание готово. А следовательно: Уже первое июня (я: февраля), следовательно, продукт готов. «В тираж» – говорят они, и срок сдачи становится единственным признаком завершенности проекта.

Причём, о том, чтобы пользователь смог работать с системой без обучения, чтения документации, и, очевидно, ощущения, что он “идиот”, я как-то не задумывался. Я всегда считал, что документация снимет все вопросы и недопонимания, который возникли из-за того, что у меня не хватило времени/ума/желания на проработку всего и вся и я реализовал процесс вот так. Да к тому же есть обучение и служба поддержки. Кстати, следует добавить, что зачастую существующая архитектура просто бы треснула при реализации интуитивно понятного интерфейса общения пользователя с записями БД.

Итого, я прочитал 4 страницы (от 71-й), а мой взгляд на мир рухнул – я всегда гонялся за сроком (держа в голове бюджет), а не за тем, чтобы всё было в первую очередь сделано предельно понятно и очевидно..  Осталось теперь переосмыслить и понять как это засунуть в спринты и рекомендации скорее выкатить продукт, чтобы посмотреть, как на него отреагирует рынок.. То есть сейчас у меня в голове явное противоречие.

Ну да ладно, читаю далее и делюсь мыслями и цитатами:

Скотт Мак-Грегорна своих занятиях использует вот такой замечательный тест. Он описывает продукт спомощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и Двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться,что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.

Далее я уткнулся в техническую поддержку – я всегда считал это выгодной услугой, и чем система хуже и запутаннее, тем лучше эту услугу продавать.Если уж у нас эту запутанность купили.. Так же я знал, что существует другой мир, , где поддержку дарят своим клиентам. Я даже знаю представителя этого мира – Microsoft, тратящий на это 800 МЛН долларов в год. И что же я вижу: Спросите любого, кому пришлось поработать в службе технической поддержки любой компании, создающей приложения для настольных компьютеров, и этот человек скажет, что большая часть его времени и усилий уходит на разъяснение вопросов,связанных с файловой системой. Можно сказать, что мой мир рухнул полтора раза…

Ещё любопытный материал про прототипы приведен, но у меня прототипы всегда были лишь рисунками. Так что я не могу оценить всю трагичность ситуации, хотя я слышал про успешные продажи прототипов (сырых или подлатанных), видимо, есть и обратные ситуации. Ценность прототипа в знаниях, приобретенных в процесс е его создания, а совсем не в коде. Мудрый разработчик Фредерик Брукс говорит: «Планируйте выбросить одну версию». Так или иначе, вы ее выбросите, так почему не запланировать это событие ссамого начала?

Читая о прототипах я бы ещё следующее добавил – меньше кнопок! Нужно стремиться к простоте интерфейса.

Какие есть ещё проблемы у программ:

  • Программы забывают (например хотелось бы выделять основные функции, которые я вечно использую)
  • Программы ленивы
  • Программы скупы на информацию (маленьких конверт аутлука рядом с часами говорит что у меня одно новое сообщение или 10?)
  • Программы не гибки
  • Программы возлагают вину на пользователей (уж не мы ли их называем юзверями, осьминогами и проч, а вообще, не мы ли сами зачастую теряли преднастройки каких-либо импортов, если нам приходилось откатываться на шаг назад)
  • Программы не несут отвественности

Ещё одна важная цитата, я думаю, большинство ей и так следует, но на всякий случай:

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

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

К описанному выше ещё следует добавить производительность, отказоустойчивоть и проч. Это я, кстати, уже на 120 стр. Читая дальше, я в очередной раз убедился, что крайне важно и необходимо четко понимать цель создания ПО.

Чтобы ещё мне хотелось бы скопипастить на будущее.. Вот этот часто встречаемый тезис: Знаменитый идеолог UNIX ЭрикРеймонд (Eric Raymond) говорит: «Хорошие программисты знают, что писать, великие -что надо использовать повторно».

Часть 4 я бы вообще рекомендовал прочитать, основное привожу:

Пользователь – должен быть полуреальным персонажем с фотографией (скаченной из интернета), имеющим имя (так же важно понять – для кого мы не проектируем).

Пользователь не должен терять связи с начальным меню (если есть меню видео …. игры), то при переходе на уровень глубже в видео пользователь теряет возможность выбора игр.. Кроме того, если выбирать видео, то надо иметь понимание – что это будут за фильмы, сколько их и тп. А если выбирать фильм, то иметь его описание. Как-то так..

Ещё полезно держать в голове: Цели – не то же самое, что задачи. Цель – это конечное состояние, тогда как задача -переходный процесс, необходимый для достижения цели. Очень важно различать задачи и цели, ведь их так легко спутать. Зачастую программисты ориентируются на задачи, а не на цели. Правда в моей реальности этим должен заниматься в первую очередь аналитик..

Очень любопытно было прочитать про вежливые программы, это на стр 208. Они, например, по умолчанию в результатах поиска выдают то, что я чаще всего выбирал по такому же запросу ранее и тп. Она должна всегда выводить полезную для принятия решения информацию, выводить вменяемые числа, а не сумму $0,00 или $8943702624,23. Или, если я 50 раз говорил, что действительно хочу печатать страницу, и ни разу не передумал, то, может хватит мне выводить это окно..

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

Ну и главное:  проектируйте взаимодействие пользователя и системы заранее – до программирования (пока этим занимаюсь я – аналитик)..

Advertisements
Standard

5 thoughts on “Психбольница в руках пациентов

  1. Pingback: Кем можно считать Алана Купера? | Блог Алексея Киселева

  2. Книга полезная.
    Но к сожалениючасто встречаются системы в которых УЖЕ есть набор стандартных форм , которые можно минимально доработать.
    Т.е. есть набор элементов, например, поле ввода, галочка, раскрывающий список и все.
    Тогда изначально придется делать “медведя”.

  3. И еще часто нет времени на проектирование , хотя это очень полезно.
    Часто со стороны Заказчика поступает предложение, а покажите или вроде того. Т.е. предварительные макеты.
    Поэтому знание приведенных в книге подходов полезно.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s