Разбираем ответы

❌ /comments?articleId=42
Технически — корректно. comments выступает корневой коллекцией, а ?articleId=42 работает как фильтр. Однако по REST рекомендуется показывать вложенность прямо в пути, чтобы сразу было видно, к чему комментарии принадлежат. Они не живут сами по себе, а относятся к конкретной статье.

❌ /articles/comments/42
Нарушен порядок. Здесь непонятно, что такое comments/42. Это все комментарии статьи 42 или комментарий 42? URL двусмыслен 😞.

❌ /articles/42?comments
Параметр comments без значения, он ничего не уточняет. Если указываете параметр, то пишите, чему он должен быть равен. И помним, query-параметры используем в основном для фильтрации, сортировки, но не для получения вложенного ресурса.

❌ /comments/42/articles
Инвертирована иерархия. Тут выглядит так, будто у комментария 42 есть статьи. Логически неверно. У нас у статьи 42 есть комментарии.

✅ Правильный ответ
/articles/42/comments
Сначала ресурс «статья» (/articles/42), а внутри него подресурс comments. Так мы получим комментарии к конкретной статье.

#rest #api

Привет! 👋
С вами Вера, основатель AnalystCore.

REST, API, методы… Всё это, конечно, важно. Но есть тема, которую системные аналитики будто бы знают, но на практике оказывается, всё гораздо сложнее. Это требования.

Давайте сделаем паузу в теме REST и вернёмся к самому началу.
Потому что всё начинается именно с требований. Без них — всё остальное теряет смысл.

💬 Требования — это то, с чего начинается любая задача системного аналитика.
Но, если честно, эту тему часто недооценивают.
Кажется, ну что там сложного? Спросил, записал — готово.
А на деле:
📌 Требования бывают противоречивыми.
📌 Их нельзя просто «записать» — их нужно вытаскивать, распутывать, уточнять.
📌 То, как вы проработаете требования, влияет на всю реализацию задачи.
📌 Часто именно «плохие требования» становятся причиной багов и переделок.
И самое интересное — чем дольше вы работаете аналитиком, тем больше понимаете, сколько всего ещё не знаете про требования 😅

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

Оставайтесь с нами — будет интересно 😉

#requirements

Задача❓ Добавить новое обязательное поле «Цель кредита» в форму заявки на кредит.

💬 Бизнес говорит:

Нужно добавить поле «Цель кредита» в заявку. Это важно для отчётности. Сделайте обязательно для заполнения. Значения — стандартные.

Кажется, всё понятно. Но давайте подумаем — действительно ли тут всё так просто?

❓Вопрос к вам:
Как бы вы подошли к этой задаче как системный аналитик?
Над чем бы задумались? Что уточнили бы у заказчика, команды или у себя самого?

✍️ Напишите свои мысли в комментариях.
А в следующем посте мы поделимся своей версией.

Не пропустите.

#requirements

Задача❓ Добавить новое обязательное поле «Цель кредита» в форму заявки на кредит.

💬 Исходный запрос от заказчика:

Нужно добавить поле «Цель кредита» в заявку. Это важно для отчётности. Сделайте обязательно для заполнения. Значения — стандартные.

Что уточнить у заказчика, у команды и у самого себя?

1️⃣ Где именно размещаем?
В каком разделе формы?
До или после каких полей?
От этого зависит и UX, и порядок полей в отчёте и пр.

2️⃣ Обязательное — всегда?
Например, если пользователь сохраняет черновик — можно ли сохранить без этого поля?
Или только при финальной отправке заявки?
От этого зависит логика на фронте и бэке, валидация.

3️⃣ Что за «стандартные значения»?
Нужен чёткий справочник:
- Покупка авто
- Ремонт
- Путешествие
- Лечение
- Образование
- Иное (а если выбрали — показывать поле для уточнения?)
❗ А кто владелец справочника? Кто будет поддерживать его актуальность? Если завтра придёт бизнес с новой целью — кто её добавит и в каком виде?

4️⃣ А что делать со старыми заявками?
В старых заявках цели не было, а новое поле будет обязательным, что там проставлять?
Что проставлять в заявках со статусами «Черновик», «В работе» и пр.?

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

5️⃣ Где должно появиться поле?
В карточке заявки (в вебе и мобильном приложении)
В интерфейсе сотрудников
В отчётах и BI-системах
В БД, API

6️⃣ Как будет использоваться?
Влияет ли цель кредита на автоматическое решение?
Используется ли в отчётах?
Может ли повлиять на ставку / условия?

7️⃣ Есть ли ограничения?
Можно ли выбрать несколько целей?
Валидация для поля «Иное»?

А ещё смотрите классные вопросы, которые написали в комментариях под прошлым постом 👆.

📌 Как видите, даже простая задача может тянуть за собой десятки вопросов, решений и проработок.

В следующем посте расскажем, что ждут от системного аналитика в такой задаче: что он должен передать фронту, бэку, тестировщикам и менеджеру.
Не пропустите 😉

#requirements

📌 Что ждут от системного аналитика в ТЗ на добавление нового поля?

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

💡 Сохраняйте, это пригодится в работе💡

🔷 Описание справочника
– Название: Цели кредита
– Список значений
– Указан владелец справочника (кто поддерживает актуальность)

🔷 Описание нового элемента UI
Обычно все элементы интерфейса описываются в виде таблицы. В неё нужно добавить новое поле. Продумайте:
– Где должно быть размещено поле
– В каких случаях оно обязательно
– Укажите возможные значения
– Есть ли значение по умолчанию
– Для цели «Иное» должно отображаться поле ввода «Иное» — описываем условия отображения
– Описываем валидацию для «Иное»: длина, допустимые символы, плейсхолдер и пр.
– Возможные ошибки и условия, когда они появляются
* Не забудьте добавить поле во все экраны, где оно появится. Например, есть ещё система для сотрудников банка, где они тоже могут заполнять и смотреть заявку.

🔷 Макеты
– Отрисуйте макеты сами или вместе с дизайнером
– Не забывайте про адаптивную версию: как поле будет отображаться на телефоне и планшете?
– Как поле выглядит в режиме редактирования и в режиме просмотра?
– Сценарии ошибок, плейсхолдеры, тексты валидаций
– Нужны ли подсказки к полю? (i)

🔷 Спецификация API
– Описание эндпоинта на получение справочника по шаблону (URL, алгоритм работы метода, входные параметры, выходные параметры, коды ответа)
– Добавьте новое поле во все методы, связанные с заявкой: на создание заявки, редактирование, получение
– Опишите новый параметр запроса по шаблону (название параметра, тип данных, обязательность, описание с учетом валидации)
– Опишите специфичную бизнес-логику, если она есть

🔷 Опишите сценарии взаимодействия
– В какой момент фронт будет запрашивать справочник?
– Что делать на фронте, если справочник не удалось получить (вернулась ошибка)?
– Кешируем ли справочник на фронте? На сколько?
– Если описываете, какие методы вызывает фронт и с какими параметрами, то обязательно уточните, как используется новое поле в запросах и ответах.

🔷 Изменения в БД
Как правило, все поля БД описываются в виде таблицы. В эту таблицу нужно внести новое поле:
– Найдите таблицу, куда добавите новое поле
– Название поля
– Тип данных
– Обязательность
– Описание (с учетом валидации)

🔷 Доработка сервиса принятия решений (если цель влияет)
– Влияет ли цель на ставку, срок, решение?
– Какие значения влияют и как?
– Обновите описание скоринга
– Кто согласует изменения логики?

🔷 Задача на миграцию. Обработка старых заявок
– Что делать с уже созданными заявками без цели?
– Какие значения подставлять?
– Если делаем маппинг — по каким правилам?
– Можно выгрузить заявки, вручную проставить цели в Excel и передать разработчику — он напишет миграцию
– Укажите, что миграция отображается в истории изменений от имени системного пользователя

🔷 Изменения для отчётности / BI
– В какие отчёты и выгрузки нужно добавить поле
– В каком месте появится новое поле
– Опишите поле
– Опишите цели использования поля

🔷 Для менеджера и всей команды
Напишите:
– Открытые вопросы и риски
– Что можно вынести вне MVP
– Места, где потребуется отдельное согласование и кого именно

💡 Как видите, простая задача оказалась не такой простой. B работе системного аналитика так всегда. Но вы и сами наверняка с этим сталкивались 🙂.


Если разбор понравился, ставьте реакции ❤️‍🔥, так мы узнаем, интересно ли это вам.

#requirements #тз_разбор

🎥 Посмотрите на курс изнутри!
Мы заглянули в первые модули, показали структуру и кусочек ДЗ.

👉 https://analystcore.com/system-analyst-base

Хотите сменить работу в этом году? 🎯

Если планируете переход — сейчас самое время начинать поиски и подготовку к собеседованиям.
В крупных компаниях часто есть годовые бонусы. Чтобы их получить, нужно отработать хотя бы полгода. А значит: устроиться до конца июня! 💸

📆 До лета — всего полтора месяца. Пора освежить знания и подготовиться к интервью.
Вот полезная подборка постов, которые помогут:

📌 Мой чеклист перед собеседованиями — это список тем, которые я всегда повторяю 😉
📌 Что происходит после нажатия на кнопку «Войти»?
📌 Задача на сбор требований и проектирование
📌 Задачи на определение «это синхронное или асинхронное взаимодействие?»
📌 Спроектируйте взаимодействие: выберите синхронный или асинхронный способ
📌 Задача на Use Cases
📌 Виды интеграций
📌 Безопасный и идемпотентный
📌 Как сделать POST-запрос идемпотентным?
📌 Почитайте все по хэштегу #api

И будьте готовы к личным вопросам:
– Расскажите о себе
– Как относитесь к переработкам?
– Что будете делать, если задача на 3 дня, а работы на 5?
– А если коллега вам не отвечает три дня, а он вам нужен — как поступите?

Если хотите не просто повторить, а наконец разобраться во всём системно, приходите на курс «Системный аналитик. БАЗА». Он поможет вам разложить знания по полочкам, чтобы пройти собеседование без страха и потом уверенно работать на новом месте.

🎯 Зачем выделять MVP даже в маленькой задаче?

Иногда кажется, что MVP — это для стартапов, больших релизов, глобальных фичей.
Но на деле его стоит выделять даже в небольших задачах. Вот пример 👇

💬 Задача
«Добавить возможность пользователю загружать документы по заявке»

Звучит просто. Но как только начинаем прорабатывать требование всплывают детали:

— А можно загружать сразу несколько файлов? Сколько максимум? Как они будут отображаться вместе на странице?
— А какие форматы и ограничения по размеру?
— Нужно ли разделять ошибки? Какие?
— Где пользователь потом увидит загруженные документы?
— Нужно ли, чтобы в списке заявок была иконка вложения, чтобы пользователь знал, в каких есть файлы, а в каких нет?
— А если пользователь случайно загрузил не тот файл? Как удалить?
— Делаем предпросмотр?
— Показываем прогресс‑бар загрузки?
и пр.

📌 И вот уже «простая» задача превращается в мини‑проект с UX-сценариями, вопросами по API, фронту, бэку и дизайну.
И всё «надо, желательно, хотелось бы». И всё это увеличивает срок разработки и тестирования.

✅ Именно в этот момент аналитик должен остановиться и совместно с командой выделить MVP — минимальный объём, чтобы пользователь мог загрузить файл и отправить заявку.

В итоге MVP:
— Грузим только один файл (представим, что для нашего кейса — это ок)
— Только PDF, до 5 МБ (если нужно загрузить несколько скриншотов — пусть объединят в один PDF)
— Без предпросмотра, разделения ошибок, прогресс‑бара, иконки вложения, без удаления (пусть если что новую заявку создают) и пр.

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

💡 Плюсы:
— задача ушла в разработку на следующий день;
— сделали быстро;
— релиз не сорвался;
— пользователь смог загрузить документ — миссия выполнена ✅

Выделять MVP можно и нужно не только для больших задач.
Даже в маленькой задаче это спасает от переработок, задержек и метаний «а давайте добавим ещё…». Когда ограничены сроки, ваше спасение — выделить MVP.

#requirements

🧩 8 способов декомпозировать задачу

Если задача выглядит громоздкой и оценена, скажем, в 3 недели работы — не спешите сразу отдавать её в разработку.
Попробуйте декомпозировать и предложите команде и менеджеру варианты, с чего начать.
Вот 8 шаблонов, которые в этом помогут 👇

1️⃣ Последовательность действий
Можно ли сначала сделать начало и конец процесса, а остальное позже?
📌 Например, процесс записи на вебинар. Сначала можно сделать форму записи и экран подтверждения. Позже интеграцию с календарём.

2️⃣ Отдельные операции
Можно ли разбить задачу на несколько операций и делать по одной?
📌 Пример: базовая декомпозиция по CRUD. Сначала делаем «создать», потом «просмотреть», «редактировать», «удалить».

3️⃣ Разные группы данных
Можно ли сначала работать с частью данных, а потом добавить остальные?
📌 Примеры:
— Разделить поведение по ролям.
— Разбить большую форму для заполнения на части.
— Разбить экран на блоки: сначала учимся выводить основную информацию, потом дополнительные блоки.

4️⃣ Упрощённый интерфейс
Можно ли сначала реализовать упрощённый UI?
📌 Пример: сначала делаем простую кнопку загрузки файла, позже добавим drag-and-drop и предпросмотр.

5️⃣ Бизнес-правила
Можно ли начать без сложной логики, а добавить её потом?
📌 Пример: на фронте сначала валидируем только заполненность полей, позже добавим более сложные проверки. Например, если в поле_1 выбрано значение А, то поле_2 становится обязательным, и в этом случае нужно выводить читаемую ошибку.

6️⃣ Производительность — позже
Можно ли сначала реализовать функциональность, а заняться оптимизацией позже?
📌 Пример: делаем простую выгрузку отчёта, даже если она будет долго грузиться. В рамках отдельной задачи будем оптимизировать процесс формирования выгрузки и биться за скорость.

7️⃣ Простота/Сложность
Можно ли сначала сделать только базу, а дополнения позже?
📌 Пример: сначала реализуем выгрузку отчёта в CSV, а позже добавим визуальный дашборд и фильтрацию.

8️⃣ Основной объём — потом
Можно ли сначала сделать happy path, а остальное позже?
📌 Например, публикация поста в админке. Сначала реализуем ввод текста и кнопку «Опубликовать». Позже добавим отложенную публикацию и черновики.

💡 Эти шаблоны помогают ускорить выход фичи в прод, сократить баги и упростить разработку. Используйте их даже в небольших задачах — это избавит вас от переделок и «пожаров» в конце спринта.

Если пост понравился, ставьте реакции ❤️‍🔥, так мы узнаем, интересно ли вам читать про декомпозицию.

#requirements

Всем привет! 👋

В последнее время у нас получаются слишком большие посты 😅. Для баланса запустим новую рубрику «мини-лайфхаки / советы».
Это короткие и местами очевидные советы, но именно они часто спасают нас в повседневной работе. Будем периодически делиться ими в течение недели.

🎯 Мини-лайфхак №1

Не используйте в ТЗ формулировки вроде «возможно», «наверное», «может быть».
Такие слова так и побуждают спросить: «А ты сам то уверен в своём ТЗ?»

Системный аналитик — это источник правды для своей команды. Мы должны формулировать требования максимально чётко.
Если есть неопределённость — выносим как открытый вопрос, обсуждаем и уточняем.

❓ А какой мини-лайфхак дали бы вы другим аналитикам?
Пишите в комментариях 💬. Лучшие советы попадут в следующий пост рубрики 😉

#лайфхаки #requirements

🔍 Как понять, что требование плохо сформулировано? Проверьте эти 3 признака

Сохраняйте себе, чтобы под рукой был мини-чеклист с примерами 👇

1️⃣ Недвусмысленность
Все должны понимать требование одинаково и без уточнений. Избегайте абстрактных формулировок.

История заказов:
❌ Пользователь может видеть все свои заказы за последний год
✅ Пользователь может видеть все свои заказы за последние 365 дней, отсчитывая от текущей даты

Поиск по сайту:
❌ Пользователь может искать по названию и категории товара
✅ Пользователь может искать товары отдельно по названию, отдельно по категории, либо по комбинации обоих полей

2️⃣ Непротиворечивость
Требования не должны конфликтовать друг с другом.

Форма заказа:
❌ Кнопка «Отправить заказ» должна всегда быть активной, но нажать можно только если все обязательные поля заполнены
✅ Кнопка «Отправить заказ» активна только после заполнения всех обязательных полей

Редактирование заявки:
❌ Заявку можно редактировать в любое время, но после отправки на согласование редактировать нельзя
✅ Редактировать заявку можно до тех пор, пока она не отправлена на согласование

3️⃣ Проверяемость
Тестировщик должен легко и однозначно проверить, выполнено требование или нет.

Уведомления по email:
❌ Пользователь должен получать уведомления достаточно быстро после регистрации
✅ Пользователь должен получать email-уведомление о регистрации в течение 5 минут после её завершения

Валидация пароля:
❌ Пароль должен быть сложным и надёжным
✅ Пароль должен состоять минимум из 8 символов, включать минимум 1 цифру, 1 заглавную букву и 1 спецсимвол из списка @#$

Если вы ловили себя на мысли, что ваши требования «понятны только вам» 😱 или команда задаёт слишком много уточняющих вопросов, значит, пора подтянуть базу 👉 Приглашаем на курс «Системный аналитик.БАЗА».

👉 Подробнее о курсе «Системный аналитик.БАЗА»

#requirements

🎯 Мини-лайфхак №2

Пишите заголовок задачи в Jira так, чтобы суть задачи была понятна без описания.

❌ Доработать форму заявки (какую именно доработку делаем?)
✅ Добавить поле Цель кредита в форму заявки

Так на дейли вы смотрите на доску и сразу понимаете, о чём идёт речь. Экономите время всей команде.

❓А вы бы что посоветовали? Пишите в комментариях 💬

#лайфхаки #requirements

🎯 На собеседовании не обойтись без вопросов по теме требований, ведь это основа работы аналитика

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

Сохраняйте самые частые вопросы по требованиям 👇

1️⃣ Какие методы сбора требований знаете? Какие применяли на практике?
2️⃣ В каком виде вам приходят задачи на текущем проекте и на прошлых? С какими подходами сталкивались?
3️⃣ Как, по вашему мнению, выглядит идеальная задача, которая поступает к вам на анализ?
4️⃣ Какие виды требований знаете?
5️⃣ Прорабатывали ли нефункциональные требования? Что к ним относится?
6️⃣ Как понять, что требование хорошее? (ожидают услышать «критерии хороших требований»)
7️⃣ Использовали ли в работе User Story? Как работали по ним?
8️⃣ Для чего применяют User Story, а для чего Use Case?
9️⃣ Работали с Use Case? Что это такое? По какому шаблону описывали?
1️⃣0️⃣ Участвовали ли в декомпозиции задач? Знаете, как можно декомпозировать? Давайте попробуем: <дают задачу на декомпозицию>
1️⃣1️⃣ Как бы вы вели документацию на проекте? Какие разделы в ней были бы? Что для вас «идеальный шаблон»?

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

Ваши Вера и Юрий, основатели AnalystCore
Удачи на собеседованиях 💪

#requirements #interview