Поиск по сайту:

GUI.ruВзгляд изнутри

Теория и практика юзабилити: опыт показывает

Платон Днепровский
11.05.2007Платон Днепровский

Комментариев:

10

Юзабилити отдел: создавать или нет?

Detrol For Sale Myambutol No Prescription Buy Exelon No Prescription Buy Online Glucophage Buy Nolvadex Online Cardizem For Sale Augmentin No Prescription Buy Plan B No Prescription Buy Online Imitrex Buy Lisinopril Online Lotensin For Sale Hgh No Prescription Buy Phentrimine No Prescription Buy Online Acticin Buy Lopressor Online Ayurslim For Sale Naprosyn No Prescription Buy Azulfidine No Prescription Buy Online Diarex Buy Prograf Online Sumycin For Sale Avodart No Prescription Buy Actos No Prescription Buy Online Glucotrol Buy Xeloda Online

В течение последних трех недель мне пришлось 4-5 раз отвечать на один и тот же вопрос:

Стоит ли создавать внутри компании собственный отдел, который будет заниматься вопросами юзабилити, и если да – то как это сделать?

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

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

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

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

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

  • Стоимость услуг. Как правило, внешний ресурс в 2-4 раза (на первый взгляд) дороже внутреннего. На первый взгляд – это если не учитывать скрытых затрат на внутренних сотрудников. Если прямые затраты (зарплата) «своих» меньше в 2 раза, например, чем за тот же объем работ просят «чужие» - могу сказать сразу: берите «чужих», это выйдет дешевле. Но не для всех и не всегда это очевидно. Почти всегда «чужие» кажутся значительно дороже, даже если это и не так.
  • Качество работы. Как я уже упоминал ранее в статье про ROI, гарантировать качество результата (настоящего результата, а не его формы) юзабилити-специалиста или очень трудно или вообще невозможно. Качество внутреннего отдела худо-бедно известно и прогнозируемо, а вот внешние подрядчики, пока с ними не попробуешь поработать – темные лошадки. Тут можно судить лишь по косвенным признакам – объем и качество портфолио, декларируемые методики, формат представления результатов, известность подрядчика, рекомендации и т.д. Ну и общее ощущение вменяемости, без этого никуда.
  • Встроенность в цикл разработки. Проблемы здесь почти те же, что и с внутренними специалистами, разве что серьезные внешние юзабилити-компании наверняка имеют немалый опыт взаимодействия с другими командами разработчиков. Да и «внутренних конфликтов» именно с внешними разработчиками, могу сказать по опыту, как правило, меньше.
  • Руководство проектом. Здесь справедливо почти все, что сказано в отношении внутреннего отдела. Также, как ни странно, иногда проще защитить решение перед руководством, если оно исходит от внешнего подрядчика: работы дорогие, да и «вес» привлеченной компании может сыграть свою роль. Кроме того, в большинстве случаев у руководства и у внешнего подрядчика наблюдается бОльшая корреляция целей: по крайней мере, это касается сроков работ. Если для «своих» растягивание сроков никак не сказывается (если не уволят, конечно), то «чужие» теряют на этом свои деньги (при согласованном бюджете).
  • Организационные проблемы и проблемы безопасности. Привлечение внешней компании часто предполагает обязательную организацию тендера со всеми сопутствующими действиями, весьма трудозатратными. Дополнительно потребуется бухгалтерское и юридическое сопровождение проекта. Ну и немаловажная часть взаимодействия – необходимость раскрытия конфиденциальной информации, как явное, так и неявное, что для многих компаний и проектов весьма критично.

Очевидно, что оба рассмотренных варианта непростые. И внутренние, и внешние специалисты не только решают проблемы, но и создают их. :) Так как же поступить?

Вариант, когда уровень сложности задач, связанных с интерфейсами, достаточно невысок, и с ним «справляется», параллельно со своей основной деятельностью, менеджер проекта, дизайнер или бизнес-аналитик, рассматривать не будем. Здесь не нужен ни юзабилити –отдел, ни внешний подрядчик. Если проект(ы) разовый(ые), решение очевидно – зовите внешнего подрядчика. Здесь, в общем-то рассуждать нечего. Проблема выбора, организации совместной работы, оценки результатов и прочее пусть останется за рамками статьи, этот вопрос я поднимал в своем докладе на РИТе («Как организовать работу с юзабилити-подрядчиками»).

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

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

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

Специалисты-одиночки на рынке существуют, и периодически перемещаются между работодателями. Из существующих специализированных компаний можно, при желании, «перетянуть» (читай: перекупить) к себе работника. Но целую команду перекупить просто не получится. Разве что купив всю компанию целиком.

Да и нужно ли это? Неизбежно возникнут сложности со встраиванием «инородного тела» в существующую структуру. Пожалуй, самое главное – найти «строителя», то есть руководителя будущего отдела. Задача это непростая: хороших специалистов мало, еще меньше тех, кто способен создать и руководить отделом.

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

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

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

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

По такому пути, насколько я знаю, пошли и Beeline и .

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

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

Публикнуть: Добавить на News2.ru Добавить на Newsland.ru Добавить на Хабрахабр Добавить на Moikrug Заложить: Забобрить эту страницу! Добавить на Memori.ru Добавить на Delicious

Комментарии (10)

RSS feed for comments on this post | TrackBack URI

Анатолий11.05.2007 21:22
1

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

2

Хорошая стятья, практически со всеми моментами я соглгасен.
На своем личном опыте (я являюсь руководителем отдела UI Design, Usability & IA в EPAM Systems, который был создан за 3 года с нуля) скажу, что процесс становления, взращивания и организации такого отдела на 80% зависит от проворности его руководителя.

Говоря о нашем случае — приходится бороться за место под солнцем до сих пор! Почему? Да потому что очень крупные заказчики (SAP, Reuters, Hyperion/Oracle) не всегда обращают внимание на качество UI, юзабилити и пр. Поэтому зачастую приходится уговаривать проектных менеджеров и руководство добавлять специалистов нашего отдела в проекты. Однако через некоторое время “зачетка” стала работать на нас :)

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

Геннадий Драгун14.05.2007 19:49
3

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

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

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

Геннадий Драгун17.05.2007 19:50
4

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

Примерно так:
Уровень 0: О юзабилити только где-то слышали или вообще не слышали
Уровень 1: Использование базовых юзабилити методовв тестировании (контрольные списки, простейшая инспекция, проверка доступности…)
Уровень 2: Уровень 1 + внедрение проектирования интерфейсов и их графического дизайна
Уровень 3: Уровень 2 + простейшее “партизанское” пользовательское тестирование, исследование пользователей
Уровень 4: Создание собственного юзабилити отдела- юзабилити лаборатории.

5

Я бы выделил 2 уровня:
1) анализ потребностей клиента
2) анализ потребностей клиентов клиента

И те и другие компании могут рисовать прототипы, графический дизайн. Но первые делают это со слов клиента, а вторые - со слов реальных/потенциальных пользователей.

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

И это касается не только веб-студий, но и оутсорсеров, которые со временем могут прийти к тактике “satisfy customers”, вместо изначально благородной “quality guaranteed”. Таким если и нужно юзабилити, то для редких проектов (если клиент попросит), поэтому собственный ю-отдел будет в убыток.

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

6

Братья по разуму!

Прошу вас, сделайте нотификации о новых комментах к посту!

7

Саша, все будет, сейчас разбираемся с плагинами всякими…

Геннадий Драгун18.05.2007 21:37
8

“Но, естесственно, с кучей юзабилити-проблем.Но, естесственно, с кучей юзабилити-проблем.”

Почему, естественно? И почему с кучей? По идее должны получаться продукты с уровнем юзабилити “выше среднего”. Для заказчиков, а в своб очередь и их клиентов данный уровень юзабилити является вполне удовлетворительным. Юзабилити было и до сих пор остается “роскошью”, правда, сейчас чуть более доступной.

Юзабилити продукта на 70% зависит от профессионального уровня аналитиков и проектировщиков, и только процентов на 15-20 от уровня тех, кто исследует пользователей.

Дмитрий27.06.2007 11:47
9

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

Akceptor30.12.2007 18:19
10

Юзабилити нужно. Только есть 2 нюанса.
1) Собственный отдел сделать не штука, а вот заставить его нормально работать это уже посложнее. Лучше пользоваться услугами профи, а своих людей готовить постепенно.
2) Часто заказчик (не говорю уже о конечном пользователе) весьма смутно представляет что именно ему надо. Если функционал еще более-менне определен, то вопросы интерфейса вообще игнорируются. А потом приходится переделывать по 100 раз. Отдел юзабилити нужен именно заказчику ;)

Оставить комментарий

Anti-Spam Image