#полезности
Симулятор PMP
В догонку сообщению выше. Тут PMI релизнули GPT-s с симулятором экзамена. Вполне себе рабочая штука!
https://chatgpt.com/g/g-elRZlGQcX-pmi-infinity-pmp-exam-simulator
Симулятор PMP
В догонку сообщению выше. Тут PMI релизнули GPT-s с симулятором экзамена. Вполне себе рабочая штука!
https://chatgpt.com/g/g-elRZlGQcX-pmi-infinity-pmp-exam-simulator
🔥18
#почтовый_ящик
Бомбардировка задачами. Часть 1
Здравствуй, ответственный читатель.
В почтовый ящик прилетело письмо, полное специфичных эмоций, которое наверняка тебе покажется знакомым.
“
Ситуация реальная, сам хз как решить, в данный момент ищу варианты
Я джун РМ в it компании, у мебя под крылом 8+ проектов, 5+ заказчиков и на все 1 команда (1 бэк, 2 фронта, 1 дизайнер, 1 QA, 1 content manager). Каждый заказчик думает, что команда занимается только его проектом. 7 проектов на этапе поддержки(развития), 1 из проектов пилится с нуля, сейчас на этапе отрисовки прототипов.
Я как РМ выступаешь в роли BA, SA и РМ соответственно
Методология: хз, какая, но похоже на канбан.
В данный момент задачи поступают следующим образом:
Клиент приходит, ставит задачу не понимая до конца что он хочет, РМ обрабатывает её, передает на оценку команде, после согласовывает оценку с клиентом и берем в работу.
Задачи сыпятся с неба астроидами на бедные головы команды, я как РМ не успеваю их обрабатывать (технической подкованности не хватает, следовательно не высокая скорость работы. Пока разберусь что от меня хотят). Из-за этого снижается качество проработки каждой задачи мной как РМом и командой (баги наше всё)
*сказать заказчику нельзя, что есть другие проекты по мимо его.
Как мне РМу выстроить свою работу и работу команды таким образом, чтобы:
- повысить удовлетворенность клиента,
- повысить качество проработки задач,
- повысить скорость работы
Вместо 8 часов работаю 10-14.
Если сможешь мне чем то подсказать или закинуть это в канал для обсуждения будет прекрасно иначе я скоро повешусь в петле задач)))
“
P.S. Как можно жить в таких условиях и сохранить здравый рассудок — обсудим в следующем посте
Бомбардировка задачами. Часть 1
Здравствуй, ответственный читатель.
В почтовый ящик прилетело письмо, полное специфичных эмоций, которое наверняка тебе покажется знакомым.
“
Ситуация реальная, сам хз как решить, в данный момент ищу варианты
Я джун РМ в it компании, у мебя под крылом 8+ проектов, 5+ заказчиков и на все 1 команда (1 бэк, 2 фронта, 1 дизайнер, 1 QA, 1 content manager). Каждый заказчик думает, что команда занимается только его проектом. 7 проектов на этапе поддержки(развития), 1 из проектов пилится с нуля, сейчас на этапе отрисовки прототипов.
Я как РМ выступаешь в роли BA, SA и РМ соответственно
Методология: хз, какая, но похоже на канбан.
В данный момент задачи поступают следующим образом:
Клиент приходит, ставит задачу не понимая до конца что он хочет, РМ обрабатывает её, передает на оценку команде, после согласовывает оценку с клиентом и берем в работу.
Задачи сыпятся с неба астроидами на бедные головы команды, я как РМ не успеваю их обрабатывать (технической подкованности не хватает, следовательно не высокая скорость работы. Пока разберусь что от меня хотят). Из-за этого снижается качество проработки каждой задачи мной как РМом и командой (баги наше всё)
*сказать заказчику нельзя, что есть другие проекты по мимо его.
Как мне РМу выстроить свою работу и работу команды таким образом, чтобы:
- повысить удовлетворенность клиента,
- повысить качество проработки задач,
- повысить скорость работы
Вместо 8 часов работаю 10-14.
Если сможешь мне чем то подсказать или закинуть это в канал для обсуждения будет прекрасно иначе я скоро повешусь в петле задач)))
“
P.S. Как можно жить в таких условиях и сохранить здравый рассудок — обсудим в следующем посте
🔥1
#почтовый_ящик
Бомбардировка задачами. Часть 2
Понимаю тебя отлично — был в таких же тисках аутсорса, когда казалось, что на команду сваливаются не просто задачи, а настоящие астероиды из космоса. Угнаться за ними было просто нереально, а о качестве думать не оставалось ни сил, ни времени
Ты, как молодой менеджер, наверняка ощущаешь вину за то, что не справляешься, начинаешь работать до восхода солнца и заканчиваешь за полночь, а сверху всё прилетает и прилетает. И тут дело не в тебе, а в самой системе — это как наливать 15 литров воды в 10-литровое ведро и удивляться, что почему-то льется через край
У меня был похожий случай: таскал 11 проектов одновременно, и кажется, тоже жил на работе. Чем это закончилось? Выгоранием, просадкой по здоровью и потерей мотивации. Тогда-то я и понял, что вся эта гонка не имеет смысла без адекватного ресурсного и портфельного планирования
Но перед тем как двинуться дальше, предлагаю тебе одну простую штуку, которую я называю Декартовой системой координат для решений:
— Что будет, если оставить всё как есть?
— Чего не будет, если оставить всё как есть?
— Что будет, если ты начнешь что-то менять?
— Чего не будет, если ты начнешь что-то менять?
Теперь что можно сделать прямо сейчас (краткосрочно):
Во-первых, начни постепенно вводить частичную прозрачность. Я понимаю, руководство требует лукавить, что команда занимается исключительно задачами заказчика, но тебе нужно научиться договариваться иначе: «Чтобы качественно выполнить задачу, команде нужно вот столько времени». Это не «вышибалы», а честность, которая, к слову, является основой нормальных отношений с заказчиком. Лучше сказать реальный срок сразу, чем потом оправдываться за срыв
Во-вторых, установи ресурсные лимиты на себя и команду. Никто не может делать больше, чем физически возможно. Поэтому расставляй приоритеты утром и вечером проверяй, что реально успели сделать. Это снимет часть напряжения и позволит контролировать ситуацию
Долгосрочные решения:
1. Внедрить ресурсное планирование
Тебе нужно четко понимать доступность и емкость сотрудников хотя бы на месяц вперед. Для начала можешь использовать простую Excel-таблицу:
— Зафиксируй сотрудников и их доступность (часы или дни) на период, включая дейоффы, праздники, отпуска и тд;
— Учти запланированные встречи, регулярные активности и резерв на непредвиденные ситуации или риски;
— Аллоцируй сотрудников на задачи с учетом последовательности;
— Выравнивай ресурсы по задачам, соблюдая баланс между нагрузкой и приоритетностью задач;
— Это поможет тебе аргументированно говорить руководству и заказчикам о том, что ресурсы ограничены и задачи нужно планировать с учетом реальной загруженности, а не «тяп-ляп»
2. Начать управлять портфелем проектов
Проекты должны оцениваться и приоритизироваться с учетом бизнес-показателей:
— Регулярно анализируй и оценивай проекты по ROI, маржинальности, обороту и стратегической важности для компании;
— Составь карту портфеля и выяви пересечения проектов по срокам, ресурсам и задачам;
— Учти влияние проектов на финансовые потоки (cash flow) компании, чтобы руководство видело прозрачную картину и понимало важность более качественного и планового подхода;
— Это позволит тебе иметь объективную аргументацию и четко понимать, когда стоит отказаться от задачи или перенести ее на другое время, сохранив и ресурсы, и репутацию компании;
3. Начать вести прозрачный диалог внутри компании
Тебе нужно показать руководству, что честность и предсказуемость важны клиентам. Вместо того, чтобы скрывать загрузку команды, предложи фокусироваться на долгосрочных контрактах и понятной аллокации ресурсов. Это снизит количество «пожаров» и повысит доверие к вам как к профессионалам
Бомбардировка задачами. Часть 2
Понимаю тебя отлично — был в таких же тисках аутсорса, когда казалось, что на команду сваливаются не просто задачи, а настоящие астероиды из космоса. Угнаться за ними было просто нереально, а о качестве думать не оставалось ни сил, ни времени
Ты, как молодой менеджер, наверняка ощущаешь вину за то, что не справляешься, начинаешь работать до восхода солнца и заканчиваешь за полночь, а сверху всё прилетает и прилетает. И тут дело не в тебе, а в самой системе — это как наливать 15 литров воды в 10-литровое ведро и удивляться, что почему-то льется через край
У меня был похожий случай: таскал 11 проектов одновременно, и кажется, тоже жил на работе. Чем это закончилось? Выгоранием, просадкой по здоровью и потерей мотивации. Тогда-то я и понял, что вся эта гонка не имеет смысла без адекватного ресурсного и портфельного планирования
Но перед тем как двинуться дальше, предлагаю тебе одну простую штуку, которую я называю Декартовой системой координат для решений:
— Что будет, если оставить всё как есть?
— Чего не будет, если оставить всё как есть?
— Что будет, если ты начнешь что-то менять?
— Чего не будет, если ты начнешь что-то менять?
Теперь что можно сделать прямо сейчас (краткосрочно):
Во-первых, начни постепенно вводить частичную прозрачность. Я понимаю, руководство требует лукавить, что команда занимается исключительно задачами заказчика, но тебе нужно научиться договариваться иначе: «Чтобы качественно выполнить задачу, команде нужно вот столько времени». Это не «вышибалы», а честность, которая, к слову, является основой нормальных отношений с заказчиком. Лучше сказать реальный срок сразу, чем потом оправдываться за срыв
Во-вторых, установи ресурсные лимиты на себя и команду. Никто не может делать больше, чем физически возможно. Поэтому расставляй приоритеты утром и вечером проверяй, что реально успели сделать. Это снимет часть напряжения и позволит контролировать ситуацию
Долгосрочные решения:
1. Внедрить ресурсное планирование
Тебе нужно четко понимать доступность и емкость сотрудников хотя бы на месяц вперед. Для начала можешь использовать простую Excel-таблицу:
— Зафиксируй сотрудников и их доступность (часы или дни) на период, включая дейоффы, праздники, отпуска и тд;
— Учти запланированные встречи, регулярные активности и резерв на непредвиденные ситуации или риски;
— Аллоцируй сотрудников на задачи с учетом последовательности;
— Выравнивай ресурсы по задачам, соблюдая баланс между нагрузкой и приоритетностью задач;
— Это поможет тебе аргументированно говорить руководству и заказчикам о том, что ресурсы ограничены и задачи нужно планировать с учетом реальной загруженности, а не «тяп-ляп»
2. Начать управлять портфелем проектов
Проекты должны оцениваться и приоритизироваться с учетом бизнес-показателей:
— Регулярно анализируй и оценивай проекты по ROI, маржинальности, обороту и стратегической важности для компании;
— Составь карту портфеля и выяви пересечения проектов по срокам, ресурсам и задачам;
— Учти влияние проектов на финансовые потоки (cash flow) компании, чтобы руководство видело прозрачную картину и понимало важность более качественного и планового подхода;
— Это позволит тебе иметь объективную аргументацию и четко понимать, когда стоит отказаться от задачи или перенести ее на другое время, сохранив и ресурсы, и репутацию компании;
3. Начать вести прозрачный диалог внутри компании
Тебе нужно показать руководству, что честность и предсказуемость важны клиентам. Вместо того, чтобы скрывать загрузку команды, предложи фокусироваться на долгосрочных контрактах и понятной аллокации ресурсов. Это снизит количество «пожаров» и повысит доверие к вам как к профессионалам
👍14👎1
#почтовый_ящик
Бомбардировка задач. Часть 3
1. Стать сервисным партнёром, а не конторой-подрядчиком
Гораздо круче работать с заказчиком на партнёрских условиях. Скажи открыто: «Команда загружена, но если это очень важно, мы можем увеличить команду под эту задачу». Честность тут будет большим плюсом. Постепенно заказчики поймут, что вы не просто код пишете, а помогаете им достигать бизнес-целей
Самое главное, помни — настоящая сила менеджера не в том, чтобы постоянно тушить пожары, а в умении их предотвращать. Если твоя текущая компания не готова меняться, то хотя бы твой подход должен меняться. Получай новые навыки, развивайся, и со временем ты найдешь место, где тебя будут ценить не за способность работать на износ, а за твоё мастерство и грамотный подход к управлению проектами и людьми
P.S. Поверь, и я когда-то думал, что иначе работать нельзя. Но можно. И нужно. Особенно, если тебе нравится быть живым, а не вечно загнанным в угол «заложником ситуации»
Бомбардировка задач. Часть 3
1. Стать сервисным партнёром, а не конторой-подрядчиком
Гораздо круче работать с заказчиком на партнёрских условиях. Скажи открыто: «Команда загружена, но если это очень важно, мы можем увеличить команду под эту задачу». Честность тут будет большим плюсом. Постепенно заказчики поймут, что вы не просто код пишете, а помогаете им достигать бизнес-целей
Самое главное, помни — настоящая сила менеджера не в том, чтобы постоянно тушить пожары, а в умении их предотвращать. Если твоя текущая компания не готова меняться, то хотя бы твой подход должен меняться. Получай новые навыки, развивайся, и со временем ты найдешь место, где тебя будут ценить не за способность работать на износ, а за твоё мастерство и грамотный подход к управлению проектами и людьми
P.S. Поверь, и я когда-то думал, что иначе работать нельзя. Но можно. И нужно. Особенно, если тебе нравится быть живым, а не вечно загнанным в угол «заложником ситуации»
👍16
#мнение
Вайбкодинг выходного дня
Здравствуй, околоайтишный читатель! Сегодня я хочу поделиться своим обзором сервиса от Google https://studio.firebase.google.com/, который я опробовал в рамках разработки моего веб-приложения по приколу. Сказать что мы все ближе к замене разработчиков сложно, но мы определенно к этому идем
Сервис обещает быстрый прототайпинг, объединяя облачную IDE, визуальный редактор и все возможности Firebase «из коробки»
При старте работы создаётся новый workspace, где можно создать новый проект на различных языках или загрузить уже существующий (например, из GitHub). Сервис позволяет работать в двух режимах:
Режим превью: сразу отображается созданный сайт в основном окне (при желании можно открыть его в отдельной вкладке);
Классическая IDE: по сути, это браузерная версия VS Code с поддержкой всех настроек и расширений, что устраняет необходимость настраивать локальное окружение
Мое специфичное мнение:
1. Ограничения большого системного промпта
При использовании обширных системных промптов сервис сразу не справляется с генерацией большой функциональности. Если заканчивается контекстное окно, результат резко обрезается, и команда забывается. Инструменты типа Replit или Cursor хотя бы давали обратную связь о проблеме;
2. Отсутствие объяснений решений
Сервис не поясняет, почему так или иначе был сгенерирован код, что усложняет понимание логики работы приложения;
3. Недостаток логического мышления и планирования
Платформа практически не умеет выстраивать план решения задачи или демонстрировать какие-либо рассуждения. Фактически, под капотом ощущается работа Gemini 2.0 flash, без продуманного ризонинга;
4. Ограниченные возможности самоисправления
Сервис способен выполнить одну итерацию исправления ошибок, но при последующих попытках может оставить сломанный код без дальнейшей поддержки;
5. Архитектурные проблемы
Построение архитектуры оставляет желать лучшего: получаются одностраничники с перемешанными представлениями, что может стать проблемой при увеличении сложности проекта;
6. Удобная облачная IDE
Разработчики не стали выпендриваться – платформа предоставляет привычный интерфейс VS Code в браузере, освобождая от заботы о локальных настройках. Наличие расширений делает работу ещё удобнее;
7. Интеграция с Gemini через API
Есть возможность интегрировать Gemini как AI через API, что позволяет давать ей задачи и тонко настраивать генерируемое решение под конкретные нужды проекта;
8. Плюшки Firebase «из коробки»
Есть множество инстурментов: эп-хостинг, линтер, аналитика, CI/CD и другие инструменты, что значительно ускоряет процесс разработки и публикации;
9. Публикация в GitHub одной кнопкой
Возможность выложить проект в GitHub нажатием всего одной кнопки – огромное удобство для быстрого деплоя и работы с вершн-контролем;
10. Автоматическое оборачивание запросов в коммиты
Каждый новый запрос автоматически превращается в коммит. Хотя автоматический пуш может быть не самой лучшей идеей, это решение помогает отслеживать изменения;
11. Интуитивный визуальный редактор
Применение визуального редактора, где можно кликать по элементам или выделять области (рисовать квадратики), позволяет быстро дать понять системе, что именно требуется изменить в интерфейсе;
12. Проблемы с UX и производительностью
Минусом является то, что разработчики, судя по всему, спешили: обнаруживается множество багов, интерфейс работает медленно, а UX оставляет желать лучшего. Глаза вытекали пока работал;
13. Бесплатность и моментальная публикация
Один из самых весомых плюсов – сервис бесплатен. Всего три действия, и твой проект запаблишен, а код готов развернуться даже на моём хостинге. Естественно пока в бета-тесте.
Вывод
Для быстрого прототипирования данный сервис уже сейчас является мощным инструментом
Мой собственный сервис AccentCoach: https://studio--accentcoach-bjcdj.us-central1.hosted.app/
P.S. Помни, иногда скорость и оперативность важнее идеальной отлаженности каждого механизма
Вайбкодинг выходного дня
Здравствуй, околоайтишный читатель! Сегодня я хочу поделиться своим обзором сервиса от Google https://studio.firebase.google.com/, который я опробовал в рамках разработки моего веб-приложения по приколу. Сказать что мы все ближе к замене разработчиков сложно, но мы определенно к этому идем
Сервис обещает быстрый прототайпинг, объединяя облачную IDE, визуальный редактор и все возможности Firebase «из коробки»
При старте работы создаётся новый workspace, где можно создать новый проект на различных языках или загрузить уже существующий (например, из GitHub). Сервис позволяет работать в двух режимах:
Режим превью: сразу отображается созданный сайт в основном окне (при желании можно открыть его в отдельной вкладке);
Классическая IDE: по сути, это браузерная версия VS Code с поддержкой всех настроек и расширений, что устраняет необходимость настраивать локальное окружение
Мое специфичное мнение:
1. Ограничения большого системного промпта
При использовании обширных системных промптов сервис сразу не справляется с генерацией большой функциональности. Если заканчивается контекстное окно, результат резко обрезается, и команда забывается. Инструменты типа Replit или Cursor хотя бы давали обратную связь о проблеме;
2. Отсутствие объяснений решений
Сервис не поясняет, почему так или иначе был сгенерирован код, что усложняет понимание логики работы приложения;
3. Недостаток логического мышления и планирования
Платформа практически не умеет выстраивать план решения задачи или демонстрировать какие-либо рассуждения. Фактически, под капотом ощущается работа Gemini 2.0 flash, без продуманного ризонинга;
4. Ограниченные возможности самоисправления
Сервис способен выполнить одну итерацию исправления ошибок, но при последующих попытках может оставить сломанный код без дальнейшей поддержки;
5. Архитектурные проблемы
Построение архитектуры оставляет желать лучшего: получаются одностраничники с перемешанными представлениями, что может стать проблемой при увеличении сложности проекта;
6. Удобная облачная IDE
Разработчики не стали выпендриваться – платформа предоставляет привычный интерфейс VS Code в браузере, освобождая от заботы о локальных настройках. Наличие расширений делает работу ещё удобнее;
7. Интеграция с Gemini через API
Есть возможность интегрировать Gemini как AI через API, что позволяет давать ей задачи и тонко настраивать генерируемое решение под конкретные нужды проекта;
8. Плюшки Firebase «из коробки»
Есть множество инстурментов: эп-хостинг, линтер, аналитика, CI/CD и другие инструменты, что значительно ускоряет процесс разработки и публикации;
9. Публикация в GitHub одной кнопкой
Возможность выложить проект в GitHub нажатием всего одной кнопки – огромное удобство для быстрого деплоя и работы с вершн-контролем;
10. Автоматическое оборачивание запросов в коммиты
Каждый новый запрос автоматически превращается в коммит. Хотя автоматический пуш может быть не самой лучшей идеей, это решение помогает отслеживать изменения;
11. Интуитивный визуальный редактор
Применение визуального редактора, где можно кликать по элементам или выделять области (рисовать квадратики), позволяет быстро дать понять системе, что именно требуется изменить в интерфейсе;
12. Проблемы с UX и производительностью
Минусом является то, что разработчики, судя по всему, спешили: обнаруживается множество багов, интерфейс работает медленно, а UX оставляет желать лучшего. Глаза вытекали пока работал;
13. Бесплатность и моментальная публикация
Один из самых весомых плюсов – сервис бесплатен. Всего три действия, и твой проект запаблишен, а код готов развернуться даже на моём хостинге. Естественно пока в бета-тесте.
Вывод
Для быстрого прототипирования данный сервис уже сейчас является мощным инструментом
Мой собственный сервис AccentCoach: https://studio--accentcoach-bjcdj.us-central1.hosted.app/
P.S. Помни, иногда скорость и оперативность важнее идеальной отлаженности каждого механизма
👍4👀2
#рецепт
Секретное оружие: ресурсное планирование
Здравствуй, дорогой читатель. Ты не поверишь, но многие начинающие менеджеры в последнее время совсем забывают про важнющую штуку — ресурсное планирование. Главное помни правило клуба - НИКОГДА НЕ НАЗЫВАЙ РЕСУРС РЕСУРСОМ ПРИ РЕСУРСЕ (профессионализмы могут быть странными и непогруженных могут обидеть)
Классическая логика планирования
В водопадном подходе план идёт от требований к расписанию. Подробнее смотри у Селиховкина:
https://drive.google.com/file/d/1uCV7cu_1JgVGYk9pXP-LFCv1E1EdNF3m/view?usp=sharing
1. Формируем матрицу требований (матрицу трассировки), чтобы связать каждый запрос заказчика с конкретными результатами: https://habr.com/ru/articles/831922/;
2. Далее — WBS, декомпозиция проекта на мелкие задачи (чтобы сразу было понятно, что за чем идёт):https://kaiten.ru/blog/model-wbs/;
3. Потом строим сетевую диаграмму, чтобы увидеть зависимости между задачами: https://forpm.ru/сетевой-график);
4. На основе WBS и сети определяем ресурсы, причём есть неплохая статья про это: https://probusiness.io/master_class/529-chto-nado-znat-pro-raspredelenie-resursov-chtoby-ne-zagubit-dazhe-khoroshiy-plan-proekta.html;
5. А параллельно оцениваем трудоёмкость/продолжительность — и в итоге получаем календарный план (диаграмму Ганта).
Основные этапы ресурсного планирования
1. Оценка доступности: учитываем, кто у нас вообще есть в команде, загружен ли кто-то другой работой, не ушёл ли в отпуск и тд.;
2. Оценка ёмкости: определяем, сколько времени реально может выделить каждый человек (FTE, часы и т.д.). Планировать 100% загрузку — наивно; оставь буфер на форс-мажор и обязательные митинги;
3. Предварительный прогноз качества ресурсов*: если задача сложная, то нужны опытные люди (например, только синьору можно);
4. Аллокация: распределяем, кто что делает. Связываем ресурс с задачей на диаграмме Ганта, в Excel таблице или таск-трекере;
5. Переоценка задач: смотрим, не вышло ли так, что один спец назначен сразу на три фронта. Если что — меняем план, ищем дополнительные руки;
6. Выровнивание ресурсов: обрезаем перегрузки, двигаем задачи, включаем автоматику (Microsoft Project и др.), чтобы не было «двойного бронирования»;
7. Актуализация и контроль: постоянно проверяем, как загрузка сходится с реальностью, ведь у нас могут уйти люди, или задачи сдвинулись.
И да, если у менеджера нет формальных подчинённых, часто помогают тимлиды и руководители отделов: они же владельцы «ресурсов». В итоге получаем документ (или диаграмму, или таблицу) — там расписано, кто и когда участвует в проекте. Без этого велик риск перегрузить команду и потом делать ночные овертаймы
P.S. В гибком мире тоже нужно планировать, даже если ты скрам-мастер «свободной команды». От хорошего ресурсного плана ещё никто не становился менее адаптивным. Обычно когда где-то все плохо с точки зрения успевания в сроки ресурсный план - одно из первых что я делаю
P.P.S А у тебя на работе есть ресурсное планирование? Поделись, как оно организовано!
Секретное оружие: ресурсное планирование
Здравствуй, дорогой читатель. Ты не поверишь, но многие начинающие менеджеры в последнее время совсем забывают про важнющую штуку — ресурсное планирование. Главное помни правило клуба - НИКОГДА НЕ НАЗЫВАЙ РЕСУРС РЕСУРСОМ ПРИ РЕСУРСЕ (профессионализмы могут быть странными и непогруженных могут обидеть)
Классическая логика планирования
В водопадном подходе план идёт от требований к расписанию. Подробнее смотри у Селиховкина:
https://drive.google.com/file/d/1uCV7cu_1JgVGYk9pXP-LFCv1E1EdNF3m/view?usp=sharing
1. Формируем матрицу требований (матрицу трассировки), чтобы связать каждый запрос заказчика с конкретными результатами: https://habr.com/ru/articles/831922/;
2. Далее — WBS, декомпозиция проекта на мелкие задачи (чтобы сразу было понятно, что за чем идёт):https://kaiten.ru/blog/model-wbs/;
3. Потом строим сетевую диаграмму, чтобы увидеть зависимости между задачами: https://forpm.ru/сетевой-график);
4. На основе WBS и сети определяем ресурсы, причём есть неплохая статья про это: https://probusiness.io/master_class/529-chto-nado-znat-pro-raspredelenie-resursov-chtoby-ne-zagubit-dazhe-khoroshiy-plan-proekta.html;
5. А параллельно оцениваем трудоёмкость/продолжительность — и в итоге получаем календарный план (диаграмму Ганта).
Основные этапы ресурсного планирования
1. Оценка доступности: учитываем, кто у нас вообще есть в команде, загружен ли кто-то другой работой, не ушёл ли в отпуск и тд.;
2. Оценка ёмкости: определяем, сколько времени реально может выделить каждый человек (FTE, часы и т.д.). Планировать 100% загрузку — наивно; оставь буфер на форс-мажор и обязательные митинги;
3. Предварительный прогноз качества ресурсов*: если задача сложная, то нужны опытные люди (например, только синьору можно);
4. Аллокация: распределяем, кто что делает. Связываем ресурс с задачей на диаграмме Ганта, в Excel таблице или таск-трекере;
5. Переоценка задач: смотрим, не вышло ли так, что один спец назначен сразу на три фронта. Если что — меняем план, ищем дополнительные руки;
6. Выровнивание ресурсов: обрезаем перегрузки, двигаем задачи, включаем автоматику (Microsoft Project и др.), чтобы не было «двойного бронирования»;
7. Актуализация и контроль: постоянно проверяем, как загрузка сходится с реальностью, ведь у нас могут уйти люди, или задачи сдвинулись.
И да, если у менеджера нет формальных подчинённых, часто помогают тимлиды и руководители отделов: они же владельцы «ресурсов». В итоге получаем документ (или диаграмму, или таблицу) — там расписано, кто и когда участвует в проекте. Без этого велик риск перегрузить команду и потом делать ночные овертаймы
P.S. В гибком мире тоже нужно планировать, даже если ты скрам-мастер «свободной команды». От хорошего ресурсного плана ещё никто не становился менее адаптивным. Обычно когда где-то все плохо с точки зрения успевания в сроки ресурсный план - одно из первых что я делаю
P.P.S А у тебя на работе есть ресурсное планирование? Поделись, как оно организовано!
👍24🔥3
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты проджект менеджер в компании Целестиал и вызрабатываете аналог Scopify, движок для интернет-магазинов. У вас в компании ПМ являются частью продуктового офиса, подчинаются CPO и больше работают в формате сервис деливери менеджеров.
В рамках работы ты присматриваешь за двумя фича-командами в яркой манерой, Паладины (обожают вов) и Десантинками (фаны вахи). Обе питаются входящими задачами от единой команды системных аналитиков, которой передают требования стейкхолдеры, часто напрямую продакты. Часть аналитиков пишет лаконичные требования в формате бизнес концепций и критериев приемки, а другая считает, что надо рисовать UML-диаграммы и расписывать юзкейсы, их постановки соответствующие
Недавно пошла в работу большая фича — интеграция платформы с adoCRM, чтобы заказы и лиды обрабатывались автоматически. И тут началось неожиданное: Паладины уверяют, что аналитики накидали слишком сырые требования и не заложили нюансов. Десантники, наоборот, пеняют на горы схем, которые оказались неполными: «они в отрыве от цели фичи и здравого смысла». Ты пытаешься погасить этот пожар, созваниваясь с каждой стороной, но каждый интеграционный дейли превращается в перепалку: одни говорят, что слишком много документации убивает скорость, другие уверяют, что невнимание к структуре «превратит код в спаггети»
Продуктовый офис уже замечает, что сроки горят, а интеграция всё ещё не работает — клиенты пилят свои коннекторы и недовольны этим. Ты собрал фактуру, факторы конфлитной среды и мотивы, замечательно задизайнил встречу, но твоя выдающая фасилитация ни к чему не привела, разговор превратился в очередной спор, кто виноват, что фича буксует. Десантники продолжают обвинять аналитиков в излишнем формализме, а Паладины убеждена, что коллеги просто игнорируют нужные описания. Сверху тебя просят «привести людей в чувство» и как-то ускорить релиз, но при этом не скатиться в микроменеджмент, ибо не просто также была аджайл трансформация
Какую сторону ты займешь? Как выйдешь из этой ситуации?
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты проджект менеджер в компании Целестиал и вызрабатываете аналог Scopify, движок для интернет-магазинов. У вас в компании ПМ являются частью продуктового офиса, подчинаются CPO и больше работают в формате сервис деливери менеджеров.
В рамках работы ты присматриваешь за двумя фича-командами в яркой манерой, Паладины (обожают вов) и Десантинками (фаны вахи). Обе питаются входящими задачами от единой команды системных аналитиков, которой передают требования стейкхолдеры, часто напрямую продакты. Часть аналитиков пишет лаконичные требования в формате бизнес концепций и критериев приемки, а другая считает, что надо рисовать UML-диаграммы и расписывать юзкейсы, их постановки соответствующие
Недавно пошла в работу большая фича — интеграция платформы с adoCRM, чтобы заказы и лиды обрабатывались автоматически. И тут началось неожиданное: Паладины уверяют, что аналитики накидали слишком сырые требования и не заложили нюансов. Десантники, наоборот, пеняют на горы схем, которые оказались неполными: «они в отрыве от цели фичи и здравого смысла». Ты пытаешься погасить этот пожар, созваниваясь с каждой стороной, но каждый интеграционный дейли превращается в перепалку: одни говорят, что слишком много документации убивает скорость, другие уверяют, что невнимание к структуре «превратит код в спаггети»
Продуктовый офис уже замечает, что сроки горят, а интеграция всё ещё не работает — клиенты пилят свои коннекторы и недовольны этим. Ты собрал фактуру, факторы конфлитной среды и мотивы, замечательно задизайнил встречу, но твоя выдающая фасилитация ни к чему не привела, разговор превратился в очередной спор, кто виноват, что фича буксует. Десантники продолжают обвинять аналитиков в излишнем формализме, а Паладины убеждена, что коллеги просто игнорируют нужные описания. Сверху тебя просят «привести людей в чувство» и как-то ускорить релиз, но при этом не скатиться в микроменеджмент, ибо не просто также была аджайл трансформация
Какую сторону ты займешь? Как выйдешь из этой ситуации?
👍6🥴4
Что ты выберешь как курс действий?
Anonymous Poll
23%
Централизовать роль аналитика и задать процесс директивно
40%
Разделить аналитиков: на бизнес и тех фокус
7%
Пусть команды сами решают, без тебя, не маленькие
17%
Завести внешнего фасилитатора для выработки норм, например архитектора
5%
Перейти на итеративную wiki-документацию
5%
Docs-as-code!
3%
Твой вариант (напиши в комментариях)
В последнее время очень сильно упало число просмотров, реакций и в целом вовлеченность. Что то поменялось в контенте, формате и вам стало менее интересно? Или я что-то упускаю?
🤔25💩5🤡5👀3
#рецепт
Как правильно работать с капасити и велосити
Здравствуй неутомимый читатель! Я услышал твою обратную связь и пришел с более практическим, менее AI-вылизанным и менее частым контентом
Если ты хочешь, чтобы твоя команда прослыла действительно хай-перфоманс и наблюдаемой, то лови подборку приёмов, которые действительно забустят твой скрам-но:
- Начни с простого: объяви команде, что капасити и велосити — это один и тот же «спидометр»
- Велосити считай по трём самым удачным спринтам, когда «звёзды легли». Если вдруг текущий результат ниже 50 %, смело говори: «Метрика сомнительная и плавающая, не обращайте внимания”
- Длина итераций — тема для творчества. На этой итерациии сделай спринт на 10 дней, в следующей — на 15. Аргументируй “под гибкость рынка” и “неотменимостью запросов продактов”
- Спишишь? Перезапусти спринт на середине. Всё, что недоделано, выкинь из истории: «Мы же итерируемся, ребята!». Исторические данные как бы ничего не говорят
- На планировании подмигни команде и скажи: «Учёные доказали: story points чудесно складываются — 2 + 5 = 7, главное верить». Сошлись на центральную предельную теорему — большинство перестанет задавать вопросы после слов «агрегация» и «мода»
- Капасити? Планируй под единственный возможный сценарий: «никто не болеет, отпусков нет, встреч нет. инцидентов нет». Аргумент: «Scrum‑гайд про февральские простуды молчит, значит их не бывает»
P.S. Вторая порция в комментариях. Следуй этим приёмам регулярно и ваш скрам точно будет достоин рассказа на конференции
P.P.S. Чего на твой взгляд еще не хватает в списке?
Как правильно работать с капасити и велосити
Здравствуй неутомимый читатель! Я услышал твою обратную связь и пришел с более практическим, менее AI-вылизанным и менее частым контентом
Если ты хочешь, чтобы твоя команда прослыла действительно хай-перфоманс и наблюдаемой, то лови подборку приёмов, которые действительно забустят твой скрам-но:
- Начни с простого: объяви команде, что капасити и велосити — это один и тот же «спидометр»
- Велосити считай по трём самым удачным спринтам, когда «звёзды легли». Если вдруг текущий результат ниже 50 %, смело говори: «Метрика сомнительная и плавающая, не обращайте внимания”
- Длина итераций — тема для творчества. На этой итерациии сделай спринт на 10 дней, в следующей — на 15. Аргументируй “под гибкость рынка” и “неотменимостью запросов продактов”
- Спишишь? Перезапусти спринт на середине. Всё, что недоделано, выкинь из истории: «Мы же итерируемся, ребята!». Исторические данные как бы ничего не говорят
- На планировании подмигни команде и скажи: «Учёные доказали: story points чудесно складываются — 2 + 5 = 7, главное верить». Сошлись на центральную предельную теорему — большинство перестанет задавать вопросы после слов «агрегация» и «мода»
- Капасити? Планируй под единственный возможный сценарий: «никто не болеет, отпусков нет, встреч нет. инцидентов нет». Аргумент: «Scrum‑гайд про февральские простуды молчит, значит их не бывает»
P.S. Вторая порция в комментариях. Следуй этим приёмам регулярно и ваш скрам точно будет достоин рассказа на конференции
P.P.S. Чего на твой взгляд еще не хватает в списке?
😁17🔥6
#артефакты
Тренажёр постановки задач на коленке
Здравствуй, подкованный читатель
Я встал в легкий ступор, особенно после последней обратной связи на посты. Мне нравится давать контент, который можно утащить и переиспользовать, а не просто прочитать слегка задуматься. И тут я застрял, а чего бы такого написать из того что мне нравится, ибо давать шаблон условной матрицы требований, если условный Grok это сделает лучше. Хороший статей не особо много именно про то как ставить задачи, а не писать ТЗ и так родился этот пост
Я собрал на коленке Task-Setting Trainer — GPT-S https://chatgpt.com/g/g-68088b1d1b648191845465ffe163f8c1-gpt-s-task-setting-trainer, который учит формулировать постановку на разработчика чуть сложнее чем User Story
Когда я задумал Trainer, первая идея была: реализовать всё на Google AppScripts — дергай данные из гугл табличек, сохраняй инструкции в Drive, строй UI прямо в браузере. Но быстро я осознал, что OAuth, квоты и тонны boilerplate-кода превратят прототип в эпопею, а чтобы ты горел как я с вайб-код генерации я не хочу. Поэтому я свернул AppScripts и остановился на JSFiddle: чистый HTML+JS, мгновенный запуск и минимум геморроя
Второй мой просчёт — я забыл, что у многих нет GPT-Plus или Team. Чтобы не оставить тебя без тренажёра, я прикладываю в комментариях все файлы с инструкциями и канвой работы. Копируй их в DeepSeek или любой аналог n8n — и твоя копия бота заработает без ChatGPT
P.S. Жду твоих идей и новых сценариев для тренажёра!
Тренажёр постановки задач на коленке
Здравствуй, подкованный читатель
Я встал в легкий ступор, особенно после последней обратной связи на посты. Мне нравится давать контент, который можно утащить и переиспользовать, а не просто прочитать слегка задуматься. И тут я застрял, а чего бы такого написать из того что мне нравится, ибо давать шаблон условной матрицы требований, если условный Grok это сделает лучше. Хороший статей не особо много именно про то как ставить задачи, а не писать ТЗ и так родился этот пост
Я собрал на коленке Task-Setting Trainer — GPT-S https://chatgpt.com/g/g-68088b1d1b648191845465ffe163f8c1-gpt-s-task-setting-trainer, который учит формулировать постановку на разработчика чуть сложнее чем User Story
Когда я задумал Trainer, первая идея была: реализовать всё на Google AppScripts — дергай данные из гугл табличек, сохраняй инструкции в Drive, строй UI прямо в браузере. Но быстро я осознал, что OAuth, квоты и тонны boilerplate-кода превратят прототип в эпопею, а чтобы ты горел как я с вайб-код генерации я не хочу. Поэтому я свернул AppScripts и остановился на JSFiddle: чистый HTML+JS, мгновенный запуск и минимум геморроя
Второй мой просчёт — я забыл, что у многих нет GPT-Plus или Team. Чтобы не оставить тебя без тренажёра, я прикладываю в комментариях все файлы с инструкциями и канвой работы. Копируй их в DeepSeek или любой аналог n8n — и твоя копия бота заработает без ChatGPT
P.S. Жду твоих идей и новых сценариев для тренажёра!
🔥23💩4👍2👀1
#мнение
Здравствуй, упорный читатель! Я рад что ты меня не отписываешься в моменты тишины
Ты, наверное, заметил, что меня здесь давненько не было, и подумал: “Куда пропал Артём?”. Я, как обычно, немного перегнул палку и загрузил себя по полной: кроме управления четырьмя командами (кстати, одна из них DS Core с интересными задачками по AI), я в ещё включился в операционку OKR и внедрение инцидент-менеджмента и прочего по ITIL
К этому счастью сверху свалились консультации стартапа по операционным процессам на старте, параллельное менторство, программный комитет и поездка в Ташкент на конференцию asiconf.uz, а также создание курса «Gen AI на пальцах» для менеджеров в digital (потом как-нибудь анонс)
И немного полезного. Ты знаешь, что я люблю упрощать управленческие концепции до понятных и практичных схем. Так и появилась модель «руководитель на деле». В ней всё просто, как в известном меме «это же просто…». Руководитель — это человек, у которого есть стержень, навыки и мотивация
Я даже сделал систему координат XYZ от 0 до 3 по каждой оси:
- 0 - не обнаружено;
- 1 - что-то есть, но надо поднажать;
- 2 - нормально, но есть куда расти;
- 3 - молодца, вопросов нет!
Оценка простая и субъективная, основанная на личных наблюдениях и кейсах. Например, когда человек показал отличные навыки при откате важного релиза, но потом перед руководством стал валить вину на команду - это сразу для меня сигнал
Настоящий руководитель для меня начинается от стержня - 2, навыков - 1 и мотивации - 1. Если что-то по 0 - для меня это алярм. Со своими подчиненными или чаще «подшефными» (часто лиды как бы мои, но наделе у них свой руководитель) я выбираю простые стратегии воздействия: учить, лечить или мочить. Именно в таком порядке:
- Учить - если у человека нормальная мотивация, есть стержень, но не хватает конкретных навыков или опыта. Тогда я помогаю ему расти и закрывать пробелы. И не важно они в софтах или хардах. Применяю например для Н - 1, М -1, С - 2;
- Лечить - когда навыки и стержень на месте, но мотивация проседает. Здесь уже разговоры, поддержка и поиск того, что именно драйвит человека, что его мотивирует и почему сейчас нет огня в глазах;
- Мочить - звучит жёстко, но это неизбежно, если нет и стержня, и мотивации. Я могу помочь научиться или устранить препятствия, но не сломать психику об колено. С такими людьми лучше расставаться или ротировать их от ответственности, чтобы не тормозить команду и не тратить ресурсы на бесконечные попытки улучшения
Это и есть моя простая и категоричная формула управления, основанная на моём личном опыте и стиле
P.S. А какие у тебя критерии настоящего руководителя и что думаешь про мои методы?
Здравствуй, упорный читатель! Я рад что ты меня не отписываешься в моменты тишины
Ты, наверное, заметил, что меня здесь давненько не было, и подумал: “Куда пропал Артём?”. Я, как обычно, немного перегнул палку и загрузил себя по полной: кроме управления четырьмя командами (кстати, одна из них DS Core с интересными задачками по AI), я в ещё включился в операционку OKR и внедрение инцидент-менеджмента и прочего по ITIL
К этому счастью сверху свалились консультации стартапа по операционным процессам на старте, параллельное менторство, программный комитет и поездка в Ташкент на конференцию asiconf.uz, а также создание курса «Gen AI на пальцах» для менеджеров в digital (потом как-нибудь анонс)
И немного полезного. Ты знаешь, что я люблю упрощать управленческие концепции до понятных и практичных схем. Так и появилась модель «руководитель на деле». В ней всё просто, как в известном меме «это же просто…». Руководитель — это человек, у которого есть стержень, навыки и мотивация
Я даже сделал систему координат XYZ от 0 до 3 по каждой оси:
- 0 - не обнаружено;
- 1 - что-то есть, но надо поднажать;
- 2 - нормально, но есть куда расти;
- 3 - молодца, вопросов нет!
Оценка простая и субъективная, основанная на личных наблюдениях и кейсах. Например, когда человек показал отличные навыки при откате важного релиза, но потом перед руководством стал валить вину на команду - это сразу для меня сигнал
Настоящий руководитель для меня начинается от стержня - 2, навыков - 1 и мотивации - 1. Если что-то по 0 - для меня это алярм. Со своими подчиненными или чаще «подшефными» (часто лиды как бы мои, но наделе у них свой руководитель) я выбираю простые стратегии воздействия: учить, лечить или мочить. Именно в таком порядке:
- Учить - если у человека нормальная мотивация, есть стержень, но не хватает конкретных навыков или опыта. Тогда я помогаю ему расти и закрывать пробелы. И не важно они в софтах или хардах. Применяю например для Н - 1, М -1, С - 2;
- Лечить - когда навыки и стержень на месте, но мотивация проседает. Здесь уже разговоры, поддержка и поиск того, что именно драйвит человека, что его мотивирует и почему сейчас нет огня в глазах;
- Мочить - звучит жёстко, но это неизбежно, если нет и стержня, и мотивации. Я могу помочь научиться или устранить препятствия, но не сломать психику об колено. С такими людьми лучше расставаться или ротировать их от ответственности, чтобы не тормозить команду и не тратить ресурсы на бесконечные попытки улучшения
Это и есть моя простая и категоричная формула управления, основанная на моём личном опыте и стиле
P.S. А какие у тебя критерии настоящего руководителя и что думаешь про мои методы?
👍19💩4
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Был запрос на личное - рассказываю персональный кейс
В основном я работаю ровно столько, сколько указано в контракте. Без лукавства и без фанатизма - восемь часов в день, мне все таки уже не 20 и есть в жизни вещи кроме работы. За исключением, конечно, редких ситуаций, когда "всё совсем горит ***ть" или когда лично обещал что-то C-lvl
Но вот что интересно: в эти восемь часов с течением времени стало влезать всё больше тяжёлых задач и они едят больше энергии. Раньше было условно так: 3 встречи , 3-4 задачки по часу и операционка на часик + по мелочи. А теперь: плотная подготовка к встречам, куча синхронизаций с кем-то, продолжительные задачи на изменения процессов или подготовку новых релизов. Хронометраж плотнее, задачи глубже, решений ждут быстрее. И всё это - при тех же 8 часах. Но в целом особо ничего не изменилось за последние 3 года в плане типов вопросов, которые я решаю. Я работаю стабильно примерно с 35-50 человеками и 4-5 командами через их тимлидов в продуктовом контуре
В целом меня как будто ветром относит всё дальше от команд - и всё ближе к вопросам «а почему у нас так, меня не устраивает?». Всё больше занимаюсь оргдизайном, кросс-командной синхронизацией и прочими важными вопросами вида “без них компания не масштабируется". Плавный переход от микроменеджмента к макроболи. Собственно в чем проблема - в последний год я стал намного сильнее уставать, что иногда после работы просто лежу и читаю ранобэ или игрую в лигу легенд ради монотонной деятельности и быстрого дофамина
Если есть советы — с удовольствием послушаю. Если не хватает какого-то контекста
P.S. Спорт в жизни есть, периодический хайкинг, перерывы на гантели/скакалку каждый час и даже 10 тыс. шагов (гуляю по округе и фотографирую котов)
P.P.S. Периодически ощущаю себя как этот встреченный мной свежепомытый кот на ободранном диване
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Был запрос на личное - рассказываю персональный кейс
В основном я работаю ровно столько, сколько указано в контракте. Без лукавства и без фанатизма - восемь часов в день, мне все таки уже не 20 и есть в жизни вещи кроме работы. За исключением, конечно, редких ситуаций, когда "всё совсем горит ***ть" или когда лично обещал что-то C-lvl
Но вот что интересно: в эти восемь часов с течением времени стало влезать всё больше тяжёлых задач и они едят больше энергии. Раньше было условно так: 3 встречи , 3-4 задачки по часу и операционка на часик + по мелочи. А теперь: плотная подготовка к встречам, куча синхронизаций с кем-то, продолжительные задачи на изменения процессов или подготовку новых релизов. Хронометраж плотнее, задачи глубже, решений ждут быстрее. И всё это - при тех же 8 часах. Но в целом особо ничего не изменилось за последние 3 года в плане типов вопросов, которые я решаю. Я работаю стабильно примерно с 35-50 человеками и 4-5 командами через их тимлидов в продуктовом контуре
В целом меня как будто ветром относит всё дальше от команд - и всё ближе к вопросам «а почему у нас так, меня не устраивает?». Всё больше занимаюсь оргдизайном, кросс-командной синхронизацией и прочими важными вопросами вида “без них компания не масштабируется". Плавный переход от микроменеджмента к макроболи. Собственно в чем проблема - в последний год я стал намного сильнее уставать, что иногда после работы просто лежу и читаю ранобэ или игрую в лигу легенд ради монотонной деятельности и быстрого дофамина
Если есть советы — с удовольствием послушаю. Если не хватает какого-то контекста
P.S. Спорт в жизни есть, периодический хайкинг, перерывы на гантели/скакалку каждый час и даже 10 тыс. шагов (гуляю по округе и фотографирую котов)
P.P.S. Периодически ощущаю себя как этот встреченный мной свежепомытый кот на ободранном диване
👍16🕊7
#иное
Хрестоматийные статьи
Здравствуй, дорогой читатель!
Я решил добавить разнообразия, поэтому перед тобой один из немногих постов, которого не касался манипулятором AI, даже орфографию не правил, по живому. У меня для тебя немного полезного стороннего моего контента
1. В соавторстве с Kaiten я как-то написал статью https://habr.com/ru/companies/kaiten/articles/901236/, навеянную мыслями после после легкого полыхания на тему Agile https://t.me/junior_pm/315
Статья на мой вкус вышла недостаточно кусачей, но зато вполне себе расставляет по полочкам типичные когнитивные искажения на тему Agile. Их кстати очень много. Например, попробуй про себя ответить, ради чего обычно внедряют agile->scrum->scrumban?
Если твой ответ ради скорости и уменьшения time-to-market или более быстрой поставки, то настоятельно советую ее почитать. Также небольшой спойлер - если у вас batch-релизы, монолит, отсутствие фича флагов разных типов и роллбэк планов, то agile также не построить, не на чем
2. Я долго высиживал идею и наконец она созрела - курс по прикладному Gen AI для менеджеров . В рамках тестирования гипотез мы с командой энтузиастов (есть даже один товарищ из Microsoft!) запускаем предзапись на курс. Вся промокомпания одновременно является демонстрацией возможности Gen AI в правильно расположенных на теле руках и с небольшой долей погружения в тему
Вся промокомпания, которую мы будем вести в горизонте месяца будет создана совершенно без участия человека. Статья, картинки, сайт, будущие посты, рилсы, треды и тд будут созданы автоматизированными средствами. На мой взгляд это одна из самых наглядных презентаций
Например, эта статья https://habr.com/ru/articles/912776/ один из примеров такого промо к курсу. Однако все же это не**но-loop из галлюцинаций AI и gpt-generated
P.S. Поэтому прошу прощения за щитпостинг, его будет скоро много и на благое дело
Хрестоматийные статьи
Здравствуй, дорогой читатель!
Я решил добавить разнообразия, поэтому перед тобой один из немногих постов, которого не касался манипулятором AI, даже орфографию не правил, по живому. У меня для тебя немного полезного стороннего моего контента
1. В соавторстве с Kaiten я как-то написал статью https://habr.com/ru/companies/kaiten/articles/901236/, навеянную мыслями после после легкого полыхания на тему Agile https://t.me/junior_pm/315
Статья на мой вкус вышла недостаточно кусачей, но зато вполне себе расставляет по полочкам типичные когнитивные искажения на тему Agile. Их кстати очень много. Например, попробуй про себя ответить, ради чего обычно внедряют agile->scrum->scrumban?
Если твой ответ ради скорости и уменьшения time-to-market или более быстрой поставки, то настоятельно советую ее почитать. Также небольшой спойлер - если у вас batch-релизы, монолит, отсутствие фича флагов разных типов и роллбэк планов, то agile также не построить, не на чем
2. Я долго высиживал идею и наконец она созрела - курс по прикладному Gen AI для менеджеров . В рамках тестирования гипотез мы с командой энтузиастов (есть даже один товарищ из Microsoft!) запускаем предзапись на курс. Вся промокомпания одновременно является демонстрацией возможности Gen AI в правильно расположенных на теле руках и с небольшой долей погружения в тему
Вся промокомпания, которую мы будем вести в горизонте месяца будет создана совершенно без участия человека. Статья, картинки, сайт, будущие посты, рилсы, треды и тд будут созданы автоматизированными средствами. На мой взгляд это одна из самых наглядных презентаций
Например, эта статья https://habr.com/ru/articles/912776/ один из примеров такого промо к курсу. Однако все же это не**но-loop из галлюцинаций AI и gpt-generated
Статья пропитана одно из моих основных тревог последних 2 лет - насколько я заменяем и куда мне расти дальше. Например, свое время я выбрал прямой свитч из проектных менеджеров в agile coach и как оказалось это был не самый лучший выбор
P.S. Поэтому прошу прощения за щитпостинг, его будет скоро много и на благое дело
👍7🔥2😁2👎1
#мнение
AI-сервисы сливают ваши корпоративные данные
Думаете, ChatGPT и другие AI-ассистенты - это просто безобидные игрушки, которые экономят время и нервы менеджеров?
Как менеджер с техническим бэкграундом и многолетним опытом работы с командами в разных отраслях, я всё чаще сталкиваюсь с пугающим трендом: сотрудники щедро "сливают" конфиденциальные данные через публичные AI-сервисы
Недавно один коллега рассказал, как разработчик "случайно" закинул в публичный чат-бот большой кусок продакшен-кода, пытаясь быстро получить решение проблемы. И таких случаев всё больше. Что чувствую я в такие моменты? До недавнего времени смесь беспокойства и удивления, что люди до сих пор думают, будто общение с нейросетями - это приватная исповедь. Ну или немного стыда, ведь я тоже иногда грешу подобными "экспериментами"
Однако глубже познакомившись с темой и когда меня закидали помидорами в одном из моих пред. постов, оказалось что все не так плохо. Прикладываю отличную инфографику
Есть ли у вас регламенты, которые запрещают сотрудникам использовать публичные AI-сервисы для рабочих задач?
AI-сервисы сливают ваши корпоративные данные
Думаете, ChatGPT и другие AI-ассистенты - это просто безобидные игрушки, которые экономят время и нервы менеджеров?
Как менеджер с техническим бэкграундом и многолетним опытом работы с командами в разных отраслях, я всё чаще сталкиваюсь с пугающим трендом: сотрудники щедро "сливают" конфиденциальные данные через публичные AI-сервисы
Недавно один коллега рассказал, как разработчик "случайно" закинул в публичный чат-бот большой кусок продакшен-кода, пытаясь быстро получить решение проблемы. И таких случаев всё больше. Что чувствую я в такие моменты? До недавнего времени смесь беспокойства и удивления, что люди до сих пор думают, будто общение с нейросетями - это приватная исповедь. Ну или немного стыда, ведь я тоже иногда грешу подобными "экспериментами"
Однако глубже познакомившись с темой и когда меня закидали помидорами в одном из моих пред. постов, оказалось что все не так плохо. Прикладываю отличную инфографику
Есть ли у вас регламенты, которые запрещают сотрудникам использовать публичные AI-сервисы для рабочих задач?
🤡9👍2👎1🌚1
#мнение
Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект!
Заметил что многие Agile визионеры активно перетекают в сторону AI-консалтинга? Или на твой взгляд это скорее те кто чувствуют куда дует ветер, отлаживают паруса?
Я тоже активно пишу про AI и проверяю гипотезу курса, но конечно так глубоко как Владимир https://t.me/turboproject
P.S. Кстати спойлер - в июле августе множество крупнейших площадок для курсов будут запускать свои курсы, от крайне узких про оркестрацию агентов и цепочки трассировки и до очень общих про COSTAR
P.P.S Мини пост-выходного дня и не реклама это!
Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект!
Заметил что многие Agile визионеры активно перетекают в сторону AI-консалтинга? Или на твой взгляд это скорее те кто чувствуют куда дует ветер, отлаживают паруса?
Я тоже активно пишу про AI и проверяю гипотезу курса, но конечно так глубоко как Владимир https://t.me/turboproject
P.S. Кстати спойлер - в июле августе множество крупнейших площадок для курсов будут запускать свои курсы, от крайне узких про оркестрацию агентов и цепочки трассировки и до очень общих про COSTAR
P.P.S Мини пост-выходного дня и не реклама это!
🎉4
#рецепт
Не нужно верить что планы работают
Здравствуй, хронофобный коллега! Если твоя команда хоть раз зависела от сроков другой команды, то ты точно поймёшь меня. Есть такие команды - вроде бы образцовые, их ставят всем в пример, скрам у них по гайду
Но почему-то каждый раз, когда ждёшь от них задачу, дедлайн улетает куда-то запредельно. Или сам иногда смотришь на свой процесс и ловишь себя на мысли: “А что у нас вообще не так?”
Вот очень краткий чеклист - если все пункты выполняются, твое планирование действительно работает и планы управляемы. Если что-то выпадает - высоковероятно, что планы у тебя для галочки или процесс просто ещё не устоялся (что нормально для новых команд):
1. Есть проверка результативности планов по группе задач (по проекту, итерации, спринту) - видно, где накапливается ошибка и насколько план соответствует факту
2. Есть проверка попадания в оценки по отдельным задачам - оценили в 2 часа, заняло 4
3. Пересматриваются оценки, если появляется новая информация или меняются вводные
Продолжение в комментариях!
Если хотя бы один пункт мимо - твоя система скорее создает иллюзию управления, чем реально управляет процессом
P.S. Личный опыт показывает: когда этот список работает на практике, у команды и у менеджера сразу появляется больше времени на интересные задачи, а не бесконечную координацию
Не нужно верить что планы работают
Здравствуй, хронофобный коллега! Если твоя команда хоть раз зависела от сроков другой команды, то ты точно поймёшь меня. Есть такие команды - вроде бы образцовые, их ставят всем в пример, скрам у них по гайду
Но почему-то каждый раз, когда ждёшь от них задачу, дедлайн улетает куда-то запредельно. Или сам иногда смотришь на свой процесс и ловишь себя на мысли: “А что у нас вообще не так?”
Вот очень краткий чеклист - если все пункты выполняются, твое планирование действительно работает и планы управляемы. Если что-то выпадает - высоковероятно, что планы у тебя для галочки или процесс просто ещё не устоялся (что нормально для новых команд):
1. Есть проверка результативности планов по группе задач (по проекту, итерации, спринту) - видно, где накапливается ошибка и насколько план соответствует факту
2. Есть проверка попадания в оценки по отдельным задачам - оценили в 2 часа, заняло 4
3. Пересматриваются оценки, если появляется новая информация или меняются вводные
Продолжение в комментариях!
Если хотя бы один пункт мимо - твоя система скорее создает иллюзию управления, чем реально управляет процессом
P.S. Личный опыт показывает: когда этот список работает на практике, у команды и у менеджера сразу появляется больше времени на интересные задачи, а не бесконечную координацию
👍17🤡1