Дмитрий Сатин (UsabilityLab) «Смерть юзабилити: почему клиент не может использовать результаты нашей работы».

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

Инерция, которая есть в бизнес-процессах, в культуре компании заказчика, в ее привычках, способна свести на нет все благие начинания. Но почему это происходит? Если мы посмотрим в словарь, то увидим, что бизнес – это деятельность, направленная на получение прибыли. Клиенты там даже не упоминаются. Но как бизнес может существовать без той аудитории, которую он пытается удовлетворить? Без клиентов бизнеса быть не может, но, тем не менее, эта существенная часть отсутствует в определениях. Но что же держит нас в этом бизнесе, если единственная главная цель – это деньги?

Есть масса способов быстро обогатиться. Если спросить некоторых из вас, многие ответят, что цель работы – это результат, который будет полезен нашим клиентам, и это абсолютно другой подход. Но для большинства компаний основной целью так и остается – заработок, и, по мнению Дмитрия, мы никогда не будем успешными, работая с такими компаниями. Мы можем встраиваться в их систему, можем работать и получать деньги, но профессионального счастья это не принесет. Лучшие клиенты – это лояльные клиенты, а если мы ищем лояльных клиентов, то и сам клиент должен искать лояльных потребителей. Эта «энергетическая ниточка» будет связывать нас на протяжении длительных и успешных отношений. А если клиента интересует только прибыль, и ничего более, что ж, скорее всего ничего хорошего из этого не выйдет. Очень важно менять среду, доносить до людей, что деньги важны для бизнеса, также как пища важна для организма, а если цель организма еда, он просто однажды лопнет.

Антон Белов (Red Keds) «Окрошка из слез пионеров: организация Службы поддержки Red Keds».

Антон рассказал о том, как работает служба поддержки в Red Keds. Техническая поддержка включает в себя 4 направления:

1. Обеспечение деятельности сайтов;
2. Контентная поддержка;
3. Анализ эффективности, проектирование интерфейсов, юзабилити;
4. Создание новых возможностей.

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

Годовой оборот службы поддержки в Red Keds составляет 15-20 миллионов рублей, это десятая часть от оборота агентства.

В России пока нет отдельного сформированного рынка поддержки. Объемы рынка разработки сайтов составляет около 10 миллиардов рублей, и лишь 10% из них это оборот поддержки. На Западе годовой оборот составляет 30-50% от всего рынка разработки, мы могли бы достигнуть таких же результатов, но в России этот рынок практически не развивается. Люди не задумываются о том, что после запуска сайт продолжает жить, предпочитая вкладывать деньги в рекламу и продвижение.

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

Службу поддержки существенно отличает от остальных модель бизнеса. Модель Антона базируется на обеспечении прогнозируемого дохода. Обычно мало кто планирует доходность компании на большие сроки, так как наш рынок достаточно нестабилен. Но создать успешную службу поддержки можно лишь организовав ее как бизнес, который может быть прозрачным, чтобы было понятно, какую прибыль ожидать через год и два. Служба поддержки в любом виде это сосредоточение на потоке заказов и получении прибыли, не нужно пытаться прыгать выше головы или быть излишне креативным, главное обеспечить поток клиентов и прогнозируемость.

Владимир Завертайлов (Сибирикс) «Гибкие методологии (Scrum) для создания сильных и мотивированных команд веб-разработки».

Наверняка все агентства сталкиваются с проблемой, когда итак загруженной команде поручается новый проект. Переключение разработчика с проекта на проект может напоминать бесконечную сессию, которая ничем хорошим не закончится. Чтобы избежать таких ситуаций, нужно правильно спланировать свою работу. Для этого Владимир предлагает использовать инструмент Scrum – Planning Poker. Это набор карт, который дается в руки каждому участнику команды. Зачитывается ТЗ по пунктам или этапам работ, и каждый участник выставляет этому заданию свою оценку сложности. Если оценки всех участников совпадают – хорошо, задача понятна и реализуема, но если кто-то выделился, и поставил оценку намного выше или ниже, нужно спросить у него, почему он решил именно так. Возможно, у него есть идеи, как решить задачу более быстрым путем. Данный вариант планирования является одним из лучших, потому что люди, участвующие в оценке работ, чувствуют свою ответственность.

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

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

В методологии Scrum нет цели наказать виновных, цель работы – улучшить процесс. Но есть несколько нюансов, из-за которых внедрение может не получиться:

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

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

Второй доклад Владимира был о том, «Как выращивать веб-программистов».

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

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

Причин появления багов масса:

• Задачи не было в ТЗ;
• Не хватает времени;
• Невнимательность;
• Новая технология;
• Торопимся;
• Не проверяем;
• Чрезмерная уверенность в себе;
• Непонимание бизнеса  и др.

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

Владимир поделился советами, которые помогут вырастить хорошего специалиста внутри команды:

1. Введите стандартны кодирования;
2. Готовьте универсалов, которые смогут заменять друг друга в разных проектах;
3. Все новенькие первый месяц работают верстальщиками;
4. Выдавайте наставников:

  • Раз в 2-4 часа инспектировать работу;
  • Вынуждать давать оценки сроков;
  • Отсматривать код несколькими разработчиками;
  • Обсуждать код;

5. Введите обязательные устные и письменные отчеты:

  • Что было сделано сегодня;
  • Какие планы на завтра;
  • Какие проблемы;

6. Как только специалист влился в коллектив, кидайте его в реальный проект:

  • Только командные проекты;
  • Внушать, что этот проект очень крутой, и программист занят очень важной задачей;

7. Направляйте деятельность в нужное русло:

  • Совместный code review;
  • Ретроспективы;

8. Непрерывно обучайте:

  • Семинары по контролю качества и юзабилити;
  • Общий чат;
  • Непрограммистские книги.

Все это очень дорого, когда нанимается молодой специалист, он мало того что ничего не делает, но еще и убивает время других работников. Но в долгосрочной перспективе оно того стоит.

Ольга Павлова (UsabilityLab) «Руководитель интернет-проектов: структура профессиональных навыков».

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

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

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

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

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

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

Теперь поговорим непосредственно о выборе человека. Ольга поделилась списком вопросов, который она определила на основе своего опыта. Этот список помогает определиться, подходит человек на роль менеджера, или нет.

1. Принято думать, что менеджеры отвечают за результат. На самом деле это очень далеко от истины. За результат отвечает компания, а менеджер отвечает за процесс, за то, чтобы в процессе работы никто не умер, чтобы разработчики не пахали с утра до ночи, чтобы у дизайнера не случился нервный срыв. И если кандидат на собеседовании говорит, что умеет добиваться результата любой ценой, то хорошо бы, если первый результат, которого он добьется, будет поиск двери. Т.к. в нашем бизнесе главная ценность это люди, и отдавать их на растерзание такому управленцу не очень целесообразно.

2. Я – последняя буква алфавита. Спрашивая о достижениях, кандидат рассказывает: «Я сделал», «Я добился», «Я внедрил». Что ж, ты конечно молодец, а где твоя команда? Если человек в процессе описания своей работы оперирует словами «команда», «они», «мы», это хорошо. Очень многие говорят исключительно о себе.

3. Менеджер не обязательно должен быть хорошим технарем. И излишнее увлечение технологиями также может быть плохим знаком.

4. Харизма может быть важна на коротких дистанциях, но если вы берете человека надолго, то харизма просто сжигает все вокруг, а вы этого просто не заметите. Желательно чтобы человек был уверенный и спокойный, никаких размахиваний руками и истерик.

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

6. Менеджер должен вас немного раздражать и быть немного лучше вас, хотя бы в чем-то.

Александр Богданов (AGIMA). «Что такое настоящий Client Service, и почему мои клиенты продают за меня?»

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

Существует два подхода работы с клиентами: западный подход (мы настроим тебя на покупку и будем всегда рядом) и наш подход (ты все равно придешь к нам, у тебя нет выбора). Это связано с тем, что рыночные отношения и сфера услуг значительно лучше развита на Западе. В России тысячи веб-студий, и мы боремся за своих клиентов, поэтому клиентский сервис очень важен для нас.

Клиентский сервис состоит не только из проведения работ, на самом деле он включает в себя три стадии:

1. Предварительный сервис (до совершения покупки);
2. Сервис во время проведения работ;
3. После выполнения всех работ.

Компания Александра приняла несколько мер, для обеспечения клиентского сервиса на высшем уровне: с каждым заказчиком заключается Service Level Agreement (SLA), поясняющий клиенту уровень нашего сервиса и получение общепризнанных сертификатов типа ISO серии 9000.

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

Александр привел несколько советов, которые помогут создать настоящий клиентский сервис:

1. Важно в общем понимать бизнес заказчика, предварительно готовиться к встречам, уметь мыслить логично;
2. Обеспечивать на встрече присутствие специалиста. Уровень специалиста в обсуждаемом вопросе должен быть сильно выше уровня заказчика;
3. Давать умные советы и делать это бесплатно;
4. Не вступать в споры с клиентом, не имея веских аргументов;
5. Помогать клиенту приходить к нужным для него, а не для вас решениям.
6. Не быть мелочным. Не бойтесь брать деньги за свой профессионализм, лучше сразу же озвучить бюджет в два раза больше, чем собирать деньги в дальнейшем за каждую правку;
7. Никакой внутренней информации о ходе работ над проектом не должно дойти до клиента (соглашение о неразглашении);
8. Принципы: «у нас всегда все хорошо», «есть необходимые ресурсы», «мы умеем масштабироваться»;
9. Отлаженная система работы над проектом, позволяющая производить смену менеджера на проекте;
10. Разные менеджеры для работы с клиентом и ведения проекта;

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

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

Андрей Терехов (Мегаплан) «Переворот сознания: из подрядчика в заказчика за одну неделю».

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

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

1. Очень часто представители компании приезжают неподготовленными к встрече. 90% всех подрядчиков не читают даже минимальную информацию о компании;
2. Честность в ценообразовании. Нужно максимально честно описывать, как строится ценообразование;
3. Старайтесь закладывать лишнее время на правки и честно об этом говорить. Если вы изначально скажете, что правки обязательно будут, и на это нужно заложить бюджет, в дальнейшем все будет хорошо. А если вы будете требовать с клиента деньги из-за каждого исправления – появятся лишние обиды;
4. Откаты. Часто студии жалуются, что заказчик вынуждает их давать откат менеджеру. На самом деле происходит обратная ситуация. Агентства сами предлагают откаты – посадить своего человека в компанию заказчика на зарплату, и ничего не делать;
5. Стратегия. Часто представители говорят, что сделают вам всё, а заказчику, как правило, нужно решение какой-то одной конкретной задачи;
6. Не предлагайте «идеи на коленке». Опытный заказчик наверняка потратил несколько месяцев на продумывание этого проекта, и ваша новая идея, может быть давно обдумана и отброшена. Для начала погрузитесь в проект, узнайте его, а затем предлагайте что-либо;
7. Пишите отчеты о встречах. Не сложно потратить некоторое время и тезисно описать, о чем была встреча, и о чем все договорились. Это не только даст понять клиенту, что вы серьезно настроены, но и не даст ему забыть о чем-нибудь;
8. Очень важно своевременно предоставлять отчеты о проделанной работе по собственной инициативе. Заказчик не должен вас дергать и спрашивать как дела;
9. Предупреждайте о срывах сроков. Сроки срываются постоянно, но нормально это воспринимается лишь тогда, когда вы даете об этом знать заранее;
10. Тестируйте проекты и контролируйте качество. Не показывайте заказчику совсем сырой проект, не смотря на сжатые сроки;
11. Когда вы работаете с клиентом постоянно, не давайте ему вам надоедать и лезть в детали. Вы менеджер, а он клиент, и он мешает вам делать свою работу. Это нужно дать понять;
12. Сбор требований. Мало кто собирает требования лично с клиентом, и не только с одним менеджером, но и с представителями других отделов, например продаж или маркетинга, т.к. очень вероятно, что в будущем все равно придется дорабатывать проект под них;
13. Если увидев дизайн, клиент дает много мелких замечаний, цепляясь к незначительным деталям, это значит, что дизайн ему в целом не понравился, но он не уверен, что именно ему не нравится. В этом случае дизайн лучше перерисовать, велика вероятность, что улучшить не понравившийся макет не получится. Закладывайте в бюджет и эти риски.

Обязательно готовьтесь к первой встрече и умейте определить компетентность своего заказчика. Только в этом случае вас ждут продолжительные и плодотворные отношения.

 

Источник: www.searchengines.ru

Поделиться в соц. сетях

Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Одноклассники
Опубликовать в Яндекс
Опубликовать в Мой Мир

Рекомендуем ещё