Soll ich die Entwickler in die offizielle E-Mail-Kommunikation mit Kunden einbeziehen?

TL;DR

Soll ich die Entwickler in diese E-Mails aufnehmen oder nicht?

Eine verstärkte direkte Kommunikation kann, wenn sie effektiv durchgeführt wird, die Durchführbarkeit eines Projekts verbessern. Allerdings gibt es oft Vor- und Nachteile, die es zu beachten gilt. Vieles hängt von Ihrem Projektmanagement-Framework, Ihrem Projektkommunikationsplan und von der Art der Beziehung ab, die Sie zu Ihrem Kunden haben. Kurz gesagt, Ihre Laufleistung kann variieren.

Direkter Kontakt mit agilen Frameworks

Das Agile Manifest empfiehlt direkte Interaktionen und die Zusammenarbeit mit Kunden, wann immer dies möglich ist. Dies steht oft im Gegensatz zu traditionelleren Projektmanagement-Frameworks, die formelle Kommunikationspläne und sorgfältig verwaltete Kundenkommunikation schätzen.

Im XP-Framework wird der direkte Kontakt zwischen dem Entwicklungsteam und den Kunden sowohl erwartet als auch für den Erfolg benötigt. Betrachten Sie den folgenden Ausschnitt:

Eine der wenigen Anforderungen von Extreme Programming (XP) ist die Verfügbarkeit des Kunden. Nicht nur um dem Entwicklungsteam zu helfen, sondern auch ein Teil davon zu sein. Alle Phasen eines XP-Projekts erfordern die Kommunikation mit dem Kunden, am besten von Angesicht zu Angesicht, vor Ort.

In Scrum vertritt der Product Owner manchmal den Kunden, während der Product Owner zu anderen Zeiten angemessene Interaktionen zwischen dem Kunden und dem Entwicklungsteam ermöglicht . Sowohl Proxy- als auch direkte Kommunikationsmethoden haben ihre Vor- und Nachteile, und keiner der beiden Ansätze wird vom Scrum-Framework tatsächlich vorgeschrieben.

Es gibt immer Nachteile

Eine unvermittelte Schnittstelle zwischen Kunden (oder Endbenutzern) und dem Entwicklungsteam ist im Allgemeinen das Richtige™ für reife agile Teams, aber es kann durchaus Gegenanzeigen geben. Zum Beispiel:

1. Teams oder Kunden mit geringer Prozessreife benötigen oft einen Mediator.
2. Entwicklungsteams mit schlechten Kommunikationsfähigkeiten oder Teammitglieder mit erheblichen Persönlichkeitsdefiziten sollten nicht kundenorientiert sein.
3. Kunden, die keinen kooperativen, verhandlungsbasierten oder auf Gegenseitigkeit basierenden Ansatz zur Produktlieferung an Bord haben, sollten vom Entwicklungsteam isoliert werden.
4. Projekte, die auf einem „Big Up-Front Design“ basieren oder sich auf detaillierte Spezifikationsdokumente stützen, sind oft darauf ausgelegt, die laufende Kommunikation zu minimieren.

Ob die Vorteile einer verstärkten direkten Kommunikation die potenziellen sozialen, politischen oder vertraglichen Konsequenzen überwiegen oder nicht, muss jedes Projekt für sich selbst bestimmen. Auf diese komplexe Überlegung gibt es einfach keine allgemeingültige Antwort.

E-Mail als Medium zum Erfassen, Dokumentieren und Verbreiten von Anforderungen ist eine schlechte Idee

1. Entwickler sind nicht in der Kunst des diplomatischen Umgangs mit Kunden geschult. Wenn Sie sie in die E-Mail aufnehmen, werden sie antworten, wie sie es für richtig halten, und Sie können sich mit der Schadensbegrenzung befassen.
2. Die Annahme, dass das gesamte Entwicklungsteam alle Anforderungen aufgrund von E-Mails hin und her irgendwie aufnimmt, ist naiv.
3. Möglicherweise bereiten Sie sich auf unangenehme Streitigkeiten mit Ihren Kunden darüber vor, was genau Sie zu liefern versprochen haben.

Sie brauchen eine bessere Möglichkeit, Anforderungen zu erfassen. Wenn Sie dem Wasserfall-Prozess folgen, verwenden Sie die E-Mail-Kommunikation mit den Kunden als Informationsquelle dafür, was in das Anforderungsdokument aufgenommen wird, das Sie vom Kunden genehmigen lassen. Danach sollten alle Änderungen über die Änderungskontrolle behandelt werden.

Ich empfehle jedoch dringend, dem Scrum-Prozess zu folgen. Benennen Sie einen Product Owner (PO) auf Ihrer Seite, um diese Kommunikation mit dem Kunden zu führen, um sein Geschäftsziel zu verstehen und zu verstehen, was einen Erfolg bei dem ausmachen würde, was Sie alle aufbauen möchten. Dann sollte diese PO in der Lage sein, mit dem Entwicklerteam zusammenzuarbeiten, um User Stories in Form von zu schreiben

Als [Benutzertyp] möchte ich [irgendein Ziel], damit [irgendein Grund].

Und schreiben Sie auch überprüfbare Akzeptanzkriterien für jede solche User Story.

Hier ist die Meinung von Roman Pichler, Autor von Agiles Produktmanagement mit Scrum, zur PO-Rolle in kleinen Teams. Sie werden es in den Fragen und Antworten unter dem Blogbeitrag sehen: „Ich habe mit einigen Teams zusammengearbeitet, in denen eines der Teammitglieder erfolgreich die Rolle des Product Owners gespielt hat. Im Allgemeinen finde ich die Kombination der Rollen herausfordernd.“

Die Rollen spielen keine Rolle. Wichtig ist, wer davon profitiert und welche Vorteile der Empfang der Nachricht im Vergleich zu den Kosten, Risiken und Strafen hat.

Sie sollten in der Lage sein zu artikulieren, dass, wenn die Entwickler in der Kommunikationsschleife sind, der Empfang einer Nachricht spezifische Vorteile für ihre Arbeit hat. Der Nutzen kann sogar indirekt und immateriell sein, wie das Gefühl, beteiligt zu sein, Bescheid zu wissen und Transparenz. Das Einbeziehen der Entwickler kann jedoch Kosten, Risiken und Strafen verursachen, z. B. eine tatsächliche Erhöhung der Dollars, um sie einzubeziehen, das Risiko, dass eine Art von Missverständnissen oder Meinungsverschiedenheiten auftreten kann, die wirklich nicht erforderlich waren, oder dass die Informationen wirklich nicht das sind vorteilhaft und Sie trainieren Ihre Entwickler langsam, E-Mails zu ignorieren, wodurch sie etwas ignorieren, was sie nicht haben sollten.

Wenn Sie durchdachte Kommunikationspraktiken wünschen, müssen Sie über diese Dinge nachdenken. Wenden Sie nicht einfach eine einfache Richtlinie zum Einschließen oder Ausschließen an – wie dies wahrscheinlich die meisten von uns tun –, da die Schäden sehr hoch sein könnten.

BEARBEITEN: Basierend auf der fettgedruckten Frage zu bewährten Verfahren suchen Sie eindeutig nach der einheitlichen Antwort ... tun Sie dies zu Ihrem Nachteil. Es gibt keine solche Sache. Google ein wenig zur Zielgruppenanalyse. Es funktioniert in beide Richtungen, zum einen, um die Nachricht in Inhalt und Abstraktion zu definieren, basierend darauf, wer das Publikum ist, und zum anderen, um zu definieren, wer das Publikum sein muss, basierend auf der zu übermittelnden Nachricht oder Nachrichten, die Sie extrahieren müssen.

Ihr bewährtes Verfahren wird zeitweise funktionieren und den Rest der Zeit zu unterschiedlichen negativen Folgen führen. Die Kommunikation ist schwierig. Es erfordert etwas Nachdenken. Die Best-Practice-Antwort, die Sie brauchen, lautet: Analysieren Sie das Publikum und die Botschaft und machen Sie sie konsistent.

Mehr noch – Sie sollten Ihren Kunden und Ihr Entwicklerteam zu einem regelmäßigen Anforderungsgespräch einladen.

Ihr Kunde weiß, was zu tun ist, und Ihr Team weiß, wie es geht und wie lange es dauern wird. Ein regelmäßiges Gespräch zur Klärung der Anforderungen mit dem Team ist die beste Option.

Sie können die folgende Anrufagenda verwenden:

1. PM bringt den Kunden und das Team ins Gespräch.
2. PM teilt den Bildschirm mit dem Rückstand an Anforderungen, Mockups und anderen Details.
3. Der Klient geht durch, was getan werden sollte. Team gibt Feedback.
4. PM aktualisiert die Anforderungen im Handumdrehen direkt auf dem freigegebenen Bildschirm.
5. PM richtet bei Bedarf den nächsten Anruf zur Klärung der Anforderungen ein.

Es hängt wirklich von Ihrem Team ab, aber hier sind ein paar Gedanken:

Es ist wahrscheinlich keine gute Idee, alle Ihre Entwickler in allen E-Mail-Ketten zu haben, da nicht alle für ihre Arbeit relevant sein können. Zu viele Daten sind nur Lärm und verlangsamen Teams.

Hüten Sie sich davor, Anforderungen in E-Mail-Ketten zu verlieren. Eine E-Mail ist nicht der richtige Ort, um eine Geschichte zu definieren oder die Quelle der Aufzeichnungen für eine Umfangsänderung zu sein.

Erwägen Sie die Ernennung eines technischen Leiters oder eines Äquivalents, um E-Mails für die erste Iteration zu überprüfen, und lassen Sie ihn bei Bedarf mit anderen Entwicklern diskutieren, um Feedback darüber zu erhalten, ob das Team diese Praxis durchführen möchte. Gehen Sie von dort aus und entscheiden Sie, ob Sie wirklich alle Ihre technischen Ressourcen in kundenorientierte E-Mails einbeziehen möchten.

Stellen Sie sicher, dass Sie die Teilnehmer während der Retro- oder informellen Phase gelegentlich etwas fragen wie: „War das nützlich, waren alle RICHTIGEN Personen an der Kommunikation beteiligt?“ Seien Sie bereit, sich basierend auf Ihrem Entwickler- und Kundenfeedback entsprechend anzupassen. Es gibt Entwickler, die geschäftstüchtig sind, und es gibt Entwickler, die so weit wie möglich von Kunden ferngehalten werden sollten. Finden Sie heraus, wo Ihre Entwickler auf dieser Skala liegen, bevor Sie die direkte Kunden-Entwickler-Verbindung herstellen.

Denken Sie an die Vorteile, einen Entwickler in der Kette zu haben, im Vergleich zu den Nachteilen. Stellen Sie sich Entwickler und Kunden als unterschiedliche Zielgruppen vor. Können ihre Bedürfnisse durch diese Form der Zusammenarbeit erfüllt werden?

Das Gute daran ist, dass sie auf diese Weise die Antworten auf alle technischen Fragen selbst sehen können

Wenn dies Ihr Ziel ist, können Sie dieses Ziel erreichen, ohne zu riskieren, dass E-Mail-Interaktionen zwischen Clients und Entwicklern nach unten gehen, indem Sie die E-Mails an Ihre Entwickler weiterleiten.

(Ich mache hier auch eine Pause, um denjenigen zuzustimmen, die davor warnen, E-Mails zur Erfassung von Anforderungen zu verwenden. Sie können jedoch nützliche Hintergrund- und Kontextinformationen liefern.)

Die Situation meines Teams ist anders (meine "Kunden" sind keine externen), aber ich habe festgestellt, dass produktive Arbeitsbeziehungen zwischen Kunden und Entwicklern normalerweise einige Zeit brauchen, um sich zu entwickeln. Bei kurzen Projekten von 1-6 Monaten würde ich es vermeiden.

(Es sei denn, Sie verfolgen einen agilen, kundenintegrierten Ansatz.)