Analyst IT

Почему я перестала доверять «очевидным» требованиям Есть одна фраза, от которой у меня теперь непроизвольно сжимается желудок🤨. Звучит она так: «Ну это же понятно, зачем это писать». За несколько лет в аналитике я слышала её десятки раз — от бизнеса, от заказчиков, от коллег. И почти каждый раз за этой фразой прятался баг. Не в коде. В голове у людей, которые были уверены, что думают об одном и том же. Расскажу один конкретный случай из своей практики в финтехе. Мы работали над внутренним порталом для операционного отдела. На установочном митинге руководитель направления сказал: «Нам нужна кнопка выгрузки отчёта по клиентам» Коротко. Чётко. Все кивнули — и я в том числе. Требование ушло в бэклог. Через пять недель разработчики показали готовую выгрузку: все поля на месте, данные корректные, формат .xlsx, скачивается за секунду. Я проверила — полное соответствие тому, что обсуждали. Передаю на приёмку. Через час приходит сообщение: «Это не тот отчёт. Нам нужна выгрузка строго по форме № ОП-7 из нашего внутреннего регламента — с группировкой по менеджерам, подитогами по продуктам и отдельной вкладкой для просроченных клиентов». Про форму № ОП-7 на митинге не было сказано ни слова. Потому что «это же очевидно» 🤯 Две недели переделок. Недовольный заказчик. Разбор полётов с тимлидом. И главное — ощущение, что я подвела команду, хотя сделала ровно то, о чём договорились. После этого случая я изменила подход к сбору требований. Теперь любое упоминание слов «отчёт», «выгрузка», «уведомление», «форма», «статус» — это для меня стоп-сигнал. Я не иду дальше, пока не получу ответ на три вопроса: 1️⃣ Как это выглядит прямо сейчас? Покажи файл, скриншот, распечатку — что угодно реальное. 2️⃣ Кто это использует и когда? Конкретный человек, конкретная ситуация. 3️⃣ Что произойдёт, если этого не будет? Это помогает понять реальный приоритет и критичность. Эти три вопроса кажутся простыми — но именно они вскрывают всё скрытое. Форму № ОП-7. Макросы. Регламенты безопасности. Согласования со смежниками. То, что заказчик считает само собой разумеющимся и поэтому не говорит вслух. Самое неприятное в «очевидных» требованиях — они не выглядят как проблема. Никто не молчит намеренно. Люди просто не умеют видеть границу между тем, что знают они, и тем, что знаешь ты. Это не злой умысел — это разрыв контекстов. И устранять этот разрыв — наша работа, а не заказчика. Вывод: Документируй не то, что кажется сложным, — а то, что кажется очевидным. Именно там живут самые дорогие ошибки. Один уточняющий вопрос на старте стоит дешевле двух недель переделок на финише. Я убедилась в этом на собственном опыте — и теперь не киваю молча никогда! Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Архитектура предприятия: от гипотез к комплексным действиям Мы подготовили для вас 2 бесплатных вебинара курса «Enterprise Architect» для тех, кто хочет освоить современные инструменты бизнес-архитектуры. Не пропустите — регистрируйтесь прямо сейчас! 🔹 Вебинар 1. От стратегии к портфелю изменений: как архитектор связывает цели бизнеса, инициативы и архитектурные решения.- https://clck.ru/3TF3mN 30 апреля в 19:00 МСК Вы узнаете: - Дерево целей организации - Связь целей и инициатив - Понимание способностей и приоритизация их изменений - Переходим в ИТ-ландшафт 🔹 Вебинар 2. Архитектор как модератор изменений: как проводить архитектурные решения через стейкхоледеров.- https://clck.ru/3TF3mN 14 мая в 19:00 МСК Программа вебинара: - Архитектор как фасилитатор - Техника управления стейкхолдерами - Управление требованиями 🎯 Почему стоит участвовать: • практический подход и инструменты для работы; • разбор реальных кейсов; • ответы экспертов в прямом эфире; 👉 Регистрируйтесь сейчас, а мы напомним о вебинаре накануне! OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Как разрабатывать интеграционные решения в крупных компаниях: методология и артефакты ⏳ 7 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

«Невидимые требования» — главная причина провала проектов Салют! Сегодня хочу поговорить о проблеме, с которой может столкнуться каждый аналитик — вне зависимости от домена, компании и стека. Про требования, которые никто не записал. Не потому что забыли. А потому что считали: это и так понятно. Я сама сталкивалась с такой ситуацией и не раз 🥲 Большинство проектных провалов связаны не с техническими проблемами, а с плохо собранными или неполными требованиями. Но когда начинаешь разбираться в таком проекте — почти никогда не находишь явной халтуры. Люди работали. Митинги проводились. Документы писались. Вроде все гуд, все работали! ‼️ Проблема в другом. Есть целый класс требований, которые не попадают ни в один документ — потому что в момент разговора обе стороны искренне убеждены, что понимают друг друга. ✔️ Заказчик не договаривает детали — он уверен, что они очевидны. ✔️ Аналитик не уточняет — боится выглядеть некомпетентно. ✔️ Разработчик молчит — думает, что аналитик разберётся. Так рождается иллюзия согласия. Все кивают на митинге. Все расходятся с ощущением, что договорились. А потом, на приёмке, выясняется, что каждый имел в виду своё. Я называю такие требования - «невидимыми». Они не злонамеренные и не случайные — они системные. И появляются по трём предсказуемым причинам: 1️⃣ Разрыв контекстов. Заказчик живёт внутри своего процесса годами — для него многое фоновое знание, которое он физически не умеет передать словами. Он не скрывает, он просто не видит, что скрывает. 2️⃣ Разница уровней абстракции. Бизнес думает результатами и процессами. Аналитик — сущностями и логикой. Разработчик — данными и структурами. Одно и то же слово на каждом уровне означает разное. 3️⃣ Социальная динамика. Задавать уточняющие вопросы неловко — кажется, что ставишь под сомнение компетентность собеседника или собственную. Молчание воспринимается как понимание, хотя на самом деле это просто вежливость. Всё это вместе создаёт среду, в которой невидимые требования не просто появляются — они неизбежны, если аналитик не выстраивает процесс их намеренного извлечения. Именно об этом хочу написать несколько постов с моими примерами. Не о том, как правильно заполнять шаблоны требований. А о том, как вытаскивать то, что люди не говорят вслух, — методично, без конфликта и без лишних митингов🧐 Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

System Design: проектируем сервис заказа такси ⏳ 21 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Кто решает судьбу вашего проекта? Разбираем заинтересованные стороны. BABOK #1 ⏳ 8 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Салют! Сегодня хочу напомнить, что у меня выходили посты с вопросами, которые любят задавать на собеседованиях. Часть 1 Часть 2 В сумме вышло 50 вопросов, с их разбором, также собрала все вопросы в pdf формате, можно скачать, будет полезно)) Готовится вторая часть таких вопросов уже с уклоном на ИИ, покажу, что изменилось и какие сейчас дополнительные вопросы задают на собесах 🧐 Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

От ТЗ до сертификата: как интегрировать оценку соответствия в жизненный цикл продукта ⏳ 7 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Это ты завтра на рабочем месте …

MoneyDev: как заработать на макулатуре ⏳ 21 мин | 🟡⚪️⚪️ Читать статью | @ analysis_it 💙 Analyst IT | 💬 Analyst IT

🔥 Приглашаем на бесплатный открытый вебинар курса «Микросервисная архитектура»: “Основы проектирования бизнес-логики в микросервисной архитектуре” На этом уроке мы поговорим о подходах к проектированию бизнес-логики в распределённых системах: как декомпозировать логику по сервисам, какие паттерны использовать и как избежать хаоса при росте приложения. Что будет на вебинаре: • Принципы проектирования бизнес-логики в микросервисной архитектуре • Основные паттерны: Shared Kernel, API Composition, Saga и др. • Где должна жить логика — в сервисе, API-шлюзе или общем слое? • Ошибки при проектировании и как их избежать на ранних этапах. • Кейсы из реальной практики: как правильно декомпозировать сложную бизнес-логику 👉 Зарегистрируйтесь https://clck.ru/3SyS89 Бесплатное занятие приурочено к старту курса Микросервисная архитектура, на котором вы научитесь проектировать распределённые системы, интегрировать сервисы через брокеры сообщений и добиваться высокой доступности. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Коллеги, интересное наблюдение из свежей статистики по BI: каждый пятый корпоративный пользователь уже обращается к ИИ-агентам за поиском бизнес-инсайтов. Подробности в новости: https://ko.ru/news/kazhdyy-pyatyy-korporativnyy-polzovatel-prosit-ii-agenta-nayti-biznes-insayty/?ysclid=mneiwo7f1j748287914 Что важно: ИИ перестал быть «надстройкой» и становится повседневным инструментом аналитика. 73% пользователей используют его для генерации формул, а половина — для интерпретации графиков. Причём речь не просто о подписи осей: агент на естественном языке объясняет динамику, находит аномалии и помогает валидировать гипотезы. По отраслям картина ожидаемая, но показательная: лидирует ИТ (40%), затем ритейл (25%), финтех (10%), логистика (5%), медицина (4%). То есть там, где скорость реакции на данные напрямую влияет на деньги. Ключевая ценность — сокращение времени от данных к решению. Если в ритейле задержка в обнаружении падения маржи на 5 дней может стоить 15–20 млн, то ИИ позволяет сократить этот лаг до часов за счёт мгновенных срезов и автоматического поиска отклонений. Фактически мы видим сдвиг: BI-инструменты эволюционируют от «дашбордов для чтения» к «собеседникам по данным». Вопрос уже не в том, использовать ли ИИ, а в том, как встроить его в ежедневные аналитические процессы без потери качества интерпретации.

ИИ-агенты защищают друг друга от отключения: анализ уязвимостей в передовых моделях ⏳ 11 мин | 🟡⚪️⚪️ Читать статью | @analysis_it

Салют! На днях писала пост про то, как ИИ повлиял на нашу работу. Сегодня привожу пример с моей рабочей жизни) Пример: Интеграция с внешним API поставщика Был проект по автоматизации закупок. Нужно было интегрироваться с API крупного поставщика, у которого документация была… как бы помягче… «исторической». Swagger-спеки не было, был PDF на 200 страниц, где описание полей шло вперемешку с юридическими оговорками и примерами на устаревшем XML. Задача: спроектировать систему обмена данными (заказы, статусы, отгрузки), описать маппинги полей и написать ТЗ для разработки адаптера. 👩‍💻 Как я использовала ИИ 1. Структурирование «мусора» Я скормила ИИ (через API, с соблюдением всех NDA и анонимизацией данных) выдержки из PDF — только описания методов и схемы объектов. Промпт был такой:

У меня есть описание REST API (фрагменты). Документация неструктурированная. Выдели все эндпоинты, методы, обязательные и опциональные параметры. Приведи в виде таблицы: эндпоинт, метод, описание, входные параметры (с типами), выходные параметры. Если есть зависимости между вызовами — отметь. Не додумывай, только то, что явно написано

ИИ вытащил структуру за 15 мин, которую я вручную собирала бы 2–3 дня. Да, были неточности — нейросеть иногда путала description поля с примером значения. Но база была готова. 2. Генерация маппингов Дальше нужно было сопоставить поля поставщика с нашей внутренней моделью данных. Я подготовила таблицу с нашей схемой (поля, типы, ограничения) и дала задание:

Вот поля поставщика (колонка A), вот наши поля (колонка B). Предложи маппинг. Где нет прямого соответствия — отметь как “требует преобразования” и предложи вариант логики. Где данных не хватает — отметь как “требует уточнения у бизнеса”

ИИ выдал черновик маппинга с 40+ полями. Из них около 30 я приняла без изменений, в 7 добавила свои правки, а 3 действительно пошли на уточнение к заказчику (и оказалось, что эти поля реально не используются — я бы сама копалась полдня). 3. Написание ТЗ для разработчиков Самый приятный момент. У меня была готова структура: эндпоинты, маппинги, бизнес-сценарии. Нужно было превратить это в ТЗ, которое не вызовет у разработчиков 100500 уточняющих вопросов. Я использовала ИИ так:

У меня есть описание интеграции. Напиши раздел ТЗ “Логика обработки ошибок” для следующих сценариев: таймаут, 4xx, 5xx, невалидный JSON. Для каждого укажи: что логируем, нужен ли ретрай (с какой задержкой), переходим ли в ручной режим. Стиль — технически точный, без воды

ИИ сгенерировал матрицу обработки ошибок, которую я только немного адаптировала под наши корпоративные стандарты (у нас своя политика ретраев с экспоненциальной задержкой). Аналогично я накидала: - описание аутентификации - примеры запросов/ответов (которые ИИ сгенерировал на основе структуры полей) - чек-лист для приемки интеграции (разработчик сказал потом: «О, тут даже кейс с пустым массивом учтен — спасибо, я б забыл») 4. Валидация (ключевой момент!) И вот тут — самое важное. Я не просто скопировала результат. Когда ИИ сгенерировал маппинг, я заметила странность: поле delivery_address.line2 он замаппил на наше address_extra, а поле delivery_address.full — на наше address_full. Но в документации поставщика было написано, что line2 используется только если full не заполнен. Это бизнес-логика, которую нейросеть упустила (или она была на другой странице PDF, которую я не скормила). Я докрутила: добавила условие «если full не пуст — берем его, иначе формируем из line1 + line2». ‼️ Без моей экспертизы это уехало бы в разработку, а потом — баг на тестировании и лишняя итерация. Что по итогу Итого: вместо 4–5 рабочих дней я уложилась в 1,5 дня. При этом качество выросло — потому что время освободилось на сложную логику и валидацию, а не на перепечатывание полей из PDF в Excel. ‼️В комментариях оставила небольшой вывод👇 Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

Observability в финтехе: связываем клик пользователя с падением интеграции ⏳ 10 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

Как проектировать интеграции с Kafka ⏳ 7 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT

🔵🗣Вырасти до хардового Middle+ аналитика. Как? Добавьте к своим скилам навыки в проектировании архитектуры и интеграций веб-сервисов! Рассмотрите — авторский курс про архитектуру и интеграции с практикой. ————— По результатам курса вы: ▫️научитесь выбирать стиль интеграции под вашу задачу; ▫️сможете проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и др. + брокеры сообщений); ▫️поймете, как правильно собирать требования и моделировать в UML; ▫️подготовитесь к собеседованию, решив более 100 тестов; ▫️разработаете свой API на Python; ————— 🟢Вы получите большую базу фундаментальных знаний, доступ к урокам и обновлениям остается навсегда 💡 • Всю программу и отзывы смотрите в боте курса. • Бонусный модуль про проектирование баз данных — нормализация, транзакции, основы DWH, индексы. • Результат после прохождения курса: 15 рабочих проектов в портфолио. • Доступ к чату учеников (общение, обмен опытом, помощь внутри сообщества) 🔹🔹 С чего начать?🔹🔹 С открытых бесплатных уроков по архитектуре и интеграциям в чат-боте курса. Переходите. 👇 @studyit_help_bot Скидка на курс от канала — 1 500₽ по промокоду ANALY до конца марта

От нуля до продакшена: как команда без ML-экспертизы построила AI-ассистента для звонков ⏳ 11 мин | 🟡🟡⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT