Курс по технике разработки требований уже на этой неделе! Осталость ещё пара мест, можно успеть.

А ещё лично меня можно увидеть в марте на классическом курсе-боевике "Системный анализ. Разработка требований в ИТ-проектах" от школы системного анализа и проектирования Systems.Education.

Курс просто ставит голову системного аналитика на место и даёт четкий и последовательный план работы над проектом требований к новой системе. Как писать требования, когда применять use cases, как думать про НФТ и зачем нужна контекстная диаграмма и модель предметной области — всё расскажу. Идёт уже больше 10 лет, практически живая легенда, а не курс! Буду вести его очно в Москве 21-23 марта.

А в апреле будет его продолжение: разработка проекта интеграции, для опытных аналитиков — "Основы проектирования интеграций ИТ-систем". Тут мы разбираемся с интеграциями систем во всех видах, от обмена файлами до брокеров сообщений, и, конечно, особенно подробно с проектированием REST API. Это уже апрель, тоже очно в Москве, с 4 по 6.

Дальше по плану — онлайн-конференция "Проектирование промышленных ИТ-систем", тоже от Systems.Education, и программа там просто огонь! Это 20-21 апреля. https://systemsdesign.online/

Потом уже в мае в Санкт-Петербурге сначала Analyst Days (24-25), а потом Анализ & Управление от Инфостарта (30-1).

А там и ЛАФ в июле!

Очень насыщенный событиями для аналитиков год, выбирай — не хочу!

Из перечисленных выше законов хочу обратить внимание на принцип Постела или Принцип устойчивости (Robustness principle).

Изначально его сформулировал Джон Постел, разработчик множества интернет-протоколов. Многих учёных и инженеров называют "отцами" и "матерями" Интернета, а Постела ещё при жизни звали "God of the Internet", хотя он сам был против такого именования.

Принцип устойчивости впервые приведен в RFC 760 со скромным названием "Internet Protocol". Позже переформулирован в RFC 1122: "Требования к хостам Internet". То есть, принцип изначально относится к приему и отправке IP-пакетов, и звучит так:

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

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

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

В этом есть некоторое противоречие: когда вам рассказывают про API, обязательно говорят про схемы запросов и ответов (json-schema, xsd, схема в OpenAPI), и эти схемы исподволь продвигают идею контроля: больше правил валидации, точное указание типов данных и набора полей. Одновременно схема используется для генерации кода на клиентах и сервере. Удобно, если вы можете менять клиентов и сервер одновременно. Но это и означает связанность и синхронизацию релизов!

Так можно делать, если:
1) ваше API внутреннее;
И/ИЛИ
2) стабильность вашего сервиса важнее удобства клиентов (вы намного главнее и не зависите от клиентов - например, вы гос.орган, под который все подстроятся)

А вот расшивка клиентов и сервера требует сооблюдения принципа устойчивости. Для API это означает, что схема запросов должна:
🔸допускать в запросах неизвестные поля и параметры (сервер должен игнорировать их и не выдавать ошибку);
🔸принимать значения в виде строк, а не чисел/булевых;
🔸не ограничивать значения набором символов, масками и регулярными выражениями;
🔸избегать перечислимых типов (enum);
🔸не ограничивать максимальный размер списков;

Это не означает, что вообще не нужно делать никакие проверки — это означает, что не следует отправлять ошибку сразу при проверке запроса, до обработки. То есть, приняли, как есть, попытались обработать, всё, что не соответствует ожидаемому формату — записали в журнал. Проверки делаем не на уровне API, а немного за ним, поближе к логике: форматы и валидацию делаем там, а заодно санитарную обработку запроса — удаляем разные варианты инъекций, XML-бомб и т.п. И никогда не передавать/принимать напрямую бизнес-объекты без валидации и проверок!

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

Ну вот, кстати, по поводу либеральной обработки входной информации. Не дотянули немного до 1 апреля 😆

Зато смотрите, как грамотно: ошибки http с кодами 2xx — это успешно выполненные запросы. Там уже есть 200 OK, 201 — Created, 202 — принято на обработку, запущен долгий процесс, 203 — информация не из первичного источника, 206 — возвращена запрошенная часть ресурса.

Сомнительно, впрочем, что API возвращают такие ответы, а клиенты умеют их обрабатывать. Обычно всё ограничивается 200 — окэй.

Надеюсь, вы и ваши близкие здоровы и целы. Берегите себя.

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

Хотя статьи эти написаны в первую очередь для разработчиков, аналитикам, особенно проектирующим API, тоже нужно разбираться в теме. Особенно критичной тема перезапросов становится при наличии множества экземпляров клиента (фронтового клиента или клиента-микросервиса) и высокой нагрузки. Если у вас API используется только между двумя экземплярами системы раз в сутки — то вам и заморачиваться особо не нужно (и вообще это больше похоже на ETL, а не на API).

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

Даже если сервер не упадет совсем, а просто замедлится — начнет расти число активных клиентов по Закону Литтла: число клиентов в очереди равно интенсивности запросов умноженное на среднее время обработки запроса. Через некоторое время сервер просто перестанет отвечать: все доступные соединения будут заняты. Если клиент сам обрабатывает запрос другого сервиса — что бывает очень часто в микросервисной архитектуре — задержка начнет распространяться по всей системе в обратную сторону, и ляжет всё.

Как сказано в статье от AWS:

Рассмотрим систему, в которой вызов пользователя создает пятиуровневый стек вызовов сервиса. Он предусматривает отправку в итоге запроса к базе данных, а также три повторные попытки на каждом уровне. Что происходит, когда в базе данных начинают возникать ошибки запросов вследствие нагрузки? Если на каждом уровне выполняются свои повторные попытки, нагрузка на базу данных увеличится в 243 раза, что сделает ее восстановление маловероятным.

Какие моменты в статье про Васю и на что нужно обратить внимание, когда в проектируете перезапросы:
1. Максимальное число перезапросов (в какой-то момент нужно остановиться и выдать ошибку)
2. Промежутки между запросами: равные или увеличивающиеся (exponential backoff)? Кроме экспоненциального роста промежутка бывают ещё увеличивающиеся по последовательности Фибоначчи.
3. Максимальное время, пока мы вообще делаем перезапросы.
4. Jitter — случайная задержка между запросами, чтобы распределить нагрузку от разных экземпляров клиентов.
5. Circuit Breaker — "размыкатель" — отключение ретраев при превышении числа неисполненных запросов определенного порога, например — 20%
6. Retry Budget — на перезапросы выделяется ограниченный "бюджет", доля от общего числа запросов. В статье от AWS упомянут "алгоритм маркерной корзины", который работает примерно так: от каждого успешного запроса клиент "откладывает" в "корзину" часть маркера/токена, например, 0.1. Для того, чтобы сделать перезапрос, клиент должен "взять" из корзины целый токен (соотношение 1/10). Если целых токенов в корзине нет — перезапрос не на что сделать.

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

P.S.: Кроме статьи про ретраи, про Васю есть ещё статья, в которой он проектирует API, там тоже много интересного.

В статье про то, как Вася проектировал API, есть блок про безопасность.
Но не такую безопасность, как https и схемы авторизации, а не совсем очевидную: раскрытие чувствительных данных и компрометация системы.

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

Про ситуации, когда по известной структуре адреса можно скачать документ безо всякой авторизации, думаю, вы не раз слышали. То есть, у вас есть бинарный документ (doc, pdf, xls) или образ (jpg, png), и он лежит в файловом хранилище, а в ответ API подставляется по ссылке. Если ссылки устроены однотипно, а файлы имеют упорядоченные наименования — например, по порядку, или по дате — то можно выкачать их все. Например, как это было на Госуслугах.

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

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

✅ выдача идентификаторов не должна идти подряд! Иначе можно простым инкрементом вытащить сразу много объектов. А также, например, узнать прирост числа объектов за день, что тоже может быть интересным.

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

✅ избегайте бесконтрольное перекладывание данных из БД в API, включая мета-информацию (кто создал, кто последний раз обновлял, и т.п.)

✅ не выдавайте лишней информации в ошибках. Например, API Github не выдает ошибку 403 при попытке доступа к приватному ресурсу, а выдает 404 — чтобы нельзя было в принципе обнаружить существование такого ресурса!

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

✅ контроль подозрительной широты запросов клиента, не соответствующих естественным бизнес-потребностям (от имени учителя истории в средней школе множество запросов результатов тестов по математике и физике 10-11 классов)

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

Знаете ли вы, что уровни обязательности требований стандартизированы? Ну, хотя бы в Интернете: есть RFC 2119, где перечислены следующие модальные глаголы:

MUST (необходимо) — а также требуется (REQUIRED) и нужно (SHALL), означают абсолютную необходимость.
MUST NOT (недопустимо), SHALL NOT (не позволяется) — соответственно, абсолютный запрет.
SHOULD (следует) и RECOMMENDED (рекомендуется) — требования, от выполнения которых можно отказаться при наличии разумных причин.
SHOULD NOT (не следует) и NOT RECOMMENDED (не рекомендуется) — эти вещи допустимы, но могут вызвать проблемы.
MAY (возможно) и OPTIONAL (опционально) — можно включать (для полноты), можно не включать (для упрощения) — в целом, все должны быть готовы к тому, что у кого-то эта функция может быть не реализована.

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

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

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

А вот в RFC 6919 от 1 апреля 2013 были добавлены дополнительные уровни требований:

MUST (BUT WE KNOW YOU WON'T) — необходимо (но мы знаем, что вы всё равно не сделаете). Думаю, тут не нужно объяснять, очень полезный уровень требований в реальных проектах! В реальной практике выражение в скобках очень часто опускается.

SHOULD CONSIDER (следует рассмотреть) — когда авторы спецификации хотели бы, чтобы тут что-то было сделано, но пока не придумали — что именно.

REALLY SHOULD NOT (действительно не следует) — когда мы знаем, что что-то нежелательное всё равно будет сделано, и поэтому не можем написать "недопустимо".

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

WOULD PROBABLY (вероятно стоило бы) — когда четкого обоснования требования нет, на автор спецификации хочет надавить на разработчика, используя пассивную агрессию.

MAY WISH TO (могут пожелать) — описание почти бессмысленной функциональности, которую запросил кто-то из второстепенных согласующих и которую точно никто не будет делать, но намек на неё остается, чтобы не затягивать согласование документа.

COULD (может) — тонкий намек на критически важную функцию, но без жестких требований.

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

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

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

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

1. Сформулированы.
2. Записаны.
3. Доведены до адресатов.
4. Проверены на соответствие результатов.

В деталях:
Сформулированы: Должна быть буквально проведена работа по выявлению ожиданий. Кто, чего и от кого/чего ожидает. Особенно если неявно. Особенно если «ну я думал вы сами догадаетесь, это же очевидно».

Записаны: Должна быть буквально проведена работа по фиксированию всего о чём проговорили. Текстом, документом, табличкой, реестром, схемами, всем чем можете. Лаконично, но достаточно. Главная цель — ничего не оставить на словах.
Сюда же входит задача провалидировать записанное с заказчиками. Иван Иваныч, а я правильно записал? Ну-ка гляньте.

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

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


Этот пост мне живо напомнил принцип 3C's Рона Джеффриса, сформулированный ещё в 2001 году применительно к пользовательским историям: Card, Conversation и Confirmation. Требования сформулированы и записаны — это Card. В оригинале карточка не равна требованию, сам Рон называет её токеном (token), вещью для представления требования и управления им. Такая заметка, чтобы не забыть, что нужно обсудить идею. Четвертую C обычно не упоминают, но это Commitment — обязательство. Как только идея — может быть, ещё даже не требование! — зафиксирована, у команды возникает обязательство её обсудить. В одном из проектов у меня даже KPI были такие — число обработанных идей, то есть — рассмотренных, обсужденных, возможно — проверенных экспериментом и принятых в работу.

Обсуждение — conversation — вот что важно. Это решает задачи и по формулированию, и по доведению до адресатов (тех, кто будет создавать реализацию). И тут стоит добавить пятую C — Collaboration. Требования не записаны в голове у стейкхолдера, требования - точнее, решения по свойствам будущего продукта — рождаются в ходе совместного обсуждения, поэтому обсуждение так важно. И особенно важна возможность свободного высказывания членами команды, предложения идей, уточнения запроса. Вовлечение команды разработки в процесс определения свойств продукта (специально не пишу "выявления требований"!). Иначе это прямой путь к выгоранию.

Тут опять возникает commitment: обсудив решение, команда принимает обязательство по его реализации. А коллаборация подключает "эффект Икеа": если ты принимал участие в разработке решения, то ценность его для тебя растет, и такое решение легче исполнять.

Ну и подтверждение, confirmation. В свежей (от 2019 года) статье про 3C's Рон пишет про сдвиг в сторону максимально конкретного выражения этого самого confirmation — в виде конкретных примеров, в идеале — исполнимых. Хуже ничего нет, чем "совещание по приёмке" — когда толпа людей просто идут по пунктам ТЗ и отмечают их реализацию путем осмотра готового ПО, без заготовленных примеров, без рассмотрения краевых ситуаций и стыков — на чем в последствии и вылезают большинство дефектов.

Так что, идеальная картина:
1. Зафиксировали намеченное требование (идею).
2. Обсудили вместе с заказчиком и представителями разработки, наметили способ реализации.
3. Составили и согласовали способ проверки.
4. Реализовали, проверили.

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

Собственно, по управлению требованиями у нас есть целый ГОСТ Р 59194-2020.

Вот его основные положения.

1. Есть два вида деятельности:
— разработка требований (инженерная деятельность по выявлению, анализу, декомпозиции, проверке, согласованию и утверждению требований к изделию).
— контроль требований (управленческая деятельность, направленная на поддержание актуальности и согласованности требований к изделию и его СЧ в ходе всего ЖЦ изделия (в том числе при изменении потребностей заинтересованных сторон).

2. Требования могут быть представлены в форме базы данных или документа.

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

4. Есть два типа "контрольных рубежей":
— на которых проверяют, согласовывают и утверждают разработанные требования к объекту (в результате требованиям присваивают статус готовности);
— на которых проверяют соответствие объекта требованиям (в результате требованиям присваивают статус выполнения).

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

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

6. Минимальный набор атрибутов требования:
— Уникальный идентификатор
— Ссылка на потребность заинтересованной стороны (в идеале -- выраженной в документе. Ссылка на конкретный пункт документа)
— Для проектных требований — ссылка на исходное требование или запись о принятом техническом решении (привет ADR!)

7. Очень сильная идея: требования являются частью конфигурации!
И статус выполнения требования тоже относится к конкретной конфигурации и конкретному этапу работ (в стандарте они названы "контрольные рубежи").

То есть, одно и то же требование может быть выполнено в одной конфигурации, и не выполнено в другой!

Про конфигурации и их изменения есть соседний ГОСТ Р 59193-2020 "Управление конфигурацией", там, в частности, написано, как обходиться с изменениями конфигураций разных видов и по разным причинам (и изменениями требований, как части конфигурации).

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

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

Вот тут-то управление конфигурациями и начинается!

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

В модели KSA это третья буква — Attitude, в переводе: отношение, подход, жизненная позиция. Я уже писал про неё пару раз. И это отношение очень хорошо проявляется на тренинге.

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

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

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

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

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

И ведь как интересно может быть!

Помню, когда я вел тренинг Сергея Нужненко про ручку, мы загадали участникам написать ТЗ на ручки для детского самоката. Так как это товар для детей, было очевидно, что он зарегулирован. И действительно, есть ГОСТ Р ИСО 8124-1-2014, где детским самокатам посвящен отдельный раздел 4.29 и разделы 5.26-30 с методами испытаний. Это же просто песня! Во-первых, можно сразу брать из документа готовые требования. Во-вторых, я надолго зачитался самим стандартом и пришел в восторг — как много, всё-таки, требований к физическому изделию — там и размеры, и прочность, и острые углы, и акустика, и магнитные свойства, и электрические — вот где действительно требуется анализ требований!

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

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

Ваше API не REST! Ну и что?

Слова "REST API" уже несколько потеряли свой смысл, и только пуристы и зануды вспоминают Леонарда Ричардсона с его четырьмя уровнями зрелости REST API и Роя Филдинга с его диссертацией. Это как Конституция — все слышали, что она есть, но мало кто её сам читал, а уж когда доходит дело до применения... Мы используем http — значит, у нас уже REST!

В реальной практике чего только не бывает, и CRUD вокруг ресурса — под что REST наилучшим способом заточен — бывает как раз не так уж часто. В сервисах и микросервисах часто в API выставляют некие функций (у которых даже имена, как у функций: getClientPortfolio, validatePassport, saveFile), и близко не покрывающие матрицу действий по созданию, чтению, изменению и удалению.

И это оправдано! Ну вот какой ресурс мы создаем или читаем при проверке паспорта заёмщика? Да мы его просто проверяем.

не-REST API — это нормально. Если вы осознанно выбрали этот вариант, и понимаете плюсы и минусы. Удаленный вызов процедуры, RPC, как паттерн имеет смысл. Только давайте будем честны перед собой и не будем называть это REST. С другой стороны, а как называть, если это не SOAP, а что-то более легкое и на JSON-чиках?

Вообще, с 2005 года существует и развивается протокол JSON-RPC, сейчас уже версии 2.0. Хотите RPC на JSONах — возьмите хоть что-то более-менее стандартизованное, не изобретайте велосипед. Есть уже готовые реализации протокола почти на любом языке.
Официальный сайт https://www.jsonrpc.org/

Есть свой эквивалент сваггера и OpenAPI: OpenRPC, который одновременно и документацию генерит, и работает как WSDL для SOAP — то есть, позволяет получить весь контракт сервиса JSON-RPC.

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

В англоязычной среде есть термин 'bikeshadding', "обсуждение сарая для велосипедов". Велосипеды здесь по совпадению, а может быть и нет. Источником является история про комиссию, которая должна была согласовать проект атомной электростанции, но на каждом совещании занималась рассмотрением мелких вопросов вроде сарайчика для велосипедов — из каких он должен быть материалов и где установлен? Другое название этого эффекта — "Закон тривиальности":

"Участники обсуждения всегда придают чрезмерное значение тривиальным вопросам"

или

"Время, потраченное на обсуждение пункта повестки, обратно пропорционально его важности"

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

В общем, прекращайте обсуждать сарайчик для велосипедов! Решите главное: у вас REST или RPC. Решили? Берите готовый стандарт: OpenAPI и JSON:API для REST, JSON-RPC или SOAP для RPC, и двигайтесь дальше. Там, глядишь, и до gRPC доживете :)

В этом году я член ПК Летнего Аналитического Фестиваля, он состоится в Подмосковье 13-14 июля, и остается чуть больше недели, чтобы подать заявку на доклад!

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

Темы, которые мы ждем больше всего:
- Проектирование, интеграция и архитектура
- Практики использования инструментов для системных аналитиков
- Продуктовые практики
- Использование AI-инструментов

А также:

- Разработка и управление требованиями
- Развитие и саморазвитие аналитика
- Soft skills
- Лидерство и управление командой
- Другие темы, которые помогут расширить кругозор аналитика

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

Зарегистрировать заявку на доклад можно здесь: https://events-pro.ru/conference/fe501f51-4043-4340-882b-55e5cd97f1a5/become_speaker

(Если совсем сомневаетесь — можете мне в личные сообщения написать с идеей, обсудим)

Для докладчиков проживание в отеле Sheraton Skypoint Luxe 5* БЕСПЛАТНО при включении вашего выступления в программу.

Срок подачи заявок - до 20 апреля 2024 года.

На корпоративных тренингах на рабочем месте часто бывает ситуация, когда люди отваливаются: вчера ещё было 3 человека в команде, а сегодня, смотришь — остался только один, остальных растащили на встречи.

И часто этот оставшийся работает лучше и быстрее, чем до этого они работали втроем!

Я и сам сталкивался с таким, как участник: на одном курсе по управлению проектами мы выполняли задание сначала индивидуально, а потом то же задание в группах. По идее, результат группы должен быть лучше самого лучшего индивидуального результата, но моя группа сумела даже ухудшить мой результат :) Инициативу захватила одна участница, которая, видимо, очень хотела показать свои лидерские качества, а проще всего это сделать, если всех критиковать, подвергать сомнению и настаивать на собственной правоте. А то какой же я лидер, если просто прислушиваюсь к другим! Я в это играть не очень хотел, ну и вот. Не хотите ко мне прислушиваться — садитесь в лужу, bon voyage.

У этого явления есть название: эффект Рингельмана. В ИТ мы знаем его следствие, известное как Закон Брукса:

«Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».

Эффект Рингельмана формулируется так:

«Личная продуктивность отдельных членов группы снижается по мере роста численности группы»

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

В исследованиях Рингельмана общая продуктивность группы уже на 5 участниках составляет только 3.5 (считая эталонную продуктивность каждого в отдельности за 1), а после 7 практически перестает расти, застывая на отметке 3.92.

Обычно эффект объясняют двумя причинами: "социальной ленью" и потерей координации.
Если мы видим, что над той же задачей работает кто-то ещё, мы уже не так сильно вкладываемся. Это "социальная лень" или "социальное бездействие".

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

Что тут можно сделать?

Брукс предлагал выстраивать группы вокруг признанного лидера и эксперта, по типу операционной бригады (всегда есть главный хирург, который делает операцию, остальные ему ассистируют).

Agile говорит, что команда должна быть не больше, чем можно накормить двумя пиццами (5-7 человек).

Исследования сообщают, что социальное бездействие ослабевает, если:
1. У людей есть общая разделяемая цель
2. Вклад каждого участника может быть идентифицирован и оценен
3. Люди чувствуют свою незаменимость

В целом, это вопрос мотивации.

А вот координация — вопрос технический, это "харды" организации работ. Сам Рингельман, кроме перетягивания каната, изучал ещё перетаскивание камней при помощи веревок и перемещением тележек мускульной силой (он вообще занимался организацией работ в сельском хозяйстве, и работал примерно в одно время с Тейлором и Гастевым). Измеряя силы, прикладываемые работниками к камню, он выяснил, что основная проблема в синхронизации усилий: то один начинает не вовремя, то тянут в разные стороны. Про мотивацию он как раз не писал.

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

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

Хм, кажется, опять получилось про анализ и архитектуру.

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

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

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

Вопросы:
* Для чего? (Вариант: что будет дальше?)
* Какое обратное действие?
* Кто? (роль; есть ли дополнительные признаки и условия?)
* Когда? (ограничения на допустимые состояния; триггеры автоматического запуска)
* Где? (какое устройство? что вокруг?)
* С кем? Кто рядом?
* Сколько? (любой численный показатель, который может описывать процесс)
* Как? (какие есть альтернативные способы выполнения действия и какие ограничения?)
* Какой? (особенности, классификаторы и состояния объекта)
* Что нужно/может быть до начала действия? (в описании use case это нужно писать в "предусловия", но мало кто пишет)
* Что уменьшается/увеличивается в процессе? (например, при записи на курс уменьшается число свободных мест; у робота тратится заряд и увеличивается убранная площадь)
* Чем заканчивается действие? (Постусловия, что будет создано? что поменяется? есть ли триггер на прерывание длительного действия?)
* Что может помешать выполнить действие?
* Что будет, если каких-то объектов 0,1,N? (Например, один студент записывается на курс. Может ли на курс записаться N студентов одним действием? А N студентов параллельно?)

Можно добавить вопросы безопасности:
* Чем система может навредить при выполнении действия?
* Какую информацию нельзя показывать/изменять при выполнении действия?
* Что может сделать злоумышленник при выполнении действия?

На фичу из предыдущего поста могут навести вопросы "Кто рядом?" (дети, домашние животные), "Что было до?" (что от них могло остаться на полу?), "Что может помешать?", "Чем система может навредить?"

Пятничный пост (не очень серьезный)

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

Вот, например, пирамида Дилтса (не путать с Маслоу и Минто!).

Её уровни:

1. Окружение. Кто вокруг, контекст, использующая система. От кого мы зависим, чьё мнение про систему для нас важно. На кого мы хотим повлиять.

2. Поведение. Это функции системы. Что система делает, как ведёт себя в зависимости от реакции пользователя/внешней среды.

3. Способности (capabilities) — возможности системы. Что система потенциально может делать (и что ей сделать будет трудно). Тут связь с архитектурой.

4. Ценности и принципы. Продуктовые параметры. Что для нас, хорошо, и что — плохо? На что мы никогда не пойдем? Что мы будет поддерживать изо всех сил? Что для нас ценно, а что неважно? (Важны ли данные пользователя, или их можно потерять? Важна ли безопасность? Важна ли социальная составляющая, и какие именно взаимодействия мы хотим поддерживать? Исходя из чего мы выбираем, что делать?)

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

6. Миссия — зачем мы делаем систему? Какое влияние хотим оказать на мир?

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

Вопрос "кем является система" для меня связан с вопросом "какие социальные взаимодействия поддерживает система"?

Проще говоря, как у вас люди общаются друг с другом через систему.

В российской практике профессиональной ориентации очень часто применяют типологию профессий Е.А.Климова: вот эти вот ЧЕЛОВЕК-ПРИРОДА, ЧЕЛОВЕК-ТЕХНИКА, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, ЧЕЛОВЕК-ЧЕЛОВЕК. Вы, возможно, помните из школы. За пределами пост-советских стран такая типология, правда, не встречается.

Так вот — работа с информационными системами, это, конечно, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, но в современных реалиях это почти всегда ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА-ЧЕЛОВЕК. Вы через систему взаимодействуете с другими людьми опосредовано. Система может вам помогать это делать, а может мешать или диктовать свои способы взаимодействия, часто неестественные.

У Джоела Спольски, которого я считаю одним из лучших авторов по проектированию интерфейсов, есть книга: User Interface Design For Programmers, в русском переводе Руководство по UI дизайну для программистов (тут сразу pdf).

Это 2001 год, а примеры там вообще из 90-х. Но принципиально ничего не поменялось... в интерфейсах. А вот в проектировании поменялось — теперь мы почти всегда проектируем социальные системы. Джоел написал об этом в 2004: It’s Not Just Usability, перевод: Не юзабилити единым, а ещё раньше в 2003: Building Communities with Software, перевод не нашел.

Один из примеров — интерфейс Napster (если вы помните такое приложение, кхе-кхе). Интерфейс был ужасен. Программа работала только на Windows. Это было одно из самых популярных приложений в мире. В 2000 году Napster создавал от 40 до 60% трафика в частных сетях и в сетях университетов.
Если вы делаете то, что нужно людям — они будут мириться с любым интерфейсом. Сейчас, наверное, можно привести в пример красноглазые интерфейсы в области крипты.

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

Есть масса приложений с красивыми интерфейсами, совершенно не учитывающими — как именно люди общаются и взаимодействуют в каком-то процессе. Школьные дневники. Запись ко врачу и хранение истории приемов. Социальные сети (нечеловеческий LinkedIn чего стоит!). Системы приема докладов на конференции. Системы управления задачами и документацией.

Джоел приводит в пример свой FogBugz — багтрекер, в котором люди действительно работали над исправлением дефектов, в отличие от других систем, которые "was never getting used, because it did not align with the way people wanted to work together" (кстати, не доверяйте переводам, там эта фраза переврана до противоположного смысла). Про FogBugz не знаю, не видел, а Trello, разработанная в той же компании, конечно, почти эталонная по интерфейсу легковесная система управления задачами.

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

В принципе, можно было бы отмахнуться от рассуждений какого-то там очередного программиста-предпринимателя. Ну он же не дизайнер и не психолог, что нам втирает. Если бы не одно "но": Джоел Спольски — создатель StackOverflow. Социального сервиса, который собрал крупнейшее сообщество разработчиков и в определенном смысле перевернул способ обучения програмиированию и разработки. Я бы прислушался.

Примеры социальных функций в приложениях и сложностей с ними:

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

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

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

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

2) баны. В одном сообществе были личные баны — один пользователь мог забанить другого и не видеть его постов и комментариев. В какой-то момент забаненному перестали показывать комментарии забанившего, а стали показывать плейсхолдер <здесь комментарий от пользователя, который вас забанил>. Что тут началось! Люди обнаружили, что кем-то забанены, начинают выяснять — кем? Кто меня забанил? Ах, этот! Вот ведь гад!

Сообщество бурлит, число взаимных банов (в ответ) растёт, связность падает, кто-то решил вообще удалиться... А всего-то маленькая функция!

Джоел упоминает множество non-features, функций, которых нет в продукте. Для аналитика это очень странно — некоторые стандарты даже напрямую запрещают писать "отрицательные требования" — чего не должно быть в системе. А вот с точки зрения требований к социальной системе это может быть критически важно!

Наткнулся на интересный набор паттернов обмена сообщениями от Microsoft Azure. Так как это паттерны, реализовать их можно на любых технологиях.

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

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

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

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

Итак, паттерны:

* Асинхронный запрос-ответ.
В общем, простая идея про запросы, длительность обработки которых на сервере может занять больше, чем 100 мс, а очереди/брокера у вас нет или вы не хотите их использовать — и вы используете поллинг. Первым запросом запускаете процесс на сервере, а сервер возвращает 202 (Accepted) и ссылку, которую нужно поллить. Клиент регулярно ходит по этой ссылке и проверяет — выполнился ли запрос. Пока он не выполнен — сервер возвращает 200 (OK). Когда результат готов — 302 (Found) и переадресует на место, где лежит результат.
Как вариант, тут можно было бы использовать WebHook, но далеко не все клиенты поддерживают вызовы к ним — технически или по соображениям безопасности.

* Квитанция (claim-check).
Если вы собираетесь передавать большой объем данных, имеет смысл не загружать систему передачи (например, брокера или очередь), а выслать "квитанцию" с токеном, по которому клиент сможет забрать ответ из хранилища статических данных. Также паттерн можно использовать, когда нужна дополнительная защита, чтобы чувствительные данные не проходили через брокер/очередь/прокси и т.п. Ну и в принципе неплохо бы защищать статику каким-нибудь токеном, чтобы не было ситуаций с утечкой документов, доступных по прямым адресам без всякой проверки — про это следующий паттерн.

* Valet Key — не знаю, как перевести на русский, видел автоматический перевод "ключ камердинера", но не встречал такого употребления в живой среде. Это как раз токен из предыдущего паттерна: когда вы получаете статический ресурс, если он не должен быть общедоступным — защищайте его токеном. То есть, клиент сначала запрашивает ресурс у приложения, приложение отдает ссылку на ресурс + токен (либо токен зашит прямо в URL), и передает токен хранилищу. Хранилище обрабатывает запрос к ресурсу только с токеном — так гарантируется, что запросивший клиент — именно тот, кому выдали разрешение, а ещё можно ограничить действие токена по времени.
Этот паттерн также описан в книге O'Reilly 'Cloud Architecture Patterns' — хотя остальные паттерны в ней в основном низкоуровневые.

Где можно использовать эти паттерны? Например, при запросе большого отчета, который относительно долго формируется. "Заказать" формирование мы можем через асинхронный запрос и поллинг, либо через очередь запросов, потом получим "квитанцию" с токеном доступа, а сам сформированный отчет ляжет в файловое хранилище. Файловое хранилище отдаст готовый отчет только клиенту, предъявившему квитанцию с токеном. Про истечении времени жизни токена отчет будет удален.

UML умер, но никто этого не заметил?

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

Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)

Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.

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

Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".

Интересными мне показались два поинта в статье:

1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.

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

Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.

В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.

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

А вы применяете UML? Насколько часто, и что именно из него?