БИБЛИОТЕКА CАЙТОСТРОИТЕЛЬСТВА

новости, статьи, обзоры по веб-дизайну и графике, разработке, оптимизации и продвижению веб-сайтов

Про разработчиков, постановщиков и телепатию

Я понял - это намек, я все ловлю на лету,
но непонятно, что конкретно ты имела в виду?
Вот я не понял.
НС

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

К примеру есть система, в которой нужно что-то изменить. У тебя есть видение существующей системы (набор исходных данных), видение новой системы (цель, к чему стремиться), и есть метод решения. Ты даёшь постороннему человеку описание своего видения обоих систем и передаёшь метод решения, в расчёте на то, что это описание у него трансформируется в его видение, полностью соответствующее твоему.
На самом деле так бывает редко (а в деталях, так и никогда), потому что описание - вербально, оно не передаст ни образы (запахи, чувства), ни опыта, который позволит увидеть эту систему живой, ни сути, поэтому то видение, который человек у себя создаст по твоему описанию, будет са-а-авсем другим. При этом в соответствии с теорией относительности всего по отношению к всему очень может возникнуть такая ситуация, что даже при наличии разных видений у постановщика и его исполнителя результат преобразования исходной системы в требуемую получается очень даже удовлетворительный. Только что-то редко так бывает.

Зато часто бывает по-другому. Разумеется, прежде, чем позволить исполнителю начать процесс преобразования, постановщик может убедиться в том, что задача понята правильно. Если нет, то повторять (изменять, дополнять) процесс постановки до тех пор, пока не убедится в том, что его понимают правильно В ДОСТАТОЧНОЙ МЕРЕ для того, чтобы начать работу. Это довольно забавный и трогательный этап, особенно, если смотришь на него со стороны, не являешься ни постановщиком, ни исполнителем. Эмоции, повышенные тона, напряжение возрастает… Почему?

1. Возможно, постановщик даун. Не может словами выразить, что же и с чем нужно делать.

1. а) Нет картины исходных данных. Встречается довольно часто: постановщик с заказчиками, аналитиками и прочими ответственными людьми обсасывает проблему, можно ли её решить, если можно - то как, и почему так, и в результате у него накапливается изрядное количество мелочей, каждая из которых незначительна сама по себе, но незаменима для построения живой системы. Часть этих мелочей через некоторое время становится “чем-то очевидным” для него, и он начинает полагать, что опираясь только на здравый смысл и обычный житейский опыт каждый первый (разработчик) и так поймёт их необходимость в системе. Т.е. либо не считает нужным передавать исполнителю информацию обо всех этих мелочах, либо ему даже не приходит в голову, что об этом тоже нужно говорить. Исполнитель недополучает исходные данные, соответственно, не понимает, что от него хотят.
2. б) Не даётся полное описание требуемого результата работы, цели. Тоже много разных причин, одна из типичных - конечному разработчику это не нужно. К примеру, потому, что это, на самом деле, корпоративная тайна. Поэтому изыскиваются такие слова и обороты, которые скрывают реальную цель работы, отрисовывая некую псевдо- цель, подобную исходной настолько, что исполнитель, сам того не зная, как раз и сделает то, что нужно заказчику. Но нарисовать мнимую цель, действительно подобную реальной - это, знаете ли, великое искусство, не каждому дано, и, как следствие, редко срабатывает так, как ожидалось.
   -
   Ещё одна часто замечаемая причина - отсутствие понимания цели у самого постановщика. Т.е как бы он предполагает, что понимание есть, но именно в процессе постановки непосредственному разработчику, уже на этапе повышенных тонов и обид, обвинений во взаимной тупости выясняет (-ся), что — да, разработчик указывает ему на, к примеру, технические несоответствия, и в относительно благополучных командах это заканчивается перекраиванием задачи, в соответствии с другим уже пониманием цели. А бывает и такая причина: постановщик действительно не понимает чётко что нужно сделать и перекладывает ответственность на разработчика, расчитывая на его опыт, на то, что он, такой умненький, сам сведёт концы с концами и догадается, что же нужно было сделать.
3. с) Методы решения не вписываются в процесс преобразования одной системы в другую. Конечно, чаще всего бывает, что ведущими будут причины а) и б), но при этом постановщик вообще не озабочен тем, чтобы дать полное описание исходной системы и цели, упор же делается на метод решения, который как будто бы подробно описывается, а исполнитель всё равно не понимает, что же ему нужно делать и, главное, зачем.

2. Возможно, разработчик даун. Разумеется, приятно работать со звёздами, которые всё схватывают на лету, предугадывают следующую фразу и даже при небезупречной постановке умудряются сделать работу лучше ожидаемого. Средний разработчик среднее количество рабочего времени среднего уровня сложности постановки воспринимает на среднем уровне достоверности. Что означает, что даже при подробной и вполне качественной озвучке 1.а), 1.б) и 1.с) он всё равно будет “тупить”. Да по каким угодно причинам. Сонный после безсонной ночи (ребёнок плакал, девушка требовала внимания, у друга день рождения) с временно пониженной способностью воспринимать информацию. Недостаточно квалификации у разработчика (он ли не “семи пядей”, или задача на самом деле сверх традиционного уровня сложности для существующей команды). Нет цели понять (скучно ему, не зажигает задача, приступ мозговой лени, слизни одолели).

Конечно, бывают ситуации, когда именно повышенные тона и эмоции либо “пробуждают” разработчика, либо открывают глаза постановщику на то, что он вбивает в несчастного непродуманную глупость. Но как же хочется всегда обходиться без напряжения, как же хочется, чтобы между постановщиком и разработчиком были более адекватные каналы передачи информации. Ну да. Напрямую, в мозг. Или каким-нибудь ещё альтернативным методом.

По поводу альтернативных методов можно с примером. И в самом деле, как выше и было написано, очень много для понимания задачи значит опыт (и жизненный, куда же без него), и по специальности. К примеру, ставится задача талантливому, умному и сообразительному дизайнеру, у которого вовсе не было никаких приступов тупости. И изрядный (можно уже сказать так на сегодняшний момент) опыт рисования интерфейсов для веб-сайтов. Но не особенно значительный опыт рисования интерфейсов для веб-сайтов с динамическим контентом - так, всё больше рекламные сайты, один раз сверстал почти открыточный макет, так он и живёт. И вот один за другим приходят проекты, где дизайн нужен для динамического контента, начиная от произвольного (для разных групп пользователей) количества элементов меню и субменю и заканчивая текстами, которые добавляют пользователи. И раз за разом дизайнер рисует эскизы, умиляюще красивые, такие, какие с первого раза нравятся заказчику, но, мягко говоря, не особо удобные для динамики. Первые проекты приходилось контролировать и переделывать оформление тех блоков, которые при всей их красоте были не особо уместны для конкретной задачи. Потом были разговоры о том, что надо, надо, надо обучиться вёрстке, что пока не будет пережитого лично тобой опыта вёрстки, внедрения твоего дизайна в живой проект, пока не увидишь причины, почему так а не иначе, на словах не получается объяснить, в чём разница “презентационного-рекламного дизайна” от “дизайна для динамического контента”, и желающих помочь, от тимлидера до остальных верстальщиков вроде хватает, и книг, и работы, но… то одно, то другое, то времени нет, то жених ждёт, то как-то прям сегодня не хочется…

На последнем проекте, уже скорее с целью эксперимента, исправив в эскизе ряд совсем уж явных ошибочек (к примере, в профайле юзера должен был показываться его мейл, но этот блок был оформлен в размере по ширине соответствующем первому попавшемуся адресу. Предложила в этот блок на эскизе поставить другой, реальный, взятый из корпоративной переписки, с в три раза большим количеством символов и объяснить поведение этого блока - будет он становиться шире, в зависимости от размера мейла пользователя, или будет мейл частично скрываться, чтобы сохранить красоту начального дизайна), объяснив очередной раз про динамический контент и про то, какие элементы будут куда вытаскиваться из базы, ушла в отпуск. Эскиз приняли, порезали, внедрили. только вот блок, следующий после дескрипшина, визуально панелечкой выровнян по вертикали с большой заметной кнопкой. И это, разумеется, очень важно для дизайна. И, разумеется, маркетологи, данные которых выводятся на этой странице, гады такие, вбивают дескрипшины разного размера. А нужно (по дизайну) чтобы текста хватало на четыре строки. А они, лентяи, пишут пять слов, вмещающихся в одну неполную. И что делать с несчастным блоком, таким красивым, который следует за дескрипшином, не понятно. То ли продолжать выравнивать по большой кнопке (тогда на кратких дескрипшинах будет дырка в три текстовые строки), либо отпустить размер высоты дескрипшина, тогда красивый блок не будет выровнян по правой кнопке, получается визуальная кривость.

Вот честно признаюсь, можно было изначально на этапе эскиза очередной раз указать на “великое будущее” этого блока, видно было изначально. Но тогда сколько ещё проектов, сколько ещё элементов в эскизах придётся под диктовку переделывать, сколько раз повторить практически одну и ту же лекцию про динамический контент? В таких ситуациях лучше, если дизайнер уже сам переживёт эту проблему, запомнит её и не будет смешно настаивать, чтобы “пользователи вводили четыре строки текста в этом дескрипшине, ибо это важно для дизайна” (что по любому невозможно будет заставить сделать тех маркетологов, которые ещё и не наши, а заатлантические). Будет опыт. Будет на пол повторяющейся лекции меньше. А всё потому, что я не могу передать часть своего видения системы, включающего опыт проектирования-рисования-вёрстки-интерграции макетов для динамического контента, напрямую в мозг моему хорошему, талантливому дизайнеру, который рисует эскизы для наших проектов.

• Оставить комментарий к заметке
• Другие заметки по теме в блоге

ИНТЕРЕСНО ПОЧИТАТЬ:

:: Форма поиска: обязательные по правилу "или" поля
Есть форма поиска (людей) в очень большой базе данных. Представлена в двух вариантах - дефолтовый (easy) и advanced. Но уже с оформлением дефолтовой, простой формы возникли траблы - она не только интуитивно не понятна, она, пока что, всем своим видом вводит пользователя в заблуждение......>>

:: Офисное дизайнерское: закрытая система
Как-то не особо у нас продвигаются идеи по теме обучения сотрудников. Ситуация напоминает вязкое и тягучее болото - вроде все понимают, что дело нужное, но как только речь заходит о конкретных мероприятиях, даже отпроситься с работы на какую-нибудь конференцию, семинар или тренинг невозможно....>>

:: Офисное дизайнерское: оглядываясь назад
Нечёткие постановки - хроническая беда руководства и тимлидеров. Знаю, что не хорошо и непедагогично спорить с начальством (и уж тем более в присутствии моих уже подчинённых), но уж больно часто задалбывают нечёткими, двусмысленными или даже противоречивыми постановками задач. Как тут обойтись без повышенных тонов?...>>

:: Взаимодействие систем: споры и дискуссии
Как хорошо всё-таки, что все люди разные. Как тяжело, что все такие разные. Как часто бывает, что мы говорим об одном и том же разными словами и не слышим друг друга. Как часто бывает так, что мы говорим о настолько разных вещах, что не можем слышать друг друга…...>>

:: Про этап тестирования на прототипах
Разбираем-изучаем с утра по-раньше корпоративную почту; один из новых программеров, работающих на новом же проекте, удивлённо замечает: странно это, говорит, обычно когда разрабатывается новый сервис, люди сначала думают, а потом делают....>>

:: Выныривая ненадолго:
Интересное наблюдение: за последнюю неделю-полторы пришло изрядно адресных, не спамерских писем от разных хедхантеров с предложениями поработать и "вообще", и конкретно; к чему бы это? Подозрительно....>>

:: Особенности проектирования интерфейсов командами, разделёнными океаном
У нас продолжается наработка сурового опыта разработки ПО и сервисов разделёнными между двумя континентами командами. Оказывается, наиболее весёлый аттракцион происходит в том случае, когда идёт этап проектирования нового сервиса, так же разделёнными командами. ...>>

:: Почему продолжают появляться такие ужасные веб-сайты
Пару дней назад искали с хорошим знакомым информацию об одном харьковском пригороде; нашли мало чего, даже гуглмапс выдал больше информации, чем веб-сайты по запросу....>>

:: Дизайнерское: о шрифтах и их оформлении
Вчера анализировали некоторые присланные за последнее время разными дизайнерами эскизы на веб-сайты; только и удивлялись, как много общих ошибок, связанных, к примеру, со шрифтами, их выбором, оформлением, размещением. ...>>

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

:: Дизайнерское: интерфейсы в исходниках
Когда я писала заметку "Офисное дизайнерское - несколько наших agreement" - тогда большая часть договорённостей из списка была на стадии обсуждения и внедрения....>>

:: И ещё про дизайн
Английское слово design первоначально означало замысел, проект, расчет, чертеж, узор. С течением времени к этому добавились значения: креатив, искусство композиции. Корни дизайна - в искусстве и в инженерии....>>

:: Web Standards 2008: Three Circles of Hell
...>>

:: Замена текста изображением шрифта
Facelift Image Replacement (or FLIR, произносится как fleer) - Java-скрипт, динамически генерирующий изображение букв с использованием заданного ttf шрифта и заменяющий этим изображением текст....>>

:: Скрипт: hover-эффект для любого элемента в Internet Explorer 6
В свете предложенных дополнительных вариантов скрипта, так сказать, на все случаи жизни, в комментариях к статье “Простейший скрипт для реализации hover-эффекта для любого элемента в Internet Explorer 6“, а также развернувшихся там же баталий, я решил реинкарнировать данную статью, описав эти варианты, и показать их живые примеры....>>

:: WordPress плагин jQuery Comment Links
Плагин “jQuery Comment Links” заменяет ссылку автора комментария и (или) ссылки в тексте комментария на jQuery-ссылки, т.е. по сути превращает все внешние ссылки в комментариях во внутренние....>>

:: OpenID и Simple Registration Extension
OpenID был разработал Брэдом Фицпатриком, одним из создателей LiveJournal. Этот стандарт изначально проектировался, как независимый от провайдера метод аутентификации....>>

:: Статьи: 10 необычных метафор в дизайне иконок
Для одного и того же действия или объекта можно нарисовать совершенно разные иконки. Варьировать можно всё: стиль, цвет, перспективу и даже метафору. На мой взгляд, последнее — самое ценное в дизайне иконок — концентрированный смысл. ...>>

:: Чего не хватает Microsoft Blend: взгляд проектировщика взаимодействия
Технология XAML/Blend обещает дать нам, проектировщикам взаимодействия более высокий контроль над результатом их работы. Это здорово, потому что позволяет нам добиваться того, чтобы конечный продукт имел интерфейс, максимально приближенный к задуманному. Однако данная технология меняет привычный для проектировщиков способ работы, и требует от них новых навыков....>>

:: Internet Explorer и z-index
ИЕ воспринимает z-index не совсем так, как все остальные браузеры. Это поведение настолько часто встречается в моей жизни, что я решил о нём написать целый пост. Меня часто просят поправить ошибки в верстке. Так вот эта — входит в топ-5....>>

:: Альфа-каналы в PNG-8
Проблема полупрозрачных картинок медленно умирает вместе с IE5-6, но, тем не менее будет актуальна для популярных сайтов еще несколько лет. Вдобавок, дальше станет понятно, почему процентная прозрачность для PNG-8 будет важна и без ИЕ....>>

• Предыдущий выпуск рассылки - #233
• Подпишитесь на RSS

::: рассылку ведет:     Татьяна Вукс 2009 :::