Если вот мы прямо все вместе решимся, то всех же не уволят 🤣

Лаааадно!
А как вам идея обмотать все вилки для электроприборов скотчем?
Работать же не будут!🤣🤣🤣
А фиг разберешься!😁

«Великий навозный кризис» в 1894 году или почему зарплаты в ИТшке будут падать

Короче, кто знаком со мной знают, что я часто утверждаю следующее:
💰высокие зарплаты в ИТшке закончатся еще на моем «рабочем веку».

И нет, дело не во всяких gpt (тут уж если все-таки случится мега-дизрапт, то во многих интеллектуальных областях), а дело в том, что бизнес не будет мериться с высокими зарплатами и прочими затратами долго.
На самом деле, он уже это делает каждый день - повышает эффективность.

В конце концов - моя работа делать так, чтобы на каждую бизнес потребность требовалось меньше и меньше ресурсов.
И у получается это у меня очень неплохо 😉
А почему можно быть уверенным, что так и случится?

А вот вам небольшой экскурс в историю:

Великий навозный кризис 1894 года — это популярная история, иллюстрирующая вызовы, с которыми сталкивались города в эпоху до автомобилизации, хотя детали этой истории могут быть несколько преувеличены или апокрифичны.

В конце 19-го века и начале 20-го века лошади были основным средством транспортировки в городах, таких как Лондон и Нью-Йорк. На крупных улицах можно было увидеть тысячи повозок, карет и ездоков на лошадях. Однако с увеличением числа лошадей возникла и проблема их содержания, в частности, утилизации навоза, которого производилось огромное количество.

Считается, что в 1894 году газета «The Times» предсказала, что если проблема навоза не будет решена, то к 1950 году улицы Лондона будут погребены под слоем навоза в девять футов (около 2,7 метра). При этом, на каждого коня приходилось от 15 до 35 фунтов (7-15 кг) навоза в день, что создавало проблемы не только с уборкой, но и с санитарией.

Причем тут навозный кризис?

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


👉🏼 Вот тут можно прокомментировать и дополнить

🦄 - норм, будут расти зарплаты
🔥 - падает, уже все началось! Конспирологи были правы

@badtechproject

Короче, буду периодически тут добавлять USE CASE по AI, которые сам считаю полезными😉

Вот вам смешнявка, чтобы добавить полезности😁

Проблема менеджеров и удаленка

🔩Фулл-тайм удаленка скоро закончится.
Смиритесь, утрите слезы и идите назад на свой конвейер.
Вы нужный винтик корпорации.

Короче, в этой битве менеджеров и удаленки недавно где-то слышал наброс одного из ex топов Amazon, что эти самые менеджеры и ТОПы не чувствую проблемы на простых ребят.
Почему?
Ну ответ на поверхности: на работу их самих возит личный водитель, их детей возит водитель. А в доме кто убирается? Домработница.
Может быть они сами готовят? И тут мимо, у них есть повора.

Но суть проблемы же не в разнице доходов и возможности закрыть множество вопросов деньгами.
И дело в этой борьбе даже не в эффективности.

И да, я считаю, что удаленка не так эффективна на длиной дистанции и для большинства людей.

А дело в том, что нам что-то дали, а потом решили забрать.
Вот так просто…
Это то, чему учат в самом основе менеджмента: сильнейший демотиватор - сначала дать человеку некую «плюшку», а потом забрать его.

Все мы знаем теорию, что «потеря 10 долларов, равна по уровню влияния приобретению 100».

Что нам всем делать?

Смеритесь… Текущие экономические условия, толкают нас к тому, что выбора особо у нас не будет.

👉🏼Вот тут можно прокомментировать и дополнить

💪 - я нужный винтик корпорации и горжусь этим
🔥 - удалеееенкаааа! Видал я всех этих менеджеров, знаете где???
🦄 - я единорожек😁

@badtechproject

Если вы такие, ну чисто любопытно, а чем человек занимается в час ночи.

То вот ответ 😁

Менеджеры плодят все больше менеджеров, чтобы чувствовать свою значимость

Тут мой дружище-пирожище Миша Трифонов напомнил мне про статью Пола Гремма

«Maker’s Schedule, Manager’s Schedule» (а написал ее он, когда я еще под стол пешком ходил)

Основные идеи статьи

1. Два типа расписаний
- Расписание менеджера: предполагает дробление дня на часовые интервалы, где встречи и переключения между задачами — норма. Это удобно для координации, но неприменимо для «создателей» (программистов, писателей), которым нужны длительные периоды концентрации (минимум полдня) .
- Расписание создателя: требует непрерывного времени для погружения в сложные задачи. Даже одна встреча может разрушить продуктивность, разбив день на фрагменты, слишком короткие для глубокой работы .

2. Работа менеджера: встречи. Время, когда нет встречи - впустую потраченное время.

3. Время создателя: собственно, что-то сделанное. Для него встреча - разрушенная продуктивность.

Оооокей!

А что с этим можно делать?

1. Дни без встреч.
2. Группировка встреч под вечер, чтобы высвободить утро.
3. Менеджерам научиться находить себе «занятие» в свободные слоты.

А знаете каким путем идут большинство компаний?

Мы создаем все больше менеджеров, для того, чтобы менеджеры могли общаться между собой и не отвлекать «создателей»🤣

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


👉🏼Вот тут можно прокомментировать и дополнить

@badtechproject

Гугл опять дропнули такую вот штуку

Prompt Engineering
Author: Lee Boonstra

Как пользоваться:
1. кидайешь в чат LLM-ки
2. задаешь вопросы нейронке и она тебе расскажет, как и что делать))


‼️Вы только вдумайтесь! Даже читать не надо, чтобы пользоваться! 😂

Вот как пользоваться: реально, можно не читать!


Файл во вложении. Какие эффекты менеджер продукта может получить? Какие сценарии использования? Напиши в ответе описание сценария и промпт

————

Ниже приведены основные эффекты, которые может получить менеджер продукта, используя крупномасштабные языковые модели (LLM) и методы prompt engineering, а также три примера сценариев применения вместе с соответствующими промптами .

---

## Эффекты (польза) для менеджера продукта

1. Ускорение аналитики и принятия решений.
Автоматическое суммирование, поиск инсайтов, быстрая оценка идей или спецификаций.

2. Оптимизация коммуникации в команде.
Генерация структурированных user stories, подготовка писем и документации для разных целевых аудиторий.

3. Классификация и приоритизация фидбэка.
Быстрое извлечение сути из пользовательских отзывов, определение приоритетов (баг, запрос фичи, UX-проблема и т. п.).

4. Автоматизация рутины.
Написание черновиков, перевод контента, подготовка тест-кейсов и так далее.

5. Ускоренное прототипирование и проверка гипотез.
Генерация концепций фич, сценариев использования, brainstorming с фиксацией ключевых шагов.

---

## Сценарии использования и примеры промптов

### Сценарий 1: Анализ отзывов пользователей и выделение ключевых категорий

Описание сценария:
Менеджер продукта хочет быстро понять, на какие основные темы жалуются (или хвалят) пользователи, чтобы принять решение о приоритетах доработок. LLM может за несколько секунд «прогнать» сотни отзывов и сгруппировать их по типам: UX-проблемы, функциональные баги, запросы новых фич и пр.

Пример промпта:
<|prompt|>
У меня есть несколько пользовательских отзывов о нашем мобильном приложении. Нужно:
1. Разделить каждый отзыв на категории: "Баг", "UX-проблема", "Запрос новой функции", "Похвала", "Прочее".
2. Для каждого отзыва выдать одну категорию и краткое обоснование.
3. Вернуть результат в JSON-формате.

Примеры категорий:
"Приложение вылетает" → "Баг"
"Очень сложное меню, не могу ничего найти" → "UX-проблема"
"Хочу тёмную тему" → "Запрос новой функции"

Отзывы:
1) "После обновления кнопка 'Оплатить' пропала, приходится заходить в браузер"
2) "Очень удобное приложение, спасибо!"
3) "Не хватает сортировки по дате"
</|prompt|>

---

### Сценарий 2: Генерация пользовательских историй (User Stories) для новой фичи

Описание сценария:
Менеджер продукта описывает идею, а LLM на её основе формирует структурированные user stories с учётом роли пользователя, необходимых Acceptance Criteria и приоритетов. Это упрощает формализацию требований в бэклоге.

Пример промпта:
<|prompt|>
Ты выступаешь в роли Product Owner. Нужно из идеи сформировать user story с приоритетом.

Идея: "Пользователь хочет видеть рекомендации похожих товаров после добавления продукта в корзину."

Шаги:
1. Напиши user story формата:
"Как [тип пользователя], я хочу..., чтобы..."
2. Пропиши Acceptance Criteria (минимум 2 пункта).
3. Укажи приоритет (P1, P2 или P3) и обоснуй, почему именно такой.

4. Верни ответ в JSON:  {
  "user_story": "...",
  "acceptance_criteria": ["...", "..."],
  "priority": "..."
}
</|prompt|>

---

### Сценарий 3: Подготовка черновика письма команде о запуске новой версии

Описание сценария:
Менеджеру продукта нужно оперативно оповестить команду о выходе новой версии продукта, перечислить ключевые изменения и пригласить протестировать. LLM сгенерирует основу письма в нужном стиле (деловом или дружеском) и сократит время на редактирование.

Пример промпта:
<|prompt|>
Контекст: пишем письмо внутренней команде (разработчики, QA, аналитики) о выпуске новой версии нашего мобильного приложения.
Требования к письму:
- Официально-дружелюбный тон.
- Указать 3 ключевых изменения (пример: улучшена стабильность, обновлён дизайн профиля, добавлена фильтрация по датам).
- Завершить письмо призывом к тестированию и обратной связи.

Сформируй короткий текст (не более 120 слов). В конце добавь подпись: “С уважением, [Команда продукта]”.
</|prompt|>

Мальчик - радуется новой приставке!

Мужчина - новому пылесосу 😂😂😂

Сейчас будем вскрывать)

Обратная связь

Вроде как в современным мире нам регулярно объясняют как правильно давать обратную связь друг другу.
Но очень обидно, когда забываются некоторые вещи.
Очень больно видеть, когда все еще совершаются такие ошибки.

Давайте повторим еще раз правила:

1.
Нельзя-нельзя сотруднику на протяжении всего периода говорить, что у вас все норм, а потом неожиданно на ревью начать говорить ему, как и где он ошибался. Обратная связь должна быть регулярной и последовательной
2.
Обратную связь можно и нужно давать руководителю. Кстати, и тут действует принцип (1).
3.
Говорить нужно конкретные факты. Нужно ссылаться, на конкретные события. Абстрактная похвала или развивающая обратная связь никому не помогут.
4.
Мы говорим и хорошее, и развивающее.
Если вы не можете найти что-то из этого - как руководитель вы не доработали.

И помните, вы хотите развивать, а не наказывать!

👉🏼Обсуждаем вот тут: можно накидать свои кейсы, мы их вместе разберем.

Как прошла твоя прошлая обратная связь?

🔥 - я в восторге
♥️ - с этим миром все, несите следующий

@badtechproject

Короче, забирайте:
я вам принес Гайд от OpenAI, как эффективней пользоваться 4.1

Сделал его, кстати, вот так:
1. Открыл LLM
2. Написал: Дружище, вот тебе ссылка, сделай, плз, PDFку мне.

‼️Как пользоваться?
1. Кидаешь ПДФ в LLMку
2. Задаешь ей вопросы (не будете же вы реально читать 26 страниц!)
3. Просишь учитывать эти знания при обработке и остальных твоих вопросов

@badtechproject

Пхахаха

OpenAI учат нас, как пользоваться их продуктами 🤣

На самом деле, это очень грамотный шаг, по своим темам с ИИшкой я делаю тоже самое.

По ссылке гайд для бизнеса от OpenAI, о том, как внедрять GenAI в бизнесс процессы:
https://openai.com/business/guides-and-resources/

Что там найдешь?
– ИИ на предприятии: опыт семи передовых компаний
– Практическое руководство как делать агентов ИИ и зачем это вашим сотрудникам?
– Сценарии и подходы к масштабированию

Для любого корпоративного менеджера маст рид!

@badtechproject

Предлагаю сегодня кайфовать от такого трека😉