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

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

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

— Добрый день, Егор! Подскажите, пожалуйста, ориентировочную стоимость проектирования и аудита интерфейса. Уже есть готовый проект, думаем о редизайне.

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

Объясняю в переписке, что всё очень индивидуально и предлагаю время созвона. Моя задача — организовать часовой разговор, во время которого я познакомлюсь с человеком и проектом, а также успею провести экспресс-аудит. Это бесплатно и всегда интересно.

Агенты — одна из горячих тем этого лета: интерес к ним существенно вырос, как и потребность в инструментах, упрощающих разработку таких систем. И мы в Beeline Cloud собрали несколько open source-проектов по теме под лицензией Apache 2.0.

Есть один чудесный советский фильм — «Приключения Электроника». В нём злой персонаж с криком «Где же у него кнопка?!» ищет у мальчика-робота скрытый рычаг, который заставит робота вести себя так, как нужно злодею. Многие руководители и тим лиды, напоминают мне этого персонажа, считая, что человек устроен просто - у него есть "волшебный пендель" или "волшебная кнопка", нажав на которую можно сделать так, чтобы он (сотрудник) наконец начал поступать правильно. И я, грешен, тоже искал эти «кнопки». Но моя практика упрямо показывает: у людей нет таких кнопок.

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

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

Но если вы когда-либо задавались вопросом: «Почему этот человек снова и снова поступает именно так, как поступает?» — возможно, эти паттерны помогут вам увидеть то, что скрыто за словами.

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

Микросервисы обещают решение. Гибкость. Масштабируемость. Независимые команды. Быстрые релизы. Звучит идеально. Но дорога к этой цели усеяна ловушками. Я видел проекты, которые провалились, потратив миллионы. Они просто поменяли один большой клубок проблем на десятки маленьких.

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

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

Чек-лист для аудита проекта внутри.

Практическое руководство по работе со сложными клиентами — с примерами из нефтегаза, госсектора, бизнеса и стартапов.

Эта статья — концентрированный опыт нашей команды аналитиков из компании Rubius, накопленный за годы работы в заказной разработке. Здесь нет теории из учебников — только проверенные на практике методы общения с «Генералами», «Истериками», «Цезарями» и другими сложными типами заказчиков.

Ястолкнулся с такой проблемой: логика между доменами сложнее самих доменов

Если строить систему по DDD: домены, агрегаты, use cases, события - всё красиво.

Потом пришёл сценарий: «Отменить заказ»

Я думал: `Order::cancel()`, вызову `inventory.release()`, `pricing.refund()`, и готово». Но...

• Если доставка уже в пути - нужно создать возвратную накладную

• Если платёж падал дважды - отменить всё, а при первой попытке только заморозить баллы

• Если товара нет - перенести резерв на другой склад, пересчитать доставку, спросить клиента, если дороже

• Если клиент повторил платёж - восстановить резерв и доставку

И я решил:

Самая сложная логика тут не в доменах, а между ними.

А в книжках по DDD, Clean Architecture, Hexagonal об этом не пишут.

Это напомнило проблему в ООП, когда каждый объект отвечает только за свою корректность (инвариант), а логическую зависимость при взаимодействии должен обеспечить ещё один класс "чистая выдумка". Также, у ФП есть более простые и явные способы.

Я напишу на Rust, потому что этот язык удобнее управляет бизнес правилами.

Всем привет! Меня зовут Дима Лунин, я автор курса по экспериментам в Академии Аналитиков Авито. В текущей статье я хочу "обкатать" материал, который мы рассказываем на курсе экспериментов, а также поделиться экспертизой по АБ-тестированию с ребятами, которые только начинают свой путь в аналитике, но уже имеют базовые знания в статистике и в проверке стат. гипотез.

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

Продолжаем изучение по работе с требованиями по Карлу Вигерсу. В этой статье законспектированы разработка (выявление, анализ, документирование, утверждение) и управление требования.

Когда мы проектируем ИИ-агентов, мы обычно начинаем с анализа пользовательского опыта: клики, воронки, метрики.
Но что, если сам этот опыт — не отправная точка, а результат?

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

Именно здесь на помощь приходит Иммануил Кант — не как философ в парике, а как первый системный архитектор опыта.

Он бы не стал спрашивать: «Каков опыт пользователя?»
Он спросил: «Что именно делает возможным опыт?»

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

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

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

Прошло целых два года, как команда NSR Specification твердо пообещала добиться автоматизации экспертизы цифровых информационных моделей (ЦИМ) за счет создания машинопонимаемых представлений требований стандартов проектирования. На тот момент мы очень хотели регулярно рассказывать о промежуточных результатах, но слишком увлеклись разработкой. Ежедневно возникали новые и новые проблемы, в муках рождались способы их решения, в спешке писались задачи на разработку, когда заканчивались слова мы рисовали картинки, потом, дрожащими руками тестировали новый функционал, с азартом отлавливали баги, умело замаскированные под фичи... Каждый раз нам казалось, что осталось только дождаться свежего релиза, и все, мы победили. Оглядываясь назад, мне все чаще кажется, что мы были немного сумасшедшими, раз взялись за эту задачу. Но это, наверное, к лучшему. Если бы тогда, в 2023 году мы знали обо всех сложностях, с которыми нам предстоит столкнуться, то сегодня не смогли бы похвастаться работающим решением. Теперь то уж точно нам есть о чем рассказать: решение работает и уже обкатано на нескольких пилотных проектах.

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

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

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

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

Представьте, что у вас есть кнопка, которая запускает в работу не просто нейросеть, а целый аналитический отдел. Один AI-агент лезет в Google изучать тренды, второй — шпионить за конкурентами, третий — анализировать ваши внутренние данные, а четвертый, на основе всего этого, генерирует три готовые стратегии. Звучит как научная фантастика? А я расскажу, как собрал именно такую систему на принципах мультиагентных систем, с «боссом-оркестратором» и даже собственной базой знаний.

Погрузимся в мир, где AI — это не просто чат, а целая виртуальная команда.

Привет Хабр, меня зовут Алина, и я HR-lead компании SSP SOFT (мы занимаемся заказной разработкой). Написать пост про особенности найма сеньоров мне помог наш райтер Сергей, а на саму идею — сподвиг случайно встреченный на просторах интернета пресс-релиз из заглавной иллюстрации. Не буду останавливаться на названии этой компании, его легко загуглить по фразам из скрина. Важно другое — коллеги по отрасли написали про избыток сеньоров на рынке труда в 2Q/2025 г., что казалось немыслимым еще пару лет назад. А как принимают на работу сеньоров, если речь идет не о массовом наборе, а точечно, под конкретные проекты? Об этом я и хотела порассуждать в этом посте.

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

Теперь это значит только одно — оправданий больше нет. Отсидеться не получится. Не бойтесь, что ИИ убьет творчество. Бойтесь мира, в котором правила его использования и этику его применения напишут те, кто в творчестве ничего не понимает, пока вы стояли в стороне. Раньше можно было сказать “у меня нет возможности, чтобы воплотить идею”, теперь единственный честный ответ — “у меня нет идеи, достойной воплощения”.

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

Так обычно начинается повесть о созданном в рекордные сроки дашборде. А потом боль и унижение, и никто не хочет брать на себя ответственность, когда упал прод, потому что BI‑аналитик выгружал 90 миллионов строк join’ом без фильтра. А вашему бизнесу всё равно, кто виноват. Данные не пришли, отчёта нет, шеф злой.