Жду новый пост

Серия «Карьера в IT. Системный аналитик.»

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

Поэтому данный способ достаточно часто срабатывает в плюс и ты начинаешь получать офферы.

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

❕Однако, лично мое мнение в том, что не нужно перебарщивать. Я имею ввиду то, что если у вас совсем нет опыта - не нужно сразу устраиваться на миддла или сеньора, накручивая слишком большой опыт (такое, судя по некоторым историям, тоже реально).

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

Поэтому единственный совет - подходите ко всему разумно.

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

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

!(4) и что-то новенькое: hh.ru, на котором размещаются резюме, начал проверять точность информации и связываться с работодателями.

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

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

(2) Использовать нетворкинг - знакомиться с людьми, которые работают в тех компаниях, куда вы хотите. Даже просто написать и попросить зарефералить. Теория с рукопожатиями тоже работает (у меня так много клиентов и знакомых нашли работу)

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

(3) Резюме должно быть продумано до мелочей, из самого базового:

➡️ название должности должно соответствовать названиям вакансий, т.е не "специалист", а максимально конкретно;

➡️на первом месте должен быть опыт по той вакансии, на которую вы хотите, даже если это учебный опыт;

➡️ расписать подробно навыки, которые вы получили на обучении, лучше сразу с примерами из практики.

(4) Брать из предыдущего опыта все навыки, которые могут быть полезны. Смена направления — это не начинать с нуля, всегда есть переносимые навыки. Например, опыт ведения коммуникации и работа в команде, который есть у всех, и другие soft skills. Успех поиска 50/50 зависит от hard и soft skills.

(5) Использовать сопроводительные письма и писать вдумчивые отклики на позиции (спам-рассылка скорее всего не даст результата). А вот резюме + нормальное сопроводительное можно отправлять не только на hh, но и напрямую в компании, даже если вакансии нет, вас могут добавить в базу и написать позже.

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

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

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

Какие есть варианты написания ТЗ для данной задачи?

1️⃣Самый минимальный уровень детализации. Это когда системный аналитик просто ставит задачу на разработку Джире (ну или в рамках небольшой страничке в конфлю\ворде, в зависимости от того, как принято) и в постановке этой задачи пишет что-то вроде "Требуется реализовать процесс получения данных о пользователе и передачу ее с бэка на фронт по REST-запросу. Со стороны фронта требуется создать новую экранную форму приложения - "Личный кабинет" или "Профиль пользователя". Со стороны бэка требуется реализовать новый метод, который будет использовать фронт для запроса информацию по пользователю (и, скорее всего, перечисляет набор полей, которые должны передаваться на фронт в формате "Фамилия", "Имя" и т.д.)". Усё

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

2️⃣Вариант с немного лучшей детализацией. В этом формате системный аналитик уже пишет ТЗ в каком-либо формате, в рамках которого указывает, что: "Требуется реализовать новый метод GET /users/{id}, указывает полноценно параметры, которые данный метод должен потреблять на вход и параметры, которые он должен отдавать на выходе." Плюс может описать, также как в предыдущем пункте, верхнеуровневый сценарий взаимодействия с этим методом.

Уже чуть лучше и чуть больше полезной информации для разработчика, правда?

3️⃣Вариант с достойной реализацией. Этот вариант обычно используется на большинстве проектов ФинТеховских и я считаю его достаточным для того, чтобы написать хорошее, качественное ТЗ и разгрузить разработчика так, чтобы он не думал о деталях реализации, хотя бы алгоритмических и системных (то, к чему нужно стремиться со стороны СА, имхо).

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

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

4️⃣Более полноценный вариант придумать не могу =)

Плюсом к 3 пункту дополнительно описывается еще и swagger-спецификация микросервиса в целом и конкретных эндпоинтов в частности. Кроме того, что это просто удобно, наглядно и очень детально - эту спецификацию разработчики могут использовать, чтобы сконвертировать ее напрямую в готовый код с расписанными классами и эндпоинтами, останется "только" докрутить бизнес-логику и метод готов (Тут просьба поправить меня коллегам, которые более глубоко погружены в разработку - так ли это или есть еще какие-то бенефиты для разработчиков. Могу в этом предложении быть не прав, пишу исходя из того, как мне это объясняли).

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

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

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

А с какими процессами и подходами работаете вы?

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть огромное количество постов на тему софт-, хард-скиллов и про карьеру в целом - см. закрепленный дайджест.

• GET /users

• GET /users/{userId}

• PUT /users/{userId}

• DELETE /users/{userId}

• POST /users

Т.е. по сути реализуем концепцию CRUD по отношению к ресурсу User.

То, как описать метод GET /users/{userId} мы рассмотрели в прошлый раз, сегодня рассмотрим метод POST /users.

Но для начала расскажу как описывать модель данных системы (один из вариантов того, как это можно сделать), т.к. это тоже важная часть ТЗ (спеки), которую должен делать СА. Разберем просто на примере с комментариями:

Ссылка на конфлю кому нужно, пока он еще работает.

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

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

В рамках данного шаблона есть немного кастомных вещей, свойственных для моих проектов. Например, вот эта вот "Ссылка на userGroup", это означает FK на таблицу на таблицу USER_GROUP и связку с соответствующим объектом. А атрибут role с ссылкой в типе на ref.Roles это enum (справочник). Т.е. атрибут может принимать только одно из значений из списка:

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

С моделью данных разобрались, это нам поможет при описании метода в том числе.

Описание самого метода (ссылка на конфлю):

Обычно методы по созданию объектов сложнее, но тут у нас очень простой процесс, почти нет проверок, поэтому так)

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

И не менее главное - указать правила того, как должны заполняться атрибуты объекта при его создании (маппинг). Чтобы разработчик понял, откуда ему брать эти значения. В данном случае часть полей заполняется константами а остальная часть полей берется из request, т.е. тех данных, которые прислали на вход данному методу.

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

Получился еще более длинный длиннопост, чем обычно. Но вам, вроде бы, не привыкать. Вопросы, комментарии по сабжу - как обычно welcome.

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.

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

Бизнес-анализ

Дальше должен идти этап бизнес-анализа задачи, в результате которого должны появится качественные БТ (бизнес-требования), в которых детально описано то, как процесс нужно изменить, чтобы выполнить цели задачи. Как именно это будет описано - уже не важно, хоть через AS IS\TO BE, хоть простым русским языком.

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

Проработка архитектуры

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

Опять же, на одном из проектов был процесс, когда архитекторы системы оценивали КАЖДУЮ задачу и даже если она была небольшой, то не писали больших документов, а прям в JIRA писали краткое архитектурное заключение о том, какие процессы требуется доработать (и это было прям хорошо, заметно снизило количество кросскомандных недоработок).

Системный анализ

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

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

И вместо того, чтобы сделать задачу за неделю, ты тратишь две (а потом еще два месяца на круговые согласования. Не буду говорить где - кто знает, тот знает). А если потом еще что-то вскрывается на этапе тестирование - становится еще веселее)

Разработка

Разработчику также много проще разрабатывать задачу, когда есть не только ТЗ, но и различные документы более верхнеуровневого характера (сужу по фидбекам коллег).

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

Тестирование

А вот тут интересно. Потому что хороший тестировщик не будет ориентироваться только на ТЗ - он еще просмотрит BRD, БТ - сверит то что там написано с тем, что написано в ТЗ, потенциально выявит недостаток требований или их некорректность (было такое на практике) и только потом уже приступит непосредственно к тестированию.

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

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

Заключение

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

Если же проект маленький или просто нет позиций PO\БА\АР и вот этого всего многообразия ролей, то вспоминаем что я говорил в самом начале серии постов про системного аналитика - что это человек, который может совместить в себе все эти роли и обязанности, проделать сбор требований, бизнес-анализ, архитектуру и системный анализ самостоятельно и потом выдать удобоваримое, комплексное ТЗ разработчику. И сначала это даже интересно, сильно прогрессируешь в компетенциях, но только сначала)

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

P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.