Original post: Блог NunDesign. Comment: this.

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

Original post: Блог NunDesign. Comment: this.

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

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

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

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

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

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

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

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

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

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

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

Original post: Блог NunDesign. Comment: this.

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

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

Очередной семинар, на который авторитарно не отпустили (как же как же, целый рабочий день!) - “Интернет-реклама: итоги и перспективы…” от Яндекса, на который давно зарегистрировалась и собиралась. Запороли идею с формулировкой “зачем дизайнеру (и программисту) какой-то там маркетинг, какая-то там реклама?” Ну да, действительно. Зачем разработчикам, очередной раз ваяющим очередной маркетинговый тулз, разбираться в интернет маркетинге? Вдруг разберутся.

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

Вообще какие могут быть реальные причины, почему руководство компании не поощряет обучение или хотя бы даже желание самообразовываться у сотрудников? Я вижу:

1. Пропадёт желание заниматься тем, за что им в компании платят деньги. Появится заинтересованность в другом направлении;
2. Станут больно умными, посчитают, что им нужно больше платить;
3. Будут излишне часто мелькать где-то там, где их нельзя будет проконтролировать, и их поймает какой-нибудь чужой hr;
4. Вернутся с новыми идеями, начнут поднимать волну, придётся перестраивать отлаженную уже, пусть плохо и со скрипом, но работающую систему.

Дорогие мои, поделитесь идеями, какие ещё поводы могут быть в голове у руководства компанией, в данном сл. IT, тормозить образовательные мероприятия для сотрудников, и, если можно, посоветуйте, как можно разбить подобные поводы (доказать их несостоятельность?), помочь изменить политику компании?

Зато я с начала следующей неделе в законном отпуске, и во второй половине октября очень даже настроена выбраться на BlogCamp CEE в Киев, скорее всего буду. На сайте мероприятия уже потихоньку публикуются всякие полезности, типа “где же остановиться в Киеве“, такие вопросы желательно утрясти заранее, чтобы не было паники в последний момент, как получилось у меня с UA WEB (у меня вообще по жизни такие вот естественные вопросы хуже всего получается решать). Так что если собираетесь - пишите, я ведь многих в реале и не видела никогда, хотя с некоторыми знакома годы. Ещё зарегистрировала этот блог на конкурсе “Best Ukrainian Blog Awards“, и за блог можно даже голосовать:

Original post: Блог NunDesign. Comment: this.

И у меня скоро грядёт долгожданное счастье - две недели отпуска. Уехать по особым причинам никуда не выйдет - и дитёнку в школу, а куда ж я без него, и вообще, так что должгожданного моря в этом году уже не светит, вот и кончилось наше лето. Но всё равно, даже о таком тихом отдыхе мечталось уже давно, и стопка книжек для чтива ждёт, и настроение мало рабочее. Заявления на отпуск у наших тимлидов обязательно должны согласовываться с канадским руководством, и я, честно говоря, волновалась, что как раз именно перед отпуском обрушится срочный, важный, глобальный проект и мне дешевле будет остаться в офисе. Но вроде всё тихо, руководство “дало добро”, руководитель одного из подразделений даже с комментарием “ I think that Tatiana really deserves a vacation and I’m ok with it! ” - прям умилилась, чесслово, настолько, что даже не стала отвечать, что правильное написание имени - Tatyana через ya :):).

Правда, что уже ожидаемо, повылазили траблы из старых проектов, трёх-шести месячной давности. И на таких примерах особенно заметно, какой бардак у меня в документации и в контроле переписки с нашими заатлантическими. Во французской версии одного из давно сданных проектов обнаружены неправильные названия разделов сервиса. А у меня чёткое ощущение того, что туда-сюда мы их меняли уже раза три или четыре. А в гневном письме - “Я уже 4 месяца назад говорил тебе, что нужно исправить ошибки “… По текстовой документации, таскам в джире и найденным в архиве письмам - версия верная, может, по телефону был какой-то разговор? Или затерялось какое-то письмо? Или было оно не четыре месяца назад, а неопределённый период времени назад и искать по полному архиву следует, что не возможно за разумное время? Не вспомнить.

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

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

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

Нечёткие постановки - хроническая беда руководства и тимлидеров. Знаю, что не хорошо и непедагогично спорить с начальством (и уж тем более в присутствии моих уже подчинённых), но уж больно часто задалбывают нечёткими, двусмысленными или даже противоречивыми постановками задач. Как тут обойтись без повышенных тонов? “Ну тут же всё понятно! Что же вам не понятно?” - так сидишь, думаешь, может, это я такой даун. Оглядываешься на своих техдиректоров-тимлидов - им тоже не понятно. Начинаешь ковырять непонятную задачу в присутствии всех же, показываешь постановщику - вот, смотрите, если так, как вы говорите, то *тут* и *тут* не сходится. Если *вот это* родительские элементы, а *вот это* — дочерние элементы, то каким образом вы поворачиваете вашу матрицу на 90­° против часовой стрелки и как это ваши дочерние элементы стали главными, а некоторые из родительских - младшими? Ага, тут постановщик понимает, что сам чего-то недопонимает, и правда, не сходится.

Или так: “я же об этом вчера целый час всем вам рассказывал!” — уж сколько раз собирались завести маленький такой локальный диктофон и записывать голосовые совещания, мало ли, может, дома перед сном захочется переслушать… А на самом деле тоже обычная ситуация, никакая не чрезвычайная или исключительная, когда постановщик имеет представление некоего продукта (проекта), перед глазами он его держит, что ли. И вот он пытается описать это представление своими словами перед аудиторией. Вы в корову играли? Многие играли. Иногда даже простая задачка на “изобразить слово” не решаема - не читает аудитория то, что пытается изобразить герой игры. Так и у нас часто бывает. И ему, постановщику, уже давно кажется, что описание он сделал очень подробное и понятное, а все слушатели либо не видят (не понимают) его описания, либо видят настолько искажённым, что постановщик (о! презентатор идеи!) начинает раздражаться, а в последствии - искать виноватых (чем вы слушаете?!). А оказывается, нужен был именно ветеринар, способный писать, а не, хм., борзописец, готовый разобраться в теме. Хотя… во многих случаях как раз неоднозначные формулировки - это очень хитрый шаг процесса: когда заказчик или постановщик сам не понимает что нужно, а признаться в этом не хочет (не обязательно из-за комплекса неполноценности, может как раз из-за сложной стратегии работы с командой), и далее - либо команда уже без него попытается найти оптимальное решение, либо, если решение всё-таки получилось глючное, всегда ясно, кто виноват: я же говорил, что ветеринар, а вы опять всё не правильно поняли, и что мне предлагаете?

Где берут грамотных постановщиков, способных транслировать некую потребность заказчика в рабочий таск, однозначный, читаемый без трактовок?

Original post: Блог NunDesign. Comment: this.

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

Цель спора - доказать единственность своей точки зрения. Во время дискуссии стороны ее просто высказывают, а принимать ее или нет - дело каждого. Отсутствует присущая спору враждебность.

Во время дискуссии стороны не просто высказывают. Можно представить собеседников, как две (к примеру, в простом случае) системы, которые отличаются друг от друга, но не полностью (если бы отличались полностью, они бы не состыковались для дискуссии). Но передать полностью и сразу описание каждой из систем не возможно, требуется механизм состыковки несоответствий.

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

В споре нет как такового процесса обмена и анализа. Есть бомбинг паттернами информации, и качество спора зависит от силы, мощности потока паттернов. В некоторых случаях избранные паттерны, запущенные с особой силой, пробивают защитное поле собеседника и худо-бедно проникают в его систему, становятся частью этой, новой системы. Часто, если пробить не удалось, вырабатывается защитная “мозоль”, которая позволит в дальнейшем не так болезненно на этот паттерн реагировать или вообще игнорировать. Что для второй системы тоже не обязательно в пользу на будущее: непонятое не всегда есть бесполезное.

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

А может, и нет разницы между дискуссией и спором, и это очередная игра словами.

Original post: Блог NunDesign. Comment: this.

Разбираем-изучаем с утра по-раньше корпоративную почту; один из новых программеров, работающих на новом же проекте, удивлённо замечает: странно это, говорит, обычно когда разрабатывается новый сервис, люди сначала думают, а потом делают. А здесь как-то странно: сначала делаем, потом обнаруживаем траблы, переделываем; по результатам переделывания обнаруживаем ещё более стрёмные траблы, уже труднее решаемые, переделываем. Цикл может повторяться до момента, когда руководство разочаровывается в проекте, что автоматически означает — разочаровывается в разработчиках, этот проект наваявших. И правильно, кто виноват в том, что программа “не пошла”? Ессно, программеры. Собирается новая команда, которая получает исходные коды предыдущей версии с задачей “переделать”.

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

Read the rest of this entry »

Original post: Блог NunDesign. Comment: this.

Редко пишу сюда последнее время. Заметил кто-нибудь вообще? Да, бывает, и почта большей частью непрочитанная две последние недели уходила в удалённые за исключением некоторых, заинтересовавших заголовками, и темы для блога были, но многое пришлось отложить на по-позже. Отчасти личные-оффлайновые квесты, сложные для меня, вытягивали много сил, внимания, минут, отчасти то, что так и не сложилось этим летом отдохнуть и добраться до моря, хоть и мечталось до слёз, но… Говорят же, что “что ни делается, всё к лучшему”, а без отпуска не первый год, справлюсь.

Интересное наблюдение: за последнюю неделю-полторы пришло изрядно адресных, не спамерских писем от разных хедхантеров с предложениями поработать и “вообще”, и конкретно; к чему бы это? Подозрительно. Но по работе, как и в жизни, всё по довольно плотному графику, так что извините, господа хорошие, отвечу всем сразу: пока не актуально У нас тут интересно, весело и перспективно, хотя и не безупречно (перспективно - важнее!). Но для читателей, особенно украинских, поделюсь инфой из одного письма, от администрации некоего HighTechHire.com: пригласили зарегестрироваться и ознакомиться с публикациями новых вакансий и фриланс проектов в США и Европе для украинских программистов, дизайнеров, аниматоров и инженеров:

• ASP .NET and MSSQL project
• SEO expert needed for link building
• Graphic Designer for Tape cover
• Website help (Joomla) needed
• Web designer for a newspaper
• Fun website for a DJ
• Original Dragon art design needed
• Freelance Graphic Designer
• Graphic Designer for T-shirts
• MySpace page designer needed
• Property search real estate site
• PHP/MySQL Programmer
• Graphic Designer Needed
• Talented Web Designer-Developer

До hightload`ов (обоих) точно не доеду, даже если вдруг окажется, что время появится, буду отсыпаться. Ещё одно (случайно обнаруженное) событие - этот блог попал в акцию среди членов profyclub`а, о чём было написано в блоге у Павла Рогожина; там же было написано о том, что “Все необходимые инструкции вы получите в ближайшие дни по почте.” Интересно, инструкции о чём? Я ведь могла и прозевать какое-то особо полезное уведомление о том, как “продолжить” участие в акции-то. Вот что с людьми напряги по работе делают!
И ма-а-аленький такой вопрос к профи, к IT-элите рунета: знают ли разработчики сайта profyclub.org о том, что ссылки на rss у них ведут на feeds.profyclub.org, который, в свою очередь, не находится? Или это не глюк, а такая особая фича, с которой я в спешке недоразобралась?

А вот в конце октября на User Experience’08 очень хотелось бы выбраться, всё ещё надеюсь, что даже удастся. Кто не знает, скажу: это ежегодная международная конференция по юзабилити. Очень удачно придумано: конференция состоит из трёх довольно независимых блоков: это курс для новичков, 29 октября, два дня - как бы “основное тело” конфы, и 1 ноября - авторский семинар Джеффа Джонсона. Так вот можно посетить (и оплатить) каждый из блоков можно отдельно (можно и все три сразу), это замечательно.
Мы тут, пока на один из новых разрабатываемых сервисов отрисовали тыщу экранов со сценариями поведения типа типичного юзера в программе, так столько вопросов накопили, из которых главный - что же мы делали не так??? Ну да ладно, кажется, пошла уже, наконец-то, реальная разработка, теперь-то основная сложность - в освоении и совершенствовании новых несовершенных тулзов для разработки интерфейсов и интерфейсных элементов, а так же изыскивание способов обойти это самое несовершенство разработкой элементов в более изящной и знакомой среде.

Ещё одно письмо, интересное, пришло от therbobs.com, ещё 4 сентября, о том, что “Веблог добавлен в Блогопедию“, и там (по ссылке) можно “Предложить этот блог для участия в THE BOBs 2008” как “Лучший блог“, “Лучший блог на русском” (я так понимаю, это и есть доступные мне номинации на конкурс), а можно проголосовать (звёздочками) и прокоментировать - наверное, голоса и комментарии будут как-то учитываться в конкурсе.

Подводя итоги: я жива, пишу пока ещё более сумбурно, чем раньше, работа кипит, хотелось бы пообщаться, обо всём, какие важные новости я пропустила за последние пару недель, и вообще, пишите!

Original post: Блог NunDesign. Comment: this.

Кстати доступна новая версия браузера от Google (версия 0.2.149.29:). Чтобы обновиться, зайдите в пункт меню “О браузере Google Chrome”, или с сайта. Вот здесь - несколько полезных типсов для него же, а здесь - дофига визуальных схем.

Original post: Блог NunDesign. Comment: this.