На вопросы: «Кто такой project manager?», «Каковы обязанности менеджера проектов?» и «Что должен знать проджект менеджер?» можно отвечать бесконечно, так как у каждой компании свои законы и постулаты внутренней работы.
В своей же статье я предлагаю рассмотреть только тысячную часть всего объема информации, которую должен знать менеджер проектов любой веб-студии страны. То, о чем тут пишется, не является догмой, это просто мой опыт вкупе со знаниями.
Давайте обсудим, какие же основные принципы менеджера проектов должны быть заложены в коммуникативной зоне ответственности внутри команды и перед самим собой…
Часть 1. Работа с вашими коллегами-специалистами
Уважение – ключ к успешной работе над проектом. Уважайте каждого специалиста команды, будьте максимально тактичны и вежливы с ними.
Менеджер проектов должен всегда знать, чем занят сотрудник, работающий над проектом. И это должен понимать разработчик — чтобы уведомлять менеджера, если ему нужно переключиться на другую задачу (например, поставленную руководителем его отдела). Вы не можете отследить каждый шаг своих коллег (вы не машина), и тут на помощь приходит понимание — специалист ставит вас в известность при изменении своего рабочего графика. Но вы все равно должны его контролировать, следить за сроками выполнения задач (ведь когда срок срывается, а специалист разводит руками, перед заказчиком оправдываться вам).
Вообще сроки – это очень сложное понятие в сфере web-разработки, и они у каждого свои. Как минимум в трех вариациях:
- срок по договору для заказчика
- срок для разработчика (он отличается от срока договора)
- срок для себя, чтобы была возможностью выстраивать график работы сотрудника над всеми текущими проектами
Все сроки нужно помнить, по каждому планировать, исходя из текущей загруженности. Специалисту говорите сроки, комфортные для вас, а клиентам — те, которые комфортны для процесса работы всей проектной команды (с учетом возможных правок).
Срок сдачи проекта должен быть четко обозначен и нерушим. Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш). Если специалисту все равно и он винит всех вокруг, утверждая, что время было учтено неверно, возможно это сотрудник не вашей команды (частные случаи усложнения проекта или неверного расчета сроков отделом продаж рассматриваются отдельно).
Решение менеджера проектов – решение компании, это высокая ответственность. Отсюда в работе со специалистами команды разработки вытекают свои нюансы — все принятые решения должны быть структурированными и закономерными, не противоречить друг другу. Вся проектная команда должна понимать: решения, принятые руководителем, не оспариваются на предмет выполнения. Они должны реализовываться.
Основная задача менеджера проектов – грамотный тайм-менеджмент (если таковой существует в компании) и точная постановка задач для сотрудников (любая неточность в поставленной задаче приведет к последствиям, за которые отвечать только вам). Всегда нужно помнить о контроле и мониторить результаты не реже чем раз в 3-4 часа, в противном случае могут пострадать сроки и качество работы.
Кстати о том, что касается качества — любые допущенные специалистом ошибки должны оговариваться с ним. Не бывает такого, что во всем виноват только исполнитель, все ситуации нужно разбирать и анализировать. И, сделав выводы, не допускать подобного в дальнейшем.
Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к негативным результатам. Контакт должен происходить исключительно через менеджера проекта. И не стоит передавать специалистам негативные мысли заказчика, если таковые имеются. Возможно, утром он просто встал не с той ноги, простите ему это и продолжайте свою работу.
Часть 2. Работа над самим собой
Процесс самоорганизации для менеджера проектов очень важен — как только Вы научитесь управлять своими обязанностями, в работе получится и все остальное.
Начинайте свой рабочий день с планирования. Я приезжаю на работу за полчаса до ее начала, лишь немногим раньше остальных, но это время позволяет мне распланировать свой день, определить наиболее и менее приоритетные задачи. Держите себя в рамках, старайтесь добиться не только дневного планирования, но и выполнять его в рамках каждой из задач, выделяйте и ограничивайте время.
Наиболее сложные задачи расписывайте для себя подробно, чтобы взглянуть на них со стороны (возможно, появится новое решение, которого Вы и не ожидали).
Еще один шаг — ведение задач (и по проектам, и своих личных — на день, месяц и так далее). Все крупные задания фиксируйте в таскменеджерах — они станут вашими незаменимыми помощниками. Какой именно использовать, решать только вам.
При работе над конкретным проектом старайтесь расписывать всю информацию отдельно — будут ясны как общая картина, так и частности, вы сможете обнаружить спорные моменты. Данные, полученные по телефону, фиксируйте и согласовывайте с заказчиком по почте. А перед передачей материала разработчикам старайтесь обдумывать каждый комментарий.
Принимайте решения быстро (наиболее верные из них — те, что не обдумывались часами, а были осмысленно приняты в сжатые сроки). Это сэкономит время и улучшит результат.
Еще хотелось бы сказать о проблемах, которые существуют в любых проектах (проект без проблем невозможен — либо вы отнеслись к нему невнимательно, либо заказчик вообще не смотрел результатов). Всегда старайтесь еще перед стартом предугадать возможные риски. Тогда вы сможете предупредить их в самом начале (путем переговоров с заказчиком) или продумать стратегию работы при их возникновении. А когда проблема все же появляется на пороге вашего проекта, не ищите виноватого — это проще всего. Старайтесь командно найти решение, позволяющее коренным образом изменить ситуацию. Каждый специалист имеет право на ошибку, и каждый должен знать, что может ее озвучить. Потому что его ждет не порицание, а коллективная поддержка.
Комментарии (33)
SbWereWolf
18.04.2017 12:48+1В целом очень адекватная статья по управлению временем, но по части каждые три часа спрашивать как дела — это думаю лишние, если только задачи не такие короткие, а исполнители не делают это первый раз в жизни.
Ведь речь идёт о веб разработке — то есть нет ни чего проще чем самому открыть сайт и протыкать функционал. Рабочую копию разработчика расшарить на локалку как бы не очень сложно.
Или можно камиты посмотреть, если задачи на самом деле короткие то и камититься можно хоть раз в час.
TutmeeAgency
18.04.2017 17:23Спасибо. Писал в большинстве своем из опыта приобретённого в работе. Подходить к проектам стараюсь максимально индивидуально и соответственно на каждый случай можно написать свое мини-резюме советов)
Это не универсальные решения, а скорее мысли, к которым могут прислушаться pm-ы и взять на заметку))
dyhmichail
18.04.2017 14:10+2Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш).
Если немного переформулировать в наши реальности то получается:
«Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — интерес компании, а не ваш).»
Так как в статье не увидел связи результата проекта с личными интересами остальных лиц (ПМ и специалистов).
А если начать именно с этого «Совместить интерес компании с личными интересами работников», то тогда работник и без напоминания готов будет не то что задержаться, а жить на работе.
zharikovpro
18.04.2017 15:03> Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш).
На это хочется ответить: если потребуется, начальство должно быть готово компенсировать сверхурочные (так как завершение и успешная сдача проекта — общий интерес компании, не только разработчика).TutmeeAgency
18.04.2017 18:11+1Сверхурочные – это хорошо, в любой достойной компании всегда должны быть системы мотивации)) Но и ответственный подход к работе должен быть, если косяк по вине специалиста (прожекта или разраба), это необходимо устранить и конечно же максимально быстро)
boblenin
18.04.2017 20:44Сверхурочные хороши пока это не норма. Поработаешь 7 дней в неделю по 12 часов несколько месяцев и уже никакие деньги не нужны.
boblenin
18.04.2017 20:44+1Мастерство высшего класса. Вы сорвали срок, а расплачиваться должны все кроме вас. Разработчики тем, что работают вместо отдыха, руководство — тем, что теряют выручку.
Я думаю при такой постановке вопроса ПМ должен быть готов компенсировать издержки из своего кормана. Ведь это общий интерес компании.
TutmeeAgency
18.04.2017 17:56+1Результат проекта с личными интересами остальных лиц оговаривается в мотивационной схеме компании, которая у каждых своя. Как Вы верно подметили, нужно верно «Совместить интерес компании с личными интересами работников», но эта тема нуждается в подробном рассуждении)))
Ну и конечно, разные бывают специалисты, кто-то сказал: «Да сдадим все в четверг на этой неделе, будет идеально», а потом не сдал и ушел, такой подход тоже не очень компетентен. Помимо мотиваций нужен, конечно, еще и старый добрый — энтузиазм, который любому специалисту не позволит сдать плохой результат)
WizardryIB
18.04.2017 14:10+2Достаточно использовать несколько правил из теории ограничений:
1. Задача должна выполняться в срок и в полном объеме.
Требование для сотрудника – необходимо выполнить задачу точно к
определенному времени и в соответствии с точно указанной декомпозицией.
Требование для руководителя – при постановке цели необходимо
указывать время ее выполнения и проводить полную декомпозицию
выполнения.
2. При возникновении отклонения следует незамедлительное
извещение инициатору запроса.
Требование для сотрудника – при возникновении отклонения
необходимо предотвратить задержку принятия корректирующих действий
руководителем.
Требование для руководителя – при возникновении отклонения
требуется минимизировать время для корректировки декомпозиции
выполнения или для постановки новой задачи.
3. Знание о невыполнимости задачи в срок не освобождает сотрудника
от ответственности за ее выполнение.
Требование для сотрудника — предотвратить задержку принятия
корректирующих действий руководителем при постановке первоначальной
задачи.
Требование для руководителя – при непонимании сотрудником
поставленной задачи требуется минимизировать время для корректировки
декомпозиции выполнения или для постановки новой цели. Необходимо
рассмотреть вопрос смены исполнителя.
4. Увеличение сущностей при решении задачи запрещено.
Минимизация не нужных действий сотрудника.
Требование для сотрудника – определить свою цель.
Требование для руководителя – определить цель сотруднику.boblenin
18.04.2017 20:58+1Требование для сотрудника – необходимо выполнить задачу точно к
определенному времени и в соответствии с точно указанной декомпозицией.Сотрудник не может быть ответственным за срыв сроков, которые ему назначили. Срок, Объем работ, Ресурсы — у работника ресурсы фиксированы — один человекодень, объем работ вы фиксируете своей "декомпозицией", но вы фиксируете и сроки.
Требование для руководителя – при постановке цели необходимо
указывать время ее выполнения и проводить полную декомпозицию выполнения.Руководитель занимающийся декомпозицией — это бесполезное существо. Вместо руководства он выполняет функцию бизнесс аналитика, плюс изображает, что знает лучше исполнителя то КАК ему надо выполнять его работу.
Требование для сотрудника – при возникновении отклонения
необходимо предотвратить задержку принятия корректирующих действий
руководителем.Так не делают ни в армии/полиции ни даже на конвеере. У каждого есть должностная инструкция, руководитель должен вмешиваться только тогда, когда чего-то нет даже в инструкции.
Требование для руководителя – при возникновении отклонения
требуется минимизировать время для корректировки декомпозиции
выполнения или для постановки новой задачи.Вы пробовали так вообще руководить более чем 2-я подчиненными которые делают что-то сложнее чем кубики по цветам расскладывать?
Требование для сотрудника — предотвратить задержку принятия
корректирующих действий руководителем при постановке первоначальной
задачи.Ага. Фактически только что создали лазейку для фактического байкота указаний руководителя либо тотальный абьюз для руководства.
Требование для руководителя – при непонимании сотрудником
поставленной задачи требуется минимизировать время для корректировки
декомпозиции выполнения или для постановки новой цели. Необходимо
рассмотреть вопрос смены исполнителя.А лучше сменить руководителя сразу. Он поставил некорректно задачу, дал неверную оценку — вся проблема в нем.
Минимизация не нужных действий сотрудника.
Требование для сотрудника – определить свою цель.
Требование для руководителя – определить цель сотруднику.Так они оба определяют одно и то же. Т.е. компания за одну и ту же работу платит дважды. Один раз руководителю, другой раз сотруднику.
PS: Это вы вообще что изобразили?
WizardryIB
19.04.2017 09:19+1Сотрудник не может быть ответственным за срыв сроков, которые ему назначили.
Сроки исполнения всегда заранее согласовываются с сотрудником.
Руководитель занимающийся декомпозицией — это бесполезное существо. Вместо руководства...
Что такое руководство? Это постановка задач и контроль их выполнения. (это если кратко). Декомпозиция задачи до уровня исполнителя — главная задача руководителя! Иначе задача может быть «не так» понята и не выполнена в срок.
руководитель должен вмешиваться только тогда, когда чего-то нет даже в инструкции
РМ управляет рисками проекта. Без данного ограничения управление рисками будет выполняться с задержкой, что приведет к срыву сроков проекта.
Вы пробовали так вообще руководить...
Я руководил отделом разработки (20 сотрудников) и ИТ-проектами (100 сотрудников) в крупной международной компании.
А лучше сменить руководителя сразу
Руководитель всегда прав!
Так они оба определяют одно и то же.
Второй помогает первому. Это разные задачи. И конечно, у каждого есть и другие…boblenin
20.04.2017 16:23Сроки исполнения всегда заранее согласовываются с сотрудником.
Согласовывать можно с кем-то вышестоящим или равным по должности. В противном случае идет продавливание своего мнения в 9 случаев из 10.
Это постановка задач и контроль их выполнения. (это если кратко). Декомпозиция задачи до уровня
исполнителя — главная задача руководителя!Декомпозиция (определение того как нужно выполнить задачу) — задача исполнителя. Задача руководителя — обозначить задачу и критерии выполнения. Руководитель определяет что и фиксирует когда, а исполнитель решает как.
РМ управляет рисками проекта. Без данного ограничения управление рисками будет выполняться с
задержкой, что приведет к срыву сроков проекта.PM или руководитель? PM совсем не обязательно должен иметь подчиненных. Если речь о руководителе, то если за каждым чихом подчиненные должны бегать к руководителю — то руководитель не справляется со своей ролью.
Я руководил отделом разработки (20 сотрудников) и ИТ-проектами (100 сотрудников) в крупной
международной компании.
требуется минимизировать время для корректировки декомпозиции
выполнения или для постановки новой задачи.Вы занимались "полной декомпозицией" для каждого из 100 сотрудников? "при возникновении отклонения" 100 сотрудников приходили к вам для "принятия корректирующих действий руководителем"?
Каковы были показатели до вас и после в "ИТ-проектах" крупной компанией? (как я понял вы ни там ни там больше не работаете)
Руководитель всегда прав!
Надеюсь это сакрказм.
Второй помогает первому. Это разные задачи. И конечно, у каждого есть и другие…
Судя по вашему описанию задачи одинаковые (может быть дело в формулировке). С точки зрения владельца компании такой руководитель — лишнее звено.
WizardryIB
21.04.2017 11:34Все мои предыдущие утверждения исходили от лица руководителя проектов, а не от лица операционного руководителя. Возможно, что недопонимание в этом.
Руководитель определяет что и фиксирует когда, а исполнитель решает как.
Исполнитель предлагает «как», а руководитель согласовывает и совместно определяются метрики и сроки по ним.
Вы занимались «полной декомпозицией» для каждого из 100 сотрудников?
Я занимался разработкой планов проекта, планов управления проектом, планов управления рисками проекта,… согласованием указанных планов с участниками проекта и другими задачами РМ по ходу проекта. (см PMBOK)
Каковы были показатели до вас и после
Последние три года не было факапов.
Надеюсь это сакрказм.
Без юмора в нашем деле нельзя!
В современной компании почти любой операционный руководитель — лишнее звено! Современные технологии управления сотрудниками и проектное управление позволяют резко уменьшать количество «обычных» руководителей, приводя компании к более плоской структуре. Конечно, это встречает сильный отпор операционного менеджмента...)
keenondrums
18.04.2017 16:47+1Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к негативным результатам. Контакт должен происходить исключительно через менеджера проекта. И не стоит передавать специалистам негативные мысли заказчика, если таковые имеются. Возможно, утром он просто встал не с той ноги, простите ему это и продолжайте свою работу.
Еще предложения есть поухудшениюулучшнию испорченного телефончика?zharikovpro
18.04.2017 18:16+1Это амортизирующий буфер (если менеджер компетентно отрабатывает свой хлеб) :)
boblenin
18.04.2017 20:02+1Этот амортизирующий буфер менее компетентен в разработке и/или в бизнесе заказчика, чем разработчики и заказчик.
zharikovpro
18.04.2017 20:05+1> Этот амортизирующий буфер менее компетентен в разработке и/или в бизнесе заказчика, чем разработчики и заказчик.
Вы бы хотели избавиться от всех менеджеров проектов в сфере разработке ПО и чтобы все заказчики и разработчики работали исключительно напрямую. В теории звучит интересно… на практике — за что же тогда получают деньги эти самые менеджеры? За что-то все-таки получают.boblenin
18.04.2017 20:23+1Вы бы хотели избавиться от всех менеджеров проектов
Судя по тому, что написано в статье у вас строго не верное представление о том, чем должен заниматься менеджер проектов. Позвольте задать вам наводящий вопрос: "если заказчик и разработчик — представители одной и той же компании, то чем занимается PM"? И еще один: "Если речь идет не о разработке ПО, то чем занимается PM"?
В теории звучит интересно… на практике — за что же тогда получают деньги эти самые менеджеры?
За управление проектами. Т.е. это управляющий портфолио проектов. У каждого проекта есть жизненный цикл. В нем есть этапы. PM следит за тем чтобы проект проходил через эти этапы гладко и контролирует, чтобы ни на каком из них не было задержек, и решает проблемы если таковые возникают. И координирует свою и в целом работу с ответственными за разные этапы в жизни проекта.
За что-то все-таки получают.
Вы, верно подметили. За что-то получают, но не за то, что вы думали.
zharikovpro
19.04.2017 00:03+1> PM следит за тем чтобы проект проходил через эти этапы гладко и контролирует, чтобы ни на каком из них не было задержек, и решает проблемы если таковые возникают. И координирует свою и в целом работу с ответственными за разные этапы в жизни проекта.
Согласен, в таком случае мы и не спорим получается)
WizardryIB
19.04.2017 09:25+11. РМ управляет рисками проекта. Если бы не было рисков, то РМ был бы не нужен;
2. РМ координирует работу команды проекта;
3. РМ выполняет роль фасилитатора при коммуникациях между заказчиками и командой проекта.boblenin
19.04.2017 16:43+1- Ok. Одного проекта или нескольких?
- Выполняет работу тимлида?
- Выполняет работу Product Owner-a или BA или может быть Account Manager?
WizardryIB
20.04.2017 11:38+11. Обычно нескольких.
2. В более широком смысле. В команде проекта участвуют не только разработчики ПО.
3. Ближе к Account Manager, но для всех участников проекта и стейкхолдеров.boblenin
20.04.2017 15:57- В более широком смысле. В команде проекта участвуют не только разработчики ПО.
Ок. Согласен.
- РМ выполняет роль фасилитатора при коммуникациях между заказчиками и командой проекта.
- Ближе к Account Manager, но для всех участников проекта и стейкхолдеров.
Либо вы изначально слишком узко определили роль либо два определения не сочетаются. Либо считаем, что заказчик — часть комманды в более широком смысле и тогда нет смысла выделять общение с заказчиком в отдельную статью, либо PM становится фронтменом и тогда он — bottleneck для проекта.
Почему-то на пост-советском пространстве часто используется схема когда PM — это звено-изолятор между заказчиком и коммандой в широком смысле. Иногда такая схема может работать, но часто это способ играть в испорченый телефон и в конечном итоге срывать регулярно сроки, делать не то, что надо и разрушать нормальные деловые отношения.
WizardryIB
21.04.2017 11:37Если убрать это звено, то тогда РМ-ом становиться сам заказчик.
boblenin
21.04.2017 20:04Если убрать это звено, то тогда РМ-ом становиться сам заказчик.
Не убрать, а оставить выполнять свои функции. Координацию и управление проектом.
boblenin
18.04.2017 20:00+1Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к
негативным результатам.Прощай Agile и Scrum, здравствуй waterfall.
boblenin
18.04.2017 20:10+1Всегда нужно помнить о контроле и мониторить результаты не реже чем раз в 3-4 часа
Это менеджер проектов или менеджер проекта? Чекпоинты каждые 3-4 часа скорее похоже на микроменеджмент.
Менеджер проектов должен всегда знать, чем занят сотрудник, работающий над проектом.
Вы серьезно? Менеджер проектов управляет проектами или ресурсами?
И это должен понимать разработчик — чтобы уведомлять менеджера, если ему нужно переключиться на другую
задачу (например, поставленную руководителем его отдела).А походы в туалет они должны с ним согласовывать?
Но вы все равно должны его контролировать, следить за сроками выполнения задач (ведь когда срок срывается,
а специалист разводит руками, перед заказчиком оправдываться вам).Вам не оправдываться надо, а исправлять ситуацию. Определить почему оценки сроков были не верными и решить как избежать этого в будующем. А вообще надо заранее выяснять есть ли затыки по задачам у каждого разработчика, хотя это не для PM-а вообще вопрос, а для тимлида или даже техлида.
Принимайте решения быстро (наиболее верные из них — те, что не обдумывались часами, а были осмысленно
приняты в сжатые сроки)Ага. Вот откуда берутся сорваные сроки. Собственно все верно. Разработчики не всегда виноваты в их срывах, а скорее те, кто по быстрому все решил.
morincer
Вообще-то, по канону, кроме сроков, РП еще должен управлять качеством и бюджетом, а иначе дисбаланс возникает.
И в целом, основная задача менеджера проектов уж никак не тайм-менеджмент и уж точно не теребить каждые три часа разработчика, а выстраивать и обеспечивать эффективные коммуникации. И тогда и инфа о статусе задач будет у того, у кого нужно и тогда, когда нужно, и требования будут будут пониматься однозначно, да и оценки сроков будут реалистичные.
З.Ы. Я лично всегда воспринимаю необходимость овертаймов — как личный факап РП
TutmeeAgency
Да, согласен, если описывать весь спектр зоны работ pm-ов, можно и не остановиться вовсе в рассуждениях))
На своем опыте убедился, что есть рабочие моменты, требующие неусыпного контроля промежуточных результатов, чтобы вовремя прийти к ожидаемым итогам и не сорвать работы. Но это все очень индивидуально, как для компании, так и для команды)
Спасибо за дополнение, всегда рад комментариям и уточнениям)
boblenin
Я согласен со всем, что написали вы. И это совершенно не согласуется с тем, что написал автор статьи.
Не всегда. Это может быть не факп, если это осознанное решение, принятое в начале проекта.