Системный сдвиг @systemswing Channel on Telegram

Системный сдвиг

@systemswing


Юрий Куприянов. EdTech, системный анализ, архитектура, управление продуктом и ChatGPT.

Программный директор WAW, член ПК Flow, ЛАФ.

Контакты по рекламе и заявки на посты: t.me/YuryKupriyanov

Курсы для системных аналитиков: https://systems.education

Системный сдвиг (Russian)

Системный сдвиг - это Telegram канал, созданный специально для тех, кто интересуется EdTech, системным анализом, архитектурой, управлением продуктом и ChatGPT. Здесь вы найдете полезные материалы, статьи, обзоры и многое другое от эксперта в области IT - Юрия Куприянова.

Юрий Куприянов - это программный директор WAW, член ПК Flow и ЛАФ. Он делится своим опытом и знаниями с подписчиками, помогая им развиваться в выбранных областях.

Если вы заинтересованы в рекламе на канале или хотите разместить пост, вы можете связаться по ссылке t.me/YuryKupriyanov.

Также на канале есть информация о курсах для системных аналитиков, которые могут помочь им улучшить свои навыки и стать успешнее в своей профессии. Посетите https://systems.education, чтобы узнать больше. Присоединяйтесь к каналу Системный сдвиг и начните свой путь к профессиональному росту уже сегодня!

Системный сдвиг

07 Dec, 14:40


Учат ли системному анализу в школе? Оказывается, да! В 10-11 классах. Есть вот целый учебник.

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

Как думаете, поможет это в становлении системного аналитика?

Не знаю, правда, есть ли школы, в которых такой предмет реально преподают.

Системный сдвиг

04 Dec, 13:22


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

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

Мне кажется, в таком подходе есть большая доля идей позитивизма, даже логического позитивизма. Его адепты верили, что любое знание можно вывести и доказать либо путем эмпирических наблюдений (то есть, проверить на опыте), либо из логических правил и преобразований. Это идеи 20-30-х годов XX века, т.н. "Венский кружок". Дальнейшие разработки, в том числе членов кружка — Гёделя, например — привели к формальным доказательствам того, что истинность (и даже непротиворечивость) сложных систем доказать невозможно. Дальше больше — в квантовой физике обнаружился принцип неопределенности, в термодинамике — хаотические системы, в информатике — проблема остановки (принципиальная невозможность доказать — зациклится программа или выдаст ответ. в частности, это означает невозможность доказать наличие решений у некоторых уравнений).

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

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

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

Точнее, разработка прошла все этапы:

метафизику, то есть разговор об очень абстрактных понятиях, не имеющих строгого содержания ("требование", "решение", "проект", "система", "данные");

позитивизм (мы можем всё определить, логически выразить и формально доказать);

постпозитивизм в виде фальсифицируемости (не можем доказать правильность программы, но хотя бы можем сказать, что те функции на тех данных, что мы проверили, работают корректно — тестирование и BDD), конструктивизма (не существует абсолютной истины, мы конструируем подходящий нам результат в процессе совместной деятельности, постоянно проверяя результат опытом; важна структура этой деятельности — agile), и неопрагматизма (нечто, что мы называем, имеет смысл, пока это несёт для нас пользу в определенном контексте; нет описания реальности "вообще", есть описание под конкретную задачу — DDD).

Окончательно добивает остатки позитивизма современный подход к ИИ: оказывается, при помощи "грубой силы" и наращивания числа связей в сети можно гораздо лучше решать практические задачи, чем через построение абсолютной исчерпывающей модели (см. очень показательную историю последних лет компании Abbyy и их проекта Compreno — чем она закончилась, я думаю, вы все слышали).

Наглядно видно это и в истории REST, например — тот же HATEOAS очень оптимистично выглядит в теории, а на практике почти не применяется.

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

Системный сдвиг

03 Dec, 11:52


На тренинге по интеграциям возник вопрос: что куда класть в http-запросе (в REST API). Решил разложить по полочкам (pun intended).

Полочек в http четыре штуки:

➡️ путьpath или route, эндпоинт, он же на жаргоне яндексоидов "ручка" (то, что после адреса сервера, за символом '/' — иерархия типов ресурсов и их идентификаторов. По аналогии с путем к файлу на диске, в пути говорят о вложенности — как будто каждый следующий уровень в цепочке '/' вложен в предыдущий. То есть, /orders/123456 — это заказ с id=123456, а /orders/123456/items — это перечень товаров в этом заказе, товары "вложены" в заказ)

➡️ параметры запроса, или query (то, что в конце URL, за символом '?' — перечисление параметров в формате имя=значение, разделенных &.)

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

➡️ заголовки запроса — http headers (передаются после строки запроса в виде пар "имя":"значение"). Обычно не сохраняются в логах, но иногда могут (можно настроить частичное сохранение — например, значение cookie или токенов точно не нужно сохранять, т.к. их можно использовать для выдачи себя за другого пользователя).

➡️ тело запроса — http body (тут понятно, это сами содержательные данные, которые мы передаем).

Есть из чего выбрать! Понятно, что идентификатор запрашиваемого ресурса мы обычно размещаем в пути, а содержимое помещаем в теле запроса (если это POST/PUT/PATCH). А если мы хотим указать связь нашего ресурса с другим? Например, связь заказов с клиентом? Тут уже могут быть два варианта: nested resources (вложенные ресурсы: /clients/689697/orders) или flat (плоские: /orders?client=689697, в API только пути с названиями ресурсов).

А если мы хотим указать версию API, у нас ещё больше вариантов: путь (/api/v1/orders), параметры (/api/orders?version=1) и заголовки (через кастомный заголовок: X-API-Version: 1, или через стандартный заголовок Accept: application/json; version=1 ). Я видел даже парочку случаев, когда версия передавалась в теле(!), даже для GET (хотя вообще сервер должен игнорировать тело GET-запроса).

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

Вопросы эти очень дискуссионные, я для себя выработал такие правила:

Путь — это указатель на коллекцию ресурсов или конкретный экземпляр. Лучше не тянуть туда ни версионность, ни фильтры, ни метаданные. Идентификатор в пути может быть только один (то есть, если мы описываем вложенные ресурсы, там может быть идентификатор на конце, или вторым от конца. Таким образом, вложенность будет только двухуровневая, и не будет диких URL типа /cities/77/pickpoints/35/clients/689697/orders/123456/items)

Параметры запроса — это ограничения на выдаваемую коллекцию ресурсов или набор полей одного ресурса. Поэтому тут будет простой поиск, фильтрация, набор полей в выдаче, пагинация, сортировка. То есть, это метаданные, относящиеся к ресурсу. Если мы хотим получить заказы клиента, доставленные в пункт выдачи с id=35, это будет выражено так: clients/689697/orders?city=77&pickpoint=35 (мы ограничиваем спискок заказов).

Заголовки — это метаданные запроса (а не ресурса). Это всё, что касается форматов выдачи (я видел API, в которых формат был зашит в путь: /api/xml/orders и /api/json/orders — не делайте так!), версии API и версии ресурса, кэша, параметров соединения, id запроса и т.п. Дискуссионный вопрос про пагинацию: её можно поместить и в заголовки тоже, как и ответную информацию (текущая страница, общее число страниц, число записей всего, следующая страница, предыдущая страница). Часто метаинформацию про пагинацию помещают в тело ответа, но, как по мне, это перегружает структуру ответа и может сделать её разнотипной для разных ответов — будьте с этим осторожнее.

Системный сдвиг

03 Dec, 11:52


Тело — непосредственно сам ресурс или коллекция ресурсов. Метаданные о ресурсе лучше отдать в заголовках ответа, хотя я вижу часто подходы, когда метаданные отдают в одном json'е с содержательными данными, как например, в спецификации JSON:API. Там у них вообще в ответе сразу и данные (data), и ошибки (errors), и метаданные (meta), и ссылки (links), и вложенные объекты (included):
{
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON:API paints my bikeshed!"
},
"links": {
"self": "http://example.com/articles/1"
},
"relationships": {
"author": {
"links": {
"self": "http://example.com/articles/1/relationships/author",
"related": "http://example.com/articles/1/author"
},
"data": { "type": "people", "id": "9" }
},
"comments": {
"links": {
"self": "http://example.com/articles/1/relationships/comments",
"related": "http://example.com/articles/1/comments"
},
"data": [
{ "type": "comments", "id": "5" },
{ "type": "comments", "id": "12" }
]
}
}
}],
"included": [{
"type": "people",
"id": "9",
"attributes": {
"firstName": "Dan",
"lastName": "Gebhardt",
"twitter": "dgeb"
},
"links": {
"self": "http://example.com/people/9"
}
}, {
"type": "comments",
"id": "5",
"attributes": {
"body": "First!"
},
"relationships": {
"author": {
"data": { "type": "people", "id": "2" }
}
},
"links": {
"self": "http://example.com/comments/5"
}
}, {
"type": "comments",
"id": "12",
"attributes": {
"body": "I like XML better"
},
"relationships": {
"author": {
"data": { "type": "people", "id": "9" }
}
},
"links": {
"self": "http://example.com/comments/12"
}
}]
}


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

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

Let's discuss!

Системный сдвиг

29 Nov, 13:45


А написать я хотел про синхронные и асинхронные взаимодействия, по следам предыдущего (теперь уже пред-предыдущего) поста.

Андрей Бураков справедливо заметил, что WebSockets-то асинхронный, а я его в синхронные записал, вот позор.

Но логика у меня в этот момент была вот какая: если нам нужен быстрый отклик — мы берем паттерн "запрос-ответ", то есть RPC и REST. Но если нам нужен ещё более быстрый отклик — мы берём WebSockets, где взаимодействие асинхронное. Ну или используем Long Polling, WebHooks или MQTT — все они асинхронные, и все применяются, когда нам нужно очень быстро отреагировать на событие.

Следующий шаг в этом же направлении, но на другом уровне, сделал Google со своим протоколом QUIC, заменяющим TCP. Потому что установка соединения TCP — слишком дорогая и долгая операция, а делать её приходится почти при каждом запросе (да, есть keep-alive, тогда соединения будут держаться дольше, но у этого есть и обратная сторона — именно это соединение нужно использовать, пока оно живо. Иначе у вас будет много живых соединений и, соответственно, много занятых портов).

Протокол QUIC в основном ориентирован на веб-браузеры, а веб-браузеры имеют обыкновение запрашивать много разных ресурсов одновременно. Хотя каждый запрос сам по себе синхронный, выполняются они в java script'е асинхронно, через промисы и async/await, и про это есть много шуток у фронтендеров — очень больная тема, сложно понять.

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

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

Получается, в этом в целом асинхронном мире есть довольно узкая прослойка — место для условно синхронных коммуникаций, где-то в районе от 100 миллисекунд до секунды, где они могут работать. Именно здесь работают все пользовательские интерфейсы, и именно в этом временном промежутке вырос весь Web на базе REST API.

По случайному совпадению, этот диапазон как раз соответствует человеческому восприятию "мгновенной реакции". Она как раз примерно от 100-120 мс у гонщиков F1, пилотов истребителей и топовых кибер-спортсменов, до 250-300 мс — у обычных людей. Можете проверить себя: https://humanbenchmark.com/tests/reactiontime , у меня как раз 253 получилось в среднем. Хорошее пятничное развлечение :)

Так случайно совпало, что типичные http-запросы выполняются как раз примерно за 300-900 мс (передача данных через websocket — 200 мс). Действий быстрее 13 мс человек вообще не воспринимает (скорость обмена в 5G-сетях — 15 мс, это быстро). Аукцион рекламодателей за рекламное место на веб-странице — RTB — занимает 100-200 мс. В высокочастотном трейдинге решение о сделке принимается за микросекунды. На таких скоростях важным становится расстояние между серверами, поэтому их ставят прямо в датацентре биржи или вообще втыкают прямо в PCI-шину биржевого сервера. Вызов обработчика прерываний вообще в тактах процессора считается — это наносекунды для современных компьютеров.

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

Системный сдвиг

27 Nov, 14:38


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

Краткое содержание: с середины октября российские сервера точного времени (NTP) второго уровня, поддерживаемые сообществом (то есть, люди по собственной инициативе у себя их развернули на роутерах, на своих серверах), испытали практически DDoS-атаку — трафик на них катастрофически вырос, и люди стали их отключать. Из 140 серверов осталось 5. Оказалось, этот трафик посылают умные колонки от Яндекса, в которые с очередным обновлением прошивки приехал баг, заставляющий их слать запросы на синхронизацию времени каждые 5 секунд.

Обнаружил это один из участников пула NTP, и опубликовал 24 ноября статью на Хабре, чтобы привлечь внимание к проблеме. Сейчас Яндекс баг уже признал и исправил, и пообещал установить собственные сервера точного времени, а не полагаться на общественные.

Вопрос методический: чья эта область ответственности?

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

Яндексу в колонке точное время нужно для будильников, таймеров и календаря, а также для некоторых технических вещей.

И когда это устройство было экспериментальным — никто особенно не задумывался над серьезностью такого взаимодействия. Ну, сели на общий pool.ntp.org, который используется всеми линуксами и большинством устройств. Оно работает, и ладно.

Когда колонки стали продавать миллионами в год, это уже совсем другой уровень ответственности (ещё один вопрос из курса по интеграциям — с какой скоростью вы собираетесь масштабироваться?). Один непротестированный апдейт — и вся инфраструктура легла.

На мой взгляд, здесь есть три момента, которые относятся к задачам системного аналитика:

1. Анализ эффектов при масштабировании (рост нагрузки на смежные системы, превышение лимитов внешних API);
2. Анализ условий использования внешних систем (у проекта NTPPool есть гайдлайны для вендоров оборудования, им нужно следовать);
3. Контроль и учет всех входов и выходов системы (Сергей Нужненко рассказывал об этом упражнении на Flow).

Системный сдвиг

25 Nov, 10:11


Часто возникает вопрос — какой выбрать режим интеграции — синхронный или асинхронный.

Особенно если у вас в инфраструктуре есть и то, и то. То есть, вы приходите к владельцу/архитектору системы, с которой хотите интегрироваться, а он говорит: у нас и REST API есть, и к Кафке мы подключены, нам в принципе всё равно, что для тебя сделать, а тебе-то как удобнее? То есть, перекладывает выбор на аналитика. А как аналитику выбрать? Ну, провести анализ, а что анализировать-то?

Тем более, что вариантов у вас три (да ещё с подвариантами):
1. Синхронная интеграция (запрос-ответ, выполняемый немедленно)
— в пределе — постоянный двунаправленный канал (websockets)
2. Асинхронная (и запрос, и ответ асинхронные; по сути, двунаправленный паттерн "публикатор/подписчик", обычно это топик для запросов и топик для ответов)
3. Смешанная или гибридная (обычно синхронный запрос и асинхронный ответ), причем тут два варианта:
— ответ через очередь сообщений;
— ответ через прямое обращение (webhook, подписки в graphql / grpc)

Итого, на что смотрим и что анализируем:

1. Требования бизнес-процесса: нужен ли нам по сути деятельности немедленный ответ? (скорость ответа — десятки и сотни миллисекунд). То есть, онлайн-игры, чаты, совместное редактирование документов, управление видеоконференциями — это вебсокеты или что-то похожее. Онлайн-платежи, переводы, запрос баланса, аренда самоката, открытие автомобиля каршеринга, перевод, заполнение форм и вообще действия в интерфейсе — это синхронный запрос-ответ, REST API и RPC в любых видах.

2. Если время выполнения запроса может превышать секунды (граница тут тонкая, как видите) — можно думать про асинхронное взаимодействие. Нужны уточняющие вопросы:
— Нужно ли сохранять все запросы? Будем ли мы перепосылать каждый запрос, если его не смогли обработать? (насколько ценна информация и насколько быстро она меняется? Важен ли нам конкретный экземпляр запроса? Заказ в магазине, вызов такси и запрос на создание документа точно будем перепосылать. А вот запрос остатков товара, оповещение о текущем положении вызванной машины, подтверждающий код — можем и пропустить, сохранять его не нужно — ответ именно на этот запрос нам не актуален, мы другой отправим. То есть, если промежуточное хранение не нужно — выбираем синхронную связь с возможными потерями, если нужно сохранять сообщение или обеспечить точный порядок сообщенийасинхронную очередь.

— Нагрузка, которую мы обеспечим взаимодействующей системе: сможет ли её API выдержать наши запросы? Какой у системы RPS и насколько часто мы к ней собираемся обращаться? Возможно, для разгрузки системы перед ней нужно поставить очередь.

— Как долго обрабатывается наш запрос? Если смежная система будет обрабатывать секунды и минуты — это точно асинхрон или гибрид: мы можем отдать команду на старт процесса синхронно (через REST API), а получить ответ асинхронно: через webhook, если нам ответ не очень важен, или через очередь, если ответ для нас важен, или ответов может быть несколько и важна их очередность.

— Мы обращаемся к одной системе, или ко многим сразу? Например, у нас много систем, в которых учитываются разные банковские или страховые продукты для одного клиента, и мы хотим опросить все системы. Можем на своей стороне делать по запросу к каждой системе, а можем кинуть один запрос в очередь запросов, и пусть все системы оттуда его считают и отвечают в своем темпе. Если число систем неизменно, а отвечают они быстро — это API Gateway. Если системы по-разному нагружены, и число их может расти — лучше очередь.

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

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

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

Системный сдвиг

24 Nov, 14:13


Закончился очередной поток очного курса по проектированию интеграций, а я в очередной раз задумался про обучение взрослых. И кстати нашел тезисы по андрагогике Малколма Ноулза (Malcolm Knowles, отличная фамилия для ученого, занимающегося образованием!)

Он много занимался обучением взрослых ещё в середине XX века, и сформулировал следующие принципы:

1. Потребность в знаниях. Взрослым нужно четко понимать — зачем они учатся.

2. Опыт. Обучение взрослых должно быть основано на опыте (включая ошибки).

3. Самостоятельность (self-concept). Взрослые сами отвечают за решения в отношении обучения, в том числе в планирование и оценку качества преподавания.

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

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

6. Мотивация. Мотивация взрослых скорее внутренняя (улучшение жизни, рост уверенности, удовлетворенность работой), чем внешняя (оценки, учебные достижения).

Эти идеи совпадают с тем, как у нас в Systems.Education устроено обучение (мы пришли у этому на собственном опыте, без теории) — работа над кейсом в течение курса, никаких оценок, обучение выстроено вокруг получения реального опыта, применять можно сразу, есть возможность углубить или пропустить какую-то тему, если группе это нужно (или не нужно).

Однако многие онлайн-курсы сделаны по прямо противоположным принципам! Без объяснения, зачем вам нужно это обучение (это скорее внешний фактор, когда вас компания посылает на обучение, не объясняя, зачем). С минимальным опытом (пройдите тесты, вот и весь опыт). Без вариантов влияния на планирование, содержание и темп обучения (а тем более — без оценки качества преподавания). С кучей теории, которую непонятно, как применить. С занятиями, выстроенными вокруг контента (это вообще не обучение, это ознакомление). И с мотивацией в виде оценок и геймификации.

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

Системный сдвиг

20 Nov, 16:22


Любопытные результаты! Половина аудитории вообще не слышала про MQTT, четверть — слышала, и только 7% (29 человек) используют в работе.

Это при том, что MQTT — один из самых ранних протоколов, реализующих паттерн "Публикация-подписка", ещё 1999 года. AMQP, на котором построен RabbitMQ и прочие брокеры с буквами MQ в названии — предложен в 2003, а Kafka вообще в 2011.

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

Интересный набор статей про MQTT есть на сайте Kai Waehner. У него там интересные разборы архитектур систем стриминга данных, причем он часто сочетает MQTT с Kafka (MQTT выступает интерфейсом для сбора данных, а Kafka — для хранения и дистрибуции, как например здесь.

В общем, если в вашем проекте появляются такие слова, как IoT, сбор данных с датчиков, телеметрия, умный дом/умный город, роботы, цифровые двойники, автомобили/самокаты/велосипеды/дроны/самолеты, сотни тысяч и миллионы устройств, realtime processing, слабые каналы связи, mesh networks, а может быть наоборот — 5G для IoT, или, например, каппа-архитектура — то имеет смысл посмотреть в сторону MQTT.

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

Системный сдвиг

18 Nov, 12:39


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

А кто-нибудь его вообще в реальной жизни на работе применял? В смысле, не только для умного дома? Расскажите?

Системный сдвиг

15 Nov, 14:59


В проектировании систем есть фундаментальная проблема:

Закон Дырявых Абстракций: Все нетривиальные абстракции дырявы. (All non-trivial abstractions, to some degree, are leaky)

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

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

А ещё бывают конкурирующие запросы — один клиент изменяет ресурс, а другие в этот момент его читают. А ещё внезапно оказывается, что запросы выполняются не мгновенно, и передача большого куска данных может идти довольно долго (а при случайном или намеренном сложном запросе может и вообще завесить ваш сервер, см. XML Bomb или Billion Laughs Attack).

Вопрос границ ответственности в данном случае очень спорный. В общем случае аналитик не может быть глубоко погружен в технические детали. Пока абстракции не начали течь, и пока своими глазами не увидишь, как два почти идентичных запроса к БД выполняются за время, отличающееся в десятки раз, потому что запрошенные данные не попали на страницу, подгруженную в кэш СУБД (какой кэш? какие страницы? почему я вообще должен об этом думать?)

Итого, ответ такой: про зоны ответственности лучше договориться заранее. Где мне остановиться и что не описывать в моем документе? Кэширование — это ещё мое, или нет? А обработка ошибок? А санитаризация ввода — об этом нужно писать?

Я знаю, во многих компаниях есть соглашение о моделировании (бизнес-процессов, архитектуры). Почему-то гораздо реже встречается соглашение о содержании требований. Где останавливается БА, что добавляет СА, а что является технологической документацией, которую пишут разработчики/архитекторы или SRE?

Заодно при составлении такого соглашения может выясниться, что у вас в команде недостает каких-то специальных компетенций (например, по тем же уязвимостям API или по оптимизации запросов к БД).

Это риски, а системный анализ — он весь про риски. Лучше их выявить и принять меры.

Ну а чтобы выявить и разобрать, что кому уходит, нужно представлять весь процесс в мельчайших деталях. И, к сожалению, на нескольких уровнях абстракции, вплоть до физического. До сих пор помню, как мы недели две искали плавающий баг — у части клиентов сервер регулярно отваливался на несколько секунд, и не принимал подключения. Вычистили пару реально странных мест в обработчиках соединений, нашли одну утечку памяти. Всё без толку. А оказалось — разъем на свитче разболтался, нужно было патчкорд поменять.

Системный сдвиг

15 Nov, 14:58


По принципу Баадер-Майнхоф, вопрос "Что происходит, когда вы набираете google.com" не отпускает.

Шутки-шутками, но тут можно поговорить на серьёзную тему: про абстракции.

Ведь в этой картинке шутка в чем: никто не ожидает услышать в ответ на этот вопрос рассказ о таких глубоких уровнях реализации, как скан-коды клавиатуры (а если она USB — можно ещё и про потоки данных рассказать, стандарт USB довольно интересно устроен с точки зрения передачи данных — как маленькая сеть с иерархической топологией, и с разными режимами передачи пакетов данных). Даже в видео из предыдущего поста, на мой взгляд, чересчур подробно расписаны взаимодействия в процессе установки соединения TLS — аналитики в это обычно не погружаются.

Между тем, если абстрагироваться от устройства компьютера и ОС, а рассмотреть только сетевое соединение, остаются 7 уровней абстракции по модели OSI (никто не помнит все 7): от физического уровня — как электрончики бегают — до прикладного (собственно, протокол HTTP, например).

В модели TCP/IP уровней всего 4 (над физическим), легче запомнить: уровень передач пакетов в одной сети (link), уровень передачи между сетями (internet), уровень транспорта — как эти ваши пакеты собирать, что вам, например, важнее — надежность доставки (TCP) или своевременность (UDP), и, наконец, уровень приложений — что мы вообще передаем: файлы, гипертекст? Тут мы опять останавливаемся в лучшем случае на уровне приложений, а то и выше — SOAP и GraphQL — это надстройки на HTTP. Собственно, абстракции хороши чем — можно не думать, как они внутри устроены, а просто ими пользоваться.

Ну, до какого-то предела. Пока абстракция не начинает протекать.

Системный сдвиг

13 Nov, 10:26


Если вам задают вопрос "Что происходит, когда вы набираете в браузере 'google.com'?", вспомните это видео: https://www.youtube.com/watch?v=atcqMWqB3hw

Осторожно, видео со звуком! В офисе используйте наушники. Ну или наоборот — зовите всех вокруг, особенно разработчиков — они наверняка порадуются. В комментариях отметился Даниэль Стенберг — собственно, создатель утилиты curl. Он такой подход одобряет! :)

Системный сдвиг

11 Nov, 15:22


В комментариях к предыдущему посту замечают (справедливо!), что, следуя таким советам, можно легко остаться без проектов и без заработка. Это верно — всё определяется культурой управления, в которой вы находитесь.

Я знаю про два типа управленческой культуры: культура зонтика и культура воронки (Umbrella vs Funnel). Эти образы на картинке (с сайта https://sketchplanations.com/umbrella-funnel). В первом случае ваш менеджер ограждает вас от потока разнообразных... скажем так... внезапных входящих дистракторов. Дистракторы образно изображены на второй картинке.

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

И вот в этом стиле мне, как руководителю, как раз важно вовремя узнавать про проблемы, чтобы вовремя принять меры и прикрыть команду. А потом уже выяснять причины, извлекать lessons learned и придумывать противодействие таким ситуациям на будущее.

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

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

Вот такие корпоративные игры, так что выбирайте аккуратно — в какой культуре вам работать. Или учитывайте, в какой вы сейчас работаете.

Системный сдвиг

01 Nov, 12:01


Знаете ли вы, что у ChatGPT можно попросить нарисовать вашу жизнь по мотивам вашего общения?

Промпт такой: "Based on what you know about me from our previous conversations, please draw a picture how in your opinion my life could look like“

Мне рисует вот такое 👆

Не знаю, откуда он взял всех этих Supplers Suppllelers Suppleton, но если считать, что я поддерживаю и обеспечиваю деятельность аналитиков — то даже похоже :)

Системный сдвиг

31 Oct, 11:57


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

Как всё устроено:
1️⃣ Учитесь где и когда удобно
Обучение разбито на спринты по несколько недель, а график позволяет совмещать учёбу с другими делами.

2️⃣ Практика с первого дня
Учимся на примерах из работы и используем популярные рабочие инструменты.

3️⃣ Задачи из реальных сфер
На курсе будут проекты из разных сфер бизнеса, чтобы вы набрались опыта и сразу же применяли новые знания.

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

Вот несколько наших курсов:
Инженер данных
Инженер машинного обучения
SQL для работы с данными и аналитики
SQL для разработки

Получите скидку 20%  после прохождения первой темы любого курса. Она бесплатная🔥

Системный сдвиг

30 Oct, 11:39


Раз зашла речь про софт-скиллы, напомню ещё раз анекдотическую ситуацию с половиной статей про эти самые софт-скиллы: https://t.me/systemswing/213

Помните! Если вы видите в какой-нибудь статье фразу "Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%." — это из книги 1918 (не опечатка!) года про обучение инженеров в США, и главный "софт-скилл" там — твердость характера!

Системный сдвиг

29 Oct, 14:11


Продолжая тему конференций — не кажется ли вам, что популярность тем хардов и софтов на конференциях меняется циклично?

В какой-то момент, ещё лет 5 назад, чуть ли не половина докладов была про софты: как продуктивно работать, как проводить совещания, как не выгореть, как избегать конфликтов или наоборот манипулировать. Про разные там модели личности были популярны доклады, про балансы работы и жизни. Я на ЛАФе в 2022 году даже слышал доклад про то, как устроить себе саббатикал — то есть, уйти в долгий отпуск. В докладе было про 5 месяцев, но вообще саббатикал может быть и на год; в университетах его дают профессорам каждые 7 лет (или даже 5), Дональд Кнут написал TeX как раз во время такого отпуска.

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

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

Я вижу это по запросам на менторинг/консультации (а на Flow, например, была такая активность — "спроси эксперта", вот я был тем экспертом, и угадайте — про что был вопрос? Точно не про интеграции :))

Ещё примерно те же темы поднимались в опросе, который я когда-то проводил — и проблемы тоже совсем не с технологиями связаны и не с техниками анализа, а в основном с людьми.

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

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

Пишите в комментах вопросы, которые вас беспокоят, и на которые у вас нет ответа — будем разбираться!

Системный сдвиг

28 Oct, 13:17


Только представьте: вы приходите работать системным аналитиком в Т-Банк, а там выстроенные процессы, простое взаимодействие с командами и быстрые согласования. Никто не перекладывает ответственность, все ищут решения вместе с вами.

Хорошо, что это не просто фантазии, а собеседование в Т-Банк можно пройти за выходные. Оставьте заявку на Weekend Offer до 6 ноября  — как раз ищут специалистов уровней middle и senior.

Системный сдвиг

26 Oct, 08:32


На прошлой неделе посетила сразу 3 конференции: Joker, Heisenbug и Mobius. Проводила глубинные интервью, пытаясь выяснить следующие вопросы:
- Зачем ходят на конференции?
- Какие видят альтернативы?
- Зачем выступают на конференциях?
- Почему не выступают?

Пока выборка не насколько большая, чтоб делать глобальные выводы. А вот некоторыми интересными наблюдениями хочу поделиться:
- Java-разработчики отмечают, что уровень контента на конференциях сильно упал за последние пару лет 🔔
- Миддлы ходят на конфы в основном за тем, чтоб узнать что-то новое, собрать "спойлеры", которые потом поизучать
- Сеньоры и старше ходят на конфы в первую очередь за нетворкингом. Полезного контента для себя особо не ждут и не видят
- Разрабы показали крайнюю степень социофобии. Выступают те, кто "родился болтуном", остальные даже супер-экспертные профи - предпочитают общение с монитором. Тех, кто преодолевает это блокер - единицы ((
- У тестировщиков, аналитиков и менеджеров такой массовой проблемы с коммуникацией не наблюдается ))
- У спикеров везде своя тусовка и нетворкинг на порядок качественнее, чем у обычных участников 😎
- Выступают ради популяризации практик и походов, развития личного бренда, и потому что любят выступать )
- И нашла несколько звезд, которые выступают для того, чтоб делиться лучшими ноу-хау, и вернуть обществу "должок" (говорят, когда начинали свой путь - очень много полезного узнавали именно с конференций)

Все, без выводов. Я призадумалась. Вам тоже на подумать, что с этим делать 👀

Системный сдвиг

26 Oct, 08:32


Ещё немного инсайтов про конференции. Вот про нетворкинг спикеров — это правда. Я в свое время с очень крутыми людьми познакомился и пообщался именно в спикерской или в ПК.

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

Но при подготовке доклада приходится общаться с другими — и крутыми! — людьми, к которым потом можно придти и со своим вопросом или идеей. А ещё на некоторых конференциях для спикеров устраивают отдельный нетворкинг, что тоже очень круто. (А где делают несколько конференций — ещё и нетворкинг для членов ПК). В этом смысле был очень хорош ЛАФ, который и начинался как посиделки за шашлыком, и сейчас продолжает эту традицию, но почему-то не все доходят — видимо, не знают главной фишки :)

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

Системный сдвиг

23 Oct, 13:28


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

Мне кажется (как члену ПК нескольких конференций и много выступавшему чуваку), что конференции нужны для того, чтобы понять "где мы сейчас" и "что нового и актуального появилось". Это не совсем про учебу -- за один доклад ничему не научишься, а мастер-классы на конференциях ограничены по времени и их обычно не очень много.

А вот именно понять, чем индустрия дышит, что обсуждет, что нового появилось -- вот для этого. Можно читать форумы и статьи, но тут есть некоторое сведенная воедино силами программного комитета картина, курированный контент. То есть, не выдумки отдельных авторов, а репортажи о реальных делах.

Что с этим дальше делать -- конечно же, принимать решения. Моими первыми конференциями были, кажется, IT-people и RuCamp. Это был просто другой мир, после затхлых банков (это было время, когда итшников в банках ещё считали центром расходов и неизбежными дармоедами, и относились соответственно) и примерно таких же вузов. Во многом эти события определили мою дальнейшую траекторию. И я очень жалею, что не попал в те тусовки, в которые в итоге попал благодаря этим конференциям, ещё раньше (например, прозевал расцвет рунета).

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

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

У аналитиков, наверное, новое не так часто возникает, поэтому и кажется, что всё одно и то же. Ну, это тоже некоторый ответ -- раз всё одно и то же, значит что, индустрия стагнирует и не развивается? Все книжки друг другу кидают, так они ещё из прошлого века. Вигерс 2013, но это переиздание, первая версия написана в 1999. Купер и "Психбольница в руках пациентов" -- 1998. Что нового появилось? Какие новые технологии, какие вызовы?

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

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

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

Напишите -- а вы зачем ходите на конференции, или почему не ходите, если не?

Системный сдвиг

22 Oct, 11:40


Приглашаем на бесплатный онлайн-митап 😊
Поговорим о работе аналитика в B2B, обсудим реальные кейсы и инструменты, которые помогут повысить эффективность.

В программе четыре доклада:
🔸 На грани: как продакт и аналитик встретились в одной задаче — Мария Вострикова из ITSM 365
🔸 Балансируя между процессами: как аналитику не проиграть многозадачности — Наталья Асмолова из Naumen Inventory
🔸 Информационная безопасность — это больно? — Елизавета Степанова из Naumen Contact Center
🔸 Не рой аналитику яму: искусство сложных коммуникаций — Ирина Горбач из Naumen Contact Center

→ Зарегистрироваться.

Встречаемся онлайн 7 ноября в 16:00 мск.
Если вы из Екатеринбурга — приходите на афтепати 🍕

Реклама. ИНН 6671116364. erid 2VtzqvmQVL7

Системный сдвиг

22 Oct, 06:48


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

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

Например, два года назад я учился в РАНХиГС, и там мы строили CJM. А нынешнее обучение началось с трехдневной "деловой игры", которая на практике оказалось форсайтом (и именно rapid foresight, про который я несколько раз рассказывал в ИТ-сообществе, и который сейчас активно продолжает продвигать Дима Безуглый — собственно, я его с методикой и познакомил).

Методику воспроизводят неточно, где-то утерян дух, где-то — смысл, но, тем не менее, это она. Нужно отдать должное авторам — теперь, кажется, форсайты стали общим местом и стандартом для стратегических сессий (кстати, обращайтесь, если что, я их тоже провожу 🖐). А дальше обещают lego serious play и всё такое прочее.

Согласитесь, это вам не традиционные лекции и семинары! (Хотя они предусмотрены тоже, но, кажется, их не более трети от всех учебных активностей)

И это правильно — учиться нужно через деятельность, и только делая что-то своими руками/головой.

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

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

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

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

На практике же получается совсем другое: люди начинают защищать свой результат, потому что никому не нравится выглядеть дураком (об этом был прекрасный рассказ на Fail Night на последнем Flow — без записи, естественно).

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

В ситуации манипуляции человек тоже учится, но часто чему-то не тому (помните — "выученная беспомощность"? Вот, выучился!)

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

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

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

Системный сдвиг

22 Oct, 06:48


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

А с мотивацией можно работать отдельно, если это требуется.

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

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

Не знаю, как с этим обстоит сейчас дело в технических и итшных вузах, да и в компаниях, но, кажется, в нормальной компании и общение должно быть нормальным, а иначе бы все из них сбежали — при таком-то рынке кандидата!

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

Ну а для тех, кто организует, выбирает или проектирует обучение, повторю ещё раз:

1⃣ Освоение навыков происходит только в практической деятельности, соответствующей навыку (прохождение тестов учит проходить тесты, ну ещё способствует запоминанию, если вам это требуется).

2⃣ Манипуляции результатами через нарушения в организации деятельности (чрезмерное сокращение времени на задание, нечеткие инструкции или требования к результату, намеренный или случайный пропуск шагов при работе по методике) приводят не к обучению, а к отторжению (и иногда — к сплочению группы против ведущих, тоже результат).

3⃣ Уважительное общение и поддержка желательного поведения даёт при обучении гораздо больший эффект, чем выискивание и подчеркивание ошибок.

4⃣ Без лекционной части не обойтись, но старайтесь доносить одну сильную мысль за один смысловой блок — объем внимания человека ограничен.

5⃣ В практических заданиях сталкивайте человека со средой, фактами и логическими промахами, а не с мнением ведущего (особенно если это мнение выглядит как "к чему бы тут докопаться").


Так что спасибо этому обучению, я лучше стал понимать свои ценности и методы в обучении — на контрасте.

Системный сдвиг

19 Oct, 12:45


Пришли дети, увидели открытый draw.io, ой, а что это за стикмены? Слово за слово, нарисовали диаграмму.

Вопросы:
— содержит ли эта диаграмма элементы UML?
— это структурная или поведенческая диаграмма? (или диаграмма взаимодействия?)
— какой процесс тут, собственно, изображен?

Системный сдвиг

17 Oct, 12:32


Сколько вы знаете способов передачи данных на клиент по инициативе сервера?

В комментариях к предыдущему посту отмечают, что GraphQL не совсем верно упоминать рядом с Websockets, это вещи разного уровня. Давайте разберемся, и вспомним все варианты отправки данных с на клиент в тот момент, когда их решил отправить сервер.

Я насчитал 6 (добавляйте, если знаете ещё):

1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.

2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.

3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.

4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).

5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.

6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.

Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.

На самом деле, внутри GraphQL либо WebSocket, либо multipart subscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).

А  стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.

Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.

Системный сдвиг

14 Oct, 17:08


Главная проблема у Вигерса — это, конечно, полное отсутствие хоть каких-нибудь слов о проектировании API.

Абсолютно ничего. Хотя вся база для проектирования есть, и главное — это диаграммы. DFD в главе 12 (стр. 269) и, ещё лучше — Карта диалоговых окон на стр. 280 (напоминаю, что я даю страницы по изданию BHV 2013 г.).

Я такую диаграмму на тренингах обычно называю "схема навигации". Это очень простая диаграмма: прямоугольники — отдельные экраны (или разные состояния одного экрана), а стрелки — переходы с одного экрана к другому. Это очень мощный инструмент, необходимый и для проектирования интерфейсов, и для создания API. С точки зрения интерфейсов мы проверяем все варианты использования — буквально задавая вопрос "а на каком экране происходит этот шаг сценария?" (конечно, нас интересуют шаги, где пользователь вводит данные или дает команду, и те, где система запрашивает пользователя, предлагает выбор, предоставляет информацию или оповещает пользователя о чем-то).

Эта же диаграмма в какой-то мере повторяет диаграмму состояний — если у вас изменилось состояние ключевого объекта, то, скорее всего, это изменение инициировано действиями в интерфейсе (мы можем проверить полноту требований через проверку наличия требований/сценариев для всех переходов на диаграмме состояний). Тут же можно задать вопросы про обратные действия и возвраты — на диаграмме они будут видны особенно ясно: если у вас есть тупик, экран только с входящими переходами, это странно. Вы с него никуда не уйдете?

В общем, если к каждому экрану приписать состав данных, которые выводится на экране и которые вводятся, а также основное действие пользователя на этом экране и второстепенные — будет сразу понятно, как визуально выстроить экран, и дизайнер скажет вам спасибо!

Но эта же информация пригодится вам и для проектирования REST API! Именно REST, т.к. речь идёт о состоянии. Это распространенная ошибка — считать, что в REST нет состояния. Состояние клиента очень даже есть! (И это один из критериев, что вам подходит REST). Просто это состояние локализовано на клиенте, и не хранится на сервере (а только запрашиваются данные для смены состояния, Representational State Transfer). Вот ваша схема экранов и переходов как раз и является диаграммой возможных состояний клиента! И каждый переход — это вызов API. Нужно только к переходу дописать название эндпоинта, параметры и ответ. В таком виде диаграмма представлена в статье Майка Амундсена, про которую я уже писал, и которую, оказывается, давно перевел пользователь Andrei Gordienkov.

Тут может возникнуть вопрос — а если изменения происходят на сервере, и должны быть переданы на клиент? Во-первых, как это нарисовать? (Ну, тут я обычно рисую вместо экрана звездочку, и стрелку от неё к нужному экрану, где эти изменения должны быть отображены — состояние клиента изменилось). Во-вторых, что это за вызов? Очевидно, что это уже не REST, а нечто другое — Long Polling, WebHook, WebSockets, GraphQL или gRPC в режиме подписки/стриминга.

И всё, считайте, что эндпоинты API у вас уже готовы. Одновременно с дизайном.

Системный сдвиг

10 Oct, 13:43


Мы уверено преодолели отметку в 7000 подписчиков! Спасибо вам! 🙏🙏🙏Надеюсь и дальше вас радовать смешными и полезными постами.

А в комментах к этому посту предлагаю всем знакомиться, и написать — вдруг вам нужна какая-нибудь помощь? Может, вы ищете работу, или наоборот — нового коллегу, или совет, или ментора. Напишите! Нас тут много, возможно вам помогут!

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

Системный сдвиг

07 Oct, 09:54


Хорошую картинку нашел у bytebytego — сразу понятно, где какие стили API обычно используются.

Вот только в наших реалиях SOAP — это не Legacy, а государственные сервисы. И сбоку ещё брокера сообщений нужно пририсовать, с потоками из соседней системы, а снизу слой данных с ETL-процессами.

Системный сдвиг

04 Oct, 11:49


Channel photo updated

Системный сдвиг

02 Oct, 09:01


Недавно слушал отличную лекцию про сценарии сериалов и про особенности кинопроизводства. Я давно интересуюсь способом организации производства в других отраслях, и кино, мне кажется, во многом похоже на ИТ (ну или ИТ на кино, всё-таки киноиндустрии уже больше ста лет, а ИТ всё ещё молодое 😉).

Вот смотрите:

Всё начинается с логлайна. Это описание идеи фильма или сериала в 1-2 предложениях. По нему продюсеры принимают решение — брать сценарий или не брать. Структура логлайна: герой — проблема — цель героя — конфликт. А, каково? В принципе подходит для описания концепции ИТ-продукта — для него есть своя формула, похожая.

Идеи фильмов делятся на high-concept и low-concept. High-concept — это такая идея, которой ещё не было, и которая захватывает сразу с логлайна. В нашем понимании — прорывной стартап. Low-concept — обычная идея, знакомая всем, из которой, тем не менее, может что-то получиться за счет каких-то особенных мелочей или общей синергии.

После логлайна (или вместе с ним) пишется синопсис. Это — короткое описание всей истории, на 1-2 странички + особенности производства + формат, жанр, аудитория, бюджет места съемок, продолжительность и т.д. Короткий, но основной продающий документ. В ИТ это концепция проекта. У нас на курсах, например, на базовом "Разработка требований в ИТ-проектах" используется шаблон как раз на 2 страницы.

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

Дальше идёт поэпизодный план — он уже имеет размер 20-30 страниц, выстроен по сценам и актам, и в том порядке, в котором их увидит зритель. Диалогов в нём всё ещё нет! Ну может только ключевые реплики. Зато есть все сюжетные повороты. В поэпизодном плане проверяется структура истории, пересечение линий персонажей и их взаимовлияние, и продумываются решения отдельных сцен — мы в этой сцене хотим, чтобы зритель понял вот это, а как мы это покажем? Как эта сцена двигает сюжет или раскрывает персонажей? В большой ИТ-системе это соответствует схеме навигации с описанием экранов (но без дизайна!)

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

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

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

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

И сценарист начинает переделывать или уточнять сценарий после всех замечаний.

Мне кажется, это очень классная практика, и её нужно повсеместно в ИТ внедрять. Вот именно в виде синхронной читки документов всеми цехами. Вообще на планировании спринта именно это должно происходить, но на практике, кажется, идея потеряна, а стоило бы на всех проектах ввести!

Системный сдвиг

01 Oct, 09:51


Публикую презентацию с Flow про UML. Нужно тему сворачивать, а то уже, говорят, приклеилась слава, что "Куприянов всем говорит, что UML умер". Так вот — UML жив, и неплохо себя чувствует. Прямо по Жванецкому: "И что смешно — министр мясной и молочной промышленности есть и очень хорошо выглядит". Или как в "Кин-дза-дзе": "Побойся неба! ПЖ жив! И я счастлив!" (да, я бумер, и мемы у меня бумерские).

Так вот, что смешно: UML жив, и хорошо выглядит. Собственно, об этом в презентации. Основные тезисы:

80% опрошенных используют UML (хоть какие-то элементы из него). Впрочем, эта оговорка почти незначима — опрос показывает, что если уж вы начали использовать UML, то скорее вы используете в целом что-то похожее на стандартные диаграммы, а не отдельные элементы.

84% диаграмм — формальные. Наброски и "просто картинки" системные аналитики не рисуют.

Да, аналитиков в опросе было 59%, 19% — архитекторов, 13,5% — разработчики.

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

Что ещё: аналитики в основном работают в финтехе (больше всех), в екоме и гос.проектах. И в других отраслях россыпью, почти столько же, сколько в финтехе. Большинство работает в крупных или средних компаниях — почти 85%.

Там же чаще используют UML. Если вы фрилансер или работаете в маленькой компании, UML у вас скорее не используется.

Почти 42% работают в продуктовых компаниях (так что неверен тезис, что в продуктах нет системных аналитиков), 25% — во внутренней автоматизации.

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

Поэтому неудивительно, что самая популярная диаграмма — Sequence Diagram. Её используют вдвое чаще, чем любую другую.
Удивительно, что на втором месте по частоте использования — Use Case Diagram, а за ней — State Machine и Activity. Остальные используют реже.

Применение agile никак на использование UML не влияет. От стажа работы использование UML зависит отрицательно: чем больше стаж, тем меньше применяют UML (корреляция небольшая, -0.26, но отрицательная).

Кроме UML используют BPMN (примерно треть опрошенных), C4 (10%), Archimate (21 человек из 275), а ещё ERD, IDEF0, DFD и EPC — но очень мало.

Вот такие основные выводы. Если есть идеи, что ещё можно было бы проверить на этих данных — пишите, посмотрим.

Системный сдвиг

27 Sep, 09:39


Одним из самых главных инсайтов Flow для меня стало вот это разделение нотации и метода. Часто их не разделяют, и от этого много путаницы.

Вот смотрите:
UML — это нотация. Booch, OMT, OOSE, Iconix (и даже C4!) — методы применения этой нотации.

IDEF0 — это метод. Так и называется: "МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ", есть рекомендации по стандартизации Р 50.1.028-2001.

BPMN — нотация. Есть книга Брюса Сильвера 'BPMN Method and Style' (https://methodandstyle.com/books/bpmn-method-and-style/), вот в ней предложен метод создания BPMN-дигарамм.

DFD — нотация, а структурный анализ — набор методов.

DDD — набор идей и паттернов, Event Storming — метод.

Agile — декларация ценностей, SCRUM и SAFe — методы ведения деятельности по разработке ПО.

ГОСТ 34 — описание содержания документов, "Руководство по написанию требований INCOSE" — метод.

REST — набор принципов, OpenAPI — язык описаний API, 'Design and Build Great Web APIs' Майка Амундсена — метод их проектирования.

User Story — формат фиксации требований, а Impact mapping и User Story Mapping — методы работы с ними. А JTBD, например, не просто формат записи, но ещё и имеет некоторые элементы метода.

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

Системный сдвиг

24 Sep, 11:28


Мы с уточкой передаем всем подписчикам большой привет с конференции Flow'2024, поздравляем с днём системного аналитика, и желаем удачных проектов, интересных задач, успешного профессионального развития, достижения личных и карьерных целей, а также всеобщего процветания!

Ура! 🎆🎆🎆

Системный сдвиг

21 Sep, 10:14


На тренинге возник вопрос: вот я аналитик/менеджер/заказчик. Разработчики или архитекторы приносят проект архитектуры. Как мне понять — он хороший или нет? Соответствует ли он требованиям бизнеса? Подойдет ли? Не будет ли с такой архитектурой проблем в дальнейшем, а если будут — то в каком месте они могут возникнуть? И как вообще разработчики и архитекторы придумывают эту архитектуру? Что бы почитать или какой курс пройти на эту тему?

Мне, в первую очередь, приходит в голову книга Алекса Сюя про прохождение System Design Interview. Но для совсем начинающих там очень хороша первая глава ("Масштабирование от 0 до миллионов пользователей"), а дальше начинаются частности — примеры рассуждений при проектировании конкретных систем, причем зачастую низкоуровневых: ограничителя трафика, хранилища ключ-значение, генератора уникальных идентификаторов и т.п. Нет, там есть, конечно, проектирование новостной ленты, мессенджера, youtube и google drive, что можно соотнести с прикладными задачами, но половина примеров — чисто инфраструктурные, и тут, мне кажется, разрыв с первой вводной главой слишком велик — нужно предварительное понимание, например, как работает кэш, а это и не каждый программист понимает.

Первая глава последовательно вводит некоторые базовые идеи, рассказывающие о начальных принципах архитектуры:
* система с одним сервером (имеется в виду веб или мобильное приложение с бэкендом);
* выделение базы данных (и короткий обзор реляционных и NoSQL);
* вертикальное и горизонтальное масштабирование;
* балансировщики нагрузки;
* репликация;
* кэширование;
* системы с сохранением состояния и без сохранения состояния;
* очереди сообщений и т.д.

А вот более сложные концепции, типа CAP-теоремы, технологий опроса (polling, long polling, WebSocket...), стратегии гарантированной доставки или примеры решений по обработке ошибок — "зарыты" в описании конкретных примеров. Причем заранее не угадаешь — где будет про проектирование API (тема подходит для технического менеджера или аналитика), а где про префиксные деревья (тема чисто программистская).

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

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

Системный сдвиг

19 Sep, 10:58


Стартовал образовательный сезон — даже не знаю, какой по счёту — 17?.. Кажется, я начал регулярно преподавать в 2007 году, разработал и вел курс "Технологии программирования" в МИЭМе. До этого никто и никогда не рассказывал студентам про паттерны, VCS и таск-трекеры, представляете?

Стартую бодро, с корпоративного курса по проектированию интеграций, группа подобралась отличная!

Сразу после курса еду на Flow 2024 Autumn — рассказывать о результатах исследования по использованию диаграмм.

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

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

Потом, вероятно, будет Analyst Days, ну и между этим всем ещё наверняка парочку корпоративных воткнут.

Сезон! Все хотят учиться! (Если вы тоже хотите — приходите в личку за промокодами)

Системный сдвиг

17 Sep, 16:42


Никто не может объять необъятное. Сколько не изучай методы проектирования API, всегда найдется что-то новое. Или старое. Вот, например, текст, который мне раньше не попадался, и идеи, которые в нём приводятся, тоже отдельно не встречались (хотя сам я их использовал при проектировании, так часто бывает).

Статья 2014 года, нужно это иметь в виду! В некоторых местах взгляды автора явно несколько устарели.

Итак, Майк Амундсен, Методология проектирования API из 7 шагов, краткий пересказ:

Хороший дизайн идёт прежде эндпоинтов, кодов ответов, заголовков и форматов сообщений.

1️⃣ Перечислите все данные, которые клиентское приложение может захотеть получить или передать в сервис. Назовем их семантическими дескрипторами — они имеют смысл и описывают, что происходит в приложении. Важно: это точка зрения именно клиента! Примеры для приложения для ведения списка дел:
id: уникальный идентификатор каждой записи в системе;
title: название каждого пункта;
dateDue: дата, до которой нужно сделать дело;
complete: флаг да/нет, показывающий, сделано ли дело.
(на курсе мы называем это "словарь данных")

2️⃣ Нарисуйте диаграмму состояний
Тут автор приводит некую хитрую диаграмму, где прямоугольниками нарисованы формы представления (representations) — документы или экраны, содержащие элементы данных (семантические дескрипторы из предыдущего шага). Между формами представления рисуют стрелки — переходы. То есть, каждый переход трансформирует форму представления (например, список дел ➡️ одно дело). Трансформации помечаются как безопасные (идемпотентные) или небезопасные (неидемпотентные). Названия переходов-трансформаций — это тоже семантические дескрипторы.

3️⃣ Согласуйте "магические имена"
"Магические имена" — это названия ваших семнатических дескрипторов. Майк рекомендует придумывать их не абы как, а синхронизировать с открытыми перечнями названий данных и операций: schema.org, microformats.org, Dublin Core, IANA Link Relation Values. Идея в том, что с этими именами разработчики клиентов могли ранее сталкиваться в других API, и поймут их смысл. Для своего примера он выбирает такие названия:
id -> identifier из Dublin Core;
title -> name из Schema.org;
dueDate -> scheduledTime (мне кажется, dueDate было понятнее)
complete -> status (вот тут я против, скажу прямо)

(В общем, спорное решение, но вообще над стандартизацией названий и действий стоит задуматься!)

4️⃣ Выберите Media Type
Тут можно выбирать между XML/HTML/JSON/и т.д., но можно и глубже — например, структуры JSON могут быть разными (скажем, есть HAL, а есть JSON:API, это всё зарегистрированные IANA медиа-типы).

5️⃣ Создайте "семантический профиль"
Тут всё просто — это OpenAPI или TypeSpec (автор упоминает WSDL, я немного актуализировал).

6️⃣ Напишите или сгенерируйте серверный и клиентский код.

7️⃣ Опубликуйте описание API в каталоге
(Имеется в виду, что он есть у вас в организации или вы публикуете спецификацию открытого API в одном из общедоступных каталогов).


Вот такие шаги :)

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

Системный сдвиг

15 Sep, 10:17


Как выглядит на практике работа с Enhanced Burndown Chart.

Попросили меня посмотреть, что с проектом. А то заказчик говорит — уже почти два месяца прошло, а ничего не движется. Первичная диагностика: смотрим, что там "не движется" (картинка 1). Видим, что с 1 по 5 итерации разработка действительно не очень сильно напрягалась, но, тем не менее, выполнила все первоначальные задачи. Видим резкие скачки на 3 и на 7 итерации — заказчик накинул новые требования, которых не было в самом начале.

В принципе, для agile это нормально, но конкретно на этом проекте ситуация с поставкой ценности не очень — заказчик до сих пор не может ничего использовать — нет законченных целостных сценариев (это проблема планирования спринтов, явная ошибка). Ну и первоначально выявленные требования очевидно не полны — можно увидеть, как заказчик смотрит на промежуточный результат, и только в этот момент понимает, что ему нужно (3 итерация).

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

Команда понимает недовольство заказчика, и пытается решить это, как умеет — сделать побольше задач, возможно — с переработками. Это дает мощный 7 спринт, да и 6 тоже был производительный. Однако в ожидания вновь не очень попали: заказчик в 7 опять накидал новых задач. Ясно, что команда в таком же авральном режиме долго работать не сможет.

Теперь нужно решить, что делать дальше. Варианты (на картинках — прогноз числа задач по спринтам):

* объявить фича-фриз, то есть перестать принимать новые задачи на какое-то время, и закончить те сценарии, которые уже в работе. Заказчику не понравится, но будет хоть какое-то законченное изделие к 11 итерации;

* посмотреть на тренд 7 и 8 итерации, и предположить, что команда уже достаточно выявила потребности заказчика, и дальнейших рывков вниз не будет. Поэтому можем не морозить скоуп, а заодно можем ещё раз напрячься, как мы уже делали на 6-ой итерации. Тогда можем успеть к 12 итерации, но есть значимая вероятность, что проект уедет правее;

* если не напрягаться, но предположить, что новых требований не будет, то мы уезжаем куда-то вдаль, и конца проекту не видно;

* наконец, если совместим фича-фриз и напряжемся, то можем выиграть одну итерацию (11 вместо 12).

Вот такой диагноз и такие варианты действий. Как вы думаете, какой вариант был выбран в реальности?