Я руковожу командой разработчиков из 8 человек. У нас здесь есть несколько продакт-менеджеров, и они часто спрашивают, как получить хорошее представление о том, какие бесплатные ресурсы для разработчиков у нас есть.
Другие части бизнеса имеют общий календарь Outlook, но я считаю, что для разработчиков это сводится к микроуправлению. Всегда есть над чем работать, но это вопрос приоритетов. Я не хочу, чтобы продакт-менеджеры подвергали сомнению тот факт, что кто-то рефакторит сборку или проводит проверку кода; предлагая заменить эту работу какой-либо проектной работой.
Мы используем Trello для назначения людей для запросов в службу поддержки и т. д., но это не дает представления о том, насколько хорошо мы можем обеспечить ресурсы для многонедельных/месячных проектов.
Кто-нибудь знает что-нибудь хорошо работающее?
Похоже, вы пытаетесь решить не ту проблему, рассматривая ее как проблему индивидуальной доступности. Скорее всего, это связано с тем, что у вас странная матричная организация, основанная не на проектных командах или планировании ресурсов команды , а, по-видимому, на заведомо неудачном вопросе «Джо сейчас занят?» методология.
Ваша команда из восьми человек должна иметь переменный, но в целом предсказуемый потенциал. В Scrum это ваш диапазон скоростей за некоторый исторический период. Независимо от того, следуете ли вы Scrum или нет, такая историческая оценка будущих возможностей часто является вашим наиболее точным руководством для определения того, может ли команда иметь возможность для дополнительной работы.
Кроме того, не следует ожидать, что каждая проектная группа будет переключаться между контекстами без видимого и дорогостоящего снижения производительности. В вашей организации явно не хватает как владельца продукта для каждого проекта, так и масштабируемой структуры, которая может расставлять приоритеты в работе над несколькими проектами. В результате каждый относится к своим личным приоритетам как к приоритетам, а когда все является «высшим приоритетом», то ничего не делается.
Ваш организационный процесс явно нуждается в доработке. Рассмотрим Scrum, Kanban и доступные масштабируемые фреймворки, такие как SAFe или Scrum-of-Scrums. Серебряной пули не существует, но почти любая формальная структура будет лучше, чем то, что организация делает сейчас.
Я был в похожей ситуации до того, как мы перешли на полный Scrum с фактическим планированием с командами и владельцами продукта, чтобы определить бэклог спринта. Что мы делали, чтобы смягчить постоянный поток запросов к команде разработчиков (20 разработчиков, 7 QA), было следующим:
Это очень грубый способ (и немного медленный), опять же, не включающий в себя переговоры разработчиков с продакт-менеджерами о сокращении функций, когда это возможно, и все эти прекрасные вещи Scrum, но это может помочь в промежутке. Все, что мы пытались сделать заранее, только с PM и тимлидами.
Если возможно, я бы посоветовал перейти на полный Scrum, если у вас есть хороший кандидат на ПО и вы только начинаете с нуля. Требуется некоторое время, чтобы наладить скрам-мероприятия и правильно спланировать их, но это действительно окупается.
Роланд Тифенбруннер