В последнее время мы обсудили много интересного!

Сохраняйте подборку полезных постов, чтобы было куда заглянуть в нужный момент 👇

📌 Как вести историю изменений в требованиях?
📌 Короткие советы по тому, как описывать логику обработки ошибок
📌 Как оформить задачу на разработку справочника?
📌 Техника «5 почему» для сбора требований
📌 Чек-лист по своему проекту, чтобы не забыть все точки входа
📌 Подборка постов, как качественно описать задачу на фронт
📌 Чем отличается бизнес-аналитик от системного аналитика
📌 Где может работать системный аналитик?
📌 Что делает системный аналитик в банках?

Как сочетать Use Case с другими артефактами и разделами в документации?

Предлагаю один из вариантов, как можно включить Use Case в вашу документацию👇

1️⃣ Шаблон предполагает ведение большинства функциональных требований в формате Use Case.

2️⃣ Если в Use Case предполагается использование экранной формы, то в шаги включается отображение этой формы со ссылкой на отдельную страницу с её описанием (GUI). Ранее я давала шаблон описания элементов интерфейса.

3️⃣ Если к Use Case вы хотите добавить диаграмму, это тоже возможно. Просто на странице этого Use Case создайте внизу раздел «Детализация требований» и добавьте диаграмму туда.

4️⃣ Если в Use Case предполагается отправка запроса, добавьте шаг, описывающий этот момент, и дайте ссылку на страницу с описанием API (метод, сценарий, входные/выходные параметры, коды ответа и т.д.)

5️⃣ Как сочетать User Story и Use Case при таком подходе?
В задаче в Jira укажите формулировку User Story, а затем добавьте раздел «Вспомогательные материалы». Сюда входят все связанные требования из Confluence: ссылки на Use Case, GUI, требования в произвольном формате и пр. Это и будут критерии приёмки вашей User Story.

#requirements

Часто бывает так, что один и тот же кусок логики используется в нескольких требованиях. Классический способ избежать дублирования — вынести общее описание на отдельную страницу и в других требованиях написать: «см. Общие требования такие-то».
Это работает, и всех это устраивает. Но бывают случаи, когда не хочется уводить читателя документа со страницы, и хочется показать ему всё описание здесь и сейчас. Для таких случаев в Confluence есть макросы «Excerpt» и «Excerpt Include».

Пример использования смотрите на картинке 👆

#requirements

Про названия параметров в документации 🤔

В последнее время я часто замечаю, что у многих названия параметров в документации и в реализации сильно отличаются. Да, такое бывает, не уследили, или просто не успели обновить. Но это объясняют тем, что в документации у нас «требования», а в сваггере «реализация». Это 2 разных мира, и мы не обязаны синхронизироваться.

Я думала над этим вопросом, и всё-таки, не могу это принять.
У меня вопрос, а что делать командам, которые являются потребителями вашего контракта?

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

Вижу три выхода из ситуации:

1️⃣ Синхронизировать названия. Если параметры описаны и в документации, и в сваггере, они должны совпадать.

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

3️⃣ После реализации удалить параметры из доки и оставить ссылку на сваггер. В документации останется только логика работы метода, примечания, интеграционный use case, а параметры и коды ответа будут в сваггере. Но этот вариант работает, только если сваггер оформлен нормально.

Мы, как аналитики, не должны вводить в заблуждение коллег из смежных команд. Давайте следить за актуальностью документации. Выходы есть. 😉

#requirements

✨Судя по опросу, у нас много ребят, кто только входит в профессию.
А значит, самое время обменяться историями ✨

У каждого свой путь. Кто-то стал системным аналитиком сразу после ВУЗа, кто-то сменил профессию, кто-то загорелся рассказами друзей из IT и решил тоже в это ввязаться)

У меня история достаточно стандартная — я устроилась на первую работу в роли СА после бакалавриата. Специальность была "Информационные системы и технологии". Дальше училась в магистратуре и параллельно работала.
А как у вас было?

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

Давайте соберём коллекцию вдохновляющих историй ✨

Сегодня захотелось немного покритиковать «распиаренные плюшки» IT 😈
(ну те самые, которыми пытаются затащить человека в айти)

1️⃣ Работа прекрасна, потому что офис классный

В ленте часто вижу видео, где айтишники рассказывают о прекрасном офисе. Что работа в IT — сказка, посмотрите, какой у нас спортзал, массаж по записи, автомат Вкусвилл с едой, на кухне печеньки, кофемашина, психолог, чиллинг зоны. Можно работать лёжа, сидя, стоя. Есть капсулы для сна. Поработать сегодня на пуфике или в уединённой кабинке? А может пойти на крышу или в переговорку?

👉 Офис правда классный и комфортный. Сюда приятно приходить, наливать кофе, брать печенье и посидеть утром на пуфике.
НО! После дейли начинается череда созвонов, задачи, сроки, чаты с миллионом вопросов. Опомниться успеваешь только к обеду. А после обеда бешеный ритм продолжается.
До спортзала вообще доходят единицы (я ими искренне восхищаюсь 🤝, вообще всеми, кто может использовать офис на максимум).

2️⃣ Можно работать в кофейне и пить капучино на кокосовом. Можно работать у бассейна или прямо в бассейне

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

А какие «плюшки в IT» вам кажутся самыми забавными? 👇

Аналитики с опытом 1–3 года часто критикуют себя такими мыслями:
- Я тупой.
- Когда же я наконец почувствую уверенность в себе?
- Когда же я наконец пойму, что мне делать по задачам?
- Почему опять пришла задача, с которой я не сталкивался раньше?
- Настанет вообще момент, когда я буду всё знать?

Если честно, такой момент не настанет 😅, и это просто нужно принять.

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

Просто это суть работы айтишника. Мы должны понимать, что всё постоянно меняется, мир меняется. Нельзя всё выучить, нельзя знать всего. Это не минус, а часть профессии.
Разбираемся по мере поступления проблем. И это касается не только джунов и мидлов, но и сеньоров, и даже руководителей.

Просто выдыхаем и учимся спокойно к этому относиться ☘️.
Я тоже учусь.

Корпоративный этикет: когда хочется кричать 🥲

Этикет — это, конечно, хорошо. Но:

- Сообщение от коллеги в корпоративном мессенджере «Привет! как дела?» — просто давай ближе к делу... Мы не друзья, да и будем откровенны, тебе всё равно, как у меня дела.

- 5 минут приветствий и благодарностей в начале встречи на большое число людей. «Спасибо, что подключились!», «Спасибо всем, кто…» — ладно, может это и приятно, если хватят тебя, но что делать остальным? 😅

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

- 15 минут пишешь письмо, ещё 15 проверяешь его на ошибки, ещё 5 нужно, чтобы сделать текст вежливым, ещё 5 на то, чтобы решиться отправить — лучше бы поработали, честное слово. В итоге всё равно находишь какую-то дурацкую опечатку.

- Вопросы на собеседовании вроде «Как вы относитесь к переработкам?» — все понимают, что нужен «правильный ответ», что вы за проект горой, да и личная жизнь подождёт. Попробуй скажи честно — опрокинут (у меня был такой опыт 😬).

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

Кто пополнит список? 😂

Системный аналитик без вопросов, это как бариста без кофе ☕️

Каждый день мы закидываем разработчиков десятками вопросов «А используем ли мы этот параметр?», «А что в коде указано на этот счёт?», «А можно ли реализовать требование так-то?», «Так как будем делать?», «Подтверди, это так?».

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

Если возникают такие мысли, это в голове говорит ваш «прокурор». Поругал, опустил ниже плинтуса, растоптал весь потенциал и испортил настроение на пару часов.

Но что говорит ваш «адвокат»? Адвокат аналитиков сказал бы:
- Это ваша работа «вопросы задавать». Системный аналитик большую часть времени задаёт вопросы. Без этого требования не собрать и задачи разработчикам не поставить.
- По задаче есть действительно дискуссионные вопросы. Если их не проговорить, то на ревью задачи со всеми этими вопросами придут к вам же. Если есть двойственность — спрашивать обязательно. Это нормально.
- А даже если и можете принять решение, представьте: в вашей голове родилось классное решение, вы его зафиксировали и сказали всем «делайте так». А потом приходит архитектор и говорит, да это же противоречит нашим последним договорённостям среди разработчиков, почему не уточнил перед написанием ТЗ? Вот и думай, спрашивать или нет 🤷‍♀️.

Конечно, бывает, что некоторые вопросы избыточны. Если прям что-то совсем очевидное, лишний раз лучше не отвлекать. Но если есть сомнения, лучше спросите. Проекту будет только лучше. А мы мыслим успехом проекта, а не только своими чувствами 😉.

А если сомневаетесь, «спрашивать или нет», потому что знаний не хватает, можно подтянуть базу на курсе 👉 Системный аналитик с нуля до старта.

А у вас бывало чувство, что разработчики устали от ваших вопросов? Как справляетесь с этим?

Спрашивать — это нормально. Это и есть наша работа.

Когда это ваше первое или второе место работы, то всегда интересно, а как у других? Как можно работать по-другому?

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

Я была на разных проектах и в разных командах. Требования к аналитику везде отличаются. В целом встречала такие схемы:

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

2️⃣ Большой проект делят на куски, и за каждый кусок отвечает одна команда: команда по совершению платежей, истории операций, профиль и пр. Тут аналогично предыдущему варианту, аналитик прорабатывает и UI и бэковую часть. Каждый отвечает за свою область: платежи, историю, профиль. Есть интеграции с другими командами.

3️⃣ Бывает, что большой проект делят по другому принципу. Есть отдельная команда фронта и много команд на каждый сервис. Здесь аналитики команд сервиса отвечают чисто за бэковую часть этого кусочка, а аналитик фронта прорабатывает взаимодействие со всеми командами бэка. Аналитик фронта отвечает за UI часть и интеграции с командами бэка.

В общем, аналитик всегда найдёт себе работу. Вопрос только, за какой кусок отвечать.
А вы за что отвечаете сейчас: фронт, бэк или всё сразу? Как больше нравится работать?

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

Для тех, кто не в теме: командное собеседование проводится на самом последнем этапе, после скрининга HR и технического собеседования. Тут не гоняют по задачам, вопросам, просто знакомишься с ребятами и проектом. Казалось бы, самое лёгкое…

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

История 1️⃣
На собесе всё шло хорошо. Мне понравились ребята, и я им вроде тоже. В тот раз собесилась на внутренний проект, предметная область была интересной. И тут мне задают вопрос: «Что для тебя важно на проекте, в работе?». Я ответила, что «мне нравятся проекты, которые приносят пользу, и в идеале, которыми я сама пользуюсь». Потом меня спросили: «а каким проектом ты гордишься?». Я ответила: «Тинькофф Инвестиции». Что вы думаете? Мне отказали по причине «У нас интерфейс не очень, вам будет скучно и вы уйдёте». С чего они решили за меня? 😅 Мне была интересна предметная область, да и я бы могла поспособствовать, чтобы интерфейс стал приличным))

История 2️⃣
Мне с ходу не понравилось отношение к собеседованию. Ребята опоздали. Один на 5 минут, второй на 15. Собеседование было назначено на 18:00, а это уже поздно. Из рассказа было видно, что им самим не нравится их проект. И тут звучит самый популярный вопрос: «А как вы относитесь к переработкам?». В этот раз я решила не увиливать и сказала правду, что я действительно думаю. Я ответила: «Как и любой человек, я не люблю переработки. В своей работе я планирую дни так, чтобы укладываться в сроки и не приходилось перерабатывать. Но, конечно, если придётся и это требуется проекту, я готова». Что в итоге? Меня не взяли. Какой ответ они хотели услышать?

История 3️⃣
Моя любимая. Не помню, что именно были за вопросы, но они отражали суть, почему я сейчас в поиске работы? Я ответила то, что нельзя говорить в корпоративном мире. Сказала что-то вроде «ищу новые карьерные возможности, рост дохода и т. д.». Мне отказали по причине: «Вы идёте работать из-за денег».
Я не люблю эти корпоративные лицемерные игры. Я готова подыграть, если нужно, но вам самим не смешно? А ради чего человек ещё работать идёт? Если бы у вас откуда-то были деньги на еду, ипотеку, закрытие всех потребностей, путешествия, вы бы не работали, а занимались чем-то другим. Открывали бизнес, отдыхали, занимались спортом, посещали спа днём, а не сидели бы в офисе. Не понятно мне это...

История 4️⃣
Отказ был снова якобы по причине, что мне будет у них скучно. Но я грешу на другое. Мне устроили блиц из вопросов о моей жизни. В итоге после каждого ответа мне прямо так и говорили: «о, ред флаг». А потом отмазывались, что это шутка. Какие ред флаги отпугнули:
Я люблю кататься на самокате, люблю не ту музыку, считаю, что документация на проекте должна быть.

Вот и решайте сами, что говорить, а о чём лучше промолчать 😅
А вас что спрашивали на командных собесах? Делитесь опытом в комментариях 👇

Мой план подготовки к собеседованиям я оставила в отдельном посте. Переходите и сохраняйте.

Меня часто спрашивают, а будет ли курс с практикой? Будет 💪

Я перфекционист и вылизываю все задания. Они связаны друг с другом, нужно собрать требования, составить User Story Map, декомпозировать задачи, выделить MVP, потом проработать новый Use Case и доработать существующие, нарисовать диаграмму процесса, доработать ER-модель и спроектировать эндпоинт в стиле REST, чтобы передать данные с фронта на бэк.

В процессе продумывания заданий вылезают дыры, и я их устраняю 😅
Сама же выполняю свои задания, продумываю ожидаемое решение и натыкаюсь на спорные моменты. Какой тип данных выбрать? Выделить справочник или лучше ENUM? Один выбор тянет за собой изменения: возвращаюсь к Use Case и дорабатываю всё дальше по цепочке.

В общем, строга к себе так же, как и к ученикам, кто делает практику.
А вообще, только через суровую реальность можно чему-то научиться. Я даю развёрнутую обратную связь, где могу зачеркнуть практически всё. Но именно так и идёт обучение. Можно сделать задачу «нормально», а можно «хорошо», в соответствии с последними тенденциями и best practices.

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

Этот день наконец настал! Курс «Системный аналитик: практикум с ручной проверкой» запущен 💪

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

- Не умеете декомпозировать задачи?
Потренируйтесь в сборе требований, изучите шаблоны декомпозиции и попрактикуйтесь в построении User Story Map.
- К спроектированной бизнес-логике у команды много вопросов?
Освойте технику Use Case, она учит системно мыслить и не пропустить требования.
- Не понимаете, как вписать доработки в существующую БД и API?
И это можно побороть. Вспомните теорию и выполните один сквозной проект. Так вы поймёте связи от требований до API.

Курс именно практический. Здесь нет лекций. Есть 6 больших практических заданий, которые я проверяю вручную. Будем работать в Google-документах и draw.io. Оставляю комментарии прямо в ваших файлах, а после даю развёрнутую обратную связь на платформе. Есть закрытый чат для вопросов.

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

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

До встречи на практике ❤️