☕️ Дайджест публикаций канала №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