Зачем нужен аналитик на проектах

28.12.2016

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

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

Этот человек – аналитик.

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

Что делает аналитик?

1. Понимает потребности клиента. Предположим, компания А хочет видеть в формализованном документе новое поле. Казалось бы, простое пожелание. Но, во-первых, это уже решение определенной потребности, и на деле вариантов реализации может быть множество; а во-вторых, обычного пожелания крайне мало для разработки. Поэтому аналитик приходит с уточняющими вопросами:
• С какой целью будет использоваться новое поле?
• Для чего нужно видеть это поле?
• Какая информация будет передаваться в нем?
• Откуда берется эта информация?

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



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


3. Систематизирует и визуализирует полученную информацию. В некоторых случаях действительно достаточно описания терминов, детализации потребностей и краткого описания требования, если это маленькая задача, как у компании А по добавлению поля. Но если мы говорим о компании Б, для которой нужно воплотить в жизнь электронный факторинг, то полученные результаты исследования, общения с клиентом нужно систематизировать. Скорее всего потребуется:
• изобразить бизнес-процесс схематически и коротко его описать;
• выделить потребности и требования клиента, которые касаются создания новой системы или изменения существующей;
• обсудить и согласовать с заказчиком приоритеты реализации требований.

Сбор информации

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

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

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

Как действует аналитик?

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

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

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

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

Что получает клиент, благодаря участию аналитика?

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

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

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

И еще несколько плюсов:

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

В свою очередь аналитики Synerdocs готовы не только оказать разностороннюю помощь на проекте, но и проконсультировать по самым различным темам - от применения электронной подписи до подключения контрагентов. Ежемесячно в разделе "Консультации" на сайте www.synerdocs.ru аналитики отвечают на вопросы пользователей, доказывая свою компетентность во многих аспектах ЭДО.

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

Автор: Анастасия Щепина, аналитик Synerdocs