🛰 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 🤣

#юмор

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

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

#юмор #жиза

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

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

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

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

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

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

Так вот. Пару часов назад сходил на Почту, чтобы поинтересоваться, не приходило ли мне что-то. На самом деле я рассчитывал, что отправление уже меня заждалось, поскольку 12-го февраля мне на e-mail написали о факте отправки.

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

В отделении действительно пылился конверт ✉ , мне его сразу же отдали, после чего я поинтересовался, почему в приложении пусто (у них же есть фича с получением уведомления о том, что тебе кто-то что-то отправил). На это мне ответили, что в поле получателя была указана моя фамилия и инициалы, а не полные ФИО, и это не позволяет автоматически определить получателя.

Я удивился. Мои ФИО и адрес в профиле в Почте России указаны, почему бы не "догадаться" по адресу, полной фамилии и инициалам, что я это я? А если бы мне по "электронке" не сообщили, то я, получается, вообще мог бы не узнать, что меня ждёт корреспонденция?..
P.S. Если в подписчиках есть кто-то, причастный к почтовым сервисам, возьмите в бэкложек себе эту задачку, пожалуйста.

<|°_°|> Вы ещё не уволились? Тогда мы идём к вам

Вопрос о том, заменит ли ИИ системных аналитиков или других специалистов, уже несколько лет будоражит умы. Но тут появился повод посмотреть на вопрос в несколько ином ракурсе. На Хабре вышла статья (ссылка) о том, что в МФТИ разрабатывают платформу на базе ИИ 🤖, которая позволит предсказывать увольнение сотрудников. Для этого предполагается как-то отслеживать производительность, учитывать стаж и другие параметры.

После прочтения у меня осталось какое-то тягостное впечатление. В голове возникают довольно явные параллели с сюжетом киноленты "Особое мнение" с Томом Крузом в главные роли: ты ещё не совершил преступление принял решение уволиться, а тебе уже замену ищут… И это на фоне и так нестабильной ситуации с занятостью и сокращениями из-за внедрения технологий искусственного интеллекта (ссылка на статью по теме, кстати, эта статья тоже создана ИИ...).

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

#ai #4ir

💡 Забота о клиенте, или снова про AI

В текущем проекте задействуется LLM для принятия решения о дальнейших шагах в программной логике. Если не вдаваться в подробности, то выглядит так. Ты передаёшь в языковую модель запрос клиента и дополнительную информацию, включающую список доступных вариантов: <мнемоника; при каких условиях надо предпочесть её>, а модель должна сделать выбор одного варианта. Это своего рода switch-case из языков программирования, только на стероидах.

Так вот. Одна из моделей, на которых тестировал, напрочь отказывалась выбирать вариант "abort_scenario", хотя по описанию именно он лучше всего подходила под ситуацию. Модель с упорством выбирала другой вариант – "make_decision". В какой-то момент меня осенило: надо прямо спросить модель (это же диалоговая штука): почему она выбирает именно это? И, когда я пойму логику выбора, смогу что-то с этим сделать.

Каково же было моё удивление, когда я увидел объяснение.

Оказалось, что модель считала, что при выборе "abort_scenario" клиент вообще не получит ответа на свой запрос и останется неудовлетворённым (к слову, это не так, но модель не знала того, что предполагалось делать потом). Модель целенаправленно выбирала "make_decision", чтобы данный запрос был передан в работу другому специалисту (видимо, человеку), который смог бы уточнить у клиента его потребность и помочь ему.

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

#ai #4ir #программирование

Что-то в этом есть😅

#юмор #жиза

👀 Видишь легаси? Нет. И я не вижу, но он есть.

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

📟 Средства связи. В Японии до сих пор пользуются факсами. Заметьте, в стране, которую многие ассоциируют с качественными автомобилями, роботами и другими передовыми разработками. Но, как говорится, не факсами едиными. Британские врачи всё ещё активно пользуются пейджерами, словно герои из "Доктора Хауса" или "Скорой помощи".

💾 Носители информации. Для создания резервных копий данных в мире по традиции используется магнитная лента. И буквально на днях выходила новость, что одна компания обнаружила, что их регулярно записываемые бэкапы годами не проверялись на возможность восстановления. Хорошо, обошлось без жертв. Ну а как насчёт типов видов носителей? А вот так. Метрополитен Сан-Франциско до сих пор использует дискеты в своей системе управления поездами, а отказываться от них планируется только в середине 2030-х. Удивляет? Меня точно удивляет. Но ещё больше удивляет то, что, как оказалось, на немецких фрегатах типа "Бранденбург", предназначенных для обнаружения и борьбы с подводными лодками противника, до сих пор используются 8-дюймовые дискеты. Ещё раз: не 3.5" и даже не 5.25", а 8"!

💻 Программное обеспечение. Легаси-системы довольно широко используются в промышленности. На своей первой работе, кстати, я удивлялся устойчивой практике использования языка C (именно "Си", никаких "плюсов") для реализации HMI-систем, работающих под Windows XP. И, судя по прочитанному на просторах всемирной паутины, ситуация за минувшие годы кардинально не изменилась.

👨‍💻 Языки программирования. Наверняка многие слышали, что язык Fortran до сих пор имеет широкое прикладное применение в задачах, связанных с математическими расчётами и наукой. Но, выяснилось, что "старичок" COBOL тоже в строю. Именно на нём на Западе написана куча систем в сфере финансов. Приложения, обрабатывающие транзакции, операции по счетам и ведущие расчёты доходности сложных финансовых инструментов – это всё историческая "вотчина" языка COBOL.

Если у вас есть что добавить по теме, обязательно делитесь в комментариях 👇

#любопытное #программирование #быловремя

Сегодня мир отмечает необычный праздник — День числа "пи". Это событие посвящено одной из самых известных математических констант — числу π, которое приблизительно равно 3.14 (поэтому и 14-е марта).

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

Сегодня открыл для себя "съедобные" названия элементов UI для разных типов меню. Гамбургер, дёнер, бенто, кебаб и фрикадельки — ну что может быть лучше? 😋

#uxui #любопытное #термины

Разбирая диаграммы последовательности, время от времени наблюдаю 3 повторяющиеся паттерна странного использования фреймов (фрагментов). Вот они.

1️⃣ Фрейм alt используется для опциональных условий. Это довольно частая ситуация. Возможно, авторы не знают или не понимают, зачем использовать opt, когда есть alt.

2️⃣ Во фрейме alt первая секция полностью пропускается. PlantUML, конечно, позволяет выполнить этот фокус, но вот зачем? Возможно, так хотят добиться выравнивания по левому краю всех проверяемых условий?

3️⃣ Вообще не используется break. Вместо этого может использоваться opt или alt. Авторы, видимо, полагают, что если довести стрелку до пользователя, то сценарий закончится.

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

#визуализация #plantuml #кейсы

📋 Подводные камни YAML

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

Ситуацию быстро локализовали, а результат вскрыл факт того, что YAML не так уж и прозрачен. Полученный тогда опыт и другие неочевидности, собранные из открытых источников, я попробовал собрать в кучу. Надеюсь, будет полезно. А вот и сама "куча" 🤭: https://telegra.ph/Pitfalls-of-YAML-03-27.

Кстати, я ранее делал пост со сравнением ряда текстовых форматов. Там YAML тоже есть, так что рекомендую.

#форматы #статьи #гайды

В этом году, насколько я могу судить, искусственный интеллект переживает очередную волну интереса. И если раньше всё крутилось вокруг ML, то в последнее время всё чаще в фокусе находятся AI-агенты.

В свете этого хочу поделиться вышедшим в этом году документом (в оригинале — whitepaper) от компании Google. Это достаточно понятное чтиво, которое позволит понять идею и принципы, на которых строятся AI-агенты.

Ссылка: здесь, ссылка для скачивания: здесь.

Для удобства в первом комментарии к данному посту 👇 размещу переведённую на русский язык версию. В целом неплохо, но в примерах на Python есть ляпы (может, ИИ переводил?👀), так что по необходимости рекомендую обращаться к оригиналу.

#книги #ai

Прочитал в одном профильном ТГ-канале новость о создании обширного глоссария для системных аналитиков с призывом пользоваться. Подумал, что это, наверное, неплохо. Да, с одной стороны, есть глоссарий в конце BABOK, но, быть может, у ребят больше уклон на технику?

И вот добрался я до оного (ссылка). Первое, что насторожило, это изображённый робот. Почему? Но этот вопрос стал проясняться, когда я при беглом пролистывании увидел термины: "дым-тест" 🚬, "загрузка баланса" 💰, "релиз-ноты" ♪♬. А чего только стоит красивое русское слово "рефайнмент"! В общем, рука-лицо…

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

Остаётся только вопрос: неужели нельзя было "причесать" созданный нейронкой текст? 🤷‍♂️ Даже если предположить, что это не нейронка, а условный гугл-переводчик, то от этого не легче.

📣 CodeFest 15 в Новосибирске

Друзья, спешу с новостью. Как вы, наверное, знаете, 31 мая – 1 июня в Новосибирске пройдёт 15-й по счёту CodeFest. А вот и сама новость: программа секции по системному анализу свёрстана. Поэтому, если кто-то ждал определённости, чтобы решить, идти ли на конференцию, то вот она 👉 https://15.codefest.ru/program/sa

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

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

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

Очередь (queue) и топик (topic, она же "тема") — это различные подходы к организации взаимодействия между системами.

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

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

📌 Что ещё стоит отметить.

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

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

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

#интеграции #архитектура #термины