Аналитик в ИТ — это специалист, который является своеобразным «мостом» между бизнесом и технической командой. Его основная роль — понимать и преобразовывать бизнес-требования в задачи, понятные разработчикам и инженерам. В работе аналитикам пригодятся технические знания, а также навыки коммуникации и аналитического мышления.
В этой статье мы решили посмотреть на профессию через призму необычных вопросов, которые задали Даниилу Иванову — аналитику из департамента CRM и BPM из КОРУСа.
О СТАРТЕ РАБОТЫ В КОРУСе
Даниил, когда и как ты попал в компанию? Какой карьерный трек уже смог пройти?
Моя коллега с прошлого места работы (это был небольшой интегратор, связанный с Битрикс24) перешла в какой-то момент в КОРУС. Мы с ней продолжили поддерживать деловые связи и периодически общались. В какой-то момент она стала рассказывать про свою новую работу, и я поймал себя на мысли, что работа и атмосфера в КОРУСе меня привлекают гораздо больше, в том числе с точки зрения развития. Я нашел в КОРУСе вакансию аналитика, откликнулся, успешно прошел собеседование, получил оффер, и вот я здесь, тоже в направлении Битрикс24.
За 3 года в компании я прошел путь от middle-аналитика до ведущего аналитика, роль которого выполняю сейчас на всех своих проектах. Как говорит генеральный директор компании Александр Семенов: «КОРУС — это платформа». Эта концепция подразумевает уникальные возможности для роста сотрудников и новых бизнесов, а также энергичную и мотивированную команду, которая не боится брать на себя ответственность использовать эти возможности. Условия КОРУСа как платформы, интересные проекты и люди, которые меня окружают, стали значимой движущей силой моего развития.
С самого начала у меня был очень классный наставник, который сейчас является руководителем нашей группы аналитиков. Он дал много ценных знаний в плане эффективного подхода к работе на проектах, умения делегировать задачи и так далее. И масштабы самих проектов в КОРУСе несравнимы с проектами в моей предыдущей компании. Это тоже заставляет постоянно подтягиваться до определенного уровня и расти.
НЕОБЫЧНО О ПРОФЕССИИ
Как бы ты объяснил бабушке, чем занимаешься сейчас на работе?
Это один из самых легких вопросов для меня, потому что я стабильно 1 раз в год объясняю своей бабушке (и бабушке жены), чем занимаюсь на работе. Во-первых, нельзя упоминать слово «компания». Им это непонятно. Надо говорить слово «фирма». А еще они понимают слово «контора».
Я говорю, что наша фирма помогает другим фирмам работать эффективнее, быстрее развиваться и зарабатывать больше денег за счет внедрения современных технологий. А я — тот человек, который выясняет:
- В чем именно наша фирма может помочь другой фирме
- За счет каких конкретных инструментов и технологий мы можем сделать их работу лучше и эффективнее
Обычно этого объяснения хватает на год, а потом приходится повторять.
Профессия аналитика только для людей с аналитическим мышлением?
Хотелось бы ответить «нет»: приходите все, кому деятельность аналитика интересна, и пробуйте. Но не хочется давать какие-то надежды людям, которые не то чтобы не обладают аналитическим мышлением (мне кажется, оно так или иначе есть у всех), а тем, которые просто мыслят иначе. Если по умолчанию человек не привык смотреть на всё через призму условного абстрактного аналитического мышления, думать:, зачем это нужно, кому это нужно, какой в этом во всём смысл, как мы будем решать эту задачу, зачем мы эту задачу решаем, на мой взгляд, ему будет тяжеловато.
Аналитик находится на стыке между разработчиками; бизнесом; стейкхолдерами; лицами, принимающими решение; руководителем проекта и всеми остальными, но он сам должен иметь в голове полную картину того, что происходит на проекте. Поэтому я бы сказал, что аналитическое мышление очень нужно аналитику.
Можно ли использовать искусственный интеллект (ИИ) в твоей работе?
Сто процентов да, не просто можно, а нужно. Мне кажется, что сейчас это — must have. Видно, что между компаниями, которые понимают ценность ИИ, начинается настоящая гонка — кто раньше поймет, как правильно использовать его инструментарий.
Я начал пробовать ИИ в работе еще до того, как это стало мейнстримом: года 4 назад стал изучать и смотреть, какие есть модели, что они умеют. Даже писал статью на Хабр про ИИ, и как он помогает в работе аналитикам.
Я сам лично в ежедневном режиме использую ИИ для рутинных задач (транскрибировать встречу и получить текстовую выжимку), а также для постановки задач разработчикам, подготовки детализированных повесток, черновиков, схем. У меня и моих коллег есть довольно много проверенных промптов, которые мы с удовольствием используем.
Но при этом ИИ — не панацея, он не делает работу за аналитика. Нет такого, что ты закинул один промпт, написал две строки, скопировал результат и вроде как сэкономил себе один день или сколько-то часов. В любом случае нужна дополнительная валидация, вычитка, корректировки. Это важно понимать.
Нужно ли аналитику писать код?
Если коротко, то нет. Для этого есть специально обученные люди — разработчики. Чаще всего аналитик вообще никак не взаимодействует с кодом, это — не его задача.
Но многое зависит от платформы и продукта, с которым работает аналитик. Например, я работаю в направлении Битрикс24 и, внедряя CRM на базе этой платформы, иногда сталкиваюсь с задачами, где нужен код. И могу через тот же самый ИИ пару строчек какого-нибудь нужного мне кода получить, но скорее не для того, чтобы решить задачу в итоговом её исполнении, а для тестирования какой-либо гипотезы, чтобы не тратить время разработчика.
Есть еще другая сторона в виде умения прочитать код. Вот это штука полезная, когда на базе стека платформы, с которой работает аналитик, и используемых ею языков программирования, он понимает хотя бы в общем виде, как устроен этот язык, и что там в коде содержится. Ты смотришь на какой-то кусок кода и, не отвлекая разработчика, понимаешь, что он делает. Часто это помогает на более поздних этапах проектов, когда начинается опытная эксплуатация, этап сопровождения и поддержки, и нужно в чем-то разобраться.
Оценивая свою роль в проектах, с каким супергероем ты бы себя сравнил и почему?
Недавно я посмотрел фильм «Фантастическая четверка». Пусть это будет Мистер Фантастик, который очень сильно тянется во все стороны.
В проекции на профессию, с одной стороны, в проекте нужно одновременно дотягиваться до разных точек — до клиента, системы, требований, документации. Ты пытаешься за всё удержаться, тебе важно ничего не отпустить, иначе всё полетит. В обратную сторону это тоже работает. В фильме есть сцена, где главный злодей берет Мистера Фантастика и растягивает во все стороны. Жутко, но в работе тоже такое иногда происходит, и нужно найти баланс и не разорваться.
Какую самую странную или нестандартную задачу тебе приходилось решать?
Если говорить про отдельно взятые задачи, то ничего такого нестандартного или странного в работе аналитика нет. Ты просто решаешь задачи, сначала они для тебя новые, а потом перестают ими быть.
Поэтому я вспомнил скорее не про отдельно взятую задачу, а про процесс. Когда я работал на предыдущем месте, к нам пришел заказчик, который не сразу объяснил, в чем смысл деятельности его компании, а когда весь пазл сложился, я даже удивился. Это было небольшое ИП с парой сотрудников, связанное с нотариальными и юридическими услугами. Потом он направил схему бизнес-процесса компании. Мы начали её изучать, смотреть документацию, задавать вопросы. В итоге мы поняли, что процесс связан с выкупом акций некоего предприятия у наследников умерших людей.
Сотрудники ИП каким-то образом узнавали, что есть определенные держатели большого количества акций. И нередко получалось, что их наследники (если с этими людьми что-то случалось), не очень понимали, что с акциями делать (особенно если никогда в эту тему не вникали). Сотрудники ИП каким-то образом находили этих людей и к моменту вступления в наследство выкупали у них акции за не очень большие деньги. Для наследников это был быстрый способ их обналичивания, потому что в целом процедура достаточно сложная, не все хотят в ней разбираться. Куда дальше переходили акции я не знаю, но сама бизнес-модель мне тогда показалась забавной, поэтому и запомнилась.
Кто важнее, аналитик или руководитель проекта (РП)?
Вопрос немного провокационный Это примерно как сравнивать, что важнее для автомобиля — руль или колеса. При этом не всегда руководитель — руль, а аналитик — колеса. Роли в проекте могут очень динамично меняться между собой.
Возьмите проект, в котором есть РП и аналитик, отправьте одного из них в отпуск, и второму сразу станет понятно, что без первого, который в отпуске, проект никуда не уедет. Обе роли важны, но у каждого своя зона ответственности. Аналитик отвечает за итоговое проектное решение, за то, как это будет реализовано. У руководителя проекта в какой-то степени больше ответственности, потому что он в итоге отвечает за проект, бюджет и сроки. Каждый выполняет свою функцию и важен, как в автомобиле руль, колеса и все остальное.
А реально ли в принципе обойтись без аналитика в команде?
Я недавно смотрел шуточный ролик про то, как родилась профессия бизнес-аналитика. Общаются заказчик и разработчик. Заказчик описывает, что ему нужно, разработчик слушает, что-то делает (как он это понял), и потом оказывается, что вообще никто друг друга не понял. Один имел в виду одно, другой услышал по-другому.
В какой-то момент они поняли, что им нужен переводчик, и этим человеком стал аналитик. Самое забавное, что стороны порадовались: «У нас появился переводчик с глупого на умный!». И каждый был уверен, что глупый — на той стороне.
Без аналитика, в принципе, существовать можно, как и выйти без зонта в ливень — ничего глобально страшного не случится, но результат, скорее всего, будет не тот, который ожидался. Возвращаясь к посылу шуточного ролика, скажу, что аналитик — важный переводчик с языка «хочу космический корабль» на язык «мы делаем не космический корабль, а батут, но с красивой кнопкой… нам этого хватит» с пониманием того, зачем эта кнопка нужна, и насколько высоко должен подбрасывать батут.
Как бы ты назвал книгу о своей работе?
Небольшая отсылка. Недавно я был в отпуске в Карелии, где в составе организованной группы сплавлялся по реке. В какой-то момент мы попали в небольшую «бочку», нас начало заворачивать, и чтобы выбраться, всем пришлось очень активно грести веслами.
Я подумал, что книга про мою работу могла бы называться «Нескончаемая гребля». А на обложке должны быть изображены все члены и стороны проектных команд в разных ролях: разработчик, аналитик, бизнес-заказчик, стейкхолдеры. На проектах все куда-то «гребут», зачастую в разные стороны, поэтому в «бочке» можно оставаться долго. Но нужно собираться и думать, как сделать так, чтобы пойти дальше вперед.
Как не запутаться в большом количестве рабочих данных?
Здесь можно вернуться к вопросу про аналитическое мышление. Аналитик по роду своей деятельности должен быть достаточно системным во всем, в том числе в организации своего рабочего процесса и пространства. Без этого наверняка потеряешься в большом объеме рабочих данных.
Здесь на помощь приходят специальные инструменты: трекеры для задач (типа Jira), базы для документации (типа Confluence), хранилища данных для записей встреч. Хорошо, если разные инструменты синхронизированы или в данных расставлены перекрестные ссылки.
Поддержание такой системы трудозатратно в моменте, но если эту привычку выработать, то в перспективе это поможет быть в контексте ситуации и действительно не потеряться.
Плюс еще какой-нибудь собственный трекер для отслеживания личных и рабочих задач тоже неплохо было бы иметь.
ВМЕСТО ЗАКЛЮЧЕНИЯ
Что тебе нравится, а что раздражает в профессии?
Нравится то, что суммарно уже почти за 5 лет работы аналитиком мои задачи глобально никогда не повторялись. На уровне микро задач, конечно, делаешь примерно одно и то же, но с точки зрения всего процесса и бизнеса каждый раз взаимодействуешь с разными людьми. Они мыслят по-другому, по-разному описывают даже схожие процессы, сами процессы зачастую отличаются, как и сферы бизнеса. Классно, что за небольшой период активной фазы проекта ты погружаешься в новый для тебя бизнес. Это помогает развиваться и не стоять на месте, потому что ты все время изучаешь новое.
Раздражают в работе нередкие изменения –, требования, которые случаются прямо перед выходом в опытную эксплуатацию или перед сдачей проекта. Классика, когда бизнес описал свои процессы, и мы уже провели этап бизнес-моделирования, внедрили всё по требованиям, протестировали, всё отлично, а потом бизнес приходит и говорит: «Мы забыли тут еще N процессов, а эти 2 у нас поменялись, а вот это вообще теперь не существует, давайте быстренько что-то сделаем и будем выходить через неделю в опытную промышленную эксплуатацию». Я к этому привык, но иногда это ненадолго выбивает из колеи.
Какой карьерный рост у аналитика?
Он достаточно простой, но при этом интересный. Начинающему аналитику классно пройти стажировку (в КОРУСе они регулярно проводятся). Например, в июле этого года у нас в департаменте CRM была масштабная стажировка по всем направлениям, и часть ребят потом остались у нас и работают сейчас младшими аналитиками.
Потом идет три стандартных грейда аналитика, как и везде в IT, это: младший аналитик (джуниор), миддл-аналитик и ведущий аналитик. Собственно, я сейчас на этой позиции и нахожусь.
Дальше всё зависит уже от желания человека. Можно остаться на позиции ведущего аналитика и просто менять разные системы, платформы, сферы бизнеса, с которыми ты работаешь. Но если хочется еще дальше, то я лично для себя вижу два основных трека:
- Если хочется «закопаться» еще глубже в систему и понимать вообще всё до атомов, включая стек платформы, с которой работаешь, то можно стать функциональным архитектором.
- Если больше нравится работать с командой в плане координации и управления, взаимодействия с заказчиком, то можно перейти на руководителя проектов.
Дай совет начинающим аналитикам.
Дам несколько.
- Шуточный, но правдивый. Желательно как можно быстрее научиться читать мысли. Хотя даже это не гарантирует того, что требования будут поняты правильно. Аналитик — немного психолог, который должен понимать, что не всегда то, что говорит заказчик, это то, что он на самом деле хочет. Надо уметь это подмечать и правильно выявлять истинные требования.
2. Начинающему аналитику нужно запомнить, что при проведении интервью и сборе требований его главные и любимые вопросы должны начинаться со слов «Что» и «Зачем». Что мы хотим сделать? Зачем мы хотим это сделать? Какая у этого цель? Вопросы из серии «в какой системе, какими инструментами, как мы это разработаем, сколько это стоит?» — вторичны (по крайней мере для аналитика в начале проекта).
3. Привыкнуть и научиться документировать и протоколировать абсолютно всё. Потому что всего, что обсуждалось на встрече, но не было зафиксировано в письме, не существовало. Я сам прошел через это. Вы с заказчиком что-то обсудили, ты это запомнил в голове, а через полгода, когда проект подходит к концу, заказчик говорит: «Да я в жизни этого не мог произнести». А у вас нет ни записи встречи, ни протокола. И выкручивайся, как хочешь.
4. Нередко аналитики и разработчики находятся в состоянии некоторого «противостояния»: до какой степени должно быть детализировано то, что хочет сделать аналитик, и то, что может в срок и в рамках заявленной оценки сделать разработчик. Начинающим аналитикам важно ценить тех разработчиков, которые без прикрас «приземляют» тебя после первого прочтения документации. Иногда это может показаться грубоватым, потому что разработчики по-разному выражают свои мысли. Но это очень ценные диалоги, которые позволяют лучше понять, что, в принципе, ваша команда может сделать как одно целое, а не только ты как аналитик.
