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

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

Дисклеймер

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

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

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

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

Прелюдия

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

Ещё смешнее (или грустнее) становится, когда на эту тему начинают рассуждать различного рода эйчары или методологи.

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

Возможно, вы задаётесь вопросом – почему я вдруг решила, что могу говорить об этом? Всё просто. Достаточно перечислить роли, которые я сменяю на протяжении любого своего проекта:

• бизнес-аналитик;
• системный аналитик;
• UI/UX-дизайнер;
• технический писатель;
• тестировщик;
• преподаватель;
• саппорт.

Если же речь идёт о проектах повышенной сложности и масштабности, с командой из нескольких аналитиков, среди которых могут оказаться новички, то дополнительно добавляются роли:

• наставник;
• Tech Lead;
• Team Lead.

И во всём этом многообразии ролей я работаю уже без малого восемь лет.

Рынок

Однако, начнём издалека. А точнее – с той ситуации, которая сложилась сейчас на рынке.

Если зайти, к примеру, на хедхантер и вбить в поисковую строку слово «аналитик», на нас обрушится всё богатство фантазий и интерпретаций на тему.

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

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

Достаточно популярна обтекаемая и ёмкая категория ИТ-аналитиков. В их описании, обычно, целое русское поле экспериментов с обязанностями, ограниченное, по сути, только сферой IT. Эти вакансии больше всего напоминают мне истории про тыжпрограммистов, у которых регулярно просят починить пылесос или чайник.

Честнее всех поступают те, кто хотя бы в названии пытается указать – что именно нужно будет «аналитить». В результате появляются совершенно разнообразные вакансии вида «аналитик SQL», «аналитик бизнес-процессов», «аналитик требований», «аналитик 1С», «аналитик продаж», «аналитик-маркетолог» и т.д. Впрочем, это не спасает от разности задач даже в вакансиях с двумя одинаковыми названиями.

Стандарты

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

Но не тут-то было.

Конечно, нужно радоваться, что стандарты всё-таки существуют, хоть и появились сравнительно недавно. Стандарту на системного аналитика осенью исполнится пять лет. Существенно позже подтянулся стандарт на бизнес-аналитика – ему даже года нет.
Интересно, что разницу между бизнес- и системным аналитиком эти стандарты декларируют уже на уровне кодов профессиональной сферы: для системного аналитика указан код 06, а для бизнес-аналитика – 08. Иными словами, системный аналитик причислен к профессиональной сфере «связь, информационные и коммуникационные технологии», а бизнес-аналитик – к сфере «финансы и экономика». И никакого вам IT.

Если же мы перейдём к целям профессиональной деятельности, закреплённым в стандартах, разница станет ещё более очевидной и занимательной. Системному аналитику, раз уж он отнесён к сфере IT, с чистой совестью вменена работа с требованиями, упоминается программное обеспечение, автоматизированные системы, в общем всё, как мы любим. Бизнес-аналитик в свою очередь работает не с требованиями, но с потребностями, однако цель его сконцентрирована на изменениях в организации, приносящих пользу. И, заметьте, ни слова о системах или программно-аппаратных комплексах.

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

Миссии

Перейдём к конкретике.

Любой проект, в котором участвует наш аналитик, так или иначе проходит 4 глобальные миссии, назовём их – пресейл, предпроект, проект и внедрение. Безусловно, аналитик может участвовать не во всех миссиях, а изолированно подключаться на любую из них, но раз уж мы переходим в режим супергероя, давайте детально поговорим о каждой. Сразу оговорюсь, сопровождение, как миссию, я убрала из списка вполне сознательно, т.к. считаю нерациональным держать на этих задачах высокоуровневого специалиста.

Pre-Sale

Первая миссия – это, конечно же, пресейл.

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

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

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

Предпроект

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

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

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

Постепенно погружаясь в контекст будущего проекта, аналитик вычерчивает его рамки и определяет, на какие условно-изолированные составные части можно будет его разделить. После чего, уже совместно с руководителем проекта, распределяет команду по выделенным блокам. Здесь очень важно учитывать взаимосвязи модулей будущей системы и понимать, какой именно объём работ может быть безболезненно выделен в независимый блок.

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

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

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

Проект

Основная работа, конечно же, начинается непосредственно на проекте. Именно на этом этапе происходит постоянная смена ролей.

Сперва аналитик плотно работает с Заказчиком в роли бизнес-аналитика. При этом он может либо эпизодически выезжать на встречи и интервью, либо вообще находиться на территории Заказчика в режиме фулл-тайм. На этом этапе проводится глубокое исследование процессов компании, выявляются узкие места и потребности в автоматизации, оказываются консультации по возможным решениям обнаруженных проблем. Причём эти решения могут быть не только системными, но и административно-организационными. По итогам исследования рождаются детальные схемы и описания бизнес-процессов «as is» и «to be», со всеми тонкостями и возможными вариантами развития событий. Попутно выявляются и собираются требования к объектам будущей системы.

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

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

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

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

После завершения этапа документирования, фундаментальный труд проходит минимум два рецензирования – ведущим аналитиком и ведущим разработчиком команды. А при возможности – ещё и внешнее рецензирование коллегами из других команд и проектов. После рецензирования документ отправляется на согласование Заказчику. Причём не сваливается на него непонятным многостраничным талмудом, а сперва демонстрируется в виде презентации с пояснениями, песнями, плясками и весёлыми картинками. Далее аналитик сопровождает процесс согласования, отвечая на вопросы Заказчика, корректируя те или иные формулировки, доуточняя, при необходимости, требования и решения. После успешного завершения согласования документ отправляется в разработку.

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

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

Внедрение

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

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

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

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

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

Рано или поздно проект завершается, передаётся в поддержку выделенным службам, а наш аналитик получает заветный носок.

Bonus-level

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

В первую очередь – это наставничество. Каждый новый сотрудник компании обязательно получает персонального наставника на первые 3-4 месяца работы. Наставник составляет персональный план развития, помогает новичку адаптироваться, изучить продукты и технологии, узнать всё о внутренней кухне, и в целом становится практически родной матерью.

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

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

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

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

Epic-fail

Ну не может же быть всё так радужно, скажете мне вы. И окажетесь правы. Рано или поздно нашего аналитика подстерегает самая большая ловушка под названием – overqualified.

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

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

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