Просмотр исходного текста страницы Блог:Максима Цепкова/2016-08-08 - аналитики и UX-Usability-UI: какие есть специализации и кто нужен в проекте

[[Блог:Максима Цепкова/2016-07-24: IT Global Meetup Piter United - общение сообществ в действии|Рассказывая]] о недавно прошедшем '''IT Global Meetup''', я отметил контакты сообществ аналитиков и UX с HR сообществом для получения полного представления HR о соответствующих специализациях. Тема важная и интересная, поэтому я по просьбе [https://www.facebook.com/alexey.a.emelianov Алексея Емельянова] написал отдельный развернутый пост и приглашаю к обсуждению всех заинтересованных.

= О ситуации =

Для начала - в чем, собственно, проблема? Проблема состоит в том, что вакансии и ИТ-аналитиков и UX/Usability/UI специалистов часто сформулированы таким образом, что неверно отражают суть будущей работы. И потому профессионалы просто не опознают подходящую к ним вакансию. Почему так происходит? Дело в том, что ИТ-отрасль развивается очень быстро, и специализации возникают и оформляются по факту в ней за 2-3 года. А потом идет накопление опыта и способов работы. И оказывается, что для некоторых задач, которые раньше решали заодно с другими, есть отдельные специалисты, и продукты, разработанные с их участием, обладают определенным конкурентным преимуществом. Их хотят привлечь, но в той компании, где таких специалистов не было, естественно, нет. Поэтому грамотно сформулировать вакансию они не могут, и ориентируются на другие вакансии рынка, или на представления своих других специалистов своей компании. Которые отстали от переднего края специализации на те же 2-3 года, если не больше. 

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

= UX/Usability/UI =

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

Началось все со специализации '''UI-дизайнера''', он же проектировщик интерфейсов. Родилась она в Web-разработке по мере развития парадигм программирования MVC, MVVM и других, различающих визуальное от внутренней логике, работой с данными и наполнением контента. Из Web-разработки она перекочевала в enterprise разработку desktop-приложений, откусив кусочек от области аналитиков. Это - историческое изложения. А основания для специализации состоят в том, что когда экраны стали большими, появилась проблема расположения на них информации удобным для восприятия образом. Именно этим и занимается UI-дизайнер. При чем в ней можно выделить еще одну специализацию '''графического дизайнера''', который занимается фонтами, цветами, промежутками между элементами, видами графиков и прочими мелочами, которые, однако. достаточно сильно сказываются на восприятии информации.

В enterprise-разработке быстро выяснилось, что расположить информацию - недостаточно для удобства работы. Потому что в интерактивном приложении, в котором человек выполняет свои функции, важна возможность быстрого совершения действий и ввода информации. Что оказывается далеко не всегда удобно в интерфейсах, ориентированных именно на представление информации. Так визуальный дизайн дополнился представлениями об эргономике интерфейсов и возникла специализация по Usability. Эта специализация, наоборот, перекочевала из enterprise-разработки в Web, потому что там эти проблема проявились позднее. '''Usability специалист''' занимается удобством '''работы''' пользователя - тем, чтобы мышь не надо было вести через весь экран, чтобы действия можно было делать с клавиатуры потому что переключение ввода между клавиатурой и мышью - долгое, чтобы частые действия выполнялись в один клик, а не в 5-10.

Следующий этап развития специализации связан с распространением смартфонов. Экран с хорошим разрешением, но маленький.А вместо мышки - пальцы. Все это предъявляло отдельные требования и к UI-дизайну, и к Usability, относительно приложений на большом экране. И это быстро выросло в отдельную специализацию, достаточно далеко отстоящую от предыдущих - '''Usability в мобильной разработке'''. 

А еще мобильные приложения выявили, что массовый пользователь очень чувствителен к тому, где ему причиняют пользу и обеспечивают удобство. Отсутствие критичных мелочей могло привести к тому, что продукт безнадежно проигрывал конкурентам. При этом ретроспективный анализ не позволял эти мелочи выявить - от продукта к продукту они очень сильно различались. Более того, иногда фишка была в оригинальности, а иногда - наоборот, в следовании каким-то привычным стереотипам, обеспечивающим, как оказалось, интуитивное освоение неподготовленным пользователем. И тога родилось понятие про User Experience, опыт пользователя. Который не поддается объяснению, а требует экспериментального изучения. Усугубляет ситуацию то, что экспериментировать пока продукта еще нет - как будто не на чем. А - нужно. Вокруг решения этой задачи и развилась отдельная специализация. Таким образом, '''UX-специалист отвечает за ценность продукта, доставляемую в процессе использования'''.

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

Еще одно расширение связано с тем, что смартфон, планшет, ноутбук и компьютер - место работы одного и того же человека, в одной и той же среде. Для Web-разработки это так, скоро так же будет и в enterprise, тренду уже несколько лет. Человек использует разные устройства в разных ситуациях, решает разные задачи, и по-хорошему, необходимо проектировать приложения и сайты с учетом этого. А значит - должно вовлекаться представление о жизни пользователя и ситуациях в ней, а не просто об использовании приложением. Для этого уже появился термин - '''Ambient User Experience'''.     

= Аналитики =        

Теперь про аналитиков. Эта специализация более старая и развивалась совершенно другим путем - от методологии, а не от решения практических задач. При попытке решить проблемы гарантированного получения ИТ-продукта классическими методами разделения труда по Тейлору был придуман [http://en.wikipedia.org/wiki/Waterfall_model Waterfall '''водопад''']. Ройс, который впервые написал схему, предлагал его как антипаттерн, которому нельзя следовать. Аргументы против сочли незначительными и схему взяли на вооружение. В ней был этап '''сбора требований''' и '''проектирования''' системы на основе этих требований. Это и родило специализации '''бизнес-аналитиков''' (BABOK - про это) и '''системных аналитиков''' соответственно. Где-то рядом с системными аналитиками находятся '''архитекторы''' и как-то делят поляну проектирования.

Потом произошло интересное. Вместо inhouse-разработки и разработки продуктов, которые характеризуются полным циклом создания ИТ_продукта внутри оной организации, стала распространенной '''заказная разработка'''. Да и внутри корпораций произошло размежевание ИТ-отделов и бизнес-пользователей, работающих в модели внутреннего заказа. 

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

[[Файл:Responsibilities in software development Tsepkov AnalystDays-2015.pdf|page=16|300px|right]]

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

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

[[Файл:Responsibilities in software development Tsepkov AnalystDays-2015.pdf|page=28|300px|right]]

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

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

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

Вообще про разделение ответственности в заказной разработке я делал [[Разделение ответственности в заказной разработке (Максим Цепков на AnalystDays-2015)|доклад на AnalystDays-2015]], там было много про аналитиков и архитекторов, а вот про линейку UX/Usability/UI - не было. Слайды в этом разделе - оттуда.

= Кто нужен на проекте=

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

При этом в большинстве небольших проектов на эту роль достаточно '''одного''' человека - аналитика или UX/Usability специалиста. Об этом был [http://analystdays.ru/ru/talk/33312 доклад Юры Куприянова] на Analyst Days, в котором он указывал, что практически не знает, проектов, действительно требующих обоих специализаций с организацией коммуникаций между ними и принятием связанных с этим накладных расходов.

Кого предпочесть, зависит от характера разрабатываемого приложения: если основная ценность связана с коммуникацией между человеком и компьютером, то это UX/Usability, а если ИТ-система имеет сложную внутреннюю конструкцию, обеспечивающую ценность, например, координацию деятельности людей в сложном процессе, или сложные алгоритмы, то нужны аналитики.      

Но в любом случае, когда вы берете готового специалиста с одной специализацией, у него может оказаться провал в других. Что неважно для одних проектов, но критично для других. С другой стороны, если провал невелик, то он легко устраняется: аналитика можно отправить на тренинг по UX на 2-3 дня, или наоборот, обучить UX системному анализу на базовом уровне тоже на небольшом тренинге. Что потенциально нанесет большую пользу проекту. 

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

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

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

В принципе, описанные задачи по организации работы - находятся в поле деятельности HR. Однако, требуют специфических знаний об организации ИТ-разработки. Которые не обязательно осваивать самому. Но и полагаться на публичные советы тоже не слишком следует, потому что решения могут '''критичным образом''' сказаться на успехе проекта. Эту задачу тоже пытались решить традиционными методами - через сертификации, однако темп развития ИТ таков, что это по факту институализироваться не успевает, все стандарты, тот же BABOK - находятся в прошлом. Поэтому стоит действовать другим методом - через доверенных экспертов или сообщества.
{{wl-publish: 2016-08-08 17:29:16 +0300 | MaksTsepkov }}

[[Категория:Люди]][[Категория:Роли]]