Автор много знает про управление ресурсами и встречал разных руководителей: и тех, которым надо вчера, и тех, кому вообще надо мухой. И даже тех, кто выслушивал сроки от РП и соглашался на них - такие тоже бывают.
Автор умеет планировать работы с реальной утилизацией 80% при сохранении текучки на уровне 10% и удовлетворенности команды на уровне 4.8 из 5. Если вы когда то управляли ресурсами, вы понимаете, о чем я.
И все мои тексты как раз посвящены обучению джунов, которых, по некоторым оценкам, до 45% на рынке ИТ сейчас.
Это лирика. По факту: "у меня нет ресурсов" не решает проблемы и не показывает желания менеджера что-то сделать с проблемой шефа. Дословно это считывается как "мне пофиг на твои проблемы, моя хата с краю". Это - непрофессиональный и некомандный подход. Если считаете шефа кретином - валите, если все шефы кретины - можно почитать мою статью "Что делать, если вас окружают кретины". Если ни то, ни то - лучше помогать решить ему проблему. И это любая другая фраза кроме той самой.
"Почему это критично?"
"Что мы можем подвинуть?"
"Когда реально это нужно и кто умрет?" - это десятки вариантов кроме вот этого, никому не помогающего "у меня нет ресурсов". Хорошо, а идеи у вас есть, хочется спросить?
Хуже: каждый раз, когда менеджер приходил ко мне с этой фразой, окей, не каждый, но в 60% случаев я лез в детали, и ресурсы находились.
Натура человека такая, что хочется решать проблему самым простым путем экстенсивного роста. Мозг включать некоторые не хотят вообще. Это касается и исполнителей - если их не пинать, добавляение кнопки - это 2 дня, если пнуть - 2 часа. Это касается менеджеров.
Так и хочется спросить некоторых менеджеров: Нет ресурсов? А если найду?
Спасибо, люблю Хабр именно за то, что тут умеют не соглашаться с выводами, и есть о чем поговорить. Так давайте поговорим, если у вас реально есть опыт внедрений.
Суть статьи не в том, что менеджер не должен держать проектный треугольник. Как раз должен. Суть в том, что сама по себе такая фраза не помогает клиенту решить его проблему. И да, именно РП находится на переднем крае отношений с клиентами, пусть где то выше договорились о чем то (что, кстати бывает далеко не всегда, автору есть что рассказать про тендеры и их непредсказуемость). Фраза "Этого нет в ТЗ" должна произносить просто иначе.
Возможно в военке можно и иначе, в военке не работал. Но это как раз узкий сегмент, который отдельно выделять не стоит.
Кстати, тут еще для начала стоит определить что такое для вас - успешный проект? Это тоже очень тонкая материя, которая почти никогда не завязана чисто на срок/бюджет.
Что до моего опыта - он в профиле, вы можете поглядеть. про вас тоже интересно узать: не чтобы пипками меряться, но чтобы понимать уровень ваших проектов и сколько их было
в быдло стиле на "этого нет в ТЗ" обычно отвечают (и такое я тоже встречал): "потому что твои аналитики криворукие дебилы и написали говно, я за это платить не собираюсь и мне вообще плевать как ты это решишь" А дальше это летит шефу, для которого данный клиент важный и любимый.
И конечно можно уволиться, но можно и договориться, просто не надо лезть на рожон в слабой позиции.
Оттенки очень важны. Наверное корень в том же самом, что и по всем остальным фразам: запрещенная фраза просто констатирует факт, и менеджер не предлагает решения проблемы заказчика.
Заказчику это, как правило, не нравится.
Ну и отдельно именно "Этого нет в ТЗ" моментально и всегда (всегда) приводит к выяснению точно что там есть и нет и попыткам найти его недостатки. И почти всегда они там есть.
А инструменты, да, такие:
брать мелочевку и делать не просто молча типа "ну ок", нет, каждый раз подчеркивая, как мы идем на встречу выполняя допработу. Ночами не спим. Три раза придет, на четвертый уже можно эскалировать шефу: мы им идем на встречу, давайте прекратим - бюджет нерезиновый. Это вообще иная позиция.
не делать вообще, сперва задаваясь вопросом: "а кому это вообще надо и для чего?" Очень часто многие CR умирают именно в этом месте
не делать вообще, задавая вопросы по технике, на которые бизнес ответить просто не в силах. И тогда реализация переезжает в следующую фазу автоматом: у нас же сроки, мы не можем сдать.
не факт. в простых случаях прокатит. в сложных - вы будете втянуты в спор с заказчиком на тему, кто дурак: толи ваши аналитики, которые продолбали требования, толи бизнес. И по опыту, послушают скорее бизнес, только если у вас не будет железобетонной базы в виде протоколов именно в нужных формулировках.
Что бывает, но нечасто, потому что если вы практикующий РП вы знаете, что все зафиксировать невозможно, а если вы попробуете - этого читать никто не будет.
Поэтому фраза "Этого нет в ТЗ, но мы добавим за деньги" - тоже не очень приближает вас к результату.
Есть много других фраз вообще вбок, которые реально помогают.
самая простая: а что это и зачем нужно? Почему это критично, как вы считаете? а почему на этапе сбора требований это мы не обсудили (уже веет, но аккуратно).
Отдельно - есть способ взять в объем небольшую доработку, пойдя заказчику на встречу. и еще есть, но не могу же я переписать всю статью заново в камент. Тем более что после нее я еще 2 дописал в тележке.
угу. Если у вас такое ТЗ, что заказчик и правда за все заплатил, и вы сами лично его согласовали - придется сделать. Это раз.
Если серая зона - это отличный повод для договоренностей. Про это я пишу на канале, есть несколько стратегий. Если вам реально интересно, и в не просто тролите, могу дать пару ссылок на канал, маякните.
Если коротко 1: для неопределенности должен быть небольшой буфер (или большой, зависит от рисков), если нет ни буфера, ни требований а вы согласились - вопрос к вам - нафига?
Если коротко 2: часто можно договориться на небольшие и реально критичные доработки, а по остальным вступить в дискуссию "а зачем это нужно, давайте обсудим". Как правило, только если проект не провален в части аналитики, реально критичного упускается мало.
Ну, и отвечая именно на ваш кейс:
Я тимлид, у меня фикспрайс проект с заранее составленным и оцененным ТЗ. В середине пути заказчик решает для себя, что у нас тут аджайл, и начинает просить бесконечных правок и отступлений от изначального ТЗ. Вопрос - если фраза "Этого нет в ТЗ" и все ее производные запрещены, то как следует себя вести по мнению автора в данной ситуации
Заказчик , как правило, не решает аджайл или нет. Ему вообще плевать на методологию. Ему надо добавить требования в объем которые по какой то причине были пропущены.
Или ИТ команда профакапила анализ (что бывает), или бизнес пропустил (бывает также). А дальше у меня вопрос: насколько этап 1 встанет без этих доработок? Что на них завязано и какая цена вопроса? Если критично и недорого - можно и пойти на встречу. Если некритично - можно сделать потом (тем более, что сейчас уже работы идут и их изменние приведет к изменению сроков). А может быть надо собраться, все систематизировать и сделать Этап 2 проекта.
Итак: я предложил несколько вариантов решения на ваш кейс и ни разу не ответил "Этого нет в ТЗ".
А вы даете ваше личное оценочное мнение, не прочитав даже статьи, и уж тем более - остальных статей автора. Иначе данный комментарий бы не появился вообще.
Ваша логика нормально работает для исполнителя по задаче. От РП требуется смотреть несколько дальше, чем 1 задача или 1 проект. Есть классический вопрос на собеседовании РП "что такое успешный проект?"
Так вот успешный - это не только сделанный в срок и бюджет. Если проект сделан хорошо, но отношения испорчены, это почти всегда неуспешный проект.
Ну и конечно же я не призываю нигде молча соглашаться со всем, что менеджеру предлагают, я пишу о другом. Есть 100 и 1 способ говорить иначе. Это просто навык переговоров и умение отстаивать личные и профессиональные границы, не теряя способности договариваться.
да ладно вам. отстойная пассивно-агрессивная фраза. https://t.me/morkovka_speredi_morkovka_szadi/271 вот тут в каменты загляните (не реклама, просто там хорошо обсудили), если хотите. Тут уже не буду писать, извините, не успеваю :)
Понял вас. С позиции разработчика, который вынужден брать на себя работу непрофессиональных менеджеров, которые неспособны ограничить объем и защитить команду от треша, вы 100% правы.
Задача менеджера (тоже много писал про это) видится мне в том, что для клиента он должен быть удовлетворителем потребностей, но не за счет команды и не за счет своей компании, в целом. Это непросто и это как раз показатель профессионализма, софтскиллов и всего о чем я пишу. Но чтобы разом ответить на все, нужна книжка (может и издам по мотивам статей потом). А тут просто статья, чего говорить им нельзя.
Потому что менеджер - штука нежная: ему говоришь "не ложись под заказчика" и он начинает всех слать, а потом проектов нет. Говоришь ему "будь добрее" - он подписывается вообще подо всем. Вот и приходится учить балансу :)
Для команды менеджер должен быть требовательным помощником. Тогда отлично работает связка: он прикрывает пацанов, а пацаны - его. Я так работал, и по моему, это самый лучший формат.
Про регламенты тоже писал, и там баланс знать надо. Есть менеджеры, которые даже в CV не стесняются написать, что они создали несколько сотен регламентов за год работы (!) Оно то конечно наверное круто и эффективно, только такое на практике никто не читает :) А так то согласен.
Его задача - чтобы проекты (все, а не только один конкретный) двигались, команда работала и сроки не срывались
Замечательно.
А если он делает проекты хорошо, но заказчик не доволен и не дает новых проектов? А если от него команда разбегается? А что если даже заказчик доволен, а недоволен шеф (который и есть главный заказчик менеджера, кстати)? Шефа послать нахрен?
Блин, факт, Я ВАС УСЛЫШАЛ забыл ( вот что значит, писать статьи по ночам. а в Телеге, кстати, мы мощно перетерли и ее (заходите в мой канал и вы, дада, ссылочки под роликом, как водится), и знаете что? 1/3 подписчиков воспринимает ее совершенно нормально. Я бы сказал, что она мерзкая, но сильно не вредит, так что в списке она лишняя. У меня только максимально вредительские.
Чтобы нам с вами поговорить про клиентоориентированность и чего она стоит, мне надо понять ваш опыт: если вы продаван и знаете другие способы win-win кроме как понимать потребности вашего клиента и удовлетворять их - поделитесь, пожалуйста. Про себя и свой опыт я в профиле написал много, у вас в профиле ничего нет. А с дивана критиковать можно, но смысл.
Протоколировать надо, да. Но не только это. Менеджер который только протоколирует - это тупой админ.
ну вам коллега все ответил уже, все так: я не помню - это просто фраза которая говорит "я ничего делать не буду". Это плохая позиция для менеджера. Да и для исполнителя тоже, если он отвечает по задаче. Да еще и показывает нежелание помогать.
А так как мы про менеджеров, то кому он так может ответить? Заказчику или шефу (тоже заказчику). Отлично, выходит, вы не хотите помогать тем, кто вам деньги платит?
А вы по ссылке прошли, статью прочитали? Потому что она дает ответ именно на этот вопрос. А на комментарии и вопросы я там подробнейше ответил в каментах. Если есть вопрос про ТЗ - пишите туда, я тоже отвечу :)
Что делать - ясно там, это классика качественного управления.
Да и у меня статья есть "как говорить НЕТ, когда все хотят слышать ДА". Она тут на сайте - там все ответы, исчерпывающе
нисколько не утрирую, у меня за 25 лет таких случаев - вагон и тележка: как в бигтехах, так и в небольших командах, как с внутренним, так и с внешним заказчиком :)
и те, кто эти фразы говорит именно так, как сказано в обеих статьях - практически всегда - неопытные и неумеющие решать проблему на своем уровне менеджеры.
Я и сам такой был. Потом научился иначе, да и свою команду тоже научил, что показало, что если хочется - все можно.
Кстати, вы же тоже наверняка не просто предлагаете по любому поводу эксалировать? Если РП может подумать, передвинуть некритичные задачи и поставить критичные вперед - он же вполне способен сделать это сам, без руководителя? Особенно если он заранее не завязан на платежи и что-то такое?
О, а расскажите, как это оформляется на внутренних проектах и продуктах, мне интересно?
окей
Я тут придерживаюсь четкой позиции: процессы всегда неидеальны, на них, при желании можно спихнуть все, что угодно, в том числе собственное нежелание включить голову у товарища менеджера. Так что для начала пусть попробует включить голову, подумать, попробует решить на своем уровне а потом - добро пожаловать эскалировать. Но не в формате "спасите", а в формате, про который писал раньше: четко и с вариантами решения.
Автор много знает про управление ресурсами и встречал разных руководителей: и тех, которым надо вчера, и тех, кому вообще надо мухой. И даже тех, кто выслушивал сроки от РП и соглашался на них - такие тоже бывают.
Автор умеет планировать работы с реальной утилизацией 80% при сохранении текучки на уровне 10% и удовлетворенности команды на уровне 4.8 из 5. Если вы когда то управляли ресурсами, вы понимаете, о чем я.
И все мои тексты как раз посвящены обучению джунов, которых, по некоторым оценкам, до 45% на рынке ИТ сейчас.
Это лирика. По факту: "у меня нет ресурсов" не решает проблемы и не показывает желания менеджера что-то сделать с проблемой шефа. Дословно это считывается как "мне пофиг на твои проблемы, моя хата с краю". Это - непрофессиональный и некомандный подход. Если считаете шефа кретином - валите, если все шефы кретины - можно почитать мою статью "Что делать, если вас окружают кретины". Если ни то, ни то - лучше помогать решить ему проблему. И это любая другая фраза кроме той самой.
"Почему это критично?"
"Что мы можем подвинуть?"
"Когда реально это нужно и кто умрет?" - это десятки вариантов кроме вот этого, никому не помогающего "у меня нет ресурсов". Хорошо, а идеи у вас есть, хочется спросить?
Хуже: каждый раз, когда менеджер приходил ко мне с этой фразой, окей, не каждый, но в 60% случаев я лез в детали, и ресурсы находились.
Натура человека такая, что хочется решать проблему самым простым путем экстенсивного роста. Мозг включать некоторые не хотят вообще. Это касается и исполнителей - если их не пинать, добавляение кнопки - это 2 дня, если пнуть - 2 часа. Это касается менеджеров.
Так и хочется спросить некоторых менеджеров: Нет ресурсов? А если найду?
Спасибо, люблю Хабр именно за то, что тут умеют не соглашаться с выводами, и есть о чем поговорить. Так давайте поговорим, если у вас реально есть опыт внедрений.
Суть статьи не в том, что менеджер не должен держать проектный треугольник. Как раз должен. Суть в том, что сама по себе такая фраза не помогает клиенту решить его проблему. И да, именно РП находится на переднем крае отношений с клиентами, пусть где то выше договорились о чем то (что, кстати бывает далеко не всегда, автору есть что рассказать про тендеры и их непредсказуемость). Фраза "Этого нет в ТЗ" должна произносить просто иначе.
Возможно в военке можно и иначе, в военке не работал. Но это как раз узкий сегмент, который отдельно выделять не стоит.
Кстати, тут еще для начала стоит определить что такое для вас - успешный проект? Это тоже очень тонкая материя, которая почти никогда не завязана чисто на срок/бюджет.
Что до моего опыта - он в профиле, вы можете поглядеть. про вас тоже интересно узать: не чтобы пипками меряться, но чтобы понимать уровень ваших проектов и сколько их было
в быдло стиле на "этого нет в ТЗ" обычно отвечают (и такое я тоже встречал): "потому что твои аналитики криворукие дебилы и написали говно, я за это платить не собираюсь и мне вообще плевать как ты это решишь" А дальше это летит шефу, для которого данный клиент важный и любимый.
И конечно можно уволиться, но можно и договориться, просто не надо лезть на рожон в слабой позиции.
Оттенки очень важны. Наверное корень в том же самом, что и по всем остальным фразам: запрещенная фраза просто констатирует факт, и менеджер не предлагает решения проблемы заказчика.
Заказчику это, как правило, не нравится.
Ну и отдельно именно "Этого нет в ТЗ" моментально и всегда (всегда) приводит к выяснению точно что там есть и нет и попыткам найти его недостатки. И почти всегда они там есть.
А инструменты, да, такие:
брать мелочевку и делать не просто молча типа "ну ок", нет, каждый раз подчеркивая, как мы идем на встречу выполняя допработу. Ночами не спим. Три раза придет, на четвертый уже можно эскалировать шефу: мы им идем на встречу, давайте прекратим - бюджет нерезиновый. Это вообще иная позиция.
не делать вообще, сперва задаваясь вопросом: "а кому это вообще надо и для чего?" Очень часто многие CR умирают именно в этом месте
не делать вообще, задавая вопросы по технике, на которые бизнес ответить просто не в силах. И тогда реализация переезжает в следующую фазу автоматом: у нас же сроки, мы не можем сдать.
не факт. в простых случаях прокатит. в сложных - вы будете втянуты в спор с заказчиком на тему, кто дурак: толи ваши аналитики, которые продолбали требования, толи бизнес. И по опыту, послушают скорее бизнес, только если у вас не будет железобетонной базы в виде протоколов именно в нужных формулировках.
Что бывает, но нечасто, потому что если вы практикующий РП вы знаете, что все зафиксировать невозможно, а если вы попробуете - этого читать никто не будет.
Поэтому фраза "Этого нет в ТЗ, но мы добавим за деньги" - тоже не очень приближает вас к результату.
Есть много других фраз вообще вбок, которые реально помогают.
самая простая: а что это и зачем нужно? Почему это критично, как вы считаете? а почему на этапе сбора требований это мы не обсудили (уже веет, но аккуратно).
Отдельно - есть способ взять в объем небольшую доработку, пойдя заказчику на встречу. и еще есть, но не могу же я переписать всю статью заново в камент. Тем более что после нее я еще 2 дописал в тележке.
художника обидеть может каждый (
Нет, это предоставление точной информации.
в статье есть про "пойду уточню и отвечу" для случая "мой проект". направлять к человеку можно далеко не всегда. Шеф на такое посшлет нафиг
Не мой проект - да, так можно отвечать, ничего криминального не вижу
угу. Если у вас такое ТЗ, что заказчик и правда за все заплатил, и вы сами лично его согласовали - придется сделать. Это раз.
Если серая зона - это отличный повод для договоренностей. Про это я пишу на канале, есть несколько стратегий. Если вам реально интересно, и в не просто тролите, могу дать пару ссылок на канал, маякните.
Если коротко 1: для неопределенности должен быть небольшой буфер (или большой, зависит от рисков), если нет ни буфера, ни требований а вы согласились - вопрос к вам - нафига?
Если коротко 2: часто можно договориться на небольшие и реально критичные доработки, а по остальным вступить в дискуссию "а зачем это нужно, давайте обсудим". Как правило, только если проект не провален в части аналитики, реально критичного упускается мало.
Ну, и отвечая именно на ваш кейс:
Я тимлид, у меня фикспрайс проект с заранее составленным и оцененным ТЗ. В середине пути заказчик решает для себя, что у нас тут аджайл, и начинает просить бесконечных правок и отступлений от изначального ТЗ. Вопрос - если фраза "Этого нет в ТЗ" и все ее производные запрещены, то как следует себя вести по мнению автора в данной ситуации
Заказчик , как правило, не решает аджайл или нет. Ему вообще плевать на методологию. Ему надо добавить требования в объем которые по какой то причине были пропущены.
Или ИТ команда профакапила анализ (что бывает), или бизнес пропустил (бывает также). А дальше у меня вопрос: насколько этап 1 встанет без этих доработок? Что на них завязано и какая цена вопроса? Если критично и недорого - можно и пойти на встречу. Если некритично - можно сделать потом (тем более, что сейчас уже работы идут и их изменние приведет к изменению сроков).
А может быть надо собраться, все систематизировать и сделать Этап 2 проекта.
Итак: я предложил несколько вариантов решения на ваш кейс и ни разу не ответил "Этого нет в ТЗ".
Ответил?
А вы даете ваше личное оценочное мнение, не прочитав даже статьи, и уж тем более - остальных статей автора. Иначе данный комментарий бы не появился вообще.
Ваша логика нормально работает для исполнителя по задаче. От РП требуется смотреть несколько дальше, чем 1 задача или 1 проект. Есть классический вопрос на собеседовании РП "что такое успешный проект?"
Так вот успешный - это не только сделанный в срок и бюджет. Если проект сделан хорошо, но отношения испорчены, это почти всегда неуспешный проект.
Ну и конечно же я не призываю нигде молча соглашаться со всем, что менеджеру предлагают, я пишу о другом. Есть 100 и 1 способ говорить иначе. Это просто навык переговоров и умение отстаивать личные и профессиональные границы, не теряя способности договариваться.
да ладно вам. отстойная пассивно-агрессивная фраза. https://t.me/morkovka_speredi_morkovka_szadi/271 вот тут в каменты загляните (не реклама, просто там хорошо обсудили), если хотите. Тут уже не буду писать, извините, не успеваю :)
Понял вас. С позиции разработчика, который вынужден брать на себя работу непрофессиональных менеджеров, которые неспособны ограничить объем и защитить команду от треша, вы 100% правы.
Задача менеджера (тоже много писал про это) видится мне в том, что для клиента он должен быть удовлетворителем потребностей, но не за счет команды и не за счет своей компании, в целом. Это непросто и это как раз показатель профессионализма, софтскиллов и всего о чем я пишу. Но чтобы разом ответить на все, нужна книжка (может и издам по мотивам статей потом). А тут просто статья, чего говорить им нельзя.
Потому что менеджер - штука нежная: ему говоришь "не ложись под заказчика" и он начинает всех слать, а потом проектов нет. Говоришь ему "будь добрее" - он подписывается вообще подо всем. Вот и приходится учить балансу :)
Для команды менеджер должен быть требовательным помощником. Тогда отлично работает связка: он прикрывает пацанов, а пацаны - его. Я так работал, и по моему, это самый лучший формат.
Про регламенты тоже писал, и там баланс знать надо. Есть менеджеры, которые даже в CV не стесняются написать, что они создали несколько сотен регламентов за год работы (!) Оно то конечно наверное круто и эффективно, только такое на практике никто не читает :) А так то согласен.
Его задача - чтобы проекты (все, а не только один конкретный) двигались, команда работала и сроки не срывались
Замечательно.
А если он делает проекты хорошо, но заказчик не доволен и не дает новых проектов? А если от него команда разбегается? А что если даже заказчик доволен, а недоволен шеф (который и есть главный заказчик менеджера, кстати)? Шефа послать нахрен?
Уточните, пожалуйста
это не получится, я вам по опыту скажу.
это не то чтобы я тут рассуждаю о справедливости: просто так не получится.
Блин, факт, Я ВАС УСЛЫШАЛ забыл ( вот что значит, писать статьи по ночам. а в Телеге, кстати, мы мощно перетерли и ее (заходите в мой канал и вы, дада, ссылочки под роликом, как водится), и знаете что? 1/3 подписчиков воспринимает ее совершенно нормально. Я бы сказал, что она мерзкая, но сильно не вредит, так что в списке она лишняя. У меня только максимально вредительские.
Чтобы нам с вами поговорить про клиентоориентированность и чего она стоит, мне надо понять ваш опыт: если вы продаван и знаете другие способы win-win кроме как понимать потребности вашего клиента и удовлетворять их - поделитесь, пожалуйста. Про себя и свой опыт я в профиле написал много, у вас в профиле ничего нет. А с дивана критиковать можно, но смысл.
Протоколировать надо, да. Но не только это. Менеджер который только протоколирует - это тупой админ.
ну вам коллега все ответил уже, все так: я не помню - это просто фраза которая говорит "я ничего делать не буду". Это плохая позиция для менеджера. Да и для исполнителя тоже, если он отвечает по задаче. Да еще и показывает нежелание помогать.
А так как мы про менеджеров, то кому он так может ответить? Заказчику или шефу (тоже заказчику). Отлично, выходит, вы не хотите помогать тем, кто вам деньги платит?
сложно, но можно. а если сильно давят и не слушают, можно принять как есть или уволиться. Отличие от галер все таки есть )
А вы по ссылке прошли, статью прочитали? Потому что она дает ответ именно на этот вопрос. А на комментарии и вопросы я там подробнейше ответил в каментах. Если есть вопрос про ТЗ - пишите туда, я тоже отвечу :)
Что делать - ясно там, это классика качественного управления.
Да и у меня статья есть "как говорить НЕТ, когда все хотят слышать ДА". Она тут на сайте - там все ответы, исчерпывающе
нисколько не утрирую, у меня за 25 лет таких случаев - вагон и тележка: как в бигтехах, так и в небольших командах, как с внутренним, так и с внешним заказчиком :)
и те, кто эти фразы говорит именно так, как сказано в обеих статьях - практически всегда - неопытные и неумеющие решать проблему на своем уровне менеджеры.
Я и сам такой был. Потом научился иначе, да и свою команду тоже научил, что показало, что если хочется - все можно.
Кстати, вы же тоже наверняка не просто предлагаете по любому поводу эксалировать? Если РП может подумать, передвинуть некритичные задачи и поставить критичные вперед - он же вполне способен сделать это сам, без руководителя? Особенно если он заранее не завязан на платежи и что-то такое?
О, а расскажите, как это оформляется на внутренних проектах и продуктах, мне интересно?
окей
Я тут придерживаюсь четкой позиции: процессы всегда неидеальны, на них, при желании можно спихнуть все, что угодно, в том числе собственное нежелание включить голову у товарища менеджера. Так что для начала пусть попробует включить голову, подумать, попробует решить на своем уровне а потом - добро пожаловать эскалировать. Но не в формате "спасите", а в формате, про который писал раньше: четко и с вариантами решения.