И целого проекта мало — как системному аналитику собрать побольше опыта и не сойти с ума

Меня зовут Анастасия Кайнова, я — старший системный-аналитик в ИТ-компании STM Labs. В своей статье рассказываю, как жить и набираться опыта аналитику, когда почти научился жить и еще не сошел с ума от полученного опыта!

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

Через какое-то время вы осваиваетесь в изначальном проекте. Но системная аналитика, как оказалось, штука очень интересная. Поэтому вы начинаете искать, во что бы еще вляпаться — в своей статье говорю про развитие soft skills. Случаи, когда базовых hard skills нет совсем, здесь не рассматриваются.

Вы принимаете условия и ввязываетесь в челлендж.

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

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

N. B. Замечание выше про технические навыки было важным. Эта статья больше про развитие soft skills. Случаи, когда базовых hard skills нет совсем, здесь не рассматриваются.

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

В этом разделе примем следующее:

Стоит сразу принять то, что ваши первые N постановок будут… не слишком хороши. Это связано как с пониманием и привыканием к техническому стеку, так и с выработкой собственного стиля постановок, соответствующего принятому на проекте. И это норма!

Старшие коллеги были на вашем месте и прекрасно понимают, что новичку приходится непросто (а если коллеги не понимающие — то зачем вообще такие коллеги?). На старте работы в вас ищут мысли по решению проблемы, а не конкретные и точные ответы.

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

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

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

Для себя я выбрала проблемно-ориентированный способ исследования системы (problem-oriented research) — есть конкретная задача, для ее решения необходимы конкретные знания. Таким образом, проект постигается постепенно, без перегрузок мозга. Да, иногда мне приходится говорить: «Я не знаю», затем идти за уточнениями, но это естественная часть обучения и погружения в проект.

Попробуем найти время, работая с такими моментами, как:

Как бы вам не хотелось прыгнуть выше головы, спокойно и взвешенно обдумайте, сколько задач/проектов вы можете вести одновременно — и правильно поставьте запятую в предложении из заголовка. Самое страшное — стать заложником идеи «Чем больше задач я возьму, тем лучше я покажу свою мотивацию». Это, конечно, прекрасно, только вот вашему руководству нужен качественный результат и продуктивный работник, у которого не слипаются глаза от переработок в ночи. Будьте честными перед собой и начальством. Не потянете — не влезайте, успеете еще поучаствовать в проектном марафоне: )

Разберу на своем примере. Грамотно распределить силы между тремя проектами мне больше всего помогли три основных фактора:

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

Еще один хороший способ разгрузить себя — думать о том, что на самом деле болит у пользователя. Разберу на примере.

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

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

У аналитиков есть две крайности при написании постановок.
Первая — написать хоть что-то, чтобы быстрее согласовать. А подробностями наполнять в ходе разработки и тестирования. Этот подход в большей мере отвечает гибким методологиям разработки. Вторая — сразу написать качественную постановку с необходимой степенью детализации.

На моей практике были проекты и с тем, и с другим вариантами. И, по моим прикидкам, написать один раз подробно или много раз дописывать — занимает одно и то же время. Только при постоянном переписывании вы не можете оторваться от сопровождения разработки и заняться другими задачами/проектами. Мне кажется, что между «напиши сразу с подробностями» и «напиши идею, а там разберемся» много промежуточных точек, этакий спектр возможных написаний постановок. И в какой точке этого спектра остановиться — задача многопараметрическая, в нее входят, например, квалификация аналитика и разработчиков, релизная политика и так далее. Создание постановки под конкретный проект — это умение выделить ту часть спектра, которая полезна в конкретной ситуации. Для себя я выбрала левую часть этого спектра — потому что мне комфортнее тратить меньше времени на сопровождение разработки и тестирования, и я справляюсь с созданием постановок с нужной степенью детализации в установленные сроки. К сожалению, это не означает, что я никогда не исправляю и не дополняю: )

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

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

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

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

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

В процессе можно нарабатывать и свои шаблоны. К примеру, у вас есть периодическая задача реализации загрузки документов нового для системы формата. А это означает, что нужно добавить шаблоны документов на backend и вывести их на UI с корректными названиями. Поскольку набор действий всегда одинаковый, можно оформить себе шаблон, который будет кочевать из постановки в постановку. Также полезно спросить других коллег-аналитиков на предмет таких шаблонов и не забывать делиться своими: )

Развиваемся посредством:

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

P. S Конечно, здесь нужна разумная балансировка — не стоит уматывать коллег раньше времени: )

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

…. а главное преимущество развивающегося аналитика. Причем не только в сфере технологий, которые вы используете на проекте.

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

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

Очень здорово, если вы нашли для в статье полезные для себя подходы: научились смирению (с ограничениями: )) , поняли как беречь время или увидели пути развития.

Мои согласования обычно заканчиваются фразой «Вопросы, предложения, угрозы?»
Так и здесь, если у вас есть проверенные практики, положительный и негативный опыт, вы категорически (не) согласны с материалом статьи — буду рада всем дискуссиям в комментариях!