Ситуация: Мы небольшой поставщик полностью распределенных программных решений. Мы обслуживаем несколько клиентов, и, учитывая наш размер, это означает, что каждый член команды работает в нескольких оплачиваемых командах с частичной занятостью. Обычно 2 таких команды на человека, чтобы минимизировать переключение контекста. Каждый работает в общей сложности 30-40 часов в неделю, варьируя от недели к неделе в зависимости от доступной работы и обычных задач. Все команды оценивают работу, используя баллы или часы, но их определение зависит от клиента, равно как и методология (Kanban или Scrum, с различными итерациями) и инструменты (Jira, PT и V1).
Проблема: В совокупности состав команды и ее исполнение никогда не бывают достаточно последовательными, чтобы поддерживать типичные показатели скорости или эффективности, что, в свою очередь, затрудняет создание надежных целей для клиентов (например, где мы окажемся в невыполненной работе к заданным датам, предполагаемым сметы работ). Мы делаем все возможное, чтобы поддерживать состав команды в течение нескольких месяцев ради преемственности, но аспекты, упомянутые выше, очевидно, приводят к труднопрогнозируемым результатам и, вероятно, скрывают другие проблемы.
Итак, как мы можем стать лучше, желательно без радикальных изменений в том, как мы ведем бизнес?
Подходы, которые приходили нам в голову до сих пор, имеют важные подводные камни:
Мы фиксируем наши входные данные (например, определение сюжетных точек), методологию и инструментарий и итерируем до тех пор, пока не достигнем с ними максимально возможного результата. Подвох, как мы его видим: риск взаимоотношений с клиентами, поскольку у большинства из них уже есть команды, методологии и инструменты, с которыми мы сосуществуем.
Мы придумываем метрики скорости для каждого человека, которые можно агрегировать, перекрестно ссылаясь на вид работы, размер команды и т. Д., По мере того, как мы получаем понимание с течением времени. Попался: судя по нашим исследованиям, это кажется спекулятивным, и блокировка может занять целую вечность.
Мы стабилизируем наши команды, чтобы включить более традиционные показатели скорости, методы оценки и планирования. Подсказка: риск развития и поддержания бизнеса, поскольку это уменьшит нашу способность смешивать и подбирать команды в ответ на изменения бюджета и новую работу.
Какие из них звучат наиболее эффективно? Или смесь? Любые другие идеи?
Я согласен с тем, что предложил @barnaby. Вариант 3 здесь является предпочтительным решением, однако он будет работать только при наличии поддержки на организационном уровне. Есть несколько способов избежать упомянутых вами "попавшихся"
Подсказка: риск развития и поддержания бизнеса, поскольку это уменьшит нашу способность смешивать и подбирать команды в ответ на изменения бюджета и новую работу.
Внедрите Scrum в свои команды. Объясните, что это означает для внешних заинтересованных сторон, и убедитесь, что они уважают Scrum и его принципы. Как только ваша команда освоится и поймет, что означает Scrum, ваша задача — защитить Scrum-команду.
Во время спринтов ваша работа заключается в том, чтобы не допустить нарушения согласованной цели спринта. Однако это не означает, что вы не можете быть Agile. Например, многие организации проводят спринты продолжительностью 1 или 2 недели. Так что, если за пределами вашей Scrum-команды возникает что-то, над чем нужно поработать как можно скорее, Scrum может это учесть. Просто это нужно делать контролируемым образом (посредством планирования спринта).
Без более подробной информации трудно дать совет относительно «изменения бюджета». Как часто меняются бюджеты проектов и почему?
Scrum может работать только в том случае, если Scrum-команда защищена и не прерывается. Это может быть сложно во многих организациях, которые могут использовать более традиционные стили управления проектами. Возможно, аналогичные примеры могут помочь переубедить внутренних скептиков, например, подход Джеффа Безоса, согласно которому «в команде никогда не должно быть больше людей, чем могут выдержать две большие пиццы». Однако это более тесно связано с организационными изменениями, чем с управлением проектами.
Вариант 3 — это тот, на который стоит пойти, и я объясню, как избежать «подводного камня».
Мы стабилизируем наши команды, чтобы включить более традиционные показатели скорости, методы оценки и планирования. Подсказка: риск развития и поддержания бизнеса, поскольку это уменьшит нашу способность смешивать и подбирать команды в ответ на изменения бюджета и новую работу.
Наличие стабильных команд не снижает вашей гибкости при реагировании на изменения бюджета и новую работу. Это улучшает его, потому что повышается эффективность команд (например, у них может быть усовершенствованный процесс адаптации изменений приоритетов).
Передавайте работу командам, а не формируйте новые команды для конкретных проектов.
Если бюджет изменится, измените приоритет невыполненной работы, чтобы команды отражали его. Если появляется новая работа, определите ее приоритет по отношению к другой работе, которая уже есть в бэклоге команды.
Это может означать, что команда работает более чем над одним проектом одновременно. Это не идеально, так как переключение контекста снизит их эффективность. Тем не менее, вы можете смягчить это в некоторой степени:
Самые большие проблемы будут связаны с такими вещами, как механизм выставления счетов и восприятие клиентов (например, им может понадобиться «выделенная команда»). Если у вас хорошие отношения со своими клиентами, вы можете объяснить им преимущества стабильной команды, и, надеюсь, они будут готовы пойти на компромисс в других областях.
Даниэль
Тодд А. Джейкобс
Барт ван Инген Шенау