Анализ и проектирование систем *

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

Оба продукта — CDP (Customer Data Platform) для маркетинга. По сути это база данных, которая собирает информацию о клиенте отовсюду и нарезает её в сегменты, — а сверху на эту базу наслаиваются рассылки, бонусы и акции, ласково выманивающие клиента с дивана. Задача-дубль — конструктор сценариев: визуальный редактор, где кампания собирается цепочкой блоков. Классика жанра — сценарий на день рождения:

Около двух лет я использую Obsidian как основное приложение для ведения заметок, планирования и написания статей. В этой статье я хочу поделиться своим полным workflow: от распределения заметок по папкам и горячих клавиш до детального Cheatsheet по хранилищу и организации метода Zettelkasten.

О чём будет статья:

Архитектура папок (где и что хранится, а также подробный Cheatsheet.md, который я составлял для себя).

Плагины, которые я использую.

Настройка Homepage и каталога книг.

Синхронизация ПК + телефон (плагин Git + Termux на телефоне, у меня репозиторий в Gitea).

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

Это первая статья практической серии, продолжающей тему материала «Автоматизировать бардак нельзя навести порядок». В заглавной статье речь шла о праве ИТ остановить преждевременный переход к реализации. Теперь разберём, что делать после такой остановки: как проверить бизнес-инициативу, отделить проблему от уже выбранного решения и понять, существует ли проект в содержательном смысле.

Когда человек впервые слышит про одногодичную магистратуру, обычно возникает один из двух вопросов:

«А так вообще можно?»

«Что из обычной двухлетней программы пришлось выбросить?»

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

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

 Под катом — три рассказа о внедрении, три типовых истории из жизни.

«Это же бюрократия, у нас и так всё работает!» / «Документация — это отлично, но у нас есть задачи поважнее» / «Катя, я пришла на проект, а у них ничего, а у нас аудит». Эти фразы и еще много подобного я слышала так много раз, что кажется, время этой статьи пришло).

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

Пять пробелов, которые не видны на архитектурных блок-схемах.

Пользователь нажимает «Place Order» (Сделать заказ).

API возвращает 200 OK. Заказ появляется в базе данных. На странице оформления заказа выводится сообщение «success» (успех). Извне всё выглядит нормально.

А потом в службу поддержки прилетает тикет.

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

Современный смартфон представляет собой доступную COTS‑платформу с набором встроенных датчиков: камерой, GNSS‑приемником, 6-DoF IMU, барометром и микрофонами. По отдельности эти сенсоры ограничены, однако их совместное использование в распределенной сети потенциально позволяет создавать новые подходы к обнаружению низколетящих БПЛА.

Это не задача создания «смартфонного радара», а инженерная задача на стыке краудсорсинга, Edge Computing, машинного обучения и обработки сигналов.

Как превратить множество пользовательских устройств в единую распределенную апертуру? Попробуем рассмотреть возможную архитектуру такой системы.

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

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

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

Цель статьи

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

Привет, Хабр! На связи команда Research & Insights Департамента стратегического развития МТС. В первом материале из цикла мы разобрали, чем пятое поколение связи отличается от предыдущих стандартов, какие технологии лежат в его основе и почему операторы рассматривают 5G как фундамент для нового этапа цифровой экономики. Сегодня поговорим о том, как эта технология распространяется по миру. 

На 2025 год в 5G инвестируют 642 мобильных оператора, а коммерчески запустили технологию около 374 раз, но сам факт запуска технологии мало что говорит о зрелости рынка. Заходите под кат, если хотите узнать, как 5G внедряли в США, Китае, Южной Корее, Великобритании и Германии, почему у них получились разные модели монетизации и чего ждать в России. 

Программа nanoCAD Механика PRO в первую очередь предназначена для создания проектов машиностроительной отрасли (детали, механизмы и оборудование). Возможности продукта позволяют решать задачи для выпуска документации с деталями высотой точности. Строительное направление отличается тем, что погрешность на монтаже может доходить до 1 см. Но есть отдельные направления на стыке строительства и машиностроения, это малые архитектурные формы, которые поставляются высокой заводской готовности из металла, пластика и дерева. С учетом развития науки и техники, изготовление таких объектов возможно в короткие сроки и с высокой точностью сборки на монтаже.

Применение nanoCAD Механика PRO позволяет решать задачи не только оформления проектной документации, но и формирования 3D-модели для передачи ее на производство со станками с ЧПУ. Дополнительно 3D-модель может использоваться для передачи геометрии в ТИМ-проекты с целью наполнения базы данных проекта и визуализации, так как малые архитектурные формы могут быть частью строительного проекта. Использование продуктов экосистемы nanoCAD позволяет комплексно решать подобные задачи.

В этой статье рассматриваются практические приемы работы в nanoCAD Механика PRO на примере малых архитектурных форм, которые помогут ускорить процесс конструирования и избежать типичных ошибок. Материал является продолжением вебинара и ориентирован на пользователей, уже знакомых с базовым функционалом программы.

Речь о процедурно‑параметрическом программировании, о котором почти никто не пишет. Я реализовал одну и ту же задачу в ООП и в этой парадигме и сравнил их численно. Одна из метрик разошлась в 6 раз.

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

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

При этом цель осталась прежней – сократить время QA на анализ требований. Раньше приходилось руками собирать всё по ссылкам, искать недостающую информацию, проверять версии файлов, находить таблицы с калькуляциями, файлы с эмуляторами и иногда просто выяснять, какой документ сейчас считается актуальным. Поэтому мы пошли на уровень раньше и начали отдельно собирать корпус требований в Codex (но это уже следующая статья). А в данном материале покажу общий подход и несколько правил из промптов, возможно кому-то они пригодятся.

В предыдущей статье о ГОЭЛРО я писал о программе «А»: прежде чем строить новые мощности, план предусматривал восстановление и реконструкцию существовавшего энергохозяйства. Сначала вернуть основанию работоспособность — и лишь затем возводить на нём новое. Исторически эта часть плана действительно называлась программой «А»; такое описание приводит, в частности, Минэнерго России.

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

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

По обе стороны баррикады спор обычно формулируют одинаково: кто должен диктовать автоматизацию — бизнес или ИТ?

Я всё больше думаю, что это неправильный вопрос.

Бизнес должен иметь последнее слово в вопросах «зачем» и «что»: какую проблему решать, какого эффекта добиваться, чем пожертвовать и какие изменения считать приоритетными. ИТ отвечает за «как»: архитектуру, данные, технологические ограничения, интеграции и жизнеспособность будущего решения.

Всем привет! С вами на связи Евгений Певцов, эксперт по качеству данных группы развития методологии из МТС. Около года назад мои коллеги уже рассказывали, зачем нам потребовались формализованные соглашения об обмене данными и какую проблему они должны были решить.

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

Сейчас дата-контракты — это полноценный сервис, встроенный в существующие ETL-процессы на всем жизненной пути данных. Им ежедневно пользуются продуктовые команды, архитекторы, аналитики и Владельцы данных. 

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

В предыдущей статье мы разобрали третье базовое понятие BABOK — Изменение (Change). Мы выяснили, что изменение — это не событие, а процесс, и что 70% инициатив проваливаются не потому что техника плохая, а потому что человеческая сторона проигнорирована. Но предположим, вы всё сделали правильно: нашли нужных заинтересованных сторон, сформулировали истинную потребность, спроектировали переход. Следующий вопрос — самый дорогостоящий в буквальном смысле слова:

Что именно мы будем строить или менять?

Именно здесь в игру вступает четвёртое базовое понятие BABOK — Решение (Solution). И именно здесь совершается ошибка, за которую бизнес платит дороже всего: команда влюбляется в первое пришедшее в голову техническое решение и перестаёт искать альтернативы.

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

Возьмём типичный пример: неликвидные позиции на складе оценены в 5 млн рублей. При обычной для рынка стоимости хранения запаса 20–30% в год, только за то, что эти позиции занимают место и держат замороженный капитал, склад теряет от 1 до 1,5 млн рублей ежегодно. Через 3–4 года такого хранения суммарные затраты превышают закупочную цену товара. Дальше держать — терять деньги наверняка, продать — терять деньги один раз.

Эта статья — о том, как увидеть эту математику в данных WMS и принять решение раньше, чем она окончательно съест маржу.

Привет, Хаброжители! Системная инженерия — ключевой инструмент для разработки сложных систем на всех этапах их жизненного цикла. В обновленном издании эксперт в области системной инженерии подробно рассказывает, что следует учитывать при проектировании надежных и эффективных систем.

Привет, Хабр! Мы — команда разработки кредитных продуктов для физических лиц в Т-Банке. Делимся опытом нагрузочного тестирования workflow-движка Zeebe (основы Camunda 8), который проводили, когда искали альтернативу Camunda 7.

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

Компания «Нанософт» – ведущий разработчик инженерного программного обеспечения объявляет о выходе версии 26 nanoCAD Облака точек.

nanoCAD Облака точек – специализированное решение на Платформе nanoCAD, предназначенное для обработки данных 3D-сканирования и решения инженерных и информационных задач в области геодезии, машиностроения, строительства, инфраструктурного и метрологического мониторинга.

Версия nanoCAD Облака точек 26 доступна в трех конфигурациях: «ReClouds», «Метрология» и «Геотехнический мониторинг».

Что нового в конфигурации «ReClouds»

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

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

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

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