☕️ MCP (Model Context Protocol)?

MCP — это новый стандарт от компании Anthropic, который помогает искусственным интеллектам (например, модели Claude) работать с внешними системами: базами данных, файлами, API и другими инструментами.

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

MCP — это не фреймворк или инструмент, а именно протокол, аналогичный: HTTP для интернета, SMTP для обмена сообщениями.

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

🧐 Как это работает?
MCP строится на клиент-серверной архитектуре и состоит из трёх частей:
— Host (хост): Это среда, где работает ИИ (например, приложение Claude). Он предоставляет доступ к инструментам (БД, API) через MCP. Пример : Вы спрашиваете ИИ: «Проанализируй продажи за квартал». Хост запускает MCP Client, чтобы связаться с базой данных.
— MCP Client (клиент): Часть ИИ, которая формирует запросы к внешним системам. Пример : Если ИИ нужно взять данные из PostgreSQL, MCP Client превращает запрос в структурированный код (например, SQL-запрос).
— MCP Server (сервер): «Переводчик», который связывает ИИ с внешним миром (Google Drive, API, БД). Пример : MCP Server для PostgreSQL получает SQL-запрос от клиента, выполняет его в базе и возвращает результат ИИ.

🧩 Ключевые элементы MCP
Они делятся между клиентом и сервером и реализуют «правила общения»:

Для клиента (MCP Client):
❶ Roots (Корни) — Безопасный доступ к файлам и данным.
Пример : ИИ может открыть файл в Google Drive через MCP Server, но не увидит другие файлы пользователя.
❷ Sampling (Выборка) — Запрос помощи у ИИ для задачи.
Пример : ИИ просит пользователя уточнить, какую именно таблицу из БД использовать.

Для сервера (MCP Server):
❸ Prompts (Инструкции) — Подсказки для ИИ, чтобы он понимал контекст.
Пример : «Ты работаешь с финансовыми данными, используй формат отчета X».
❹ Resources (Ресурсы) — Данные, к которым обращается ИИ.
Пример : Таблицы из PostgreSQL или файлы из Dropbox.
❺ Tools (Инструменты) — Функции, которые ИИ может вызывать.
Пример : Выполнить SQL-запрос, отправить письмо через API или обработать изображение.

🤌 Как это работает на практике?
Сценарий: Вы спрашиваете: «Покажи график продаж за 2023 год».
1. Host (ваш ИИ-ассистент) запускает MCP Client.
2. MCP Client формирует запрос к MCP Server для PostgreSQL: «Получи данные о продажах».
3. MCP Server подключается к БД, выполняет SQL-запрос и возвращает данные.
4. Resources (данные о продажах) и Tools (график) используются для создания ответа.
5. ИИ показывает вам график, используя Prompts (например, «График должен быть в формате PDF»).

🔗 Полезные материалы
— Учебная программа MCP для начинающих от MS
— Документация MCP
— Спецификация MCP
— GitHub репозиторий MCP
— Сообщество MCP

#ai #mcp #bytebytego

☕️ Активность ≠ результат

— «Наша новая функция набрала 70% вовлечённости!»
— «А решает ли она проблему?».

Измерять активность, а не результат — распространённая ошибка. Пользователи могут открывать экран, но не завершать действие.

Активность — это то, что делают люди:
— Количество кликов по кнопке.
— Открытие экрана.
— Время в приложении.

Результат — это то, что меняется у пользователя:
— Сократилось ли время на задачу?
— Исчезла ли боль?
— Улучшилась ли их жизнь?

Пример:
❌ Плохо: «80% пользователей нажали на кнопку “Поделиться”».
✅ Хорошо: «Количество успешных шеров в соцсети выросло на 30%».

❌ Плохо: «В приложении совершается 10 000 поисковых запросов».
✅ Хорошо: «Конверсия после поиска выросла на 15%: пользователи находят нужное и совершают целевое действие»

❌ Плохо: «90% прошли первый этап онбординга!»
✅ Хорошо: «Удержание новых пользователей через неделю выросло до 60%: они создают первый проект в течение дня».

🤌Как перестать гнаться за активностью
❶ Задайте вопрос: «Какая проблема решается?»
Перед запуском функции определите: «Пользователь получит X, потому что Y» . Например: «Пользователь быстрее найдёт нужный документ, потому что поиск будет учитывать синонимы» .

❷ Выберите метрику-результат
Не «сколько открыли поиск», а:
— «На сколько сократилось время поиска?»
— «Сколько запросов завершились успешным действием?»

❸ Сравните «до» и «после» в контексте цели
Если метрика не связана с пользой — игнорируйте её. Даже если цифры впечатляют.

💡 Итого
Если метрика не отвечает на вопрос «Зачем это нужно?» — она бесполезна.

Активность — это шум. Результат — сигнал. Перед каждым релизом полезно задавать вопрос: «Как мы поймём, что это сработало?».

#thoughts #pm #metrics

☕️ "После не значит вследствие": как не обмануться в работе

Знакомая ситуация? Вы запустили новую фичу — и тут же пользователи начали жаловаться. Значит, фича плохая, верно?

Не обязательно))

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

корреляция ≠ причинно-следственная связь

Или проще: "после не значит вследствие".


❌ Плохой пример мышления:
"Мы внедрили новый инструмент → через неделю упали метрики → значит, инструмент виноват"

✅ Правильный подход:
"Мы внедрили новый инструмент → через неделю упали метрики. Что ещё изменилось? Какие ещё факторы могли повлиять?"

В работе мы часто сталкиваемся с этой ошибкой:
— Пример 1: После обновления UI количество отказов выросло. Команда сразу делает вывод, что новый дизайн плохой. Но возможно, в тот же день началась сезонная распродажа у конкурента.
— Пример 2: После перехода на новый фреймворк увеличилась скорость загрузки. Все рады, но на самом деле улучшение дал CDN, который подключили параллельно.
— Пример 3: После релиза новой функции выросла конверсия. Продакт рад, но на самом деле это сезонный всплеск спроса.

Как не попадаться в эту ловушку?
— Ищите альтернативные объяснения - когда видите связь между двумя событиями, задайте себе: "Что ещё могло повлиять?"
— Собирайте больше данных - одна метрика не даёт полной картины. Сравнивайте с контрольной группой, анализируйте временные ряды.
— Проводите A/B-тесты - если хотите точно знать причину, единственный надёжный способ — контролируемый эксперимент.
— Задавайте "глупые" вопросы - "А точно ли это связано?", "Может, мы что-то упускаем?", "Как это проверить?"

Помните: в нашем мире всё взаимосвязано. Просто потому что событие B произошло после события A, не значит, что A вызвало B. Иногда это просто совпадение, иногда третий фактор влияет на оба.

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

#thoughts #analytics #logic

☕️ Дайджест публикаций канала №2 (28.05.2025 - 06.08.2025)

💼 Менеджмент
— Артефакты продуктового менеджмента
— Контент как продукт: почему "создателям" нужны аналитика и обратная связь
— Канвасы - подборка популярных шаблонов


🧱 Работа с данными
— Семантический слой: ключ к доверию в данных и эффективности ИИ
— Лайфхак: Как найти дубликаты в базе данных с помощью SQL
— Почему метрика просела
— NPS: забавная метрика

⚙️ ИИ
— Основы промпт-инжиниринга
— Генерация промптов для LLM силами LLM
— Как устроен RAG: два шага к идеальному ответу
— Как устроен MCP (Model Context Protocol)

🤌 How-to
— Принцип MECE (Mutually Exclusive, Collectively Exhaustive)
— Как внедрять изменения в команде: 3 этапа по Коттеру

🤔 Размышления
— Принципы вместо процессов - как охватить необъятное
— Проблемы детального планирования - о важности решения проблем пользователей
— Баланс между скоростью и качеством - когда стоит торопиться, а когда — тормозить
— Активность ≠ результат - что действительно надо измерять
— После не значит вследствие - как не обмануться в работе

#digest

☕️ Как код превращается в приложение

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

Итак, представьте, что вы заказываете ремонт в квартире. Сначала мастер изучает план (как разработчик изучает задачу), потом делает черновую работу (пишет код), коллеги проверяют (ревью), и только потом всё закрепляется окончательно (деплой). Так же работает процесс создания IT-продуктов. Посмотрим, как из строк кода получается работающее приложение:

❶ Начало работы: IDE и исходный код

Разработчики пишут код в специальных программах — IDE (Integrated Development Environment, или "интегрированная среда разработки"). Это как конструктор LEGO с подсветкой: подсказывает ошибки, помогает дописать код и сразу показывает результат.

❷ Версионный контроль: Git и ветки

Весь код хранится в системе контроля версий (VCS, например Git/SVN) — это как "хронология изменений" проекта. Самая важная ветка — master/main (основная ветка). Это эталонная, рабочая версия приложения, которая сейчас работает у пользователей.

Перед работой разработчик:
— скачивает актуальный код из мастер-ветки (как взять чистый чертёж)
— создаёт рабочую ветку (feature branch) — это как отдельная копия проекта для своих изменений. Называется обычно по смыслу: "fix-login-button" или "add-payment-feature"

❸ Пишем код и сохраняем изменения

После изменений разработчик делает коммит — сохраняет изменения с комментарием "Что я сделал и зачем". Это как сделать заметку в дневнике: "Исправил кнопку входа — теперь она не исчезает на мобильных".

❹ Проверка коллегами: Pull Request и Code Review

Когда код готов, разработчик создаёт Pull Request (PR) — это как заявка: "Мои изменения готовы, проверьте, можно ли их добавить в основной проект".

Затем коллеги проводят code review (ревью кода):
— проверяют, нет ли ошибок
— убеждаются, что код соответствует стандартам
— дают советы по улучшению

Это как если бы прораб проверил работу мастера перед сдачей объекта.

❺ Объединение: Merge в мастер

После успешного ревью изменения мержат (merge) в мастер-ветку — объединяют с основным кодом. Это как внести утверждённые правки в окончательный чертёж.

❻ Автоматическая сборка: CI/CD

Тут вступает в работу система CI/CD (Continuous Integration / Continuous Deployment):
— сборка (build): код преобразуется в исполняемый файл — как собрать модель из деталей LEGO
— тестирование: автоматические проверки, что ничего не сломалось
— деплой (deploy): размещение приложения на серверах

❼ Раскатка на "поды"

Современные приложения часто работают в системе Kubernetes — это как "диспетчер" для серверов. В ней есть поды (pods) — минимальные единицы развертывания. Каждый под — это как отдельный контейнер с вашим приложением и всем необходимым для его работы.

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

При деплое новые поды с обновлённым кодом постепенно заменяют старые — так пользователи не замечают перехода.

❽ Готовое приложение

В итоге код:
— прошёл проверку коллег
— успешно собрался
— без проблем развернулся на серверах
— доступен пользователям как рабочее приложение


🤔 Почему так много этапов?

Каждый шаг нужен, чтобы:
— избежать ошибок в продакшене (рабочей версии)
— обеспечить возможность отката, если что-то пошло не так
— дать коллегам возможность улучшить код
— автоматизировать рутину

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

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

#dev #ликбез #simplewords

☕️ "Твоя обратная связь не в dev/null": почему важно показывать пользователям, что их голос услышан

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

Сегодня хочу поговорить о простой, но критически важной вещи: обратная связь по обратной связи.

😔 Почему "тишина" убивает мотивацию
Представьте: вы заметили баг, потратили время, чтобы подробно описать проблему, приложить скриншоты, воспроизвести шаги. Отправили в поддержку и... тишина.

Это как написать письмо другу и никогда не получить ответа. Сначала думаешь: "Может, он занят". Потом: "Может, я не так написал". В итоге: "Зачем вообще писать?".

Когда пользователь не видит, что его сообщение обработано, он теряет веру в то, что его мнение важно. И перестаёт писать.

⚙️ Что происходит "за кулисами"?
Часто команда получает ваш фидбек, создаёт тикет в Jira или другой системе, ставит статус "To Do", но пользователь об этом не знает.

Для вас это как сообщение в пустоту. Для команды — нормальный рабочий процесс.

Разрыв между этими двумя мирами убивает лояльность.

🛠 Как это должно работать
Хорошие продукты показывают пользователям, что их голос услышан:
— Мгновенное подтверждение: "Спасибо за ваш репорт! Мы создали задачу #1234 и рассмотрим её в ближайшее время."
— Видимость статуса: "Ваша идея в списке на рассмотрение", "Мы начали работу над этим", "Готово! Обновление выйдет в следующем релизе".
— Уведомления: "Ваш баг был исправлен в версии 2.1. Спасибо, что помогли сделать продукт лучше!"

Это как трек-номер посылки — даже если доставка займёт время, вы точно знаете, что ваш заказ не потерялся.

🤌 Почему это работает
Когда пользователь видит, что его фидбек имеет статус и движется по воронке, происходит магия:
— Появляется доверие — вы знаете, что команда работает
— Растёт лояльность — даже если решение придёт не сразу
— Увеличивается вовлечённость — люди начинают чаще и подробнее писать
— Создаётся сообщество — пользователи чувствуют себя частью процесса

🚀 Как внедрить в своём продукте
— Добавьте подтверждение отправки — пусть даже простое "Спасибо! Мы получили ваше сообщение"
— Покажите номер тикета — даже если это внутренний ID, дайте пользователю точку опоры
— Создайте публичный трекер — где пользователи могут следить за статусом своих запросов
— Закрывайте цикл — когда фича внедрена или баг исправлен, уведомите тех, кто об этом писал
— Будьте честны — если идею отклонили, объясните почему. "Мы ценим вашу идею, но сейчас фокусируемся на других задачах, потому что..."

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

💡 Вывод
Обратная связь — это не односторонняя урна для предложений. Это диалог.

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

Даже простое "мы видим ваш запрос и работаем над ним" может превратить случайного пользователя в активного со-создателя вашего продукта.

А вы замечали, что чаще даёте обратную связь тем продуктам, где видите, что вас слышат?

P.S. Выражение "отправить в dev/null" означает отправить в никуда, в пустоту. истоки

#feedback #product #ux

☕️ Метрики внутренних продуктов

Ранее я сравнивал внутренние и внешние продукты. Если внешние оценивают по финансовым метрикам (выручка, LTV, конверсии), то ключевые показатели внутренних сосредоточены на удовлетворённости сотрудников и сокращении времени до целевого действия.

Time to value, time to insight, time to deploy — называйте как угодно. Суть одна: насколько короток путь от начала работы до решения задачи. Но этот путь редко бывает гладким.

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

🙉 Как это исправить?
Ускорять целевое действие, минимизируя потери на пути к нему. Для этого нужно:
1. Измерить, сколько времени уходит на непродуктивные операции:
— Поиск: минуты, потраченные на поиск документа или контакта;
— Контекст-свитчи: частота переключения между вкладками и системами;
— Ожидание: периоды простоя из-за задержек согласований;
— Исправление ошибок: часы, потраченные на переделку из-за недостатка данных;
— Навигационные потери: время, ушедшее на «блуждание» по интерфейсу.
2. Проанализировать, где эти потери возникают и устранить. Например, аналитик тратит 10 минут на формирование отчёта, но 8 из них — на поиск фильтров и переходы между вкладками. Это 80% потерянного времени, которое можно вернуть в полезную работу.

📉 Какие метрики использовать?
Чтобы системно работать с проблемой, нужны не абстрактные «шероховатости», а количественные показатели:
— Search-to-Result Ratio — сколько запросов в поиске нужно сделать, чтобы найти нужную информацию?
— Context Switch Index — сколько раз сотрудник переключается между системами при выполнении одной задачи?
— Dead Time Percentage — какой процент времени тратится на ожидание (ответов, загрузки, согласований)?
— First-Try Success Rate — сколько задач выполняется с первого раза без ошибок и переделок?
Эти метрики превращают субъективные «неудобства» в чёткие точки для роста.

Как внедрить?
1. Запишите процесс - попросите коллег записать экран при выполнении типовой задачи.
2. Создайте карту потерь - отметьте все точки, где сотрудник: ищет, переключается, ждет, исправляет
3. Измеряйте до и после - перед внедрением улучшений зафиксируйте текущие показатели потерянного времени.

💡Итого
Не стремитесь просто ускорить целевое действие. Ищите и устраняйте "дыры" в процессе — те моменты, когда люди теряют время впустую.

Задача продакта "внутренних" решений — не добавлять фичи, а убирать трение. Потому что каждая минута, сэкономленная сотруднику — это минута, которую он может потратить на действительно ценную работу (попить кофе, шутка).

#metrics #product #lean

☕️ Как сделать красиво в Excel

Прекрасная Настя (канал настенька и графики) выпустила бомбический БЕСПЛАТНЫЙ курс по визуализации данных в Excel.
Будет полезен всем, кто "сидит" в Excel.

В нем вы найдёте:
— Пошаговое видео с переверсткой
— Чек-листы по переверстке
— Гайд по выбору графиков
и многое другое.

#bi #excel