Дамы, с 8 марта! 🌷

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

Пусть рядом будут люди, которые ценят вас не только за ум, работу и профессионализм, но и просто за то, какие вы есть.

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

С праздником! ❤️

IT АНАЛитика

7 признаков того, что команде пора брать аналитика.

Я бы добавил ещё один — разработчики занимаются аналитикой вместо разработки.
А у вас такое было? 👇

Читать📚

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

Как работать со смежной командой?😐

Для каждого, кто работал со смежной командой, скорее всего будет жиза 🙂

Пишешь такой письмо коллегам:

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

Проходит неделя и ТИ ШИ НА.

Чаще всего это не специально (хотя бывает и так). Люди просто не понимают, что вы от них хотите, не знают как помочь или заняты своими задачами. И вот тут твоя задача — сделать так, чтобы им было легче тебе помочь.

Вот как я бы выстроил эту работу:

1. Нормально познакомиться 🤝
Не просто «нам нужно от вас вот это». Объясните кто вы, зачем пришли и что от них потребуется на каждом этапе. Люди охотнее помогают тем, кого понимают. В идеале сразу ставьте встречу.

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

3. Фиксируйте все договорённости письменно 📝
Устные «Ало задача? Да, да релиз» — не считаются. После каждой встречи отправляйте короткий итог: кто что делает и в какой срок. Переписка вас спасёт, если кто-то проеб*тся.

4. Помогите им помочь вам 💡
Если смежная команда тормозит — не ждите. Спросите, в чём проблема. Дайте шаблон, гайд, контакт нужного человека и всё сразу пойдёт быстрее.

5. Эскалируйте вовремя 🚨
Если письма уходят в тишину — не ждите. Подключайте руководителей. Но сначала всегда пробуйте решить мягко.

Нашел статью по теме с разбором кейсов при работе со смежными командами, если захотите углубиться в тему:
Читать 📚

А какой пункт у вас чаще всего проседает? 👇

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

Если вы читаете это, значит вы и есть сопротивление.

Я когда-то знал людей, которые предупреждали: без нормальной аналитики всё рухнет. Что требования надо фиксировать. Что устные договорённости это катастрофа. Никто не хотел их слушать. Бизнес игнорировал. Разработчики смеялись. Тимлиды отмахивались.

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

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

Врываемся в новую рабочую неделю🎧
Постов не было месяц, админ восстанавливал силы в отпуске.
Теперь всё, возвращаемся в work mode 💼

Ждете уже майские? Какие планы?
#поддержка

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

Ты точно знаешь, что такое архитектура? 🤔

Недавно был на собесе и получил вопрос:

«А что такое архитектура? Зачем она вообще нужна?»

А почему солнце светит?

В комментарии выложу картинку, как выглядело моё лицо в тот момент 🙂.

Обычно такие вопросы задают с одной из двух целей.
1. Проверить самообладание.
Бизнес порой задаёт простые или странные вопросы, и важно уметь спокойно на них отвечать.
Помню, как на собесе кандидату задали простой вопрос, а он выдал: «РРЯЯЯЯЯЯЯ ВЫ ЧЕ ТУПЫЕ, НУ КТО ТАКОЕ СПРАШИВАЕТ, НУ ВЫ И КРИНЖ»

2. Проверить логику и базовые знания.
Именно на простых вопросах многие неожиданно сыплются.

Кажется, что это очевидно. Но попробуйте объяснить прямо сейчас не подглядывая 👀

Что такое архитектура? 🧱
Если совсем по-простому, то это чертёж системы.

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

Зачем это знать аналитику?🤔
Ну, во-первых, чтобы меньше платить и не брать полноценного архитектора .

Если серьёзно, то как ты будешь проводить системный анализ в отрыве от самой системы? Любое решение проектируется внутри какой-то архитектуры, и не понимать как она устроена ну вообще никак.

Не понимаешь архитектуру → не понимаешь ограничения → пишешь требования, которые невозможно реализовать. Или реализовать можно, но потом всё ломается.

Самые популярные виды:
➡️ Монолит Вся система это один большой кусок. Логика, база и интерфейс лежат в одном месте.
На старте это просто и удобно, особенно если приложение небольшое. Но чем больше система растёт, тем тяжелее её масштабировать и менять.

➡️Микросервисы Система разбита на маленькие независимые сервисы, каждый отвечает за свою задачу. Главный плюс, если один сервис упал, остальные продолжают работать. Гибко и устойчиво.
Но есть нюансы: сервисов много, значит много интеграций, много мест где может что-то пойти не так, и отлаживать, деплоить и мониторить всё это заметно сложнее чем монолит.

Дальше уже идут архитектурные паттерны, в рамках которых можно реализовать ту или иную систему.

Что будет, если накосячить? 💀
Архитектурные ошибки самые дорогие.

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

Именно поэтому архитектурные решения принимаются в самом начале и согласовываются со всеми заинтересованными сторонами.

А вам на собесах задавали базовые вопросы, от которых хотелось сказать «подержи моё пиво, ща тебе расскажу»? Делитесь в комментариях 👇

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

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

Раньше на канале выходили посты про технические штуки:
ConfigMap: Что такое и зачем?
Что такое Feign?
MAPI: что это и зачем знать аналитикам?
Что такое DTO и зачем это знать аналитику?
HAProxy: зачем это знать аналитику?
Mapping: что это такое и зачем знать аналитику?

Хочется сделать из этого отдельную рубрику про вещи, которые все скорее всего знают, они на слуху, но если спросить, в ответ услышишь: «ну блин, это же это вот, да блин, все знают, ёмоё» 🙂

Что такое CQRS?

CQRS — архитектурный паттерн. Расшифровывается как Command Query Responsibility Segregation — разделение ответственности команд и запросов.

По-простому: операции чтения (Query) и изменения данных (Command) разделяются и живут независимо друг от друга.

В классическом подходе команды и запросы идут вместе. CQRS говорит: разделите их. Пусть каждый занимается своей задачей.

Пример🏦

Допустим, есть сервис работы со счетами.

Есть сервис счетов.

Пользователи постоянно:
— смотрят баланс
— открывают историю операций

Это чтение.

Параллельно идут:
— переводы
— пополнения
— списания

Это запись.

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

CQRS решает это разделением: отдельная модель для чтения, отдельная для записи. И дальше это можно удобно масштабировать.

Важный момент: CQRS не обязательно означает две отдельные модели данных. Модель может быть одна, но пути для чтения и записи разные. Две модели — это один из вариантов реализации, который часто используют вместе с Event Sourcing.

Когда применять, а когда нет 🤔

Подойдет, если:
🆗 Нагрузка на чтение и запись сильно отличается
🆗 Сложная бизнес-логика на запись
🆗 Есть требования к производительности
🆗 Нужна независимая масштабируемость в процессах

Не лучший вариант, если у вас:
❌ Простое CRUD-приложение
❌ Маленький проект и команда
❌ нет понимания, зачем это нужно
❌ Не готовы к сложности синхронизации — если используете две модели, данные для чтения могут отставать от записи (eventual consistency)

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

Ну и на собесе спросят. Лучше ответить нормально, чем мычать 🙂

А вы сталкивались с CQRS в своих проектах?
#технические_штуки

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

CJM, USM, CGI — кто лишний?🤔

Раньше на канале были посты про USM:
➡️Прибейте меня, я веду проект с нуля. Часть 5
➡️Как с этим работать?

Сегодня про похожий, но другой инструмент — CJM.

Что такое CJM?
Customer Journey Map или карта пути клиента.

Если USM отвечает на вопрос «что нужно построить и как разложить по задачам», то CJM отвечает на другой — «что чувствует и думает пользователь, пока идёт по продукту».

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

Чем CJM отличается от USM?
USM это про команду и разработку.
Помогает декомпозировать продукт на задачи и понять что пихать в MVP.

CJM это про пользователя.
Помогает понять где ему больно, где он уходит и почему не возвращается.

Когда аналитику пригодится CJM?
CJM это больше инструмент продакта, и аналитик работает с ним ещё реже чем с USM.

Но бывает два случая когда он может пригодится:
➡️ Старт продукта — если вы достаточно глубоко погружены, CJM поможет заранее увидеть слабые места до начала разработки.

➡️ Упали метрики — если вы работаете с аналитикой и что-то пошло не так, CJM поможет найти где именно пользователь спотыкается.

Хорошая статья про то как строить CJM на практике, с примерами Читать📚

Приходилось сталкиваться с CJM? Или у вас этим занимается только продакт? 👇

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

Как выявить х*евое требование?🗑

Если вы не работали с такими требованиями, то можно сказать, и не работали в IT.

Бизнес иногда приносит ТАКОЕ, от чего вполне может развиться выгорание или ПТСР.
Конечно, можно смириться и делать что скажут жестко осуждаем такой подход и никому не советуем.

Но задача аналитика не просто принять требования и оформить, а разобраться — точно ли нужно делать именно так? И если нет, донести это без скандала.

Вот как можно разложить это по шагам:

1. Сначала идентифицируй требование🧐
Прежде чем паниковать, задай себе три вопроса:
⏺Если это не реализовать, бизнес-потребность всё равно закроется?
⏺Можно закрыть это имеющейся функциональностью или сделать проще?
⏺Есть ли риски в реализации этого требования?

Часто уже на этом шаге становится понятно, что требование можно упростить или вообще выкинуть.

2. Выяви истинную потребность🔍
Бизнес часто говорит что хочет, но не всегда понимает что ему на самом деле нужно.
Копай глубже:
💬Какую задачу он пытается решить?
💬Что произойдёт, если это не сделать?
💬Есть ли ограничения, которые не дают рассматривать другие варианты?

Если ограничения есть и альтернатив нет, то сразу переходи к шагу 4.

3. Предложи альтернативы 💡
Не просто скажи «это плохо/делать не будем/вы не шарите», а покажи варианты:

➡️ Вариант 1 — что хочет бизнес.
Опиши честно, какие трудности это создаст. Без субъективного «это тупо/сложно/некрасиво», только сухие факты. Обычно после оценки и сроков этот вариант сам отметается 🙂

➡️ Вариант 2 — некий костыль.
Может, можно сделать небольшую доработку уже существующего функционала? Обычно это самый дешёвый и быстрый вариант. Но не всегда самый правильный, тут важно обсудить его с архитектурой, потому что иногда костыль это очень плохо!!!!!!!

➡️ Вариант 3 — самый трушный.
Решение, которое закрывает потребность бизнеса с минимальными рисками. Да, может быть дороже, но в долгосрок все выигрывают и переделывать точно не придётся.

4. Зафиксируй ограничения и риски 📝
Бывает, бизнес хочет эту зелёную кнопку «ну вот тока тут». Не всегда получается переубедить, такое иногда бывает.

Да ты че? Базару нет

Но перед тем как брать в работу, обязательно зафиксируй все риски и ограничения письменно. Пропиши возможные последствия и способы их устранения.
Если на демо или ПСИ кинут предъяву, сможешь уверенно и без задней мысли сказать: «А Я ВАМ ГОВОРИЛ!!!!!!!!!!!!!!!»

5. Полный газ👍
Всё согласовано, риски зафиксированы, спокойно приступаешь к аналитике.

Главное помни: твоя задача не просто выполнить требование, а помочь бизнесу получить качественный результат. Иногда это значит задать неудобный вопрос:

"Подождите, коллеги. Я вас правильно понял? Вы хотите сделать какую-то х*ету?

А вам часто прилетают плохие требования? Как справляетесь? 👇

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

Ты точно умеешь писать документацию? 📝

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

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

Вот одни из самых частых ошибок:

1. Внутри много много мяса, мало теста.🥟
Длинные нагромождённые предложения, где много слов и смысл быстро теряется.

Плохо🤡:
Сервис проверки клиента предназначен для осуществления проверки корректности введённых пользователем данных в рамках процесса оформления кредита с учётом действующих ограничений и бизнес-правил»

Хорошо🤩:
Сервис проверяет данные клиента при оформлении заявки на кредит.

Лучше несколько коротких предложений, чем одно гигантское.

2. Жаргон в документах 🤓куку епта
Если в чате написать "пофиксить", "задизейблить", "дропнуть" и.т.д — ок.
То в документации такое уже не ок.

Кто-то может не знать ваших слов или неправильно их интерпретировать. Лучше исключить разночтение заранее.

3. Масло маслянное🤩
Тавтология и бессмысленные повторы только ухудшают восприятие. Если можно написать короче — пишите короче.

«Система должна обеспечивать возможность предоставления доступа пользователям» → достаточно «Система предоставляет доступ пользователям».

«Происходит процесс авторизации пользователя» → «Пользователь авторизуется».

«Выполнить осуществление проверки данных» → «Проверить данные».

«Производится выполнение логирования ошибок» → «Ошибки логируются».

«Происходит процесс сохранения данных в базу данных» → «Данные сохраняются в базу».

4. Противоречия между разделами⚡️
В начале написал одно, в другом разделе уже другое. Лучше не торопиться и лишний раз перечитать документ/задачу/письмо, перед тем как отдавать.
Криво напишите -> Разраб криво сделает -> Тестер криво проверит -> Баг

5. Термины без расшифровки 😏
У вас могут быть специфичные термины внутри продукта, которые знают не все. Через полгода новый человек откроет вашу документацию и вообще не въедет что и как вы тогда реализовывали.

Используете локальный термин — лучше расшифруйте.

P.S. Всё никак не могу дойти до книги «Пиши, сокращай», так и просится.

Часто ловите такое за собой или за коллегами? Я лично постоянно встречаю первый и третий пункт👇

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

Как Москва превратилась в дагестанское село 🗺

Довольно поучительная история от ребят из Авито.

Коротко о сюжете: команда выкатила фичу «Лёгкое резюме». Метрики растут, все радуются. Через неделю обнаруживают, что 45000 резюме создано в селе с населением 7000 человек 😬

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

Что из этого можно вынести:
1. Интеграцию надо проверять с каждым клиентом отдельно.
Android, iOS, web — разные клиенты с разной реализацией. То что работает на одном, может сломаться на другом. Особенно при горящих сроках и спешке.

2. Думай не только про happy path.
Что происходит когда данные некорректны, поле пустое или пользователь сделал что-то неожиданное? Такие сценарии важно проработать и описать ещё на этапе анализа, иначе система сама решит как себя вести.

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

Полная история: Читать 📚

А у вас были баги, которые потом превращались в полноценное расследование?

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

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

Пока отхожу от концерта Ye и догуливаю последние дни отпуска — ловите подборку постов за май 🌴
Были уже в отпуске или когда планируете?

Посты
Ты точно знаешь, что такое архитектура?
CQRS: что это и зачем знать аналитику?
CJM — для чего и зачем?
Как выявить х*евое требование?
Ошибки при написании документации
Kafka на примере котиков

Интересные статьи
Основы Kafka
Как Москва превратилась в дагестанское село


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

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

Кого ты забыл согласовать? 🤔

Чем больше задача — тем больше людей вокруг неё.
Бизнес, смежные команды, архитектор, безопасники, поддержка и всем в какой-то момент «ЧЕТО НАДО».

Я не раз видел на встречах, когда кто-то со стороны заказчика говорил:

А почему так решили сделать? Я это не согласовывал.

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

Зачем вообще это фиксировать?

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

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

А пропустить стейкхолдера это:
😕узнать о пропущенном требовании в самый неподходящий момент.
😐переделывать то, что уже сделано.
🥲краснеть на созвоне и объяснять почему его не позвали.

Что фиксируем?

Для каждого стейкхолдера важно понимать три вещи:
🆗 Кто это и какова его роль?
🆗 Какой у него интерес к задаче?
🆗 На каком этапе и в каком формате его нужно подключить?

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

В комментарии кину пример таблички.

А вы ведёте список стейкхолдеров или держите всё в голове? 👇

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