Pull to refresh

Comments 13

ИМХ0
По всему тексту чувствуется одна мысль «Ваша задача — не сделать все по технологиям. Ваша задача — сделать.»
а что имеется в виду под «Ваша задача — не сделать все по технологиям. Ваша задача — сделать.»?
Вот смотрите. Вы когда начинаете что-то делать, то представляете себе какие-то цели. И в зависимости от этих целей и результат получается разный. Если вы, например, занимаетесь нудными для вас вещами, то и скорее всего он будет сделан средним образом. Это не плохо или хорошо. Это результат. Потому что в Вашей голове скорее всего будет одна мысль «избавиться побыстрее». Как бы Вы не маскировали эту мысль.
Но вот если Вашей целью будет что-то другое, например, «чудо работа», то и результат будет другим. Но и времени он может затратить больше. Разница видна, просто подставьте любые дела из своей работы.
Т.е. есть цели, и у них соответствующие результаты.

По моему мнению, изначальный плохой вариант ведения дел складывался следующим образом:
Руководитель со стороны исполнителя хочет сделать хорошую вещь. Но, не просто сделать хорошую вещь. Он хочет работать с профессионалами. Чтобы во всех смыслах можно было сказать, что он как руководитель — профессионал. Ничего плохого в желаниях нет.
Соответственно, когда он рассматривает ситуацию, то видет, что заказчик — профессионал (так это или не так — не важно). И ждет от него профессионализма. Но подвох в том, что заказчик может и профи в своем деле. Но, он может быть слепым котенком в других областях. И не факт, что он будет это показывать (пример, «я же профи!»). А так же не факт, что он будет вообще понимать Вас, но будет желать показать это. Поэтому информация будет неполной, искаженной и возможно вообще неверной на корню.

Поэтому получится следующая ситуация:
Вроде как все профи. А хрень на выходе:)

А вот если Ваша задача не содержит дополнительных слов и определений. Т.е. например, выкопать яму 3 на 3. Это значит выкопать яму 3 на 3. А не «выкопать яму 3 на 3 с музыкой в стиле регги на фоне растяжного билборда с изображением Ямайки».

А вот если бы задача изначальна была проще «Хорошо сделать свою работу, и в срок». Уже в этой постановке нет ни единого требования к заказчику. Вы вообще не расчитываете на его уровень квалификации в Вашей области. Это требование Вас к Вам же.
Соответственно, с такой идеей Вы бы начали думать немного другой логикой.
Пример построения:
«Я хочу сделать хорошо и в срок» -> «мне надо убедиться, что потом не будет больших проблем, и заказчик не будет бегать и орать» -> «верна ли логика сейчас?» -> «заказчик несет хрень про шрифты» -> «Получу ка я у него письменное подтверждение по поводу того, что логика работы верная» -> Заказчик: «Ответственность! Емоё. Могут ведь потом дернуть. Посмотрю ка я логику. О! Вот тут не совсем верно. А тут круто!» -> «Ага. Надо изменить то-то и то-то»…

И результат будет другим. Потому что Вы просто хотите сделать.
1. Я, видимо, довольно удачливый парень — мне были интересны практически все проекты над которыми доводилось работать. Интересны, зачастую, иначе, чем они интересны заказчику — где то меня интересовал опыт выработки ui, соответствующего идентификации бренда, где-то — детальная проработка структуры и названий разделов, подразделов, групп товаров и их компоновки — т.е. мне обычно удавалось подойти к делу с отношением не «сделал, слил, поднял бабла» (очень за себя рад).
Но при этом я понимаю, что часто приходится видеть на стороне разработчика людей, которым, наоборот, интереснее сделать больше проектов, сделав меньше работы — грусть, печаль.

Данная статья, в частности, может помочь и им достичь в своих проектах большего качества, сэкономив время.

2. По поводу заказчика, который «в своём деле профи, а в других нет» — вот хочу на днях начать эксперимент на одном своём приятеле (он специалист в довольно узкой и труднотранслируемой области) и с задачей, которую он попросил меня решить мне, вроде как, не справиться без нескольких месяцев вникания в его область знаний. Чтобы сэкономить наше с ним время хочу попробовать другой вариант — объяснить ему основы ui, чтобы мы могли как минимум говорить на одном языке >> решить задачу не за год и без адского погружения.

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

«Сделал, слил, поднял бабла». Хочу Вас расстроить. Вы делаете тоже самое. Вы получаете работу. Вы ее делаете. Заливаете и получаете деньги. Это просто суть. Другое дело, что Вы добавляете к этому. Вы добавляете желание «в этом разобраться и сделать отлично».

Кстати, в Ваших же примерах, Вы тоже делаете по принципу «Ваша задача — сделать».
Логика та же самая. Просто Вы подходите к вопросам «хорошо и сроки» с другой стороны.
Вы не требуете от заказчика чего-то. Каких-то знаний или пониманий процесса разработки. Вы ищите другие способы решения задачи.
Так понятнее, спасибо. Но всё-же:
1. про инициатора — в оригинале статьи автор во всех случаях говорит о «стэкхолдерах», а не «кастомерах» — но, поскольку у нас региональная специфика, я перевёл их как «закачиков» и «представителей заказчика». Таким образом, автор исходит из того, что вопрос о том, что мы общаемся не с секретаршей, уже решен. Как решить этот вопрос — отдельная тема про которую можно писать много и долго.
2. Чтобы сотрудничество было более эффективным всё же стоит сделать так, чтобы заказчик понимал процесс хотя бы в общих чертах. Или хотя бы понимал, зачем нужны те или иные части процесса.
Представители заказчика и инициатор — это легко могут быть разные люди. Поэтому бедную секретаршу никто и не вспоминал. У нее совершенно другие задачи, правда, если Вы не автоматизируете ее работу.

«Чтобы сотрудничество было более эффективным»
Так Вы и пишите о том, что не ждете от заказчика понимания Вашей работы. Соответственно, Вы его сами обучаете, чтобы сделать свою работу «хорошо и в срок». Потому что предвидите ряд возникающих проблем в будущем, которые легко возникнут, если Вы не поймете друг друга на начальных этапах. Хотя достигнуть этого можно по разному. Не обязательно окунаться в обучение. Например, можно самому понять язык заказчика, и общаться на нем.
1. принято, согласен.
2. всё так. Но нужно помнить, что не всегда мы можем понять язык заказчика. Например в примере выше речь о том, что есть область знаний, которая нужна в одном отдельном случае и вникать в её язык нет никакой необходимости >> проще более детально ввести заказчика в процесс и построить результат совместными усилиями. (Конечно, если есть такая возможность.)
«1. принято, согласен.»
Простите, не удержусь. Ну ооооооочень похоже на «Одобрено РОСКОМСТАТ». :)
З.Ы. Без обид.

«2. всё так. Но нужно помнить»
Я не спорю. А привожу примеры. Просто хочу показать, что Вы делаете «хорошо и в срок», но со своими рюшечками.

А статья на самом деле приводит одно из следствий. Вернее один из примеров, который возник из ситуации и целей. Просто данная ситуация — частая ошибка.
Все происходит из конкретной ситуации и поставленных целей. В случае, если бы представители заказчика были бы «против» (по своим причинам), такой подход бы не подошел. Потому что Вы бы устали искать все возможные подробности. Потому что расчитываете на то, что представители «заинтересованы». А они будут как «террорист на допросе», по лишним поводам молчать. И тут уже надо вести другую игру.
Но суть все равно одна и таже. Вы оцениваете ситуацию и ставите цели. И в зависимости от этого тандема действуете.

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

Я просто хочу, чтобы Вы задумались;)
Согласен с автором, как правило, большинство заказчиков имея некую бизнес идею, не до конца понимают, что же они действительно хотят получить в сети. Поэтому приходится их поступательно, за руку, вести от формализации бизнес-процессов до шрифтов на сайте.
Если ui и ux не готовы взять на себя данные функции, проект не получится.
Пункт 4 мне кажется слишком странным… разве у заказчика должны быть такого рода комментарии в принципе? (Как например, “Слишком большое количество цветов мешает воспринимать информацию.”).
ИМХО задачей проектировщиков и дизайнеров является то, чтобы подобный комментариев не было. Они же профессионалы своего дела, а не клиент. Они должны видеть все подобные недостатки.
не зависимо от качества работы, случается, что клиенты пишут подобные комментарии. и дело не в том, что клиенты адовы — а в том, что они часто просто не знают, что бы такое сказать в комментариях + преувеличивают роль своего субъективного восприятия.
приведённый автором статьи пример говорит о том, что эта проблема существует не только у нас, но и у западных компаний-разработчиков. (Вряд ли автор стал бы писать об этом не будь оно наболевшим.)
Sign up to leave a comment.

Articles