Должны ли задачи даваться как приказы?

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

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

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

ДОПОЛНЕНИЕ: я думаю, что для того, чтобы установить уровень ответов, ОП должен описать уровень в WBS или указать, о чем он думал, задавая этот вопрос. Из многих приведенных здесь ответов я делаю вывод, что многие описывают ситуацию, когда компетентный и опытный технолог спрашивает у менеджера проекта разрешение на выполнение следующей задачи каждые 15 минут 1/2 часа. В своем ответе ниже я описал ситуацию с контролем рабочих пакетов, в которой у вас могут быть сотни действий и задач, и они могут длиться дни, месяцы или даже годы над действительно сложными проектами.

Частью контроля затрат и графика является концепция Документа авторизации работ (WAD). Этот документ, доставляемый команде и/или отдельному ресурсу, представляет собой контрольный приказ, в котором описывается, какая работа выполняется, кем, когда и где, целевые затраты и время, а также способ учета их рабочего времени, например, код(ы) заряда.

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

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

Есть ли польза от ожидания начала? Есть ли плата за ожидание? Как они сравниваются?

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

Для меня было интересным опытом по-настоящему разобраться в том, что происходит в команде. Я понял, что попытка смоделировать очень тесно связанные взаимодействия с зависимостями FF, FS, SF и SS не может дать мне стабильную модель (та, которая не требует постоянного обновления каждую неделю). неважно, что вы делаете на MF, если к пятнице команда выполнила X, Y и Z» (и команда может сказать, что такое X, Y и Z!) предоставила команде возможность более эффективно структурировать свою работу, и я закончилось тем, что мы управляли «недельными фрагментами», с которыми нам было гораздо проще справляться и перепланировать по мере необходимости. Тогда планирование было недельным, и все согласовывались в течение недели. Из-за этого люди знали, сколько «свободного времени» у них есть в течение недели, и могли предложить помощь тем, кто может быть перегружен.

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

В принципе, мне нравится давать командам (и отдельным лицам) свободу действовать и выполнять работу, когда они к ней готовы. Однако могут быть случаи, когда это неуместно:

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

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

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

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

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

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

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

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