In unseren Software Requirements Specifications (SRS) haben wir eine Klausel, die besagt, dass der Benutzer in der Lage sein sollte, Push-Benachrichtigungen von der Website an die mobilen Geräte zu senden.
Sollen wir den Kunden über die Einschränkungen der Funktion informieren? Zum Beispiel:
Soll ich den Kunden darüber informieren, dass sie in Push-Nachrichten auf 128 Zeichen beschränkt sind, was bestenfalls 1-2 Sätze bedeutet?
Welches ist besser:
Wir sind derzeit an dem Punkt angelangt, an dem wir dem Kunden mindestens ein- oder zweimal am Tag eine E-Mail senden, manchmal sogar drei von vier.
Die kurze Antwort ist ja.
Sie möchten den Kunden unbedingt über Einschränkungen oder andere Fallstricke im Projekt auf dem Laufenden halten. Sie werden selten die ganze Geschichte kennen und daher nicht die Perspektive haben, um zu wissen, ob dies eine große Auswirkung haben wird.
Eine längere Antwort muss untersuchen, wie Sie dorthin gekommen sind, wo Sie sind. Ben, Miles und CodeGnome berühren dies in ihren Antworten. Ich würde das auf zwei Kernpunkte reduzieren.
1- Verbringen Sie mehr Zeit mit dem Entwerfen mit dem Kunden: Auch in agilen Prozessen müssen Sie einige Zeit damit verbringen, zu verstehen, was mit dem Kunden getan wird. Die Anforderung „sollte in der Lage sein, Push-Benachrichtigungen von der Website an die mobilen Geräte zu senden“ ist äußerst vage. Hier gibt es keinen Anwendungsfall. Was wird der Kunde vorantreiben? Wie oft? Wie unternehmenskritisch ist es? Wenn Sie verstehen, wie die Funktion verwendet wird, können Sie die Funktion besser entwerfen. Wenn Sie Scrum verwenden, bedeutet die Anwesenheit des Kunden in Ihren Sprint-Planungsmeetings, dass er Fragen in Echtzeit beantworten kann.
Zumindest müssen Sie dokumentieren, was der Akzeptanztest für diese Funktion ist. Was ist das Maß für „fertig“?
2- Haben Sie keine Angst, zu viel zu kommunizieren. Nehmen Sie es stattdessen als Teil des Projekts an. Vereinbaren Sie regelmäßige Treffen mit Ihrem Kunden (z. B. Sprint-Demos), bei denen Sie das Produkt durchgehen können. Sie können nicht nur Einschränkungen teilen, sondern ihnen auch zeigen, wie das Projekt läuft. Es kann sich herausstellen, dass sie wirklich dachten, sie wollten eine blaue GUI, aber als sie es sehen, erkennen sie, dass sie wirklich eine grüne brauchen.
Machen Sie diese Art der Kommunikation zu einem festen Bestandteil Ihres Projekts. Sie werden feststellen, dass Sie unterwegs viel weniger überrascht sind.
Ihnen scheint ein Kommunikationsplan zu fehlen , der ein wesentlicher Aspekt der meisten Projekte ist. Dieser Plan würde Details enthalten, z. B. was Ihre Stakeholder wissen müssen und wann sie es wissen müssen.
Aus einer agileren Perspektive ist eine bessere Frage, ob die Implementierungsdetails das Team daran hindern, das Ziel zu erreichen. Wenn das Sprint-Ziel für eine Iteration beispielsweise lautet:
Aktivieren Sie Push-Benachrichtigungen von der Website an Mobilgeräte.
Wie das Ziel umgesetzt werden soll, ist grundsätzlich dem Entwicklungsteam überlassen. Es gibt viele technische Lösungen für Protokoll- und Transportprobleme; Die Fragen werden im Allgemeinen auf Folgendes hinauslaufen:
Ich glaube nicht, dass Ihr Beispiel ein solcher Fall ist, aber es gibt sicherlich Zeiten, in denen eine Funktion oder ein Ziel nicht rechtzeitig, innerhalb des Budgets oder mit den Fähigkeiten oder Ressourcen, die dem Projektteam zur Verfügung stehen, implementiert werden kann. Solche Blocker sollten unbedingt rahmengerecht mit den Stakeholdern adressiert werden. Dies ermöglicht den Sponsoren des Projekts, fundierte strategische Entscheidungen zu treffen, und ist eine Schlüsselverantwortung, die dem Projektmanager oder Product Owner obliegt.
Zu bestimmen, ob etwas wirklich ein Hindernis ist oder ob es sich lediglich um eine Herausforderung handelt, die gelöst werden muss, ist das wichtigste Unterscheidungsmerkmal für die effektive Kommunikation über ein Problem. Wie Sie diese Entscheidung treffen, hängt stark von Ihrem Projektmanagement-Framework, Ihrem Kommunikationsplan und (letztendlich) dem Qualifikationsniveau und der Erfahrung ab, die die Projektleitung verkörpert. Ihre Laufleistung wird daher stark variieren.
Den Kunden auf dem Laufenden zu halten, ist nie eine schlechte Sache.
Wie Sie dies kommunizieren , sollte jedoch von den Auswirkungen der entdeckten Einschränkung abhängen.
Für den Fall, dass eine Einschränkung bedeutet, dass eine bestimmte Anforderung nicht erfüllt werden kann, würde ich dies frühzeitig mitteilen, vorzugsweise von Angesicht zu Angesicht, zusammen mit (wenn möglich) einigen Optionen, wie Sie vorgehen können, um die Anforderung zu erfüllen (vielleicht müssen Sie mehr zustimmen Zeit, Kosten für verschiedene Technologien usw.).
Entdeckte Dinge, die eine Anforderung nicht direkt gefährden, könnten Sie weniger dringend über bereits vorhandene Kanäle kommunizieren (z. B. als Teil eines regelmäßigen Statusmeetings oder eines Risiko-/Problemberichts).
Eine weitere Überlegung könnte sein, wie einfach es ist, später die Richtung zu ändern. Kommunizieren Sie aktiver Dinge, die später nur schwer wieder rückgängig gemacht werden können.
Die frühzeitige Entwicklung der Mittel und Ebenen der Kommunikation im Projekt ist ein wichtiges PM-Detail. Einige Kunden möchten jedes Detail, andere nur eine Kommunikation zu bestimmten Themen. Wenn dies nicht festgestellt wurde, ist es möglicherweise eine gute Idee, mit dem Kunden über die Häufigkeit der Kommunikation zu sprechen und zu sehen, ob er mit dem Status quo zufrieden ist oder ob er nicht dringende Probleme in einer täglichen oder wöchentlichen Kommunikation gebündelt haben möchte.
Spezifisch für diese Situation ist, dass Sie die Funktionalität nach Bedarf erstellen und Android- oder iOS-Systembeschränkungen nicht anpassen können, sodass dies nicht dringend ist, es sei denn, der Wortlaut der Klausel impliziert eine Funktionalität, die Sie nicht bereitstellen können.
Willkommen bei PM SE!
Bjarke Freund-Hansen