Сейчас рынок системного анализа переживает бурный рост и на это есть несколько причин:  

• низкий порог входа (по сравнению с Java-разработчиками, например)

• несколько хаотичные требования к системному аналитику на рынке труда (у каждой компании свое видение, кто это такой и чем он должен заниматься)

• узкая специализация, например, мало кто вообще в детстве мечтал стать аналитиком:)

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

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

Start to find или обдумаем все на берегу

Привет, это Полина, системный аналитик зарплатного проекта в Центре развития финансовых технологий Россельхозбанка. Я расскажу вам о том, как грамотно и максимально удачно выбрать компанию/проект, если ты — уверенный senior или middle аналитик.

1. Первое, ты как аналитик должен уже на этапе поиска нового места понять, что именно для тебя будет критически важным? То есть еще до собеседования необходимо проговорить самые важные для себя моменты.

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

2. Второе, надо постараться выяснить, кто будет с тобой в команде, особенно познакомиться с ведущим разработчиком и product’ом. C ними приходится работать рука об руку постоянно, и если изначально есть ощущение, что человек не твоего формата, то лучше не начинать свой путь в этом проекте. Вообще, самая сложная и частая проблема — это неудачно подобранная команда. От команды зависит очень многое, и если ты будешь игнорировать этот момент — скорее всего, придется бесконечно менять проекты и компании. Аналитик — всегда командный игрок.

3. Третье, трезво оценить свой уровень профессионализма. Есть проекты, где требуется нечто среднее между тестировщиком-разработчиком и нужно еще немного менеджера. И если чувствуешь, что это будет интересный опыт и ты такое выдержишь, тогда вперед! И обратная ситуация: проекту нужен Junior, а ты будешь пытаться склонить всех перебраться на Kubernetis. Но пока ты честно не ответишь себе, какие навыки и знания у тебя на высоте и насколько они уместны в данном конкретном случае, а каких и вовсе не хватает, ты так и будешь искать «свой проект», мотылясь от одного к другому.  

4. Четвертое, это деньги. Здесь уже каждый ориентируется на свой уровень комфорта и хотелок.

А какие бизнес-проекты рынок предлагает системным аналитикам? Я поделюсь теми, с которыми сама сталкивалась на практике.

Выбираем свой проект

Итак, на рынке вы столкнетесь с 5 типами проектов:

Новый проект

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

Проект в стол

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

Сложный проект

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

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

Проект-переросток

Название говорит само за себя. Если хочется какого-то экстрима, а на улице карантин — этот проект даст такую возможность. Такой тип проектов страдает от всех болячек разом, и обычно если уже этот этап наступил — обратного пути нет. Он, как черная дыра, требует множество ресурсов, при этом ни один объект не может вырваться за его пределы:) Под объектом я понимаю крутой функционал, который приносит прибыль бизнесу. Такие проекты чаще всего очень убыточны, при том что могут играть ключевую роль в процессах. Аналитик может очень сильно выгореть на этом типе проектов, но зато у вас появится опыт сложных переговоров и решения конфликтов. Потому что здесь, как в земном разломе, пробивается колоссальное количество конфликтов различных команд и т.д. В общем, будет весело! Но проектов-переростков очень много на рынке труда, так как на них наблюдается высокая нагрузка и большая текучка кадров. Здесь всегда требуются аналитики выше среднего, но если сами процессы построены некорректно, то один аналитик вытащить весь проект, скорее всего, не сможет.

Масштабируемый проект

Данный тип проектов имеет несколько характерных черт:

1. высокий порог входа

2. много коммуникаций с другими командами

3. как правило, нет явных требований от бизнеса, но есть бесконечный поток задач из бэклога, где их может быть более 1000

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

Куда смотрим или что нас ждет на рынке системного анализа

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

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

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

Поэтому, чтобы оставаться востребованными, аналитикам уже сейчас необходимо обращать внимание на то, как сделан макет, как его увидит клиент и вообще развивать в себе эстетический интеллект. Подробнее об этом в книге Полин Браун «Эстетический интеллект». В ней автор привела множество примеров: как крупный бизнес (Google, например) терял миллионы долларов, в случаях, когда никто не ставил в приоритет интересы и желания конечного потребителя. И как, благодаря крохотным деталям, продажи вырастали на 30-40%, просто потому что был изучен подробный портрет потребителя и его основные проблемы. Например, сделать перевод клиент может почти в каждом банке, но обращается почему-то к тому приложению, которым ему элементарно приятнее пользоваться, даже если оно имеет баги. Парадокс, но все же. Подумайте об этом.

Вы скажете, но есть же UX-дизайнеры? Да, все верно. Однако некоторые компании, к сожалению, не рассматривают позицию UX-дизайнера, как что-то принципиально необходимое. Иногда приходится работать и за дизайнера, и за UX-дизайнера. При этом некоторые компании практикуют аутсорс, но надо понимать, что это достаточно дорогие услуги и не всегда удобные. К чему я веду? К тому, что важно понимать основные тренды. Системному аналитику уже недостаточно иметь хорошую техническую базу, так называемые hard skills. Хотя без них вообще никуда. Но мы постепенно приходим к тому, что умение грамотно и качественно взаимодействовать с клиентом и дарить ему приятные эмоции — весомое преимущество на рынке аналитических услуг и не важно какая это сфера. При этом уже многие школы для аналитиков обращают внимание, что помимо SQL, asciidoc и знаний нотаций, аналитик должен еще уметь управлять эмоциями (не только своими). И называют это эмоциональным интеллектом. Хорошую книгу на эту тему написал Дэниэл Гоулман —  «Эмоциональный интеллект в работе».

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

• архитектор-аналитик в области цифрового искусства (создать цифровую галерею и красиво расположить в ней картины с учетом стоимости, пожеланий клиента и его денежных возможностей на основании предиктивной аналитики)

• аналитик цифровых трендов

• экоаналитик в строительстве

• аналитик-дизайнер эмоций

• аналитик/архитектор интеллектуальных систем управления

• экоаналитик в добывающих отраслях

Поговорим и об этом

С какими проблемами сталкиваются системные аналитики на проектах чаще всего?

Незакрытый личный конфликт

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

Неоднозначность требований

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

Разработка через тестирование

Бывает так, что требования подготовлены, понятны и вроде бы можно реализовать по ним задачу. Но если процесс разработки ранее был выстроен таким образом, что разработчик не смотрит в требования (по разным причинам), а делает как ему вздумается — тестирование попадает в проблему неопределённости реализации. Документация есть, а функционал работает иначе. И как правильно, никто уже сказать не может.

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

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