После стажировки в КОРУСе я довольно быстро оказался на реальных проектах. И, как это часто бывает, проекты были далеко не учебные — крупные клиенты, сложные процессы и живая система, от которой зависит работа бизнеса.
Иногда со стороны кажется, что такие проекты — территория только для мидлов и сеньоров. Но на практике команды почти всегда состоят из специалистов разных грейдов. И это нормально.
За время работы я убедился: младший аналитик на проекте — это не ученик, который просто наблюдает. Это полноценный участник команды, который закрывает целый пласт прикладных задач. Особенно хорошо это видно на проектах внедрения и поддержки Битрикс24.
Меня зовут Семен Курганов, младший аналитик в департаменте CRM&BPM в «КОРУС Консалтинг», и в этой статье я поделюсь своим опытом работы младшим системным аналитиком на проектах Битрикс24.
Первый проект: сразу в реальную работу
Моим первым проектом стало внедрение Битрикс24 для производителя медицинского оборудования.
Когда я подключился к проекту, он находился на стадии проектирования. Команда уже провела большую работу: бизнес-аналитики описали процессы заказчика, подготовили артефакты и схемы. Первые несколько дней я знакомился именно с ними — погружался в предметную область и пытался понять, как реальные процессы компании будут ложиться на систему.
Проект состоял из двух крупных блоков: продаж и сервисного обслуживания оборудования. Я занимался сервисной частью: всем, что связано с обслуживанием проданного оборудования, гарантийными случаями, ремонтом и сервисными заявками.
Моя работа включала регулярные демонстрации системы заказчику. На этих встречах я показывал, как процессы могут работать в Битрикс24 и каким образом система может автоматизировать их работу. Интересно, что эти демонстрации одновременно стали и инструментом сбора требований.
На встречах заказчик показывал, что им особенно важно, уточнял детали процессов и отмечал, что мы поняли неправильно. После каждой такой демонстрации я возвращался к системе, дорабатывал настройки и на следующей встрече показывал обновлённый вариант. По сути это был интерактивный процесс уточнения требований через прототипирование системы.
Параллельно мы синхронизировались с командой 1С. У заказчика шло обновление системы на новую версию, и Битрикс24 нужно было интегрировать с ней. Поэтому частью моей работы стало составление реестра функциональных и нефункциональных требований для будущей интеграции.
Второй проект: поддержка большой системы
Почти параллельно меня подключили к другому проекту — поддержке крупного производителя шин.
Этот проект был совершенно другого типа. Если первый проект находился на стадии проектирования, то здесь система уже работала несколько лет. Но был нюанс: изначально внедрением занимался другой интегратор, который практи��ески не оставил после себя документации.
Когда команда КОРУСа перехватила проект, коллегам пришлось фактически разбираться в системе заново. К моменту моего подключения они уже проделали огромную работу и создали большую внутреннюю базу знаний по системе.
Пока заказчик оформлял для меня доступы — VPN, учетные записи и права — я знакомился с этой базой знаний и описаниями процессов. Но, честно говоря, без доступа к системе все это ощущалось довольно теоретически.
Когда доступы наконец появились, и я начал смотреть реальные процессы, существующие инциденты и задачи по доработке, понимание системы резко выросло.
Первая задача и первая ответственность
Я хорошо помню свою первую задачу на этом проекте.
Нужно было настроить доступ к запуску одного из бизнес-процессов. На первый взгляд задача не самая сложная, но ощущение ответственности было сильным. В тот момент я отчетливо понял одну вещь: я представляю не только себя, а всю компанию КОРУС.
К счастью, старшие коллеги всегда были готовы помочь: если возникали вопросы, мы, быстро созванивались, обсуждали проблему в чате или разбирали её вместе. Это сильно снижало стресс и помогало двигаться быстрее.
Когда начинаешь работать самостоятельно
Примерно через полтора месяца я почувствовал, что стал более самостоятельным.
Конечно, сложные вопросы всё ещё обсуждаются со старшими коллегами — и это нормально. Но многие задачи я уже веду полностью сам.
Например:
анализирую проблемные процессы;
моделирую проблемные ситуации;
нахожу возможные решения;
пишу постановки для разработчиков;
провожу тестирование.
Иногда мы вместе с разработчиками запускаем скрипты и проверяем результаты.
Один из таких случаев хорошо запомнился. В системе был бизнес-процесс, который должен был запускать PHP-код. Но процесс работал неправильно. Его настраивал ещё предыдущий интегратор, и в коде была ошибка.
Я разобрался в логике процесса, нашёл проблему и понял, как её исправить. После этого мы вместе с разработчиком на созвоне отредактировали код — и бизнес-процесс заработал корректно.
Это был тот момент, когда особенно приятно видеть результат своей работы.
Работа с клиентом
Ещё одна часть работы, которая мне нравится — это взаимодействие с заказчиком.
На проектах мы регулярно проводим совместное тестирование, обсуждаем задачи, общаемся в комментариях к задачам, отвечаем на вопросы пользователей.Такое общение помогает лучше понимать, как система используется на практике.
Я надеюсь, что в будущем на проектах появятся и командировки. Мне кажется, личные встречи с клиентами дают ещё больше понимания их процессов. К тому же я люблю путешествовать и общаться с людьми.
Как мы работаем внутри команды
Часто спрашивают, как младший аналитик взаимодействует со старшими специалистами.
На практике схема довольно простая. Когда возникает задача или проблема, я обычно действую так:
Сначала пытаюсь разобраться сам.
Если не получается — ищу ответ в базе знаний.
Проверяю документацию, гуглю, использую ИИ.
Если ответа всё ещё нет — обращаюсь к мидлу.
Если вопрос сложный — подключается сеньор.
Но на практике большинство задач удаётся решить на первых этапах. Это позволяет экономить время старших коллег, чтобы они могли фокусироваться на архитектуре решений и стратегических вопросах.
Немного про эффект Даннинга — Крюгера
В процессе работы я столкнулся с интересным эффектом — эффектом Даннинга — Крюгера.
В начале работы система казалась довольно простой. Но чем глубже я погружался в проект, тем больше понимал, сколько всего ещё предстоит изучить.
Сейчас я гораздо лучше понимаю, где проходят границы моих компетенций, какие задачи я могу закрывать самостоятельно, а где лучше сразу обсудить решение со старшими коллегами.
И это, на мой взгляд, нормальная часть профессионального роста.
Почему джуны действительно полезны на проектах
Мой опыт показывает, что младшие аналитики могут приносить реальную пользу проектам.
Они закрывают целый спектр задач:
анализ работы процессов;
настройку системы;
тестирование;
подготовку постановок;
работу с инцидентами;
коммуникацию с пользователями.
Это позволяет старшим специалистам сосредоточиться на более сложных вопросах: архитектуре решений, интеграциях и развитии системы.
Что я бы сказал джуну, который боится сложных проектов
Иногда начинающие специалисты переживают, когда попадают на большой проект.
Если бы меня сейчас спросили: «Нормально ли, что джун работает на сложном проекте?»
Я бы ответил: «Да, это нормально».
Главное — две вещи: не бояться задавать вопросы и не терять интерес к системе и предметной области. Если тебе действительно интересно разбираться в процессах, в системе и в том, как все устроено — все получится.
А команда всегда подскажет.
