⚙️ Внутренние vs Внешние. Разница в подходах к продуктам
Уже продолжительное время занимаюсь развитием в основном "внутренних" продуктов компаний — тех, что используются сотрудниками.
Решил порефлексировать на тему различий в подходах к управлению внешних и внутренних продуктов. Вот что из этого вышло:
🛠 Внутренние продукты
❶ Фокус на внутренних потребностях
— Сбор требований от разных команд (разработки, аналитики, маркетинга).
— Баланс между запросами разных отделов (например, между удобством и безопасностью).
❷ Быстрое внедрение
— Нужно быстро реагировать на запросы, так как продукт напрямую влияет на внутренние процессы.
— Релизы могут быть чаще, но при этом стабильность и надежность критичны.
❸ Коммуникация и продвижение
— Нужно "продавать" продукт внутри компании, убеждать команды в его пользе.
— Организация обучения и поддержки пользователей (сотрудников).
❹ Метрики
— Измерение внутреннего impact (например, рост adoption rate, снижение времени на тестирование).
— Аналитика, как продукт помогает командам достигать их целей.
❺ Технические требования
— Интеграция с внутренними системами (IDM, CRM, ERP....).
— Безопасность и соответствие корпоративным стандартам (например, GDPR, внутренним политикам).
🔸 Основные вызовы
— Сопротивление внутри компании :
— Коллеги могут противиться нововведениям из-за инерции или непонимания выгод.
— Как решить : Показывать прямые выгоды (например, сокращение времени на задачи).
— Баланс между удобством и контролем :
— Внутренние продукты часто требуют соблюдения политик безопасности, что может усложнить UX.
— Пример : ERP-система с жесткой политикой доступа, но сложным интерфейсом.
— Низкий приоритет у стейкхолдеров :
— Внешние продукты чаще видят как приоритет, а внутренние — как «неочевидные» затраты.
— Решение : Использовать методы вроде Business Value Analysis для доказательства ROI.
🎁 Внешние продукты
❶ Фокус на пользователях и рынке
— Исследование внешних потребностей через интервью, опросы, A/B-тесты.
— Конкуренция и анализ трендов.
❷ Монетизация
— Разработка стратегий монетизации (подписки, реклама, премиум-функции).
❸ Масштабируемость
— Подготовка к росту аудитории и нагрузки.
— Интернационализация/локализация (если продукт глобальный).
❹ Юзабилити
— Простота и интуитивность для непрофессиональных пользователей.
❺ ROI
— Четкий расчет ROI через внешние метрики (например, доход, retention).
🔸 Основные вызовы
— Конкуренция и рыночные требования :
— Нужно оперативно реагировать на изменения (например, новые технологии или конкуренты).
— Пользовательский опыт (UX) :
— Внешние продукты требуют интуитивного дизайна и поддержки разных устройств.
— Регуляторные и юридические риски :
— Например, GDPR для продуктов с обработкой данных.
Итого
Важно :
— Для внутренних продуктов: фокус на бизнес-процессы и взаимодействие с отделами .
— Для внешних: фокус на UX , рыночные тренды и ROI .
Успех в обоих случаях зависит от понимания контекста, но подходы к управлению, коммуникации и приоритизации — разные.
#product #management #IT #approach
Уже продолжительное время занимаюсь развитием в основном "внутренних" продуктов компаний — тех, что используются сотрудниками.
Решил порефлексировать на тему различий в подходах к управлению внешних и внутренних продуктов. Вот что из этого вышло:
🛠 Внутренние продукты
❶ Фокус на внутренних потребностях
— Сбор требований от разных команд (разработки, аналитики, маркетинга).
— Баланс между запросами разных отделов (например, между удобством и безопасностью).
❷ Быстрое внедрение
— Нужно быстро реагировать на запросы, так как продукт напрямую влияет на внутренние процессы.
— Релизы могут быть чаще, но при этом стабильность и надежность критичны.
❸ Коммуникация и продвижение
— Нужно "продавать" продукт внутри компании, убеждать команды в его пользе.
— Организация обучения и поддержки пользователей (сотрудников).
❹ Метрики
— Измерение внутреннего impact (например, рост adoption rate, снижение времени на тестирование).
— Аналитика, как продукт помогает командам достигать их целей.
❺ Технические требования
— Интеграция с внутренними системами (IDM, CRM, ERP....).
— Безопасность и соответствие корпоративным стандартам (например, GDPR, внутренним политикам).
🔸 Основные вызовы
— Сопротивление внутри компании :
— Коллеги могут противиться нововведениям из-за инерции или непонимания выгод.
— Как решить : Показывать прямые выгоды (например, сокращение времени на задачи).
— Баланс между удобством и контролем :
— Внутренние продукты часто требуют соблюдения политик безопасности, что может усложнить UX.
— Пример : ERP-система с жесткой политикой доступа, но сложным интерфейсом.
— Низкий приоритет у стейкхолдеров :
— Внешние продукты чаще видят как приоритет, а внутренние — как «неочевидные» затраты.
— Решение : Использовать методы вроде Business Value Analysis для доказательства ROI.
🎁 Внешние продукты
❶ Фокус на пользователях и рынке
— Исследование внешних потребностей через интервью, опросы, A/B-тесты.
— Конкуренция и анализ трендов.
❷ Монетизация
— Разработка стратегий монетизации (подписки, реклама, премиум-функции).
❸ Масштабируемость
— Подготовка к росту аудитории и нагрузки.
— Интернационализация/локализация (если продукт глобальный).
❹ Юзабилити
— Простота и интуитивность для непрофессиональных пользователей.
❺ ROI
— Четкий расчет ROI через внешние метрики (например, доход, retention).
🔸 Основные вызовы
— Конкуренция и рыночные требования :
— Нужно оперативно реагировать на изменения (например, новые технологии или конкуренты).
— Пользовательский опыт (UX) :
— Внешние продукты требуют интуитивного дизайна и поддержки разных устройств.
— Регуляторные и юридические риски :
— Например, GDPR для продуктов с обработкой данных.
Итого
Продакт-менеджер внутренних продуктов — архитектор эффективности , который оптимизирует процессы.
Продакт-менеджер внешних продуктов — архитектор пользовательской ценности , который борется за рынок.
Важно :
— Для внутренних продуктов: фокус на бизнес-процессы и взаимодействие с отделами .
— Для внешних: фокус на UX , рыночные тренды и ROI .
Успех в обоих случаях зависит от понимания контекста, но подходы к управлению, коммуникации и приоритизации — разные.
#product #management #IT #approach
❤5🔥3👍1🆒1
🗳 Data Pipeline Overview: Как данные становятся ценным ресурсом
Конвейер данных — это система, которая автоматизирует движение данных от источников до конечных пользователей. Она преобразует сырые данные в полезную для бизнеса информацию.
Сегодня разберём очередную схему от ByteByteGo и посмотрим на типовые этапы конвейера:
❶ Collect (Сбор данных)
Данные собираются из разных источников:
— Data Stores : базы данных, CRM, ERP (например, записи заказов).
— Data Streams : реальные события (клики, логи серверов).
— Applications : мобильные приложения, IoT-устройства.
❷ Ingest (Загрузка данных)
Задача — загрузить данные в систему конвейера.
Инструменты :
— Apache Kafka: для потоковой передачи данных в реальном времени.
— Amazon Kinesis : обработка больших объемов данных в режиме реального времени.
Типы обработки :
— Batch Processing : обработка данных порциями (например, ежедневный отчет).
— Stream Processing : обработка данных «на лету» (например, мониторинг транзакций).
❸ Store (Хранение данных)
Где хранятся данные :
— Data Lake : Необработанные данные (например, Amazon S3, HDFS).
— Data Warehouse : структурированные данные для аналитики (Snowflake, Redshift).
— Data Lakehouse : комбинация озера и хранилища (Delta Lake, Azure Synapse)
❹ Compute (Обработка данных)
Цель —- преобразовать данные в формат, удобный для анализа.
ETL vs ELT :
— ETL : Extract → Transform → Load (преобразование до загрузки).
— ELT : Extract → Load → Transform (преобразование после загрузки).
Инструменты :
— Apache Spark - для пакетной обработки.
— Apache Flink - для потоковой обработки.
❺ Consume (Использование данных)
Как данные помогают бизнесу :
— Business Intelligence - инструменты вроде Datalens,Tableau для создания дашбордов.
— Self-Service Analytics - платформы типа Looker для самостоятельного анализа.
— ML Services - использование данных для прогнозирования (например, рекомендации товаров).
— Data Science - исследования с помощью Jupyter Notebooks.
💪 Почему это важно?
— Автоматизация : устраняет рутину (например, ручной экспорт данных).
— Качество данных : очистка и стандартизация улучшают аналитику.
— Быстрое принятие решений : доступ к актуальным данным в реальном времени.
🤓 Основные вызовы
— Сложность интеграции : разные системы могут иметь разные форматы данных.
— Безопасность : защита данных во время передачи и хранения.
— Масштабируемость : конвейер должен расти вместе с объемом данных.
Итог
Конвейеры передачи данных — это «скелет», который позволяет компании быстро переходить от сырых данных к осмысленным решениям. Без них аналитика становится медленной, а бизнес — менее гибким.
👀 См.также
— Видео от ByteByteGo на тему "What is Data Pipeline?"
— Big Data Pipeline Cheatsheet for AWS, Azure, and Google Cloud
#data #pipeline #analytics #ByteByteGo
Конвейер данных — это система, которая автоматизирует движение данных от источников до конечных пользователей. Она преобразует сырые данные в полезную для бизнеса информацию.
Сегодня разберём очередную схему от ByteByteGo и посмотрим на типовые этапы конвейера:
❶ Collect (Сбор данных)
Данные собираются из разных источников:
— Data Stores : базы данных, CRM, ERP (например, записи заказов).
— Data Streams : реальные события (клики, логи серверов).
— Applications : мобильные приложения, IoT-устройства.
❷ Ingest (Загрузка данных)
Задача — загрузить данные в систему конвейера.
Инструменты :
— Apache Kafka: для потоковой передачи данных в реальном времени.
— Amazon Kinesis : обработка больших объемов данных в режиме реального времени.
Типы обработки :
— Batch Processing : обработка данных порциями (например, ежедневный отчет).
— Stream Processing : обработка данных «на лету» (например, мониторинг транзакций).
❸ Store (Хранение данных)
Где хранятся данные :
— Data Lake : Необработанные данные (например, Amazon S3, HDFS).
— Data Warehouse : структурированные данные для аналитики (Snowflake, Redshift).
— Data Lakehouse : комбинация озера и хранилища (Delta Lake, Azure Synapse)
❹ Compute (Обработка данных)
Цель —- преобразовать данные в формат, удобный для анализа.
ETL vs ELT :
— ETL : Extract → Transform → Load (преобразование до загрузки).
— ELT : Extract → Load → Transform (преобразование после загрузки).
Инструменты :
— Apache Spark - для пакетной обработки.
— Apache Flink - для потоковой обработки.
❺ Consume (Использование данных)
Как данные помогают бизнесу :
— Business Intelligence - инструменты вроде Datalens,Tableau для создания дашбордов.
— Self-Service Analytics - платформы типа Looker для самостоятельного анализа.
— ML Services - использование данных для прогнозирования (например, рекомендации товаров).
— Data Science - исследования с помощью Jupyter Notebooks.
💪 Почему это важно?
— Автоматизация : устраняет рутину (например, ручной экспорт данных).
— Качество данных : очистка и стандартизация улучшают аналитику.
— Быстрое принятие решений : доступ к актуальным данным в реальном времени.
🤓 Основные вызовы
— Сложность интеграции : разные системы могут иметь разные форматы данных.
— Безопасность : защита данных во время передачи и хранения.
— Масштабируемость : конвейер должен расти вместе с объемом данных.
Итог
Конвейеры передачи данных — это «скелет», который позволяет компании быстро переходить от сырых данных к осмысленным решениям. Без них аналитика становится медленной, а бизнес — менее гибким.
👀 См.также
— Видео от ByteByteGo на тему "What is Data Pipeline?"
— Big Data Pipeline Cheatsheet for AWS, Azure, and Google Cloud
#data #pipeline #analytics #ByteByteGo
❤2👍2🔥2
💼 Как управлять крупными проектами
В канале TeamLead Good Reads промелькнула статья, которая меня заинтересовала. Текст поста был суховат. Решил изучить первоисточник и изложить свою версию.
В статье автор Ben Kuhn делится своим опытом управления крупными проектами. Автор малоизвестен, но тезисы весьма интересны.
Итак — как управлять масштабными проектами:
❶ Фокусировка
Очистите расписание: для крупных проектов выделяйте 6+ часов в день . Это не столько про время, сколько про концентрацию на цели.
❷ Подробный план
Создайте план с четкими этапами и дедлайнами. План показывает, где вы отклоняетесь от графика, и позволяет вовремя скорректироваться.
❸ Цикл OODA (observe, orient, decide, act)
Цикл наблюдения, анализа, решения и действия:
— Наблюдение : отслеживайте прогресс.
— Ориентация : обновляйте приоритеты в документах.
— Действия : быстро разрешайте блокеры.
❹ Переизбыток коммуникации - это хорошо
Используйте телеграм-чаты и общие документы для отслеживания прогресса. Чем больше у команды контекста, тем лучше принимаются локальные решения.
❺ Делегирование
При команде >10 человек:
— Делегируйте управление
— Дайте ясные цели.
— Выбирайте лидеров, которые организованы и фокусированы , а не только технически сильны.
🛠 Инструменты успеха ответственного за проект
1. Weekly Meeting (Еженедельное совещание)
Что делать: запланируйте 30-минутную встречу с участниками проекта.
Адженда:
— Статус: Что сделано за неделю? Цели на следующую.
— Письменный brainstorm : участники пишут вопросы или идеи в чате (без голосового обсуждения).
— Обсуждение важного : решать самые острые вопросы вживую.
Когда увеличивать встречи :
— Сроки очень сжатые.
— Люди заняты не тем.
— Нужна оперативная помощь.
2. Landing Page / Working Doc (Главный документ проекта)
Что включить :
— Название : В URL или названии документа упомяните, что это часть большего проекта (например, go/project/subproject).
— Цель : Четко сформулируйте, что должен достичь проект, и как это связано с общими целями компании.
— Участники : Список людей, их роли и ссылка на Slack-канал.
— Ссылки : На документы, код, доски задач.
— План : Этапы проекта с дедлайнами.
— Заметки : Протоколы встреч, ключевые вопросы, риски.
3. План / Roadmap / Маршруты
Как составить :
— Разбейте цель на этапы с дедлайнами.
— Будьте честны с неопределенностью: «Дедлайн этапа 3: 15.09.2024, но мы на 70% уверены в этом сроке».
— Используйте вероятности: «Возможность завершить этап: 80%».
4. Чат-нормы
Правила :
— Все обсуждения — в общем чате, а не в личных сообщениях.
— Если кто-то пишет важное в личку, переносите это в общий чат.
— Избегайте длинных цепочек сообщений (centithreads). Можно делать треды
— Если цепочка получилась, напишите краткий итог для канала.
Пример : Вместо 20-сообщенийной ветки в Slack, создайте короткий отчет: «Итог: Найдена ошибка в коде. Иван исправит к пятнице».
5. Weekly Broadcast Updates (Еженедельные обновления)
Как писать :
— Кратко, без мелочей.
— Фокус на результатах , а не на действиях.
Пример: «Проект: Запуск ИИ-модели. Достижения: Точность выросла до 85%. Следующий этап: Тестирование в продакшене до 10.10.2024».
Где публиковать :
— В чате проекта.
Если проект часть большего, — кросс-пост в общий канал.
6. Retrospectives (Ретроспективы)
Как проводить :
— Частота : Раз в 2 недели для активных проектов.
— Формат :
Async brainstorm (13 минут): Участники пишут в документе: Что прошло хорошо? Что нужно улучшить?
Голосование : Сортируйте идеи по популярности .
Синхронное обсуждение : Обсуждайте самые важные пункты и выделяйте action items.
💡 Итого
Успешное управление проектом — это:
— Фокус на главных целях.
— План с четкими этапами.
— Скорость в принятии решений.
— Коммуникация , которая не оставляет вопросов без ответа.
#project #management #IT #team
В канале TeamLead Good Reads промелькнула статья, которая меня заинтересовала. Текст поста был суховат. Решил изучить первоисточник и изложить свою версию.
В статье автор Ben Kuhn делится своим опытом управления крупными проектами. Автор малоизвестен, но тезисы весьма интересны.
Итак — как управлять масштабными проектами:
❶ Фокусировка
Очистите расписание: для крупных проектов выделяйте 6+ часов в день . Это не столько про время, сколько про концентрацию на цели.
❷ Подробный план
Создайте план с четкими этапами и дедлайнами. План показывает, где вы отклоняетесь от графика, и позволяет вовремя скорректироваться.
❸ Цикл OODA (observe, orient, decide, act)
Цикл наблюдения, анализа, решения и действия:
— Наблюдение : отслеживайте прогресс.
— Ориентация : обновляйте приоритеты в документах.
— Действия : быстро разрешайте блокеры.
❹ Переизбыток коммуникации - это хорошо
Используйте телеграм-чаты и общие документы для отслеживания прогресса. Чем больше у команды контекста, тем лучше принимаются локальные решения.
❺ Делегирование
При команде >10 человек:
— Делегируйте управление
— Дайте ясные цели.
— Выбирайте лидеров, которые организованы и фокусированы , а не только технически сильны.
🛠 Инструменты успеха ответственного за проект
1. Weekly Meeting (Еженедельное совещание)
Что делать: запланируйте 30-минутную встречу с участниками проекта.
Адженда:
— Статус: Что сделано за неделю? Цели на следующую.
— Письменный brainstorm : участники пишут вопросы или идеи в чате (без голосового обсуждения).
— Обсуждение важного : решать самые острые вопросы вживую.
Когда увеличивать встречи :
— Сроки очень сжатые.
— Люди заняты не тем.
— Нужна оперативная помощь.
2. Landing Page / Working Doc (Главный документ проекта)
Что включить :
— Название : В URL или названии документа упомяните, что это часть большего проекта (например, go/project/subproject).
— Цель : Четко сформулируйте, что должен достичь проект, и как это связано с общими целями компании.
— Участники : Список людей, их роли и ссылка на Slack-канал.
— Ссылки : На документы, код, доски задач.
— План : Этапы проекта с дедлайнами.
— Заметки : Протоколы встреч, ключевые вопросы, риски.
3. План / Roadmap / Маршруты
Как составить :
— Разбейте цель на этапы с дедлайнами.
— Будьте честны с неопределенностью: «Дедлайн этапа 3: 15.09.2024, но мы на 70% уверены в этом сроке».
— Используйте вероятности: «Возможность завершить этап: 80%».
4. Чат-нормы
Правила :
— Все обсуждения — в общем чате, а не в личных сообщениях.
— Если кто-то пишет важное в личку, переносите это в общий чат.
— Избегайте длинных цепочек сообщений (centithreads). Можно делать треды
— Если цепочка получилась, напишите краткий итог для канала.
Пример : Вместо 20-сообщенийной ветки в Slack, создайте короткий отчет: «Итог: Найдена ошибка в коде. Иван исправит к пятнице».
5. Weekly Broadcast Updates (Еженедельные обновления)
Как писать :
— Кратко, без мелочей.
— Фокус на результатах , а не на действиях.
Пример: «Проект: Запуск ИИ-модели. Достижения: Точность выросла до 85%. Следующий этап: Тестирование в продакшене до 10.10.2024».
Где публиковать :
— В чате проекта.
Если проект часть большего, — кросс-пост в общий канал.
6. Retrospectives (Ретроспективы)
Как проводить :
— Частота : Раз в 2 недели для активных проектов.
— Формат :
Async brainstorm (13 минут): Участники пишут в документе: Что прошло хорошо? Что нужно улучшить?
Голосование : Сортируйте идеи по популярности .
Синхронное обсуждение : Обсуждайте самые важные пункты и выделяйте action items.
💡 Итого
Успешное управление проектом — это:
— Фокус на главных целях.
— План с четкими этапами.
— Скорость в принятии решений.
— Коммуникация , которая не оставляет вопросов без ответа.
#project #management #IT #team
❤4🔥2👍1🙏1
📝 "Почему" вместо "что": как объяснение причин экономит время и нервы
На днях в канале настенька и графики моей бывшей коллеги и друга Насти увидел пост про важность объяснений "почему" мы делаем так, а не иначе. Обычное "что" надо сделать — приносит мало пользы.
И правда, объяснять зачем — это не просто хороший тон, это необходимость. Особенно когда работаешь в команде или над проектом, который будет жить долго.
Вот несколько примеров из разных аспектов айтишечки, где этот принцип работает на все 100:
📚 Документация
❌ Плохо:
Это и так видно из названия. Зачем он нужен? В каких случаях использовать?
✅ Хорошо:
Почему это важно?
— Новые разработчики не потратят часы на тестирование "нерабочего" метода.
— QA поймет, какие сценарии проверять.
📋 Постановка задач
❌ Плохо:
Зачем? Может, это требование GDPR? Или маркетинг хочет аналитику?
✅ Хорошо:
Почему это важно?
— Разработчик не будет гадать, где поле должно быть обязательным.
— Тестировщик сразу поймет, какие кейсы проверять.
🔀 Pull Request'ы
❌ Плохо:
Какой баг? Почему решение верное?
✅ Хорошо:
Почему это важно?
— Ревьювер не утонет в догадках, а быстро проверит логику.
— Через месяц вы сами вспомните, почему сделали именно так.
👥 Встречи и обсуждения
❌ Плохо:
Почему не Python? Это критично для дедлайна?
✅ Хорошо:
Почему это важно?
— Команда видит, что решение взвешенное, а не "просто ради Go".
— Новые участники поймут контекст, даже пропустив обсуждение.
👀 Тестирование
❌ Плохо:
Какой email? Всем ли пользователям?
✅ Хорошо:
Почему это важно?
Тестировщик не потратит время на проверку "почему письмо не пришло".
🪄 Лайфхаки
— Везде, где возможно, добавляйте ссылки на контекст: задачи в таск-трекере, страницы в вики, чаты в телеграм.
— Если решение временное, пишите FIXME/TODO + дату:
— В сложных решениях оставляйте аргументы против альтернатив (например, "Выбрали Redis вместо Memcached из-за поддержки TTL на уровне ключей").
💡 Итого
Чем больше вы объясняете зачем, тем меньше времени команда тратит на "догадки" и тем выше качество продукта.
#softskills #management #bestpractices
На днях в канале настенька и графики моей бывшей коллеги и друга Насти увидел пост про важность объяснений "почему" мы делаем так, а не иначе. Обычное "что" надо сделать — приносит мало пользы.
И правда, объяснять зачем — это не просто хороший тон, это необходимость. Особенно когда работаешь в команде или над проектом, который будет жить долго.
Вот несколько примеров из разных аспектов айтишечки, где этот принцип работает на все 100:
📚 Документация
❌ Плохо:
API-метод /payments/cancel отменяет платежи
Это и так видно из названия. Зачем он нужен? В каких случаях использовать?
✅ Хорошо:
Метод /payments/cancel отменяет платежи до их подтверждения банком (статус pending). Используется, если пользователь передумал сразу после оплаты. Не работает для уже проведенных платежей (статус completed)
Почему это важно?
— Новые разработчики не потратят часы на тестирование "нерабочего" метода.
— QA поймет, какие сценарии проверять.
📋 Постановка задач
❌ Плохо:
Добавить поле 'регион' в форму регистрации
Зачем? Может, это требование GDPR? Или маркетинг хочет аналитику?
✅ Хорошо:
Добавить поле 'регион' в форму регистрации:
— Для пользователей из ЕС — обязательное (требования GDPR).
— Для остальных — опциональное (поможет в локализации)
Почему это важно?
— Разработчик не будет гадать, где поле должно быть обязательным.
— Тестировщик сразу поймет, какие кейсы проверять.
🔀 Pull Request'ы
❌ Плохо:
Исправил баг с авторизацией
Какой баг? Почему решение верное?
✅ Хорошо:
Исправил баг с авторизацией:
— Проблема: Токен обновлялся даже при неактивной сессии (ошибка 401).
— Решение: Добавил проверку session.isActive() перед обновлением.
— Почему это безопасно: Метод isActive() покрыт интеграционными тестами
Почему это важно?
— Ревьювер не утонет в догадках, а быстро проверит логику.
— Через месяц вы сами вспомните, почему сделали именно так.
👥 Встречи и обсуждения
❌ Плохо:
Нужно переписать модуль X на Go
Почему не Python? Это критично для дедлайна?
✅ Хорошо:
Переписываем модуль X на Go:
— Причина: Текущая реализация на Python не справляется с нагрузкой > 10k RPS.
— Альтернативы: Рассмотрели кеширование, но это лишь временное решение.
— Риски: Миграция займет 2 недели, но снизит затраты на инфраструктуру.
Почему это важно?
— Команда видит, что решение взвешенное, а не "просто ради Go".
— Новые участники поймут контекст, даже пропустив обсуждение.
👀 Тестирование
❌ Плохо:
Тест: проверить отправку email после регистрации
Какой email? Всем ли пользователям?
✅ Хорошо:
Тест: проверить отправку email после регистрации:
— Кейс: Письмо с подтверждением отправляется только новым пользователям (поле is_new=True).
— Почему: Спам-фильтры банят, если отправлять повторно
Почему это важно?
Тестировщик не потратит время на проверку "почему письмо не пришло".
🪄 Лайфхаки
— Везде, где возможно, добавляйте ссылки на контекст: задачи в таск-трекере, страницы в вики, чаты в телеграм.
— Если решение временное, пишите FIXME/TODO + дату:
// TODO: Удалить после миграции на Logbroker (дедлайн: 01.01.2024) — В сложных решениях оставляйте аргументы против альтернатив (например, "Выбрали Redis вместо Memcached из-за поддержки TTL на уровне ключей").
💡 Итого
Чем больше вы объясняете зачем, тем меньше времени команда тратит на "догадки" и тем выше качество продукта.
#softskills #management #bestpractices
👍11❤10🔥5👎1😁1
📝 Friction Logs: как найти скрытые боли пользователей в вашем продукте
Наткнулся на старую статью в канале Teamlead Good Reads. Автор статьи Shai Ben-David предлагает уникальный метод — friction logs (логи трений). Это детальные записи всех моментов, которые вызывают неудобства при использовании продукта.
Посмотрим, как это работает и как использовать:
📄 Что такое friction logs?
Это документ с описанием всех «затыков» , которые возникают при взаимодействии с продуктом:
— Ошибки, которые сложно исправить.
— Непонятные инструкции.
— Мелкие детали (например, непонятный шрифт или медленные переходы).
🤷♂️ Когда нужно использовать friction logs?
Вы разрабатываете ПО — чтобы улучшить UX.
Исследуете продукт конкурента — чтобы найти их слабые места.
Учите продакт-менеджмент — тренируете навык «смотреть глазами пользователя».
📖 Как создать friction log: пошаговая инструкция
❶ Подготовка
Создайте документ : Используйте Notion, Google Docs, Вики, да что удобно
Определите роль и сценарий :
— Кто вы? Например: «Я разработчик мобильного чата».
— Что делаете? «Хочу настроить плату за подписку».
— Критерии успеха : «Нет редиректов, все на iOS».
Не ищите информацию заранее : Попробуйте пользоваться продуктом «с нуля», как новый пользователь.
❷ Используйте продукт
Записывайте всё :
— Даже мелочи (например, «неудобно найти настройки»).
— Отмечайте эмоции: красный/желтый/зеленый эмодзи для сортировки проблем.
— Делайте скриншоты. Важно фиксировать проблемные моменты
❸ Анализ
Выделите главные проблемы :
— Пример из лога ChatGPT : сложная регистрация отпугивает пользователей.
— Пример из лога Bing AI : неясные подсказки в поиске.
Сортируйте по важности :
— Выберите 3 главных трения , которые нужно исправить в первую очередь.
❹ Передайте команде
— Не требуйте решить всё. Укажите, что многие проблемы — результат компромиссов (например, скорость vs. безопасность).
Готовьте контекст. Ответьте на вопросы: «Почему это важно?», «Как это исправить?».
⚙️ Почему это работает?
Помогает найти блокеры :
— Если пользователь не может найти кнопку «Оплатить», он уйдёт в конкуренты.
— Пример из лога Zapier : ошибка, от которой невозможно восстановиться без поддержки.
Фокус на деталях :
— Не только «большие» проблемы, но и мелочи (например, отсутствие подсказки при наведении).
Прозрачность для команды :
— Friction logs становятся «картами» для улучшения продукта.
🪧 Пример
Ситуация : Тестирование системы оплаты в мобильном приложении.
Затык : Неясная инструкция по добавлению карты.
Friction log запись :
— Проблема : Не понятно, почему не активна кнопка «Сохранить».
— Эмоции : 🟥 (очень раздражает).
— Скриншот : Картинка с нерабочей кнопкой.
Анализ :
— Эта проблема попадает в топ-3.
— Причина: Недостаточная валидация данных.
🪄 Советы от автора
Имитируйте пользователя. Даже если вы знаете продукт, ведите себя как новичок.
Отслеживайте эмоции. Замечайте моменты, когда вы «злились» или «сдались».
Не перегружайте команду. Покажите 3 главных проблемы, а не все мелочи.
❯ Посмотреть примеры
💡 Итог
Friction logs — это инструмент, который помогает «слышать» пользователей , даже если они не пишут в поддержку.
Если ваш продукт застопорился — сделайте friction log. Возможно, вы обнаружите, что пользователи не доходят даже до главного экрана.
#UX #analytics #product #IT #testing
Наткнулся на старую статью в канале Teamlead Good Reads. Автор статьи Shai Ben-David предлагает уникальный метод — friction logs (логи трений). Это детальные записи всех моментов, которые вызывают неудобства при использовании продукта.
Посмотрим, как это работает и как использовать:
📄 Что такое friction logs?
Это документ с описанием всех «затыков» , которые возникают при взаимодействии с продуктом:
— Ошибки, которые сложно исправить.
— Непонятные инструкции.
— Мелкие детали (например, непонятный шрифт или медленные переходы).
🤷♂️ Когда нужно использовать friction logs?
Вы разрабатываете ПО — чтобы улучшить UX.
Исследуете продукт конкурента — чтобы найти их слабые места.
Учите продакт-менеджмент — тренируете навык «смотреть глазами пользователя».
📖 Как создать friction log: пошаговая инструкция
❶ Подготовка
Создайте документ : Используйте Notion, Google Docs, Вики, да что удобно
Определите роль и сценарий :
— Кто вы? Например: «Я разработчик мобильного чата».
— Что делаете? «Хочу настроить плату за подписку».
— Критерии успеха : «Нет редиректов, все на iOS».
Не ищите информацию заранее : Попробуйте пользоваться продуктом «с нуля», как новый пользователь.
❷ Используйте продукт
Записывайте всё :
— Даже мелочи (например, «неудобно найти настройки»).
— Отмечайте эмоции: красный/желтый/зеленый эмодзи для сортировки проблем.
— Делайте скриншоты. Важно фиксировать проблемные моменты
❸ Анализ
Выделите главные проблемы :
— Пример из лога ChatGPT : сложная регистрация отпугивает пользователей.
— Пример из лога Bing AI : неясные подсказки в поиске.
Сортируйте по важности :
— Выберите 3 главных трения , которые нужно исправить в первую очередь.
❹ Передайте команде
— Не требуйте решить всё. Укажите, что многие проблемы — результат компромиссов (например, скорость vs. безопасность).
Готовьте контекст. Ответьте на вопросы: «Почему это важно?», «Как это исправить?».
⚙️ Почему это работает?
Помогает найти блокеры :
— Если пользователь не может найти кнопку «Оплатить», он уйдёт в конкуренты.
— Пример из лога Zapier : ошибка, от которой невозможно восстановиться без поддержки.
Фокус на деталях :
— Не только «большие» проблемы, но и мелочи (например, отсутствие подсказки при наведении).
Прозрачность для команды :
— Friction logs становятся «картами» для улучшения продукта.
🪧 Пример
Ситуация : Тестирование системы оплаты в мобильном приложении.
Затык : Неясная инструкция по добавлению карты.
Friction log запись :
— Проблема : Не понятно, почему не активна кнопка «Сохранить».
— Эмоции : 🟥 (очень раздражает).
— Скриншот : Картинка с нерабочей кнопкой.
Анализ :
— Эта проблема попадает в топ-3.
— Причина: Недостаточная валидация данных.
🪄 Советы от автора
Имитируйте пользователя. Даже если вы знаете продукт, ведите себя как новичок.
Отслеживайте эмоции. Замечайте моменты, когда вы «злились» или «сдались».
Не перегружайте команду. Покажите 3 главных проблемы, а не все мелочи.
❯ Посмотреть примеры
💡 Итог
Friction logs — это инструмент, который помогает «слышать» пользователей , даже если они не пишут в поддержку.
Если ваш продукт застопорился — сделайте friction log. Возможно, вы обнаружите, что пользователи не доходят даже до главного экрана.
#UX #analytics #product #IT #testing
🔥6❤1
💡Проведение проблемных интервью
Разбирал документы в папке и наткнулся на файл - Практическое руководство по составлению скрипта для проведения проблемных интервью, который когда-то скачал у Сергея Тихомирова (@productclub).
Решил оформить его в виде карточек и поделиться с вами, так как это руководство действительно классное.
Проблемное интервью — это метод, который помогает перейти от гипотез к фактам.
Если хотите сделать продукт, который решает реальные проблемы:
❶ Начните с формулировки гипотезы
❷ Составьте скрипт интервью
❸ Сформулируйте дополнительные гипотезы
❹ Зафиксируйте результаты
Примеры скриптов и шаблонов — в приложении.
#interview #research #product
Разбирал документы в папке и наткнулся на файл - Практическое руководство по составлению скрипта для проведения проблемных интервью, который когда-то скачал у Сергея Тихомирова (@productclub).
Решил оформить его в виде карточек и поделиться с вами, так как это руководство действительно классное.
Проблемное интервью — это метод, который помогает перейти от гипотез к фактам.
Если хотите сделать продукт, который решает реальные проблемы:
❶ Начните с формулировки гипотезы
❷ Составьте скрипт интервью
❸ Сформулируйте дополнительные гипотезы
❹ Зафиксируйте результаты
Примеры скриптов и шаблонов — в приложении.
#interview #research #product
❤7🔥7👍2
💼 Вопросы к членам команды ИТ-проекта
Представьте, что вы пришли в новую команду и хотите узнать как всё устроено. Какие вопросы задать членам команды, чтобы собрать побольше контекста?
В этом поможет классная подборка с вопросами к членам команды, которой я пользовался каждый раз когда начинался новый проект.
В ней есть вопросы для следующих ролей:
— продакту,
— разработчику,
— дизайнеру,
— маркетологу,
— сотруднику поддержки,
— техническому писателю.
Можно использовать как шпаргалку/чек-лист не только когда пришли в новую команду, но и просто, чтобы ничего не забыть.
Каждый вопрос дополнен вариантом ответа — это может быть какой-то принцип, методология, фреймворк или просто решение из жизни.
Он не претендует на последнюю инстанцию, но поможет сориентироваться в ситуации или нащупать другое решение.
❯ Подробнее
#howto #tips #onboarding
Представьте, что вы пришли в новую команду и хотите узнать как всё устроено. Какие вопросы задать членам команды, чтобы собрать побольше контекста?
В этом поможет классная подборка с вопросами к членам команды, которой я пользовался каждый раз когда начинался новый проект.
В ней есть вопросы для следующих ролей:
— продакту,
— разработчику,
— дизайнеру,
— маркетологу,
— сотруднику поддержки,
— техническому писателю.
Можно использовать как шпаргалку/чек-лист не только когда пришли в новую команду, но и просто, чтобы ничего не забыть.
Каждый вопрос дополнен вариантом ответа — это может быть какой-то принцип, методология, фреймворк или просто решение из жизни.
Он не претендует на последнюю инстанцию, но поможет сориентироваться в ситуации или нащупать другое решение.
❯ Подробнее
#howto #tips #onboarding
👍5❤3🔥1
ИИ стремительно ворвался в нашу жизнь, привнеся множество новых понятий.
Давайте вместе разберёмся что есть что:
1. Machine Learning (Машинное обучение) — методы, где компьютеры учатся находить закономерности в данных через алгоритмы и статистику.
2. Deep Learning (Глубокое обучение) — подвид машинного обучения, где нейросети самостоятельно обучаются распознавать сложные паттерны в данных.
3. Neural Networks (Нейронные сети) — модели, имитирующие структуру мозга, состоящие из слоёв для анализа данных и выявления скрытых связей.
4. NLP (Обработка естественного языка) — технологии, позволяющие компьютерам понимать, анализировать и генерировать человеческий текст или речь.
5. Computer Vision (Компьютерное зрение) — алгоритмы, учащие машины «видеть» и интерпретировать изображения, видео или графику.
6. Reinforcement Learning (Обучение с подкреплением) — метод, где ИИ учится через пробу, ошибку и получение «наград» за правильные действия.
7. Generative Models (Генеративные модели) — инструменты, создающие новые данные (текст, изображения) на основе изученных примеров.
8. LLM (Большие языковые модели) — алгоритмы вроде GPT, которые генерируют тексты, отвечают на вопросы и имитируют человеческое мышление.
9. Transformers (Трансформеры) — архитектура ИИ, фокусирующаяся на ключевых элементах данных (например, словах в предложении).
10. Feature Engineering (Инженерия признаков) — создание дополнительных параметров в данных для улучшения обучения моделей.
11. Supervised Learning (Обучение с учителем) — обучение модели на данных с готовыми ответами (например, размеченные фото).
12. Bayesian Learning (Байесовское обучение) — подход, учитывающий вероятности и неопределенность в данных для гибких прогнозов.
13. Prompt Engineering (Инженерия запросов) — формулировка задач так, чтобы ИИ давал максимально релевантные ответы.
14. AI Agents (ИИ-агенты) — автономные программы, которые воспринимают среду, принимают решения и действуют (например, чат-боты).
15. Fine-Tuning Models (Дообучение моделей) — адаптация предобученной модели (например, GPT) под конкретные задачи.
16. Multimodal Models (Мультимодальные модели) — системы, работающие с разными типами данных: текстом, изображениями, аудио.
17. Embeddings (Эмбеддинги) — представление данных (слова, объекты) в виде числовых векторов для обработки компьютером.
18. Vector Search (Векторный поиск) — метод поиска похожих объектов (товаров, текстов) через сравнение их векторных представлений.
19. Model Evaluation (Оценка моделей) — проверка точности ИИ с помощью тестовых данных и метрик (например, точность, скорость).
20. AI Infrastructure (Инфраструктура ИИ) — аппаратное и программное обеспечение для запуска и масштабирования ИИ-систем.
Эти концепции важны для понимания, как работают современные ИИ-технологии: от чат-ботов до автономных машин.
С ними вы сможете:
— Выбирать подходящие инструменты для своих проектов.
— Разбираться в новостях и трендах ИИ.
— Грамотно формулировать задачи для нейросетей.
Источник: ByteByteGo
#ai #bytebytego #terms
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤3👍2⚡1
🎯 Сегментация пользователей: как не тратить ресурсы на «всех сразу»?
Вы когда-нибудь замечали, как одни продукты будто «угадывают» ваши потребности, а другие кажутся бесполезными? Или почему одни компании тратят бюджет на рекламу для «всех сразу», а другие — на узкие группы, получая в 10 раз больше откликов?
Это работает сегментация — не просто маркетинговый трюк, а стратегия выживания.
Зачем сегментировать?
— Экономия ресурсов. В первую очередь для того, чтобы эффективно распределить ваши ограниченные ресурсы (бюджет, время, команда) и получить бОльшую отдачу.
— Точность анализа. Узкие сегменты проще тестировать и оптимизировать.
— Персонализация. 72% потребителей взаимодействуют только с персонализированным контентом (по данным SmarterHQ).
— Рост лояльности. Когда клиент чувствует, что его потребности учитывают, он чаще остаётся с брендом.
Цели сегментации могут отличаться для внешних продуктов (увеличение продаж, прибыли, удержание клиентов) и внутренних (повышение эффективности работы сотрудников, снижение времени на задачи, улучшение качества данных, повышение удовлетворенности работой).
Как сегментировать?
Существует несколько подходов к разделению аудитории:
— Демографический (возраст, пол, доход). Можно выявить через опросы, аналитику (Яндекс.Метрику)
— Географический (регион, город). Смотрим геоданные, локальные тренды
— Поведенческий (частота использования, типы транзакций). Heatmap, A/B-тесты
— Психографический (интересы, ценности, образ жизни). Соцсети, интервью, анализ контента
— Ценностный (готовность платить, потребности). RFM-анализ, NPS-опросы
и другие.
Для внутренних продуктов:
— роль и уровень доступа (аналитики, руководители, менеджеры, разработчики)
— бизнес-направление (продажи, финансы, HR, логистика)
— уровень цифровой грамотности (эксперты, новички)
— частота использования (ежедневно, эпизодически)
— влияние на бизнес-процессы (ключевые пользователи, исполнители)
Как понять, для какого сегмента делать фичи в первую очередь?
Важно выбрать не просто «удобный» сегмент, а самый выгодный.
— Правило 80/20: 20% сегментов приносят 80% прибыли. Сфокусируйтесь на них
— Оцените влияние: какие сегменты больше всего влияют на бизнес-результаты (например, руководители, принимающие стратегические решения)
— Анализ затрат: где улучшение продукта даст максимальный ROI (например, автоматизация рутинных задач для операторов)
Делать фичи только для одного сегмента или сразу для всех?
Баланс — ключ.
— Основной сегмент : 70% усилий — фичи, которые решают их боли.
— Второстепенные : 20% — доработки для других групп (например, улучшение UI для новичков).
— Эксперименты : 10% — тесты для новых сегментов (например, интеграция с API для продвинутых пользователей).
Советы для эффективной сегментации
— Не перегружайте систему. Много сегментов усложняет управление. Начните с 3–5 ключевых.
— Обновляйте данные. Потребности клиентов меняются: например, после пандемии спрос на удаленные инструменты вырос, а на офлайн-сервисы упал.
— Тестируйте гипотезы. Даже «идеальный» сегмент может не откликнуться на предложение.
— Интегрируйте сегментацию во все команды - все должны работать с единой базой.
— Избегайте стереотипов. Не все компании интересуются цифровизацией. Проверяйте данные.
💡 Итого
Сегментация — это не разовый анализ, а процесс. Даже если вы не собрали идеальные данные, начните с простых вопросов:
— Кто использует наш продукт?
— Какие задачи они решают?
— Где они тратят время/деньги?
P.S. Поделитесь в комментариях, как вы сегментируете свою аудиторию? Возможно, у вас есть кейсы, которые вдохновят других!
#product #users #analytics
Вы когда-нибудь замечали, как одни продукты будто «угадывают» ваши потребности, а другие кажутся бесполезными? Или почему одни компании тратят бюджет на рекламу для «всех сразу», а другие — на узкие группы, получая в 10 раз больше откликов?
Это работает сегментация — не просто маркетинговый трюк, а стратегия выживания.
Зачем сегментировать?
— Экономия ресурсов. В первую очередь для того, чтобы эффективно распределить ваши ограниченные ресурсы (бюджет, время, команда) и получить бОльшую отдачу.
— Точность анализа. Узкие сегменты проще тестировать и оптимизировать.
— Персонализация. 72% потребителей взаимодействуют только с персонализированным контентом (по данным SmarterHQ).
— Рост лояльности. Когда клиент чувствует, что его потребности учитывают, он чаще остаётся с брендом.
Цели сегментации могут отличаться для внешних продуктов (увеличение продаж, прибыли, удержание клиентов) и внутренних (повышение эффективности работы сотрудников, снижение времени на задачи, улучшение качества данных, повышение удовлетворенности работой).
Как сегментировать?
Существует несколько подходов к разделению аудитории:
— Демографический (возраст, пол, доход). Можно выявить через опросы, аналитику (Яндекс.Метрику)
— Географический (регион, город). Смотрим геоданные, локальные тренды
— Поведенческий (частота использования, типы транзакций). Heatmap, A/B-тесты
— Психографический (интересы, ценности, образ жизни). Соцсети, интервью, анализ контента
— Ценностный (готовность платить, потребности). RFM-анализ, NPS-опросы
и другие.
Для внутренних продуктов:
— роль и уровень доступа (аналитики, руководители, менеджеры, разработчики)
— бизнес-направление (продажи, финансы, HR, логистика)
— уровень цифровой грамотности (эксперты, новички)
— частота использования (ежедневно, эпизодически)
— влияние на бизнес-процессы (ключевые пользователи, исполнители)
Правила создания сегментов:
Измеримость: данные должны быть количественно оценены.
Доступность: возможность достичь сегмент через каналы коммуникации.
Целесообразность: сегмент должен быть достаточно большим для окупаемости.
Действенность: реагирование на маркетинговые усилия.
Как понять, для какого сегмента делать фичи в первую очередь?
Важно выбрать не просто «удобный» сегмент, а самый выгодный.
— Правило 80/20: 20% сегментов приносят 80% прибыли. Сфокусируйтесь на них
— Оцените влияние: какие сегменты больше всего влияют на бизнес-результаты (например, руководители, принимающие стратегические решения)
— Анализ затрат: где улучшение продукта даст максимальный ROI (например, автоматизация рутинных задач для операторов)
Делать фичи только для одного сегмента или сразу для всех?
Баланс — ключ.
— Основной сегмент : 70% усилий — фичи, которые решают их боли.
— Второстепенные : 20% — доработки для других групп (например, улучшение UI для новичков).
— Эксперименты : 10% — тесты для новых сегментов (например, интеграция с API для продвинутых пользователей).
Пример:
Notion начал с узкого сегмента разработчиков (основной), затем добавил функции для маркетологов (второстепенный) и экспериментировал с образовательными инструментами (эксперименты).
Советы для эффективной сегментации
— Не перегружайте систему. Много сегментов усложняет управление. Начните с 3–5 ключевых.
— Обновляйте данные. Потребности клиентов меняются: например, после пандемии спрос на удаленные инструменты вырос, а на офлайн-сервисы упал.
— Тестируйте гипотезы. Даже «идеальный» сегмент может не откликнуться на предложение.
— Интегрируйте сегментацию во все команды - все должны работать с единой базой.
— Избегайте стереотипов. Не все компании интересуются цифровизацией. Проверяйте данные.
💡 Итого
Сегментация — это не разовый анализ, а процесс. Даже если вы не собрали идеальные данные, начните с простых вопросов:
— Кто использует наш продукт?
— Какие задачи они решают?
— Где они тратят время/деньги?
P.S. Поделитесь в комментариях, как вы сегментируете свою аудиторию? Возможно, у вас есть кейсы, которые вдохновят других!
#product #users #analytics
❤5🔥3👍1
Сегодня расскажу про один из любимых инструментов, про который я бы хотел узнать как можно раньше, когда попал в ИТ — DevTools (Developer Tools). Это встроенные в браузер (Yandex, Chrome, Firefox, Safari, Edge), инструменты, которые позволяют анализировать, тестировать и оптимизировать сайт/веб-приложение/сервис.
Я не разработчик, но эти инструменты помогают и мне быстрее решать проблемы, экономить время команды. Делюсь личными кейсами, как я использую DevTools в повседневной работе:
🎨 Вкладка "Elements"
Когда дизайнеры или разработчики спорят о том, как лучше сделать, можно создать «живой» прототип в DevTools:
— Убираю лишнее. Например, скрываю пункты меню или баннеры, чтобы показать, как будет выглядеть страница после оптимизации. Делаю скриншот — и у команды уже есть визуальная база для обсуждения.
— Дублирую элементы. Если нужно добавить новый блок, я копирую существующий, меняю текст и цвет — и сразу вижу, как это повлияет на макет.
— Сохраняю SVG. Иногда нужно передать иконку дизайнеру. Выделяю SVG-элемент в коде, копирую его и сохраняю как .svg-файл — готовый исходник без лишних запросов к команде.
Пример
На встрече спорили, куда поставить кнопку. За 5 минут отредактировал HTML, сделал скриншот и отправил всем — проблема решилась без долгих обсуждений.
💬 Вкладка "Console"
Одна из моих любимых. Тут можно увидеть логи веб-приложения, но чаще всего я использую её для взаимодействия с сайтом через js-скрипты. Введите
document.querySelector('h1').style.color = 'red' прямо в консоль — это изменит цвет заголовка.Если команда разработчиков работает над интеграцией с внешним API, я часто проверяю его работу самостоятельно. Например:
— Модифицирую запросы. Копирую fetch-запрос из кода, меняю параметры (например, лимит записей с 10 до 1000), чтобы получить все данные за один раз. Это помогает сразу увидеть, как API ведет себя при больших нагрузках или как выглядит ответ.
— Тестирую гипотезы. Если пользователи жалуются на неработающую кнопку, я запускаю функцию вручную через консоль, чтобы понять, где проблема — в интерфейсе или бэкенде.
— Смотрю логи ошибок, которые возникают при загрузке страницы (например, «Uncaught TypeError»).
Пример
Нужно было выгрузить много данных по каждой из категорий. Написал js-скрипт, который по АПИ вытащил категории, потом по каждой из категорий вытащил записи. В итоге получил полные данные сервиса, которые смог потом уже проанализировать в Excel.
🌐 Вкладка "Network"
Отображает все запросы, которые браузер делает при загрузке страницы: картинки, скрипты, стили, API-запросы и т.д. Здесь видно время загрузки, размер файлов, статус ответа сервера (успешно, ошибка и т.д.).
Тут я чаще всего:
— Смотрю АПИ-запросы, чтобы скопировать их и использовать на вкладке Console
— Смотрю что фронт отправил на бэк (request), и что бэк прислал на фронт (response)
— Используя фильтр Media скачиваю видео и аудио с сайтов 🏴☠️
Пример
Надо было получить список всех элементов меню. На вкладке Network нашел запрос, который получал данные для меню, скопировал response, сконвертировал в Excel и использовал при формировании ТЗ на разработку.
Остальные вкладки я использую редко, но если кратко вот их назначение:
— 🧠 Sources — скачиваю изображения, изучаю исходники и отлаживаю JS.
— ⚡️ Performance — тестирую производительность страницы.
— 🧠 Memory — отслеживаю утечки памяти.
— 📁 Application — управляю кэшем, куками.
DevTools — это не только для технарей, немного практики — и вы начнете видеть в них помощника, который упрощает жизнь в ИТ-проектах.
В этой статье на Хабре можно найти несколько классных лайфхаков, которые пригодятся не только в работе 😜.
🔗 См. также
Новичкам
— Intro Video от команды Chrome
— DevTools (Документация)
— Обзор SkillFactory
— Обзор HTML-academy
Бывалым
— Одно из многочисленных видео Никиты Дубко (devtools-евангелиста)
— Официальные советы Chrome DevTools
— DevToolsTips.org — подборка практических примеров.
— Can I dev tools? — интерактивный гайд, который покажет, как решать конкретные задачи через DevTools.
#devtools #tools #tips
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤6👍3
📊 Метрики качества контента
В прошлом году исследовал тему метрик контента. Моей задачей было найти способ улучшения внутрикорпоративной поисковой системы, систему документирования и вики-платформы.
Проблема очевидна: в интранете много неструктурированной информации, и сложно определить, какой контент действительно полезен. Необходимо было создать механизм, который бы не только ранжировал контент по качеству, но и помогал бы авторам видеть, как их материалы влияют на пользователей, чтобы улучшать их систематически.
Нам даже удалось сделать дашборд для платформы документирования, используя который, можно управлять документацией как продуктом — авторы стали получать обратную связь в реальном времени и могли корректировать материалы, чтобы повысить их качество.
Эти метрики в дальнейшем должны были стать частью более широкой стратегии. В интранете они выступали инструментом для фильтрации качественного контента, а в будущем планировалось использовать их для создания RAG-систем (Retrieve, Augment, Generate), где автоматически подбирались бы наиболее релевантные фрагменты информации. Это позволило бы не только улучшить поиск, но и сделать контент более адаптивным к потребностям пользователей.
Материала набралось много, когда-нибудь выложу его на гитхаб. А пока поделюсь некоторыми инсайтами 📄 в этой статье
#metrics #content #quality #analytics
В прошлом году исследовал тему метрик контента. Моей задачей было найти способ улучшения внутрикорпоративной поисковой системы, систему документирования и вики-платформы.
Проблема очевидна: в интранете много неструктурированной информации, и сложно определить, какой контент действительно полезен. Необходимо было создать механизм, который бы не только ранжировал контент по качеству, но и помогал бы авторам видеть, как их материалы влияют на пользователей, чтобы улучшать их систематически.
Нам даже удалось сделать дашборд для платформы документирования, используя который, можно управлять документацией как продуктом — авторы стали получать обратную связь в реальном времени и могли корректировать материалы, чтобы повысить их качество.
Эти метрики в дальнейшем должны были стать частью более широкой стратегии. В интранете они выступали инструментом для фильтрации качественного контента, а в будущем планировалось использовать их для создания RAG-систем (Retrieve, Augment, Generate), где автоматически подбирались бы наиболее релевантные фрагменты информации. Это позволило бы не только улучшить поиск, но и сделать контент более адаптивным к потребностям пользователей.
Материала набралось много, когда-нибудь выложу его на гитхаб. А пока поделюсь некоторыми инсайтами 📄 в этой статье
#metrics #content #quality #analytics
👍9❤5🔥3
📸 Делаем скриншоты
Если вы работаете в IT, то наверняка знаете, что визуализация мыслей — это мощный инструмент коммуникации. Особенно когда нужно быстро объяснить проблему, показать результат или согласовать деталь.
И здесь меня часто спасает Яндекс.Диск. Не его облачное хранилище (хотя оно тоже удобное), а встроенная "скриншотилка".
В отличие от классических скриншотов, встроенных в ОС тут можно рисовать стрелки, добавлять комментарии, обводить нужные части, отправлять ссылку и многое другое.
📖 Как работает скриншотилка в Яндекс.Диске?
Функция доступна через контекстное меню приложения, есть горячие клавиши . После съемки скриншот автоматически сохраняется в папку «Скриншоты» на вашем компьютере и сразу загружается в Яндекс.Диск.
Это значит:
— Вы получаете прямую ссылку на изображение для отправки в чаты, тикеты или документы.
— Можно редактировать скриншот : добавлять текст, стрелки, рамки вокруг ключевых мест.
— Все изменения сохраняются в облаке, так что доступны с любого устройства.
🔍 Сценарии использования
Быстрая передача контекста
Если в телеграм пишут: «Не работает кнопка», я делаю скриншот с пометкой «Ошибка 500 здесь», отправляю ссылку в тикет — и разработчики сразу видят проблему.
Согласование дизайна
Менеджер продукта хочет убедиться, что новый интерфейс соответствует требованиям. Скриншот с выделенными элементами и комментариями экономит часы словесных объяснений.
Отчеты после тестирования
Тестировщик фиксирует баг: делает скриншот, добавляет описание шагов и прикрепляет в Jira. Все участники проекта видят проблему «живьем».
Обучение новичков
Когда наставляю коллегу, показываю процессы через скриншоты с подсветкой: «Смотри, вот здесь выбираем параметр X, затем кликаем сюда».
👀 Подробнее
— Лендинг
— Документация (win, mac)
UPD: см. также
(рекомендации из комментариев)
— Flameshot - ещё одна скриншотилка, позволяющая захватывать область экрана и редактировать изображения.
— ScreenToGif - инструмент для записи экрана в формате GIF с минимальными настройками и удобным интерфейсом.
— ShareX - мощный open-source инструмент для захвата экрана, создания GIF, автоматизации загрузки файлов и расширенного редактирования с поддержкой более 80 сервисов.
#tools #screenshots
Если вы работаете в IT, то наверняка знаете, что визуализация мыслей — это мощный инструмент коммуникации. Особенно когда нужно быстро объяснить проблему, показать результат или согласовать деталь.
И здесь меня часто спасает Яндекс.Диск. Не его облачное хранилище (хотя оно тоже удобное), а встроенная "скриншотилка".
В отличие от классических скриншотов, встроенных в ОС тут можно рисовать стрелки, добавлять комментарии, обводить нужные части, отправлять ссылку и многое другое.
📖 Как работает скриншотилка в Яндекс.Диске?
Функция доступна через контекстное меню приложения, есть горячие клавиши . После съемки скриншот автоматически сохраняется в папку «Скриншоты» на вашем компьютере и сразу загружается в Яндекс.Диск.
Это значит:
— Вы получаете прямую ссылку на изображение для отправки в чаты, тикеты или документы.
— Можно редактировать скриншот : добавлять текст, стрелки, рамки вокруг ключевых мест.
— Все изменения сохраняются в облаке, так что доступны с любого устройства.
🔍 Сценарии использования
Быстрая передача контекста
Если в телеграм пишут: «Не работает кнопка», я делаю скриншот с пометкой «Ошибка 500 здесь», отправляю ссылку в тикет — и разработчики сразу видят проблему.
Согласование дизайна
Менеджер продукта хочет убедиться, что новый интерфейс соответствует требованиям. Скриншот с выделенными элементами и комментариями экономит часы словесных объяснений.
Отчеты после тестирования
Тестировщик фиксирует баг: делает скриншот, добавляет описание шагов и прикрепляет в Jira. Все участники проекта видят проблему «живьем».
Обучение новичков
Когда наставляю коллегу, показываю процессы через скриншоты с подсветкой: «Смотри, вот здесь выбираем параметр X, затем кликаем сюда».
👀 Подробнее
— Лендинг
— Документация (win, mac)
UPD: см. также
(рекомендации из комментариев)
— Flameshot - ещё одна скриншотилка, позволяющая захватывать область экрана и редактировать изображения.
— ScreenToGif - инструмент для записи экрана в формате GIF с минимальными настройками и удобным интерфейсом.
— ShareX - мощный open-source инструмент для захвата экрана, создания GIF, автоматизации загрузки файлов и расширенного редактирования с поддержкой более 80 сервисов.
#tools #screenshots
❤11🔥3