Предыстория: крупная консалтинговая компания хочет лучше использовать время своих консультантов, когда они находятся в перерывах между заданиями. План состоит в том, чтобы иметь внутреннюю концепцию управления внутренними проектами, направленную на создание ценности для компании (демонстрации продаж, внутренние продукты и т. д.), а также дать консультантам возможность получить новые навыки (например, получить опыт работы в качестве Scrum-менеджера). Владелец).
Использование Scrum для этих проектов дает смешанные результаты, так как сотрудники покидают проекты почти сразу же после получения оплачиваемого задания, что делает невозможным достижение стабильной скорости.
Эти обстоятельства также повышают требования к простоте входа в эти проекты, например, читабельность кода, документирование принятия решений и т. д. Один из рисков заключается в том, что это может увеличить каскадный характер этих проектов, чего я очень хотел бы. избежать
Так как же управлять этими проектами? Методы проекта использовать? Подводные камни, которых следует избегать, и как? Любая помощь будет принята с благодарностью
Scrum предполагает фиксированную команду, поэтому, как сказал другой респондент, неудивительно, что Scrum вас разочаровывает. И говоря, что вы хотите больше «использовать» людей, вы опровергаете ложные предположения, что вы можете на 100% планировать людей, тем не менее, я согласен с целью помочь людям, не работающим с клиентом, найти способы сосредоточиться на других ценных занятиях.
Это больше похоже на такие понятия, как «FedEx Days» или «80% времени». По сути, придумывая рекомендации для людей, но не пытаясь создавать проекты с датами, поставками или обязательствами. Возьмите Дэниела Пинкса "Драйв". Это также может дать вам некоторые идеи о том, как вы можете мотивировать и направлять консультантов на скамейке запасных.
Я работал в консалтинговых компаниях, и по моему опыту, мы всегда были рады работать вместе, когда возвращались домой. Это дало нам возможность сделать наш бизнес лучше и учиться друг у друга, и задача руководства заключалась в том, чтобы найти способы облегчить это для нас, а также поддержать клиентов.
Что касается более конкретных инструментов, вы можете попробовать доску Канбан, но я бы серьезно спросил, зачем вам нужно измерять скорость (скорость или пропускную способность). Может быть, вам просто нужен видимый индикатор или способ передачи, или способ увидеть, что будет дальше, когда вы вернетесь. Создавайте инструмент, который вам подходит, а не управляйте им процессом. Удачи
Я не уверен, что Scrum — правильный инструмент для работы в этом случае. Аналогичный случай можно найти в разработке бесплатного программного обеспечения с открытым исходным кодом, где вклад носит непостоянный и разнородный характер.
Вероятно, вам больше подошла бы система без определенных итераций, но с непрерывным развертыванием и переменной скоростью, вроде Канбана .
Не существует панацеи, которая решит проблему вашей организации, заключающуюся в том, что она не будет инвестировать во внутренние проекты. Чтобы успешно выполнить проект, нужно реалистично подобрать персонал и выполнять его с помощью этого персонала. Если у вас есть люди, которые просто убивают время, они не будут заинтересованы в своем краткосрочном задании с неизвестной продолжительностью и не будут преданы ему.
Я бы предположил, что использование методологии итеративного проекта на самом деле вредит вам.
Почему? Гибкие методологии полагаются на постоянную команду с постоянной достижимой скоростью. Если у вас есть команда из 5 человек, и за 3-недельный цикл (даже спринт) вы теряете 2 человек, вы теряете контроль над этой скоростью и вам придется либо недоделать, либо изменить временные рамки цикла разработки.
Я считаю, что ваши проекты могли бы быть более успешными, если бы вы выделили меньшую команду (2 человека?) для написания ваших требований и создания некоторых макетов пользовательского интерфейса (например) в очень небольших рабочих пакетах, а затем, когда вы получаете разработчика на скамейке, вы назначаете ему или ей небольшой объем работы, которую ваша организация может взять на себя, чтобы позволить им закончить. В наших гибких и негибких проектах (а в некоторых и в гибридах каждого из них) мы делаем наши определяемые и тестируемые рабочие пакеты настолько «выполнимыми», насколько это возможно менее чем за неделю. Все, что превышает 3-5 дней работы, подвергается сомнению в надежде быть разбитым.
Я думаю, что лучший способ для вас - сначала создать список невыполненных работ, попытаться составить представление о том, чего именно вы хотите достичь с помощью этого инструмента. Как только у вас накопится отставание, как упоминалось выше, постарайтесь иметь 2 человека на борту на длительный срок. Эти ребята должны разбираться в дизайне/требованиях. Затем вы можете продолжать добавлять людей вокруг них. Для внутреннего проекта ни у одной компании в мире не будет ни ресурсов, ни денег. Так что делайте демо время от времени, чтобы информировать заинтересованные стороны и использовать людей в пуле.
Scrum предлагает иметь фиксированную команду, поэтому будет сложно отслеживать скорость вашего проекта.
я бы предложил разделить задачи на наименьший размер, который можно выполнить в течение дня, а затем применить цикл разработки в стиле Канбан. это поможет сдвинуть работу с мертвой точки, а также вы сможете следить за индивидуальным вкладом.
Дэйв Хиллиер
магнус.вестром