Не далее, как в прошлые выходные осилил прочесть "Психбольница в руках пациентов" Алана Купера. Замечательное чтиво по поводу простоты, сложности и создания именно того, что нужно пользователю.
Чтиво написано простым и понятным языком, и хотя Автор усиленно кроет программистов-пациентов (к коим и я себе причисляю) все равно оставляет неизгладимое впечатление собственного просветления.
Attention! Многа букав!
О чем же оно:
Понял, как жестоко я был не прав всю свою программерскую жизнь=)
Вкратце книгу можно бы изложить так : за забором функций и ограничения реализации мы теряем из виду конечную цель производства самого продукта.
Для подтверждения хочется привести пример из книги:
Уж настолько сильно книга пересекается с тем, что приходилось создавать самому или испытывать на собственной шкуре, как пользователю какого-нибудь доморощенного продукта.
Сам использую и зачастую создаю программное обеспечение с раздражающими интерфейсами (а ведь еще Скотт Беркун писал что раздражать людей - последнее дело).
Сам использую ПО, которое презираю - но приходиться терпеть, но т.к. я его использую для работы, смиряюсь и думаю, что так и должно быть и, что оно должно быть таким неудобным и мерзким.
Помимо казалось бы банальные советов не использовать неудобное ПО, которое вам не нравиться. Но его так же не следует Создавать, т.к. в итоге и оно выйдет боком, опять же процитирую:
Ах, ну разве вам не знакомо: "Давайте еще одну фичу сделаем программисты\верстальщики\еще кто-то сидят без дела!". Так и хочется вот в этом месте передать привет, тем от кого я слышал эти фразы, но сдержусь)
Не только об интерфейсах:
Вот с чего бы юзабилисту рассуждать об архитектуре и дизайне ПО ? Ведь интерфейс - он от бизнес логики MVC отделен или еще как. Но нет и тему рефакторинга и переписывания заново затрагивают:
Читал и чувствовал боль и искреннее понимание.
Сейчас приходиться и в прошлом приходилось работать с 5-10 летними программными монстрами, которые имеют несколько слоев кода написанных в разных стилях, пару разных слоев абстракции Бд и ТЫСЯЧИ хаков, чтоб поддержать еще и вот эту логику.
Эдакий мясной рубцовый-мутант =)
То же самое относиться и к использованию прототипов в качестве основы для будущего по (ну жалко же выбрасывать!).
Только тут вы сразу начинаете с нежизнеспособного мутанта с 10ю поддерживающими его костылями.
Это кстати можно сказать обратная сторона ажайл-разработки, как только показана первая РАБОЧАЯ версия программы, выкинуть и переписать ее уже будет сложно.
Так что :
Уж больно они точны и хороши.
Лучший способ сделать программу дружелюбной к пользователя поставить на коробке штамп "USER FRIENDLY".
Зачастую в составляющей программы заинтересовано 3 стороны:
бизнес - "продукт овнер", тот кто заинтересован на ней навариться,
технари - "тестеры, бэкэндеры, фронтэндеры", те кто ее разрабатывают,
проектировщики\юзабелисты, те кто предоставляют голос пользователя.
Так вот для успешного продукта не достаточно только первых и вторых, такой продукт может продаваться и быть монополистом на рынке, но как только придет конкурент который позаботиться о пользователе, так и вашему продукту настанет крышка.
Как пример приводиться 3 компании: Novell, Microsoft & Apple.
Programmers VS Users
Красной линией по всей книге идет черта: позволять программистам проектировать софт - не правильно.
Так как программист это Homo logicus, а не обычный Homo sapiens.
Чтиво написано простым и понятным языком, и хотя Автор усиленно кроет программистов-пациентов (к коим и я себе причисляю) все равно оставляет неизгладимое впечатление собственного просветления.
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 важным пунктам:
Итого: mustread!
- Программисты пожертвуют простотой ради контроля.
- Мы предпочтем более но сложную, но понятную систему магическому "черному" ящику.
- Для хомо логикус контроль - цель, тогда как сложность - просто цена, которую они готовы платить за достижение цели.
- Обменяют успех на понимание.
- Хомо логикус не может устоять перед тягой познания - он просто обязав узнать, как работают вещи. Хомо сапиенс же, напротив, стремится к достижению успеха.
- Программистам знакомо желание добиться успеха, но они часто принимают провал как цену, уплаченную за понимание.
- Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных.
- Нужно обработать и этот возможный вариант! (с) Я, более 1000 раз за всю свою жизнь
- И, наконец, ведут себя грубо и прямолинейно, как быки.
Типичный программист
- Мы смотрим свысока на тех, кто не способен разобраться в этом не совсем интуитивном функционале:
- Ну что за идиот! В мануале ж все написано!
- Кто смотрел Футураму ?)
- Кому (из программистов) НЕ нравиться Бендер ?)
- Всем нравиться!
- Дык Бендер это сферический программист в вакууме!
- Логичный (робот же), приямолинейный (честый =)) и грубый =)
Итого: mustread!
Чтение такой не совсем профильной литературы раскрывает чакры и мозг в нужную сторону и помогает взглянуть на то, чем ты занимаешься с другой стороны.
Ладно пожалуй хватит пересказывать книгу, должна же быть у вас мотивация прочитать ее. В добавок о том, о чем я уже рассказал в ней раскрываются еще такие темы, как:
- культура программирования
- повторное использование кода, и почему это плохо
- как мотивировать разработчиков на создание простых и понятных для людей, но сложных в реализации интерфейсов.
- почему программист не может быть хорошим проектировщиком (подсказка: противоречие интересов, см. пункт выше)
- как сделать меньше, но лучше
- личные и корпоративные цели пользователей при работе с программой
- о тяжелой судьбе проектировщиков и факторе "это ж очевидно"
- о юзабелити-тестировании, итерациях, документации, общем словаре и всех-всех-всех ...
Целе-ориентированное проектирование и Персоны
Если вы вы слышали краем уха про agile-проектирование продуктов для пользователя, так вот все это копи-паста с ЭТОЙ книги.
Удачного чтения и спасибо за рыбу!
Комментариев нет:
Отправить комментарий