Проектируем сервис HTTP-запросов: Kafka, PostgreSQL, Redis-очередь и миллионы логических партиций

⏳ 11 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Agile systems engineering по ISO/IEC/IEEE 24748-10:2026: как быть гибким и не потерять жизненный цикл

⏳ 10 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Безопасность ИИ: как перестать бежать анализировать каждое новое ПО и перейти к системному подходу

⏳ 9 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Дерево решений vs граф работ: как я объединила Data Science и JTBD в одном проекте

⏳ 8 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Салют! Хочу продолжить тему невидимых / очевидных требований, и поделиться еще одной историей с моей рабочей жизни))

‼️ «Сделайте нам заявку» — и два цеха три месяца не могли договориться

До финтеха я работала аналитиком в крупной нефтепереработке — участвовала в проектах автоматизации производственных процессов на заводе. Это совсем другой мир: здесь заказчики — не продакты в кроссовках, а начальники цехов с тридцатилетним стажем, которые привыкли работать в Excel, журналах и телефонных звонках.

Один из проектов — автоматизация подачи заявок на ремонт оборудования. Звучит просто.

Бизнес-заказчик — главный механик — сформулировал задачу так:

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

Все кивнули. Я записала. Пошли проектировать.

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

Второе интервью — начальник технологического цеха. И тут я понимаю, что он описывает совершенно другой процесс 🤯

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

Оба называли это словом «заявка на ремонт». Но за этим словом скрывались два принципиально разных процесса: в одном случае — административное поручение внутри цеха, в другом — межведомственное согласование с остановкой производственной установки и рисками для безопасности.

Если бы мы спроектировали одну форму под оба сценария — она не подошла бы ни одному.

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

В итоге оказалось, что под «заявкой на ремонт» на заводе существовало пять разных сценариев с разными маршрутами согласования, разными сроками, разными уровнями критичности и разными ответственными. Некоторые из них пересекались, некоторые — нет.

Я собрала это в карту процессов с разветвлениями по типу оборудования и категории работ. Когда вынесла на общий митинг — начальники цехов впервые увидели процессы друг друга.

Главный механик сказал:

«Я не знал, что у технологов это работает вот так».

‼️ Что этот проект закрепил для меня навсегда:

✅ На производстве слова особенно обманчивы — один термин может означать разное в зависимости от цеха, должности и стажа собеседника.
✅ Всегда проси показать реальный документ или журнал: бумажный процесс честнее любого описания на словах — в нём видны все обходные пути и неформальные договорённости.
✅ Интервью только с «главным заказчиком» — это половина картины. Истина живёт на уровне исполнителей и смежников.
✅ Карта процессов как артефакт работает лучше любого ТЗ на старте — люди узнают себя и сами начинают уточнять и исправлять.

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

Вывод: Чем сложнее домен — тем опаснее простые формулировки. Когда опытный заводчанин говорит «ну это понятно» — это сигнал остановиться и спросить ещё раз, но по-другому: «Покажи мне конкретный случай из прошлого месяца». Именно там, в реальном примере, прячется настоящее требование.

Источник: @ba_and_sa

💙 BA|SA | 💬 BA|SA

AI-friendly и AI-first: как адаптировать ИТ-проекты под эру LLM

⏳ 6 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Семь раз посчитай — один раз урони: моделируем инциденты до деплоя

⏳ 8 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст

⏳ 12 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Аналитики и нагрузочное тестирование: как это работает на практике

⏳ 11 мин | 🟡⚪️⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Об организации труда ИИ-агентов

⏳ 32 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT

Почему проекты превращаются в спагетти даже у хороших программистов

⏳ 4 мин | 🟡🟡⚪️

Читать статью | @analysis_it

💙 Analyst IT | 💬 Analyst IT