Comments 33
И в целом, основная задача менеджера проектов уж никак не тайм-менеджмент и уж точно не теребить каждые три часа разработчика, а выстраивать и обеспечивать эффективные коммуникации. И тогда и инфа о статусе задач будет у того, у кого нужно и тогда, когда нужно, и требования будут будут пониматься однозначно, да и оценки сроков будут реалистичные.
З.Ы. Я лично всегда воспринимаю необходимость овертаймов — как личный факап РП
На своем опыте убедился, что есть рабочие моменты, требующие неусыпного контроля промежуточных результатов, чтобы вовремя прийти к ожидаемым итогам и не сорвать работы. Но это все очень индивидуально, как для компании, так и для команды)
Спасибо за дополнение, всегда рад комментариям и уточнениям)
Я согласен со всем, что написали вы. И это совершенно не согласуется с тем, что написал автор статьи.
Я лично всегда воспринимаю необходимость овертаймов — как личный факап РП
Не всегда. Это может быть не факп, если это осознанное решение, принятое в начале проекта.
Ведь речь идёт о веб разработке — то есть нет ни чего проще чем самому открыть сайт и протыкать функционал. Рабочую копию разработчика расшарить на локалку как бы не очень сложно.
Или можно камиты посмотреть, если задачи на самом деле короткие то и камититься можно хоть раз в час.
Это не универсальные решения, а скорее мысли, к которым могут прислушаться pm-ы и взять на заметку))
Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш).
Если немного переформулировать в наши реальности то получается:
«Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — интерес компании, а не ваш).»
Так как в статье не увидел связи результата проекта с личными интересами остальных лиц (ПМ и специалистов).
А если начать именно с этого «Совместить интерес компании с личными интересами работников», то тогда работник и без напоминания готов будет не то что задержаться, а жить на работе.
Сверхурочные – это хорошо, в любой достойной компании всегда должны быть системы мотивации)) Но и ответственный подход к работе должен быть, если косяк по вине специалиста (прожекта или разраба), это необходимо устранить и конечно же максимально быстро)
Мастерство высшего класса. Вы сорвали срок, а расплачиваться должны все кроме вас. Разработчики тем, что работают вместо отдыха, руководство — тем, что теряют выручку.
Я думаю при такой постановке вопроса ПМ должен быть готов компенсировать издержки из своего кормана. Ведь это общий интерес компании.
Ну и конечно, разные бывают специалисты, кто-то сказал: «Да сдадим все в четверг на этой неделе, будет идеально», а потом не сдал и ушел, такой подход тоже не очень компетентен. Помимо мотиваций нужен, конечно, еще и старый добрый — энтузиазм, который любому специалисту не позволит сдать плохой результат)
1. Задача должна выполняться в срок и в полном объеме.
Требование для сотрудника – необходимо выполнить задачу точно к
определенному времени и в соответствии с точно указанной декомпозицией.
Требование для руководителя – при постановке цели необходимо
указывать время ее выполнения и проводить полную декомпозицию
выполнения.
2. При возникновении отклонения следует незамедлительное
извещение инициатору запроса.
Требование для сотрудника – при возникновении отклонения
необходимо предотвратить задержку принятия корректирующих действий
руководителем.
Требование для руководителя – при возникновении отклонения
требуется минимизировать время для корректировки декомпозиции
выполнения или для постановки новой задачи.
3. Знание о невыполнимости задачи в срок не освобождает сотрудника
от ответственности за ее выполнение.
Требование для сотрудника — предотвратить задержку принятия
корректирующих действий руководителем при постановке первоначальной
задачи.
Требование для руководителя – при непонимании сотрудником
поставленной задачи требуется минимизировать время для корректировки
декомпозиции выполнения или для постановки новой цели. Необходимо
рассмотреть вопрос смены исполнителя.
4. Увеличение сущностей при решении задачи запрещено.
Минимизация не нужных действий сотрудника.
Требование для сотрудника – определить свою цель.
Требование для руководителя – определить цель сотруднику.
Требование для сотрудника – необходимо выполнить задачу точно к
определенному времени и в соответствии с точно указанной декомпозицией.
Сотрудник не может быть ответственным за срыв сроков, которые ему назначили. Срок, Объем работ, Ресурсы — у работника ресурсы фиксированы — один человекодень, объем работ вы фиксируете своей "декомпозицией", но вы фиксируете и сроки.
Требование для руководителя – при постановке цели необходимо
указывать время ее выполнения и проводить полную декомпозицию выполнения.
Руководитель занимающийся декомпозицией — это бесполезное существо. Вместо руководства он выполняет функцию бизнесс аналитика, плюс изображает, что знает лучше исполнителя то КАК ему надо выполнять его работу.
Требование для сотрудника – при возникновении отклонения
необходимо предотвратить задержку принятия корректирующих действий
руководителем.
Так не делают ни в армии/полиции ни даже на конвеере. У каждого есть должностная инструкция, руководитель должен вмешиваться только тогда, когда чего-то нет даже в инструкции.
Требование для руководителя – при возникновении отклонения
требуется минимизировать время для корректировки декомпозиции
выполнения или для постановки новой задачи.
Вы пробовали так вообще руководить более чем 2-я подчиненными которые делают что-то сложнее чем кубики по цветам расскладывать?
Требование для сотрудника — предотвратить задержку принятия
корректирующих действий руководителем при постановке первоначальной
задачи.
Ага. Фактически только что создали лазейку для фактического байкота указаний руководителя либо тотальный абьюз для руководства.
Требование для руководителя – при непонимании сотрудником
поставленной задачи требуется минимизировать время для корректировки
декомпозиции выполнения или для постановки новой цели. Необходимо
рассмотреть вопрос смены исполнителя.
А лучше сменить руководителя сразу. Он поставил некорректно задачу, дал неверную оценку — вся проблема в нем.
Минимизация не нужных действий сотрудника.
Требование для сотрудника – определить свою цель.
Требование для руководителя – определить цель сотруднику.
Так они оба определяют одно и то же. Т.е. компания за одну и ту же работу платит дважды. Один раз руководителю, другой раз сотруднику.
PS: Это вы вообще что изобразили?
Сотрудник не может быть ответственным за срыв сроков, которые ему назначили.
Сроки исполнения всегда заранее согласовываются с сотрудником.
Руководитель занимающийся декомпозицией — это бесполезное существо. Вместо руководства...
Что такое руководство? Это постановка задач и контроль их выполнения. (это если кратко). Декомпозиция задачи до уровня исполнителя — главная задача руководителя! Иначе задача может быть «не так» понята и не выполнена в срок.
руководитель должен вмешиваться только тогда, когда чего-то нет даже в инструкции
РМ управляет рисками проекта. Без данного ограничения управление рисками будет выполняться с задержкой, что приведет к срыву сроков проекта.
Вы пробовали так вообще руководить...
Я руководил отделом разработки (20 сотрудников) и ИТ-проектами (100 сотрудников) в крупной международной компании.
А лучше сменить руководителя сразу
Руководитель всегда прав!
Так они оба определяют одно и то же.
Второй помогает первому. Это разные задачи. И конечно, у каждого есть и другие…
Сроки исполнения всегда заранее согласовываются с сотрудником.
Согласовывать можно с кем-то вышестоящим или равным по должности. В противном случае идет продавливание своего мнения в 9 случаев из 10.
Это постановка задач и контроль их выполнения. (это если кратко). Декомпозиция задачи до уровня
исполнителя — главная задача руководителя!
Декомпозиция (определение того как нужно выполнить задачу) — задача исполнителя. Задача руководителя — обозначить задачу и критерии выполнения. Руководитель определяет что и фиксирует когда, а исполнитель решает как.
РМ управляет рисками проекта. Без данного ограничения управление рисками будет выполняться с
задержкой, что приведет к срыву сроков проекта.
PM или руководитель? PM совсем не обязательно должен иметь подчиненных. Если речь о руководителе, то если за каждым чихом подчиненные должны бегать к руководителю — то руководитель не справляется со своей ролью.
Я руководил отделом разработки (20 сотрудников) и ИТ-проектами (100 сотрудников) в крупной
международной компании.
требуется минимизировать время для корректировки декомпозиции
выполнения или для постановки новой задачи.
Вы занимались "полной декомпозицией" для каждого из 100 сотрудников? "при возникновении отклонения" 100 сотрудников приходили к вам для "принятия корректирующих действий руководителем"?
Каковы были показатели до вас и после в "ИТ-проектах" крупной компанией? (как я понял вы ни там ни там больше не работаете)
Руководитель всегда прав!
Надеюсь это сакрказм.
Второй помогает первому. Это разные задачи. И конечно, у каждого есть и другие…
Судя по вашему описанию задачи одинаковые (может быть дело в формулировке). С точки зрения владельца компании такой руководитель — лишнее звено.
Руководитель определяет что и фиксирует когда, а исполнитель решает как.
Исполнитель предлагает «как», а руководитель согласовывает и совместно определяются метрики и сроки по ним.
Вы занимались «полной декомпозицией» для каждого из 100 сотрудников?
Я занимался разработкой планов проекта, планов управления проектом, планов управления рисками проекта,… согласованием указанных планов с участниками проекта и другими задачами РМ по ходу проекта. (см PMBOK)
Каковы были показатели до вас и после
Последние три года не было факапов.
Надеюсь это сакрказм.
Без юмора в нашем деле нельзя!
В современной компании почти любой операционный руководитель — лишнее звено! Современные технологии управления сотрудниками и проектное управление позволяют резко уменьшать количество «обычных» руководителей, приводя компании к более плоской структуре. Конечно, это встречает сильный отпор операционного менеджмента...)
Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к негативным результатам. Контакт должен происходить исключительно через менеджера проекта. И не стоит передавать специалистам негативные мысли заказчика, если таковые имеются. Возможно, утром он просто встал не с той ноги, простите ему это и продолжайте свою работу.
Еще предложения есть по
Этот амортизирующий буфер менее компетентен в разработке и/или в бизнесе заказчика, чем разработчики и заказчик.
Вы бы хотели избавиться от всех менеджеров проектов
Судя по тому, что написано в статье у вас строго не верное представление о том, чем должен заниматься менеджер проектов. Позвольте задать вам наводящий вопрос: "если заказчик и разработчик — представители одной и той же компании, то чем занимается PM"? И еще один: "Если речь идет не о разработке ПО, то чем занимается PM"?
В теории звучит интересно… на практике — за что же тогда получают деньги эти самые менеджеры?
За управление проектами. Т.е. это управляющий портфолио проектов. У каждого проекта есть жизненный цикл. В нем есть этапы. PM следит за тем чтобы проект проходил через эти этапы гладко и контролирует, чтобы ни на каком из них не было задержек, и решает проблемы если таковые возникают. И координирует свою и в целом работу с ответственными за разные этапы в жизни проекта.
За что-то все-таки получают.
Вы, верно подметили. За что-то получают, но не за то, что вы думали.
2. РМ координирует работу команды проекта;
3. РМ выполняет роль фасилитатора при коммуникациях между заказчиками и командой проекта.
- Ok. Одного проекта или нескольких?
- Выполняет работу тимлида?
- Выполняет работу Product Owner-a или BA или может быть Account Manager?
2. В более широком смысле. В команде проекта участвуют не только разработчики ПО.
3. Ближе к Account Manager, но для всех участников проекта и стейкхолдеров.
- В более широком смысле. В команде проекта участвуют не только разработчики ПО.
Ок. Согласен.
- РМ выполняет роль фасилитатора при коммуникациях между заказчиками и командой проекта.
- Ближе к Account Manager, но для всех участников проекта и стейкхолдеров.
Либо вы изначально слишком узко определили роль либо два определения не сочетаются. Либо считаем, что заказчик — часть комманды в более широком смысле и тогда нет смысла выделять общение с заказчиком в отдельную статью, либо PM становится фронтменом и тогда он — bottleneck для проекта.
Почему-то на пост-советском пространстве часто используется схема когда PM — это звено-изолятор между заказчиком и коммандой в широком смысле. Иногда такая схема может работать, но часто это способ играть в испорченый телефон и в конечном итоге срывать регулярно сроки, делать не то, что надо и разрушать нормальные деловые отношения.
Общение заказчика со специалистом строго запрещено — их прямой контакт в 90% случаев приведет к
негативным результатам.
Прощай Agile и Scrum, здравствуй waterfall.
Всегда нужно помнить о контроле и мониторить результаты не реже чем раз в 3-4 часа
Это менеджер проектов или менеджер проекта? Чекпоинты каждые 3-4 часа скорее похоже на микроменеджмент.
Менеджер проектов должен всегда знать, чем занят сотрудник, работающий над проектом.
Вы серьезно? Менеджер проектов управляет проектами или ресурсами?
И это должен понимать разработчик — чтобы уведомлять менеджера, если ему нужно переключиться на другую
задачу (например, поставленную руководителем его отдела).
А походы в туалет они должны с ним согласовывать?
Но вы все равно должны его контролировать, следить за сроками выполнения задач (ведь когда срок срывается,
а специалист разводит руками, перед заказчиком оправдываться вам).
Вам не оправдываться надо, а исправлять ситуацию. Определить почему оценки сроков были не верными и решить как избежать этого в будующем. А вообще надо заранее выяснять есть ли затыки по задачам у каждого разработчика, хотя это не для PM-а вообще вопрос, а для тимлида или даже техлида.
Принимайте решения быстро (наиболее верные из них — те, что не обдумывались часами, а были осмысленно
приняты в сжатые сроки)
Ага. Вот откуда берутся сорваные сроки. Собственно все верно. Разработчики не всегда виноваты в их срывах, а скорее те, кто по быстрому все решил.
Ключевые точки в коммуникации менеджера проектов