Wie verbessere ich den Entwicklungsprozess, wenn die einzige „Spezifikation“ ein „Slogan“ des Managements ist?

Ich arbeite in einer neuen Umgebung, in der ein typisches Projekt aus einem vom Management bereitgestellten „Slogan“ und einem Team von Ingenieuren besteht, die ein Produkt liefern, das dem Slogan entspricht. Das Unternehmen hat keinen F&E-Prozess und die Folge ist, dass die Entwicklung ad-hoc wird und Fehler gemacht werden. Beispiele für Fehler; - Der Slogan ist falsch interpretiert – F&E liefert das falsche Produkt - Entwicklung beginnt ohne Anforderungsanalyse – wir könnten aufgrund technischer Probleme in einer Sackgasse landen. - Technische Dokumentation ist fragmentiert und inkonsistent. Da es keinen Entwicklungsprozess gibt, ist auch die Dokumentation ad hoc; Es gibt keine Anforderungsdokumentation außer den Slogans und die technische Dokumentation ist fragmentiert und in verschiedenen Formaten.

Es ist eine Small-Business-Mentalität in einem Unternehmen, das einfach ein bisschen zu groß geworden ist.

Das Gute ist, dass es eine meiner Aufgaben ist, diese Probleme anzugehen. Wir sind derzeit weniger als 10 Ingenieure (Mechanik, Elektronik und Software), aber ich gehe davon aus, dass wir in den kommenden Jahren wachsen werden, also möchte ich ernsthaft versuchen, etwas Gutes zu tun. Ich habe lange darüber nachgedacht und möchte die folgende SDLC auf die Organisation anwenden;

  • Formale Phasen (Inbetriebnahme, Planung, Entwicklung, Verifizierung & Freigabe, Nachbereitung).
  • Überprüfungen für Phasenübergänge, bei denen jede Phase ihre Lieferungen an Ort und Stelle haben muss
  • Management-Abzeichnung für Phasenübergang und Release-Genehmigung
  • Risikoanalyse und Risikomanagement
  • Dokumentationspläne, bei denen die Dokumentation Teil einer Dokumentenstruktur ist
  • Regelmäßige Treffen mit den Mitgliedern des Projektteams und den Stakeholdern

Wie kann ich den Schmerz des Übergangs bewältigen? Ist es überhaupt ratsam, etwas so Strenges auf eine unerfahrene Organisation anzuwenden? Ich möchte meine Kollegen oder das Management nicht verängstigen. Also ich weiß nicht wirklich wie ich damit umgehen soll.

Ich neige derzeit dazu, einen SDLC zu schreiben, der den Prozess beschreibt, das Entwicklungsteam schult und diesen Prozess auf ein neues Projekt anwendet und dann von dort weitergeht.

MEIN WERDEGANG Ich arbeite seit fast 15 Jahren in einem regulierten multidisziplinären Engineering-Umfeld und bin strenges Projektmanagement gewohnt. Wir verwendeten ein Projektmanagementmodell, das auf 5 Phasen basierte; (0)Inbetriebnahme, (1)Planung, (2)Entwicklung, (3)Verifizierung und Freigabe, (4)Follow-up, wenn die Genehmigung zum Übergang in die nächste Phase erfordert, dass Sie die Lieferungen für die Phase erfüllt haben. Mein Hauptberuf ist Software Engineering als Software Lead, aber ich hatte auch Aufgaben als Teilprojektleiter und Scrum-Master. Als wir agile Methoden für das Softwareteam verwendeten, haben wir sie in Phase 2 und 3 verwendet.

Ich bin mir nicht sicher, was Ihr Problem hier ist. „Wie kann der PM-Prozess verbessert werden“ ist eine Umfragefrage. Können Sie stattdessen ein bestimmtes Problem ansprechen, das Sie zu lösen versuchen?
Willkommen bei PMSE, Patrick! Ich habe die Frage bearbeitet, um zu verdeutlichen, worauf Sie meiner Meinung nach hinauswollen. Lassen Sie mich wissen, wenn ich daneben liege. Ein hilfreiches Detail wäre, warum Sie nicht denselben Prozess verwenden können, den Sie in Ihrem vorherigen Unternehmen verwendet haben.
Danke @MarkPhillips - das hat es eher zu einer Frage gemacht. Mein Hauptberuf ist Softwareentwicklung und deshalb bin ich mir etwas unsicher, wie andere PM machen. Ich habe keine formelle Ausbildung bei PM. Ich würde gerne den mir bekannten Entwicklungsprozess übernehmen, aber ich befürchte, dass der Leiter des Engineering-Teams Angst vor dem strengen Prozess bekommt und es stattdessen einfach so lässt, wie es ist. Deshalb frage ich mich, wie andere das machen. (In der Softwareentwicklung gibt es je nach Kontext Muster und Antimuster, und hier hatte ich mir etwas Ähnliches erhofft).
Hallo Patrick. Auch nach den Änderungen denke ich, dass die Frage immer noch zu weit gefasst ist. Vielleicht könnten Sie uns Einzelheiten zum aktuellen Prozess mitteilen und uns von einigen Problemen erzählen, die Sie identifiziert haben und lösen möchten.
Heiligabend steht in Schweden in wenigen Stunden bevor, also werde ich das in ein paar Tagen klären. Genieße den Urlaub!
Patrik, vielleicht lautet Ihre Frage: „Was ist der beste Weg, um als Entwickler formellere Projektmanagementprozesse in einem neuen Unternehmen einzuführen?“ Trifft das das Wesentliche? Mathias, hilft das?
@MarkPhillips Ich würde wahrscheinlich dafür stimmen, eine Frage "als Entwickler" nach Workplace zu verschieben, es sei denn, sie wäre sehr zielgerichtet und würde besprechen, wie ein bestimmtes Framework oder ein bestimmter Prozess aus dem identifizierten POV bearbeitet wird.
Ok, zurück von Weihnachten.
@CodeGnome. Ich werde auch etwas Projektmanagement machen, also hoffe ich immer noch, dass die Frage hier qualifiziert ist. Ich muss nur eine gute Frage formulieren ... Ich habe über die eigentliche Frage nachgedacht und weiß eigentlich, wo ich landen möchte; Ich möchte einen SDLC (Systems Development Life Cycle) haben, dem jedes Projekt folgen kann. Ein SDLC würde (wenn es von allen Parteien akzeptiert wird) einen gemeinsamen Prozess und eine gemeinsame Terminologie innerhalb der Forschung und Entwicklung bieten. Die Frage ist, wie der Weg zu einem akzeptierten SDLC aussieht.
Eine lange Umschreibung der Frage erledigt

Antworten (3)

Soweit ich die Frage verstehe und wenn Sie mir etwas Humor erlauben, möchten Sie wissen, ob es in Ordnung ist, einen pseudo-chaotischen (Nicht-)Prozess auf einmal in einen hochbürokratischen PMBOK-vollen Prozess zu verwandeln. Nach meiner Erfahrung lautet die Antwort aus mehreren Gründen nein :

  1. Das Team ist in einem so schweren Prozess nicht geschult und es wird lange dauern, bis es effizient ist. Nicht, dass sie sich des Problems nicht bewusst wären, aber sie sind seit einiger Zeit Freestyler und es könnte schwierig für sie sein. Sie können sich wahrscheinlich nicht darauf verlassen, dass sie die neuen Mitglieder in dem Prozess schulen und dieses Team irgendwie zu einem völlig neuen Team machen.
  2. Sie wissen noch nicht – und können es noch nicht wissen –, was der beste Prozess für diese spezielle Situation ist. Hier nichts Persönliches. Ich glaube wirklich, dass niemand den besten Prozess/die beste Methodik/was auch immer auf einem Papier finden kann, ohne etwas auszuprobieren.
  3. Da Sie (eher) neu in diesem Unternehmen sind, könnten Sie große Schwierigkeiten haben, Ihren großen Prozess vom Team zu akzeptieren.
  4. Der Versuch, einen Prozess anzuwenden, der woanders funktioniert hat, ist wahrscheinlich ein Fehler. Auch hier nichts Persönliches, da dies ein ziemlich häufiges Missverständnis in der abendländischen Kultur ist, das beispielsweise in der japanischen Kultur nicht existiert. Wir wollen jetzt große Ergebnisse. Wir wollen alles und wir wollen es jetzt , also wenden wir das „Wie“ an, ohne das „Warum“ zu verstehen.
  5. Sie klingen vielleicht wie ein mürrischer alter Mann: "Zu meiner Zeit hätten wir Foobar gemacht ..."
  6. Das Team ist wahrscheinlich sehr agil gesinnt: Kein Prozess bedeutet, dass Dinge geändert werden können, wann immer die Stakeholder dies wünschen. Natürlich sind zu häufige Änderungswünsche ärgerlich, aber man sollte auch nicht zu streng sein.
  7. Das Management ist wahrscheinlich auch sehr agil. Sie werden keinen Prozess akzeptieren, bei dem sie alle Anforderungen von Anfang an angeben müssen (was übrigens unmöglich ist), während sie früher alles kostenlos ändern konnten.

In Ihrer Situation würde ich empfehlen, eine Kaizen -getriebene Verbesserung zu implementieren. Lassen Sie das Team über den aktuellen Prozess nachdenken (es muss einen Schatten von etwas geben, oder?). Ein Manager sollte auch hier sein. Erstellen Sie gemeinsam eine Wertstromanalyse dessen, was Sie jetzt tun, und versuchen Sie herauszufinden, was das Hauptproblem ist und wie Sie es beheben können. Natürlich behalten Sie Ihren Zielprozess im Auge, aber seien Sie nicht zu voreilig. Versuchen Sie stattdessen, alle Beteiligten in den Prozess der Prozessänderung einzubeziehen, schließlich wissen sie, dass es ein Problem mit der aktuellen Situation gibt. Lassen Sie den neuen Prozess einige Zeit laufen und wiederholen Sie das Ganze im Stil von Ausprobieren-Lernen-Verbessern.

Als Randnotiz möchte ich erwähnen, dass ich einmal in einer ähnlichen Situation war und mich entschieden habe, Kanban einzuführen . Sie sollten es sich ansehen, da es neue Perspektiven eröffnen könnte.

Ich werde einige Details zu Ihrer Antwort hinzufügen. 1. Es gibt viele neue Leute und 3 "Original"-Entwickler. Die anderen neuen Leute sind auch frustriert über den Nicht-Prozess. 2. Ich bin seit 12 Monaten im Unternehmen und habe einige kleine Projekte durchgeführt. Ich sehe deutlich wo die Probleme liegen, die Lösung ist natürlich jetzt genauso klar. 3. Ja. Ich brauche das Buy-in von meinem F&E-Manager. 4. Ja, ich plane kein 1:1-Mapping. Der Prozess, an den ich denke, ist agiler. 5. Stimmt 6. Ich kann sagen, dass sie von all den plötzlichen Änderungen nicht zu finden sind ... Ändert diese Information also irgendetwas?
Vielen Dank für diese Angaben. Ich werde meine Antwort bearbeiten, um einige weitere Details zum Teil "Gründe" zu geben und klarzustellen, dass es nichts Persönliches gibt
Wir sind cool, ich weiß, es ist nichts Persönliches! Etwas zusammenfassen; Bisher habe ich intensiv darüber nachgedacht, wo ich am Ende hin will – ein neuer Prozess, der die Entwicklungsgeschwindigkeit beibehält und Veränderungen annimmt, während er die Arbeit auf strukturierte und nachvollziehbare Weise erledigt. Jetzt muss ich darüber nachdenken, wie wir das Team dazu bringen, sich auf einen neuen Entwicklungsprozess einzulassen. Und Commitment kommt wahrscheinlich von der Teilnahme an der Prozessdefinition.
„das Team dazu bringen, sich auf einen neuen Entwicklungsprozess einzulassen“ und die Stakeholder, Manager usw. Es ist wichtig, dass alle auf der gleichen Seite stehen, wenn eine solche Änderung umgesetzt wird.

Das Sammeln von Anforderungen ist Teil der Arbeit des Managers, und wie es durchgeführt wird, hängt sowohl von der Unternehmenskultur / den aktuellen Prozessen, der Erfahrung des Managers in dem spezifischen Bereich des Projekts, der Erfahrung der Teammitglieder usw. ab. Wenn Sie mehr einführen möchten formaler Planungsteil, fangen Sie klein an. Beginnen Sie damit, die minimalen Anforderungen zu sammeln, mit denen Ihr Team arbeiten kann, und versuchen Sie, so viele Informationen wie nötig zu sammeln, während das Team arbeitet. Erklären Sie Ihren Managern, warum einige Informationen am Anfang wichtig sind, oder planen Sie, dass Informationen geändert werden.

Da der aktuelle Prozess „Slogan zum Produkt“ lautet, scheint von den Managern und Teammitgliedern erwartet zu werden, dass sie auf diesem Gebiet sehr erfahren sind. Investieren Sie Ihre Freizeit in das Erlernen des Geschäfts. Erklären Sie den Managern gleichzeitig, dass das Erfordernis einer solchen Erfahrung für die Ausführung der Arbeit nicht gut skalierbar ist. Daher hilft die Einführung einiger Schritte in die Planung, Projekte mit neuen Ingenieuren und Managern auf den neuesten Stand zu bringen.

Ich mag die Antwort. Ich möchte hinzufügen, dass Sie nicht ALLE Anforderungen im Voraus benötigen. Wenn Sie eine User Story nehmen, gibt es dort im Grunde nichts. Aber durch Diskussionen mit Interessenvertretern wird es zum Leben erweckt. Nehmen Sie den Slogan und fangen Sie an zu arbeiten, hören Sie einfach nicht auf, mit dem Management darüber zu kommunizieren, was sie wirklich wollen.
Es gibt keinen Prozess und wie das Produkt entwickelt wird, ist ein Ad-Hock-Prozess, der sich im Laufe der Zeit ändern wird. Ich möchte also nicht klein anfangen, ich möchte eine Struktur einführen, mit der Sie Projektmanagement betreiben können, sonst ist es nur Chaosmanagement. Und ich stimme zu, Sie brauchen nicht alle Anforderungen im Voraus. Da es sich jedoch sowohl um Hardware als auch um Software handelt, muss die Gesamtarchitektur (mit Schnittstellen zwischen Domänen) früh im Projekt definiert werden
@Patrik: Verfügen Sie über den nötigen politischen Einfluss, um sofort umfassende Änderungen am Prozess vorzunehmen? Ich würde vorschlagen, zumindest schriftliche Anforderungsdokumente einzuführen, die von Ihnen entworfen, aber vom höheren Management ("die Slogan-Meister") paraphiert werden, um eine ordentliche Überprüfung zu haben, ob Sie sich verstehen.
Ich habe Anforderungsspezifikationen für die Dinge geschrieben, die mir zugewiesen wurden. Der Grund dafür ist, dass ich den Slogan in etwas übersetzen musste, das ich verstehe, bevor ich mich an die Arbeit machte. Ich habe diese Dokumente an meinen Vorgesetzten geschickt und er findet, dass sie eine große Verbesserung darstellen. So weit, ist es gut. Mit etwas Glück kann ich also gleich größere Änderungen einführen. Aber ist es weise?
Lehren Sie sie mit gutem Beispiel. Zeigen Sie ihnen, dass die Formalisierung und Dokumentation des Prozesses zu Ergebnissen führt, indem Sie einen schnelleren Zyklus in Ihrem Projekt haben. Ihr Unternehmen durchläuft den schmerzhaften, aber notwendigen Wandel vom *'Ad-hoc'-Rummel eines kleinen Unternehmens zu einem mittelständischen Unternehmen. Sie sind von unschätzbarem Wert für Ihr Unternehmen, da Sie über die Erfahrung verfügen, um den Übergang in Ihrer Abteilung reibungslos zu gestalten. Mit etwas Glück gibt es Manager, die dieses Problem begreifen und in Ihnen einen nützlichen Verbündeten finden. Aber drängen Sie es jetzt nicht, alte Gewohnheiten verschwinden langsam.

Ich stimme Matthias in seinem Vorschlag für einen Kaizen-getriebenen Verbesserungsprozess von ganzem Herzen zu.

Sie haben angegeben, dass es bei der Implementierung Ihres SDLC nicht zu viel Widerstand vom Team geben wird, aber Sie müssen bei der Implementierung des Prozesses die Zustimmung Ihrer Stakeholder erhalten.

Ich würde empfehlen, dass Sie mehrere Schritte unternehmen, um einen starken Prozess mit dem Team aufzubauen:

  1. Bringen Sie einen sehr allgemeinen, breiten Satz von Schritten ein, der nicht sehr starr ist. Auf diese Weise haben das Management und das Team das Gefühl, dass sie immer noch flexibel sind, und es ist wahrscheinlicher, dass Sie die Zustimmung der Interessengruppen erhalten.
  2. Implementieren Sie dies zunächst in kleinen Projekten und holen Sie Feedback von allen Teammitgliedern und Stakeholdern ein.
  3. Verwenden Sie einen Kaizen-Stil der Änderungsimplementierung, damit das Team den SDLC-Prozess ausfüllt. Auf diese Weise baut das Team einen soliden, formalen Prozess auf, der für sie funktioniert.

Sie können den Prozess in Richtung Ihres endgültigen Ziels lenken, und er wird für das Team und das Management weitaus weniger störend sein.

Wie verbessere ich den Entwicklungsprozess, wenn die einzige „Spezifikation“ ein „Slogan“ des Managements ist?
AntwortenHierDatenschutz-Bestimmungen1y, 0v