Проблема стиля работы руководителя проекта или что делать с ответственной безответственностью?

    Еще несколько лет назад меня абсолютно не интересовал такой момент в управлении проектами как стиль работы руководителя. Наверное, как и многим руководителям, в первую очередь больше приходилось уделять внимание срокам, бюджету, качеству и удовлетворенности/счастью заказчика и лишь во вторую очередь комфорту работы команды. Благо велись проекты по скраму и не пропускались ретроспективы. И, конечно, получая отрицательный отзыв на какой-то процесс, уже было никак нельзя не предпринять попытки его устранить. Так или иначе, в малых и средних командах складывались дружеские отношения, чувствовался интерес к работе, ну и если что-то шло не так, то в теплой атмосфере ближайшего бара решались все прочие нюансы.

    Однако все изменилось, когда кроме прямого ведения проектов, пришлось перейти еще и к подбору, мотивации и контролю самих руководителей проектов. И если с цифрами и статистикой по проектам все более менее понятно и прозрачно, то комфорт работы команд оставался тайной за семью печатями. Причин в этом несколько:
    1. Не смотря на то, что ретроспективы никто не отменял и у команд оставалась возможность высказать все моменты, мешающие их работе, то влиять на отсутствие реакции на эти пожелания возможности не было.
    2. Высказывать негативные моменты вышестоящему начальству у нас просто не принято. «Шестерство» не в почете и поэтому отрицательный отзыв если и приходил, то уже слишком поздно (человек устал работать в постоянном напряжении/без понимания чего от него хотят и проч. и уже нашел другую компанию).

    Все это привело к тому, что появилась особая группа управленцев с этаким либеральным стилем управления, которые фактически не берут на себя ответственность за принятие решений и сами уходят как бы на второй план. Пока на проекте все спокойно – все отлично: команда работает сама по себе, проблем нет, народ мотивирован свободой принятия решения, чувствует высокую ответственность, «менеджер ему не мешает». Руководителю весьма комфортно, так как работы у него немного, а успешные же результаты так или иначе будут предписаны ему. В случае же неудачи всегда находится виновный за проступок (тестировщик недостаточно протестировал, программист не смог найти общий язык с заказчиком/программистом, задача была недостаточно ясна и проч.).

    Стоит отметить, что первоначально такого руководителя весьма сложно идентифицировать (особенно, если команда сама по себе сплочённая и работает успешно). Во-первых, такие управленцы могут вовремя предоставлять отчеты, внешне быть очень организованы, очень заинтересованы работой, могут участливо обсуждать с вами все возможные проблемы и способы их решений. Во-вторых, как и говорилось выше, отрицательные отзывы зачастую приходит слишком поздно и уже тогда, когда это действительно проблема. Так или иначе, в нашей компании с определенного момента таких руководителей начали относить к ненужному элементу команды, а иногда и вредоносному, и поэтому начали искать решение проблемы (хотя и есть огромный соблазн просто отпустить такого менеджера проекта в свободное плавание). К примеру, получая отчет по проекту с описанными проблемами, смотрим, что менеджер сделал, чтобы нивелировать проблему/избежать ее в будущем и прочее (тут подходит фраза из к/ф «Москва слезам не верит»: «Меня не волнует почему нет, меня интересует, что вы сделали, чтобы было да»), проводить анкетирование команды и проч. Сейчас пока сложно сказать насколько успешными будут все меры и именно поэтому так интересен опыт других компаний. Итак, было бы очень интересно узнать, обращаете ли вы внимание на стиль управления руководителей проекта? Каких руководителей проектов выбираете? Проводятся ли какие-либо объективные/субъективные оценки работы руководителя? Интересуетесь ли как относится команда к данному менеджеру?
    Share post

    Similar posts

    Comments 37

      +3
      У Вас всё хорошо и вас это смущает? Мне кажется с небольшой доработкой поговорка про админа (хороший админ это тот, который ничего не делает) может применяться и к руководителям, это утрированно… но посудите сами, если директор компании как шизик бегает и орёт на всех, и хватается за все дела, и в итоге ничего не получает и все косяки принимает ответственно на себя… не уж то это лучше чем грамотно делегированные обязанности? Руководитель это капитан у штурвала, а не ответственный механик левого мотора танкера…
      Соглашусь про ответственность, провал команды — твой провал. Это ж очевидно. Отсюда и подход к выбору решения, если «моя хата с краю» — в шею, и нужно разбираться в ввереной предметной области.
        +1
        Могу согласится в случае, когда менеджер проекта настроил процесс настолько, что все работает и без его непосредственного участия, а он при этом руку держит «на пульсе» и в случае возможных неприятностей находит варианты решений. Были бы все такими — набор кадров проходил бы безболезненно, мониторить руководителей не было бы необходимости и этой статьи бы не было. Другой вопрос, когда столь либеральный вариант применяется менеджером неоправданно, процессы не настроены, команде работается не комфортно и рано или поздно вылезут недовольства в виде увольнений сотрудников, низкого качества продукта и т.п. И об этом первоначально знают только непосредственные участники проекта, проблемы видят, друг другу могут тихо выговаривать недовольства. И вариант «гнать в шею» — это хорошо, конечно, но слишком поздно, так как проблемы на проекте уже явно будут. Поэтому и интересен опыт предупреждения/мониторинга работы руководителей проектов.
          +1
          Ну значит неправильно применяется скрам, вы же(всмысле продукт-оунер) на каждой итерации должны иметь что-либо удовлетворяющее требуемому качеству… вообщем это как мне кажется не проблема руководителя, а проблема руководителя руководителей… ну вы поняли… вы как руководитель руководителей похоже хотите формализма, а не доверительных отношений.
          В одном из интервью Стив Джобс так и говорил что люди которые с ним фигачили девайсы и приложения были на одном уровне а т.е. на одной волне и все вкурсе общих проблем, отвечали все. А вы же об иерархичной модели «правления», там и скрам то не нужен по большей части. А метрики — стаж работы, сроки и результаты. Ничего больше. Мониторишь результаты и всё
          И вариант «гнать в шею» никогда не поздно — just business :) хотя странно что человек стал руководителем и не разбирается в предметной области.
        0
        > «Шестерство» не в почете

        А назовите это «арбитражем». Если непосредственный руководитель не может / не хочет, то необходим вариант обращения к вышестоящему.

        А то могут быть всякие странности, от которых анкеты не спасут.

        Вот к примеру — непосредственный руководитель взъелся на двух своих подчиненных, «ваш код плохой вы индусы» (Ц). «Гнобленье» вызывало овации всей команды. Казалось бы — вот оно слабое звено, их надо немедля убирать.

        Разбор полетов показал что в комнате не поделили… кондиционер. Этим двоим «было холодно» при звуках работы аппарата. Банально посадили их в другой кубикл — и код внезапно стал снова хорошим.

        И это в общем-то простая ситуация, бывает куда похлеще.
          +1
          Просто сделайте премию РП функцией от рентабельности проекта\продукта, которым он занимается и все само станет на свои места. А еще лучше при этом удвоить нагрузку на каждого, разгонав половину самыми низкими KPI.

          Если есть проекты, на которых компания инвестирует деньги, а не получает, то за них назначайте отдельные премии обратно пропорциональные затратам.
            +1
            Спасибо за комментарий. Подтвердили вариант личной заинтересованности в успехе проекта. Мы к ней периодически возвращаемся, но пока только на словах, нужно еще получение одобрения и поддержки высших руководителей =)
              0
              А вы и так придете к этому варианту, когда захотите исправить ситуацию. Ибо на позиции менеджера очень удобно делегировать ответственность, оставаясь ни в чем не виноватым. Ничем, кроме прямой мотивации от результата проекта, это не получится исправить.
                0
                Интересный случай когнитивного искажения en.wikipedia.org/wiki/Confirmation_bias
                Наверняка у вас есть сомнения в действенности подобного решения, что небезосновательно, ведь личная заинтересованность работает не всегда. Однако за неимением рациональных критериев оценки вы находите подтверждение своей теории в комментариях из интернета.
                  0
                  Приведите пример для ПМов когда личная заинтересованность не работает.
                    0
                    Все бюрократические органы РФ работают по такой схеме. Результат виден.
                    Когда обманываешь человека и даешь ему ложную цель — он и действует исходя из ложных предпосылок. Банальная психология.
                      0
                      Не впадайте в демагогию. Вопрос касался РП на проектах разработки. Причем тут ограны? Там и близко такого нет.

                      Кстати вы путаете бюрократию и коррупцию.
                0
                А что вы думаете насчет этой статьи? habrahabr.ru/post/152445/
                  –1
                  Я думаю что вводить KPI для программистов — попытка решить проблему которой или вообще нет, или её никто не понимает.
                  Большая часть программистов уже мотивирована писать код и основная задача менеджмента — не мешать им это делать. Можно еще повышать интерес обучениями и поездками на конференцию.

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

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

                  Кстати это не значит, что не надо контролировать продуктивность. В идеале надо иметь софт для учета времени сотрудников, и если кто-то сильно отклоняется от типового поведения программистов, то это повод поговорить «по душам». При этом сотрудник не обязательно должен находится в офисе, можно и удаленных также контролировать. НО НЕЛЬЗЯ ПРИВЯЗЫВАТЬ УРОВЕНЬ ЗП К ЭТОЙ МЕТРИКЕ.
                    0
                    >А вот что действительно нужно мотивировать, так это командную работу. Очень хорошо работают проектные премии в этом случае. При этом премия должна быть значительной.

                    А вот это действительно супер подход, видел такое, работает.
                    0
                    Статья интересна. На самом деле сложности с внедрением KPI существенные. Это одна из причин, почему мы пока так и не пришли к ней в отношении руководителей проектов. Что касается программистов/тестировщиков/БА/дизайнеров, то и в планах нет привязки материального вознаграждения к каким-либо метрикам. Во-первых, зачастую у данных сотрудников нет возможности напрямую влиять на успешность проекта. Во-вторых, есть определенные сложности с объективностью метрик (в статье как раз хорошо это озвучено). В-третьих, у нас не возникало проблем с оценкой работы, т.к. работа более прозрачна, да и фидбэк получаем оперативно. Так что поступаем по правилу не трогать то, что хорошо работает итак.

                    Могу еще отметить интересный факт, который имел место в нашей компании: несколько лет назад РП начали озвучивать на ретроспективах насколько программисты вложились в собственные оценки задач (скажем, оценили в 2 дня, закрыли за неделю). С тех пор оценки задач увеличились, т.е. ребята начали страховаться, но ни чуть ни быстрее работать. И это при том, что на уровень з/п, премии, похвал и поощрений это никак не влияло, да и пофамильно никого не озвучивали. Мы пришли к выводу, что даже простое озвучивание результатов повысило ответственность за оценку. Добавление дополнительной значимости этой оценки могло спровоцировать дополнительно страховку по времени, либо низкое качество работы, лишний стресс разработчикам. Но возможно, мы столкнулись с частный случаем.
                      0
                      Хм хм — вообще говоря этот «коэффициент» еще и индивидуален и очень помогает в планировании.

                      И вот почему — если скажем Вася дает оценку в 24 часа — то это «васиных» 24 часа, Петя может работать медленнее. Тогда в спринт эти часы надо записывать с коэффициентом 0.8 или даже 0.6 — все зависит от того кто будет делать. Что интересно, даже если это оценка Васи и делать тоже будет Вася — то коэффициент тоже будет меньше единицы.

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

                      Планирование — да, станет лучше. А быстрее работать Вася не станет, мотивация же не изменилась.…
                    0
                    Особенно интересно узнать про «Выведенный экономистами показатель не совсем применим к разработчикам: ведь они не могут контролировать отдачу от своей работы и на ходу измерять ее в деньгах. То есть не могут напрямую влиять на показатель.»
                      0
                      Я думаю на материальном стимулировании далеко не уедете. Это будет работтать полгода-год, не больше. Потом народ поймет что это просто замануха и не более.
                        0
                        Это одна из составляющих. Большинство работает за деньги. Помимо этого, также необходимо показывать руководителю проекта в чем конкретно польза от его проекта для всех (социальная ответственность внутри компании и для заказчика) и давать определенную свободу действий (я никогда не понимал жесткого графика для ПМ, сейлов, РП и подобного звена — график человека должен определяться рабочими нуждами).

                        Автору поста: «Шестерство», как вы его называете — нужно вводить, но аккуратно и обдуманно. Хотя бы потому, что вы сами его так называете. Обычный руководитель проекта и исполнитель проекта — оба наемники, каждый со своими функциональными обязанностями. Попытка дистанцироваться от возможных проблем в их взаимодействии — попытка засунуть голову в песок, не более. Если эти 2 человека не срабатываются — подобные сигналы надо ловить и обрабатывать, а не спускать на тормозах. В одной из моих команд так потеряли 2 хороших программистов, сигналы выловили слишком поздно.
                          0
                          Такое наблюдается если сотрудники не видят связи между усилиями и результатами. Но для ПМов прямая привязка к финансовым результатам (в случае заказных проектов разработки ПО) очень даже прозрачную схему дает.
                            0
                            По моему опыту в таком случае ПМ получает свой бонус за счет разработчиков — проект накопит технический долг, или по просту говнокод, в котором им самим же и плавать. А ПМ такой довольный с бонусом. Лично я бы уволился с такого проекта сразу.
                              0
                              Технический долг сам по себе проблемой не является. Проблемы начинаются на поддержке. В итоге при неправильном распределении усилий технический долг в первую очередь съест премию самого ПМа.
                                0
                                В теории. На практике мой личный опыт — это фантастика. Лишить премии ПМ-а за говнокод может только тот, кто выше ПМ и каким-то образом узнал про этот говнокод. А как уже сто раз писалось обычно к начальнику начальника никто не обращяется.
                        +5
                        Смотрите. Вы отмечаете, что руководители проектов находятся в роли наблюдателей. Т.е. если в проекте все хорошо — это их заслуга, если все плохо — не их вина. На мой взгляд, решение такой проблемы есть. Например, вы делаете ответственного за проект только руководителя проекта. Т.е. тестировщик, программист, инженер и т.п. кто входит в команду проекта и находятся под управлением руководителя проекта, не несут персональной ответственности за успешность проекта. В краткосрочной перспективе это плохо, но в более далекой — есть определенные плюсы. Но об этом чуть позже. Так вот, за проект отвечает только руководитель проекта. Если проект провалился, руководитель проекта не может сказать, что его тестировщик плохо сработал. Это личное дело руководителя проекта и тестировщика, т.к. за проект отвечает исключительно его руководитель и только он. При этом его мотивировочная часть зависит не только от успешности персонально его проекта, но всей линии проектов в целом. Т.е. если два руководителя проекта сработали на отлично, а третий провалил все что мог и в сумме линия оказалась убыточна, часть премии по итогам не получают все руководители проекта, а не только главный гад. Тем самым появляется интерес доносить до руководства о проблемах в коллективе, которое руководство может не видеть по тем или иным причинам. Если ты видишь, что человек работает плохо и ты от этого персонально страдаешь, то замалчивать этот факт будет просто невыгодно.

                        Теперь о технических исполнителях. Они замотивированы на участие в проекте. Т.е. человек может за з.п. сидеть и комментировать фотографии в контакте, а может проектировать-тестировать в рамках проекта и получать за это определенный респект. Так вот если исполнитель бестолковый, руководитель проекта будет стараться не брать такого при наборе команды проекта. Балбес или сам поймет бесперспективность такого поведения или будет ковыряться за оклад. Минус такого подхода в том, что понятно будет с кем имеешь дело только через участие в двух-трех проектах.
                          0
                          Вот у вас ситуация-руководитель наладил работу своей команды так, что не требуется его вмешателсьво, это эдакая самоорганизующаяя и самомотивирующаяся команда, и вы при этом решатете что такой руководитель-лишнее звено? Интересно… Если вы едете на машине и не слышите как работает мотор, значит ли это что мотор вообще не нужен?
                          А по поводу того «что вы сделали, чтобы было да» -есть ли у такого руководителя полномочия чтобы что-то поменять? Может ли он увеличить зарплату недовольному? Врятли… Может ли он купить новую мебель и технику, сделать ремонт в офисе, оборудовать зону отдыха? Тоже нет. Ну так а какой смылс тогда с него спрашивать? Дайте ему сначала полномочия а потом спрашивайте.
                            0
                            На самом деле нет цели найти виновных или причину для наказаний и лишений. Одно дело, когда РП наладил работу и следит за процессами и совсем другое, когда он распределил свои обязанности между членами команды, тем самым сняв с себя ответственность и обязанности. На более частном примере это могло привести к тому, что программисты начинали массу времени тратить на общение с заказчиками по решению задач, которые по идее должен был решать РП, не успевать в свои оценки/дедлайны и проч., тестировщики оказывались ответственными за релизы. Никаких сроков, итераций, плановых релизов — в любой момент мог произойти аврал, срочный и внезапный апдейт, добавление супер важной фитчи и все это делалось, команда же только отчитывались о проделанной работе РП. В общей суматохе работа делалась, даже заказчик мог быть доволен, была недовольна команда. У команды сверхнагрузка, недовольство работой РП, нервозность на проекте и зачастую овертаймы, плюс сотрудники прекрасно понимают, что входит в их обязанности и любые дисбалансы радости от работы не добавляли. Это как частный случай, были и другие проблемы, которые возникали и которые оказались известными вышестоящему руководству слишком поздно. Тут стоит учитывать, что зачастую фидбэк о работе команды РП озвучивает вышестоящему руководству, а вот кфидбэк команды РП — редкий случай (нужный ли?!).

                            Стоит отметить, что до определенного времени или, скажем, определенных претендентов, РП у нас работали автономно и кто-то со стороны подключались к проекту только если возникали недовольства со стороны заказчика. Тогда старший РП/СТО и т.п. (в зависимости от проблемы) помогали найти решения проблем и все всех устраивало. В такой ситуации оценка работы РП больше оценивал заказчик с позиции доволен/не доволен (на зп или премию это никак не влияло), оценку работы команды предоставлял руководитель проекта (а тут могли быть и увольнения), отношение команды к РП оставалось неизвестным. Описанная проблема мотивации/мониторинга появилась с ростом компании, вовлечением новых РП, увеличение сложности проектов.
                              0
                              > распределил свои обязанности между членами команды
                              Распределение работы, делегирование полномочий и следовательно отвественности одна из главных задач руководителя). Если разработчики стали напрямую общатся с заказчиком-это же прекрасно, убирается несколько звеньев на пути следования информации, которые неизбежно приводят к ее искажению.
                              А вот отсутствие планирования и срыв сроков-безусловный просчет руководителя. Да и недовльство команды-тоже, тем более что если за овертаймы не доплачивали. Если руководство не знало про овертаймы-это чья вина?) Такое впечатление что у вас руководство живет какой-то своей жизнью а простые смертные своей. У вас удаленная команда? Надо быть ближе к народу)
                                0
                                Кстати об издержках бонусной системы.

                                Если бонус РП напрямую завязан на результат, то у РП появляется отличный стимул вынуждать программистов овертаймить («клиенту надо»). И если эти овертаймы еще и не оплачиваются…

                                Я такие финты ушами наблюдал, получается картинка «сдал-вовремя-получил-бонус-сменил-команду». Особенно если суппорт передается другому РП! И выходит что эпик фейлов нет, сроки отлично, но…

                                И бонусная система таких кадров активно поощряет и продвигает наверх, вот что интересно.

                                А выявляются такие гиганты только случайно — если хватанут слишком для них большой кусок и не сумеют удержаться на грани «выжимаю — разбегаются» длительное время. Или в команду нужны серьезные технари на энричмент / ресерч, которые это погоняло видят и от него бегут. Вот тогда издержки и вылезают наверх за пределы компетентности такого руководителя.
                            +2
                            Как мне кажется, вы не понимаете, что делаете.
                            Вместо выращивания руководителей вы всё сводите к поиску самого слабого звена. Пытаетесь найти виноватых в своей некомпетентности. Работа с людьми начинается с работы над собой. Надо понимать, что тот механизм организации, который вы строите, включает и вас в том числе.
                              0
                              забавная у Вас логика. Что нужно поменять в себе, чтобы другой менеджер стал лучше выполнять свою работу?
                                0
                                Я не знаю, как ответить на этот вопрос в двух предложениях. Есть много аспектов взаимодействия с сотрудниками, а значит много параметров для изменений. Процесс управления также управляем, это же очевидно.
                                  0
                                  Обычно нужно хотя бы перестать быть мудаком. Я не про вас говорю, просто частый пример. Руководитель ведет себя как мудак, в результате мудачество спускается вниз на всех уровнях.
                                    0
                                    Ну пост действительно странный, например:

                                    «1. Не смотря на то, что ретроспективы никто не отменял и у команд оставалась возможность высказать все моменты, мешающие их работе, то влиять на отсутствие реакции на эти пожелания возможности не было.»

                                    Что мешало регулярно просматривать рассылаемые минутки ретроспектив и, обнаружив отсутствие реакции на какие-то пожелания, уточнить с менеджером в чем причина и устранить ее (если выяснится, что она устранима)?
                                      0
                                      Просматривать старшему РП, т.е. руководителю менеджеров проекта? Если да, то это вариант, если в подчинение 2-3 РП и у каждого 1-2 проекта максимум, при этом вышестоящий РП с большего в курсе проектов и/или на нескольких ретроспективах звучит одна и та же проблема. Но даже в таком случае, не думаю, что на ретроспективах народ настолько откровенен, что сможет сказать своему РП, что он, к примеру, слишком мало уделяет внимание проекту и слишком много полномочий делегирует.
                                        0
                                        Да сколько бы проектов ни было — это всего-лишь вопрос небольшого времени, выделяемого раз в две/три недели. Выделять его или нет — вопрос расстановки приоритетов (важно или не важно).

                                        Да, на ретроспективах кто-то прямолинеен / кто-то нет, но если ситуация неблагополучна, то прямо или косвенно это проявится.
                                        Если проявилось, то уж на один проект также можно найти время чтобы поговорить с менеджером и людьми и изучить ситуацию детальнее — это опять таки вопрос расстановки приоритетов.
                                    0
                                    Разделяю эту точку зрения. Добавлю, что менеджеры в вышеописанной ситуации делают то, что от них требуется — отвечают за проект (в смысле получают по шапке или бонусы). А что они еще должны делать? У вас (автора статьи) есть четкие критерии что должен делать менеджер? Внутренний регламент проектного управления например, по которому можно оценивать их деятельность. Если бы был, было бы над чем работать, и не удивляться.
                                      0
                                      Ну к тому что работу надо распределять а полномочия делегировать надо еще прийти…

                                    Only users with full accounts can post comments. Log in, please.