Entwicklungslösung vor Einigung auf Anforderungen gehetzt – ist das ein gesundes Projektmanagement?

Ich arbeite seit 4 Jahren im IT-Bereich (als Entwickler und QA-Leiter) und bin erst im September 2018 als Systemanalyst in dieses Unternehmen eingetreten.

Hier sind einige Hintergrundinformationen über das Unternehmen und das Projekt, das wir gerade durchführen:

  1. Das Unternehmen ist nach CMMI Level 3 zertifiziert.
  2. Das Team besteht aus Entwicklern, die erst vor 2 Monaten in das Unternehmen eingetreten sind, während der PM seit 8 Jahren für das Unternehmen arbeitet.
  3. Projekt vor 2 Monaten gestartet.
  4. Dieses Projekt hat keine grundlegenden Konzepte / Basis für eine Demo
  5. Das Team praktiziert agile Methoden (Mein erstes Mal mit Agile)

Folgendes ist mir am aktuellen SOP/Workflow des Teams aufgefallen:

  1. Alle Benutzeranforderungen wurden bisher nicht ordnungsgemäß dokumentiert und abgezeichnet.
  2. Nach gesammelten Anforderungen wies der PM die Entwickler an, die Lösung (gemäß der Idee/Visualisierung des PM) zu codieren, während die Lösungen noch nicht dokumentiert wurden, und mit dem Kunden zur Bestätigung zu diskutieren.
  3. Während sich die Lösungen entweder noch in der Entwicklungsphase befinden oder für die Demo fertiggestellt wurden, sendet PM den entworfenen Prozessablauf zur Überprüfung an den Kunden. Kundenfeedback mit Änderungen (manchmal geringfügig, manchmal größer) und PM forderten das Team auf, innerhalb der nächsten Stunden / Tage Änderungen gemäß dem Feedback vorzunehmen.
  4. PM hat immer einen Anruf vom Kunden erhalten, nach dem Anruf gibt es in 90 % der Fälle einige Änderungen (Ändern bestehender Funktionen oder Hinzufügen neuer Funktionen) am System, und manchmal muss das Team dies in den nächsten Stunden / Tagen erledigen.
  5. Heute hat der PM diese Idee A mit mir und den Entwicklern besprochen. Ich habe es dokumentiert und zur Überprüfung an PM gesendet. Nach den nächsten Tagen, als wir Idee A erwähnten, wird der PM fragen, warum wir Idee A verwenden, da sie falsch ist, und uns auffordern, zu Idee B zu wechseln.

Ist das ein gesundes Projektmanagement? Ich habe dem PM meine Bedenken geäußert, dass wir eine ordnungsgemäße Dokumentation (URS, FRS usw.) haben und uns abmelden sollten, um häufige Änderungen von Ideen / Anfragen zu verhindern und Zeit für Entwickler zu gewinnen, aber der PM sagte, dieser Kunde kümmert sich nicht darum es und wird die Verfahren nicht befolgen. Was sollten wir tun, um mit diesen Szenarien umzugehen?

Was ist deine Rolle? Wie betrifft Sie dieses Problem? Warum müssen Sie dieses Problem lösen?
Hallo Todd! Meine Rolle hier ist ein Systemanalytiker. Dieses Problem betraf mich, weil ich in den letzten 4 Jahren in einem früheren Unternehmen mit der Wasserfallmethode gearbeitet hatte. In dieser aktuellen Firma/Umgebung ist keine Standardisierung/SOP definiert, da das Team neu hinzugekommen ist. Ich habe diesbezüglich mit dem PM gesprochen, da ich befürchte, wenn diese Szenarien weiterhin bestehen, wird dies die Teamleistung beeinträchtigen. Es wird mich auch beeinflussen, darüber nachzudenken, ob ich in dieser Art von Umgebung weiterarbeiten sollte.

Antworten (3)

Scheint sicherlich nicht gesund zu sein, wie beschrieben :/. Ich kann nicht zu allen Punkten sprechen, aber ein Stück:

  • Wenn Sie an Funktionen arbeiten, ohne etwas vorgeführt zu haben, ist dies nicht großartig. Ich bin mir nicht sicher, ob Sie mehr Dokumentation benötigen, aber Sie müssen in einen wiederholbaren Zyklus von „Bauen Sie ein Arbeitsstück, zeigen Sie es dem Kunden, entscheiden Sie gemeinsam, was als nächstes wichtig ist, was gebaut werden soll.“

    Wenn sie Änderungen wünschen, nachdem sie es gesehen haben, schön und gut – sie müssen mit den restlichen Elementen auf der Liste priorisiert werden.

Wenn Sie keine funktionierende/demontierbare Software erhalten, bevor der Kunde oder PM nach Änderungen fragt, ODER wenn die Änderungen immer oberste Priorität haben, dann werden Sie nie in einen Rhythmus der Lieferung funktionierender Software geraten, und das Projekt wird vorhersehbar sein zerbrechlich und stressig. :(

Die für Änderungen und Ergänzungen geforderte schnelle Bearbeitungszeit ist ebenfalls lückenhaft – es ist unmöglich, in einen vernünftigen Entwicklungszyklus zu gelangen, wenn jede neue Laune oberste Priorität hat.

Ich bin sicher, andere können sich mit spezifischeren Erkenntnissen melden - viel Glück. Sorgen Sie sich nicht zu sehr um die Dokumentation, aber bestehen Sie auf einem vernünftigen Entwicklungszyklus, priorisierten Anforderungen und häufigen Demos.

Hallo Taylor! Danke, dass Sie Ihre Meinung fallen lassen! Ich habe heute einige Informationen zur agilen Methodik gelesen und stimme Ihnen bezüglich der Dokumentation zu. Ich machte mir Sorgen darüber, da ich zuvor Wasserfall praktizierte und immer noch versuche, mich an die agile Umgebung anzupassen. Ich bin mir nicht sicher, warum das Unternehmen keine Demoversion davon hat, aber ich glaube, dass sie ein großes Risiko eingehen, um die Gelegenheiten dieses Projekts zu ergreifen.

Das Team praktiziert agile Methoden (Mein erstes Mal mit Agile)

Agilität ist nicht wirklich eine Methodik. Es ist ein Ansatz für die Softwareentwicklung , bei dem es wichtiger ist, auf Änderungen zu reagieren als einem Plan zu folgen.

Es scheint wahrscheinlich, dass Sie einem agilen Framework folgen, möglicherweise Scrum oder Kanban ? Wenn Sie in Sprints arbeiten, verwenden Sie wahrscheinlich Scrum. Es würde sich lohnen, mehr von Ihrer Organisation darüber zu erfahren, welchen Rahmen sie befolgen, da dies es uns ermöglicht, spezifischer auf Ihre Frage zu antworten.

Es gibt einige Probleme mit dem aktuellen Ansatz:

Der PM hat die Entwickler angewiesen, die Lösung zu codieren (gemäß der Idee/Visualisierung des PM)

Dies ist keine agile Praxis. Typischerweise ermutigen wir die Leute, die die Implementierung durchführen, das Design zu produzieren.

Kundenfeedback mit Änderungen (manchmal geringfügig, manchmal größer) und PM forderten das Team auf, innerhalb der nächsten Stunden / Tage Änderungen gemäß dem Feedback vorzunehmen.

Kundenfeedback ist wertvoll und Teil des agilen Ansatzes. Es ist jedoch ungewöhnlich, sofort auf alle Rückmeldungen zu reagieren. Ein gängiger Ansatz wäre, das Feedback zu erhalten, es zu überprüfen, zu priorisieren (neben anderen bestehenden Anforderungen) und es dann bei Bedarf in die nächste Planungssitzung einzubringen.

PM erhielt immer Anruf vom Kunden

Es ist nicht ungewöhnlich, einen primären Ansprechpartner mit dem Kunden zu haben. Es ist jedoch in der Regel sehr wertvoll, wenn auch Mitglieder des Lieferteams mit ihnen sprechen. Es wäre sicherlich nicht sinnvoll, Kommunikationsbarrieren zwischen dem Delivery-Team und dem Anforderungs-/Feedbackgeber zu errichten.

Der PM wird gefragt, warum wir Idee A verwenden, da sie falsch ist, und uns auffordern, zu Idee B zu wechseln

Das ist eindeutig eine Fehlfunktion. Es lohnt sich, das Lieferteam zusammenzubringen und mit dem Projektmanager zu sprechen. Schlagen Sie einen anderen Ansatz vor, bei dem das Team mehr Verantwortung für die Entwicklung übernimmt. Wenn Sie einen agilen Coach in Ihrer Organisation haben, wäre dies eine gute Gelegenheit, ihn einzubeziehen.

Hallo Barnaby! Danke für deine wertvollen Informationen! Ich stimmte der Umsetzung für das Design zu. Aber ist es nicht besser, wenn wir die Lösungen entwerfen und dem Kunden präsentieren, bevor die Entwickler mit der Codierung beginnen? Ich bin mir nicht sicher, ob dies in Agile anwendbar ist. Hoffe ihr könnt mich beraten!
Ich habe dem PM auch vorgeschlagen, den Entwicklern mehr Verantwortung für die Entwicklung zu überlassen, zB: sie entscheiden/planen lassen, wie die Funktionen/Datenbank funktionieren sollen, da sie wissen, was das Beste dafür ist. Aber der PM scheint an ihren Fähigkeiten zu zweifeln und würde das Team dazu bringen, auf der Grundlage des PM-Vorschlags zu entwerfen. Manchmal habe ich das Gefühl, dass der PM die Grenze überschreitet, indem er die technischen Aspekte mikroverwaltet. Gelegentlich hat der dev. Team-Lösungen scheinen kompliziert (sie wollten sicherstellen, dass die Basiscodierung in Zukunft skalierbar ist), aber der PM würde darauf bestehen, die Dinge einfach zu machen.
Es ist nichts Falsches daran, ein Design im Voraus zu erstellen. Es ist jedoch wichtig zu erkennen, dass Menschen normalerweise viel besser darin sind, Feedback zu einer funktionierenden Anwendung zu geben, als zu einem Design. Der Trick besteht darin, die richtige Balance für Ihr Team zu finden – genug Design im Voraus, um loszulegen, aber dann auch Raum für Änderungen zu lassen, die sich aus Feedback ergeben, sobald der Kunde die Anwendung sieht. Das ist es, worum es bei Agilität geht – Veränderungen antizipieren und sich an sie anpassen.
Um auf die Frage „Design vor Code“ einzugehen: Es gibt einen agilen Slogan: „Baue das Falsche schnell“ (ich würde hinzufügen „und billig“). Die Idee ist, dass das erste, was Sie bauen, unweigerlich nicht ganz richtig sein wird und dass es insgesamt kostengünstiger ist, etwas schnell zu bauen, das die Leute tatsächlich verwenden und zu dem sie sinnvolles Feedback geben können, damit die nächste Iteration näher an dem liegt, was sie wollen .

„Ob Sie es glauben oder nicht, die reale Antwort könnte lauten – vielleicht nicht, aber wir müssen es trotzdem tun.“

„Agil“ ist zunächst einmal ein Ideal. (Eine wertvolle und nützliche Perspektive, aber nichtsdestotrotz „ein Ideal“.) Als solche enthält sie bestimmte vereinfachende Annahmen – die wahr oder falsch sein können – sowohl in Bezug auf „den Kunden“ als auch in Bezug auf die Umstände, unter denen „der Client" handeln könnte. Glücklicherweise hat Ihr Team einen PM, der „8 Jahre Erfahrung mit diesem Unternehmen“ hat. ("Halleluja.")

Computersoftware ist sehr anspruchsvoll und die Entwicklung dauert lange ($$$!!) . So könnte das Team in eine bestimmte Richtung geschickt werden, bevor diese Richtung vollständig verstanden wird, in dem Wissen, dass Nacharbeit das Ergebnis sein wird. Auf Kundenanforderungen kann reagiert werden, bevor der Kunde (!) vollständig weiß, wie die endgültigen Anforderungen aussehen werden, oder die endgültigen Geschäftsentscheidungen getroffen (oder davon erfahren) hat, die sie bestimmen.

Was hier passiert – und das ist etwas, was eine Methodik trotz ihrer Vorzüge wirklich zu einfach zu verstehen ist – ist eine Reihe von fundierten Vermutungen , die gleichzeitig auf mehreren verschiedenen Ebenen angestellt werden, sowohl innerhalb als auch über dem Team.

„Computerprogrammierung“ erfordert notwendigerweise „absolute Gewissheit“, da die betreffende Maschine nur 1 und 0 kennt , aber dieses „Raten“ wird angewendet, um den Aufwand gegen die reale Geschäftsunsicherheit mit – so hoffen wir – so wenig Verschwendung und Nacharbeit wie möglich abzugleichen möglich.

Außerdem – "sobald die Software fertiggestellt ist, wird sie in Stein gemeißelt und daher viel schwieriger zu ändern sein." Dies ist ein weiteres Argument für die "Fluidität", die Programmiermethoden so schwer zu verstehen sind. Das Unternehmen kann sich sozusagen spekulativ auf bestimmte Aspekte des Gesamtprojekts festlegen, da es weiß, dass einige Teile überarbeitet werden müssen, aber nicht alle.

Entwicklungslösung vor Einigung auf Anforderungen gehetzt – ist das ein gesundes Projektmanagement?
AntwortenHierDatenschutz-Bestimmungen1y, 0v