Junior AI PM

#рецепт
Формула конфликта

Здравствуй, наблюдательный читатель!

Давай сегодня разберём одну занятную теорию, которую утащил с курса от Стратоплана.

Формулу конфликта: КНС = К – КС – (КФГ). На словах все прозаично: если вычесть из любого конфликта (К) саму конфликтную ситуацию (КС) и весь этот эмоциональный груз” (КФГ) - останется КНС, то есть конструктив. КНС - это и есть тот полезный остаток, который позволяет выйти из любого спора сильнее чем прежде и без перегара

Что сюда входит?
КС - это условия, в которых вообще возможен конфликт. Например, неясные роли, мутные процессы, давление сроков, перегретые задачи.
КФГ - это наши триггеры, все “подколки”, пассивная агрессия, колкости в стиле “ты ничего не понимаешь”, язвительные комментарии, иногда даже просто усталость, с которой срываешься на людей

Вот ты вычитаешь из конфликта ситуации и конфликтогены, и если что-то остаётся, это и есть КНС. Проще говоря, если убрать весь мусор, остаётся шанс на честный разговор на пальцах и понимание друг друга

Позитивное намерение - еще одна полезная концепция

Звучит чуть мудрено, а на деле - это то, ради чего мы вообще вступаем в спор. И это почти всегда что-то хорошее, просто часто скрытое даже от самих себя.
Например:
- Агрессия? На самом деле человек хочет защитить себя или восстановить справедливость;
- Робость? Хочет быть замеченным;
- Сопротивление изменениям? Боится облажаться и хочет сохранить уверенность;
- Ложь? Иногда - просто избежать разрушения отношений.

У меня бывает, что спорю до хрипоты, а на самом деле просто боюсь, что проект завалится и мне потом разбирать завалы

Смысл здесь - научиться видеть, какое позитивное намерение скрыто за поведением человека. Даже если она кажется стремным. И озвучить это (хотя бы для себя), чтобы не упереться в эмоции

Последовательность решения через 3 К

1) Контакт - спокойно признаём, что есть проблема, и зовём её обсудить (“Коллеги, у нас периодически переносятся релизы, что влияет на наши совместные цели - давайте поймём, почему и чем мы вам можем помочь”)

2) Коммуникация - выясняем, как видит ситуацию оппонент, чего он реально хочет (часто тут проявляется как раз то самое позитивное намерение). Проговариваем и своё (“Я вижу, что у команды перегруз, и мне важно, чтобы мы не выгорели”)

3) Консилиация - договариваемся, кто готов на какие изменения, и фиксируем это. Можно устно, можно даже письменно. А еще радуемся что не перес**лись

Если обе стороны честно участвуют, появляется шанс выйти на конструктив, а не скатиться в позиционку

Конечно есть но.
Был у меня случай с C-level в крупной телеком-компании. Все условия для конфликта (КС) - на месте: сложные процессы, закрытые правила, куча скрытых ожиданий. Конфликтогены (КФГ) - регулярно: “вы тут гости”, “у нас свои порядки”, колкости через раз. И вроде бы я держался за конструктив, вытаскивал на контакт, озвучивал позитивные намерения (“Я правда хочу, чтобы процессы были прозрачнее для всех - не для галочки, мы строим квартальное планирование чтобы повышать предсказуемость”). Но человек не хотел даже обсуждать, если ты не из его круга, а любые мои предложения - только злили. Итог - никакой КНС, только выгорание. Формула работает, если обе стороны хотя бы формально хотят договариваться и строить партнерские отношения, а если нет - хоть разбирай конфликт на атомы, конструктив не вытащишь

P.S. Сам до сих пор учусь видеть за поведением не только конфликтогены, но и позитивные намерения, честно говоря, для меня это один из самых сложных навыков. Но точно стоящий

#рецепт
Отчет по Jira любой команды без выгрузок и геморроя через Claude. Ну почти

Здравствуй, ai-совместимый менеджер!

Про это не сказал уже только ленивый, что Atlassian подключил Claude к Jira через beta MCP сервер (в комментарии оставил ссылки почитать что это такое на всякий). Теперь отчёты и задачи создаются простым промптом. Так заявляется

Я вижу пока основную ценность исключительно в верхнеуровневом обзор состояния команды, например текущие приоритеты, зависшие задачи, состояние бэклога и перфоманс

В комментариях на форумах заметили очевидные нюансы:

1. Claude иногда неточно интерпретирует промпты, нужны максимально конкретные запросы. С промтами в MCP всегда была беда

2. Не всегда подходит для сложных и очень многошаговых задач

Подробности и обсуждение:
https://community.atlassian.com/forums/Atlassian-Platform-articles/Using-the-Atlassian-Remote-MCP-Server-beta/ba-p/3005104
https://www.atlassian.com/platform/remote-mcp-server

P.S. У меня оно не завелось вообще, так как много проектов team managed в jira и оно просто отказывается с ними работать. Если кто еще попробовал, поделитесь, как оно. Я привык уже на коленке собирать скрипты на питоне и выгружать все что мне нужно по Rest

#рецепт
Этим документом стоить подтереться? Почему мы на самом деле соблюдаем NDA

Здравствуй, осторожный менеджер!

Сколько раз ты подписывал NDA и думал - а будет ли толк? На нашем рынке это скорее славная традиция, чем реальной обоснованный инструмент

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

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

Почему NDA в России и СНГ обычно бессилен? Ну чтобы он заработал, компания должна оформить режим коммерческой тайны, маркировать документы, прописывать доступы и ознакамливать тебя с порядками. Без этого - в суде NDA ничего не значит. Тут неплохо расписано . Привлечь к ответственности без всех этих процедур почти невозможно - подтверждаю из личного опыта, пытались разок в РК близкого человека

Любимый пункт в NDA - молчать о зарплате. Но ТК РФ (ст. 136 ) гарантирует только право знать свои условия оплаты, а не молчать о них. Еще и противоречит императивам о защите прав работников. Запрет обсуждать зарплату - это юридический курьёз , хороший разбор тут и доказать что разглашением зарплаты был нанесен ущерб не получится

В общем если у компании не подготовлен контур для зашиты информации (а он обычно не подготовлен) ваш NDA не стоит бумаги, на которой напечатан. В РФ и РК такие страшилки работают только для красоты. Хотя в компаниях даже если в суде не доказано, все равно по своему включается. Так за мной какое-то время следили братки на прошлом месте, но это не про юриспруденцию ни разу

Кстати вот анализ за 3 года некоторых дел, которые связаны с NDA, занимательное чтиво

Из личного, у меня три NDA с прошлого места - РФ, РК, кипрское. Первые два просто формальность. А вот по кипрскому - любой косяк и 2k евро штрафа, всё серьёзно, договор имеет юр. силу, я специально проверял.

P.S. NDA - это про культуру и отношения. Соблюдать стоит, чтобы не быть белой вороной, но иллюзий питать не надо. И перед HR лучше не шутить, что NDA - просто для галочки

#perl
Помни про важность своевременного отдыха

Я как обычно перегружен и не успеваю ничего написать по делу поэтому до конца недели буду отбиваться мемами

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

Шутки про швеца-жнеца-на дуде игреца меня не смешат, я был: промоутером, хостесом, официантом, поваром, администратором кафе, грузчиком, садовником, лесничим, лаборантом в КЛД, сапортом, в коллцентр, продажником, аккаунтом, андроид разработчиком и остановился как ПМ

P.S. Пробелов в резюме у меня нет

#perl

https://ifuckinghatejira.com/

P.S. Утащил от @mseleznev

#рецепт
Не нужно верить что планы работают

Здравствуй, хронофобный коллега! Если твоя команда хоть раз зависела от сроков другой команды, то ты точно поймёшь меня. Есть такие команды - вроде бы образцовые, их ставят всем в пример, скрам у них по гайду

Но почему-то каждый раз, когда ждёшь от них задачу, дедлайн улетает куда-то запредельно. Или сам иногда смотришь на свой процесс и ловишь себя на мысли: “А что у нас вообще не так?”

Вот очень краткий чеклист - если все пункты выполняются, твое планирование действительно работает и планы управляемы. Если что-то выпадает - высоковероятно, что планы у тебя для галочки или процесс просто ещё не устоялся (что нормально для новых команд):

1. Есть проверка результативности планов по группе задач (по проекту, итерации, спринту) - видно, где накапливается ошибка и насколько план соответствует факту

2. Есть проверка попадания в оценки по отдельным задачам - оценили в 2 часа, заняло 4

3. Пересматриваются оценки, если появляется новая информация или меняются вводные

Продолжение в комментариях!

Если хотя бы один пункт мимо - твоя система скорее создает иллюзию управления, чем реально управляет процессом

P.S. Личный опыт показывает: когда этот список работает на практике, у команды и у менеджера сразу появляется больше времени на интересные задачи, а не бесконечную координацию

#мнение
Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект!

Заметил что многие Agile визионеры активно перетекают в сторону AI-консалтинга? Или на твой взгляд это скорее те кто чувствуют куда дует ветер, отлаживают паруса?

Я тоже активно пишу про AI и проверяю гипотезу курса, но конечно так глубоко как Владимир https://t.me/turboproject

P.S. Кстати спойлер - в июле августе множество крупнейших площадок для курсов будут запускать свои курсы, от крайне узких про оркестрацию агентов и цепочки трассировки и до очень общих про COSTAR

P.P.S Мини пост-выходного дня и не реклама это!

#мнение
AI-сервисы сливают ваши корпоративные данные

Думаете, ChatGPT и другие AI-ассистенты - это просто безобидные игрушки, которые экономят время и нервы менеджеров?

Как менеджер с техническим бэкграундом и многолетним опытом работы с командами в разных отраслях, я всё чаще сталкиваюсь с пугающим трендом: сотрудники щедро "сливают" конфиденциальные данные через публичные AI-сервисы

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

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

Есть ли у вас регламенты, которые запрещают сотрудникам использовать публичные AI-сервисы для рабочих задач?

#иное
Хрестоматийные статьи

Здравствуй, дорогой читатель!

Я решил добавить разнообразия, поэтому перед тобой один из немногих постов, которого не касался манипулятором 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. Поэтому прошу прощения за щитпостинг, его будет скоро много и на благое дело

#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу

Был запрос на личное - рассказываю персональный кейс

В основном я работаю ровно столько, сколько указано в контракте. Без лукавства и без фанатизма - восемь часов в день, мне все таки уже не 20 и есть в жизни вещи кроме работы. За исключением, конечно, редких ситуаций, когда "всё совсем горит ***ть" или когда лично обещал что-то C-lvl

Но вот что интересно: в эти восемь часов с течением времени стало влезать всё больше тяжёлых задач и они едят больше энергии. Раньше было условно так: 3 встречи , 3-4 задачки по часу и операционка на часик + по мелочи. А теперь: плотная подготовка к встречам, куча синхронизаций с кем-то, продолжительные задачи на изменения процессов или подготовку новых релизов. Хронометраж плотнее, задачи глубже, решений ждут быстрее. И всё это - при тех же 8 часах. Но в целом особо ничего не изменилось за последние 3 года в плане типов вопросов, которые я решаю. Я работаю стабильно примерно с 35-50 человеками и 4-5 командами через их тимлидов в продуктовом контуре

В целом меня как будто ветром относит всё дальше от команд - и всё ближе к вопросам «а почему у нас так, меня не устраивает?». Всё больше занимаюсь оргдизайном, кросс-командной синхронизацией и прочими важными вопросами вида “без них компания не масштабируется". Плавный переход от микроменеджмента к макроболи. Собственно в чем проблема - в последний год я стал намного сильнее уставать, что иногда после работы просто лежу и читаю ранобэ или игрую в лигу легенд ради монотонной деятельности и быстрого дофамина

Если есть советы — с удовольствием послушаю. Если не хватает какого-то контекста

P.S. Спорт в жизни есть, периодический хайкинг, перерывы на гантели/скакалку каждый час и даже 10 тыс. шагов (гуляю по округе и фотографирую котов)

P.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. А какие у тебя критерии настоящего руководителя и что думаешь про мои методы?

#артефакты
Тренажёр постановки задач на коленке

Здравствуй, подкованный читатель

Я встал в легкий ступор, особенно после последней обратной связи на посты. Мне нравится давать контент, который можно утащить и переиспользовать, а не просто прочитать слегка задуматься. И тут я застрял, а чего бы такого написать из того что мне нравится, ибо давать шаблон условной матрицы требований, если условный 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. Жду твоих идей и новых сценариев для тренажёра!

#рецепт
Как правильно работать с капасити и велосити

Здравствуй неутомимый читатель! Я услышал твою обратную связь и пришел с более практическим, менее AI-вылизанным и менее частым контентом

Если ты хочешь, чтобы твоя команда прослыла действительно хай-перфоманс и наблюдаемой, то лови подборку приёмов, которые действительно забустят твой скрам-но:

- Начни с простого: объяви команде, что капасити и велосити — это один и тот же «спидометр»

- Велосити считай по трём самым удачным спринтам, когда «звёзды легли». Если вдруг текущий результат ниже 50 %, смело говори: «Метрика сомнительная и плавающая, не обращайте внимания”

- Длина итераций — тема для творчества. На этой итерациии сделай спринт на 10 дней, в следующей — на 15. Аргументируй “под гибкость рынка” и “неотменимостью запросов продактов”

- Спишишь? Перезапусти спринт на середине. Всё, что недоделано, выкинь из истории: «Мы же итерируемся, ребята!». Исторические данные как бы ничего не говорят

- На планировании подмигни команде и скажи: «Учёные доказали: story points чудесно складываются — 2 + 5 = 7, главное верить». Сошлись на центральную предельную теорему — большинство перестанет задавать вопросы после слов «агрегация» и «мода»

- Капасити? Планируй под единственный возможный сценарий: «никто не болеет, отпусков нет, встреч нет. инцидентов нет». Аргумент: «Scrum‑гайд про февральские простуды молчит, значит их не бывает»

P.S. Вторая порция в комментариях. Следуй этим приёмам регулярно и ваш скрам точно будет достоин рассказа на конференции
P.P.S. Чего на твой взгляд еще не хватает в списке?

В последнее время очень сильно упало число просмотров, реакций и в целом вовлеченность. Что то поменялось в контенте, формате и вам стало менее интересно? Или я что-то упускаю?

#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу

Ты проджект менеджер в компании Целестиал и вызрабатываете аналог Scopify, движок для интернет-магазинов. У вас в компании ПМ являются частью продуктового офиса, подчинаются CPO и больше работают в формате сервис деливери менеджеров.

В рамках работы ты присматриваешь за двумя фича-командами в яркой манерой, Паладины (обожают вов) и Десантинками (фаны вахи). Обе питаются входящими задачами от единой команды системных аналитиков, которой передают требования стейкхолдеры, часто напрямую продакты. Часть аналитиков пишет лаконичные требования в формате бизнес концепций и критериев приемки, а другая считает, что надо рисовать UML-диаграммы и расписывать юзкейсы, их постановки соответствующие

Недавно пошла в работу большая фича — интеграция платформы с adoCRM, чтобы заказы и лиды обрабатывались автоматически. И тут началось неожиданное: Паладины уверяют, что аналитики накидали слишком сырые требования и не заложили нюансов. Десантники, наоборот, пеняют на горы схем, которые оказались неполными: «они в отрыве от цели фичи и здравого смысла». Ты пытаешься погасить этот пожар, созваниваясь с каждой стороной, но каждый интеграционный дейли превращается в перепалку: одни говорят, что слишком много документации убивает скорость, другие уверяют, что невнимание к структуре «превратит код в спаггети»

Продуктовый офис уже замечает, что сроки горят, а интеграция всё ещё не работает — клиенты пилят свои коннекторы и недовольны этим. Ты собрал фактуру, факторы конфлитной среды и мотивы, замечательно задизайнил встречу, но твоя выдающая фасилитация ни к чему не привела, разговор превратился в очередной спор, кто виноват, что фича буксует. Десантники продолжают обвинять аналитиков в излишнем формализме, а Паладины убеждена, что коллеги просто игнорируют нужные описания. Сверху тебя просят «привести людей в чувство» и как-то ускорить релиз, но при этом не скатиться в микроменеджмент, ибо не просто также была аджайл трансформация

Какую сторону ты займешь? Как выйдешь из этой ситуации?

#рецепт
Секретное оружие: ресурсное планирование

Здравствуй, дорогой читатель. Ты не поверишь, но многие начинающие менеджеры в последнее время совсем забывают про важнющую штуку — ресурсное планирование. Главное помни правило клуба - НИКОГДА НЕ НАЗЫВАЙ РЕСУРС РЕСУРСОМ ПРИ РЕСУРСЕ (профессионализмы могут быть странными и непогруженных могут обидеть)

Классическая логика планирования

В водопадном подходе план идёт от требований к расписанию. Подробнее смотри у Селиховкина:
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 А у тебя на работе есть ресурсное планирование? Поделись, как оно организовано!

#мнение
Вайбкодинг выходного дня

Здравствуй, околоайтишный читатель! Сегодня я хочу поделиться своим обзором сервиса от 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. Помни, иногда скорость и оперативность важнее идеальной отлаженности каждого механизма