Управление небольшими проектами

Question

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

Я управляю небольшой командой (4 человека) с очень маленькими проектами. Обычно один инженер работает по специальному проекту. Несколько раз один инженер работал над несколькими проектами с разными приоритетами (проекты довольно часто переключались в состояние «на удержание» в течение нескольких дней).

Так что мой специфичный:

• Малые проекты с коротким сроком службы (1 недели до 2 месяцев в целом)
• Проекты, как правило, не разделяемые между инженерами
• Количество проектов может быть 2-3 в несколько раз выше, чем число людей (некоторые проекты часто находятся в ожидании)
• Существует 2 долгосрочных проекта с наименьшим приоритетом, которые могут совместно использоваться инженерами

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

Может быть, есть готовая методология для таких проектов, которые я никогда не слышал.

спасибо.

Answer 1

Предлагаю посмотреть на Канбан. Вот некоторые ссылки для изучения:

Kanban (the book) on Amazon

David Anderson's site

Some Kanban info on InfoQ

The Limited Work In Progress Society

Answer 2

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

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

Answer 3

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

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

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

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

Получение проекта за дверью и в производстве более быстро улучшит поток денежных средств/пропускную способность вашей компании. См. throughput accounting.

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

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