Forwarded from Cloud.ru
Evolution Artifact Registry стал еще мощнее 💪
Хранить артефакты — только половина дела. Вторая половина — делать это удобно и для DevOps, и для разработчиков.
Поэтому мы расширили Evolution Artifact Registry — сервис для хранения и распространения артефактов — двумя типами репозиториев.
1️⃣ RPM-репозиторий
Теперь вы можете собрать всю инфраструктуру управления пакетами в одном сервисе.
2️⃣ Generic-репозиторий
Стандартизированный и надежный пункт назначения для любых файлов.
🖱 Попробуйте на своей инфраструктуре:
Быстрый старт
Узнать подробнее о сервисе
Хранить артефакты — только половина дела. Вторая половина — делать это удобно и для DevOps, и для разработчиков.
Поэтому мы расширили Evolution Artifact Registry — сервис для хранения и распространения артефактов — двумя типами репозиториев.
Теперь вы можете собрать всю инфраструктуру управления пакетами в одном сервисе.
Подходит для:✔️ Сборки образов ВМ и контейнеров из ваших пакетов.✔️ Централизованного источника зависимостей для серверов: без самостоятельного обслуживания инфраструктуры под хранилище пакетов.✔️ Контроля версий всего, что попадает в вашу инфраструктуру.
Стандартизированный и надежный пункт назначения для любых файлов.
✔️ Загружайте бинарные сборки приложений, прошивки для IoT, отчеты и любые артефакты CI/CD или внутреннего workflow.✔️ Простой API: загрузка и выгрузка по HTTP(S), легко автоматизируется скриптом или пайплайном.
Быстрый старт
Узнать подробнее о сервисе
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Как планирование закупок помогает компании экономить?
Недавно у нас в компании немного видоизменился процесс планирования закупок.
Большинство реакций от ребят из IT что то типа
- Кругом бюрократия
- А в прошлой компании я просто говорил, когда мне что то нужно было, и мне это давали! Всё хорошо было!
- Как мы можем наверняка знать что нам будет нужно? Пустая трата времени
Мне кажется из-за модных молодёжных процессов, где приветствуется минимум бумажек и полная свобода, у людей уменьшается терпимость даже к небольшой бюрократии.
Вот как раз для таких людей этот пост - зачем же нужно компании понимать ваши хотелки как можно заранее?
1) Элементарно посчитать бюджет.
Думаю даже не стоит объяснять, что будет если дебит с кредитом не сойдётся :)
Бо-бо и кассовый разрыв
2) Получить от поставщика более выгодные условия.
Чем больше твой масштаб, тем больше у тебя возможностей диктовать условия. Вдруг несколько подразделений хотят купить одно и то же, вот тут как раз это выяснится.
3) Группировка закупок и управление их распределением.
Допустим, 2 отдела разработки хотят заказать себе IPhone и IPad для тестов мобильного приложения.
Может быть тут можно переиспользовать ресурс? Может быть хватит одного на 2 команды?
4) Плановые закупки позволяют стандартизировать железо и ПО.
Закупки это хорошее место, чтобы увидеть, что разные подразделения пытаются купить разные инструменты для решения одной проблемы. Хорошо бы выбрать одно)
Как то так.
Timofey Yakynin | Тим, который лид
#безaiконтент
Недавно у нас в компании немного видоизменился процесс планирования закупок.
Большинство реакций от ребят из IT что то типа
- Кругом бюрократия
- А в прошлой компании я просто говорил, когда мне что то нужно было, и мне это давали! Всё хорошо было!
- Как мы можем наверняка знать что нам будет нужно? Пустая трата времени
Мне кажется из-за модных молодёжных процессов, где приветствуется минимум бумажек и полная свобода, у людей уменьшается терпимость даже к небольшой бюрократии.
Вот как раз для таких людей этот пост - зачем же нужно компании понимать ваши хотелки как можно заранее?
1) Элементарно посчитать бюджет.
Думаю даже не стоит объяснять, что будет если дебит с кредитом не сойдётся :)
Бо-бо и кассовый разрыв
2) Получить от поставщика более выгодные условия.
Чем больше твой масштаб, тем больше у тебя возможностей диктовать условия. Вдруг несколько подразделений хотят купить одно и то же, вот тут как раз это выяснится.
3) Группировка закупок и управление их распределением.
Допустим, 2 отдела разработки хотят заказать себе IPhone и IPad для тестов мобильного приложения.
Может быть тут можно переиспользовать ресурс? Может быть хватит одного на 2 команды?
4) Плановые закупки позволяют стандартизировать железо и ПО.
Закупки это хорошее место, чтобы увидеть, что разные подразделения пытаются купить разные инструменты для решения одной проблемы. Хорошо бы выбрать одно)
Как то так.
Timofey Yakynin | Тим, который лид
#безaiконтент
Trending repo GitHub (trending/go)
1. danielmiessler/Fabric 🚀
А вот оно мне нафига?
2. v2fly/domain-list-community 🚀
А вот оно мне нафига?
3. Tencent/WeKnora 🚀
А вот оно мне нафига?
Timofey Yakynin | Тим, который лид
1. danielmiessler/Fabric 🚀
Fabric is an open-source framework for augmenting humans using AI. It provides a modular system for solving specific problems using a crowdsourced set of AI prompts that can be used anywhere.
А вот оно мне нафига?
2. v2fly/domain-list-community 🚀
Community managed domain list. Generate geosite.dat for V2Ray.
А вот оно мне нафига?
3. Tencent/WeKnora 🚀
LLM-powered framework for deep document understanding, semantic retrieval, and context-aware answers using RAG paradigm.
А вот оно мне нафига?
Timofey Yakynin | Тим, который лид
GitHub
GitHub - danielmiessler/Fabric: Fabric is an open-source framework for augmenting humans using AI. It provides a modular system…
Fabric is an open-source framework for augmenting humans using AI. It provides a modular system for solving specific problems using a crowdsourced set of AI prompts that can be used anywhere. - dan...
Оно работает! Хочу поделиться своим результатом 🦾
Прошло полгода как перешёл в команду Artifact Registry в Cloud.ru. За это время я сделал большой упор на развитие процессов, в этом деле один из ориентиров для меня - диаграмма сгорания спринта.
Эта диаграмма - отражение всех проблем в процессах команды. Не будет она работать без хорошего планирования, без описания задач, без вовлеченности разработчиков, без...
Все проблемы которые есть у вас в команде находят своё отражение в этой диаграмме.
Ну а теперь к результатам😎
На фото представлены две диаграммы за июль и декабрь. Я думаю не вооруженным взглядом видно что декабрь куда "Красивее". Конечное есть ещё над чем работать, но начало положено.
В чем секрет? 🧐
Есть золотое правило - ваш процесс не будет лучше процессов, которые следуют до и после него.
Поэтому мы сделали большой акцент на планировании и описании задач - это старт, с этого начинается разработка.
Также сделали акцент на последнем этапе - деплое. Сделали его более прозрачным, сгруппированным. В целом изменили процесс наших релизов.
⚡️Результат - предсказуемость спринта выросла с 20 до 60%
Будем добивать до сотки 😎
А у вас работает диаграмма сгорания?))
Timofey Yakynin | Тим, который лид
#безaiконтент
Прошло полгода как перешёл в команду Artifact Registry в Cloud.ru. За это время я сделал большой упор на развитие процессов, в этом деле один из ориентиров для меня - диаграмма сгорания спринта.
Эта диаграмма - отражение всех проблем в процессах команды. Не будет она работать без хорошего планирования, без описания задач, без вовлеченности разработчиков, без...
Все проблемы которые есть у вас в команде находят своё отражение в этой диаграмме.
Ну а теперь к результатам😎
На фото представлены две диаграммы за июль и декабрь. Я думаю не вооруженным взглядом видно что декабрь куда "Красивее". Конечное есть ещё над чем работать, но начало положено.
В чем секрет? 🧐
Есть золотое правило - ваш процесс не будет лучше процессов, которые следуют до и после него.
Поэтому мы сделали большой акцент на планировании и описании задач - это старт, с этого начинается разработка.
Также сделали акцент на последнем этапе - деплое. Сделали его более прозрачным, сгруппированным. В целом изменили процесс наших релизов.
⚡️Результат - предсказуемость спринта выросла с 20 до 60%
Будем добивать до сотки 😎
А у вас работает диаграмма сгорания?))
Timofey Yakynin | Тим, который лид
#безaiконтент
👏4
Standart First ☝
Я тут пересмотрел свой подход к построению нового процесса. Признаюсь честно, мой предыдущий поход можно назвать хаос-first (Хотя он тоже имеет место быть).
Ситуация☀
Представим, что у вас есть 2 сущности, которые отвечают за одну функцию, но работают над разными задачами.
Как пример:
- Разработчики в 2 разных проектах, но в вашей команде.
- 2 команды разных продуктов в вашем направлении
- 2 дочерних компании в вашем холдинге (если вы совсем большой Дядя)
ВАЖНО: Вы делаете это первый раз = опыта решения подобной задачи пока у вас нет.
Задача🗒
Ввести общий подход для решения новой для компании/команды задачи - сделать процесс повторяемым.
Как делал😖
Я брал сильных людей на каждое из направлений, мы обговаривали общий подход и стратегию, но тактику я оставлял им. Я не навязывал подходов, шаблонов и практик.
Цель - дать командам решить одну и ту же задачу, возможно, разными способами, чтобы получить больше опыта и сделать больше ошибок. После решения задачи производится ретроспектива, берётся лучшее из решений. После чего появляется общая практика.
Проблемы:
- Изначально процесс сложно или почти невозможно контролировать
- Не всегда очевидно, когда настал момент для "объединения общих практик".
- На старте создаётся очень много технического долга
..
Как сейчас👋
Наткнулся на практику SDCA - это цикл Standardize → Do → Check → Act.
Если коротко: делай стандарт, делай работу по стандарту (это уровень исполнителя), проверяй (уровень менеджера), меняй если что то не так.
Нужно уделить больше времени на старте - заложить архитектуру процессу. Базовые шаблоны, базовые догмы и ориентиры, чек-листы. Это как с архитектурой кода - если раньше уделить этому время, в процессе меньше нужно будет переделывать.
То есть прям берёшь своих людей, садитесь вместе и дружно делаете всё это. Вместе. Чем более детально вы пропишите алгоритм решения типовой задачи - тем проще будет контролировать работу и учиться на ошибках.
Этот подход имеет недостаток - он уменьшает гибкость. Но если цель сделать процесс управляемым и повторяемым, придётся этим пожертвовать.
В любом случае, уровень гибкости можно регулировать глубиной стандарта, который вы создаёте.
Что думаете по этому поводу?
Важно: если вы проверяете гипотезу, не нужно начинать с стандарта (Если не понятно, пишите мне, я расскажу)
Timofey Yakynin | Тим, который лид
#безaiконтент
Я тут пересмотрел свой подход к построению нового процесса. Признаюсь честно, мой предыдущий поход можно назвать хаос-first (Хотя он тоже имеет место быть).
Ситуация
Представим, что у вас есть 2 сущности, которые отвечают за одну функцию, но работают над разными задачами.
Как пример:
- Разработчики в 2 разных проектах, но в вашей команде.
- 2 команды разных продуктов в вашем направлении
- 2 дочерних компании в вашем холдинге (если вы совсем большой Дядя)
ВАЖНО: Вы делаете это первый раз = опыта решения подобной задачи пока у вас нет.
Задача
Ввести общий подход для решения новой для компании/команды задачи - сделать процесс повторяемым.
Как делал
Я брал сильных людей на каждое из направлений, мы обговаривали общий подход и стратегию, но тактику я оставлял им. Я не навязывал подходов, шаблонов и практик.
Цель - дать командам решить одну и ту же задачу, возможно, разными способами, чтобы получить больше опыта и сделать больше ошибок. После решения задачи производится ретроспектива, берётся лучшее из решений. После чего появляется общая практика.
Проблемы:
- Изначально процесс сложно или почти невозможно контролировать
- Не всегда очевидно, когда настал момент для "объединения общих практик".
- На старте создаётся очень много технического долга
..
Как сейчас
Наткнулся на практику SDCA - это цикл Standardize → Do → Check → Act.
Если коротко: делай стандарт, делай работу по стандарту (это уровень исполнителя), проверяй (уровень менеджера), меняй если что то не так.
Нужно уделить больше времени на старте - заложить архитектуру процессу. Базовые шаблоны, базовые догмы и ориентиры, чек-листы. Это как с архитектурой кода - если раньше уделить этому время, в процессе меньше нужно будет переделывать.
То есть прям берёшь своих людей, садитесь вместе и дружно делаете всё это. Вместе. Чем более детально вы пропишите алгоритм решения типовой задачи - тем проще будет контролировать работу и учиться на ошибках.
Этот подход имеет недостаток - он уменьшает гибкость. Но если цель сделать процесс управляемым и повторяемым, придётся этим пожертвовать.
В любом случае, уровень гибкости можно регулировать глубиной стандарта, который вы создаёте.
Что думаете по этому поводу?
Важно: если вы проверяете гипотезу, не нужно начинать с стандарта (Если не понятно, пишите мне, я расскажу)
Timofey Yakynin | Тим, который лид
#безaiконтент
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
🧠 Мне нужна помощь коллективного разума
Короче, я поставил себе цель - хочу в этом году выступить спикером на it конференций.
Это первый такой опыт. Хоть публичные выступления и не в новину, но вот подготовка к выступлению на конференции пока тёмный лес.
И тут нужна помощь!🤓
Самое сложное выбрать тему, есть 3 на уме, хочу узнать, какая будет интереснее.
Напиши в комменты цифру понравившегося тебе варианта!
⭐️ 1) Стори поинты на вес золота. Как история денег поможет в оценке задач
⭐️ 2) AI в работе продакта/проджекта.
⭐️3) CMM. Как оценить уровень команды? Как понять куда расти дальше?
В общем буду благодарен обратной связи!
Короче, я поставил себе цель - хочу в этом году выступить спикером на it конференций.
Это первый такой опыт. Хоть публичные выступления и не в новину, но вот подготовка к выступлению на конференции пока тёмный лес.
И тут нужна помощь!🤓
Самое сложное выбрать тему, есть 3 на уме, хочу узнать, какая будет интереснее.
Напиши в комменты цифру понравившегося тебе варианта!
⭐️ 1) Стори поинты на вес золота. Как история денег поможет в оценке задач
Честно, сам выдумал. Смысл в том, что текущие фиатные деньги напоминают стори поинты. Фиат отражает объем производства, не привязан к какому либо вещественному товару и тд.
На примере денег можно понять, как синхронизировать разные команды по оценке (также как стоимость рубля можно выразить в валюте Нигерии) и другое.
⭐️ 2) AI в работе продакта/проджекта.
Ну тут чисто на хайпе. Покажу свои наработки в виде ботов и AI агентов, которые помогают в работе. Дам фундамент по которому можно определить, что нужно автоматизировать.
⭐️3) CMM. Как оценить уровень команды? Как понять куда расти дальше?
Расскажу про Capability Maturity Model. Как оценить развитость и повторяемость процессов. Уровни развития и качества. Как переходить с уровня на уровня и когда нужно стоять на месте.
В общем буду благодарен обратной связи!
This media is not supported in your browser
VIEW IN TELEGRAM
Среднестатистический Planning Poker при оценке задач:
🤣2👍1
Забавно, что Yandex использует одну механику в 2 совершенно разных продуктах)
Я видел у людей итоги года в Я.Музыке. Прям видно, что фича активно работает - все выставляют в сторис свои достижения в прослушивании Михаила круга🥸
Соответсвенно у яндекса мощная PR компания. Пользователи сами рассказывают о сервисе другим пользователям
Но я ни у кого не видел в сторис, его результаты в Yandex Cloud за год)) Его личную облачную историю 🫠
Интересно, насколько это рабочая тема в случае Облака...
Я видел у людей итоги года в Я.Музыке. Прям видно, что фича активно работает - все выставляют в сторис свои достижения в прослушивании Михаила круга🥸
Соответсвенно у яндекса мощная PR компания. Пользователи сами рассказывают о сервисе другим пользователям
Но я ни у кого не видел в сторис, его результаты в Yandex Cloud за год)) Его личную облачную историю 🫠
Интересно, насколько это рабочая тема в случае Облака...
Forwarded from ДЕВОПСИНА | DevOps | Linux
Please open Telegram to view this post
VIEW IN TELEGRAM
Почему продавать игрушки не простая задача?🧐
Представим вы решили открыть свой мини магазин игрушек, кто ваша ЦА? Конечно же дети, ведь дети играют в игрушки! 😋
Окрылённые этой гениальной мыслью мы откроем магазин игрушек там, где детей больше всего - например прямо в школе или детском саду. Но вот проблема - у детей нет денег, деньги у взрослых.
Тогда наша ЦА - родители. Где родители бывают чаще всего? На работе.🥸
Давайте тогда откроем магазин игрушек прямо в офисе! Но вот проблема - взрослые не играют в игрушки.
На таком простом примере хочу показать, что потребитель и покупатель не всегда один и тот же человек. В случае, когда это разные люди, нужно искать подход к ним через какие общие вещи. Например в случае игрушек стоит разместить магазин там, где родитель и ребёнок будут скорее всего вместе - на выходе из детского сада, в ТЦ.😎
Что забавно, так же работает B2B. Покупать твоё решение может отдел закупок, топ менеджмент, рук отдела и тд. А вот пользоваться обычный специалист - бухгалтер, разработчик, менеджер.🤯
☝️Что это значит? Когда ты формируешь бизнес-модель, функционал и УТП продукта - убедись, что затрагиваешь интересы и потребителя и покупателя.
Мы привыкли писать user story. Думать прежде всего об интересах потребителя - так намного проще. Но не всегда тот кто будет вас использовать будет платить вам.
Представим вы решили открыть свой мини магазин игрушек, кто ваша ЦА? Конечно же дети, ведь дети играют в игрушки! 😋
Окрылённые этой гениальной мыслью мы откроем магазин игрушек там, где детей больше всего - например прямо в школе или детском саду. Но вот проблема - у детей нет денег, деньги у взрослых.
Тогда наша ЦА - родители. Где родители бывают чаще всего? На работе.🥸
Давайте тогда откроем магазин игрушек прямо в офисе! Но вот проблема - взрослые не играют в игрушки.
На таком простом примере хочу показать, что потребитель и покупатель не всегда один и тот же человек. В случае, когда это разные люди, нужно искать подход к ним через какие общие вещи. Например в случае игрушек стоит разместить магазин там, где родитель и ребёнок будут скорее всего вместе - на выходе из детского сада, в ТЦ.😎
Что забавно, так же работает B2B. Покупать твоё решение может отдел закупок, топ менеджмент, рук отдела и тд. А вот пользоваться обычный специалист - бухгалтер, разработчик, менеджер.🤯
☝️Что это значит? Когда ты формируешь бизнес-модель, функционал и УТП продукта - убедись, что затрагиваешь интересы и потребителя и покупателя.
Мы привыкли писать user story. Думать прежде всего об интересах потребителя - так намного проще. Но не всегда тот кто будет вас использовать будет платить вам.
👍2
Почему после product‑market fit в B2B SaaS всё упирается в продажи?🧐
Представь, ты делаешь B2B‑сервис. Вначале вся жизнь — это продукт. Фичи, UX, баги, созвоны с первыми клиентами, ручные кастомы. Каждая сделка — как маленький консалтинг. Ты не столько продаёшь, сколько дотащиваешь продукт до того, чтобы им вообще могли пользоваться.
В какой‑то момент наступает product‑market fit. Клиенты начинают приходить по рекомендациям, люди возвращаются в продукт сами, запросы становятся похожи друг на друга. Это как будто ты наконец собрал нормальный конструктор, а не кучку деталей.🔥
И вот дальше важный перелом.
Пока продукта не было — узкое место была разработка. После product‑market fit узкое место почти всегда становится дистрибуция:
- о тебе мало кто знает,
- в воронке мало лидов,
- сделки тянутся месяцами,
- внутри клиента никто не двигает твою тему.
Продукт уже более‑менее «летает», но сам по себе рынок он не завоюет.
Начинает работать простая логика: ещё одна фича уже почти не меняет выручку, а вот ещё один сильный сейлз или маркетолог — очень даже.🧠
В B2B это особенно жёстко чувствуется:
один клиент = много денег,
решение принимает не один человек, а цепочка: инициатор, руководитель, безопасность, закупки, финдир,
каждая сделка — маленький проект, который нужно продать, провести, внедрить, удержать.
Поэтому после product‑market fit грамотные фаундеры делают разворот мышления:
с «как нам допилить продукт» → на «как нам поставить на поток лиды, сделки и внедрения».
Отсюда появляются: сейлз‑команда, вменяемый маркетинг, контент, ивенты, вебинары, партнёрки, CRM, воронки, метрики.
☝️Вывод простой:
Пока ты не попал в product‑market fit — твоя главная задача понять, что вообще продавать.
Как только попал — главная задача понять, как это продавать много раз подряд. И вот здесь для B2B SaaS основная нагрузка закономерно переезжает в продажи и маркетинг.
Представь, ты делаешь B2B‑сервис. Вначале вся жизнь — это продукт. Фичи, UX, баги, созвоны с первыми клиентами, ручные кастомы. Каждая сделка — как маленький консалтинг. Ты не столько продаёшь, сколько дотащиваешь продукт до того, чтобы им вообще могли пользоваться.
В какой‑то момент наступает product‑market fit. Клиенты начинают приходить по рекомендациям, люди возвращаются в продукт сами, запросы становятся похожи друг на друга. Это как будто ты наконец собрал нормальный конструктор, а не кучку деталей.🔥
И вот дальше важный перелом.
Пока продукта не было — узкое место была разработка. После product‑market fit узкое место почти всегда становится дистрибуция:
- о тебе мало кто знает,
- в воронке мало лидов,
- сделки тянутся месяцами,
- внутри клиента никто не двигает твою тему.
Продукт уже более‑менее «летает», но сам по себе рынок он не завоюет.
Начинает работать простая логика: ещё одна фича уже почти не меняет выручку, а вот ещё один сильный сейлз или маркетолог — очень даже.🧠
В B2B это особенно жёстко чувствуется:
один клиент = много денег,
решение принимает не один человек, а цепочка: инициатор, руководитель, безопасность, закупки, финдир,
каждая сделка — маленький проект, который нужно продать, провести, внедрить, удержать.
Поэтому после product‑market fit грамотные фаундеры делают разворот мышления:
с «как нам допилить продукт» → на «как нам поставить на поток лиды, сделки и внедрения».
Отсюда появляются: сейлз‑команда, вменяемый маркетинг, контент, ивенты, вебинары, партнёрки, CRM, воронки, метрики.
☝️Вывод простой:
Пока ты не попал в product‑market fit — твоя главная задача понять, что вообще продавать.
Как только попал — главная задача понять, как это продавать много раз подряд. И вот здесь для B2B SaaS основная нагрузка закономерно переезжает в продажи и маркетинг.
👍2
«AI‑сотрудник», который превратился в спам‑бота 🤯
Я тоже сначала пытался играть в «автономного AI‑сотрудника»:
пусть сам мониторит конкурентов, прайсы, тренды, статьи — а я такой стратег, только принимаю решения. На практике это быстро превратилось в поток уведомлений, дайджестов и ссылок, которые физически нереально переварить и тем более осмысленно применить.
Ситуация ☀️
Логика была простая: «Отдам ИИ то, что не жалко и где не страшно ошибиться». В итоге туда улетели все «фоново‑полезные» активности: мониторинги, обзоры, тренды, новинки у конкурентов. Звучит умно, но по факту — это задачи с размытым критерием полезности. Поэтому и результат получился размытый: много, часто, непонятно, что с этим делать 🫠
Прозрение 🧠
В какой‑то момент я поймал себя на том, что трачу время не на решения, а на разбор того, что прислал ИИ.
Для управленческих задач намного лучше работает другой режим: «сделай быстро по запросу», а не «делай постоянно на фоне».
Основная работа менеджера — принимать решения, а не коллекционировать информацию. Сбор данных и анализ — это просто этапы, и с ИИ они стали слишком лёгкими, поэтому хочется «подстелить соломку» и знать всё заранее. Но переизбыток инфы только ухудшает качество решений и перегружает голову.
Как делаю сейчас 👋
Я перестал пытаться заставить AI работать «сменами» и стал использовать его как умного ментора по запросу:
- у меня есть настроенное пространство в Perplexity с нужными источниками — конкуренты, блоги, тренд‑площадки и т.п.
- когда появляется конкретный управленческий вопрос, я иду туда и запрашиваю ровно то, что нужно «здесь и сейчас»
- вместо бесконечного мониторинга — точечные сессии: собрать факты, прикинуть варианты, уточнить риски
В такой модели AI — не сотрудник, который должен что‑то «постоянно выдавать», а коуч, который ускоряет мой путь к уже понятной цели. Если самой цели нет, любой объём данных превращается в шум.
У вас как с этим? Уже налетали на AI‑перегруз, или пока наоборот ощущение, что данных мало и нужно «подкрутить автоматизацию»? 😎
Я тоже сначала пытался играть в «автономного AI‑сотрудника»:
пусть сам мониторит конкурентов, прайсы, тренды, статьи — а я такой стратег, только принимаю решения. На практике это быстро превратилось в поток уведомлений, дайджестов и ссылок, которые физически нереально переварить и тем более осмысленно применить.
Ситуация ☀️
Логика была простая: «Отдам ИИ то, что не жалко и где не страшно ошибиться». В итоге туда улетели все «фоново‑полезные» активности: мониторинги, обзоры, тренды, новинки у конкурентов. Звучит умно, но по факту — это задачи с размытым критерием полезности. Поэтому и результат получился размытый: много, часто, непонятно, что с этим делать 🫠
Прозрение 🧠
В какой‑то момент я поймал себя на том, что трачу время не на решения, а на разбор того, что прислал ИИ.
Для управленческих задач намного лучше работает другой режим: «сделай быстро по запросу», а не «делай постоянно на фоне».
Основная работа менеджера — принимать решения, а не коллекционировать информацию. Сбор данных и анализ — это просто этапы, и с ИИ они стали слишком лёгкими, поэтому хочется «подстелить соломку» и знать всё заранее. Но переизбыток инфы только ухудшает качество решений и перегружает голову.
Как делаю сейчас 👋
Я перестал пытаться заставить AI работать «сменами» и стал использовать его как умного ментора по запросу:
- у меня есть настроенное пространство в Perplexity с нужными источниками — конкуренты, блоги, тренд‑площадки и т.п.
- когда появляется конкретный управленческий вопрос, я иду туда и запрашиваю ровно то, что нужно «здесь и сейчас»
- вместо бесконечного мониторинга — точечные сессии: собрать факты, прикинуть варианты, уточнить риски
В такой модели AI — не сотрудник, который должен что‑то «постоянно выдавать», а коуч, который ускоряет мой путь к уже понятной цели. Если самой цели нет, любой объём данных превращается в шум.
У вас как с этим? Уже налетали на AI‑перегруз, или пока наоборот ощущение, что данных мало и нужно «подкрутить автоматизацию»? 😎
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Нашёл какую то гениальную визуализацию "Мы умеем планировать только на спринт вперёд"😂
Please open Telegram to view this post
VIEW IN TELEGRAM
Тут попросил Perlexity описать мне тренды в проектного/продуктового управления на 26 год. Получилось вполне себе🦾
Местами есть неточности, но узнать о новых подходах и мыслях можно (Нужно же из своего информационного пузыря вылезать)
Мне оч понравилась идея про проектно ориентированные-организации - когда во главе каждой организации стоит проект, а на AI возложены операционные функции🗒
Плюс этож Perlexity - там все источники есть для особо любознательных.
Делюсь в общем
Местами есть неточности, но узнать о новых подходах и мыслях можно (Нужно же из своего информационного пузыря вылезать)
Мне оч понравилась идея про проектно ориентированные-организации - когда во главе каждой организации стоит проект, а на AI возложены операционные функции
Плюс этож Perlexity - там все источники есть для особо любознательных.
Делюсь в общем
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1👏1
Недавно поймал себя на мысли: как вообще искать готовую автоматизацию для своей профессии, если у каждого продукта — свои обязанности, процессы и софты?
Профессия «продакт‑менеджер» звучит единообразно, но на деле это десятки разных ролей. В одной компании ты ковыряешься в SQL и ставишь эксперименты, в другой — пол‑дня в Jira и Figma, а где‑то ты вообще больше говоришь, чем трогаешь рукой хоть один продукт.
Так что вопрос в духе «GPT, дай топ‑10 способов автоматизировать жизнь продакта» звучит немного странно. Какую именно жизнь? 😅
Автоматизация — это не про красивый список тулзов. Это про знание собственной рутины. Что реально отнимает у тебя время? Что повторяется каждый день? Что можно делегировать машине, а что требует человеческого фокуса?
Пока ты не знаешь, что именно автоматизируешь, просить советы у ИИ — как чинить «всё подряд».
Профессия «продакт‑менеджер» звучит единообразно, но на деле это десятки разных ролей. В одной компании ты ковыряешься в SQL и ставишь эксперименты, в другой — пол‑дня в Jira и Figma, а где‑то ты вообще больше говоришь, чем трогаешь рукой хоть один продукт.
Так что вопрос в духе «GPT, дай топ‑10 способов автоматизировать жизнь продакта» звучит немного странно. Какую именно жизнь? 😅
Автоматизация — это не про красивый список тулзов. Это про знание собственной рутины. Что реально отнимает у тебя время? Что повторяется каждый день? Что можно делегировать машине, а что требует человеческого фокуса?
Пока ты не знаешь, что именно автоматизируешь, просить советы у ИИ — как чинить «всё подряд».
👍1
Играю в шахматы и поймал себя на том, что каждый раз после потери важной фигуры сразу хочется сдаться и начать заново 🫠 Типа «ну всё, следующая партия точно будет лучше». Но на деле — потеря ферзя ещё не мат.
Противник тоже ошибётся, позиция изменится, шансы есть. Просто разочарование застилает глаза и кажется, что продолжать бессмысленно.
Это, кстати, ровно то же самое, что происходит в работе: фича не зашла — хочется всё переписать, проект пошёл не так — хочется закрыть и открыть новый.
Шахматы хорошо учат одному: не унывай раньше времени, посмотри есть ли у тебя ещё ресурс изменить ход игры ☝
Противник тоже ошибётся, позиция изменится, шансы есть. Просто разочарование застилает глаза и кажется, что продолжать бессмысленно.
Это, кстати, ровно то же самое, что происходит в работе: фича не зашла — хочется всё переписать, проект пошёл не так — хочется закрыть и открыть новый.
Шахматы хорошо учат одному: не унывай раньше времени, посмотри есть ли у тебя ещё ресурс изменить ход игры ☝
👍3
Please open Telegram to view this post
VIEW IN TELEGRAM
😁2👾1
Забавно, что они добавили в jira подобные шутки, причем много разных
Вот эта например - мой внутренний голос😭
Вот эта например - мой внутренний голос
Please open Telegram to view this post
VIEW IN TELEGRAM
😁2