всё ещё смешнее — я пост Павловой прочитал, после того как вы мне его за пивом после прошлого uxspb порекомендовали (я — человек в синей рубашке с всклокоченными волосами).
на Хабре довольно трудно разглядеть, кто автор топика :)
К сожалению это решение не универсально — встречаются и системы, где нужно сначала набрать запрос, а потом уже активировать поиск (не обязательно кнопкой, можно и без неё — Enter'ом). Потом, уже перейдя к результатам поиска и корректируя запрос можно применять и autosuggest. Но на первом шаге — нет. Поиск — очень доступная точка выхода с текущей страницы, а это не всегда уместно и полезно.
1. принято, согласен.
2. всё так. Но нужно помнить, что не всегда мы можем понять язык заказчика. Например в примере выше речь о том, что есть область знаний, которая нужна в одном отдельном случае и вникать в её язык нет никакой необходимости >> проще более детально ввести заказчика в процесс и построить результат совместными усилиями. (Конечно, если есть такая возможность.)
Так понятнее, спасибо. Но всё-же:
1. про инициатора — в оригинале статьи автор во всех случаях говорит о «стэкхолдерах», а не «кастомерах» — но, поскольку у нас региональная специфика, я перевёл их как «закачиков» и «представителей заказчика». Таким образом, автор исходит из того, что вопрос о том, что мы общаемся не с секретаршей, уже решен. Как решить этот вопрос — отдельная тема про которую можно писать много и долго.
2. Чтобы сотрудничество было более эффективным всё же стоит сделать так, чтобы заказчик понимал процесс хотя бы в общих чертах. Или хотя бы понимал, зачем нужны те или иные части процесса.
1. Я, видимо, довольно удачливый парень — мне были интересны практически все проекты над которыми доводилось работать. Интересны, зачастую, иначе, чем они интересны заказчику — где то меня интересовал опыт выработки ui, соответствующего идентификации бренда, где-то — детальная проработка структуры и названий разделов, подразделов, групп товаров и их компоновки — т.е. мне обычно удавалось подойти к делу с отношением не «сделал, слил, поднял бабла» (очень за себя рад).
Но при этом я понимаю, что часто приходится видеть на стороне разработчика людей, которым, наоборот, интереснее сделать больше проектов, сделав меньше работы — грусть, печаль.
Данная статья, в частности, может помочь и им достичь в своих проектах большего качества, сэкономив время.
2. По поводу заказчика, который «в своём деле профи, а в других нет» — вот хочу на днях начать эксперимент на одном своём приятеле (он специалист в довольно узкой и труднотранслируемой области) и с задачей, которую он попросил меня решить мне, вроде как, не справиться без нескольких месяцев вникания в его область знаний. Чтобы сэкономить наше с ним время хочу попробовать другой вариант — объяснить ему основы ui, чтобы мы могли как минимум говорить на одном языке >> решить задачу не за год и без адского погружения.
В процессе, возможно, напишу как оно, самому интересно.
не зависимо от качества работы, случается, что клиенты пишут подобные комментарии. и дело не в том, что клиенты адовы — а в том, что они часто просто не знают, что бы такое сказать в комментариях + преувеличивают роль своего субъективного восприятия.
приведённый автором статьи пример говорит о том, что эта проблема существует не только у нас, но и у западных компаний-разработчиков. (Вряд ли автор стал бы писать об этом не будь оно наболевшим.)
на Хабре довольно трудно разглядеть, кто автор топика :)
рекомендую — olgapavlova.livejournal.com/267248.html
2. всё так. Но нужно помнить, что не всегда мы можем понять язык заказчика. Например в примере выше речь о том, что есть область знаний, которая нужна в одном отдельном случае и вникать в её язык нет никакой необходимости >> проще более детально ввести заказчика в процесс и построить результат совместными усилиями. (Конечно, если есть такая возможность.)
1. про инициатора — в оригинале статьи автор во всех случаях говорит о «стэкхолдерах», а не «кастомерах» — но, поскольку у нас региональная специфика, я перевёл их как «закачиков» и «представителей заказчика». Таким образом, автор исходит из того, что вопрос о том, что мы общаемся не с секретаршей, уже решен. Как решить этот вопрос — отдельная тема про которую можно писать много и долго.
2. Чтобы сотрудничество было более эффективным всё же стоит сделать так, чтобы заказчик понимал процесс хотя бы в общих чертах. Или хотя бы понимал, зачем нужны те или иные части процесса.
Но при этом я понимаю, что часто приходится видеть на стороне разработчика людей, которым, наоборот, интереснее сделать больше проектов, сделав меньше работы — грусть, печаль.
Данная статья, в частности, может помочь и им достичь в своих проектах большего качества, сэкономив время.
2. По поводу заказчика, который «в своём деле профи, а в других нет» — вот хочу на днях начать эксперимент на одном своём приятеле (он специалист в довольно узкой и труднотранслируемой области) и с задачей, которую он попросил меня решить мне, вроде как, не справиться без нескольких месяцев вникания в его область знаний. Чтобы сэкономить наше с ним время хочу попробовать другой вариант — объяснить ему основы ui, чтобы мы могли как минимум говорить на одном языке >> решить задачу не за год и без адского погружения.
В процессе, возможно, напишу как оно, самому интересно.
приведённый автором статьи пример говорит о том, что эта проблема существует не только у нас, но и у западных компаний-разработчиков. (Вряд ли автор стал бы писать об этом не будь оно наболевшим.)