Коллеги бранятся — только тешатся

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

После переговоров, на пути в офис, Андрей сказал мне примерно следующее: «Я могу быть неправ в своих мыслях, но в будущем воздержись от того, чтобы поправлять человека из твоей команды (если, конечно, речь идёт не о фактологических ошибках). Для клиента мы должны представлять собой единый дружный организм, не противоречащий сам себе». Я замечание услышал и в дальнейшей работе, если моё мнение расходилось со мнением шефа, держал рот на замке во время переговоров. Зато после переговоров мог говорить что угодно.

Тогда у меня не было достаточно опыта, чтобы действительно понимать этот совет, но со временем это понимание пришло. Один из наглядных примеров я увидел в прошлом году. На этот раз со стороны исполнителя был только я, а на стороне заказчика собралось четверо человек: собственник и трое его сотрудников. Переговоры велись по Скайпу. Я продемонстрировал прототип и минут через пятнадцать после начала переговоров слово взял программист клиента. Говорил он уверенно и во многом правильные вещи, но вот беда: это сильно противоречило тому, о чём мы общались с собственником. Началась «перепалка». Я взял это слово в кавычки потому что особого негатива в этом споре не было, но и прийти к согласию стороны не могли. Продолжалось это довольно долго, и я всю дорогу молчал, наблюдая за происходящим.

В итоге продуктивные переговоры так и закончились на тех первоначальных двадцати минутах, хотя продлились чуть дольше часа. Эта история повторилась ещё пару раз, после чего программиста больше не допускали к нашим переговорам.

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

Выводы:

— Участвуя в переговорах в составе собственной команды, не перечьте друг другу в рамках субъективных решений;

— Сначала приходите к согласию внутри команды, и только потом транслируйте решение клиенту, чтобы получить обратную связь;

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

Ценообразование и процесс работы над адаптивными прототипами в Проекторате

Во-первых, мы не закладываем стоимость адаптивного прототипа в первоначальную оценку. То есть, сначала делаем прототип под определённое разрешение (какое именно — зависит от преобладающей аудитории (или потенциальной аудитории) тех или иных устройств). Сейчас это разрешение чаще всего — 1024 или 1200 пикселей по ширине. Метод mobile first использовался нами лишь однажды. Когда речь идёт о сложных проектах, стоимость прототипа может измениться в процессе работы, т.к. на лету появляются новые функциональные требования, поэтому неразумно включать в этот этап и оценку адаптивки.

Во-вторых, стоимость адаптивного прототипа будет зависеть от сложности интерфейсов. И речь идёт не о количестве страниц, а об их функциональной насыщенности. От 10% от стоимости проекта до 30%. За каждое дополнительное разрешение.

В-третьих, цена будет зависеть от количества брейкпойнтов, то есть от количества разных внешних видов для разных разрешений. Сейчас чаще всего они таковы: 320 (телефон в портретной ориентации), 480 (телефон в горизонтальной ориентации), 768 (планшет в портретной ориентации), ну а планшеты в горизонтальной ориентации уже входят в первоначальный прототип.

Итого, прототипирование адаптивки составит дополнительные 10—90% от стоимости первоначального прототипа.

Откуда берутся эти проценты?

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

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

В-третьих, Axure позволяет легко показать для одного и того же разрешения несколько разных вариантов адаптивки. Возможность сравнить разное поведение интерфейса в одних и тех же условиях позволяет сделать более объективный выбор.

По срокам: мы берём за основу процентную стоимость работы над адаптивкой и превращаем её в процентные сроки. То есть, от 10% до 90% от времени работы над основной версией будут затрачены на адаптивный прототип.

О переговорах и переписках

Небольшая заметка о том, насколько сложно людям договориться друг с другом, используя переписку.

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

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

Это я к тому, что профессия учит меня снижать риски при интерпретациях того, что мне говорят другие люди. А самый простой способ «синхронизироваться» с собеседником — это задавать простые прямые вопросы, ответы на которые сложно было бы понять двояко.

Примеров из переписок с клиентами я опубликовать не рискну. Но есть похожая история с консультациями по работе в Акшуре. Каждый день множество незнакомых людей присылают мне вопросы, связанные с работой в этом инструменте или, реже, просьбы выступить с лекцией или мастер-классом. Вот несколько примеров:

Я: Настя, с тех пор, как вы написали мне первое сообщение, я так и не понял, представляете ли вы официально Epic Skills или являетесь их студентом.
Настя: Все, кто работает в Эпике — это бывшие студенты какого-либо курса) Я училась на курсе веб-дизайна

То есть, мне стоило спросить: «Настя, вы сотрудник Эпика?» Потому что ответа на свой вопрос я так и не получил. А человек старался, отвечал.

Вот ещё:
Я: Да, я думаю, кто-то сможет провести такое занятие. Может быть, я сам.
Настя: Большое спасибо, что согласились.

Тут правильно было бы написать «Я подумаю и сообщу о своём решении позже». Моя формулировка оказалась слишком сложной для понимания.

А вот примеры вопросов, на которые ответить было бы возможно, только задав встречные вопросы:

«Ребята подскажите пожалуйста — ненашла нигде инфы. В инлайн фрейм вставила паралакс а вот как прокрутку сделать в рамках этого фрейма — чет не разбирусь. Спасибо»
Параллакс — это эффект, а не объект, который можно вставить в инлайн-фрейм. Что имела в виду автор — загадка.

«Друзья! Кто знает, можно ли в акшуре сделать работающий поиск с отображением быстрых результатов в виде дропдауна?»
Вероятно, имелась в виду эмуляция автоподстановки быстрых результатов при вводе поискового запроса в текстовом поле. А не создание работающего поиска.

«Друзья, я к вам за помощью. Столкнулся с острой потребностью потестировать прототип, сделанный в Axure. Помогите избрать самый лучший способ. Есть ли в самом Axure инструмент тестирования?»
Любой тест чего угодно проводится с какой-то целью. Можно протестировать медную ложку. Тест на содержание в ложке меди будет отличаться от теста на плавучесть ложки.

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

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

Чтобы качественно оказать услугу своему клиенту, нужно хоть раз оказаться на его месте

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

Важность проверки результатов собственного труда

В числе немногочисленных требований к нашим соискателям (если называть вещи своими именами, то к нашим потенциальным партнёрам) находится привычка проверять результаты своего труда. Мы все много раз встречались со смешными опечатками в макетах дизайнера, косяках в вёрстке, которые можно было бы отловить и исправить, просто внимательно посмотрев на то, что получилось, неработающий код, который исправляется за минуту, однако, портящий впечатление от всей работы и стопорящий процесс ещё на рабочий день. Это происходит по двум причинам, истекающим друг из друга. Работа делается в последний момент и работа не проверяется. А ведь проверка работы — это постановка себя на место того человека, который будет её принимать.
То есть для проектировщика — это вообще показатель его компетентности. Тут каждая мелочь должна рассматриваться глазами гипотетического будущего пользователя системы. Где-то может спасти специально обученный тестировщик, но зачем, если можно найти специалистов, которые внимательно относятся к тому, что делают?

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

Что написать клиенту при первом письменном контакте

Чтобы понять, как предлагать незнакомым людям свои услуги, нужно однажды оказаться на месте того человека, которому эти услуги нужны.

Где Проекторат берёт клиентов на проектирование?

Часто спрашивают, где мы берём клиентов. Причём спрашивают и фрилансеры, и собственники студий. Конечно: интересно же!
Тут логичен встречный вопрос: «Каких клиентов?» Потому что их много и они разные. Есть стартаперы. Есть корпоративный сегмент, где задачи на разработку генеральные спускают сверху-вниз своим менеджерам. Есть уже давно работающие проекты, которым требуется рефакторинг. Клиенты, в проектах которых мы являемся соучредителями. Государство. Список можно продолжать и продолжать.

Естественно, в зависимости от типа клиента будет выстраиваться понимание о том, где его искать и какую методологию использовать в работе. За госпроектами идём в тендеры, за стартаперами — на тусовки, корпоративный сегмент собираем с помощью директа и своего красивого сайта с румяным портфолио. А рефакторинг придёт сам по сарафанному радио.

И именно последний тип клиентов преобладает в Проекторате.

Изначально компания выстраивалась вокруг моей личности и моего существующего пула клиентов. И вот причины, почему мы работаем с клиентами на рефакторинг больше, чем с другими:

— Этим людям не нужно объяснять банальные вещи. Все этапы разработки сайта они уже прошли и в этих вопросах опытнее, чем многие сотрудники студий;
— Рефакторинг делают чаще на проектах, которые приносят прибыль и достигли определённого порога. Соответственно, деньги у таких клиентов есть и они понимают, во что их вкладывают, покупая такую работу;
— На этих проектах уже есть вся необходимая статистика для принятия объективных решений, а не игр с гипотезами;
— Если всё же играем с гипотезами, мы можем проверить их в сжатые сроки прямо на живом проекте.

В чём сложность?
— Работа строится по одному из двух принципов. Либо вам доверяют и общаются с вами на равных, как с предпринимателем. В этом случае вы в том числе выступаете в качестве консультанта. Но для этого вы должны обладать предпринимательским опытом. Советы фрилансера без такового (или наёмного сотрудника) будут восприниматься… по-другому. Второй принцип — вам не доверяют и используют как карандаш в руках художника. Не многие любят так работать;
— Единственный надёжный источник клиентов — сарафанное радио. Работать с вами без рекомендации — большой риск. Впрочем, исключения бывали.

Резюме: сарафанное радио (где-то 70%). Один довольный клиент превращается в нескольких потенциальных довольных клиентов.

А те, кто не знают, что такое рефакторинг, то вот цитата из википедии: «…процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы». То есть, берём работающий проект и делаем его ещё прибыльней за счёт оптимизации штук, связанных с конверсионными действиями.

Привет OneWayStudio от Проектората

Мы внимательно следим за метрикой Проектората. Нам интересно знать, кто, откуда пришёл на сайт и попытаться понять, для чего. Также это помогает увидеть, позволяет ли наш простенький, лишённый дизайна, сайт, добираться до поставленных целей. Сегодня, например, 9 визитов нанесли пользователи интранета студии http://onewaystudio.ru

Мы рады проявленному интересу и хотели бы со своей стороны дать несколько советов по интерфейсу их собственного сайта, без фанатизма:

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

Базовые сценарии работы с клиентами

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

1. Клиенту всё нравится, он не задаёт никаких вопросов и принимает работу.

Такое случается, хоть и редко. Это первая крайность, потому что если вопросов и комментариев не возникает, значит заинтересованность в проекте у заказчика нулевая. Либо он ему нужен для галочки (если это непосредственно собственник), либо правки и комментарии придут уже в процессе разработки, а не проектирования (если принимал менеджер, который покажет результат работы собственнику чуть позже).

2. Клиенту в целом нравится, нужно только отработать ряд комментариев по проделанной работе.

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

3. Клиенту в целом нравится, нужно только отработать ряд комментариев по проделанной работе.

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

Самый важный вопрос к проектировщику

При проектировании интерфейсов очень важно знать ответы на все «зачем?» Иногда это «почему?», «для чего?» или даже «нахрена?» Но суть у них одна: если проектировщик не может ответить на такой вопрос, значит он не думал во время работы. Варианты ответов у начинающих могут быть такими: «Так сделано на том и на этом сайтах» (слепое заимствование), «Для того, чтобы было удобнее/красивее» (манипуляции субъективными понятиями).  Не рекомендую отвечать «А почему вы спрашиваете?» (уход от ответа) и «Так надо!» (неуместная попытка использовать свой авторитет). Варианты ответов у специалистов: «Так будет быстрее, вот результаты тестирования на таком-то проекте», «Здесь это более заметно среди такой-то целевой аудитории, потому что…», «Это позволит сэкономить вам n евродолларов на вопросах обеспечения безопасности».

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