🐣 #1. Проблема курицы и яйца в проектировании

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

👉 Если начать с требований, то архитектура может оказаться недостаточно гибкой для будущих изменений. Другой вариант: часть требований может оказаться нереализуемой в условиях ограничений сложившегося ИТ-ландшафта, а усилия, потраченные на детальное документирование таких требований, окажутся напрасными.

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

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

Так что, курица и яйцо появились одновременно? 🤔

🪒 #2. Парадокс брадобрея и его аналогии в IT-системах

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

👉 Этот классический парадокс, в частности, иллюстрирует проблемы самоприменимости логических утверждений. В IT-системах и их разработке подобные ситуации тоже просматриваются.

К примеру, проводится ли статический анализ кода (SAST) системы, которая выполняет такие проверки во время CI/CD? Описан ли в цифровом репозитории систем сам репозиторий? Выполняется ли архитектурный контроль над системой, на которую возложены эти обязанности? Есть ли гарантии, что обновляется система, которая контролирует обновления ПО в периметре компании?

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

Так, погодите, брадобрей вообще никогда не брился? 🤔

🧠 #3. Парадокс Сократа для системных аналитиков

"Я знаю, что ничего не знаю." Это, пожалуй, одно из самых известных изречений древнегреческого философа Сократа. Фраза кажется противоречивой, ведь как можно знать о своём незнании?

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

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

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

Подождите, выходит, синдром самозванца это признак адекватной самооценки? 🤔

🛠️ P.S. На этом парадоксе, пожалуй, всё. Неделя была парадоксально долгой, целых 6 дней. Ну, вы меня поняли. 😉

Друзья! Уже совсем скоро стрелки часов укажут на полночь, а значит наступит долгожданный 2025 год.

Пусть Новый год принесёт вам новые перспективы, идеально работающие системы и предсказуемых смежников, а Дедушка Мороз 🎅 подарит документацию, которая сама себя пишет. Безграничного частья, слепой удачи, железного здоровья и побольше релизов без багов новом году! 🎇🍾🥂

Ну что ж, праздники прошли. Лично я возвращаюсь в рабочий ритм довольно спокойно. Должно быть, это из-за того, что за минувшие дни мне удалось подзарядиться. Хотя всё прошло не без неожиданностей.

Поломка бытовой техники, пожар в одной из квартир в нашем доме, внеплановые посещения стоматолога и ещё несколько досадных событий перед Новым годом. Видимо, 2024-й год никак не хотел сдаваться без боя. Но 2025-й наступил. Будущее всегда побеждает; хотя бы в этом можно быть уверенным.

Желаю всем хорошей рабочей двухдневной😎 недели.

Буквально несколько минут назад наткнулся на очередной пост про пет-проекты для системных аналитиков. Основной посыл, как водится, в том, чтобы таким способом помочь новичкам без опыта себя показать потенциальному работодателю.

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

Голосуем:
🔥 — неплохая идея.
🗿 — для специалистов с опытом не актуально.

🛰 MVP и его основные виды

Сегодня хочу затронуть тему MVP (Minimum Viable Product, то есть минимально жизнеспособный продукт).

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

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

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

#статьи #продукт #термины

https://telegra.ph/MVP-and-its-main-types-01-21

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

Если не знакомы с этой историей, то рекомендую посмотреть прикреплённое видео. Хотя нет, посмотреть стоит в любом случае.😜 В общем, приятного просмотра!

#жиза #юмор #видео #нетленка

https://www.youtube.com/watch?v=G3e2NI052Iw

Сегодня хочу поделиться информацией (вдруг кому-то будет актуально) о предстоящем конкурсе "Цифровой марафон-2025". Из области системного анализа тут что-то сложно найти, но это неплохой повод подтянуть свои цифровые навыки, освоить один из языков программирования и узнать что-то новое про AI. Участие бесплатное, победителей ждёт награда🏆💰.

Все детали 👉 https://it-marathon.21-school.ru/

#мероприятия #сбер #ai #программирование

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

Столкнувшись с этим вопросом в очередной раз, я решил навести в нём порядок и структурировать знания в виде ментальной карты (mind map). Наверняка, обошлось не без субъективизма, но обозреть стили взаимодействия точно стало проще.

#интеграции #сервисы #архитектура #майндмап

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

Знаете, у этой компании в принципе часто всё криво: то одно не работает в Личном кабинете, то другое. Поэтому это либо очередной их баг, либо знак свыше, что пора вернуться в разработку на .NET 🤣

#юмор

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

А вам приходилось в условиях забитого созвонами календаря что-то пытаться делать в параллель?

#юмор #жиза

⏳ Минутка философии

Сегодня было ветрено. И пока я наблюдал за тем, как волны обрушиваются на берег🌴 одна за другой, мне в голову пришли интересные мысли и метафоры.

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

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

Мораль. Порой мы сталкиваемся со срочными и одновременно уникальными задачами, для которых у нас не хватает знаний и нет наработанной практики. В такой ситуации можно, наверное, сразу навалиться на такого рода задачу, изучая всевозможные материалы с риском выбиться из сил, захлебнуться и потонуть. Но, пожалуй, иногда стоит просто перестать куда-то бежать, взять паузу 🍹 и – даже больше! – отступить на шаг-другой назад, осмотреться и дать волнам 🌊 немного времени, чтобы они принесли полезные знания и идеи.