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

Читать далее

Статус-кво

Мир современного бизнеса — мир ПО. Достаточно посмотреть на рейтинг самых дорогих компаний мира по данным Forbes, чтобы понять, что программные продукты играют не менее важную роль чем сырьё или рабочая сила. А зачастую ПО имеет доминирующее значение в ведении бизнеса.

В 1999 году в своей книге «Бизнес со скоростью мысли» основатель компании Microsoft Билл Гейтс описывал «электронную нервную систему» организаций. Он считал, что программное обеспечение позволит организациям моментально реагировать на изменения состояния рынка, а в эпоху цифровых технологий без этого конкурентного преимущества не будут возможны ни рост, ни выживание организации вообще. Сейчас можно с уверенностью утверждать, что его предположение оказалось верным и те, кто осознал и принял этот факт, так или иначе нуждаются в специализированном ПО. В некоторых случаях можно обойтись готовыми решениями (например, такими как 1С), но чаще конкретному бизнесу нужно программное обеспечение, разработанное специально для него.

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

Во-первых, разработать нечто способное конкурировать с уже успешно существующими решениями в плане технической сложности — нетривиальная задача. А во-вторых, владеть достаточным количеством знаний одновременно во всех областях, влияющих на успешность цифрового продукта, невозможно. Для решения этих проблем принято формировать команды разработки. В таких командах существуют узкоспециализированные роли, такие как специалист по обеспечению качества (Quality Assurance, QA), специалист по поисковой оптимизации (Search Engine Optimization, SEO), графический дизайнер, специалист по вёрстке, специалист по продажам, менеджер проекта, программисты, которые обычно специализируются на определённом направлении и стеке технологий и многие другие.

Такое разделение на роли является достаточно условным. Бывает так, что программист может справиться с задачами по вёрстке, потому что ему часто приходится вносить небольшие правки в шаблоны веб-страниц, Или QA начинает программировать, потому что он учится этому в процессе работы с автоматизированными тестами. Подобных схем довольно много.

Ещё один неотъемлемый участник проекта — бизнес-аналитик (Business Analyst, BA). Он является своего рода специалистом «по связям с общественностью», основная задача которого заключается в анализе запросов заказчика и составление функциональных требований, необходимых программистам для работы.

Проблема: аналитик как промежуточное звено

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

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

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

Проблема №1: Бизнес-цели заказчика перемешиваются с другими целями.

И тут в игру вступает бизнес-аналитик. Что он делает:

• внимательно выслушивает заказчика;
• тщательно всё записывает;
• детально всё анализирует;
• формулирует требования к продукту;
• составляет вайрфреймы (Wireframes) и утверждает их у заказчика.

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

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

Однако заказчик далеко не всегда прислушивается к мнению бизнес-аналитика. Мне довелось работать с заказчиком, который на комментарий «давайте это сделаем по-другому, иначе пользователем будет тяжело с этим разобраться» ответил: «Если им будет тяжело — пусть не пользуются моим продуктом».

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

Когда экспертиза субъективна

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

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

Проблема №2: Основаниями для функциональных требований является мнение заказчика.

Результат

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

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

Например, в одной авиакомпании бортовая мультимедийная развлекательная система для запуска фильма требовала содействия бортпроводника и была настолько неудобной, что перед длительными перелётами бортпроводники выводили её из строя, а потом просто объявляли пассажирам о её неисправности.

Если проект представляет собой коммерческий продукт, пользователи просто уйдут к конкуренту.

Решение: проектировщики взаимодействия

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

Вот чем занимается этот специалист.

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

Бизнес-аналитики — завтрашние проектировщики взаимодействия

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

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

Уже сейчас встречаются проекты, на 80% состоящие из исследований и на 20% из процесса разработки. Крупные компании, имеющие опыт сотрудничества с разработчиками ПО, для заключения новых контрактов на разработку объявляют тендер, который выглядит примерно так: «Вот у нас форма пожертвований, сделайте что-нибудь, чтобы повысить конверсию». Чёткая бизнес-цель, никаких «нарисуйте собачку или цветочек». Таких проектов со временем станет всё больше, а за крупными компаниями, поступающими таким образом, подтянутся и другие.

Как быть с графическими дизайнерами?

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

Что могут сделать остальные?

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

• какую пользу это принесёт бизнесу;
• какую пользу это принесёт пользователям.

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

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

Например:

Как зарегистрированный пользователь

для того, чтобы чувствовать контроль над своим лицевым счётом,

я хочу видеть остаток своего лицевого счёта.

----------------------------------------------------------------------------------------

Допустим, в системе существует пользователь «Вася Петров».

А также я выполнил вход в систему как «Вася Петров».

Когда я перехожу на страницу «Состояние лицевого счёта»,

тогда я вижу остаток своего лицевого счёта.

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

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

Что почитать?

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

• Алан Купер. Интерфейс. Основы проектирования взаимодействия. 4-е изд. 2016.
• Расс Унгер, Кэролайн Чендлер. UX-дизайн. Практическое руководство по проектированию опыта взаимодействия. 2011.

*Мнение колумнистов может не совпадать с позицией редакции.

Место солидарности беларусского ИТ-комьюнити

Далучайся!