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

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

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

Вот характеристики моей компании:

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

Учитывая эти особенности, кажется, что управление каждым проектом с помощью Scrum не будет работать хорошо, поскольку в любой момент времени существует много многозадачности и текучести между наборами навыков, необходимых для одного проекта по сравнению с другим. Канбан может работать лучше, поскольку мы просто сосредоточимся на незавершенной работе, но меня беспокоит необходимость должным образом поддерживать «глобальное представление» всех задач, а также следить за соблюдением сроков для каждого проекта. Я вижу применение водопадного подхода к более простым, ориентированным на процесс задачам, но это явно не сработает для проектов НИОКР.

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

Что касается инструментов, мы используем Jira для назначения задач и управления ими, но не все проекты управляются с одинаковым уровнем интеграции Jira. Многие люди по-прежнему полагаются на MS Project, Excel и/или блокнот.

В качестве дополнительного примечания: каждый раз, когда я пытался обсудить подходы к управлению проектами с членами команды, они очень скептически и цинично относились к принятию какого-либо «процесса». Обычно я скрываю от них, что мы даже что-то пробуем. Например, у многих закатываются глаза, когда я произношу слова «Спринт» и «Ретроспектива». Это немного выходит за рамки этого вопроса, но все же является фактором успеха любого подхода.

+1 за закатывание глаз "Спринт". Я так хорошо знаком с рефлекторным противодействием любому процессу, кроме «Я сделаю это, когда это будет сделано».

Ответы (2)

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

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

Общий вид

Вы можете поддерживать глобальное представление нескольких проектов следующим образом:

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

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

Хронология

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

Большинство онлайн-приложений Kanban имеют либо встроенную диаграмму выгорания, либо дополнительные средства для этого. В настоящее время мы используем Trello с Plus For Trello , и это дает нам представление о количестве оставшихся усилий в конкретном проекте.

Раньше я использовал Jira с Greenhopper, и мне это очень нравилось. Однако у него более жесткая структура, чем та, с которой кажется удобной вашей команде. Я бы посоветовал взглянуть на Trello и настроить простую доску для отслеживания задач.

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

Удачи в управлении всеми вашими проектами!

Как Uservoice использует Канбан: community.uservoice.com/blog/…

В конечном счете, ваша текущая рабочая среда и ограничения вообще не способствуют разработке программного обеспечения.

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

  1. Работайте с небольшими группами с большим количеством проектов, группируя похожие проекты или объединяя проекты в фреймворки, поддерживающие множество проектов.
  2. Сосредоточьтесь на чем-то одном сразу. Если у вас их много в работе для одной команды, вы только создадите иллюзию того, что работы еще больше. Это ничего не даст и будет держать вас в вечном цикле. Заставьте бизнес расставлять приоритеты в проектах. Может быть, вы можете называть проекты эпиками, но работать только над одним проектом одновременно. Закончите его, затем переходите к следующему. Почитайте проект Феникс.
  3. Создавайте выделенные совмещенные команды и еще одну команду из удаленных сотрудников.
  4. Пока не будет ясного пути, не начинайте проект. Задача бизнеса — дать вам четкий путь и финансирование для реализации проекта, заставить их взять на себя эту ответственность и перестать отнимать ее у них.
  5. Здесь нет никаких правил, только бизнес-процессы. Время на проект, разбитое на капзатраты и эксплуататоры, соответствует всем требованиям, с которыми я когда-либо сталкивался.

С удовольствием обсудим дальше...

Спасибо за ваши идеи. Несколько уточняющих моментов: мы в основном не софтверная компания, больше аппаратного обеспечения и консалтинга/знаний, хотя мы также разрабатываем некоторое программное обеспечение. Моя проблема заключается в том, что я не знаю, как сосредоточиться на чем-то одном (по крайней мере, на уровне компании/команды/макро). Финансирование, контрактные обязательства и набор навыков команды не способствуют этому. По той же причине мы не можем строго разделить команды на совместные и удаленные. Дополнительная сложность... контрактные правила иногда требуют операционных затрат вместо капитальных. Цените любые дальнейшие идеи.
Не стесняйтесь, пишите мне по электронной почте ☺, сегодня я преподаю класс Professional Scrum Foundations, но могу ответить позже...