Search
Write a publication
Pull to refresh
33
29.2
Петр Жарков @peterzh

Руководитель проектов и проектных офисов с 2005 г

Send message

нисколько не утрирую, у меня за 25 лет таких случаев - вагон и тележка: как в бигтехах, так и в небольших командах, как с внутренним, так и с внешним заказчиком :)

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

Я и сам такой был. Потом научился иначе, да и свою команду тоже научил, что показало, что если хочется - все можно.

Кстати, вы же тоже наверняка не просто предлагаете по любому поводу эксалировать? Если РП может подумать, передвинуть некритичные задачи и поставить критичные вперед - он же вполне способен сделать это сам, без руководителя? Особенно если он заранее не завязан на платежи и что-то такое?

  1. О, а расскажите, как это оформляется на внутренних проектах и продуктах, мне интересно?

  2. окей

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

поддержу: всегда есть выбор: прикрыться бумажкой (при должном умении никто и никогда не трахнет или пойти спасать мир.

В моем мировоззрении и то, и то - крайности.

Все время прикрывать попу бумагой - бюрократия, все время спасать мир = неумение делегировать ответственность другим. Я за баланс.

НО есть и отличие стройки от айтишки: мы, в отличие от вас, можем "докручивать" систему.

Как вот построил каркас школы - пустил детей. Потом достроил крышу, переделал первый этаж нафиг. Если совсем уже все грустно - зарефактроил фундамент (да это сложно но можно))), потом уже вставил окна там, отопление и вот это все.

ну а потом А/Б тестирование: этот флигель школы покрасил в синий, тот в розовый и смотрю, куда чаще ходят ))

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

Нет ресурсов = "я не хочу думать, реши за меня проблему" Говорить так или иначе - ваш выбор. Просто потом не надо сердиться, что кругом повышают "удобных" людей. Для вас они "удобные", а для шефа они обладают той самой Can do attitude: "не говори мне, почему ты не можешь этого сделать, лучше скажи, что тебе надо, чтобы ты это сделал".

Никто же не запрещает сказать: "я сделаю, если отложить вот это и это и выделить мне дополнительную команду"...

Со всем уважением отвечу, что я многократно прочитал данные посты, когда их писал для ТГ канала, затем я перечитал их, когда писал статьи, а до этого, я 4 года применял их у себя в компании, где было РПО.

Если вы видите логическое несоответствие - спросите, почему так? Пока что ваш комментарий не более, чем пассивная агрессия.

  1. да, полезно. но, как правило, это не прописано. Тем более на внутренних проектах/продуктах такое не принято прописывать, я не встречал ни разу

  2. суть статьи не в том, что ресурсов должно всегда хватать. Нет, разумеется. просто эта фраза, сказанная именно так, показывает РП, как человека, не желающего для начала включить свою голову. Эскалировать надо, но не фразой "у меня нет ресурсов". Эскалировать надо разобрав проблему и предлагая варианты решения.

прочитать первую статью :)

автор выражает благодарность. доброе слово и собаке приятно, а автор - не собака, так что тем более ))

Поясните почему, интересно

вы не понимаете, это другое )))

а нет противоречия :)

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

тут знаете как у меня: кто-то должен беречь отношения с клиентом, а кто-то целостность системы и качество.

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

Например: делаем какашечку, но прямо сразу планируем время на техдолг и РП зуб дает, что будет сделано нормально. Или сразу РП идет и увеличивает оценку заказчику. Да сложно , да больно. А надо.

  • База упала!

  • не волнуйся, я сделал скриншоты!

  • ты наверное хотел сказать снепшоты?

  • ....

да, это хорошо. я тоже наверняка с вами бы не сработался :)

продолжим давайте) 100М рублей или других условных единиц?

Я и за ярд проекты делал, неоднократно. Не было судов. Крики, шум, пыль - да. А судов нет. Больше того, почти всегда (исключение - лютая политика) мои аккаунты росли YoY на 20% (ну это примерно за последние лет 15, бывало и веселее). Я считаю, именно за счет желания помогать и умения договориться с клиентом. Да, иногда делали виноватым, иногда помогал проектный запас на это все.

Если вы про проекты более 1 млрд и цепочки субчиков - пожалуй, соглашусь - там вообще другая коммуникация. Матрица ответственности, борда стейкхолдеров и уведомления под роспись, чтобы никто не отполз. Тут готов сказать, что я пишу обо всем, что менее ярда на рынке ИТ РФ. и таких проектов (в штуках) - подавляющее большинство. Пусть начинающие менеджеры сперва учатся азам: сперва надо догвариваться и только потом идти бить друг другу лица. Война - продолжение политики. Но для меня - именно продолжение. Сперва - политика )

А я даже спорить не буду, вы совершенно, просто на 150% правы. Договоренности должны быть.

Моя позиция всегда постоянна, все мои статьи на Хабре почти про одно и тоже: "добрым словом и пистолетом можно сделать намного больше, чем просто добрым словом", только я ее немного переворачиваю: "пистолетом и добрым словом можно сделать намного больше, чем просто пистолетом".

Пистолет = ТЗ

Доброе слово = хорошие отношение и желание помочь.

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

Да, когда прижмет, ты можешь стать крайним. Да, я участвовал в проектах, когда заказчик тупо использовал и кидал исполнителя - бывает, риски. А все равно фраза "Этого нет в ТЗ" никогда не помогала отношениям.

Это не значит , что нельзя заказчику говорить "нет", еще как можно. Просто не так топорно и в лоб. А вот как - я отдельно писал, есть статья "как говорить "нет", когда все от вас ждут "да"".

увы, все так. причем, я вижу что у нас на рынке в РФ таких тенденций больше и больше: вместо того, чтобы учиться говорить "нет", манагеры учатся манипулировать командой. Потому и начал писать статьи год назад.

Но, кстати, в бигтехах массово наблюдаю противоположную картину: разработчики берут дикие сроки на ерунду (кнопку добавить - неделя), манагеры такие "ой я не буду спорить, лишь бы сделал". И в итоге компания тратит зазря огромные бабки на ФОТ бездельников - разработчиков.

Я бы сказал - все хороши уже :)

Спасибо, понял.

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

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

Почему уверен: потому что и в моем опыте и в опыте многих коллег я слышу одно и тоже (да и теория игр говорит аналогичное): win-win выгоднее для обеих сторон. А поэтому выгоднее договариваться.

Это не отменяет жесткости позиции, но, мой тезис в другом: позиция должна быть доброжелательной. Разумеется, пока одна из сторон не собралась в суд.

Но судами заканчивается очень мало проектов, так что я бы назвал это исключением. Поделитесь, если в вашем опыте иначе (из скольки запущенных проектов у вас сколько закончилось судами или околосудебными разборками).

Искренне интересно, так как у меня за 50-100 проектов (я точно не считал, но оч много) - ни одного. Да, собирались в суд несколько раз, но всегда договаривались. И да, фраза "нет в ТЗ" работала плохо, договаривались "по понятиям", как и в вашем случае.

Если это система - да. Но речь идет вовсе не про это.

Вы знаете, я сам сделал много проектов и как РПО - еще столько же примерно.

Я ни разу не встречал мотивации клиента "затянуть сроки, чтобы выставить исполнителя на штрафняки". Новые требования - да. Пропустили что-то на фазе анализа - да.

Но штрафняки - нет.

по остальному, как прокаментил выше:

Смысл не в вылизывании попы заказчика. Смысл в запрете на конкретную фразу именно в таком звучании. Потому что - см статью.

Как эту фразу говорить правильно, можно прочитать например вот здесь:
https://habr.com/ru/articles/837070/ - "Как говорить заказчику НЕТ, когда все от вас хотят услышать ДА."

ТЗ обязательно - это мастхэв.

Заказчик не всегда прав - это факт

Но от того что вы тыкнете заказчика в то, что он кретин, ни проекту ни вам лучше не сделает. Это надо решать дипломатичнее. Иначе - будете ловить проблемы на проектах.

нет, вы не поняли смысла (возможно потому, что надо было передать его четче.

Смысл не в вылизывании попы заказчика. Смысл в запрете на конкретную фразу именно в таком звучании. Потому что - см статью.

Как эту фразу говорить правильно, можно прочитать например вот здесь:
https://habr.com/ru/articles/837070/ - "Как говорить заказчику НЕТ, когда все от вас хотят услышать ДА."

ТЗ обязательно - это мастхэв.

Заказчик не всегда прав - это факт

Но от того что вы тыкнете заказчика в то, что он кретин, ни проекту ни вам лучше не сделает. Это надо решать дипломатичнее. Иначе - будете ловить проблемы на проектах.

1
23 ...

Information

Rating
566-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Project Director, Chief Operating Officer (COO)
Lead
Project management
Development management
People management
Product management
IT service management
Company management
Business development
Personnel development