🐲 Переходные требования и где они обитают

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

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

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

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

Как это будет происходить, сообщу чуть позже. В общем, буду держать вас в курсе!

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

P.S. Недавно провёл небольшой опрос среди действующих аналитиков. Отвечая на вопрос, какие виды требований бывают, никто из респондентов не назвал переходные требования👀

#требования #анонсы

🔥🔥🔥 О пользе прогреваний ♨️

В мире высоких нагрузок и быстрых приложений даже самые умные алгоритмы требуют разминки 🏋️‍♂️. Это помогает системе набрать рабочую скорость 🏃🏽 и встретить пиковую нагрузку во всеоружии. Такие "разминки" получили название прогревов. Рассмотрим наиболее популярные из них.


😀 Прогрев виртуальной машины (VM Warming, или JIT Warming)

Процесс, при котором виртуальная машина (например, JVM или .NET CLR) постепенно компилирует наиболее часто используемые участки кода в машинный код с помощью JIT-компиляции (Just-In-Time). В результате приложение со временем начинает работать быстрее и отзывчивее. Правда, производительность во время прогрева может меняться неравномерно, и пиковая скорость достигается не всегда мгновенно — но в целом техника действительно ускоряет долго работающие программы.


😀 Прогрев кэша (Cache Warming)

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


😀 Прогрев сессии пользователя (Session Warming)

Метод продления активной сессии без повторного входа. Мобильные приложения и веб‑сервисы периодически отправляют серверу сигнал (ping), чтобы сервер не закрывал сессию из-за таймаута. Обычно сессия просто продлевается, и клиент продолжает использовать тот же идентификатор. В некоторых системах при этом может выдаваться новый токен, клиенту может возвращаться заголовок Set-Cookie с новым значением Expires или что-то иное, но, при этом, главной задачей является сохранение пользователя в системе, пока он активен.


😀 Прогрев индекса (Index Warming)

Техника для баз данных и поисковых движков. Индексы — это структуры данных, ускоряющие поиск. Их прогрев означает предварительную загрузку индексных данных в оперативную память, чтобы первые запросы после запуска системы обрабатывались максимально быстро. Часто для этого используются специальные команды (например, LOAD INDEX INTO CACHE в MariaDB) или прогревочные запросы (искусственные запросы, которые заставляют систему загрузить в память данные из критичных таблиц). Прогрев индекса фактически является частным случаем прогрева кэша, но применительно к кэшу СУБД.

#термины #данные #проектирование #архитектура

🎭 Пословицы в IT: мудрость, проверенная временем

Ну что, немного похулиганим? Предлагаю вспомнить народную мудрость, но уже в новом исполнении. Специально ко Дню смеха 🤣

🟢Один в поле не кластер.
🟠Мал DDR, да дорог.
🟢Не пойман — не баг.
🟠Хочешь Miro — готовь VPN.

🟢Фичу тогглом не испортишь.
🟠Тише едешь — меньше троттлинг.
🟢Меньше багов — крепче спишь.
🟠Поспешишь — саппорт насмешишь.

🟢Не всё то денежка, что кэш.
🟠На чужой API рот не разевай.
🟢Бэкап познаётся в беде.
🟠Лучше Kafka, чем никогда.

🟢Первый код комом.
🟠Язык до стейкхолдера доведёт.
🟢Чем дальше влез, тем больше логи.
🟠Метрика не воробей: вылетит — не поймаешь.

🟢Кто рано встаёт, pull request подаёт.
🟠Что написано пером, то не вырубишь hotfix'ом.
🟢Без труда не выкатишь и фичу из спринта.
🟠Волков бояться — на собес не ходить.

🟢Большому серваку большое облако.
🟠Серверная стойка недалеко падает.
🟢Лучше синица в руках, чем блэкаут в ЦОДе.
🟠В гостях хорошо, а под админом лучше.

🟢Синк скрам-мастера боится.
🟠Терпение и труд бэклог перетрут.
🟢Одна голова хорошо, а две — команда.
🟠Делу — время, дедлайну — час.

Друзья, тоже посетило вдохновение? Тогда пишите свои шедевры в комментариях.
👇

#юмор

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

P.S. Если что, имею водительское удостоверение категорий "B", "B1", "M". 16 лет водительского стажа. Предложения о работе направляйте в личку 🙄

#юмор

⚡ CodeFest 16: а поговорить?

Спешу поделиться отличной новостью!

✅Этой весной, 30–31 мая, в Новосибирске пройдёт ежегодная ИТ-конференция CodeFest. Это уже само по себе замечательное событие, но есть и ещё одна приятная деталь.

✅Программный комитет утвердил меня в качестве спикера трека "Архитектура и анализ". Я выступлю с докладом на тему: «AS IS → TO BE: минимизируем риски перехода».

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

#анонсы #события #выступления #требования #проекты

❌ Ничего не произошло и не произойдёт

Эта памятная доска прекрасно иллюстрирует идею, что иногда полезно в спецификации/ТЗ явно прописывать то, что точно не стоит ожидать после реализации ☝️🙄

Для этих целей стоит предусмотреть отдельный раздел документа, назвав его, например, "Ограничения и допущения".

Но зачем вообще описывать то, что делать не планируется? Я выделяю две основные причины.

1️⃣ Так вы жёстко выстраивание рамки, препятствующие расползанию скоупа (scope creep) — неконтролируемого расширения уже зафиксированного объëма работ. При возникновении недопонимания в будущем (смежники и заказчики порой такие забывчивые...🙈) всегда можно будет ссылаться на зафиксированные рамки.


2️⃣ Как это ни парадоксально, такой способ стимулирует другие стороны более вдумчиво относиться к согласованию документа. Именно в этот момент могут выявиться ранее не озвученные требования, которые "выстрелили" бы позднее.

В общем, как ни крути, сплошная польза😎

#требования

😁😆😁 на выходных закончить чек-лист по переходным требованиям. Заодно разобраться со странностями в Word.

🤸‍♀️ "Бесполезные" слова JSON Schema

Сегодня хочу рассказать о нескольких ключевых словах JSON Schema, польза которых может быть на первый взгляд сомнительной. На конкретных примерах, хоть и выдуманных🙄, убедимся, что в жизни эти ключевые слова вполне могут пригодиться.


✅ multipleOf
Позволяет ограничивать кратность числовых значений заданному числу. Если по-простому: проверяемое значение должно без остатка делиться указанное вами. Примеры:

🔘Бронирование переговорных комнат доступно на любую продолжительность в минутах с шагом в 15 минут (15 мин, 30 мин и т.д.).

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "minutes" : {
      "type": "integer",
       "multipleOf": 15
    }    
  }
}

😀Общая площадь квартиры должна иметь точность до 1 знака после запятой.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "area" : {
      "type": "number",
      "multipleOf": 0.1
    }    
  }
}

🔘Цена должна иметь точность до 2 знаков после запятой. Дополнительно явно учтём, что величина должна быть строго положительной.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "price" : {
      "type": "number",
      "multipleOf": 0.01,
      "minimum": 0,
      "exclusiveMinimum": true
    }   
  }
}

🔘Заказ на производство ПЭТ-бутылок ограничен ассортиментом тары с ёмкостью в 0.5л, 1.0л, 1.5л, и 2.л. Значит значение должно делиться на 0.5 с дополнительными ограничениями на диапазон.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "capacity" : {
      "type": "number",
      "minimum": 0,
      "exclusiveMinimum": true,
      "maximum": 2.5,
      "exclusiveMaximum": true,
      "multipleOf": 0.5
    }
  }
}

😫 const
Ограничивает значение поля единственным значением. Формально использование const эквивалентно использованию enum с одним единственным значением, но const позволяет выстраивать более гибкие условия. Пример:

🔘Роль пользователя должна строго соответствовать значению "seller" либо "cashier", хотя ролевая модель может предусматривать больше доступных вариантов.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "role" : {
      "type": "string",
      "oneOf": [
        {"const": "seller"},
        {"const": "cashier"}
      ]
    }
  }
}

✅ if-then-else
Позволяет задать условия проверки полей. Например, мы можем проверить значение и в зависимости от результата проверки потребовать выполнение других условий. Пример:

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

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    
    "order_status": { "enum": ["pending", "processing", "paid"] },
    "payment_details": {
      "type": "object",
      "properties": {
        "account_number": { "type": "string" },
        "amount_paid": { "type": "number" }
      },
      "required": ["account_number", "amount_paid"]
    }
  },
  "if": {
    "properties": { "order_status": { "const": "paid" } }
  },
  "then": {
    "required": ["payment_details"]
  },
  "else": {}
}

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

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

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name" : {
      "type": "string",
      "not": { "enum": ["admin", "root", "guest"] }
    }
  }
}

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

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "minLength": 1,
      "not": { "pattern": "^\\s*$" }
    }
  }
}

#проектирование #интеграции #сервисы #форматы

Ⓜ M-shaped: расширяем словарный запас

Наверняка многие из вас слышали, что нужно стремиться стать T-shaped специалистом. Сам я тоже часто сталкивался с этой идеей и считал её вполне обоснованной. Но буквально сегодня услышал, что теперь гораздо правильнее быть M-shaped 🙈

Что это вообще означает? Думаю, пересказывать саму концепцию не лучший выход. Проще сразу поделиться полезными ресурсами👇

🙂Если хотите быстро познакомиться с этой новой моделью, почитайте вот эту статью: https://www.rbc.ru/education/07/11/2025/6905df819a7947dd6c6fb913

🙂Но если интересуетесь деталями и личным опытом, рекомендую посмотреть это видео: https://youtu.be/ExvUFrHuBHM?si=xP4QCkSW01oVG2dG
Мне оно очень понравилось, многое стало понятно, и точно есть над чем поразмыслить.

#карьера #статьи #видео

🔂 Границы системы: иллюзия покоя и нескончаемый поток работ

Что происходит, когда компания принимает решение прекратить развитие функционала какой-нибудь информационной системы? Казалось бы, жизнь становится проще: новые фичи не появляются, нагрузка на команду снижается, можно расслабиться... Ан нет!

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

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

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

☝️ Отсюда мораль: заморозка функциональности вовсе не означает статику, а границы системы — это не предел, а источник постоянных задач.

Знакомо? Если да, поделитесь в комментариях своим опытом и впечатлениями.

#системныйподход

☠ История про 12000 часов, или как угробить компанию

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

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

Заинтриговал? Тогда рекомендую обратиться к отрезвляющей 👉 статье

#методыуправления #статьи

🌭 Иллюзии, или Как я дважды наступил на одни и те же грабли за одну неделю

На прошлой неделе на работе я решил, что мне не хватает адреналина, и дважды подряд наступил на одни и те же грабли🧹

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

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

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

Выяснилось:
1⃣в зависимости от кейса экраны с продуктами, по которым предполагаем клики, разные. Всего возможно 2 варианта (и на том спасибо);
2⃣данные для них надо тянуть из двух разных сервисов;
3⃣у каждого из сервисов своя, уникальная и неповторимая классификация продуктов.

Но почему? Классификацию смежные команды вводили довольно давно для своих локальных задач, и их "номенклатуры" ложится на нашу примерно так же, как попытка зарядить старенький iPhone через USB-шный шнурок коллеги.

Стадии принятия неизбежного прошли по классике: гнев ("Как так?!"), отрицание ("Этого не может быть, у нас же есть стандартизованная типизация...") и торг ("А может, всё-таки можно как-то..?").

Торг, кстати, провалился с треском. Пришлось выкручиваться самому и придумывать варианты 🛠️ на своей стороне.


🧐 Мораль

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

А раз так, то пока вы не докопались до сути и не подтвердили всё сами, заверения смежников о том, что "это есть" — это лишь иллюзия.

👉 Кстати, на тему иллюзий могу порекомендовать статью на Хабре. Букв много, но интересно.

#статьи #психология #мозг