В чате разработки начался сущий кошмар, когда они увидели этот метод

Я видел однажды, как он убил прод… методом.

В Джоне Уике (2014) Киану Ривз убил троих карандашом, но только не методом /GET и не на проде.
У нас же «оружием» иногда становится плохо описанный метод, который может завалить проект ничуть не хуже🤯.

Какие есть подводные?

1. Неясные входные параметры
Аналитик не указал, какие поля обязательные.
На проде метод вызывают без нужного параметра → упали.

2. Неопределённые типы данных
Ожидали int, прилетел string → через некоторое время приходит баг.

3. Нет описания ошибок и кодов ответа
Метод возвращает какой-то ответ, но без описания.
В итоге каждый понимает его по-своему.

4. Логика описана не полностью
Запись не найдена, сервис вернул пустой ответ, превышен лимит и т. д.
На проде это превращается в зависший UI или кривые данные.

5. Нет ограничений по производительности
Не уточнили, что метод должен отдавать максимум 50 записей.
Фронт запросил все транзакции клиента (500 строк) → таймаут, нагрузка, сервер лёг.

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

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

IT АНАЛитика | Подписаться

Подборка шаблонов для аналитика

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

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

Для ведения документации на проекте
Общий для заведения задач на разработку
Для оформления бизнес требований
Для оформления системных требований
Для принятия от бизнеса задач в работу
Для документации к микросервису
Для функциональных требований (фронтенд)
Для описания методов

А какие шаблоны есть у вас?

IT АНАЛитика | Подписаться

Главное не забыть стоп слово🍑

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

Похихикать можно по тэгу #поддержка

IT АНАЛитика | Подписаться

HAProxy: зачем это знать аналитику?

Если вы работаете с высоконагруженными системами или микросервисами, то наверняка слышали где-то в чате или от своих разработчиков фразу:
«Что-то с хапрокси».

Пугаться не стоит давайте разберёмся.

🧠 Что такое HAProxy?
HAProxy (High Availability Proxy) - это программный балансировщик нагрузки и обратный прокси (reverse proxy).
Скорее всего, вы слышали про NGINX - это примерно то же самое, только со своими нюансами.

Он получает входящие запросы от пользователей (например, с фронта или внешних систем) и распределяет их по backend-сервисам.
То есть он как диспетчер на перекрёстке: стоит между клиентом и вашими микросервисами и решает, куда направить трафик.

Зачем он нужен?

➡️ Балансировка нагрузки
Когда есть несколько инстансов сервиса, HAProxy распределяет трафик между ними.
Это повышает надёжность и масштабируемость.

➡️Отказоустойчивость
Если один из серверов упал, HAProxy уберёт его из списка доступных и продолжит работу без сбоев.

➡️ Роутинг по условиям
Можно настроить маршрутизацию по URL, HTTP-заголовкам или другим параметрам.

➡️ Безопасность и контроль
HAProxy умеет ограничивать частоту запросов, блокировать IP и логировать обращения, что удобно для аудита.

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

✅ Быстрее понять, где может быть ошибка
✅Говорить с командой на одном языке (и даже с умным видом сказать: «ну я так и думал»).

Пример: если запрос с фронта "не доходит до backend'а", и тебе говорят, что "проблема где-то в HAProxy", то ты уже не паникуешь, а понимаешь, что это может быть связано с конфигом, правилами маршрутизации или падением одного из backend'ов.

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

📣 А вы сталкивались с HAProxy в своих проектах? Или вообще с балансировщиками?

IT АНАЛитика | Подписаться

Кто ты сегодня — джун, мидл или сеньор?

Когда меня на работе кому-то представляют:

«Это Виктор, он у нас сеньор»,
я каждый раз немного смущаюсь.

С одной стороны приятно (они ведь реально так думают, и не просто так).
С другой неловко.
Не потому что синдром самозванца, а потому что у каждого своё понимание, кто такой senior.

Всегда найдётся человек, который может спросить:

— «А ты делал задачу X на технологии Y для проекта Z, на 100500 пользователей, в условиях невесомости, с закрытыми глазами и на горящем стуле в поезде?»
— «Не делал, да?»
— «Тогда ты не сеньор. Ты чмоня, лох, позор компании и своих родителей. За что тебе вообще платят? Иди в 1С»

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

Я понимаю, что в рамках корпоративной культуры нельзя просто сказать вместо senior:

«Это чувак, который лучше всех шарит».

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

Но вот в чём парадокс: в одной компании ты можешь быть «сеньором»,
а в другой внезапно «уверенным мидлом».

Реальный пример: парень из Тбанка, сеньор-аналитик, пришёл на собес в Озон.
И там ему говорят — ну максимум джун+.
Те же скиллы, тот же опыт, просто другая культура и другие ожидания.

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

В разных проектах, конечно, свои особенности и требования, но я бы остановился на таких интерпретациях:

1️⃣Джун — неумёха, который хочет расти и развиваться.
Есть базовое понимание вещей, но не хватает опыта и практики, чтобы выполнять задачи самостоятельно.

2️⃣Мидл — уже многое умеет, владеет основными навыками и знаниями,
но иногда сталкивается с задачами, где без помощи будет тяжело.

3️⃣Сеньор — может с любой задачей справиться самостоятельно и без помощи.
Тут даже не обязательно дело в хардах.
Просто если перед ним появляется что-то новое и незнакомое он спокойно разберётся, быстро вникнет в суть и выдаст отличный результат.

А у вас как в команде или компании определяют, кто сеньор, а кто ещё нет?

IT АНАЛитика | Подписаться

Можешь объяснить попроще? Мы стартап

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

Разговор был хороший, вроде не тупил, и, скажу честно, был сильно уверен в себе и рассчитывал на оффер💵.
Это был один из первых собесов по системному дизайну, я тогда ещё не прочитал ТУ САМУЮ КНИГУ.

Но потом пришёл вот такой ответ (картинка к посту).

Честно? Я бы даже больше обрадовался, если бы меня просто назвали чмоней и сказали, где конкретно не зашло.

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

«Ок, мы видим, что ты тут шаришь, давай дальше».

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

А вы как считаете — что важнее на собесе: глубина или скорость? Делитесь в комментариях

🦄 — если детали важнее
🐶 — если скорость решает

IT АНАЛитика | Подписаться

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

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

Посты
Набор уроков, чтобы начать лучше писать текст
Сайт, через который можно прогонять свой текст на "воду" (удобно при описании задач)
Шаблон для описания методов
Подборка шаблонов для аналитика на каждый день
Про HAProxy aka балансировщик нагрузки
Про грейды в IT и их целесообразность
Как я сходил на собес в стартап в прошлом году

Интересные статьи
Одна из инструкций на тему, как начать пользоваться PlantUML на практике
Про работу кросс-функциональных команд по модели Spotify

Мемы
Бизнес спрашивает у аналитика за оценку
Настраиваем почту по принуждению

#итоги_месяца

IT АНАЛитика | Подписаться

НУ ОН!!!!!Карл Вигерс😏

В 2020 я переходил из саппорта в бизнес-анализ.
И первую неделю на новой роли делал то, что делают, наверное, все в такой ситуации:

шарился по сетевым дискам в поисках хоть какой-то полезной информации.

И вот я нахожу ТОТ САМЫЙ файл с легендарным названием:
razrabotka-trebovaniy-k-programmnomu-obespecheniyu-3-e-izdanie-2014 (12).pdf

Открываю. Начинаю читать.
И ловлю себя на мысли: «Подождите… это что, это про меня?!»

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

Эта книга дала мне очень сильный старт.
Я в своем познании настолько преисполнился....

Потом я еще читал:
🟣A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)
🟣Руководство по улучшению бизнес-процессов
🟣Искусство системного мышления
🟣Настольная книга аналитика

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

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

И к чему это всё.

Канал перевалил за 2к человек, и мне как-то захотелось отметить это, но не просто словами типа «спасибо за доверие» (хотя спасибо, правда).

Поэтому я решил разыграть эту книгу.
Бумажную. Настоящую. Ту самую.
Условия будут в следующем посте.

А вы читали Вигерса?

IT АНАЛитика | Подписаться

Mapping: что это такое и зачем знать аналитику?

Если вы работаете с интеграциями, то наверняка хотя бы раз сталкивались с маппингом.
Штука простая… пока её не забыли сделать🙈.

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

Разберёмся, что это и зачем оно вообще нужно.

Что такое маппинг?🧠
Маппинг - это понятная таблица соответствий, которая показывает, какие данные из нашей системы должны попасть во внешнюю и в каком виде.

Если совсем по-простому, это способ ответить на три вопроса:

🟣Что у нас есть?
Как поле называется у нас и какое значение там лежит.

🟣Что ждёт другая система?
Как это поле называется у них и что они хотят получить.

🟣Нужно ли что-то менять по пути?
Например, формат даты, статус клиента, код справочника или структуру данных.

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

Где аналитик сталкивается с маппингом?
➡️Интеграции - 90% всех задач.
➡️Проработка API - особенно, когда описываем входящие/выходящие данные.
➡️Миграции данных - когда нужно переносить информацию между разными системами.

📄 Пример
Допустим, внешняя система хочет получать от нас 5 полей о клиенте:

clientId, fullName, birthDate, status, riskSegment.

А у нас это хранится как:

id, fio, dob, clientCategory, riskLevel.

Разные названия, разные форматы, иногда разные справочники. Где-то дата в формате DD.MM.YYYY, где-то статус хранится текстом, а у них нужен код.

Что делает аналитик?
Он готовит маппинг, в котором чётко прописывает:

🐗 Как поле называется у нас и где оно живёт (таблица, метод, сервис).
🦛 Как называется поле у внешней системы и что оно означает.
🐘 Как преобразовать данные: формат даты, перекодировка статуса, замена справочника.
🧌 Что делать, если данных нет: ставим null, считаем, не передаём.

Частые ошибки
➡️Пропустили обязательное поле
Самое популярное. Ориентировались на старую доку, не уточнили обязательность, в итоге интеграция падает.

➡️Неверный формат данных
Например, внешняя система ждёт число, а мы отправляем строку.

➡️Не проработали справочники
У нас значение хранится, как "ACTIVE", у них оно "01".

➡️Нет логики поведения при отсутствии данных
Поле пустое, что делать? Отдавать null? Рассчитывать? Не отправлять?

🍌 Мини-чеклист хорошего маппинга

1⃣ Добавляйте комментарии.
Если у поля есть логика - фиксируйте её.

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

3⃣ Указывайте источник
Таблица, API-метод, сервис - откуда поле достаем.

4⃣ Версионируйте
Убрали поле? Лучше отмечайте причину и ссылку на задачу. Через полгода проще будет вспомнить, если возникнут проблемы.

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

📣А вы часто делаете маппинг в своих задачах?

IT АНАЛитика | Подписаться

Шанс, что вас на собесе спросят за SQL маловероятен, но никогда не равен нулю😐
Я уже писал, про "Нужен ли аналитику SQL?" и что почитать для старта.

Вот ещё одна хорошая статья, чтобы закрыть базу и чувствовать себя увереннее перед любыми интервью:
Читать📚

P.S Всех РАБотяг с пятницей!