Как называть очереди в брокерах
Слава пришла откуда не ждали. Вчера во внутренней группе для аналитиков коллега поделился артефактом СА с таким комментарием:
Из любопытства я порылся в приложенном документе (закину в комментарии к посту) и обнаружил в нём копию своего собственного документа, который я создал на одном из проектов в 2022 году.
Неповторимый, так сказать оригинал вот он: Правила именования топиков
Создавайте правила
Мало просто правильно назвать очередь или грамотно описать артефакт. Создавайте правила, описывайте стили, внедряйте принципы организации информации. Тогда больше шансов, что команда будет работать как команда, а не просто группа случайно собранных людей, каждый со своим неповторимым почерком.
#брокеры
Слава пришла откуда не ждали. Вчера во внутренней группе для аналитиков коллега поделился артефактом СА с таким комментарием:
Зашёл я в Инстаграм значит, а там в рилсах вот такой шаблон девушка раздает. Некоторые примеры наивные, но в целом как чек-лист о чем нужно/можно подумать аналитику наверное неплохо
Из любопытства я порылся в приложенном документе (закину в комментарии к посту) и обнаружил в нём копию своего собственного документа, который я создал на одном из проектов в 2022 году.
Неповторимый, так сказать оригинал вот он: Правила именования топиков
Создавайте правила
Мало просто правильно назвать очередь или грамотно описать артефакт. Создавайте правила, описывайте стили, внедряйте принципы организации информации. Тогда больше шансов, что команда будет работать как команда, а не просто группа случайно собранных людей, каждый со своим неповторимым почерком.
#брокеры
👍13❤2
Помощь ИИ в анализе и проектировании
Лично я пока не видел реальной помощи от ИИ в анализе, проектировании и в операционной части бизнеса электронной коммерции. Проблема, на мой взгляд, состоит в том, что ИИ на самом деле не понимает, о чем пишет/говорит/рисует. Он анализирует частотность токенов при обучении и их связь между собой. И чем длиннее ассоциативные цепочки токенов, тем «умнее» выглядит ИИ.
В екоме, несмотря на общие закономерности, бизнес-процессы сильно различаются от организации к организации. И выходит, что каждая решаемая аналитиком проблема — оптимизация, проектирование процессов или автоматизация — уникальна. ИИ просто неоткуда взять решение; он пытается собрать из грязи и палок то, что где-то видел. А там про другое. Да ещё без глубины смысла.
Поэтому взять и натравить ИИ на бизнес и сказать «проектируй» или «анализируй» — не получится. Те процессы наполовину состоят из «крысиных» чатиков и эмоциональной поддержки людей друг друга; поди это учти в моделях без интервью.
Думаю, со временем ситуация улучшится, когда ИИ сможет теснее наблюдать нас в естественной среде обитания; длина цепочек анализируемых токенов позволит таки создавать убедительные результаты и артефакты.
Пока максимум что ИИ может в разработке — это помогать писать типовые конструкции в коде, где много повторяющихся паттернов и экономить труд разработчиков на написание действительно сложных частей. Аналитики пользуются ИИ, чтобы набросать типовые sequence-диаграммы (которые потом всё равно допиливать руками до ума). В системах массового обслуживания, которые легко алгоритмизируются — например, колл-центры, кассы и так далее, — там ИИ действительно эффективно помогает.
Видели ли вы примеры в работе, где ИИ действительно блестяще справляется? Лучше людей? Поделитесь в комментариях, это интересно.
Лично я пока не видел реальной помощи от ИИ в анализе, проектировании и в операционной части бизнеса электронной коммерции. Проблема, на мой взгляд, состоит в том, что ИИ на самом деле не понимает, о чем пишет/говорит/рисует. Он анализирует частотность токенов при обучении и их связь между собой. И чем длиннее ассоциативные цепочки токенов, тем «умнее» выглядит ИИ.
В екоме, несмотря на общие закономерности, бизнес-процессы сильно различаются от организации к организации. И выходит, что каждая решаемая аналитиком проблема — оптимизация, проектирование процессов или автоматизация — уникальна. ИИ просто неоткуда взять решение; он пытается собрать из грязи и палок то, что где-то видел. А там про другое. Да ещё без глубины смысла.
Поэтому взять и натравить ИИ на бизнес и сказать «проектируй» или «анализируй» — не получится. Те процессы наполовину состоят из «крысиных» чатиков и эмоциональной поддержки людей друг друга; поди это учти в моделях без интервью.
Думаю, со временем ситуация улучшится, когда ИИ сможет теснее наблюдать нас в естественной среде обитания; длина цепочек анализируемых токенов позволит таки создавать убедительные результаты и артефакты.
Пока максимум что ИИ может в разработке — это помогать писать типовые конструкции в коде, где много повторяющихся паттернов и экономить труд разработчиков на написание действительно сложных частей. Аналитики пользуются ИИ, чтобы набросать типовые sequence-диаграммы (которые потом всё равно допиливать руками до ума). В системах массового обслуживания, которые легко алгоритмизируются — например, колл-центры, кассы и так далее, — там ИИ действительно эффективно помогает.
Видели ли вы примеры в работе, где ИИ действительно блестяще справляется? Лучше людей? Поделитесь в комментариях, это интересно.
🔥4👍2
Здоровый АйТи | Максим Каширин
На днях прочел перевод статьи Ицхака Адизеса https://premiummanagement.com/blog/ichak-adizes-chto-takoe-zdorovaya-kompania
В статье поднимается тема успешности стартапов:
- что для этого важно и необходимо для успеха,
- о важности внимания к проблемам своих клиентов,
- что нужно уделять внимание как краткосрочным так и долгосрочным перспективам
Но меня заинтересовала следующая мысль:
Организация, которая эффективно обслуживает своих клиентов, принимая во внимание заинтересованные стороны в краткосрочной и долгосрочной перспективе, является ЗДОРОВОЙ компанией.
В статье поднимается тема успешности стартапов:
- что для этого важно и необходимо для успеха,
- о важности внимания к проблемам своих клиентов,
- что нужно уделять внимание как краткосрочным так и долгосрочным перспективам
Но меня заинтересовала следующая мысль:
Организация, которая эффективно обслуживает своих клиентов, принимая во внимание заинтересованные стороны в краткосрочной и долгосрочной перспективе, является ЗДОРОВОЙ компанией.
Здоровая организация
Увидел размышления про здоровую организацию на канале Максима Каширина и прокомментировал пост — в лучших восточных традициях «комментарий на комментарий на комментарий» ☺️
Возьму на себя смелость уточнить уважаемого Адизеса:
Эффективно — означает, что бизнес приносит прибыль своему владельцу (для простоты будем иметь в виду только коммерческие организации).
Результативно — означает, что клиенты полностью удовлетворены качеством товаров и услуг.
Одно вообще не связано автоматически с другим, и я наблюдаю повсеместный перекос и болтания процессов из одной крайности в другую: то зарабатываем деньги и забываем про клиентов, то бежим облизывать клиентов и забываем зачем нужен бизнес. Поэтому: обязательно нужно мониторить оба набора метрик. Не контролировать. Мониторить, по необходимости делать выборочный контроль и при сбоях процессов — корректировать (управляющие воздействия).
Если коммерческая организация не приносит прибыль владельцу, то она бессмысленна. Если клиенты не удовлетворены— то в условиях рынка компания рискует лишиться клиентов.
В здоровой организации владелец компании делится прибылью со своими сотрудниками. Не только окладом, а еще и переменной частью, которая зависит от степени влияния сотрудника на конечный результат. Даже уборщица и офис-менеджер сильно влияют на результат; эту очевидную истину почему-то редко кто видит и регулярно переоткрывают Америку: а офис-то должен быть уютным! Вот уж сюрприз.
Я уж не говорю про продажников, аналитиков, разработчиков и прочих (мне проще про ИТ). Все они влияют на результат и в здоровой организации должны получать плюсы и минусы финансового результата.
У меня есть опыт выстраивания процессов, в которых сотрудники получают прибыль (или убыток) прямо пропорционально эффективности процесса. Это сложно, но дает потрясающие результаты.
Как считаете, жизнеспособна ли такая модель? Приходилось ли работать в процессно-ориентированном бизнесе или некоммерческой организации?
Увидел размышления про здоровую организацию на канале Максима Каширина и прокомментировал пост — в лучших восточных традициях «комментарий на комментарий на комментарий» ☺️
Возьму на себя смелость уточнить уважаемого Адизеса:
Организация, которая эффективно и результативно обслуживает своих клиентов…
Эффективно — означает, что бизнес приносит прибыль своему владельцу (для простоты будем иметь в виду только коммерческие организации).
Результативно — означает, что клиенты полностью удовлетворены качеством товаров и услуг.
Одно вообще не связано автоматически с другим, и я наблюдаю повсеместный перекос и болтания процессов из одной крайности в другую: то зарабатываем деньги и забываем про клиентов, то бежим облизывать клиентов и забываем зачем нужен бизнес. Поэтому: обязательно нужно мониторить оба набора метрик. Не контролировать. Мониторить, по необходимости делать выборочный контроль и при сбоях процессов — корректировать (управляющие воздействия).
Если коммерческая организация не приносит прибыль владельцу, то она бессмысленна. Если клиенты не удовлетворены— то в условиях рынка компания рискует лишиться клиентов.
В здоровой организации владелец компании делится прибылью со своими сотрудниками. Не только окладом, а еще и переменной частью, которая зависит от степени влияния сотрудника на конечный результат. Даже уборщица и офис-менеджер сильно влияют на результат; эту очевидную истину почему-то редко кто видит и регулярно переоткрывают Америку: а офис-то должен быть уютным! Вот уж сюрприз.
Я уж не говорю про продажников, аналитиков, разработчиков и прочих (мне проще про ИТ). Все они влияют на результат и в здоровой организации должны получать плюсы и минусы финансового результата.
У меня есть опыт выстраивания процессов, в которых сотрудники получают прибыль (или убыток) прямо пропорционально эффективности процесса. Это сложно, но дает потрясающие результаты.
Как считаете, жизнеспособна ли такая модель? Приходилось ли работать в процессно-ориентированном бизнесе или некоммерческой организации?
🔥3👍1
На выходных провели вместе с Натальей @start_in_IT тренинг «Китайская ручка» по систематизации знаний по разработке требований. Я выступал на тренинге в качестве заказчика, и это было очень необычно; как правило, я выступаю в роли аналитика либо архитектора.
Кратко впечатления можно охарактеризовать моими репликами Наталье в личке:
Во вторник на встрече с заказчиками начал рисовать такую вот диаграмму, чтобы пояснить где у нас на проекте сложности. Очень удобно обозначить две точки: (а) нет согласованных требований, потому что стейкхолдеры игнорируют наши запросы и предпочитают отмалчиваться (верификация) и (б) огромная вероятность сделать качественный продукт, который абсолютно не попадёт в ожидания заказчика (валидация).
Очень поучительно в игровой форме опробовать разные роли. На тренинге я хорошо почувствовал, как аналитики пытаются меня принудить согласовать низкоуровневые требования, которых я явно не выдвигал; вместо этого легко и приятно согласовывать требования бизнес- и менеджерского уровня. Потому что из позиции заказчика такие требования максимально понятны. Всё, что глубже — требует дополнительного когнитивного напряжения и возрастают риски добавить ненужные, на самом деле, ограничения.
Кратко впечатления можно охарактеризовать моими репликами Наталье в личке:
Мы (аналитики) в самом деле ерундой такой страдаем на проектах?
…
Я кое-что начинаю понимать насчёт [заказчика]
…
Кажется это не они странные
Во вторник на встрече с заказчиками начал рисовать такую вот диаграмму, чтобы пояснить где у нас на проекте сложности. Очень удобно обозначить две точки: (а) нет согласованных требований, потому что стейкхолдеры игнорируют наши запросы и предпочитают отмалчиваться (верификация) и (б) огромная вероятность сделать качественный продукт, который абсолютно не попадёт в ожидания заказчика (валидация).
Очень поучительно в игровой форме опробовать разные роли. На тренинге я хорошо почувствовал, как аналитики пытаются меня принудить согласовать низкоуровневые требования, которых я явно не выдвигал; вместо этого легко и приятно согласовывать требования бизнес- и менеджерского уровня. Потому что из позиции заказчика такие требования максимально понятны. Всё, что глубже — требует дополнительного когнитивного напряжения и возрастают риски добавить ненужные, на самом деле, ограничения.
👍5🔥3
Уровни архитектуры
В сложных проектах мне, бывает, нужно объяснить заказчику (и своей команде), как именно мы анализируем архитектуру предприятия и где проектируем информационные системы. Пока об этом говоришь на словах, попытка объяснить это — дохлый номер. Нужно показывать, включать схему архитектуры предприятия в артефакты проекта и время от времени на созвонах показывать её и уточнять, на каком уровне абстракции мы работаем в данный момент.
Мне нравится TOGAF, но всухую без подготовки этот фреймворк довольно сложно начать использовать; на практике помогает вот такая упрощенная схема. На ней показаны основные слои архитектуры и сущности, которые исследуется на этом уровне.
Опираясь на эту модель, довольно просто объяснить заказчику, почему нас интересуют причины, побудившие заказчика на этот проект. Здесь же можно указать, что входит в рамки анализа, а что останется за границами проекта. Например, «драйверы бизнеса» и «производственные линии» часто можно исключить безболезненно, а «бизнес-процессы» и «данные логические» — обычно обязательны для анализа.
Прикладываю ссылку на диаграмму в draw.io.
Рисуете ли вы диаграммы архитектуры предприятия на своих проектах? Какие уровни архитектуры отрисовываете?
#архитектура
В сложных проектах мне, бывает, нужно объяснить заказчику (и своей команде), как именно мы анализируем архитектуру предприятия и где проектируем информационные системы. Пока об этом говоришь на словах, попытка объяснить это — дохлый номер. Нужно показывать, включать схему архитектуры предприятия в артефакты проекта и время от времени на созвонах показывать её и уточнять, на каком уровне абстракции мы работаем в данный момент.
Мне нравится TOGAF, но всухую без подготовки этот фреймворк довольно сложно начать использовать; на практике помогает вот такая упрощенная схема. На ней показаны основные слои архитектуры и сущности, которые исследуется на этом уровне.
TOGAF, аббревиатура от The Open Group Architecture Framework. Фреймворк архитектуры предприятия определяет, как создавать и применять архитектуру предприятия; нас в данном случае интересует системный подход к исследованию архитектуры.
Опираясь на эту модель, довольно просто объяснить заказчику, почему нас интересуют причины, побудившие заказчика на этот проект. Здесь же можно указать, что входит в рамки анализа, а что останется за границами проекта. Например, «драйверы бизнеса» и «производственные линии» часто можно исключить безболезненно, а «бизнес-процессы» и «данные логические» — обычно обязательны для анализа.
Прикладываю ссылку на диаграмму в draw.io.
Рисуете ли вы диаграммы архитектуры предприятия на своих проектах? Какие уровни архитектуры отрисовываете?
#архитектура
👍8
Технология бутерброда
Когда мне нужно высокоуровнево описать модель какого-то бизнес-процесса, я часто использую нотацию IDEF0. На мой взгляд, она идеально подходит, когда требуется «helicopter view» на один или несколько процессов, чтобы понять:
* основные связи между шагами процесса,
* регламентирующие документы и воздействия,
* роли, которые нужны для выполнения процесса,
* системы, механизмы и разнообразные ресурсы — пока не нарисуешь, даже не догадаешься что потребуется.
Чтобы объяснить стейкхолдерам, что такое IDEF0 (звучит страшновато и пыльно), нарисовал процесс «Как приготовить бутерброд» по всем правилам и заветам стандарта. Делюсь — может, кому-то пригодится :)
Рисую процессы обычно в draw.io и сохраняю исходники на Гуглодиске, либо если у заказчика Confluence с нужными плагинами — то рисую прямо внутри конфы.
Нотация минималистичная, кубики-и-стрелочки, всё как мы любим. На этапе концептуального обсуждения ровно то, что нужно. Далее по необходимости отдельные процессы декомпозирую в BPMN, где словарь гораздо богаче и можно точно показать логику исполнения бизнес-процессов.
#idef0
Когда мне нужно высокоуровнево описать модель какого-то бизнес-процесса, я часто использую нотацию IDEF0. На мой взгляд, она идеально подходит, когда требуется «helicopter view» на один или несколько процессов, чтобы понять:
* основные связи между шагами процесса,
* регламентирующие документы и воздействия,
* роли, которые нужны для выполнения процесса,
* системы, механизмы и разнообразные ресурсы — пока не нарисуешь, даже не догадаешься что потребуется.
Чтобы объяснить стейкхолдерам, что такое IDEF0 (звучит страшновато и пыльно), нарисовал процесс «Как приготовить бутерброд» по всем правилам и заветам стандарта. Делюсь — может, кому-то пригодится :)
Рисую процессы обычно в draw.io и сохраняю исходники на Гуглодиске, либо если у заказчика Confluence с нужными плагинами — то рисую прямо внутри конфы.
Нотация минималистичная, кубики-и-стрелочки, всё как мы любим. На этапе концептуального обсуждения ровно то, что нужно. Далее по необходимости отдельные процессы декомпозирую в BPMN, где словарь гораздо богаче и можно точно показать логику исполнения бизнес-процессов.
#idef0
🔥5❤4🤔2
Забыл написать важное:
Завтра у нас старт потока Курса интеграции, кто любит запрыгивать в последний вагон — присоединяйтесь. Кворум уже набран, но чем больше народу — тем мощнее динамика и веселее обсуждать домашку 😄
Завтра у нас старт потока Курса интеграции, кто любит запрыгивать в последний вагон — присоединяйтесь. Кворум уже набран, но чем больше народу — тем мощнее динамика и веселее обсуждать домашку 😄
sup.expert
Всё для системных аналитиков и бизнес-аналитиков — sup.expert
Всё для системных аналитиков и бизнес-аналитиков, а также тех, кто хочет ими стать: курсы, тренинги, вебинары, статьи, менторство, консультации
❤6👍3
История провала
Однажды мы начинали проект по производству электронного магазина с одним известным брендом и потребовалось срочно подтвердить, что в нашей команде есть специалисты, умеющие работать с OMS Starfish24.
(сразу скажу, что проект закончился относительно успешно, хотя и обошёлся заказчику в несколько раз дороже, чем изначально планировалось. Но виноваты были не мы, там всё было плохо спланировано ещё на этапе идеи и оценки бюджета)
В нашей команде, разумеется, вынь-да-положь такого человека не было; планировалось нанять или взять в аренду спеца по ходу дела. А тут — лицо, принимающее решение на стороне заказчика потребовало предъявить компетенции «прям сурочна!». Менеджмент заметался, шестерни завертелись и «жребий упал на меня» (ц) Кир Булычев, «Путешествие Алисы».
Я растерянно сказал менеджменту: менеджмент, что я там смогу ответить на собеседовании, если я систему-то в глаза ни разу не видел?! Менеджмент велел мне посмотреть документацию (из документации был список эндпоинтов API в Сваггере) и диаграммы внедрений на других проектах (стрелочки и квадратики невнятного происхождения и семантического наполнения).
Делать нечего и я честно поковырял унылую документацию и осторожно потыкал палочкой Сваггер. Ничего не понял, потому что логики между 80+ эндпоинтов и процессом регистрации заказов как-то не улавливалось.
В общем, на собеседование я пришёл с видом бравым и слегка придурковатым. Ни на один вопрос я ответить внятно не сумел, хотя тупо не молчал и невероятным усилием воли формулировал ответы, которые теоретически можно было принять за правду. Да вот только нёс я полную чушь, потому что в сути работы системы я не разобрался.
Заказчик мне так и сказал (близко к оригиналу, но прошло больше 3-х лет, могу путать слова): «— Молодой человек, вы вообще не компетентны в части работы этой системы. Совершенно точно я буду требовать замены команды и постараюсь больше с вами никогда не встречаться».
Сказать, что мне было стыдно — это ничего не сказать. Такого феноменального, катастрофического и бездарно унизительного поражения я не припомню с универа, когда профессор выгнал меня с пары за опоздание, выговаривая на аудиторию из 100 человек.
В тот день я поклялся сам себе, что больше не пойду на сделку с совестью и не поведусь на уверения менеджмента, что это «как комарик укусит», «давай, вошли и вышли, приключение на 20 минут».
После того случая у меня не раз бывали и уверен, ещё не раз будут ситуации, когда на вопрос собеседника я понятия не имею, что ответить. В этом случае я либо сразу говорю, что не знаю ответа; либо отвечаю, что мне нужно подготовиться и я вернусь с ответом через некоторое время.
К слову, с тем человеком, который меня собеседовал, мы потом проработали ещё полтора года на проекте: пришлось дипломатично забыть мой эпичнейший провал, потому что менеджмент, надо отдать должное, встал на мою защиту горой и отказался заменять команду на проекте. А значит — мне пришлось изучать, как работает OMS Starfish24 — только в этот раз по-честному и без дураков.
Поделитесь вашими историями провала в комментах? :))
Однажды мы начинали проект по производству электронного магазина с одним известным брендом и потребовалось срочно подтвердить, что в нашей команде есть специалисты, умеющие работать с OMS Starfish24.
OMS — Order Management System, система управления заказами в электронной коммерции.
(сразу скажу, что проект закончился относительно успешно, хотя и обошёлся заказчику в несколько раз дороже, чем изначально планировалось. Но виноваты были не мы, там всё было плохо спланировано ещё на этапе идеи и оценки бюджета)
В нашей команде, разумеется, вынь-да-положь такого человека не было; планировалось нанять или взять в аренду спеца по ходу дела. А тут — лицо, принимающее решение на стороне заказчика потребовало предъявить компетенции «прям сурочна!». Менеджмент заметался, шестерни завертелись и «жребий упал на меня» (ц) Кир Булычев, «Путешествие Алисы».
Я растерянно сказал менеджменту: менеджмент, что я там смогу ответить на собеседовании, если я систему-то в глаза ни разу не видел?! Менеджмент велел мне посмотреть документацию (из документации был список эндпоинтов API в Сваггере) и диаграммы внедрений на других проектах (стрелочки и квадратики невнятного происхождения и семантического наполнения).
Делать нечего и я честно поковырял унылую документацию и осторожно потыкал палочкой Сваггер. Ничего не понял, потому что логики между 80+ эндпоинтов и процессом регистрации заказов как-то не улавливалось.
В общем, на собеседование я пришёл с видом бравым и слегка придурковатым. Ни на один вопрос я ответить внятно не сумел, хотя тупо не молчал и невероятным усилием воли формулировал ответы, которые теоретически можно было принять за правду. Да вот только нёс я полную чушь, потому что в сути работы системы я не разобрался.
Заказчик мне так и сказал (близко к оригиналу, но прошло больше 3-х лет, могу путать слова): «— Молодой человек, вы вообще не компетентны в части работы этой системы. Совершенно точно я буду требовать замены команды и постараюсь больше с вами никогда не встречаться».
Сказать, что мне было стыдно — это ничего не сказать. Такого феноменального, катастрофического и бездарно унизительного поражения я не припомню с универа, когда профессор выгнал меня с пары за опоздание, выговаривая на аудиторию из 100 человек.
В тот день я поклялся сам себе, что больше не пойду на сделку с совестью и не поведусь на уверения менеджмента, что это «как комарик укусит», «давай, вошли и вышли, приключение на 20 минут».
После того случая у меня не раз бывали и уверен, ещё не раз будут ситуации, когда на вопрос собеседника я понятия не имею, что ответить. В этом случае я либо сразу говорю, что не знаю ответа; либо отвечаю, что мне нужно подготовиться и я вернусь с ответом через некоторое время.
К слову, с тем человеком, который меня собеседовал, мы потом проработали ещё полтора года на проекте: пришлось дипломатично забыть мой эпичнейший провал, потому что менеджмент, надо отдать должное, встал на мою защиту горой и отказался заменять команду на проекте. А значит — мне пришлось изучать, как работает OMS Starfish24 — только в этот раз по-честному и без дураков.
Поделитесь вашими историями провала в комментах? :))
❤5👍4🔥4
Заказчик, может, и неправ, но это его дело
На проекте возникла ситуация: клиент хочет решение в дизайне, которое субоптимально, по мнению команды. Один из аналитиков обратился ко мне за советом:
Я вспомнил Максима Ильяхова и его мантру:
Поэтому ответил коллеге вот так:
Совет простой: нарисуйте вариант с точки зрения, когда на сниппете «есть всё». Все цвета, размеры, свистелки — всё. И покажите, как это будет выглядеть.
Если заказчик скажет, что ему это нравится — значит, мы сделаем ТАК, как этого хочет заказчик.
Наша задача — не научить заказчика прекрасному чувству тонкого вкуса, а объяснить, какие есть варианты, разъяснить, чем лучше или хуже.
Выбирает заказчик; нам не следует печалиться и терять радость работы в проекте из-за этого. Это нормально, что заказчик может выбрать условное говно; плохо, если не попытались ему объяснить, что это говно.
Мы пытаемся, но нужно делать это лаконично, хладнокровно, профессионально и не рвать на себе волосы, если не получилось.
===
Надо уточнить, что конкретно этот макет в согласовании уже почти месяц, так что переубеждать время было, и все подходы к объяснению «почему лучше иначе» сделаны. Команда откровенно заколебалась уже. И да, какую проблему заказчик хочет решить — тоже отлично понимаем. Осталось просто сделать, как просят.
На проекте возникла ситуация: клиент хочет решение в дизайне, которое субоптимально, по мнению команды. Один из аналитиков обратился ко мне за советом:
Андрей, мне ещё твой совет нужен по сниппету для каталога, они всё-таки размеры и цвета на ховер затащить хотят и отказаться от модалки. У меня пока, кроме как "перегруженный ховер", аргументов нет... Больше, чем уже есть на модалке, они функционал не хотят.
Я вспомнил Максима Ильяхова и его мантру:
Раньше я говорил себе: «Я должен делать лучшие в мире проекты». Сейчас я говорю так: «Я хочу помогать клиентам решать их проблемы настолько хорошо, насколько могу».
Поэтому ответил коллеге вот так:
Совет простой: нарисуйте вариант с точки зрения, когда на сниппете «есть всё». Все цвета, размеры, свистелки — всё. И покажите, как это будет выглядеть.
Если заказчик скажет, что ему это нравится — значит, мы сделаем ТАК, как этого хочет заказчик.
Наша задача — не научить заказчика прекрасному чувству тонкого вкуса, а объяснить, какие есть варианты, разъяснить, чем лучше или хуже.
Выбирает заказчик; нам не следует печалиться и терять радость работы в проекте из-за этого. Это нормально, что заказчик может выбрать условное говно; плохо, если не попытались ему объяснить, что это говно.
Мы пытаемся, но нужно делать это лаконично, хладнокровно, профессионально и не рвать на себе волосы, если не получилось.
===
Надо уточнить, что конкретно этот макет в согласовании уже почти месяц, так что переубеждать время было, и все подходы к объяснению «почему лучше иначе» сделаны. Команда откровенно заколебалась уже. И да, какую проблему заказчик хочет решить — тоже отлично понимаем. Осталось просто сделать, как просят.
🔥8
ИИ-психолог
Этот вопрос возник у меня после прочтения поста с анализом того, понимает ли ИИ о чем пишет или только мимикрирует?
Не вдаваясь в детали — мимикрирует, и делает это очень хорошо, раскладывая запрос в семантический вектор по большому количеству осей смысла и подыскивая релевантный ответ.
Задал вопрос в канале психолога Михаила Прасса, где похожий вопрос обсуждался. Ответы процитирую:
Михаил Прасс:
Aleksandr K:
Михаил Прасс:
По моим ощущениям, меня сейчас больше всего привлекает связка врач-человек + ассистент ИИ. Потому что ИИ эрудирован, быстрее «думает», внимателен к мелочам. А человек как раз способен мыслить вне рамок «обучения» и «похожести векторов».
Идти к автономному врачу-ИИ я сейчас точно не готов.
А вы бы пошли к врачу, зная что он либо совсем робот либо человек, который использует помощь ИИ в работе с вами?
Если беседа с ИИ-психологом не будет отличима от беседы с человеком-психологом (тест Тьюринга или что-то более специальное), то в чем тогда разница?
Этот вопрос возник у меня после прочтения поста с анализом того, понимает ли ИИ о чем пишет или только мимикрирует?
Не вдаваясь в детали — мимикрирует, и делает это очень хорошо, раскладывая запрос в семантический вектор по большому количеству осей смысла и подыскивая релевантный ответ.
Задал вопрос в канале психолога Михаила Прасса, где похожий вопрос обсуждался. Ответы процитирую:
Михаил Прасс:
Дело в том, что по статистике примерно треть случаев относится к категории "сюрприз". То есть, они не имеют схожих не только в практике конкретного психолога, но и в литературе. Здесь нужно действовать методом "проб и ошибок", а в этой сфере ИИ просто ужасен и опасен для человека.
Ещё в трети случаев мы имеем "последовательное приближение к результату". Тут уже чуть лучше, но человек пока сильно эффективенее ИИ.
И только в случае, когда клиент изначально находится в высокой степени готовности или его случай более-менее стандартен, ИИ уже сейчас может превосходить среднего психолога.
Aleksandr K:
На типовых случаях может и неотличима. А однажды случится какая-то крайность, не описанная в системном промпте и выяснится, что "король-то голый" а ИИ-психолог не понимает, что несёт.
Как пример - ЧатЖПТ, который помогал подростку написать предсмертную записку и в целом консультировал по уходу из жизни но при этом за весьма длинный диалог ни разу не предложил альтернативных решений.
Оговорка: есть вероятность, что в ближайшие 10 лет ИИ по качеству работы превзойдёт "среднего" врача в большинстве медицинских специальностей, а может даже встанет на уровень лучших, причём во всех. Но пока предостережения типа моего актуальны.
Михаил Прасс:
ИИ в медицине уже превосходит узких диагностов в типовых случаях. Но в "смазанных" случаях ИИ уверенно "убивает" пациентов. Даже врач средней квалификации справляется в таких ситуациях лучше.
По моим ощущениям, меня сейчас больше всего привлекает связка врач-человек + ассистент ИИ. Потому что ИИ эрудирован, быстрее «думает», внимателен к мелочам. А человек как раз способен мыслить вне рамок «обучения» и «похожести векторов».
Идти к автономному врачу-ИИ я сейчас точно не готов.
А вы бы пошли к врачу, зная что он либо совсем робот либо человек, который использует помощь ИИ в работе с вами?
🔥3👍1
Forwarded from Системный сдвиг
Про протоколы приколы интеграции.
Сижу, готовлю презу к Flow. Подходит сын, садится рядом и внимательно изучает, что я рисую. Потом говорит: "Ааа! Протоколы интеграции! А я думал — приколы интеграции!"
Ну, поговорили о приколах. Навскидку, вспомнил такие приколы:
* SOAP, один из самых сложных по структуре протоколов, расшифровывается как Simple Object Access Protocol. Простой он по сравнению с такими монстрами, как CORBA.
* MQTT, несмотря на буквы MQ в названии (обычно означающие Message Queue), вообще не содержит очередей.
* YAML не является языком разметки, его теперь так и расшифровывают: YAML Ain't Markup Language.
* Основной принцип REST — управление через гипермедиа, HATEOAS. Но этому принципу почти никто следует в реальных REST API.
* REST API (HTTP-запросы) считается синхронным, но в реальных программах почти всегда HTTP-запросы выполняются асинхронно.
* Брокеры типа Kafka и RabbitMQ считаются (и являются!) асинхронными, но скорость обмена (latency или round trip) в них может быть в разы меньше, чем в "синхронных" HTTP-запросах.
* FlatBuffers, несмотря на своё название (flat=плоский), может хранить и вложенные объекты (через опцию nested_flatbuffers).
* Продукты RabbitMQ и Kafka часто рассматривают, как альтернативы, но они принципиально отличаются: RabbitMQ — это брокер сообщений с очередями без записи на диск, а Kafka — распределенный журнал с высоконадежным хранением, но без маршрутизации и очередей. Впрочем, в последнее время в Kafka появились очереди (в каком-то виде), а в RabbitMQ — персистентные сообщения и журналы (в каком-то виде). Напоминает сказку Киплинга про ежа и черепаху, которые друг друга учили плавать и сворачиваться в клубок.
* Несмотря на наличие "семантики доставки" exactly-once в Kafka, на самом деле доставка консьюмеру тут вообще никак не контролируется, это только про однократную и без потерь запись в журнал.
Это те, что я вспомнил минут за пять. Какие у нас ещё есть приколы в области интеграции?
Сижу, готовлю презу к Flow. Подходит сын, садится рядом и внимательно изучает, что я рисую. Потом говорит: "Ааа! Протоколы интеграции! А я думал — приколы интеграции!"
Ну, поговорили о приколах. Навскидку, вспомнил такие приколы:
* SOAP, один из самых сложных по структуре протоколов, расшифровывается как Simple Object Access Protocol. Простой он по сравнению с такими монстрами, как CORBA.
* MQTT, несмотря на буквы MQ в названии (обычно означающие Message Queue), вообще не содержит очередей.
* YAML не является языком разметки, его теперь так и расшифровывают: YAML Ain't Markup Language.
* Основной принцип REST — управление через гипермедиа, HATEOAS. Но этому принципу почти никто следует в реальных REST API.
* REST API (HTTP-запросы) считается синхронным, но в реальных программах почти всегда HTTP-запросы выполняются асинхронно.
* Брокеры типа Kafka и RabbitMQ считаются (и являются!) асинхронными, но скорость обмена (latency или round trip) в них может быть в разы меньше, чем в "синхронных" HTTP-запросах.
* FlatBuffers, несмотря на своё название (flat=плоский), может хранить и вложенные объекты (через опцию nested_flatbuffers).
* Продукты RabbitMQ и Kafka часто рассматривают, как альтернативы, но они принципиально отличаются: RabbitMQ — это брокер сообщений с очередями без записи на диск, а Kafka — распределенный журнал с высоконадежным хранением, но без маршрутизации и очередей. Впрочем, в последнее время в Kafka появились очереди (в каком-то виде), а в RabbitMQ — персистентные сообщения и журналы (в каком-то виде). Напоминает сказку Киплинга про ежа и черепаху, которые друг друга учили плавать и сворачиваться в клубок.
* Несмотря на наличие "семантики доставки" exactly-once в Kafka, на самом деле доставка консьюмеру тут вообще никак не контролируется, это только про однократную и без потерь запись в журнал.
Это те, что я вспомнил минут за пять. Какие у нас ещё есть приколы в области интеграции?
👍1
Все кругом используют ИИ
…или как в одном анекдоте, говорят о том, что используют ИИ. При этом все разговоры крутятся обычно вокруг простых языковых трансформеров. Про живые внедрения агентских ИИ я читал только в новостях и профильных каналах, вживую пока не довелось попробовать.
Сам я использую ChatGPT в работе и хобби — но не в веб-варианте, а как телеграм-бот. В телеге чертовски удобно общаться и регулировать контекст; я написал бот, в котором реализовал шаблон RAG и эмбеддинг узкоспециализированных материалов в контекст для одного дружественного проекта. Попутно изучил, как вся эта кухня работает.
Конкретно для анализа и проектирования я обычно беру транскрибированный текст из встречи с заказчиком и командой, размечаю тегами его на блоки (теги любые, чаще использую xml-подобный синтаксис). Далее загружаю контекст в бота, велю ему ждать команду на начало работы.
Из последнего — я делал BRD по результатам установочной встречи с заказчиком. Предварительно накидал инструкции о том, что я хочу увидеть в структуре BRD; в той части, где мне нужны высокоуровневые требования, я даю предельно точные инструкции примерно такого вида:
Дальше велю ИИшке приступать к работе, по частям отдавая мне результат.
Дальше я нудно и тщательно проверяю результаты работы и оформляю результирующий документ. ИИшка нет-нет да и наврёт, сколько ты не пиши инструкции «отвечай только если уверен более чем на 75%», галлюцинации проскакивают регулярно.
Плюс бывает откровенный бред, но это всё устраняется осмыслением и редактурой. Главное что я получаю — это экономия времени на сбор структуры, поиск альтернативных вариантов и генерация внятного текста. Мне править всегда проще, чем писать с нуля. И ещё: когда долго работаешь с LLM, начинаешь чувствовать некоторую «пластмассовость» в её суждениях и это надо убирать, люди далеко не дураки.
Ещё использую LLM для уточнений по пирамидам метрик либо как переводчик с любых языков на любые, либо на поиск терминов или контекста. Но всегда, всегда надо делать фактчек за ИИшкой.
Как у вас дела обстоят с ИИ? Получается внедрять в работу, помогает или мешает?
…или как в одном анекдоте, говорят о том, что используют ИИ. При этом все разговоры крутятся обычно вокруг простых языковых трансформеров. Про живые внедрения агентских ИИ я читал только в новостях и профильных каналах, вживую пока не довелось попробовать.
Агентские ИИ не просто отвечают на вопросы или выполняют одну команду, а действует самостоятельно, добиваются целей, могут «размышлять» о собственных действиях и менять поведение в процессе выполнения задачи.
Сам я использую ChatGPT в работе и хобби — но не в веб-варианте, а как телеграм-бот. В телеге чертовски удобно общаться и регулировать контекст; я написал бот, в котором реализовал шаблон RAG и эмбеддинг узкоспециализированных материалов в контекст для одного дружественного проекта. Попутно изучил, как вся эта кухня работает.
Конкретно для анализа и проектирования я обычно беру транскрибированный текст из встречи с заказчиком и командой, размечаю тегами его на блоки (теги любые, чаще использую xml-подобный синтаксис). Далее загружаю контекст в бота, велю ему ждать команду на начало работы.
Из последнего — я делал BRD по результатам установочной встречи с заказчиком. Предварительно накидал инструкции о том, что я хочу увидеть в структуре BRD; в той части, где мне нужны высокоуровневые требования, я даю предельно точные инструкции примерно такого вида:
(5) Высокоуровневые бизнес-требования. Требования опиши в канонической форме, как указано в примере ниже. Пронумеруй каждое требование в формате БТ-X где X — монотонно возрастающее целое число.
Каноническая форма: <Программная система> <должна> позволять <Участник> <действие> <Объект><условия>
<пример> Система должна позволять пользователю с ролью “Абонент” создавать карточку жилого помещения.</пример>
Дальше велю ИИшке приступать к работе, по частям отдавая мне результат.
Дальше я нудно и тщательно проверяю результаты работы и оформляю результирующий документ. ИИшка нет-нет да и наврёт, сколько ты не пиши инструкции «отвечай только если уверен более чем на 75%», галлюцинации проскакивают регулярно.
Плюс бывает откровенный бред, но это всё устраняется осмыслением и редактурой. Главное что я получаю — это экономия времени на сбор структуры, поиск альтернативных вариантов и генерация внятного текста. Мне править всегда проще, чем писать с нуля. И ещё: когда долго работаешь с LLM, начинаешь чувствовать некоторую «пластмассовость» в её суждениях и это надо убирать, люди далеко не дураки.
Ещё использую LLM для уточнений по пирамидам метрик либо как переводчик с любых языков на любые, либо на поиск терминов или контекста. Но всегда, всегда надо делать фактчек за ИИшкой.
Как у вас дела обстоят с ИИ? Получается внедрять в работу, помогает или мешает?
🔥4👍2
Паттерн: Сага
Интересный архитектурный шаблон, особенно актуальный в условиях распределённых систем, когда некое бизнес-осмысленное действие будет успешным, только если будет успешным каждый небольшой шаг, а функционал реализован в разных сервисах; если любой шажок закончится неудачей, то надо откатить все предыдущие (успешные) шаги.
— Pattern: Saga
Пример — создание заказа на одном из текущих проектов. Задача: создать сущность заказа в OMS в статусе «Создан», затем зарезервировать остатки под заказ в системе оперативных остатков товаров, потом сменить статус заказа на «Оформлен» и в конце отправить уведомления клиенту и менеджеру (ещё нужно будет бонусы списывать в программе лояльности, но это на следующих этапах проекта).
Формально сагу рекомендуют делать на событиях, которые либо оркестрируются либо обрабатываются хореографически. Мы сделали упрощённый оркестратор, который хранит состояние саги в реляционной СУБД. В случае неудачи оркестратор пытается выполнить шаг с таймаутом с нелинейным возрастанием задержки. Если попытки исчерпаны — вся сага отменяется с компенсирующими действиями.
Наша сага имеет следующие шаги:
APPLY_STOCK — создать временный резерв остатков
APPLY_LOYALTY — списать бонусы в системе лояльности
CONFIRM — подтвердить заказ, отправить уведомления
Финальные шаги:
FINISHED — сага успешно завершена
FAILED — сага завершилась с ошибками
Шаг отката:
ROLLBACK_STOCK — убрать временный резерв остатков в случае ошибок
Я решил не усложнять архитектуру асинхронными очередями, потому что: (1) тестировать сагу стало бы в разы сложнее; (2) проектная нагрузка на систему далека от „High load“; (3) узнать в моменте состояние саги стало бы сложнее.
Подобная реализация уже была сделана нашим тимлидом на другом проекте и по моим наблюдениям вполне неплохо себя зарекомендовала. Проблемы, которые там были, появились из-за некачественного логгирования шагов и плохо настроенных таймаутов (финальные таймауты достигали дней между повторами). Я с самого начала спроектировал логгирование правильно, ну а для таймаутов, для разнообразия взял ряд Фибоначчи с ценой деления 1 минута.
А есть ли у вас в практике интересные шаблоны проектирования, которые вы использовали осознанно? (ну или случайно, главное чтобы вам понравилось :) )
Интересный архитектурный шаблон, особенно актуальный в условиях распределённых систем, когда некое бизнес-осмысленное действие будет успешным, только если будет успешным каждый небольшой шаг, а функционал реализован в разных сервисах; если любой шажок закончится неудачей, то надо откатить все предыдущие (успешные) шаги.
Сага — это последовательность локальных транзакций. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие, чтобы запустить следующую локальную транзакцию в саге. Если локальная транзакция завершается неудачей из-за нарушения бизнес-правила, сага выполняет серию компенсирующих транзакций, которые отменяют изменения, внесённые предыдущими локальными транзакциями.
— Pattern: Saga
Пример — создание заказа на одном из текущих проектов. Задача: создать сущность заказа в OMS в статусе «Создан», затем зарезервировать остатки под заказ в системе оперативных остатков товаров, потом сменить статус заказа на «Оформлен» и в конце отправить уведомления клиенту и менеджеру (ещё нужно будет бонусы списывать в программе лояльности, но это на следующих этапах проекта).
Формально сагу рекомендуют делать на событиях, которые либо оркестрируются либо обрабатываются хореографически. Мы сделали упрощённый оркестратор, который хранит состояние саги в реляционной СУБД. В случае неудачи оркестратор пытается выполнить шаг с таймаутом с нелинейным возрастанием задержки. Если попытки исчерпаны — вся сага отменяется с компенсирующими действиями.
Наша сага имеет следующие шаги:
APPLY_STOCK — создать временный резерв остатков
APPLY_LOYALTY — списать бонусы в системе лояльности
CONFIRM — подтвердить заказ, отправить уведомления
Финальные шаги:
FINISHED — сага успешно завершена
FAILED — сага завершилась с ошибками
Шаг отката:
ROLLBACK_STOCK — убрать временный резерв остатков в случае ошибок
Я решил не усложнять архитектуру асинхронными очередями, потому что: (1) тестировать сагу стало бы в разы сложнее; (2) проектная нагрузка на систему далека от „High load“; (3) узнать в моменте состояние саги стало бы сложнее.
Подобная реализация уже была сделана нашим тимлидом на другом проекте и по моим наблюдениям вполне неплохо себя зарекомендовала. Проблемы, которые там были, появились из-за некачественного логгирования шагов и плохо настроенных таймаутов (финальные таймауты достигали дней между повторами). Я с самого начала спроектировал логгирование правильно, ну а для таймаутов, для разнообразия взял ряд Фибоначчи с ценой деления 1 минута.
А есть ли у вас в практике интересные шаблоны проектирования, которые вы использовали осознанно? (ну или случайно, главное чтобы вам понравилось :) )
❤4
Таксономия базы знаний
Т. — учение о классификации сложных иерархических систем. Здесь: система классификации статей в базе знаний (в конфлюенсе, вики, БД).
Принципы
Найти статью базе знаний будет легче, если она снабжена метками (тэгами) в соответствии с принятой на проекте таксономией.
Статья может быть снабжена метками из следующих разделов:
Аудитория, Тип документа, Тема, Система, Функция
Как работают метки
Пример для конфлюенса
Чтобы добавить метку, нажмите справа-внизу страницы на иконку бейджика, появится всплывающее окно. Метка создаётся в конфе, когда её первый раз присваивают странице. Метка удаляется из конфы, когда не остаётся больше страниц с такой меткой.
Правила именования меток
Формат названия:
— строчные (малые) буквы
— слова-разделены-дефисом (kebab-case)
— первое слово метки определяет раздел таксономии: аудитория-; тип-; продукт-; тема-; система-; функция-.
Для метки используется только русский язык. Названия систем, функций и модных фичей переводим в удобоваримый аналог на русском языке (например «система-нав»). Таким образом мы всегда будем знать, как набирать название метки в конфе.
Правила для тематических меток
Метки из группы «тема-*» создаются путем перечисления сущностей из предметной области от общего-к-частному во множественном числе. Например:
К чему я это всё? Нашёл сегодня свою собственную статью в базе знаний проекта и понял, что неплохо её проработал для использования на любых проектах, где документации больше чем пара десятков страниц. Метки удобны тем, что их можно гибко фильтровать и создавать промежуточные страницы для группировки сходных документов, которые лежат исходно в разных ветках базы знаний.
Например: «Фиды», «Алгоритмы ETL», «Обработка остатков» и так далее.
P.S. Для классификации страниц идеально использовать языковые модели; NLP — их сильная сторона.
Т. — учение о классификации сложных иерархических систем. Здесь: система классификации статей в базе знаний (в конфлюенсе, вики, БД).
Принципы
Найти статью базе знаний будет легче, если она снабжена метками (тэгами) в соответствии с принятой на проекте таксономией.
Статья может быть снабжена метками из следующих разделов:
Аудитория, Тип документа, Тема, Система, Функция
Как работают метки
Пример для конфлюенса
Чтобы добавить метку, нажмите справа-внизу страницы на иконку бейджика, появится всплывающее окно. Метка создаётся в конфе, когда её первый раз присваивают странице. Метка удаляется из конфы, когда не остаётся больше страниц с такой меткой.
Правила именования меток
Формат названия:
— строчные (малые) буквы
— слова-разделены-дефисом (kebab-case)
— первое слово метки определяет раздел таксономии: аудитория-; тип-; продукт-; тема-; система-; функция-.
Для метки используется только русский язык. Названия систем, функций и модных фичей переводим в удобоваримый аналог на русском языке (например «система-нав»). Таким образом мы всегда будем знать, как набирать название метки в конфе.
Правила для тематических меток
Метки из группы «тема-*» создаются путем перечисления сущностей из предметной области от общего-к-частному во множественном числе. Например:
тема-товары-остатки
тема-товары-цены
тема-товары-отображение
тема-заказы-статусы
тема-рефералка-управление
К чему я это всё? Нашёл сегодня свою собственную статью в базе знаний проекта и понял, что неплохо её проработал для использования на любых проектах, где документации больше чем пара десятков страниц. Метки удобны тем, что их можно гибко фильтровать и создавать промежуточные страницы для группировки сходных документов, которые лежат исходно в разных ветках базы знаний.
Например: «Фиды», «Алгоритмы ETL», «Обработка остатков» и так далее.
P.S. Для классификации страниц идеально использовать языковые модели; NLP — их сильная сторона.
🔥5
Говорю про банальные вещи, которые тем не менее остаются актуальными: в статье разбираю причины несоответствия ИТ-решений ожиданиям клиентов и предлагаю очевидные (хыхы) методы минимизации разрыва между ожиданиями заказчика и конечным результатом.
https://www.it-world.ru/cionews/hk0qmcxmm00k80wcskogcgw8wcg4os4.html
https://www.it-world.ru/cionews/hk0qmcxmm00k80wcskogcgw8wcg4os4.html
ИТ Медиа | Управление ИТ
Как не «утопить» ИТ-проект
В разработке ИТ-решений часто возникает разрыв между тем, что ожидал клиент, и тем, что в итоге получилось.
🔥6👍2❤1