Es gibt viele Projektmanagement-Methoden. Jeder von ihnen hilft auf seine Weise, Geschäftsziele zu erreichen. Oft sind sie nicht einfach zu etablieren, insbesondere zu Beginn eines Projekts, und entstehen erst während der Implementierung. Als Antwort auf dieses Problem wurden agile Methoden entwickelt, deren Kern der häufige Informationsaustausch zwischen dem Entwicklungsteam und Unternehmensvertretern ist.

Aber wie sieht das in der Praxis aus? Ich werde versuchen, einige Beispiele aus der Praxis zu nennen, die beschreiben, wie wichtig eine gute Zusammenarbeit zwischen Entwicklern und Unternehmen ist und welche Probleme dadurch vermieden werden können. Viele Techniker werden jetzt wahrscheinlich denken: „In meinem Team gibt es einen Product Owner, ich möchte nicht mit dem Unternehmen sprechen“. In einer idealen Welt mag das funktionieren, aber die Realität sieht etwas anders aus.

‍

1) Projektzeitrahmen

Es wird unglaublich klingen, aber manchmal ist sich das Entwicklungsteam nicht bewusst, in welchem Zeitrahmen die Funktionalität getestet werden sollte. Dies ist einer der wichtigsten architektonischen Faktoren, anhand dessen wir bestimmen können, welche Architektur zur Lösung eines bestimmten Problems geeignet ist. Diese Art von Untertreibung kann aus verschiedenen Gründen auftreten:

Für Unternehmen ist der Begriff selbstverständlich, z. B. Black Friday
Unternehmen verwenden Feiertagsnamen, z. B. Thanksgiving (in Kanada 11.10.2021 in den USA 25.11.2021)
Unternehmen, die den Begriff Q2 verwenden, haben den Beginn des zweiten Quartals vor Augen, das Entwicklungsteam strebt das Ende des zweiten Quartals an.
Das letzte Beispiel zeigt eindringlich, dass ein so häufiger Begriff wie Q2 dazu führt, dass wir bis zu 90 Tage Diskrepanz in der Bedeutung eines bestimmten Begriffs haben. Das ist ziemlich viel... Deshalb ist eine gemeinsame Sprache so wichtig, und sie kann verbessert werden, indem man einfache Fragen stellt:

„Bis wann sollte eine bestimmte Funktion nachgewiesen sein — was ist das genaue Datum?“
„Worauf basiert dieses spezielle Datum?“
„Welche der Funktionen des Projekts ist am wichtigsten?“
„Was passiert, wenn eine bestimmte Funktion nicht rechtzeitig bewiesen wird?“

‍
Ein System, das den erhöhten Traffic am Black Friday bewältigen soll, das 2 Tage später ausgeliefert wird, ist bereits nutzlos. Es lohnt sich also, den Zeitrahmen und den nächsten Punkt bei der Entwicklung einer bestimmten Software zu kennen:

‍

2) Der Zweck des Projekts

Entwickler „schließen gerne Aufgaben“. Sie erhalten eine bestimmte Benutzergeschichte, schätzen, schreiben Code und schließen die Aufgabe. Auf den ersten Blick sieht alles in Ordnung aus, aber es kommt vor, dass die Aufgabe nicht spezifiziert ist oder mit einer anderen Aufgabe „zusammenfällt“. In einer solchen Situation lohnt es sich, Fragen zu stellen:

„Welches Problem versucht unser Projekt zu lösen?“
„Wie trägt die Aufgabe zur Lösung dieses Problems bei?“
„Ist sich das Unternehmen der Inkonsistenzen zwischen den Aufgaben bewusst?“
„Ist die angegebene Lösung so konzipiert, dass sie das Unternehmen oder den Endverbraucher zufrieden stellt?“
„Kenne ich einen besseren Weg, dieses Problem zu lösen?“

‍
Oft fragte sich das gesamte Team: „Wie wird diese Aufgabe zum Wohl des gesamten Projekts beitragen?“ Oft entdeckten wir von Geschäfts- und Entwicklerseite aus eine völlig andere Perspektive auf das Problem, die uns zuvor nicht bewusst war. Da wir den Zweck des Projekts kennen, können wir als Entwickler auch bessere Lösungen finden:

Problem -> Das Unternehmen möchte, dass die Standardsprache der Anwendung Englisch ist. Auf jedem Bildschirm muss ein Menü zum Ändern der Sprache angezeigt werden.

Vorschlag des Teams -> Wir können die auf dem Gerät des Benutzers verwendete Sprache abrufen und so die Sprache in der App festlegen, die in den Einstellungen geändert werden kann. Eine kleine Änderung, aber für eine App, deren visuelle Ebene extrem wichtig war, war das Ausblenden des Sprachauswahlmenüs wichtig.

Manchmal lohnt es sich, uns zu fragen: „Warum?“ bevor wir eine Aufgabe übernehmen. Möglicherweise stellen wir eine Inkonsistenz zu den Projektzielen fest, und es könnte sich lohnen, mit unserer Sichtweise zur Sache zurückzukehren. Fragen Sie nach dem Ursprung der Aufgabe und ob die Aufgabe in ihrer aktuellen Form mit dem Projektziel übereinstimmt. Es sind nur ein paar Minuten Konversation, und es kann viele Stunden Programmieren ersparen, und es wird dazu beitragen, die Kommunikation mit dem Unternehmen zu verbessern, was der nächste Punkt ist.

‍

3) Kommunikation mit dem Unternehmen

Es wird gesagt, dass gute Kommunikation der Schlüssel zu einem erfolgreichen Projekt ist, und ich stimme voll und ganz zu. Wenn ich mir Geschichten über „tragische Projekte“ anhöre, wird sehr oft als Problem die schlechte Kommunikation mit dem Unternehmen erwähnt. Was heißt das eigentlich? Aus eigener Erfahrung kann ich einige der Probleme auflisten, die ich hatte:

Die Wirtschaft hat Angst, mit dem Entwicklungsteam zu sprechen.
Entwickler haben Angst, mit Unternehmen zu sprechen.
Chaos in den Kommunikationskanälen - ich bin mir nicht sicher, was ich tun soll.
Viele Arten von Geschäften — ich bin mir nicht sicher, was wichtiger ist.
Die Wirtschaft legt unrealistische Fristen fest.
Die Wirtschaft versteht unsere Technologie nicht.
Die Antwort auf die Punkte 1, 2, 3 besteht darin, gemeinsame Kommunikationskanäle einzurichten. Es ist wichtig, dass es einen gemeinsamen Kanal gibt. Es ist gut für andere Projektmitglieder, die Diskussionen verfolgen und zu ihnen beitragen zu können. Ein einziger Kommunikationskanal stellt sicher, dass Bugs oder Uploads nicht im Spam-Bereich eines privaten Postfachs untergehen, und wenn jemand die Farbe der Buttons in der gesamten Anwendung ändern möchte, kann jeder nachlesen, warum, sodass er eventuell etwas dazu sagen kann. Es lohnt sich, den Grundsatz zu übernehmen, dass wir nur ein Ziel verfolgen und dass der Erfolg des Projekts von gemeinsamen Anstrengungen abhängt.

Die Punkte 4, 5, 6 können gelöst werden, indem nach dem Ende des Sprints „Demos“ für mehr Stakeholder/Unternehmen organisiert werden. Es ist auch wichtig, die Prioritäten für den aktuellen und den nächsten Sprint oder den Zugriff von Unternehmen auf Jira zu besprechen (nur lesen ist ausreichend). Wenn es Schwierigkeiten gibt, kannst du zeigen, womit das Team gerade zu kämpfen hat. Ich hatte die Gelegenheit zu beobachten, wie nach einer gemeinsamen Demo Vertreter relativ unabhängiger Unternehmen untereinander festlegen, wessen Funktionalität wichtiger ist, und es manchmal schaffen, den gemeinsamen Teil herauszuholen und alle sind zufrieden?

Technische Kennzahlen in einem Projekt sind sehr wichtig. Es ist gut zu wissen, welche Testabdeckung wir haben oder wie hoch der Prozentsatz erfolgreicher Implementierungen ist. Durch das Prisma der Projektdauer betrachte ich jedoch auch, wie die Zusammenarbeit mit dem Unternehmen verlaufen ist. Es lohnt sich, nach Abschluss des Projekts einen gemeinsamen Rückblick zu machen und herauszufinden, was in der Kommunikation gut gelaufen ist und was noch verbessert werden kann. Am Ende des Tages stehen Menschen hinter den Projekten, nicht nur Kennzahlen. Lassen Sie uns diese Zusammenarbeit fruchtbar machen und gute Emotionen wecken.

Das wünsche ich allen, dass die Zusammenarbeit zwischen dem Entwicklungsteam und dem Unternehmen reibungslos und natürlich verläuft. Mauern und starre Unterteilungen in agilen Methoden zu bauen nützt wenig — es lohnt sich hinzuzufügen, dass eine gemeinsame oder allgegenwärtige Sprache die Softwareentwicklung erheblich erleichtert, wie Eric Evans in seinem Buch über DDD schrieb.

Ps. Es lohnt sich hinzuzufügen, dass dies meine subjektiven Gedanken sind, ebenso viele Teams wie viele Probleme und Lösungen. Bei agilen Methoden übernehmen verschiedene Personen unterschiedliche Verantwortlichkeiten, und es ist durchaus möglich, dass ein Programmierer in großen Teams möglicherweise nicht einmal Zugang zum Geschäft hat. Ich denke jedoch, dass es sich lohnt, solche künstlichen Wände einzureißen, und früher oder später wird die Distanz zwischen Programmierern und dem Unternehmen kürzer — das kommt meistens gut heraus.

Hab einen schönen Tag! 🙂