#проектирование_взаимодействия — Public Fediverse posts

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

О чем стоит подумать на берегу, прежде чем отправить ваш корабль в новую интеграцию

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона. Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день. Эта статья появился на основе собственного опыта, а также консультирования коллег. Довольно часто я вижу, что поднимаются вопросы проектирования API, моделей данных, но при этом не решены концептуальные моменты, на которых строится вся логика взаимодействия и сам бизнес-процесс. Когда я решила оформить свои мысли в статью, поняла, что хочу использовать ассоциации: система – это корабль, а проектирование новой интеграции - это отправка его в путь по морям. Нельзя просто взять и направиться в сторону конечной точки. Сначала нужно изучить маршрут, понять, какие у корабля есть ограничения и как их учитывать, запастись спасательными кругами и обязательно подумать, как оповещать пассажиров о бедствии. Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу? 1. Определение ответственности вашей системы Перед проектированием новой интеграции нужно в первую очередь понять, какая у вас система, за что она является ответственной, как хранятся данные, как они передаются. И главное - определить, какая ответственность именно на вашей системе. Иначе может произойти рассинхрон данных, деление ответственности, повтор бизнес-логики, из-за чего данные в один миг могут оказаться ошибочными, и станет непонятно, где искать правду.

https://habr.com/ru/companies/megafon/articles/971070/

#интеграция_приложений #интеграция #системный_анализ #системное_мышление #асинхронность #синхронность #проектирование #проектирование_систем #проектирование_взаимодействия #проектирование_и_рефакторинг

Секреты создания эффективного REST API: гайд для системных аналитиков

Привет, Хабр! Меня зовут Дарья Борисова, я системный аналитик в ПСБ. Однажды я попробовала интеграции... и теперь они преследуют меня везде, как навязчивый мотив из песни. Пришлось изучать и внедрять разные подходы, а заодно накопить вагон и маленькую тележку лайфхаков. Сегодня я работаю с Системой быстрых платежей в ПСБ — и готова поделиться тем, что спасло нас в критичных ситуациях. Почти наверняка вы бывали в ситуациях, когда всё выпустили в прод, а сервер нагрузку не тянет. Или бизнес давит сроками, а времени на идеальные решения нет. Приходится подставлять костыли и ставить быстрые заплатки. Вопрос в том, могут ли они стать надежным решением? И какие компромиссы придется принять — об этом и поговорим. А точнее: об оптимизации REST API в бою: как снизить количество запросов без потери данных, где проводить расчеты (и чем это грозит), зачем стандартизировать ответы, как кешировать с умом и почему health-check — это не просто «жив/мертв».

https://habr.com/ru/companies/psb/articles/949246/

#rest #rest_api #restful_api #проектирование_систем #проектирование_взаимодействия #системный_анализ

Памятка по XSD

Самое главное стоит понимать, что XSD (XML Schema Definition) – это схема, то есть описание данных взаимодействия. Схемы бывают разные, например, наша XSD, которую обычно используют для описания структур в формате XML, или JSON-schema - для описания структур в формате JSON. Использование схем в контрактах API сейчас уже является стандартом де-факто, так как это удобно. Основные объекты, из которых состоит XSD-схема: - Элементы; - Типы; - Индикаторы порядка.

https://habr.com/ru/companies/sberbank/articles/876978/

#xsd #xml #json #схема #интеграция #интеграция_сервисов #интеграция_систем #проектирование_взаимодействия #api #микросервисы

Механика бесплатных уроков на ed-tech продукте. От гипотезы до результатов. Или как увеличить продажи онлайн-курсов

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

https://habr.com/ru/articles/879672/

#онлайнобразование #онлайнкурсы #продуктовый_дизайн #маркетинг #продвижение #конверсия_сайтов #проектирование_взаимодействия #продажи

Проектирование Информационных систем. Часть 5. Формализация потребностей заказчика

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

https://habr.com/ru/articles/915090/

#проектирование_систем #проектирование_по #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #проектирование_взаимодействия

Проектирование Информационных систем. Часть 4. Управление целями заинтересованных лиц

Одним из основных признаков системы, отличающим ее от #НЕСистемы, является подчиненность всей структуры некоторым целям. Проектная работа команды представляет собой тоже некую систему и, следовательно, должна «идти на поводу» у какой-то цели. Потому установив коммуникации между участниками проекта, начнем вместе с ними определять цели, которые каждое из заинтересованных лиц хочет достичь в результате создания нового продукта. Цель данной группы работ : определить основные ключевые цели, которых хотят достичь группы заинтересованных лиц, в результате участия в процессе производства Информационной системы. Поскольку мы постоянно оперируем очень сложными конструкциями и понятиями для эффективного управления ими, на протяжении всего курса мы будем использовать прием «Классифицирование» объектов анализа.

https://habr.com/ru/articles/914794/

#проектирование_систем #проектирование_по #проектирование_взаимодействия #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация

Проектирование Информационных систем. Часть 3. Инфраструктура (ландшафт) для организации проектной деятельности

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

https://habr.com/ru/articles/914296/

#проектирование_систем #проектирование_по #проектирование_взаимодействия #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация

Проектирование Информационных систем. Часть 2. Введение в процесс формирования требований

Для оптимизации хода освоения навыка формирования Требований к Информационной системе (далее - ИС), разберем сначала упрощенный процесс. Обсудим, как может происходить анализ системы и формирование требований к ней, используя прием реверс-инжиниринга. То есть, рассмотрим уже существующую систему и постараемся воспроизвести процесс формирования требований для ее создания Чаще всего процесс формализации требований к целевой системе включает 3 этапа:

https://habr.com/ru/articles/913592/

#проектирование_систем #проектирование_по #проектирование_взаимодействия #проектирование #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия #промышленная_автоматизация

Проектирование Информационных систем. Часть 1. Введение

При подготовке специалиста в области проектирования Информационных систем, важно учитывать конъектуру применения навыков в дальнейшем. Это может быть либо роль “Проектировщик” в каком-то из проектов, либо постоянная профессия “Проектировщик ИТ-продуктов”. Для кого предназначен курс? Для ИТ аналитиков: В курсе лекций, на примерах, Вы сможете глубже осознать принципы общения с заказчиком, при сборе и формализации требований. Освоить разные методы объяснения неопределенности доступным для большинства заинтересованных лиц способами, а также овладеть методикой построения конвейера по разработке спецификаций требований в ИТ проектах. Для ИТ разработчиков: Умение проектировать и с легкостью ориентироваться в моделях и требованиях к продукту предметной области, является важнейшим навыком зрелого программиста. Курс поможет структурировать знания в сфере выполнения проектных работ и эффективного использования их результата. Для ИТ менеджеров: Если у Вас случаются срывы сроков и бюджетов проекта, из-за отсутствия детального понимания контекста проекта, состава работ, требований к качеству и т.п., ознакомление с методикой позволит на самых ранних стадиях ИТ проекта с высокой точностью и глубокой детализацией определять объемы работ по созданию целевого продукта. Как следствие - разрабатывать реалистичные план-графики проекта, а также эффективно распределять ресурсы в нем. Для студентов и выпускников ВУЗов: Если вы получили специальность, связанную с ИТ, но не видите для себя перспектив на стезе программирования, попробуйте себя в роли ИТ аналитика. Освойте профессию, которая в ИТ проектах является центральной и выступает “мостиком” между заказчиком и остальной командой, реализующей проект.

https://habr.com/ru/articles/912914/

#проектирование_систем #проектирование_по #проектирование_взаимодействия #проектирование #анализ #анализ_данных #системный_анализ #системный_аналитик #системная_инженерия #системная_аналитика

Что я понял о жителях России, пока изучал гватемальцев. Опыт UX-исследования с другой стороны планеты

Привет! Меня зовут Данила Тарасов, я UX-исследователь в

https://habr.com/ru/companies/agima/articles/864184/

#uxисследования #проектирование_интерфейсов #проектирование_взаимодействия #зарубежный_опыт #зарубежные_рынки #зарубежные_клиенты

Красота требует жертв! Как увеличить ценность продукта с помощью дизайна

Заново Америку не открою, если утвержу, что красота требует жертв, в нашем случае — вложений. Всем доброго времени суток! Сегодня хочу затронуть значимую тему: как дизайн способен увеличить ценность продукта. Не буду углубляться в гипотетические размышления или пересказывать банальные книги; остановлюсь на конкретном примере. Меня зовут Армине, и я — менеджер продукта в компании ВИАР ИТ. Веду отдел R&D и занимаюсь созданием экосистемы для цифровизации архивов. В нашем мире, где каждое мгновение наполнено визуальными образами, дизайн становится не просто оформлением, а важнейшим инструментом, способствующим трансформации и повышению ценности. Я уверена, что когда эстетика ведет за собой функциональность, мудрость технологии обретает новое звучание. Убедитесь, что вложения в дизайн — это не просто расходы, а инвестиции в будущее вашего продукта, которые откроют двери к новым вершинам успеха.

https://habr.com/ru/articles/859024/

#ценность_продукта #менеджмент_продукта #аналитика #бизнесанализ #проектирование #проектирование_интерфейсов #проектирование_взаимодействия #дизайн #дизайн_интерфейсов