Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик, разработчик и автор телеграм-канала IT Talks. Многие начинающие специалисты, которые только пришли в профессию, сталкиваются с непониманием своей роли, задач и зоны ответственности. В теории все достаточно понятно, но в реальных задачах на практике часто сталкиваешься с тем, к чему сложно подготовиться в процессе обучения.

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

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

А ещё в моем канале ты можешь скачать бесплатный гайд с шаблонами диаграмм на PlantUML.

Предыстория

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

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

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

Новая задача

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

Необходимо интегрироваться с новым файловым хранилищем. Файлы больше не будут храниться в нашей базе данных. Еще добавятся новые типы файлов, так как теперь мы можем работать с файлами большого объема.

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

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

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

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

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

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

Что же делать, что же делать

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

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

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

Еще я не подумала про существующую логику работы. Её нужно было не только выпилить из кода, нужно было сделать это незаметным для пользователя. Соответственно, проработать нужно было еще и имеющиеся процессы.

Единственный момент, с которым не должно было возникнуть проблем – это интеграция. Ведь здесь нужно только описать контракты. Но раньше я не видела того, что происходит до того, как я беру задачу в разработку. Система, с которой мы интегрируемся, может отправлять данные не так, как мы договорились изначально. А также в принципе может не передавать те данные, которые необходимы в процессе. Это череда встреч, договоренностей и согласований.

От слов к делу

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

Во-первых, в новой команде и роли важно сразу определиться с тем, за что ты отвечаешь, как пересекаешься с другими ролями, а также что от тебя ждет команда в целом. Во-вторых, системный аналитик не просто пишет требования и работает с документацией. Он должен быть погружен, как минимум, в бизнес-процесс и архитектуру системы. Также важно знать бизнес-цель свой задачи и уметь работать с пользовательскими требованиями. Я бы назвала это MVP для роли системного аналитика.

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

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

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

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

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

Может понадобиться описать бизнес-процесс на техническом языке. Чтобы описание было понятно разработчикам, особенно если процесс новый или достаточно сложный относительно тех, что есть.

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

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

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

Чем дальше в лес

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

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

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

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

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

Подведём итоги

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

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

Доклад написан по материалам, которые были подготовлены мной для стрима о роли системного аналитика с Игорем Антоновым: