🧩 Как enterprise architecture (EA) помогает достигать "быстрых побед"
Интересная статья от Daniel Lambert — эксперта в области бизнес- и enterprise architecture (EA), автора книги о agile-стратегиях и партнера компании Business Architecture Info.
В статье рассказывается, как использовать знания о корпоративной архитектуре (EA) для быстрых улучшений. Хотя больше выглядит как попытка объяснить простой подход "делай вещи, которые приносят бОльшую пользу с меньшими усилиями в первую очередь" через сложный аппарат "копроративной архитектуры"
Вот основные идеи:
Что такое «быстрые победы»?
Это небольшие проекты , которые:
— Реализуются быстро (недели, а не месяцы).
— Доставляют ощутимую пользу (сокращают затраты, улучшают процессы).
— Показывают ROI и мотивируют команду к большим изменениям.
Примеры:
Автоматизация рутинных задач.
Устранение дублирующих систем.
Оптимизация данных для быстрого доступа.
Как EA помогает их находить?
В статье предлагается шесть методов :
❶ Стратегическая выравнивание
Проверяйте, насколько проекты соответствуют целям компании.
❷ Оптимизация процессов
Используйте EA для визуализации процессов и выявления «узких мест».
Пример: сокращение этапов в цепочке поставок.
❸ Рационализация технологий
Уберите «лишние» системы.
Пример: замена нескольких CRM на одну.
❹ Управление данными
Централизуйте данные, чтобы избежать «силосов».
Пример: создание общего хранилища.
❺ Повышение эффективности
Найдите простые способы сэкономить ресурсы (например, пересмотр контрактов).
❻ Создание новых источников дохода
Используйте EA для анализа клиентских цепочек и добавления новых услуг.
Как это работает на практике?
Всё просто — классифицируйте проекты :
— Быстрые победы — низкий трудозатрат, высокая отдача.
— «Денежные дыры» — требуют много ресурсов, но не приносят ценности.
Сосредоточьтесь на первых) Profit!
#prioritization #projects #ea
Интересная статья от Daniel Lambert — эксперта в области бизнес- и enterprise architecture (EA), автора книги о agile-стратегиях и партнера компании Business Architecture Info.
В статье рассказывается, как использовать знания о корпоративной архитектуре (EA) для быстрых улучшений. Хотя больше выглядит как попытка объяснить простой подход "делай вещи, которые приносят бОльшую пользу с меньшими усилиями в первую очередь" через сложный аппарат "копроративной архитектуры"
Вот основные идеи:
Что такое «быстрые победы»?
Это небольшие проекты , которые:
— Реализуются быстро (недели, а не месяцы).
— Доставляют ощутимую пользу (сокращают затраты, улучшают процессы).
— Показывают ROI и мотивируют команду к большим изменениям.
Примеры:
Автоматизация рутинных задач.
Устранение дублирующих систем.
Оптимизация данных для быстрого доступа.
Как EA помогает их находить?
В статье предлагается шесть методов :
❶ Стратегическая выравнивание
Проверяйте, насколько проекты соответствуют целям компании.
❷ Оптимизация процессов
Используйте EA для визуализации процессов и выявления «узких мест».
Пример: сокращение этапов в цепочке поставок.
❸ Рационализация технологий
Уберите «лишние» системы.
Пример: замена нескольких CRM на одну.
❹ Управление данными
Централизуйте данные, чтобы избежать «силосов».
Пример: создание общего хранилища.
❺ Повышение эффективности
Найдите простые способы сэкономить ресурсы (например, пересмотр контрактов).
❻ Создание новых источников дохода
Используйте EA для анализа клиентских цепочек и добавления новых услуг.
Как это работает на практике?
Всё просто — классифицируйте проекты :
— Быстрые победы — низкий трудозатрат, высокая отдача.
— «Денежные дыры» — требуют много ресурсов, но не приносят ценности.
Сосредоточьтесь на первых) Profit!
#prioritization #projects #ea
👍3🔥2
🤓 Продуктовые паттерны: как решать проблему «неправильного порядка действий»
Пользователи часто совершают действия в неправильной последовательности — это приводит к ошибкам, недовольству и упущенным возможностям. Как это исправить?
Рассмотрим 7 продуктовых решений , которые помогут снизить количество таких случаев:
❶ Визуальное подсказывание порядка
Используйте визуальные элементы, чтобы подчеркнуть последовательность шагов.
Пример:
Шаги с нумерацией (например, «1. Выберите дату → 2. Введите данные»).
Анимация или цветовые акценты для текущего шага (например, подсветка активного поля в форме).
Почему работает : Пользователи интуитивно понимают, что делать дальше.
❷ Realtime-валидация
Проверяйте порядок действий на лету и блокируйте ошибки до их совершения.
Пример:
В форме регистрации запретить переход к следующему шагу, пока не заполнены обязательные поля.
Показывать ошибку, если пользователь пытается оплатить заказ до выбора доставки.
Почему работает : Сразу исправляете ошибки, не оставляя пользователя в недоумении.
❸ Уведомления и подсказки
Помогайте пользователям в момент совершения ошибки.
Примеры:
Всплывающее окно: «Вы не выбрали категорию. Это нужно сделать до сохранения».
Тултипы с пошаговыми инструкциями.
Почему работает : Фокусирует внимание на ключевых шагах без необходимости читать документацию.
❹ Автоматизация
Сделайте систему «непробиваемой» — пусть она сама корректирует действия.
Примеры:
Автозаполнение пропущенных шагов на основе данных пользователя.
Система, которая перестраивает процесс, если порядок нарушен (например, возвращает к предыдущему шагу).
Почему работает : Сокращает нагрузку на пользователя и уменьшает ошибки.
❺ Обучающие гайды и чек-листы
Встроенные руководства внутри продукта.
Примеры:
Всплывающий гид при первом входе: «Сначала выберите проект, затем добавьте задачу».
Чек-листы на экранах: «Проверьте: все поля заполнены → нажмите «Сохранить»».
Почему работает : Упрощает понимание процесса, особенно для новичков.
❻ Предотвращение шагов
Запрещайте выполнение шагов в неверной последовательности.
Примеры:
Кнопка «Далее» становится активной только после выполнения предыдущего шага.
Убрать доступ к определенным функциям до завершения предварительных условий.
Почему работает : Физически невозможно сделать ошибку.
❼ Аналитика и A/B-тесты
Используйте данные для выявления проблемных мест.
Примеры:
Следите за тем, где чаще всего нарушают порядок (например, через Session Replay).
Проводите A/B-тесты: сравните два варианта интерфейса и выберите лучший.
Почему работает : Оптимизация на основе фактов, а не гипотез.
💡 Дополнительные советы
— Упростите процесс : Если порядок сложный — переработайте его. Например, объедините шаги или сделайте их неочевидными (например, автоматическое сохранение данных).
— Обратная связь : Добавьте форму для пользователей, чтобы узнать, почему они нарушают порядок (возможно, логика процесса неочевидна).
😉 Как выбрать решение?
Для критичных ошибок (например, потеря данных): Используйте блокировку шагов или валидацию в реальном времени.
Для сложных процессов (например, настройка CRM): Внедрите обучение или чек-листы.
Для массового использования (например, форма заказа): Проверьте через A/B-тесты, что лучше работает.
😜 Итог
«Защита от дурака» — не всегда оскорбление, а инструмент, который помогает пользователям быстрее достигать цели.
Пробуйте комбинировать подходы: например, визуальные подсказки + уведомления. И помните: лучшая система та, где пользователь даже не замечает ограничений.
#product #UX #problems #path
Пользователи часто совершают действия в неправильной последовательности — это приводит к ошибкам, недовольству и упущенным возможностям. Как это исправить?
Рассмотрим 7 продуктовых решений , которые помогут снизить количество таких случаев:
❶ Визуальное подсказывание порядка
Используйте визуальные элементы, чтобы подчеркнуть последовательность шагов.
Пример:
Шаги с нумерацией (например, «1. Выберите дату → 2. Введите данные»).
Анимация или цветовые акценты для текущего шага (например, подсветка активного поля в форме).
Почему работает : Пользователи интуитивно понимают, что делать дальше.
❷ Realtime-валидация
Проверяйте порядок действий на лету и блокируйте ошибки до их совершения.
Пример:
В форме регистрации запретить переход к следующему шагу, пока не заполнены обязательные поля.
Показывать ошибку, если пользователь пытается оплатить заказ до выбора доставки.
Почему работает : Сразу исправляете ошибки, не оставляя пользователя в недоумении.
❸ Уведомления и подсказки
Помогайте пользователям в момент совершения ошибки.
Примеры:
Всплывающее окно: «Вы не выбрали категорию. Это нужно сделать до сохранения».
Тултипы с пошаговыми инструкциями.
Почему работает : Фокусирует внимание на ключевых шагах без необходимости читать документацию.
❹ Автоматизация
Сделайте систему «непробиваемой» — пусть она сама корректирует действия.
Примеры:
Автозаполнение пропущенных шагов на основе данных пользователя.
Система, которая перестраивает процесс, если порядок нарушен (например, возвращает к предыдущему шагу).
Почему работает : Сокращает нагрузку на пользователя и уменьшает ошибки.
❺ Обучающие гайды и чек-листы
Встроенные руководства внутри продукта.
Примеры:
Всплывающий гид при первом входе: «Сначала выберите проект, затем добавьте задачу».
Чек-листы на экранах: «Проверьте: все поля заполнены → нажмите «Сохранить»».
Почему работает : Упрощает понимание процесса, особенно для новичков.
❻ Предотвращение шагов
Запрещайте выполнение шагов в неверной последовательности.
Примеры:
Кнопка «Далее» становится активной только после выполнения предыдущего шага.
Убрать доступ к определенным функциям до завершения предварительных условий.
Почему работает : Физически невозможно сделать ошибку.
❼ Аналитика и A/B-тесты
Используйте данные для выявления проблемных мест.
Примеры:
Следите за тем, где чаще всего нарушают порядок (например, через Session Replay).
Проводите A/B-тесты: сравните два варианта интерфейса и выберите лучший.
Почему работает : Оптимизация на основе фактов, а не гипотез.
💡 Дополнительные советы
— Упростите процесс : Если порядок сложный — переработайте его. Например, объедините шаги или сделайте их неочевидными (например, автоматическое сохранение данных).
— Обратная связь : Добавьте форму для пользователей, чтобы узнать, почему они нарушают порядок (возможно, логика процесса неочевидна).
😉 Как выбрать решение?
Для критичных ошибок (например, потеря данных): Используйте блокировку шагов или валидацию в реальном времени.
Для сложных процессов (например, настройка CRM): Внедрите обучение или чек-листы.
Для массового использования (например, форма заказа): Проверьте через A/B-тесты, что лучше работает.
😜 Итог
«Защита от дурака» — не всегда оскорбление, а инструмент, который помогает пользователям быстрее достигать цели.
Пробуйте комбинировать подходы: например, визуальные подсказки + уведомления. И помните: лучшая система та, где пользователь даже не замечает ограничений.
#product #UX #problems #path
❤3🔥1
⚙️ Внутренние 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