Comments 38
У Вас всё хорошо и вас это смущает? Мне кажется с небольшой доработкой поговорка про админа (хороший админ это тот, который ничего не делает) может применяться и к руководителям, это утрированно… но посудите сами, если директор компании как шизик бегает и орёт на всех, и хватается за все дела, и в итоге ничего не получает и все косяки принимает ответственно на себя… не уж то это лучше чем грамотно делегированные обязанности? Руководитель это капитан у штурвала, а не ответственный механик левого мотора танкера…
Соглашусь про ответственность, провал команды — твой провал. Это ж очевидно. Отсюда и подход к выбору решения, если «моя хата с краю» — в шею, и нужно разбираться в ввереной предметной области.
Соглашусь про ответственность, провал команды — твой провал. Это ж очевидно. Отсюда и подход к выбору решения, если «моя хата с краю» — в шею, и нужно разбираться в ввереной предметной области.
Могу согласится в случае, когда менеджер проекта настроил процесс настолько, что все работает и без его непосредственного участия, а он при этом руку держит «на пульсе» и в случае возможных неприятностей находит варианты решений. Были бы все такими — набор кадров проходил бы безболезненно, мониторить руководителей не было бы необходимости и этой статьи бы не было. Другой вопрос, когда столь либеральный вариант применяется менеджером неоправданно, процессы не настроены, команде работается не комфортно и рано или поздно вылезут недовольства в виде увольнений сотрудников, низкого качества продукта и т.п. И об этом первоначально знают только непосредственные участники проекта, проблемы видят, друг другу могут тихо выговаривать недовольства. И вариант «гнать в шею» — это хорошо, конечно, но слишком поздно, так как проблемы на проекте уже явно будут. Поэтому и интересен опыт предупреждения/мониторинга работы руководителей проектов.
Ну значит неправильно применяется скрам, вы же(всмысле продукт-оунер) на каждой итерации должны иметь что-либо удовлетворяющее требуемому качеству… вообщем это как мне кажется не проблема руководителя, а проблема руководителя руководителей… ну вы поняли… вы как руководитель руководителей похоже хотите формализма, а не доверительных отношений.
В одном из интервью Стив Джобс так и говорил что люди которые с ним фигачили девайсы и приложения были на одном уровне а т.е. на одной волне и все вкурсе общих проблем, отвечали все. А вы же об иерархичной модели «правления», там и скрам то не нужен по большей части. А метрики — стаж работы, сроки и результаты. Ничего больше. Мониторишь результаты и всё
И вариант «гнать в шею» никогда не поздно — just business :) хотя странно что человек стал руководителем и не разбирается в предметной области.
В одном из интервью Стив Джобс так и говорил что люди которые с ним фигачили девайсы и приложения были на одном уровне а т.е. на одной волне и все вкурсе общих проблем, отвечали все. А вы же об иерархичной модели «правления», там и скрам то не нужен по большей части. А метрики — стаж работы, сроки и результаты. Ничего больше. Мониторишь результаты и всё
И вариант «гнать в шею» никогда не поздно — just business :) хотя странно что человек стал руководителем и не разбирается в предметной области.
> «Шестерство» не в почете
А назовите это «арбитражем». Если непосредственный руководитель не может / не хочет, то необходим вариант обращения к вышестоящему.
А то могут быть всякие странности, от которых анкеты не спасут.
Вот к примеру — непосредственный руководитель взъелся на двух своих подчиненных, «ваш код плохойвы индусы» (Ц). «Гнобленье» вызывало овации всей команды. Казалось бы — вот оно слабое звено, их надо немедля убирать.
Разбор полетов показал что в комнате не поделили… кондиционер. Этим двоим «было холодно» при звуках работы аппарата. Банально посадили их в другой кубикл — и код внезапно стал снова хорошим.
И это в общем-то простая ситуация, бывает куда похлеще.
А назовите это «арбитражем». Если непосредственный руководитель не может / не хочет, то необходим вариант обращения к вышестоящему.
А то могут быть всякие странности, от которых анкеты не спасут.
Вот к примеру — непосредственный руководитель взъелся на двух своих подчиненных, «ваш код плохой
Разбор полетов показал что в комнате не поделили… кондиционер. Этим двоим «было холодно» при звуках работы аппарата. Банально посадили их в другой кубикл — и код внезапно стал снова хорошим.
И это в общем-то простая ситуация, бывает куда похлеще.
Просто сделайте премию РП функцией от рентабельности проекта\продукта, которым он занимается и все само станет на свои места. А еще лучше при этом удвоить нагрузку на каждого, разгонав половину самыми низкими KPI.
Если есть проекты, на которых компания инвестирует деньги, а не получает, то за них назначайте отдельные премии обратно пропорциональные затратам.
Если есть проекты, на которых компания инвестирует деньги, а не получает, то за них назначайте отдельные премии обратно пропорциональные затратам.
Спасибо за комментарий. Подтвердили вариант личной заинтересованности в успехе проекта. Мы к ней периодически возвращаемся, но пока только на словах, нужно еще получение одобрения и поддержки высших руководителей =)
А вы и так придете к этому варианту, когда захотите исправить ситуацию. Ибо на позиции менеджера очень удобно делегировать ответственность, оставаясь ни в чем не виноватым. Ничем, кроме прямой мотивации от результата проекта, это не получится исправить.
Интересный случай когнитивного искажения en.wikipedia.org/wiki/Confirmation_bias
Наверняка у вас есть сомнения в действенности подобного решения, что небезосновательно, ведь личная заинтересованность работает не всегда. Однако за неимением рациональных критериев оценки вы находите подтверждение своей теории в комментариях из интернета.
Наверняка у вас есть сомнения в действенности подобного решения, что небезосновательно, ведь личная заинтересованность работает не всегда. Однако за неимением рациональных критериев оценки вы находите подтверждение своей теории в комментариях из интернета.
А что вы думаете насчет этой статьи? habrahabr.ru/post/152445/
Я думаю что вводить KPI для программистов — попытка решить проблему которой или вообще нет, или её никто не понимает.
Большая часть программистов уже мотивирована писать код и основная задача менеджмента — не мешать им это делать. Можно еще повышать интерес обучениями и поездками на конференцию.
Измерять кто пишет лучше, а кто хуже — очень сложно, слишком много нелинейных факторов. Только на очень типовых проектах можно ввести подобие нормирования, и то не всегда такая система работает.
А вот что действительно нужно мотивировать, так это командную работу. Очень хорошо работают проектные премии в этом случае. При этом премия должна быть значительной.
Кстати это не значит, что не надо контролировать продуктивность. В идеале надо иметь софт для учета времени сотрудников, и если кто-то сильно отклоняется от типового поведения программистов, то это повод поговорить «по душам». При этом сотрудник не обязательно должен находится в офисе, можно и удаленных также контролировать. НО НЕЛЬЗЯ ПРИВЯЗЫВАТЬ УРОВЕНЬ ЗП К ЭТОЙ МЕТРИКЕ.
Большая часть программистов уже мотивирована писать код и основная задача менеджмента — не мешать им это делать. Можно еще повышать интерес обучениями и поездками на конференцию.
Измерять кто пишет лучше, а кто хуже — очень сложно, слишком много нелинейных факторов. Только на очень типовых проектах можно ввести подобие нормирования, и то не всегда такая система работает.
А вот что действительно нужно мотивировать, так это командную работу. Очень хорошо работают проектные премии в этом случае. При этом премия должна быть значительной.
Кстати это не значит, что не надо контролировать продуктивность. В идеале надо иметь софт для учета времени сотрудников, и если кто-то сильно отклоняется от типового поведения программистов, то это повод поговорить «по душам». При этом сотрудник не обязательно должен находится в офисе, можно и удаленных также контролировать. НО НЕЛЬЗЯ ПРИВЯЗЫВАТЬ УРОВЕНЬ ЗП К ЭТОЙ МЕТРИКЕ.
Статья интересна. На самом деле сложности с внедрением KPI существенные. Это одна из причин, почему мы пока так и не пришли к ней в отношении руководителей проектов. Что касается программистов/тестировщиков/БА/дизайнеров, то и в планах нет привязки материального вознаграждения к каким-либо метрикам. Во-первых, зачастую у данных сотрудников нет возможности напрямую влиять на успешность проекта. Во-вторых, есть определенные сложности с объективностью метрик (в статье как раз хорошо это озвучено). В-третьих, у нас не возникало проблем с оценкой работы, т.к. работа более прозрачна, да и фидбэк получаем оперативно. Так что поступаем по правилу не трогать то, что хорошо работает итак.
Могу еще отметить интересный факт, который имел место в нашей компании: несколько лет назад РП начали озвучивать на ретроспективах насколько программисты вложились в собственные оценки задач (скажем, оценили в 2 дня, закрыли за неделю). С тех пор оценки задач увеличились, т.е. ребята начали страховаться, но ни чуть ни быстрее работать. И это при том, что на уровень з/п, премии, похвал и поощрений это никак не влияло, да и пофамильно никого не озвучивали. Мы пришли к выводу, что даже простое озвучивание результатов повысило ответственность за оценку. Добавление дополнительной значимости этой оценки могло спровоцировать дополнительно страховку по времени, либо низкое качество работы, лишний стресс разработчикам. Но возможно, мы столкнулись с частный случаем.
Могу еще отметить интересный факт, который имел место в нашей компании: несколько лет назад РП начали озвучивать на ретроспективах насколько программисты вложились в собственные оценки задач (скажем, оценили в 2 дня, закрыли за неделю). С тех пор оценки задач увеличились, т.е. ребята начали страховаться, но ни чуть ни быстрее работать. И это при том, что на уровень з/п, премии, похвал и поощрений это никак не влияло, да и пофамильно никого не озвучивали. Мы пришли к выводу, что даже простое озвучивание результатов повысило ответственность за оценку. Добавление дополнительной значимости этой оценки могло спровоцировать дополнительно страховку по времени, либо низкое качество работы, лишний стресс разработчикам. Но возможно, мы столкнулись с частный случаем.
Хм хм — вообще говоря этот «коэффициент» еще и индивидуален и очень помогает в планировании.
И вот почему — если скажем Вася дает оценку в 24 часа — то это «васиных» 24 часа, Петя может работать медленнее. Тогда в спринт эти часы надо записывать с коэффициентом 0.8 или даже 0.6 — все зависит от того кто будет делать. Что интересно, даже если это оценка Васи и делать тоже будет Вася — то коэффициент тоже будет меньше единицы.
Конкретные цифры обычно получаются экспериментально после первых спринтов, и в дальнейшем уточняются по ходу работ. И если коэффициент у Васи устойчиво растет — значит и Вася над собой тоже растет и его оценки все точнее ;-)
Планирование — да, станет лучше. А быстрее работать Вася не станет, мотивация же не изменилась.…
И вот почему — если скажем Вася дает оценку в 24 часа — то это «васиных» 24 часа, Петя может работать медленнее. Тогда в спринт эти часы надо записывать с коэффициентом 0.8 или даже 0.6 — все зависит от того кто будет делать. Что интересно, даже если это оценка Васи и делать тоже будет Вася — то коэффициент тоже будет меньше единицы.
Конкретные цифры обычно получаются экспериментально после первых спринтов, и в дальнейшем уточняются по ходу работ. И если коэффициент у Васи устойчиво растет — значит и Вася над собой тоже растет и его оценки все точнее ;-)
Планирование — да, станет лучше. А быстрее работать Вася не станет, мотивация же не изменилась.…
Особенно интересно узнать про «Выведенный экономистами показатель не совсем применим к разработчикам: ведь они не могут контролировать отдачу от своей работы и на ходу измерять ее в деньгах. То есть не могут напрямую влиять на показатель.»
Я думаю на материальном стимулировании далеко не уедете. Это будет работтать полгода-год, не больше. Потом народ поймет что это просто замануха и не более.
Это одна из составляющих. Большинство работает за деньги. Помимо этого, также необходимо показывать руководителю проекта в чем конкретно польза от его проекта для всех (социальная ответственность внутри компании и для заказчика) и давать определенную свободу действий (я никогда не понимал жесткого графика для ПМ, сейлов, РП и подобного звена — график человека должен определяться рабочими нуждами).
Автору поста: «Шестерство», как вы его называете — нужно вводить, но аккуратно и обдуманно. Хотя бы потому, что вы сами его так называете. Обычный руководитель проекта и исполнитель проекта — оба наемники, каждый со своими функциональными обязанностями. Попытка дистанцироваться от возможных проблем в их взаимодействии — попытка засунуть голову в песок, не более. Если эти 2 человека не срабатываются — подобные сигналы надо ловить и обрабатывать, а не спускать на тормозах. В одной из моих команд так потеряли 2 хороших программистов, сигналы выловили слишком поздно.
Автору поста: «Шестерство», как вы его называете — нужно вводить, но аккуратно и обдуманно. Хотя бы потому, что вы сами его так называете. Обычный руководитель проекта и исполнитель проекта — оба наемники, каждый со своими функциональными обязанностями. Попытка дистанцироваться от возможных проблем в их взаимодействии — попытка засунуть голову в песок, не более. Если эти 2 человека не срабатываются — подобные сигналы надо ловить и обрабатывать, а не спускать на тормозах. В одной из моих команд так потеряли 2 хороших программистов, сигналы выловили слишком поздно.
Такое наблюдается если сотрудники не видят связи между усилиями и результатами. Но для ПМов прямая привязка к финансовым результатам (в случае заказных проектов разработки ПО) очень даже прозрачную схему дает.
По моему опыту в таком случае ПМ получает свой бонус за счет разработчиков — проект накопит технический долг, или по просту говнокод, в котором им самим же и плавать. А ПМ такой довольный с бонусом. Лично я бы уволился с такого проекта сразу.
Смотрите. Вы отмечаете, что руководители проектов находятся в роли наблюдателей. Т.е. если в проекте все хорошо — это их заслуга, если все плохо — не их вина. На мой взгляд, решение такой проблемы есть. Например, вы делаете ответственного за проект только руководителя проекта. Т.е. тестировщик, программист, инженер и т.п. кто входит в команду проекта и находятся под управлением руководителя проекта, не несут персональной ответственности за успешность проекта. В краткосрочной перспективе это плохо, но в более далекой — есть определенные плюсы. Но об этом чуть позже. Так вот, за проект отвечает только руководитель проекта. Если проект провалился, руководитель проекта не может сказать, что его тестировщик плохо сработал. Это личное дело руководителя проекта и тестировщика, т.к. за проект отвечает исключительно его руководитель и только он. При этом его мотивировочная часть зависит не только от успешности персонально его проекта, но всей линии проектов в целом. Т.е. если два руководителя проекта сработали на отлично, а третий провалил все что мог и в сумме линия оказалась убыточна, часть премии по итогам не получают все руководители проекта, а не только главный гад. Тем самым появляется интерес доносить до руководства о проблемах в коллективе, которое руководство может не видеть по тем или иным причинам. Если ты видишь, что человек работает плохо и ты от этого персонально страдаешь, то замалчивать этот факт будет просто невыгодно.
Теперь о технических исполнителях. Они замотивированы на участие в проекте. Т.е. человек может за з.п. сидеть и комментировать фотографии в контакте, а может проектировать-тестировать в рамках проекта и получать за это определенный респект. Так вот если исполнитель бестолковый, руководитель проекта будет стараться не брать такого при наборе команды проекта. Балбес или сам поймет бесперспективность такого поведения или будет ковыряться за оклад. Минус такого подхода в том, что понятно будет с кем имеешь дело только через участие в двух-трех проектах.
Теперь о технических исполнителях. Они замотивированы на участие в проекте. Т.е. человек может за з.п. сидеть и комментировать фотографии в контакте, а может проектировать-тестировать в рамках проекта и получать за это определенный респект. Так вот если исполнитель бестолковый, руководитель проекта будет стараться не брать такого при наборе команды проекта. Балбес или сам поймет бесперспективность такого поведения или будет ковыряться за оклад. Минус такого подхода в том, что понятно будет с кем имеешь дело только через участие в двух-трех проектах.
Вот у вас ситуация-руководитель наладил работу своей команды так, что не требуется его вмешателсьво, это эдакая самоорганизующаяя и самомотивирующаяся команда, и вы при этом решатете что такой руководитель-лишнее звено? Интересно… Если вы едете на машине и не слышите как работает мотор, значит ли это что мотор вообще не нужен?
А по поводу того «что вы сделали, чтобы было да» -есть ли у такого руководителя полномочия чтобы что-то поменять? Может ли он увеличить зарплату недовольному? Врятли… Может ли он купить новую мебель и технику, сделать ремонт в офисе, оборудовать зону отдыха? Тоже нет. Ну так а какой смылс тогда с него спрашивать? Дайте ему сначала полномочия а потом спрашивайте.
А по поводу того «что вы сделали, чтобы было да» -есть ли у такого руководителя полномочия чтобы что-то поменять? Может ли он увеличить зарплату недовольному? Врятли… Может ли он купить новую мебель и технику, сделать ремонт в офисе, оборудовать зону отдыха? Тоже нет. Ну так а какой смылс тогда с него спрашивать? Дайте ему сначала полномочия а потом спрашивайте.
На самом деле нет цели найти виновных или причину для наказаний и лишений. Одно дело, когда РП наладил работу и следит за процессами и совсем другое, когда он распределил свои обязанности между членами команды, тем самым сняв с себя ответственность и обязанности. На более частном примере это могло привести к тому, что программисты начинали массу времени тратить на общение с заказчиками по решению задач, которые по идее должен был решать РП, не успевать в свои оценки/дедлайны и проч., тестировщики оказывались ответственными за релизы. Никаких сроков, итераций, плановых релизов — в любой момент мог произойти аврал, срочный и внезапный апдейт, добавление супер важной фитчи и все это делалось, команда же только отчитывались о проделанной работе РП. В общей суматохе работа делалась, даже заказчик мог быть доволен, была недовольна команда. У команды сверхнагрузка, недовольство работой РП, нервозность на проекте и зачастую овертаймы, плюс сотрудники прекрасно понимают, что входит в их обязанности и любые дисбалансы радости от работы не добавляли. Это как частный случай, были и другие проблемы, которые возникали и которые оказались известными вышестоящему руководству слишком поздно. Тут стоит учитывать, что зачастую фидбэк о работе команды РП озвучивает вышестоящему руководству, а вот кфидбэк команды РП — редкий случай (нужный ли?!).
Стоит отметить, что до определенного времени или, скажем, определенных претендентов, РП у нас работали автономно и кто-то со стороны подключались к проекту только если возникали недовольства со стороны заказчика. Тогда старший РП/СТО и т.п. (в зависимости от проблемы) помогали найти решения проблем и все всех устраивало. В такой ситуации оценка работы РП больше оценивал заказчик с позиции доволен/не доволен (на зп или премию это никак не влияло), оценку работы команды предоставлял руководитель проекта (а тут могли быть и увольнения), отношение команды к РП оставалось неизвестным. Описанная проблема мотивации/мониторинга появилась с ростом компании, вовлечением новых РП, увеличение сложности проектов.
Стоит отметить, что до определенного времени или, скажем, определенных претендентов, РП у нас работали автономно и кто-то со стороны подключались к проекту только если возникали недовольства со стороны заказчика. Тогда старший РП/СТО и т.п. (в зависимости от проблемы) помогали найти решения проблем и все всех устраивало. В такой ситуации оценка работы РП больше оценивал заказчик с позиции доволен/не доволен (на зп или премию это никак не влияло), оценку работы команды предоставлял руководитель проекта (а тут могли быть и увольнения), отношение команды к РП оставалось неизвестным. Описанная проблема мотивации/мониторинга появилась с ростом компании, вовлечением новых РП, увеличение сложности проектов.
> распределил свои обязанности между членами команды
Распределение работы, делегирование полномочий и следовательно отвественности одна из главных задач руководителя). Если разработчики стали напрямую общатся с заказчиком-это же прекрасно, убирается несколько звеньев на пути следования информации, которые неизбежно приводят к ее искажению.
А вот отсутствие планирования и срыв сроков-безусловный просчет руководителя. Да и недовльство команды-тоже, тем более что если за овертаймы не доплачивали. Если руководство не знало про овертаймы-это чья вина?) Такое впечатление что у вас руководство живет какой-то своей жизнью а простые смертные своей. У вас удаленная команда? Надо быть ближе к народу)
Распределение работы, делегирование полномочий и следовательно отвественности одна из главных задач руководителя). Если разработчики стали напрямую общатся с заказчиком-это же прекрасно, убирается несколько звеньев на пути следования информации, которые неизбежно приводят к ее искажению.
А вот отсутствие планирования и срыв сроков-безусловный просчет руководителя. Да и недовльство команды-тоже, тем более что если за овертаймы не доплачивали. Если руководство не знало про овертаймы-это чья вина?) Такое впечатление что у вас руководство живет какой-то своей жизнью а простые смертные своей. У вас удаленная команда? Надо быть ближе к народу)
Кстати об издержках бонусной системы.
Если бонус РП напрямую завязан на результат, то у РП появляется отличный стимул вынуждать программистов овертаймить («клиенту надо»). И если эти овертаймы еще и не оплачиваются…
Я такие финты ушами наблюдал, получается картинка «сдал-вовремя-получил-бонус-сменил-команду». Особенно если суппорт передается другому РП! И выходит что эпик фейлов нет, сроки отлично, но…
И бонусная система таких кадров активно поощряет и продвигает наверх, вот что интересно.
А выявляются такие гиганты только случайно — если хватанут слишком для них большой кусок и не сумеют удержаться на грани «выжимаю — разбегаются» длительное время. Или в команду нужны серьезные технари на энричмент / ресерч, которые это погоняло видят и от него бегут. Вот тогда издержки и вылезают наверх за пределы компетентности такого руководителя.
Если бонус РП напрямую завязан на результат, то у РП появляется отличный стимул вынуждать программистов овертаймить («клиенту надо»). И если эти овертаймы еще и не оплачиваются…
Я такие финты ушами наблюдал, получается картинка «сдал-вовремя-получил-бонус-сменил-команду». Особенно если суппорт передается другому РП! И выходит что эпик фейлов нет, сроки отлично, но…
И бонусная система таких кадров активно поощряет и продвигает наверх, вот что интересно.
А выявляются такие гиганты только случайно — если хватанут слишком для них большой кусок и не сумеют удержаться на грани «выжимаю — разбегаются» длительное время. Или в команду нужны серьезные технари на энричмент / ресерч, которые это погоняло видят и от него бегут. Вот тогда издержки и вылезают наверх за пределы компетентности такого руководителя.
Как мне кажется, вы не понимаете, что делаете.
Вместо выращивания руководителей вы всё сводите к поиску самого слабого звена. Пытаетесь найти виноватых в своей некомпетентности. Работа с людьми начинается с работы над собой. Надо понимать, что тот механизм организации, который вы строите, включает и вас в том числе.
Вместо выращивания руководителей вы всё сводите к поиску самого слабого звена. Пытаетесь найти виноватых в своей некомпетентности. Работа с людьми начинается с работы над собой. Надо понимать, что тот механизм организации, который вы строите, включает и вас в том числе.
забавная у Вас логика. Что нужно поменять в себе, чтобы другой менеджер стал лучше выполнять свою работу?
Я не знаю, как ответить на этот вопрос в двух предложениях. Есть много аспектов взаимодействия с сотрудниками, а значит много параметров для изменений. Процесс управления также управляем, это же очевидно.
Обычно нужно хотя бы перестать быть мудаком. Я не про вас говорю, просто частый пример. Руководитель ведет себя как мудак, в результате мудачество спускается вниз на всех уровнях.
UFO just landed and posted this here
Просматривать старшему РП, т.е. руководителю менеджеров проекта? Если да, то это вариант, если в подчинение 2-3 РП и у каждого 1-2 проекта максимум, при этом вышестоящий РП с большего в курсе проектов и/или на нескольких ретроспективах звучит одна и та же проблема. Но даже в таком случае, не думаю, что на ретроспективах народ настолько откровенен, что сможет сказать своему РП, что он, к примеру, слишком мало уделяет внимание проекту и слишком много полномочий делегирует.
Разделяю эту точку зрения. Добавлю, что менеджеры в вышеописанной ситуации делают то, что от них требуется — отвечают за проект (в смысле получают по шапке или бонусы). А что они еще должны делать? У вас (автора статьи) есть четкие критерии что должен делать менеджер? Внутренний регламент проектного управления например, по которому можно оценивать их деятельность. Если бы был, было бы над чем работать, и не удивляться.
Ну к тому что работу надо распределять а полномочия делегировать надо еще прийти…
Вы слышали про skip level one to one? Или про OKR? Если слышали, то вот вам и ответ.
Я одно не пойму, как так получается у вас, что можно делегировать ответственность? Ответственность имеет направленность только вверх — ты можешь принять ответственность за нижестоящих, но не можешь делегировать.
То есть, если у менеджера получается делегировать ответственность в вашей компании то значит менеджер менеджера это позволяет. И вопросы на самом деле к менеджеру менеджеров.
—
Ответственность здесь значит accountability, не responsibility. Responsibility как раз нужно делегировать. Не знаю как лучше перевести это два слова, извините.
Sign up to leave a comment.
Проблема стиля работы руководителя проекта или что делать с ответственной безответственностью?