среда, 18 мая 2011 г.

Психбольница и ты %username%!

Не далее, как в прошлые выходные осилил прочесть "Психбольница в руках пациентов" Алана  Купера. Замечательное чтиво по поводу простоты, сложности и создания именно того, что нужно пользователю.
Чтиво написано простым и понятным языком, и хотя Автор усиленно кроет программистов-пациентов (к коим и я себе причисляю) все равно оставляет неизгладимое впечатление собственного просветления.

Attention! Многа букав!

О чем же оно:
Понял, как жестоко я был не прав всю свою программерскую жизнь=)

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

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

На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:
6) быстро и легко срезает траву;
7) на этом удобно сидеть.
На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.
Читал и плакал! ;)
Плакаль
Уж настолько сильно книга пересекается с тем, что приходилось создавать самому или испытывать на собственной шкуре, как пользователю какого-нибудь доморощенного продукта.

Сам использую и зачастую создаю программное обеспечение с раздражающими интерфейсами (а ведь еще Скотт Беркун писал что раздражать людей - последнее дело).

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

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

Ах, ну разве вам не знакомо: "Давайте еще одну фичу сделаем программисты\верстальщики\еще кто-то сидят без дела!". Так и хочется вот в этом месте передать привет, тем от кого я слышал эти фразы, но сдержусь)

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

Сейчас приходиться и в прошлом приходилось работать с 5-10 летними программными монстрами, которые имеют несколько слоев кода написанных в разных стилях, пару разных слоев абстракции Бд и ТЫСЯЧИ хаков, чтоб поддержать еще и вот эту логику.

Эдакий мясной рубцовый-мутант =)

То же самое относиться и к использованию прототипов в качестве основы для будущего по (ну жалко же выбрасывать!).
Только тут вы сразу начинаете с нежизнеспособного мутанта с 10ю поддерживающими его костылями.
Это кстати можно сказать обратная сторона ажайл-разработки, как только показана первая РАБОЧАЯ версия программы, выкинуть и переписать ее уже будет сложно.

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

Лучший способ сделать программу дружелюбной к пользователя поставить на коробке штамп "USER FRIENDLY".
Зачастую в составляющей программы заинтересовано 3 стороны:
бизнес - "продукт овнер", тот кто заинтересован на ней навариться,
технари - "тестеры, бэкэндеры, фронтэндеры", те кто ее разрабатывают,
проектировщики\юзабелисты, те кто предоставляют голос пользователя.
Так вот для успешного продукта не достаточно только первых и вторых, такой продукт может продаваться и быть монополистом на рынке, но как только придет конкурент который позаботиться о пользователе, так и вашему продукту настанет крышка.


Как пример приводиться 3 компании: Novell, Microsoft & Apple.

  • Novell -  была монополистом на рынке локальных сетей, но как только появилось чуть-менее геморройное  для настройки по и оборудование для локальных сетей она стухла и ушла с доминирующих позиций.
  • Microsoft  - многие плюются на него но пользуются его продуктам, т.к. выбора - нет, но победить его пока не кому.
  • Apple - какое-то время переживала феерический кризис, но из-за ориентации на интерфейс и пользователей выжила благодаря поддержки лояльных пользователей и теперь снова на коне.


Programmers VS Users

Красной линией по всей книге идет черта: позволять программистам проектировать софт - не правильно. 
Так как программист это Homo logicus, а не обычный Homo sapiens.
Мы - программисты отличаемся от обычных людей по 4 важным пунктам:
  • Программисты пожертвуют простотой ради контроля. 
    • Мы предпочтем более но сложную, но понятную систему магическому "черному" ящику.
    • Для хомо логикус контроль - цель, тогда как сложность - просто цена, которую они готовы платить за достижение цели.
  • Обменяют успех на понимание.
    • Хомо логикус не может устоять перед тягой познания - он просто обязав узнать, как работают вещи. Хомо сапиенс же, напротив, стремится к достижению успеха.
    • Программистам знакомо желание добиться успеха, но они часто принимают провал как цену, уплаченную за понимание.
  • Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. 
    • Нужно обработать и этот возможный вариант! (с) Я, более 1000 раз за всю свою жизнь
  • И, наконец, ведут себя грубо и прямолинейно, как быки.
      Типичный программист

    • Мы смотрим свысока на тех, кто не способен разобраться в этом не совсем интуитивном функционале: 
      • Ну что за идиот! В мануале ж все написано!
    • Кто смотрел Футураму ?) 
      • Кому (из программистов) НЕ нравиться Бендер ?) 
      • Всем нравиться! 
      • Дык Бендер это сферический программист в вакууме!
      • Логичный (робот же), приямолинейный (честый =)) и грубый =)
Подпишусь под каждым пунктом!


Итого: mustread!

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

Ладно пожалуй хватит пересказывать книгу, должна же быть у вас мотивация прочитать ее. В добавок о том, о чем я уже рассказал в ней раскрываются еще такие темы, как:
  • культура программирования 
  • повторное использование кода, и почему это плохо
  • как мотивировать разработчиков на создание простых и понятных для людей, но сложных в реализации интерфейсов.
  • почему программист не может быть хорошим проектировщиком (подсказка: противоречие интересов, см. пункт выше)
  • как сделать меньше, но лучше
  • личные и корпоративные цели пользователей при работе с программой
  • о тяжелой судьбе проектировщиков и факторе "это ж очевидно"
  • о юзабелити-тестировании, итерациях, документации, общем словаре и всех-всех-всех ... 
А так же главные фичи книги, средство избавление от всех болезней, ответ на главный вопрос жизни, вселенной и всего такого, работающие практики: 
Целе-ориентированное проектирование и Персоны
Если вы вы слышали краем уха про agile-проектирование продуктов для пользователя, так вот все это копи-паста с ЭТОЙ книги. 

Удачного чтения и спасибо за рыбу!

Комментариев нет:

Отправить комментарий