- Wenn Entwickler Nein sagen, hilft der richtige Umgang damit Produktmanagern dabei, ihre Verantwortung wahrzunehmen und Ziele zu erreichen
- Wenn sie sagen, dass eine Funktion aus technischen Gründen nicht innerhalb des vorgegebenen Zeitrahmens umgesetzt werden kann, können die richtigen Fragen helfen, die Situation zu lösen
1. Gibt es andere technische Lösungsansätze, um die Funktion zu bauen?
- Es gibt viele Wege, eine Funktion zu bauen, und der erste Ansatz ist nicht immer der beste
- Entwickler wollen oft mit den neuesten Technologien beeindruckende Funktionen bauen, doch das kann statt einer Optimierung auf Einfachheit zu Overengineering führen
- Entwickler mit einem bestimmten technischen Stack erkennen möglicherweise einfachere Lösungen außerhalb ihres eigenen Wissensbereichs nicht
- Deshalb ist es sinnvoll, Ingenieure dazu anzuregen, kreativer über technische Lösungen nachzudenken
- Einige der besten Produktmanager, mit denen ich gearbeitet habe, hatten genug technisches Verständnis und Wissen über die technische Landschaft, um mit klugen Fragen dazu beizutragen, dass Ingenieure über den Tellerrand hinausdenken
2. Wie würden Sie eine Lösung vorschlagen, wenn Sie mit genau diesen Einschränkungen arbeiten müssten?
- Wenn Entwickler Einwände gegen die von Ihnen vorgeschlagene Lösung haben, bitten Sie sie um ihren eigenen Lösungsvorschlag
- Entwickler sind eine Quelle von Kreativität und Innovation, und indem man nach einer einfacheren Version der Funktion fragt, gibt man ihnen die Möglichkeit, kreativ zu denken
- Wenn sie den Kern des Problems verstehen, denken Entwickler kreativ und finden Lösungen, die innerhalb der Projektgrenzen funktionieren
3. Können wir für diese Funktion einen schrittweisen Ansatz in Betracht ziehen?
- Wenn gesagt wird, dass die Implementierung einer Funktion wegen technischer Komplexität nicht möglich ist, fragen Sie, ob sich das Projekt in Phasen aufteilen und auf unterschiedliche Release-Termine verteilen lässt
- Es ist verlockend, die große Vision auf einmal liefern zu wollen, aber ein schrittweiser Ansatz ist iterativer und liefert schneller greifbare Ergebnisse
- Prioritäten können sich ändern, und ein schrittweiser Ansatz ermöglicht es, gemeinsam mit den Entwicklern abzustimmen, welche Funktion als Nächstes hinzugefügt werden sollte
4. Welche Hindernisse können wir beseitigen oder lösen, damit die Arbeit möglich wird?
- Diese Frage zielt auf ressourcenbezogene Einwände ab: Wenn Entwickler begrenzte Ressourcen als Grund nennen, etwa Zeit oder verfügbare Entwickler, sollte man proaktiv Arbeit entfernen, um Kapazitäten freizumachen
- Mögliche Wege: Aufgaben komplett streichen, Arbeiten selbst übernehmen, für die kein Entwickler nötig ist, die Kommunikation mit anderen Teams und/oder Dritten übernehmen oder den Prozess verantworten und Legacy-Funktionen abschaffen, um die Arbeit zu erleichtern
Fazit
- Es kann unangenehm sein, bei einem „Geht nicht“ von Entwicklern nachzuhaken, aber dadurch kann man mehr Respekt gewinnen
- Man sollte etwas tiefer nach den Gründen fragen, warum Ingenieure Einwände haben, diese verstehen und die Gegenargumente eines nach dem anderen ausräumen
- All diese Fragen sind gut, weil sie die spezifischen Schwierigkeiten und Einschränkungen anerkennen, mit denen Ingenieure bei der Umsetzung einer bestimmten Funktion konfrontiert sein können
- Sie machen außerdem deutlich, dass man bereit ist, selbst mit anzupacken, unangenehme Aufgaben zu übernehmen oder Anforderungen und Zeitpläne anzupassen, um dem Team und dem Projekt zu helfen
8 Kommentare
Letztlich kommt es darauf an, wie man es abstimmt
Danke für den guten Inhalt
Wenn man mit den oben genannten Punkten nachfragt, lässt sich wohl schnell herausfiltern, ob jemand einfach nur keine Lust hat und deshalb "No" sagt
Als PM/PO haben mir bei der Koordination zwischen Fachbereich und IT-Abteilung in Projekten zwei Vorgehensweisen geholfen.
Natürlich setzt das voraus, dass sowohl der Fachbereich als auch die IT „vernünftig miteinander reden“ können.
Erstens: schrittweise vorgehen.
Zweitens: den Umfang verkleinern.
Das sind die beiden Punkte.
Die größte Schwierigkeit bei Projekten im Fachbereich oder in der IT ist die „Zeit“.
Die Frist steht fest, und sehr oft ist das Volumen in dieser Zeit nicht zu schaffen.
In so einem Fall geht man „schrittweise“ vor. Also mit aufeinanderfolgenden Zeitplänen wie Phase 1, 2, 3 ... Die wichtigsten Funktionen in Phase 1, die weniger wichtigen in Phase 2 usw.
Wenn es aber Projekte gibt, die sich nicht so stufenweise umsetzen lassen, also auf einmal live gehen müssen,
muss man den Umfang an die „Zeit“ anpassen und reduzieren. Von dem, was eigentlich in Phase 1, 2 und 3 käme, muss alles außer den „wirklich nötigen Funktionen“ gestrichen werden.
Mit diesen zwei Vorgehensweisen stimmen die meisten „verständigen Fachbereiche/IT-Abteilungen“ in der Regel zu.
Immer noch besser, als dass das Projekt scheitert und jeder von seinem Vorgesetzten Ärger bekommt ...
Tja.
Kopf hoch, alle zusammen^^
PS:
Zum Schluss noch eine kleine Würze.
Auch wenn man die beiden Methoden oben anwendet, reagieren Entwickler oft noch zögerlich.
Dann hilft oft Folgendes:
„Lassen Sie uns etwa zur Mitte der Projektlaufzeit noch einmal prüfen. Wenn es so aussieht, als bräuchten wir mehr Zeit, übernehme ich die Verantwortung und sorge für eine Verlängerung.“
Dann entspannt sich der Gesichtsausdruck der Entwickler oft deutlich.
Und wenn wir dann zur Halbzeit geprüft haben, brauchten wir in 95 % der Fälle doch keine zusätzliche Zeit.
Außerdem geht es oft ziemlich schnell, sobald Entwickler einmal mit dem Coden angefangen haben.
Als jemand, dessen Rolle Abstimmung mit Entwicklern erfordert, würde ich gern mit Entwicklern arbeiten, mit denen solche Gespräche möglich sind. Bisher habe ich leider nur Entwickler erlebt, die erst einmal sagen, dass etwas nicht geht. Wenn man dann hier und da nachhakt und nachfragt, stellt sich meist heraus, dass es einen Weg gab, den sie selbst nicht kannten …
Hahahahahaha, das tut weh..
Fragen, die sich Ingenieurinnen und Ingenieure stellen sollten, bevor sie "NEIN" sagen.
Das sind wirklich gute Fragen, die ich mir auch selbst stellen sollte.
Ingenieurinnen und Ingenieure sind eben vor allem Menschen. Ich stimme zu, dass ein reflexhaftes Nein als Ingenieur problematisch ist, aber wenn PMs/POs solche Fragen im Hinterkopf haben, dürfte das eine große Hilfe sein.