Нам в Systems.Education нужен part-time CTO/CIO

сейчас мы внедряем ИИ в наши курсы, хотим предлагать ученикам использовать не только внешние готовые SaaS, но и уметь ставить и настраивать локальные-облачно-доверенные LLM

для этих целей выбираем тариф-хостинг сервера, дальше делаем что-то вроде Лаборатории по применению ИИ для анализа и проектирования ИТ-систем

также во многих курсах постоянно нужны разные СУБД и middleware ПО, организация учебных сред для разработки-тестирования, хочется это всё нормально организовать и менеджерить

у нас есть парт-тайм технический администратор вышедший из бухгалтеров-аналитиков и есть тимлиды аналитиков с серьёзным опытом в бэкенде, но хочется чтобы такими вопросами занимался выделенный технический менеджер (не я)

итого, что делать:
— анализировать запросы экспертов и преподавателей на инфраструктурные сервисы и ПО для применения в обучении и прикладных исследованиях
— выбирать подходящий хостинг(И?)
— организовывать развёртывание необходимого ПО
— организовывать администрирование этого ПО

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

денег немного, тысяч 40-50, но и загрузки будет пропорционально, часов 4-5 в неделю

если у вас есть опыт техдиректора/CTO и вам интересно то, что мы делаем, пишите плс мне в личку @beskov

Недавно в этом посте рассказали про No-code и low-code интеграции и различные сценарии их использования. Но важно понимать, что no-code ≠ универсальный подход. За удобство приходится платить рядом ограничений.

🚨 О некоторых из них хотим рассказать сегодня:

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

— Масштаб и нагрузка: Когда речь о нескольких сотнях записей в день – no-code справится отлично. Но если нужно обработать миллион транзакций или обеспечивать задержки в миллисекундах, могут возникнуть проблемы с производительностью. Типичная архитектура no-code сервисов — облачная и мультиарендная, рассчитанная на усреднённые кейсы. Интенсивные нагрузки могут либо сильно стоить (тарифы часто зависят от количества операций), либо вообще выйти за пределы поддерживаемого. Кроме того, некоторые облачные интеграторы работают не в режиме реального времени, а с небольшими задержками. Например, у бесплатного тарифа Zapier задачи выполняются раз в 15 минут, что неприемлемо для ряда сценариев, требующих мгновенного отклик.

— Скрытая сложность: Фраза «без кода» не означает, что интеграцию может сделать кто угодно без подготовки. Порог входа ниже, чем у классического программирования, но разобраться всё же нужно. Новичку придётся понять логику работы переменных, условий, форматов данных, иначе даже с визуальным интерфейсом можно запутаться. Например, чтобы связать две системы, надо чётко представлять, какие данные на каком шаге передаются, в каком формате (JSON, XML, CSV и т.д.), как обработать ошибки. Без базовых знаний о тех же API и вебхуках возможно столкнуться с трудностями.

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

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

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

Регистрация

#интеграции@systems_education #REST@systems_education #брокеры@systems_education #Kafka@systems_education #SOAP@systems_education #XML@systems_education

Проверим, насколько хорошо вы знаете нотацию BPMN?

Мы подготовили диаграмму, НО на ней есть несколько ошибок. Каких? Это вам предстоит понять самостоятельно. Через 3 дня мы выложим разбор этого кейса с комментариями от эксперта.

🖋Немного бэкграунда — описание кейса, по которому построена диаграмма:

Процесс записи пациента на прием администратором

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

Если пациент обращается повторно спустя 6 месяцев и более, то из этого перечня документов он обязан заполнить при визите анкету анамнеза и согласие на обработку персональных данных.

Когда наступает время приема и пациент приходит в клинику, администратор обязан его идентифицировать. Для этого пациент должен предъявить паспорт. Если этого не сделать, то клиника вправе отказать в оказании услуг.

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

Если пациент не явился на прием по предварительной записи, то фиксируется факт отсутствия пациента на приеме.

Если пациент пришел и все документы готовы, то документы передаются ассистенту врача, а пациент ожидает начала приема.

Процесс завершен.

Будем ждать ваше мнение в комментариях, какие ошибки и неточности допущены в нашей диаграмме! ⬇️

Если вы не смогли без труда найти тут хотя бы 5 ошибок, приглашаем вас на воркшоп «BPMN для людей: основы самой популярной нотации для описания бизнес-процессов», на котором вы познакомитесь с принципами построения BPMN-диаграмм и на практике освоить применение основных элементов её алфавита.
Регистрация

#воркшоп@systems_education

User Story Map: как карта пользовательских историй помогает в создании и развитии IT-продукта

🤔 Что это такое?
User Story Mapping (USM, карта пользовательских историй) – техника проектирования продукта на основе пользовательского пути, а также формирования общего понимания продукта у команды. Проще говоря, вы раскладываете работу над продуктом в виде истории от лица пользователя. На большой доске описывается последовательность действий пользователя и под каждым шагом — конкретные User Story. В итоге получается карта, которая показывает весь пользовательский путь в продукте: видно, на каких этапах ему удобно, а где есть пробелы, какие функции действительно важны, а какие можно отложить.

👩‍💻 Как это помогает команде?
Карта историй даёт целостное представление о продукте и помогает упорядочивать бэклог. Вместо разрозненных задач команда видит «большую картину».

Вот ключевые преимущества использования User Story Map:
— Целостное видение продукта. Все участники видят сценарий взаимодействия пользователя с продуктом от начала до конца. Это помогает лучше понять контекст каждой функции и вовремя убрать дубликаты или лишнее.
— Приоритизация задач. Легче определить, что действительно необходимо в первую очередь, а что может подождать. Видя карту, команда фокусируется на важных функциях, а второстепенные опции оставляет на потом.
— Проектирование MVP. Карта явно показывает минимальный набор пользовательских историй необходимый для первого релиза. Достаточно провести горизонтальную черту, чтобы отделить обязательные возможности от тех, что могут войти в последующие итерации.
— Выравнивание контекста. Карта помогает наладить общий язык между бизнесом, аналитиками, дизайнерами и разработчиками. Команда обсуждает как пользователь взаимодействует с продуктом и какие результаты нужно доставить первыми.

А вот так выглядит готовая карта пользовательских историй ⬆️

На воркшопе «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку» вы построите User Story Map и поймёте, как использовать её для выявления MVP, планирования релизов и выстраивания общего понимания продукта с командой и бизнесом.

Регистрация

#воркшоп@systems_education #популярные_посты

Онлайн-курс «Интеграция систем. Разработка требований и основы проектирования»

🔹Когда?
1 поток: 9 Июня — 20 Июня
2 поток: 12 Июля — 27 Июля

🔹Цель курса — разобраться в теме интеграций и научиться проектировать взаимодействие ИТ-систем

🔹Этот курс для:
— Системных аналитиков, которые хотят повысить свой уровень и зарплату с Junior + на Middle
— IT-специалистов, которые хотят разобраться в интеграциях
— Бизнес-аналитиков, которые хотят стать системными и для этого освоить интеграцию
— Руководителей отдела анализа и проектирования, которым нужно подтянуть подчинённых по интеграции
— HR, T&D, Тимлидов, которым нужно выбрать курс по запросу внутри компании и обучить на нём сотрудников

🔹На курсе вы:
— Изучите технологии интеграции
— Спроектируете рабочую интеграцию, которую можно будет использовать в качестве образца в работе или положить в Портфолио
— Научитесь документировать межсистемное взаимодействие

Регистрация

#интеграции@systems_education #REST@systems_education #брокеры@systems_education #Kafka@systems_education #SOAP@systems_education #XML@systems_education

Путаница вокруг термина REST: почему у каждого он свой

Сегодня «REST» стало почти синонимом API, передающего JSON через HTTP. Но на деле всё не так просто. На практике большинство API, которые называют себя RESTful, находятся на 0 или 1 уровне зрелости по модели Ричардсона. Это не ошибка, но это стоит осознавать.

0 уровень: Всё в одном мешке
— Один URL /api/command
— Всё через POST
— HTTP служит лишь для транспорта JSON

1 уровень: «Ресурсы появились, но глаголы игнорируют»
— Отдельные URL /users, /orders
— Но снова всё POST

2 уровень: «Смысл HTTP»
— GET, POST, PUT, DELETE по назначению
— Корректные статусы: 404, 201
— Чёткая иерархия URL /orders/{id}

3 уровень: HATEOAS
— В ответах помимо данных приходят ссылки на доступные действия
— Клиент может сам обнаруживать возможности API по ссылкам

Почему важно избегать путаницы?
Представьте, что ваша команда разрабатывает интеграцию с внешним API. В техническом задании написано: «REST API для работы с заказами». Вы ожидаете, что сможете отправлять запросы GET /orders/{id}, обновлять PUT /orders/{id}, удалять DELETE /orders/{id}.

Но на практике оказывается: всё происходит через один POST /api/command с разными командами в теле запроса.

На воркшопе «Проектирование интеграции с REST API» вы под руководством эксперта проанализируете процесс взаимодействия систем, потоки данных, опишете REST-like API и поймёте, как аналитик решает интеграционные задачи.
Регистрация

#воркшоп@systems_education #интеграция@systems_education #RESTAPI@systems_education