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

В каждой компании независимо от ее размера и вида деятельности проводятся совещания. Многие сотрудники, да и руководители разных уровней считают, что совещания отнимают много времени и зачастую зримого результата от них не наблюдается. Тем не менее они регулярно проводятся. Проведение совещания — это прихоть руководителя компании или что‑то другое, что необходимо для деятельности компании?

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

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

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

Привет, Хабр! Меня зовут Николай Бушков, я работаю архитектором в команде Engineering Productivity R&D в Т-Банке (группа «Т-Технологии»). В начале лета я выступал на конференции MTS True Tech Day c докладом «Не эксперимент, а стратегия: путь к системному использованию AI в SDLC». А сейчас хочу поделиться текстовой версией описания сценариев использования искусственного интеллекта (ИИ) в программной инженерии, которые реализуются у нас в компании. Уверен, наш опыт будет полезен многим для генерации и фильтрации идей применения ИИ, а также сравнения их с положением дел в ваших рабочих процессах. В конце статьи кратко сформулирую наше видение дальнейшего развития и приглашу поучаствовать в  исследовании ИИ в инженерной культуре России.

Вечные переделки и продукты, не решающие реальные проблемы? Возможно, вашей команде не хватает фазы Discovery.

Из этой статьи вы узнаете, как внедрить фреймворк, который делит работу на две четкие стадии: Исследование (Discovery) и Реализация (Delivery).

На практическом примере разберем:

- Как провести глубинное исследование проблемы до написания первой строчки кода.
- Что входит в процессы бизнес- и системного анализа на каждом этапе.
- Шаги внедрения фреймворка на вашем проекте.

Перестаньте тушить пожары и начните создавать востребованные продукты.

Business Process Model and Notation (BPMN) — это стандартизированное графическое представление, предназначенное для облегчения визуализации, понимания и взаимодействия сложных бизнес-процессов. Этот метод предоставляет целостную структуру, обеспечивающую единообразие описания между различными участниками, эффективно устраняя разрыв между технической и нетехнической аудиториями. BPMN использует набор стандартизированных символов, позволяющих компаниям системно описывать свои операционные потоки. Такая наглядность особенно важна в средах, где критичны оптимизация процессов и соблюдение регламентов, — она дает ясное представление о том, как действия, события и точки принятия решений взаимосвязаны внутри процесса.

С другой стороны, нестандартные инструменты автоматизации, такие как платформа n8n, предлагают иной подход к автоматизации рабочих процессов. В отличие от BPMN, который придерживается формальной нотации, n8n представляет собой low-code среду, ориентированную на гибкость и индивидуальную настройку. Подобные инструменты позволяют создавать сценарии автоматизации, соединяя различные приложения и сервисы без необходимости глубоких знаний в программировании. Такие среды особенно привлекательны для гибких рабочих процессов, где часто происходят итеративные изменения и требуется интеграция со множеством систем. Нестандартные инструменты нередко удовлетворяют уникальные бизнес-потребности, которые стандартизированные методологии, такие как BPMN, могут охватывать не полностью, предлагая тем самым альтернативное решение для оркестрации процессов.

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

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

Представьте, что вы покупаете мотоцикл. Чего вы от него ожидаете? Чтобы он мог разгоняться до 180км/час и при этом не разваливался? Чтобы к нему можно было прикрепить коляску? И не забудем про систему безопасности.

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

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

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

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

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

Как аналитику превратить расшифровку интервью в полный пакет документации за 15 минут вместо 5 часов. С примерами промтов и результатами.

В рамках проекта проведено сопоставление российского инженерного ПО Engee и иностранного аналога MATLAB/Simulink для решения задач цифровой обработки сигналов и моделирования гидропривода электропогрузчика ЭП2020. Испытания подтвердили практическую зрелость Engee и её готовность к использованию в инженерных подразделениях ПАО «МЗИК».

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

Техническая архитектура предприятия (ETA - Enterprise Technical Architecture) – это совокупность программно-аппаратных средств, методов и стандартов, поддерживающих эффективное функционирование приложений, и обеспечивающих стабильность, масштабируемость, безопасность.

С другой стороны, можно констатировать, что основное предназначение технологической(технической) архитектуры – это обеспечение надежных ИТ-сервисов(услуг), предоставляемых в рамках всего предприятия в целом и координируемых централизованно ИТ службой.

«Ну ты же компьютерщик!» — многим из ИТ-сферы знакома эта фраза из прошлого. Ей обосновывали, почему именно вы должны сделать почти всё: от настройки принтера до разработки и тестирования систем.

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

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

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

Небольшое вступление

UX в благотворительности часто недооценивают. Кажется, что если тексты добрые, фотографии вызывают эмоцию и видна боль героев, то этого достаточно. Эмоция действительно может подтолкнуть к действию: человек может перевести 100 рублей на импульсе или на эмоции жалости грусти и прочего. Но основная цель UX , за ручку вести клиента, строить понятный путь, который шаг за шагом ведёт человека от намерения помочь к реальному действию. Запоминаем => ведём от намеренья к четкому действию и говорим об этом прямо!

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

Методика Сигаевой: CX→UX→UI Pipeline, помогает выстроить последовательный процесс работы над диджитал продуктом. CX — даёт понимание мотиваций, UX — логику взаимодействия, UI — визуального усиления. Вместе они формируют продукт, который отвечает ожиданиям, укрепляет лояльность и поддерживает рост бизнеса.

Хороший дизайн — это не только красиво. Это логика, эмпатия, исследование и внимание к деталям. Особенно к деталям, которые важны пользователю.

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

Пример юзкейса, который точно прочитают разработчики!

Хабр, привет! Я Ира, бизнес-аналитик в онлайн-кинотеатре Okko.

На работе каждый день я описываю Use Case. Эта техника помогает увидеть путь пользователя от А до Я и не забыть про корнер-кейсы.

За 6 лет и 4 места работы я попробовала разные форматы и шаблоны описания юзкейсов. И недавно пообещала написать статью с примерами и картинками.

Привет! Меня зовут Артемий, я инженер в команде Processing и веду фичатрек по развитию FlinkSQL в Авито. Сегодня я расскажу про инструмент, который мы развиваем в Avito — FlinkSQL. Он использует потоковые данные для аналитики в реальном времени: метрики, временные срезы, A/B-расчеты, поиск аномалий. Все это на привычном SQL, чтобы команда видела картину и могла действовать сразу.

Правила игры поменялись: атомарный уровень процессов - ключевой элемент эффективной ИИ-трансформации

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

Именно об этом и стоит задуматься.

Эта статья для тех, кто проектирует процессы в BPMN и работает в Camunda Modeler: узнаем, как «оживлять» диаграммы с помощью Token Simulation, находить логические ошибки и недостижимые ветки. По дороге аккуратно разберём базовые понятия — экземпляр процесса и токен — чтобы одинаково понимать, что именно показывает симуляция и где в модели зашиты риски.

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

Результат довольно предсказуем: продукты, которые прекрасны на бумаге, не находят отклика у аудитории.

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

Хороший системный дизайн редко выглядит эффектно. В нём нет модных паттернов, десятков сервисов и Kafka на каждый чих. Он скучен — и именно поэтому работает. В этой статье автор рассуждает о том, почему простота — не наивность, а зрелость инженерного мышления; как состояние становится главным врагом стабильности; и почему настоящая архитектура рождается не из гениальных трюков, а из понимания границ и закономерностей сложных систем.

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

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