Ich habe viele Organisationen gesehen, in denen Projektmanager so argumentieren würden:
Wir sind spezialisiert auf sehr kleine Projekte. Da ein sehr kleines Projekt ein sehr kleines Team benötigt, sollte ich jedem Projekt eine oder zwei Personen zuweisen. Dies bedeutet jedoch, dass nur wenige Personen in der Organisation über das Projekt Bescheid wissen ; Wenn sie aussteigen oder von einem Bus angefahren werden, ist das Projekt zum Scheitern verurteilt. Deshalb werde ich dem Projekt trotz der unnötigen Überlastung für alle Fälle vier oder fünf Personen zuweisen.
Ich kann verstehen, dass ein Projektmanager möglicherweise besorgt darüber ist, dass ein Mitarbeiter kündigt und das Projekt unbesetzt lässt; das wäre fatal. Es sieht jedoch nicht nach einer guten Idee aus, als Ausgleich vier oder fünf Personen an einem sehr kleinen Projekt arbeiten zu lassen, das nur einen oder zwei benötigt.
Welche anderen Strategien fallen Ihnen ein, um das Risiko zu minimieren und gleichzeitig Ressourcen zu schonen?
Gute, klare Dokumentation wie die Ziele des Projekts, die damit verbundenen Aufgaben, die Risiken, der Zeitplan und die Aufzeichnungen über die Kommunikation mit dem Kunden.
Das Ändern von Ressourcen sollte ein Projekt nicht zum Scheitern bringen, solange es gut dokumentiert ist und in Ihrer Organisation kluge Leute arbeiten. Es ist auch hilfreich, wenn die vorherigen Personen, die an dem Projekt gearbeitet haben, klug und organisiert waren, damit der Code lesbar und wartbar ist. Obwohl es immer eine Lernkurve geben wird, sollten andere Entwickler in der Lage sein, einzuspringen und die Rolle zu übernehmen.
Ich habe mit Entwicklern zusammengearbeitet, die in ein Projekt eingestiegen sind und eine Rolle übernommen haben, und nach ein paar Wochen waren sie produktiv an dem Projekt beteiligt. Ich habe noch nie ein Projekt sterben sehen, weil jemand die Organisation verlassen hat.
Eine Sache ist, dass die Angst, ein Projekt von einer Person zu übernehmen, die „vom Bus angefahren“ wurde, überbewertet wird. Tatsächlich habe ich viele Fälle gesehen, in denen Teams dies aus welchen Gründen auch immer tun mussten, und es war nicht so schwer.
Allerdings möchte jeder lieber vorbereitet sein. Ich bin mir nicht sicher, ob es die Lösung ist, mehr Leute auf kleine Projekte zu werfen. Ich denke, es geht mehr darum, die Arbeit so zu organisieren, dass das Wissen unter den Teammitgliedern geteilt wird, als sie einfach dem Projekt zuzuordnen.
Ein paar Ideen, die mir in den Sinn kommen.
Paarprogrammierung (wenn wir ein Softwareprojekt besprechen). Es ist keine einfache Sache, da sich die Leute dieser Technik oft widersetzen, aber das ist nichts völlig Neues oder Unbekanntes. Die Leute paaren sich für lange Zeit und in bestimmten Umgebungen scheint es sehr gut zu funktionieren. Und Sie können mindestens doppelt so viele Leute haben, die das Projekt kennen.
Kollektiver Codebesitz (wiederum für Softwareprojekte). Es eignet sich besonders gut für Projekte in der Wartungsphase. Wenn Sie einen Fehler beheben oder eine Änderung vornehmen möchten, können Sie jede freie Person damit beauftragen, selbst wenn sie mit dem Code nicht vertraut ist. Wenn sie sich verlaufen, können sie diejenigen um Hilfe bitten, die zuvor an einer Anwendung gearbeitet haben. Nach einiger Zeit ist das Wissen über Projekte im ganzen Team verteilt. Dieselbe Technik können Sie gegen Projekte in ihrer Aufbauphase anwenden, aber Sie brauchen sowieso eine Art technischen Leiter oder Projektleiter, um die Bemühungen aller zu koordinieren.
Wartungsteam, das nach einer bestimmten Phase die Verantwortung für das Projekt übernimmt. Es macht einen Projektübergang in die Wartungsphase explizit und erzwingt somit den Austausch von Wissen, eine minimale angemessene Dokumentation usw.
CesarGon
Kwang Mark Eleven
Mark Phillips
CesarGon