Verträge über Inputs und Outputs zwischen Teilsystemteams?

Du brauchst keine Verträge. Sie benötigen klar definierte Anforderungsdokumente für jede zu erstellende Leistung. Diese sollten gemeinsam von mindestens drei Teams geschrieben werden:

• Das Team, das das Ergebnis verwenden wird
• Das Team, das das Ergebnis erstellen wird
• Das Team, das den Input für das Ergebnis liefert

Das Endergebnis sollte eine Reihe sich überschneidender Dokumente sein, die klare Verantwortlichkeiten für die Bereitstellung der erforderlichen Anforderungen und Ergebnisse für jede Leistung liefern.

Dieses kollaborative Dokument sollte vom PM und seinem Team überprüft werden, um sicherzustellen, dass keine Goldplattierung stattfindet, die Leistung innerhalb des Umfangs liegt, die Qualitäts- und Abnahmekriterien klar sind, Rollen definiert sind usw. usw. Ein gutes Beispiel ist die Arbeitspaketvorlage von PRINCE2. Diese und andere Vorlagen erhalten Sie [hier]. 1

Die Antwort ist ein eindeutiges Ja. Wenn der Input von einem externen Anbieter stammt, haben Sie sicherlich eine Vereinbarung in Bezug auf Menge, Qualität, Spezifikationen, Kosten usw. getroffen. Warum sollte es anders sein, wenn die Eingabe von einer internen Quelle käme?

Jetzt würden die meisten vertraglich eine Art Papiervereinbarung mit Unterschriften annehmen. Einige Teams könnten so etwas verlangen, zB wenn Sie Organisationsabteilungen überqueren, während andere eine einfache mündliche Vereinbarung und einen Handschlag erfordern würden. Viele Team-Chartas können bis zu einem gewissen Grad auch Einsatzregeln festhalten.

Wie auch immer, wenn Sie den Anforderungen innerhalb des Teams nicht zustimmen, verwalten Sie die Arbeit nicht.

Ja, Sie sollten auf jeden Fall eine schriftliche Spezifikation haben, in der die Schnittstelle zwischen den Subsystemen beschrieben wird. Dies bildet den Vertrag zwischen den beteiligten Teams. Beide (alle) sollten an der Erstellung der Spezifikation beteiligt sein. Abhängig von Ihrem Dokumentationsstil kann dies eine Wiki-Seite oder ein anderes Online-Dokument sein.

Einige der Dinge, die ich behandeln würde, sind:

• Format(e) der Daten.
• Übertragungsmethode (Datei, SOAP, REST, andere).
• Stapelgrößen, wenn Daten im Stapel übertragen werden.
• Erwartete Antwortzeit (insbesondere für Schnittstellen, auf die für OLTP zugegriffen wird).
• Verfügbarkeitsplan.

Ich kann mir das Problem vorstellen, auf das Sie sich beziehen, und ich stimme zu, dass es sich lohnen könnte, es proaktiv zu lösen. (Proaktive Lösungen umfassen Governance/politisches Kapital/Stakeholder-Management. In manchen Umgebungen sind politisches Kapital und Governance außerordentlich teuer, sodass es langfristig billiger sein kann, Fehler einzuplanen und das Problem rückwirkend zu lösen).

Auf den ersten Blick ist dies entweder ein Qualitätsproblem oder ein Risikoproblem. Team A füttert Team B; Team B muss die gewünschten Qualitätsstandards zum Ausdruck bringen, und Team B muss planen, die Risiken zu mindern, wenn die Qualitätsstandards nicht erfüllt werden. Wie @David Espina sagt: Wenn Sie die (teaminternen) Anforderungen nicht verwalten, verwalten Sie die Arbeit nicht. Wenn wir über Protokolle, Inputs und Outputs sprechen, dann zwingt uns der gemeinsame Wunsch nach einem hervorragenden Ergebnis dazu, sehr detaillierte Informationen über Erwartungen auszutauschen.

Beinhaltet das ein formelles SLA für die Teams? Das hängt von den beteiligten Beziehungen ab. Wenn die Teams eng und kooperativ sind, kann ein formelles SLA tatsächlich Innovation und verbesserte Qualität hemmen. Ich werde nervös, wenn Sie den Begriff "Zwang" einführen, weil ich denke, dass die Zusammenarbeit wahrscheinlich wichtiger ist als die tatsächliche Qualität eines Teils. Wenn Sie nicht die Absicht haben, zusammenzuarbeiten und sich gegenseitig exzellent aussehen zu lassen, haben Sie möglicherweise ein XY-Problem , aber vielleicht lese ich da zu tief.

Verlassen Sie den agilen Tenor, sich weniger auf die Dokumentation und mehr auf die Menschen zu konzentrieren, anstatt auf einen Vertrag zu schauen, um zu spezifizieren, was benötigt wird, und konzentrieren Sie sich auf die Einrichtung einer Umgebung, die eine offene, konsistente und genaue Kommunikation fördert.