Специалисты, которые умеют выявить, что значит «хорошо» и как это спроектировать
Зачем ИТ-бизнесу нужны аналитики, какие они бывают и что делают — в интервью руководителя аналитической практики компании iFellow Анастасии Бильдановой.
Группа компаний iFellow работает на рынке информационных технологий с 2015 года. Основная специализация группы — развитие собственных продуктов, заказная разработка, ИТ-консалтинг, тестирование и сопровождение программного обеспечения.
Работает с клиентами сегмента enterprise. Входит в ТОП-5 разработчиков решений для финансового сектора в рейтинге Skolkovo Fintech Hub.
— Когда аналитики подключаются к работе с заказчиками?
Наша работа с клиентами может начинаться еще на этапе знакомства. Конечно, все зависит от запроса заказчика: когда нужны, например, только тестировщики, мы не участвуем. Но чаще всего мы подключаемся почти сразу и присутствуем практически на всех этапах работы.
Практику привлекают, чтобы понять, что «болит»: мы помогаем продавцам, подготавливая вопросы для выявления потребностей, понимания направления, куда предстоит двигаться при выполнении работ.
Мы можем коммуницировать и самостоятельно с техническими специалистами со стороны клиента, чтобы понять, какие есть ограничения, какие технологии им преимущественно необходимы.
В iFellow сформирована сплоченная рабочая группа, которая подключается к взаимодействию с клиентом по необходимости. Туда входят аналитики, разработчики и тестировщики, иногда привлекаются иные специалисты, но первыми всегда подключаемся мы.
— Какие задачи решают аналитики? В чем заключается ваша работа?
Я, наверное, отвечу университетской формулировкой: аналитики – это мосты, которые соединяют разные области знаний и помогают установить в них взаимосвязи. И сейчас много направлений аналитики, в каждой сфере существуют свои специалисты.
В случае с моей практикой, большинство специалистов — это системные и бизнес-аналитики, и различные вариации смешения этих областей.
В их обязанности входит выяснить, как обстоят дела у заказчика сейчас, какую задачу нужно решить и, соответственно, построить такое новое решение.
— В чем разница между системными и бизнес-аналитиками? Как определять, какой специалист с каким клиентом будет работать?
Весь прошлый год мы в компании шлифовали методику, по которой такое разделение происходит. Сотрудники практики распределены по разным проектам с разным уровнем вовлечения: где-то один сотрудник на проекте, в другом случае – несколько, и они обладают разными компетенциями.
Например, бизнес-аналитики должны быть хорошо знакомы с различными нотациями и проектированием бизнес-процессов. Системному аналитику вариативность этих нотаций и глубина их знаний не требуется, но умение применять хотя бы одну – необходимо. Ведь какую бы систему он не раскапывал, она так или иначе часть определенного бизнес-процесса.
Для системного аналитика важен уровень понимания архитектуры приложений: он должен хорошо оперировать понятиями этой компетенции, знать принципы построения. В то время как бизнес-аналитику достаточно поверхностно владеть этой информацией.
Но есть и общие для этих ролей навыки: например, умение работать с целями. Кроме того, встречаются проекты, где требуются аналитики уровня фулстек, то есть понимающие специфику работы и там, и там.
Для себя мы разработали матрицу компетенций, которая позволяет понять, какими навыками обладает каждый наш сотрудник, и максимально близко подбирать релевантного проекту специалиста.
Но в целом здесь история про «сколько людей, столько и мнений». Даже у профессиональных сообществ нет четких критериев разграничения этих компетенций: в каких случаях необходим бизнес-, а в каких – системный аналитик.
Восприятие заказчиков также разнится: есть клиенты, для которых бизнес-аналитик ориентирован именно на бизнес, оптимизирует процессы, выстраивает их последовательность и т.д. Для других такой специалист должен погружаться до уровня системы и писать верхнеуровневые требования к прикладным решениям: что должна делать система, как и т.д.
Третьи ждут от системного аналитика весомого набора компетенций в общении с бизнес-заказчиками. Именно поэтому на старте помимо сути самого проекта, мы определяем и набор скиллов, который понадобится клиенту. И здесь помогает наша матрица компетенций, а то, как будет называться роль специалиста, – уже второстепенный вопрос. Главное – получить максимально успешный симбиоз умений сотрудника и потребностей клиента.
— А с каким подразделениями наиболее плотно взаимодействуют аналитики?
Если говорить об iFellow, внутри нашей компании мы взаимодействуем со всеми подразделениями, потому что везде есть процессы и автоматизация. Очень важную роль в работе аналитиков играют коммуникации.
Если для разработчика или тестировщика эту компетенцию можно отнести к понятию soft-skills, то для аналитика это настоящий хард-скилл – умение правильно прокоммуницировать, выявить потребности, перевести информацию на нужный язык и передать дальше для реализации. Границы взаимодействия здесь зависят от проектов, которые мы реализуем для клиента.
Например, есть задача проектирования решений для обмена данными между двумя системами. В большей степени системному аналитику здесь придется коммуницировать со смежными командами разработки, которые отвечают за эти системы. Лишь изредка нужно будет выявлять соответствие бизнес-цели – у владельца продукта или бизнес-аналитика, если он есть. То есть, по большей части здесь будут коммуникации на техническом языке.
И совершенно иначе обстоит дело в выстраивании процесса работы двух подразделений. Допустим, это будут продажи и отдел учета в каком-нибудь процессе. Тут нужно уметь общаться с сотрудниками подразделений, чтобы понимать, что они делают и что можно оптимизировать, уметь показать им предстоящие изменения и обосновать их. А затем донести эти изменения до команд, которые будут их реализовывать, причем так, чтобы у всех сложилось одинаковое представление. То есть здесь коммуникации разносторонние.
— Можно ли обойтись на проекте без аналитика? «Размазать» его функции между другими специалистами.
Нужно смотреть на задачи в производственном процессе. Например, если нам нужен рефакторинг, улучшение кода, то здесь аналитик скорее всего не потребуется, либо понадобится в крайних случаях, когда разработчики натыкаются на код, который непонятно для чего был написан.
Посмотрим на бизнес-процессы: если у клиента есть сотрудники, которые четко понимают потребности своего бизнеса и процесса, готовы четко сформулировать, что нужно, то здесь можно красиво выстроить работу между бизнес-подразделением и уже непосредственно командой разработки.
Так или иначе, анализ всегда присутствует при проектировании процессов или системных решений. Но я считаю, что выделение для этой задачи отдельной роли всегда показывает более высокую эффективность работы. Это может очень сильно влиять на качество предоставляемого решения, на его дальнейшее развитие.
Полная, комплексная документация по разрабатываемому проекту очень пригодится в дальнейшем для масштабирования. При участии аналитиков скорость реализации проекта может быть чуть медленнее, но вот скорость внедрения уже готового решения и качество этого внедрения будут намного выше.
Что самое сложное в работе аналитиков?
Я уже говорила, что для аналитиков очень важны коммуникации, так вот они и есть самое сложное. Один из самых трудных и мало предсказуемых этапов работы – этап согласования. Согласование требований, документации, решения и т.д.
Тут важно понимать, с кем ты будешь договариваться, о чем, какие кейсы предстоит защищать, чем можно поступиться. Бывают легкие проекты, когда всем понятный функционал или процесс, есть один представитель заказчика – тут все проходит гладко и понятно. А бывают сложные кейсы, когда лиц, принимающих решение, несколько. И у них прямая конфронтация интересов. Здесь от аналитика реально ожидается просто мастерство ведения переговоров.
Последнее время в ИТ-отрасли эту роль чаще стали забирать на себя руководители проектов, но я придерживаюсь мнения, что хороший аналитик должен владеть достаточным уровнем аргументации по задаче, чтобы уметь защитить и обосновать свое решение. Все остальные этапы – это уже дело практики, накопление знаний и опыта.
— Но не всегда же заказчики четко формулируют, что необходимо. Как понять, что хочет клиент, и предложить подходящее решение?
Тут нужно копать в глубину. Для любого клиента мы стараемся выявить именно истинную потребность: зачем необходимо это решение, чего пытаемся добиться этим функционалом, какая конечная цель, на что она повлияет. И не всегда первоначальный ответ клиента сходится с тем, до чего мы можем докопаться.
От ответов на такие вопросы зависит дальнейший выбор прикладного решения, пути реализации, компетенция необходимых специалистов и множество других деталей. И каждое общение с заказчиком – это диалог.
С одной стороны, есть потребность клиента, который хочет в рамках времени и финансов получить качественный результат. А с другой – целый ряд ограничений, условий, истинных целей, для которых этот результат создается. И наши специалисты еще на первых этапах общения стараются помочь заказчику определить оптимальный путь достижения результата. И затем помочь его добиться, если дальнейшие переговоры проходят успешно.
Если кратко, то любой клиент хочет, чтобы было «хорошо». Сотрудники практики аналитики – специалисты, которые умеют выявить, что значит «хорошо», понять, кому должно быть «хорошо», и спроектировать это «хорошо» для дальнейшей работы.
