Работая в айтишечке
1.13K subscribers
287 photos
4 videos
55 links
Канал о том, как эффективно работать в IT: простые объяснения технических вещей, лайфхаки, лучшие практики и полезные инструменты для повседневных задач.

Автор: @Shevtsoff
Download Telegram
☕️ Метрики внутренних продуктов - фреймворк CASTLE

Когда-то ранее я писал про метрики продукта и разные фреймворки вроде HEART от Google. Там мы говорили о Happiness, Engagement, Adoption, Retention и Task success.

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

На днях мне попалась статья про фреймворк CASTLE от Nielsen Norman Group и её содержимое мне очень откликнулось т.к. давно похожее крутилось в голове, но не было никак оформлено.

Делюсь находкой с вами в виде карточек (см. выше 👀)

#product #metrics
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
4🔥3
☕️ Менеджер B2E продуктов: кто это и чем он отличается от обычного PM

Если вы думаете, что менеджер продукта в B2E (Business-to-Employee) — это просто PM, который работает с внутренними инструментами вместо внешних, — глубоко ошибаетесь. Это совершенно другая роль с уникальными вызовами и компетенциями.

В отличие от B2B/B2C-продуктов, где пользователи могут выбрать или уйти, B2E-продукты живут в мире, где сотрудники вынуждены их использовать. И от этого меняется всё.

🧭 Кто такой B2E-менеджер продукта?
Это не просто стратег или решатель проблем — это архитектор изменений внутри организации. Его главная задача — не написать ТЗ или приоритизировать фичи, а найти баланс между противоречивыми интересами:
— Бизнес-пользователи хотят удобных инструментов
— Финансы требуют строгого контроля бюджетов
— СИБ обеспокоен безопасностью и интеграцией
— А сотрудники хотят, чтобы всё «просто работало»

По статистике, 70-80% цифровых инициатив проваливаются не из-за технических проблем, а из-за сопротивления сотрудников и плохого управления изменениями. И B2E-PM как раз стоит на передовой этого боя.

💡 Ключевые навыки B2E-менеджера
1. Язык бизнеса, а не техники
Вместо «реализации API-эндпоинтов» вы говорите: «Это сократит время на обработку заявок на отпуск на 30%». Ваша аудитория — руководители подразделений, а не инженеры.

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

3. Мастерство управления изменениями
Это не просто «провести обучение». Это построение плана внедрения с executive sponsorship, постепенным запуском, коммуникационной стратегией и поддержкой на всех этапах.

4. Приоритизация через призму бизнес-метрик
В B2E приоритет не получают самые громкие жалобы. Приоритет получают задачи, которые влияют на:
— Операционную эффективность (время выполнения задач)
— Уровень вовлечённости сотрудников
— Снижение текучести кадров
— ROI на процессы

📊 Как измерять успех в B2E?
Забудьте про классические метрики вроде ARR или LTV. В B2E-мире вы измеряете:
— Internal NPS — готовность сотрудников рекомендовать систему коллегам
— ESAT — уровень удовлетворённости сотрудников
— Process Execution Time Reduction — сокращение времени на задачи
— Error Rate Reduction — снижение количества ошибок
— Триадный ROI — операционный (время/деньги), опытный (удовлетворённость), стратегический (агильность/удержание талантов)

🗣 Особенности работы с пользователями
В B2E вы не можете (зависит от компании) просто опросить «клиентов», потому что у сотрудников часто нет психологической безопасности говорить о проблемах с инструментами. Поэтому B2E-менеджер:
— Анализирует поведенческие данные (usage analytics) вместо прямых опросов
— Работает с анонимными каналами обратной связи
— Наблюдает за «серыми зонами» (shadow IT), где сотрудники используют сторонние инструменты для обхода корпоративной системы
— Вовлекает пользователей в дизайн (co-design) ещё на этапе прототипирования

🔮 Как перейти в B2E из B2B/B2C?
Если вы хотите работать с внутренними продуктами:
— Изучите язык бизнеса — забудьте про CAC/LTV, освойте операционную эффективность и ROI на процессы
— Научитесь управлять изменениями — 70% вашего времени будет уходить не на продукт, а на коммуникацию и обучение
— Понимайте внутреннюю политику — в B2E важно не только «что делать», но и «кто за это отвечает»
— Освойте работу с косвенными метриками — научитесь связывать использование продукта с бизнес-результатами

B2E-менеджер — это не «второсортный» PM. Это гибрид стратега, дипломата, HR-эксперта и адвоката сотрудников. Успешный B2E-продукт не измеряется в деньгах напрямую — он измеряется в часах, сэкономленных сотрудникам, в их удовлетворённости и в способности компании адаптироваться к изменениям.

#product #b2e #management #internaltools
Please open Telegram to view this post
VIEW IN TELEGRAM
11🔥6🤩3👍2👏1
Пятничный мем

#memes
😁27🔥8
Друзья, всех с новым годом! Спасибо, что вы есть. Пусть всё складывается только лучшим образом!
21🔥8🥰6
Всем привет! 👋

Количество подписчиков перевалило за 1000, а это повод познакомиться))

Я Данила Шевцов — продакт в Avito. До этого был продактом в Яндексе.
Работаю в основном над внутренними (B2E) продуктами — то есть теми, которые делают жизнь коллег внутри компаний чуть удобнее, а иногда и спасают от хаоса.

Чем я занимался?
→ Системы управления проектами и знаниями
→ Платформы документирования
→ Feature store и ERP-системы
→ Сейчас — BI-система, которую мы строим своими руками

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

Моя страсть?
Я обожаю данные. Если что, лезу в логи, фронтовые ручки и raw-данные. В этой связи очень рад быть продактом BI-системы - тут и данные и продуктовые задачи.

Почему я пишу сюда?
Работаю в IT уже не первый год. За это время накопил практический опыт в product management, аналитике данных, системном дизайне и командной коммуникации.
Хочу делиться не абстрактными теориями, а реальными кейсами, лайфхаками и инсайтами, которые работают в повседневной работе. Здесь нет «воды» — только проверенные практики, которые помогут вам стать эффективнее в профессиональной деятельности.

Что ждёт тебя здесь?
— Реальные кейсы из Avito и Яндекса
— Практические гайды — по работе с API, SQL, метриками, Git и другим инструментам
— Лайфхаки и инструменты — от простых команд в браузере до продвинутых возможностей ИИ
— Технический ликбез — сложные темы (CLI, RAG, MCP) простыми словами для нетехнических специалистов
— Полезные ссылки, инструменты, книги
— И да, иногда будет юмор — потому что без него в продукте никак 😅

Подписывайся, если:
— Ты product-менеджер, аналитик или работаешь над цифровыми продуктами
— Хочешь понимать технический контекст, даже если не пишешь код
— Интересуешься инструментами ИИ для повышения продуктивности
— Ценишь конкретику вместо абстракций и готов(а) применять знания на практике
— Работаешь с внутренними корпоративными продуктами и ищешь способы улучшить adoption и UX


P.S. Я не продаю курсы, не делаю платные рекомендации и не пишу по заказу. Это мой канал — мои мысли, мой опыт, мои ошибки. Спасибо, что вы здесь ☕️
Please open Telegram to view this post
VIEW IN TELEGRAM
59🔥22🥰11🍾2
☕️ Миграция между системами

Сколько лет работаю в ИТ, постоянно сталкиваюсь с необходимостью "закапывания" (sunsetting) изживших себя сервисов и миграции на новые. Я столько раз "хоронил" старые сервисы, что уже чувствую себя похоронным агентом цифровых систем 😄 Каждый раз казалось, что это последняя миграция в моей жизни, но рынок не стоит на месте — технологии устаревают, требования меняются, и снова приходится собирать команду для "переезда".

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

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

Сохраняйте себе — пригодится, когда ваш руководитель скажет: "Нам нужно переехать на новую систему до конца квартала".😉

P.S. Решил написать этот пост, т.к. в работе как раз есть ещё один кандидат на закапывание 🪦

#lifehacks #howto #guides
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
12🔥8👍2👏1
☕️ Как «подружить» LLM с вашей PostgreSQL: лайфхак для быстрой аналитики

Если ваш сервис использует в качестве БД PostgreSQL и вы часто пишете SQL-запросы для аналитики — вам знакома боль: «а какая там колонка?», «как называется связующая таблица?», «какие индексы есть?».

Обычно лезут в pg_catalog или DBeaver, но есть способ проще и удобнее — особенно если вы используете LLM для генерации запросов.

Забудьте про системные таблицы — встречайте pg_dump 🔥 — утилиту командной строки из поставки PostgreSQL, которая создаёт резервные копии БД. Но её можно использовать и для экспорта схемы данных в читаемом виде. И это идеальный способ получить полный контекст для LLM.

(👀 см. карточки ↑)

⚠️ Важные нюансы
— Фильтруйте чувствительные данные перед отправкой в LLM: удалите комментарии с секретами, триггеры с логикой бизнес-правил.
— Обрезайте большой дамп — если схема огромная, оставьте только релевантные таблицы для задачи.
— Используйте .pgpass — чтобы не вводить пароль каждый раз при запуске pg_dump.

Промпт для генерации описания таблиц на основе схемы из pg_dump:

Проанализируй схему PostgreSQL, полученную через утилиту pg_dump (включая CREATE TABLE-запросы, комментарии к таблицам и колонкам, а также определения внешних ключей), и сформируй структурированное описание каждой таблицы в следующем формате:

# Описание таблиц BI-системы

## Хранилище данных: PostgreSQL

### Таблица: [название таблицы]
**Описание:** [Текст из COMMENT ON TABLE. Если комментарий отсутствует, сформулируй краткое описание на основе названия таблицы и контекста.]

**Колонки:**
- **[имя колонки]** ([тип данных]): [Текст из COMMENT ON COLUMN. Если комментарий отсутствует, опиши назначение на основе названия колонки и типа данных. Для внешних ключей добавь: "Ссылка на [таблица].[колонка] ([пояснение связи, например: 'определяет контекст видимости', 'используется для проверки условий']".]

**Бизнес-логика:**
- [Перечисли ключевые аспекты логики на основе:
1. Связей через внешние ключи (например: "Связь с [таблица] через [колонка] определяет [логика]"),
2. Флагов/статусов (например: "Использование флага [колонка] позволяет [действие]"),
3. Контекста из комментариев (например: "Алерты срабатывают при [условие] на основе данных из [таблица]").
Каждый пункт должен начинаться с тире и содержать пояснение, как колонка или связь влияет на бизнес-процессы.]

---

Требования к оформлению:
1. Используй строгую структуру с markdown-заголовками (###, **, -).
2. Для внешних ключей в разделе "Колонки" всегда указывай связанную таблицу и логику связи (например: "Ссылка на queries.id, по результатам которого проверяются условия алерта").
3. В "Бизнес-логике" фокусируйся на взаимодействии таблиц, условиях срабатывания, правах доступа и других бизнес-аспектах (не технических деталях).
4. Если в схеме отсутствуют комментарии, сделай обоснованные выводы на основе названий колонок и типов данных (например, `is_active` → "Флаг активности записи").
5. Не добавляй информацию, которой нет в схеме (только то, что можно вывести из pg_dump и логических связей).

Пример корректного описания для таблицы alerts (как в приложенном файле) должен быть воспроизведен для каждой таблицы в схеме.


🤌 Итого
pg_dump — это не только для бэкапов. Это мощный инструмент для ускорения работы с данными, особенно в связке с LLM. Вы экономите время на рутине и фокусируетесь на том, что действительно важно — анализе и принятии решений.

См.также
Как писать SQL-запросы с помощью LLM: гайд для менеджеров без аналитиков
Pg_dump документация

#tips #llm #sql #analytics
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥75👍2