Ich versuche herauszufinden, wie ich dieses Problem am besten lösen kann. Wir haben einen Pool von Ressourcen, die an Projekten, BAU und Produktionsunterstützung arbeiten. PMs nutzen diese Ressourcen in einer agilen Methodik und melden die Zeit in JIRA auf ihren Tickets für Produktfunktionen. Das Problem ist, dass ich die Zeit dieser Ressourcen mit MS Project Server an Corporate melden muss.
Projektzeitpläne sind schwierig zu verwalten, da Ressourcen während des gesamten Projekts Tickets ein- und ausbuchen oder eine Ressource einen PM kontaktieren kann, um zu sagen, dass sie an ihrem Projekt gearbeitet hat, aber keine Einzelposten gesehen hat, um ihre Zeit zu melden. Die PMs gehen rein, erstellen die Aufgabe, fordern Stunden an, die in einer T-Shirt-Größe benötigt werden (die sich ändern kann).
Wie kann ich einen Standardprozess und/oder Verfahren und eine Art Projektplan erstellen, um die Berichterstattung über Arbeit, Ressourcen und Budget für ein sich ständig änderndes Projekt zu bewältigen, mit einem Prozess, der es mir ermöglicht, Ressourcen spontan anzupassen, ob täglich, wöchentlich, oder stündlich?
Okay, ein paar Vorschläge:
Scrum ist darauf ausgelegt, mit dedizierten Teams mit bekannter Geschwindigkeit zu arbeiten. Dies erleichtert die Vorhersage der Kapazität des Teams in jedem Sprint und erleichtert somit die Planung.
Idealerweise arbeitet ein Scrum-Team an einer Sache nach der anderen, aber in Ihrer Situation kann es notwendig sein, sie an einer Mischung aus Projekt/BAU/Support arbeiten zu lassen. Einige Scrum-Teams widmen BAU/Support einen Prozentsatz ihrer Kapazität. Sie können beispielsweise sagen, dass 20 % der Kapazität des Teams für BAU/Support verfügbar sein werden und der Rest für Projektarbeit aufgewendet wird. Wenn Sie dies tun, wird es einfacher, die Projekte zu planen. Angenommen, Sie haben ein Team mit 5 Mitgliedern. In jedem Sprint können Sie ein Teammitglied für BAU/Support einsetzen, während die verbleibenden 4 Mitglieder die Projektarbeit übernehmen.
Um Scrum erfolgreich einzusetzen, benötigen Sie eine gewisse Stabilität der Anforderungen. Ein Scrum-Team hat während eines Sprints Stabilität und akzeptiert dann Änderungen (z. B. neue Arbeit, Änderungen der Prioritäten usw.) an den Sprintgrenzen. Wenn sich die Dinge in Ihrer Organisation sehr schnell ändern, könnten Sie eine kurze Sprintdauer von beispielsweise 1 Woche in Betracht ziehen.
Wenn es nicht möglich ist, die Anforderungsstabilität auch nur für eine Woche zu erreichen, sollten Sie stattdessen Kanban verwenden. Dies ist ein kontinuierlicher Arbeitsfluss, der auf einem Taskboard verfolgt wird, anstatt in Sprints mit fester Länge zu arbeiten.
Eine weitere Überlegung wert ist es, Teammitgliedern zu erlauben, ihre eigenen Aufgaben in JIRA zu erstellen. Auf diese Weise müssen sie die Projektmanager nicht ständig bitten, dies für sie zu tun. Es ist möglich, JIRA so zu konfigurieren, dass alle neuen Aufgaben/Probleme eine Warn-E-Mail an eine bestimmte Rolle generieren. Sie können es so konfigurieren, dass die Projektmanager mit diesem Ansatz benachrichtigt werden, wenn neue Aufgaben/Probleme hinzugefügt werden.
Sie haben Probleme, weil Ihr JIRA-Ticketing nicht mit Ihrem realen Prozess übereinstimmt. Darüber hinaus versuchen Sie, Ihr Ticketing-System zu Ihrer Quelle der Wahrheit für Zeitberichte in einem separaten System zu machen, wodurch eine (möglicherweise unnötige) indirekte Ebene eingeführt wird.
Langfristig sollten Sie Ihren Prozess so anpassen, dass die von Ihnen verwendeten Tools an Ihren realen Arbeitsabläufen ausgerichtet sind. Kurzfristig sollten Sie die verfügbaren Funktionen Ihrer Tools nutzen, um Zeitdaten direkt zu erfassen.
Verwenden Sie die „Arbeit protokollieren“-Funktion von JIRA, um die für Tickets aufgewendeten Stunden zu verfolgen. Wenn Ihr Prozess sehr chaotisch ist und das Ziel darin besteht, die aufgewendete Zeit zu verfolgen, anstatt JIRA zu verwenden, um den Fortschritt oder die Fertigstellung von Ergebnissen zu verfolgen, erstellen Sie einfach einige High-Level-Tickets (z. B. Epics), die als Bucket pro Projekt verwendet werden können Ressourcen, denen sie ihre Zeit widmen können. Dies ist eindeutig nicht The Right Thing to Do® , kann aber in pragmatischer Hinsicht nützlich sein.
JIRA hat einige begrenzte integrierte Zeitberichte, aber Sie sollten sich auch die Vielfalt der Plugins ansehen, die für diese Art von Funktionalität verfügbar sind. Ob eine davon für Ihren Anwendungsfall geeignet ist, ist höchst subjektiv.
Bedenken Sie auch, dass Sie in JIRA nicht an Zeitberichte gebunden sind. Sie können JIRA für das Ticketing verwenden und MS Project Server mit einigen Buckets pro Projekt verwenden, um die Zeit zu verfolgen. Da Sie die Aggregate in MS Project sowieso melden müssen, macht es nur Sinn, es zu Ihrer "Quelle der Wahrheit" für Zeitberichte zu machen.
Barnaby Golden
Cicely Mason