Екатерина Канаева

Начнем с традиционного — кто ты в профессиональном плане?

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

То есть, есть сопутствующие вещи, и их много, но бизнес-анализ — это основное.

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

По сути, последние 11 лет — сколько работаю в ЭПАМ — я занимаюсь бизнес-анализом и только им.

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

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

Иногда мы размещаем вакансию, и на нее откликаются люди с чистым профилем бизнес-аналитика — системный анализ они в своей работе не встречали.

И они не получают оффер в итоге.

Не получают.

Потому что по умолчанию компания ищет именно системных аналитиков.

Не могу сказать, что это на 100% системный анализ, но да.

Объясни разницу этих двух профессий.

Для меня грань проходит так: у каждой организации есть цели, и для достижения этих целей она выстраивает бизнес-процессы. В это вовлекаются различные люди, оборудование, все это интегрируется в какой-то информационной платформе, в основе которой лежит технологическая платформа — данные, сервера, код и т.д. Так вот: бизнес-аналитик, на мой взгляд, спрашивает у бизнеса — а что это за процессы, зачем это нужно — и на этом останавливается. Системный аналитик вдобавок к этому идет и думает, как это вписать в информационную систему, которая есть, или которая предполагается к реализации. Что там за программное обеспечение, как строятся обеспечивающие системы и так далее. То есть он не только задает, “что” делает система, но и помогает ее спроектировать.

Бизнес-аналитик зачастую не может сформулировать требования в виде, который достаточен для технической команды, чтобы взять их и сделать требуемое. А системный аналитик — может.

Бизнес-аналитик анализирует бизнесовые показатели, системный смотрит на техническую сторону, так?

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

Хорошо. То есть системный аналитик — это мостик между заказчиком и технической командой.

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

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

А иногда и просто невозможно.

То есть аналитик — это переводчик?

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

Получается, не просто переводчик. Давай развернем вопрос: почему недостаточно просто передачи информации? Должен же этим кто-то заниматься?

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

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

“Простой транслятор” записал вопрос от разработчика, никак его не переработал и отнес заказчику. Тот вопрос как-то интерпретировал, ответил, а разработчик понял, что это никак его к решению не приближает. И процесс уточнения этого вопроса может проходить несколько итераций, до получения окончательного ответа. Это плохой вариант.

В хорошем аналитик получает вопрос и не знает ответа, так как, например, не обсуждал это с заказчиком. Тогда он как минимум запрашивает возможные варианты разрешения и прорабатывает с разработчиком детали вариантов A, B, C, D — реализуемость, стоимость, зависимости и так далее. И тогда мы не только отбрасываем часть вариантов, но и четко понимаем, в чем именно состоит затруднение разработчика, максимально конкретно формулируем вопрос и передаем его заказчику наиболее подходящим способом. Потому что иногда достаточно  просто письма или письма со скриншотом и схемами, а какие-то вопросы слишком сложные, и их надо обсуждать лично на отдельной встрече.

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

Я правильно понимаю, что наши бизнес-аналитики чаще вырастают из технических специалистов? Ну или, по крайней мере, у них должен быть технический бэкграунд из вуза или прошлой работы?

Это не всегда так. Пул аналитиков в саратовском ЭПАМе не так велик, их около 20 человек, и я знаю прекрасных аналитиков без технического образования. Иногда достаточно просто интересоваться техническими вопросами и постигать технические знания на практике, не бояться их. Некоторые специалисты перед тем, как перепрофилироваться в аналитики, проходили специально курсы программирования, погружались в отрасль.

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

Не всегда. Иногда задача ставится в виде “А сделайте нам вот эту кнопку на той форме”.

Так. И что должен сделать аналитик в этом случае?

Он должен спросить: “Зачем?”.

Как это — зачем? Вам трудно, что ли? Сделайте и все!

Нам нетрудно, мы сделаем. Но на следующий день после выхода в продакшн приходит письмо от заказчика с вопросом: “А почему в этом отчете я не вижу значений, которые я вводил в это поле???” А никто и не знал, что эти данные должны куда-то попадать.

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

Это частный случай, когда с той стороны тоже техническая команда. В общем же смысле два языка — это технический и бизнесовый. Вот этим, вторым языком, как овладеть?

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

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

Согласен.

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

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

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

Получается, аналитик по определению самый упорядоченный член команд.

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

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

Давайте определимся, что мы считаем требованиями?

Талмуды или многостраничные сервисы, где описано, как должна вести себя система.

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

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

Замечу, что в достаточно сложных системах даже не очень аджайльные команды сталкиваются с этим же, ну да не суть. Гибкие методологии хаосу способствуют, согласен.

Есть ли какие-то специальные инструменты воспитания аналитика, или главное  — это практика? Своди команды, учи языки, пиши требования?

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

И мы переходим к вопросу “Как быть хорошим бизнес-аналитиком?”. Что еще для этого нужно?

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

Дороже ошибки аналитика только ошибка архитектора.

Или врача. Еще важное качество для аналитика — это умение быстро учиться. Часто приходится сталкиваться с новыми процессами, бизнесами, областями знаний. Мы отбираем тех, кто умеет быстро учиться, потому что если человек дожил до 25 лет и не приобрел этот навык, он может его уже и не получить. Люди, которые сидят и ждут, что новые знания им разжуют и в рот положат, в аналитике не нужны. А может, и в айти не нужны.

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

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

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

Есть ли что-то еще, что нужно добавить в копилку качеств хорошего аналитика?

Скорость обучения и гибкость ума в широком смысле слова — важные навыки. У нас очень много точек контакта в работе, и есть еще специфика, которая иногда выносит мозг. Аналитик живет в будущей системе, которая еще не реализована. Он ее придумывает прямо сейчас. Tут приходит вопрос из прошлого: “Как устроено …”, а ты уже работаешь над другим модулем. И нужно моментально переключиться между участками системы и между состояниями системы — актуальным и будущим. Все это вместе —  большое количество людей, разных контекстов и необходимость переключаться между ними — создает нагрузку на аналитика. И приходится как-то к этому приспосабливаться, например, разбивать день на участки, когда ты прорабатываешь документацию, и когда ты отвечаешь на всевозможные вопросы. Без тайм-менеджмента никуда.

Серьезная внутренняя дисциплина должна быть.

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

Ну как же непонятно. Ты говорила про то, что аналитик живет в будущей системе. А программист не просто в ней живет — он ее реально строит. И глубина детализации, погружения в эту будущую систему у хорошего разработчика на порядки выше. Это его мир, где все будет так, как он придумает. И переключение этих модальностей  “ Я творю мир” и “Я общаюсь с другими” — оно больших усилий требует.

А аналитик на полшага там, полшага тут.

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

Здорово, что все мы разные, и у всех свои задачи. Главное — найти свое место для каждого человека.

И тут следующий вопрос — что для тебя хорошего в работе аналитика? По нашей беседе рисуется довольно тяжелая картина: стрессы, масса людей все время чего-то хотят от тебя, и ты между ними постоянно переключаешься. А что хорошего?

Забавно со стороны взглянуть. Для меня в этой работе самое приятное —  выстраивать взаимодействие. Когда есть контакт, когда все сошлись и нашли взаимопонимание. Если нет меня, связующего звена, то и результата хорошего не будет. Именно с моей помощью эта магия, по сути, и свершается. С полуслова понять обе стороны, найти точки соприкосновения, сформировать оптимальное по пользе и бюджету решение — вот моя работа. Простой транслятор так не сможет.

Я так понимаю, что ты не только работаешь аналитиком, но и занимаешься развитием сообщества аналитиков, воспитываешь молодых специалистов. Можешь сказать, по степени важности, или по вкладываемым силам, как распределяются эти две активности?

Работа с людьми всегда отнимает много сил. Наши группы обучения не бывают массовыми. Воспитать враз 10 аналитиков очень трудозатратно.

А сколько можно воспитать?

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

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

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

Факультативная деятельность отнимает много сил,  но не заниматься этим ты не можешь. Почему?

Во-первых, таких специалистов нигде не готовят. Не существует вузов, которые воспитывают аналитиков. Есть предмет “Системный анализ”, но специалистов не воспитывают. Наши аналитики — или выпускники наших курсов, или самоучки, но их не так много. Софт скиллз, или курсы коммуникации, которые я веду, логично вытекают из всего, о чем мы говорили. До недавнего времени я бы сказала, что большинство проблем на проекте возникали из-за коммуникаций — кто-то не так понял или не так объяснил и так далее. В последнее время мое понимание несколько углубилось, и я понимаю, что в основе этого лежит нехватка эмоционального интеллекта. То есть коммуникация как таковая идет нормально — интерпретация полученной информации хромает. В разговоре всегда можно понять, если в данный момент человек тебя не слушает, он не здесь, а в каких-то проблемах, а ты продолжаешь ему доносить важные для тебя мысли и через полчаса обижаешься, что он тебя не услышал. Это нельзя назвать проблемами в коммуникации — человек тебе все сказал, только невербальными средствами, это ты его не услышал.

Можно еще примеров, чему вы пытаетесь учить людей?

Мы больше пытаемся не учить, а, скажем так,  поднимать уровень осознанности в самом широком смысле этого слова. Все люди разные, с разным жизненным опытом и контекстом.  В книге Александра Звонкина я почерпнула ценную мысль: “Вопросы важнее ответов”. Если человеку, не давая никаких объяснений, задать вопрос, к примеру: “А как ты думаешь, что такое эмоциональный интеллект?” — и если его это зацепит — то подспудно, невольно он будет думать над этим вопросом и так или иначе ответ найдет.

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

Что на выходе получает человек, после занятий в софт скиллз?

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

Давай еще раз про осознанность.

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

Мы делимся тем, что узнали сами, и передаем всем, кому это интересно. И я вижу, что многим это полезно.

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

Ты не думала выйти за пределы компании и вести сообщество бизнес-аналитиков всего Саратова?

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

А  на эту открытую встречу по бизнес-анализу много пришло людей из других компаний?

Цифр у меня нет, но люди приходили.

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

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

Может быть, потому, что аналитиков в компаниях очень мало. Да и мне кажется, что так или иначе аналитиков учат везде, может быть, это просто не формализовано.

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

Есть много историй с тех же собеседований, когда человек несколько лет работает аналитиком «как умеет», и нет никого, кто помог бы ему, направил или подсказал, что вообще-то можно и по-другому. У меня свой проект и свои проблемы, у тебя свои. И каждый варится в своей каше. В ЭПАМ Саратов все по другому: есть стандарт профессии, разработанные матрицы компетенции, есть активное внутреннее сообщество по обмену опытом, менторинг, наставничество, благодаря которым лучшие мировые практики и промышленный опыт применяются для обучения молодых специалистов.

Каково будущее этой профессии, как она будет развиваться? Какие-то тенденции можешь отметить?

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

Другая тенденция вытекает из предыдущей: аналитик становится более вовлеченной в создание продукта (в данном случае IT-продукта) фигурой,  и часто говорят о трансформации профессии со временем в “Product Management”. Но в целом это означает только то, что мы овладеем в дополнение к тому, что уже умеем, новыми компетенциями, но и старые нам будут все еще очень нужны. И уж конечно нам пригодятся наши софт скилы, быстрая обучаемость и умение обрабатывать и анализировать большие объемы информации.