Ich arbeite als Entwickler in einem kleinen IT-Unternehmen mit 4 Entwicklern und 2 Projektmanagern. Wir implementieren derzeit eine Art traditionelles Projektmanagement, bei dem der Arbeitsablauf für ein bestimmtes Projekt wie folgt aussieht:
Jedes von uns durchgeführte Projekt ist auf die spezifischen Bedürfnisse unserer Kunden zugeschnitten. Das bedeutet, dass die Aufgabenschätzungen manchmal falsch sind (es ist schwer, eine Aufgabe zu schätzen, die Sie noch nie zuvor gemacht haben) oder dass bestimmte technische Probleme nur auftreten, wenn wir uns mitten in der Entwicklung befinden. Dies frustriert unsere Projektmanager sehr, da dies normalerweise bedeutet, dass wir unsere geschätzten Entwicklungskosten überschreiten und unsere Gewinnspanne für das Projekt schleicht.
Die größte Frustration entsteht jedoch durch fehlende Fristen, die den Kunden zugesagt wurden. Dies liegt daran, dass wir zu jedem Zeitpunkt immer 3 oder mehr Projekte in aktiver Entwicklung haben. Daneben werden die Entwickler oft direkt von Kunden für Fragen/technische Probleme/Notfälle angerufen. Hinzu kommt der zusätzliche Overhead, wenn Aufgaben von einem Entwickler auf einen anderen verschoben werden, die dann dem Entwickler erklärt werden müssen, der die Aufgabe erhält.
Jede Woche weist einer der Projektmanager den Entwicklern Aufgaben zu, die in dieser Woche fertig sein müssen, um die Fristen einzuhalten. Von den 38 zuweisbaren Arbeitsstunden pro Entwickler bleiben 4 Stunden nicht zugewiesen, um unvorhergesehene Ereignisse zu berücksichtigen. Es gibt auch einen neuen Entwickler, der erst vor drei Wochen zu uns gestoßen ist, und er braucht von Zeit zu Zeit technische Hilfe, was im Durchschnitt jede Woche etwa 2 bis 3 Stunden meiner Zeit in Anspruch nimmt.
Fazit: Diese 4 Stunden haben bisher nie ausgereicht. Die Kommunikation mit dem Management, Bugs mit hoher Priorität, ... dauert jede Woche länger als 4 Stunden. Das Management beschuldigt die Entwickler, dass sie nicht in der Lage sind, Prioritäten zu setzen, und sagt, wir sollten uns mehr Mühe geben, genaue Schätzungen vorzunehmen und unsere Fristen tatsächlich einzuhalten.
Meine Frage ist: Was ist hier der richtige Ansatz? Wie können wir den Umfang und die Dauer eines Projekts besser abschätzen und Fristen effektiv festlegen und einhalten? Was muss sich ändern?
Vielen Dank im Voraus.
Es gibt so viele klassische Probleme, die in diesem Ansatz enthalten sind, dass es schwer ist, den besten Ausgangspunkt zu finden! Zunächst möchte ich sagen, dass ein agiler Ansatz aufgrund der Art und Weise, wie er mit funktionalen Anforderungen und technischen Schulden (Bugs und Problemen) umgeht, möglicherweise besser zu Ihnen passt, aber ich persönlich habe keine direkte Erfahrung mit diesem Modell. Ich bin mir sicher, dass jemand vorbeikommen und das als Ansatz besprechen wird. Angenommen, Sie möchten in der Zwischenzeit bei einem Wasserfallmodell bleiben:
Projektmanager sammeln funktionale Anforderungen: Dies ist keine traditionelle PM-Aufgabe und eher für Geschäfts- und Systemanalysten geeignet. BAs werden darin geschult, die genauen funktionalen Anforderungen herauszuarbeiten und sie so darzustellen, dass der Kunde sie genehmigen und (hoffentlich) das Entwicklungsteam in ihren Schätzungs- und Entwicklungsprozessen verwenden kann.
Planung: Offensichtlich planen die PMs die Projekte nicht mit genügend Kontingenz, um unvorhergesehene Probleme, Auswirkungen durch andere überlaufende Projekte und kritische Fehler und Probleme zu berücksichtigen. Es klingt für mich nicht so, als wäre dies ein Schätzungsproblem (hängt davon ab, wie wild die Schätzungen der Entwickler tatsächlich sind und wie stark sie von der Realität abweichen). Es klingt eher nach hoffnungslos optimistischer Planung und falschem Erwartungsmanagement. Dies sind alles Bereiche, in denen die PMs vielleicht von einer zusätzlichen Schulung profitieren könnten.
Kapazitätsplanung: Die Personen, die für die Planung der Zuweisung und Zuordnung des Ressourcenpools verantwortlich sind (Sie sagen nicht, ob dies auch die PMs sind), müssen mit ihrem Verständnis für die unterschiedlichen Ausgaberaten des Teams schlauer werden – einige werden es immer tun schneller/produktiver zu sein als andere, und wenn das Team für ein bestimmtes Projekt zusammengestellt wird, muss dieses Wissen in die Planung einfließen – so zu tun, als ob jeder so schnell arbeitet wie das schnellste Mitglied des Teams, ist etwas wahnhaft und führt immer zu Über- optimistische Planung. Es ist auch wichtig, die Auswirkungen auf die bestehenden Teammitglieder zu berücksichtigen, wenn neue Mitglieder hinzukommen, die geschult/betreut oder einfach nur in das Team integriert werden müssen – die Auswirkung betrifft niemals nur die Produktivität der neuen Person, sie wirkt sich auf die aus Produktivität aller um diese Person herum. Die andere Seite der Kapazitätsplanungs-Medaille ist, dass in einer reinen Softwarehaus-/Beratungsumgebung die Auslastung König ist. Kein Unternehmen kann es sich leisten, Mitarbeiter auf der Bank zu haben, daher wird eine verkaufsorientierte Umgebung das Personal immer überlasten ("Schwitzen der Vermögenswerte") - Dies wird nie verschwinden und geht mit dem Territorium einher, jedoch durch bessere Planung und Verständnis der Produktivität von den Leuten könnte es besser sein. Das Management muss dabei ebenfalls eine Rolle spielen und zu dem Verständnis geführt werden, dass, wenn Sie die Mitarbeiter zu sehr drängen, die Ecken gekürzt werden, die Qualität sinkt und mehr Zeit für die Behebung der Qualitätsprobleme aufgewendet wird. Hinzu kommt in der Regel ein Beziehungs- oder Reputationsschaden. Dies gegen eine nicht aufladende "Bank" von nicht ausgelasteten Personen auszugleichen, ist immer eine knifflige Aufgabe.
Das Management beschuldigt Entwickler, dass sie nicht in der Lage sind, Prioritäten zu setzen: Dies hat eine einfache Antwort: Entwickler priorisieren die Probleme NICHT. Die PMs vielleicht. Die BAs vielleicht. Der Kunde, immer (sobald Sie bei UAT angekommen sind). Irgendjemand sollte die ausstehenden Probleme diskutieren und ausgleichen und das Entwicklungsteam über die Prioritätsreihenfolge der Fehler informieren. So einfach ist das – Entwickler sind wahrscheinlich die schlechteste Personengruppe, die man bitten kann, Fehler und Probleme zu priorisieren, da sie (normalerweise) nicht die übergeordnete/geschäftsorientierte Sicht auf das Projekt haben. Nach meiner persönlichen Erfahrung begleite ich als PM normalerweise die Priorisierung von Problemen. Während der SIT-Phase verwenden wir einen risikobasierten Ansatz (um es zu vereinfachen,
Eine letzte Sache, Sie erwähnen das Testen in Ihrem Wasserfallprozess nicht. Ist das, weil Sie es nicht tun, oder nur, weil es "so offensichtlich" ist, dass es nicht erwähnt werden muss? Wenn Sie direkt von Developer/Unit Testing zum Client/Go-Live gehen, dann fragen Sie nach Ärger. Das Team muss System- und Integrationstests (SIT) durchführen, bevor der Kunde sie überhaupt sieht, und das muss von jemandem, der sich mit Testen auskennt, richtig geplant werden; kein PM und definitiv KEIN Entwickler. Hier kommen die Aufgaben der richtigen BAs voll zur Geltung, da ihre Spezifikationen von Testexperten verwendet werden, um Testfälle zu erstellen und dann zu beweisen, dass das Produkt anhand dieser Testfälle funktioniert. Wenn der Client den Code sieht, sollte er bereits alle Tests bestanden haben, die der Client jemals gegen ihn ausführen wird.eine einfache Sache sein (obwohl es das irgendwie nie ist!)
Ich hoffe, das hilft. Viel Glück!
BEARBEITEN nach erneutem Lesen der Frage: Da es sich um ein kleines Unternehmen handelt, haben Sie wahrscheinlich nicht den Spielraum, BAs hinzuzufügen und Ressourcen zu testen. Ich würde jedoch ernsthaft in Frage stellen, warum zwei PMs für vier Entwickler benötigt werden. Für so viele Leute kann ich nicht sehen, wie Sie mehr als einen PM benötigen, der mehrere Projekte durchführt. Wenn Sie eine PM fallen lassen und dann durch einen BA ersetzen, der Testerfahrung hat, wäre das meiner Meinung nach eine viel bessere Mischung.
Es ist sicherlich eine schwierige Aufgabe, parallele Projekte mit begrenzten Ressourcen zu verwalten. Ich bin in letzter Zeit mit diesen Problemen konfrontiert und habe einen Ausweg gefunden, indem ich Agile und einige Teile von KANBAN implementiert habe.
Ich habe dafür gesorgt, dass es ein PM + Aufgabenmanagement-Tool gibt, das mich bei allen Prozessen während des gesamten Projektlebenszyklus unterstützt. Ich habe Redmine implementiert, um Projekte und Aufgaben zu verwalten. Verlinkte alle Teammitglieder mit dem Portal, definierte Sprints nach der Durchführung von Scrum of Scrum und führte weiterhin tägliche Scrums durch, um sicherzustellen, dass Projekt-/Aufgabenzeitpläne eingehalten werden. Leider war ich als PM auch dafür verantwortlich, Anforderungen zu sammeln, zu dokumentieren und später beim Staging zu testen.
Zusammenfassend würde ich Ihnen folgende schnelle Schritte vorschlagen:
Diese Schritte würden das Chaos bei der Verwaltung mehrerer Projekte ziemlich gut kontrollieren.
Thiago Cardoso