Ключевые точки в коммуникации менеджера проектов

    Кто такой менеджер проектов? Этим вопросом задаются все молодые специалисты и те, кто только собирается внедриться в сферу web-менеджмента.

    На вопросы: «Кто такой project manager?», «Каковы обязанности менеджера проектов?» и «Что должен знать проджект менеджер?» можно отвечать бесконечно, так как у каждой компании свои законы и постулаты внутренней работы.

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

    Давайте обсудим, какие же основные принципы менеджера проектов должны быть заложены в коммуникативной зоне ответственности внутри команды и перед самим собой…

    image

    Часть 1. Работа с вашими коллегами-специалистами

    Уважение – ключ к успешной работе над проектом. Уважайте каждого специалиста команды, будьте максимально тактичны и вежливы с ними.

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

    Вообще сроки – это очень сложное понятие в сфере web-разработки, и они у каждого свои. Как минимум в трех вариациях:

    • срок по договору для заказчика
    • срок для разработчика (он отличается от срока договора)
    • срок для себя, чтобы была возможностью выстраивать график работы сотрудника над всеми текущими проектами

    Все сроки нужно помнить, по каждому планировать, исходя из текущей загруженности. Специалисту говорите сроки, комфортные для вас, а клиентам — те, которые комфортны для процесса работы всей проектной команды (с учетом возможных правок).

    Срок сдачи проекта должен быть четко обозначен и нерушим. Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш). Если специалисту все равно и он винит всех вокруг, утверждая, что время было учтено неверно, возможно это сотрудник не вашей команды (частные случаи усложнения проекта или неверного расчета сроков отделом продаж рассматриваются отдельно).

    Решение менеджера проектов – решение компании, это высокая ответственность. Отсюда в работе со специалистами команды разработки вытекают свои нюансы — все принятые решения должны быть структурированными и закономерными, не противоречить друг другу. Вся проектная команда должна понимать: решения, принятые руководителем, не оспариваются на предмет выполнения. Они должны реализовываться.

    Основная задача менеджера проектов – грамотный тайм-менеджмент (если таковой существует в компании) и точная постановка задач для сотрудников (любая неточность в поставленной задаче приведет к последствиям, за которые отвечать только вам). Всегда нужно помнить о контроле и мониторить результаты не реже чем раз в 3-4 часа, в противном случае могут пострадать сроки и качество работы.

    Кстати о том, что касается качества — любые допущенные специалистом ошибки должны оговариваться с ним. Не бывает такого, что во всем виноват только исполнитель, все ситуации нужно разбирать и анализировать. И, сделав выводы, не допускать подобного в дальнейшем.
    Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к негативным результатам. Контакт должен происходить исключительно через менеджера проекта. И не стоит передавать специалистам негативные мысли заказчика, если таковые имеются. Возможно, утром он просто встал не с той ноги, простите ему это и продолжайте свою работу.

    Часть 2. Работа над самим собой

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

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

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

    Еще один шаг — ведение задач (и по проектам, и своих личных — на день, месяц и так далее). Все крупные задания фиксируйте в таскменеджерах — они станут вашими незаменимыми помощниками. Какой именно использовать, решать только вам.

    При работе над конкретным проектом старайтесь расписывать всю информацию отдельно — будут ясны как общая картина, так и частности, вы сможете обнаружить спорные моменты. Данные, полученные по телефону, фиксируйте и согласовывайте с заказчиком по почте. А перед передачей материала разработчикам старайтесь обдумывать каждый комментарий.

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

    Еще хотелось бы сказать о проблемах, которые существуют в любых проектах (проект без проблем невозможен — либо вы отнеслись к нему невнимательно, либо заказчик вообще не смотрел результатов). Всегда старайтесь еще перед стартом предугадать возможные риски. Тогда вы сможете предупредить их в самом начале (путем переговоров с заказчиком) или продумать стратегию работы при их возникновении. А когда проблема все же появляется на пороге вашего проекта, не ищите виноватого — это проще всего. Старайтесь командно найти решение, позволяющее коренным образом изменить ситуацию. Каждый специалист имеет право на ошибку, и каждый должен знать, что может ее озвучить. Потому что его ждет не порицание, а коллективная поддержка.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 33
    • +3
      Вообще-то, по канону, кроме сроков, РП еще должен управлять качеством и бюджетом, а иначе дисбаланс возникает.

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

      З.Ы. Я лично всегда воспринимаю необходимость овертаймов — как личный факап РП
      • 0
        Да, согласен, если описывать весь спектр зоны работ pm-ов, можно и не остановиться вовсе в рассуждениях))

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

        Спасибо за дополнение, всегда рад комментариям и уточнениям)
        • +1

          Я согласен со всем, что написали вы. И это совершенно не согласуется с тем, что написал автор статьи.


          Я лично всегда воспринимаю необходимость овертаймов — как личный факап РП

          Не всегда. Это может быть не факп, если это осознанное решение, принятое в начале проекта.

        • +1
          В целом очень адекватная статья по управлению временем, но по части каждые три часа спрашивать как дела — это думаю лишние, если только задачи не такие короткие, а исполнители не делают это первый раз в жизни.
          Ведь речь идёт о веб разработке — то есть нет ни чего проще чем самому открыть сайт и протыкать функционал. Рабочую копию разработчика расшарить на локалку как бы не очень сложно.
          Или можно камиты посмотреть, если задачи на самом деле короткие то и камититься можно хоть раз в час.
          • 0
            Спасибо. Писал в большинстве своем из опыта приобретённого в работе. Подходить к проектам стараюсь максимально индивидуально и соответственно на каждый случай можно написать свое мини-резюме советов)
            Это не универсальные решения, а скорее мысли, к которым могут прислушаться pm-ы и взять на заметку))
          • +2
            Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш).

            Если немного переформулировать в наши реальности то получается:
            «Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — интерес компании, а не ваш).»
            Так как в статье не увидел связи результата проекта с личными интересами остальных лиц (ПМ и специалистов).
            А если начать именно с этого «Совместить интерес компании с личными интересами работников», то тогда работник и без напоминания готов будет не то что задержаться, а жить на работе.
            • 0
              > Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш).

              На это хочется ответить: если потребуется, начальство должно быть готово компенсировать сверхурочные (так как завершение и успешная сдача проекта — общий интерес компании, не только разработчика).
              • +1

                Сверхурочные – это хорошо, в любой достойной компании всегда должны быть системы мотивации)) Но и ответственный подход к работе должен быть, если косяк по вине специалиста (прожекта или разраба), это необходимо устранить и конечно же максимально быстро)

                • 0

                  Сверхурочные хороши пока это не норма. Поработаешь 7 дней в неделю по 12 часов несколько месяцев и уже никакие деньги не нужны.

                • +1

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


                  Я думаю при такой постановке вопроса ПМ должен быть готов компенсировать издержки из своего кормана. Ведь это общий интерес компании.

                • +1
                  Результат проекта с личными интересами остальных лиц оговаривается в мотивационной схеме компании, которая у каждых своя. Как Вы верно подметили, нужно верно «Совместить интерес компании с личными интересами работников», но эта тема нуждается в подробном рассуждении)))

                  Ну и конечно, разные бывают специалисты, кто-то сказал: «Да сдадим все в четверг на этой неделе, будет идеально», а потом не сдал и ушел, такой подход тоже не очень компетентен. Помимо мотиваций нужен, конечно, еще и старый добрый — энтузиазм, который любому специалисту не позволит сдать плохой результат)
                  • +2

                    Энтузиазм — не замена хорошо поставленному процессу.

                • +2
                  Достаточно использовать несколько правил из теории ограничений:

                  1. Задача должна выполняться в срок и в полном объеме.
                  Требование для сотрудника – необходимо выполнить задачу точно к
                  определенному времени и в соответствии с точно указанной декомпозицией.
                  Требование для руководителя – при постановке цели необходимо
                  указывать время ее выполнения и проводить полную декомпозицию
                  выполнения.

                  2. При возникновении отклонения следует незамедлительное
                  извещение инициатору запроса.

                  Требование для сотрудника – при возникновении отклонения
                  необходимо предотвратить задержку принятия корректирующих действий
                  руководителем.
                  Требование для руководителя – при возникновении отклонения
                  требуется минимизировать время для корректировки декомпозиции
                  выполнения или для постановки новой задачи.

                  3. Знание о невыполнимости задачи в срок не освобождает сотрудника
                  от ответственности за ее выполнение.

                  Требование для сотрудника — предотвратить задержку принятия
                  корректирующих действий руководителем при постановке первоначальной
                  задачи.
                  Требование для руководителя – при непонимании сотрудником
                  поставленной задачи требуется минимизировать время для корректировки
                  декомпозиции выполнения или для постановки новой цели. Необходимо
                  рассмотреть вопрос смены исполнителя.

                  4. Увеличение сущностей при решении задачи запрещено.
                  Минимизация не нужных действий сотрудника.
                  Требование для сотрудника – определить свою цель.
                  Требование для руководителя – определить цель сотруднику.
                  • +1
                    Требование для сотрудника – необходимо выполнить задачу точно к
                    определенному времени и в соответствии с точно указанной декомпозицией.

                    Сотрудник не может быть ответственным за срыв сроков, которые ему назначили. Срок, Объем работ, Ресурсы — у работника ресурсы фиксированы — один человекодень, объем работ вы фиксируете своей "декомпозицией", но вы фиксируете и сроки.


                    Требование для руководителя – при постановке цели необходимо
                    указывать время ее выполнения и проводить полную декомпозицию выполнения.

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


                    Требование для сотрудника – при возникновении отклонения
                    необходимо предотвратить задержку принятия корректирующих действий
                    руководителем.

                    Так не делают ни в армии/полиции ни даже на конвеере. У каждого есть должностная инструкция, руководитель должен вмешиваться только тогда, когда чего-то нет даже в инструкции.


                    Требование для руководителя – при возникновении отклонения
                    требуется минимизировать время для корректировки декомпозиции
                    выполнения или для постановки новой задачи.

                    Вы пробовали так вообще руководить более чем 2-я подчиненными которые делают что-то сложнее чем кубики по цветам расскладывать?


                    Требование для сотрудника — предотвратить задержку принятия
                    корректирующих действий руководителем при постановке первоначальной
                    задачи.

                    Ага. Фактически только что создали лазейку для фактического байкота указаний руководителя либо тотальный абьюз для руководства.


                    Требование для руководителя – при непонимании сотрудником
                    поставленной задачи требуется минимизировать время для корректировки
                    декомпозиции выполнения или для постановки новой цели. Необходимо
                    рассмотреть вопрос смены исполнителя.

                    А лучше сменить руководителя сразу. Он поставил некорректно задачу, дал неверную оценку — вся проблема в нем.


                    Минимизация не нужных действий сотрудника.
                    Требование для сотрудника – определить свою цель.
                    Требование для руководителя – определить цель сотруднику.

                    Так они оба определяют одно и то же. Т.е. компания за одну и ту же работу платит дважды. Один раз руководителю, другой раз сотруднику.


                    PS: Это вы вообще что изобразили?

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

                      Сроки исполнения всегда заранее согласовываются с сотрудником.

                      Руководитель занимающийся декомпозицией — это бесполезное существо. Вместо руководства...

                      Что такое руководство? Это постановка задач и контроль их выполнения. (это если кратко). Декомпозиция задачи до уровня исполнителя — главная задача руководителя! Иначе задача может быть «не так» понята и не выполнена в срок.

                      руководитель должен вмешиваться только тогда, когда чего-то нет даже в инструкции

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

                      Вы пробовали так вообще руководить...

                      Я руководил отделом разработки (20 сотрудников) и ИТ-проектами (100 сотрудников) в крупной международной компании.

                      А лучше сменить руководителя сразу

                      Руководитель всегда прав!

                      Так они оба определяют одно и то же.

                      Второй помогает первому. Это разные задачи. И конечно, у каждого есть и другие…
                      • 0
                        Сроки исполнения всегда заранее согласовываются с сотрудником.

                        Согласовывать можно с кем-то вышестоящим или равным по должности. В противном случае идет продавливание своего мнения в 9 случаев из 10.


                        Это постановка задач и контроль их выполнения. (это если кратко). Декомпозиция задачи до уровня
                        исполнителя — главная задача руководителя!

                        Декомпозиция (определение того как нужно выполнить задачу) — задача исполнителя. Задача руководителя — обозначить задачу и критерии выполнения. Руководитель определяет что и фиксирует когда, а исполнитель решает как.


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

                        PM или руководитель? PM совсем не обязательно должен иметь подчиненных. Если речь о руководителе, то если за каждым чихом подчиненные должны бегать к руководителю — то руководитель не справляется со своей ролью.


                        Я руководил отделом разработки (20 сотрудников) и ИТ-проектами (100 сотрудников) в крупной
                        международной компании.
                        требуется минимизировать время для корректировки декомпозиции
                        выполнения или для постановки новой задачи.

                        Вы занимались "полной декомпозицией" для каждого из 100 сотрудников? "при возникновении отклонения" 100 сотрудников приходили к вам для "принятия корректирующих действий руководителем"?


                        Каковы были показатели до вас и после в "ИТ-проектах" крупной компанией? (как я понял вы ни там ни там больше не работаете)


                        Руководитель всегда прав!

                        Надеюсь это сакрказм.


                        Второй помогает первому. Это разные задачи. И конечно, у каждого есть и другие…

                        Судя по вашему описанию задачи одинаковые (может быть дело в формулировке). С точки зрения владельца компании такой руководитель — лишнее звено.

                        • 0
                          Все мои предыдущие утверждения исходили от лица руководителя проектов, а не от лица операционного руководителя. Возможно, что недопонимание в этом.
                          Руководитель определяет что и фиксирует когда, а исполнитель решает как.

                          Исполнитель предлагает «как», а руководитель согласовывает и совместно определяются метрики и сроки по ним.
                          Вы занимались «полной декомпозицией» для каждого из 100 сотрудников?

                          Я занимался разработкой планов проекта, планов управления проектом, планов управления рисками проекта,… согласованием указанных планов с участниками проекта и другими задачами РМ по ходу проекта. (см PMBOK)
                          Каковы были показатели до вас и после

                          Последние три года не было факапов.
                          Надеюсь это сакрказм.

                          Без юмора в нашем деле нельзя!

                          В современной компании почти любой операционный руководитель — лишнее звено! Современные технологии управления сотрудниками и проектное управление позволяют резко уменьшать количество «обычных» руководителей, приводя компании к более плоской структуре. Конечно, это встречает сильный отпор операционного менеджмента...)
                  • +1
                    Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к негативным результатам. Контакт должен происходить исключительно через менеджера проекта. И не стоит передавать специалистам негативные мысли заказчика, если таковые имеются. Возможно, утром он просто встал не с той ноги, простите ему это и продолжайте свою работу.

                    Еще предложения есть по ухудшению улучшнию испорченного телефончика?
                    • +1
                      Это амортизирующий буфер (если менеджер компетентно отрабатывает свой хлеб) :)
                      • +1

                        Этот амортизирующий буфер менее компетентен в разработке и/или в бизнесе заказчика, чем разработчики и заказчик.

                        • +1
                          > Этот амортизирующий буфер менее компетентен в разработке и/или в бизнесе заказчика, чем разработчики и заказчик.

                          Вы бы хотели избавиться от всех менеджеров проектов в сфере разработке ПО и чтобы все заказчики и разработчики работали исключительно напрямую. В теории звучит интересно… на практике — за что же тогда получают деньги эти самые менеджеры? За что-то все-таки получают.
                          • +1
                            Вы бы хотели избавиться от всех менеджеров проектов

                            Судя по тому, что написано в статье у вас строго не верное представление о том, чем должен заниматься менеджер проектов. Позвольте задать вам наводящий вопрос: "если заказчик и разработчик — представители одной и той же компании, то чем занимается PM"? И еще один: "Если речь идет не о разработке ПО, то чем занимается PM"?


                            В теории звучит интересно… на практике — за что же тогда получают деньги эти самые менеджеры?

                            За управление проектами. Т.е. это управляющий портфолио проектов. У каждого проекта есть жизненный цикл. В нем есть этапы. PM следит за тем чтобы проект проходил через эти этапы гладко и контролирует, чтобы ни на каком из них не было задержек, и решает проблемы если таковые возникают. И координирует свою и в целом работу с ответственными за разные этапы в жизни проекта.


                            За что-то все-таки получают.

                            Вы, верно подметили. За что-то получают, но не за то, что вы думали.

                            • +1
                              > PM следит за тем чтобы проект проходил через эти этапы гладко и контролирует, чтобы ни на каком из них не было задержек, и решает проблемы если таковые возникают. И координирует свою и в целом работу с ответственными за разные этапы в жизни проекта.

                              Согласен, в таком случае мы и не спорим получается)
                              • +1
                                1. РМ управляет рисками проекта. Если бы не было рисков, то РМ был бы не нужен;
                                2. РМ координирует работу команды проекта;
                                3. РМ выполняет роль фасилитатора при коммуникациях между заказчиками и командой проекта.
                                • +1
                                  1. Ok. Одного проекта или нескольких?
                                  2. Выполняет работу тимлида?
                                  3. Выполняет работу Product Owner-a или BA или может быть Account Manager?
                                  • +1
                                    1. Обычно нескольких.
                                    2. В более широком смысле. В команде проекта участвуют не только разработчики ПО.
                                    3. Ближе к Account Manager, но для всех участников проекта и стейкхолдеров.
                                    • 0
                                      1. В более широком смысле. В команде проекта участвуют не только разработчики ПО.

                                      Ок. Согласен.


                                      1. РМ выполняет роль фасилитатора при коммуникациях между заказчиками и командой проекта.
                                      2. Ближе к Account Manager, но для всех участников проекта и стейкхолдеров.

                                      Либо вы изначально слишком узко определили роль либо два определения не сочетаются. Либо считаем, что заказчик — часть комманды в более широком смысле и тогда нет смысла выделять общение с заказчиком в отдельную статью, либо PM становится фронтменом и тогда он — bottleneck для проекта.


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

                                      • 0
                                        Если убрать это звено, то тогда РМ-ом становиться сам заказчик.
                                        • 0
                                          Если убрать это звено, то тогда РМ-ом становиться сам заказчик.

                                          Не убрать, а оставить выполнять свои функции. Координацию и управление проектом.

                                          • 0
                                            Что тогда по вашему — управление проектом?
                      • +1
                        Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к
                        негативным результатам.

                        Прощай Agile и Scrum, здравствуй waterfall.

                        • +1
                          Всегда нужно помнить о контроле и мониторить результаты не реже чем раз в 3-4 часа

                          Это менеджер проектов или менеджер проекта? Чекпоинты каждые 3-4 часа скорее похоже на микроменеджмент.


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

                          Вы серьезно? Менеджер проектов управляет проектами или ресурсами?


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

                          А походы в туалет они должны с ним согласовывать?


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

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


                          Принимайте решения быстро (наиболее верные из них — те, что не обдумывались часами, а были осмысленно
                          приняты в сжатые сроки)

                          Ага. Вот откуда берутся сорваные сроки. Собственно все верно. Разработчики не всегда виноваты в их срывах, а скорее те, кто по быстрому все решил.

                          • 0
                            Дико спорная статья практически без аргументов и без статистики.

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