Zusammenarbeit mit einem Software-Partner? Ja, aber dann richtig! 4 Grundmodelle für ein konstruktives miteinander.

In diesem Beitrag erfährst Du:

• Wann Du mit einem Software-Partner zusammenzuarbeiten solltest
• Wie Du den richtigen Software-Partner findest
• Welche Herausforderungen die Zusammenarbeit mit einem Software-Partner stellt
• In welchen Situationen Du wie mit einem Software-Partnern zusammenarbeiten solltest
• Welche Erfolgsfaktoren eine effiziente und effektive Zusammenarbeit gewährleisten

Warum mit einem Software-Partner zusammenarbeiten?

Du solltest Dir überlegen, was die Gründe sind, welche Dich veranlassen eine Zusammenarbeit mit einem Software-Partner in Betracht zu ziehen. Wenn Du Dir Über die Gründe im Klaren bist, dann kannst Du sehr viel gezielter auf die Suche nach dem richtigen Partner gehen und von Anfang an den richtigen Setup auswählen.

Jetzt denkst Du Dir vielleicht, dass der Software-Partner dann schon weiss, was der richtige Setup ist. Wie optimal zusammengearbeitet werden soll. Also warum solltest Du Dir das im Vorfeld überlegen?

Ja, der Software-Partner hat sicher eine ganz genaue Vorstellung, wie die Zusammenarbeit gestaltet werden soll. Nur: Der Software-Partner hat wahrscheinlich eine etwas andere Sicht auf die Zusammenarbeit und verfolgt natürlich auch eigene Ziele.

Deshalb solltest Du Dir im Vorfeld genau überlegen, was die Deine Gründe und Ziele sind, mit dem einem Partner zusammenzuarbeiten. Nachfolgend eine (nicht abschliessende) Liste von Gründen und Zielen:

• Du brauchst kurzfristig und temporär für ein Projekt mehr Manpower im Entwicklungsteam.
• Du möchtest ein ganzes System oder Teilsysteme extern entwicklen lassen. Dies weil Du keine eigene Software-Entwicklung hast, oder Dir die Kapazitäten fehlen.
• Du brauchst zu einem spezifischen Thema Expertenwissen, welches Du Dir mit Deinen Leuten nicht selber erarbeiten kannst oder möchtest.
• Du möchtest Deine Entwicklung längerfristig erweitern und suchst Dir dafür einen externen Entwicklungspartner. Vielleicht, weil Du damit flexibler auf Schwankungen in der Auslastung reagieren möchtest, oder weil Du von den reduzierten Kosten einer Near- oder Off-Shore Entwicklung profitieren möchtest.

Da gibt es sicher noch mehr Gründe und Ziele… Auf jeden Fall macht es in solchen Fällen Sinn eine Partnerschaft zu prüfen. Aber nicht jede Situation hat die gleichen Anforderungen an eine externe Unterstützung.

Was wichtig ist:

Wenn du mit externen Partnern zusammenarbeitest, solltest Du dadurch keine unnötige Komplexität in Deine Entwicklung einbringen.

Das passiert leider häufig. Damit verpufft der Unterstützungseffekt. Erkennen kannst Du das, wenn der Nutzen der externen Unterstützung von den Beteiligten stark in Frage gestellt wird. Äusserungen wie «dieser Partner bringt nichts» oder «mit diesen Externen sind wir noch langsamer» sind dann an der Tagesordnung. Verhindern kannst Du das indem Du die Zusammenarbeit transparent und zielgerichtet aussetzt – was der Zweck dieses Beitrages ist.

Der zweite wichtige Punkt ist:

Du solltest sicherstellen, dass auch nach dem Einsatz des Software-Partner auf dessen Ergebnisse basierend weiterentwickelt werden kann.

Ob Du mit internen Leuten darauf basierend weiterentwickeln möchtest, oder Du gar vielleicht einen anderen Partner einsetzen möchtest, Du solltest das auf jeden Fall sicherstellen. Zu solchen und ähnlichen Fragen, solltest Du Antworten haben:

• Hat der Software-Partner die internen Entwicklung-Richtlinien wie z.B. Codier-Richtlinien verwendet?
• Mit welchen Tools hat der Software-Partner verwendet um Ergebnisse zu erstellen? Könnt Ihr diese mit Euren Tools weiterverarbeiten?
• Wie wurden die Ergebnisse versioniert? Könnt Ihr auf die Historie zugreifen?
• Wie wurden Architektur- und Designentscheidungen und dessen Dokumentationen erstellt?
• Sind die Tests, welche erstellt wurden in Eure Test-Umgebung integrierbar?
• …

In diesem Beitrag habe ich Dir die verschiedenen Modelle für eine Zusammenarbeit mit externen Partnern zusammengestellt. Ich werde die Unterschiede der Modelle beleuchten und Dir aufzeigen, wann welches Modell am geeignetsten ist. Ausserdem wirst Du die Erfolgsfaktoren kennenlernen, um eine effiziente und effektive Software-Entwicklung mit externen Partnern zu erreichen. 

Starten wir mit dem einfachsten Modell:

Skalierung

Dieses Modell ist dann zu verwenden, wenn Du Deine bestehende Entwicklung in Bezug auf Manpower verstärken musst. Solche Situationen ergeben sich häufig aus den folgenden Gründen:

• Du musst die Termineinhaltung sicherstellen.
• Du musst Verzögerungen aufholen.
• Zusätzliche Anforderungen führen zu Mehraufwand, welche Du mit den zusätzlichen Ressourcen abgefangen möchtest.
• Du hast nicht genügend eigene Mitarbeiter aufgrund von Abgängen oder Auslastung durch andere Projekte und Aufgaben.
• Du findest aufgrund des Fachkräftemangels keine Leute für Deine offenen Stellen.

Das folgende Diagramm zeigt, wie dieses Modell in einem agilen Setup funktioniert. Die drei wesentlichen Parteien sind Kunde (Customer), eigene Entwicklung (Development) und der Software-Partner. Bei der Entwicklung einer eigenen Software könnte der Kunde auch im selben Unternehmen sein.

Wichtig bei dieser Art der Zusammenarbeit ist, dass durch die externe Unterstützung wenig zusätzliche Komplexität in die Entwicklung reinkommt. D.h. die externen Mitarbeiter sollen so weit wie möglich wie interne Mitarbeiter behandelt werden und die gleichen Prozesse und Standards befolgen. In einem agilen Setup bedeutet das, dass die zusätzlichen Entwickler Teil des bestehenden Scrum Teams werden.

Die Erfolgsfaktoren in einem solchen Setup sind:

• Definierte Anforderungen (auch in Form von User Stories möglich)
• Vorhandene und dokumentierte Coding- und Development-Guidelines
• Architektur-Definitionen und Dokumentationen
• Aktuelle Skill-Profile (fachlich und technisch) der Entwickler
• Guidelines & Checklisten für das Aufsetzen der Entwicklungsinfrastruktur 
• Guidelines & Checklisten für Berechtigungen & Accounts von externem Mitarbeiter
• Um die Zusammenarbeit zu reflektieren und allenfalls optimieren zu können empfiehlt es sich ein regelmässiges Steering Meeting mit dem Verantwortlichen des Software-Partners aufzusetzen 

Kommen wir zum 2. Modell:

Expertise

Dieses Modell solltest Du nutzen, wenn Du zu einem bestimmten Thema keine eigene Expertise hast und Dir deshalb diese von einem oder mehreren Experten holen musst. Im Gegensatz um «Skalierungs-Modell» macht es hier keinen Sinn die Experten ins Team reinzunehmen. Meine Empfehlung ist hier einen «Single Point of Contact» zu installieren, welcher die Zusammenarbeit mit dem oder den Experten koordiniert. Dieser SPOC sollte mit den Experten eine auftragsbasierte Zusammenarbeit aufsetzen und unterhalten. Je nach Situation können das unterschiedliche Resultate sein, die so ein Experte oder ein Expertenteam zu liefern hat. In jedem Fall sind die Resultate jedoch vorab zu definieren damit eine effektive Zusammenarbeit möglich ist. Das Einbinden der Resultate von den Experten geschieht dann wieder intern über den SPOC ins Entwicklungsteam.

Das folgende Diagramm veranschaulicht dieses Modell:

In diesem Modell sind die folgenden beiden Faktoren essenziell: 

• Klare Auftragsdefinition zu dem/den Experten welche sämtliche relvanten Aspekte umfassen sollte. Abhängig vom Auftrag können das funktionelle Anforderungen, Qualitätsanforderungen oder gar Vorgehensprozesse sein.
• Definition eines «Single Point of Contact», welcher die effiziente und effektive Zusammenarbeit mit dem/den Experten sicherstellt.

Auslagerung von Paketen, Teil- oder Gesamtsystemen

Dieses Modell kommt dann zum Einsatz, wenn Du definierte Aufgabenpakete, Teilsysteme oder Gesamtsysteme extern umsetzen lassen möchtest. Die Gründe dafür sind vielfältig:

• Du hast einen enormen Skalierungsbedarf Deiner Entwicklung und brauchst gleich ganze Teams 
• Du möchtest von den reduzierten Stunden- oder Tagessätzen einer Near- oder Offshore Entwicklung profitieren
• Du möchtest Teilsysteme oder ganze Systeme extern entwickeln lasen, für welche Du nicht das notwendige Knowhow intern hast
• Du hast gar keine eigene Software-Entwicklung und möchtest deshalb die Erstellung Deines Systems extern machen lassen

Bei diesem Modell ist essenziell, dass die Koordination über Anforderungen resp. in einem agilen Setup über User Stories läuft. Basierend auf einem Gesamt-Produktbacklog werden die User Stories oder Anforderungen für das oder die externen Teams selektiert und diesen zur Verfügung gestellt. Wie genau die Externen entwickeln ist nicht relevant. Wichtig ist jedoch, dass neben den inhaltlichen (fachlichen) Anforderungen über auch Qualitäts- und Lieferanforderungen definiert und abgestimmt werden. Dies geschieht im Idealfall über einen SPOC des Software-Partner, welcher sicherstellt, dass diese Anforderungen dann auch erfüllt werden.

Die Integration oder falls ein ganzes System vom Software-Partner entwickelt wird, die Verifikation und Validierung der Lieferobjekte des Partners, sollten dann wieder intern gemacht werden, um sicherzustellen, dass die Kundenerwartungen auch wirklich erfüllt werden.

Auch hier wieder die Veranschaulichung in einem Diagramm:

Falls Du keine eigene Software-Entwicklung hast, oder Deine eigene Software-Entwicklung mit anderen Projekten und Vorhaben beschäftigt ist, dann fällt das eigene Dev Team, der Scrum Master und der Sprint-Backlog weg. Im Bild ist das mit der gestrichelten Umrahmung dargestellt. Sinnvollerweise installierst Du jedoch auch in solchen Fällen einen Product Owner (oder Projektleiter), welcher einen priorisieren Backlog verwaltet und daraus die Aufgaben für den externen Partner ableitet. Auch die Rolle des Quality Officer ist in dieser Situation essenziell. Wobei üblicherweise in einem solchen Fall wohl die Product Owner und Quality Officer Rollen durch die gleiche Person übernommen werden.

Die Erfolgsfaktoren in einem solchen Setup sind:

• Definierte Anforderungen (auch in Form von User Stories möglich)
• Priorisierter Product Backlog
• Definition von Qualitäts-, Prozess- und Lieferanforderungen resp. Vorgaben zusammen mit dem Software-Partner. Dieser Punkt umfasst alles was für die spätere Weiterarbeit wichtig ist. Das sind beispielsweise:
  • Tool Vorgaben
  • Dokumentations-Richtlinien
  • Architektur- und Design Vorgaben
  • Test-Anforderungen
• Single Point of Contact aus Software-Partner Seite, welcher sicherstellt, dass die Anforderungen und Vorgaben eingehalten werden
• Bei Teilsystemen und Paketen klare und eindeutige Schnittstellen-Definitionen, um die Integration ins Gesamtsystem sicherzustellen

In einem solchen Setup macht es durchaus auch Sinn die Vorgaben zu überprüfen. Was sich in eine solchen Fall gut eignet und sehr empfehlenswert ist, ist eine Architekturüberprüfung. Diese prüft die Architektur- und Design-Vorgaben sowie die Dokumentation. Auch eine eine Software-Inspektion, macht in einem solchen Setup durchaus Sinn.

Kommen wir zum letzten Modell:

Entwicklungs-Partnerschaft

Dieses Modell ist eher selten, jedoch bei grösseren Systemen doch ab und zu anzutreffen. Im Gegensatz zu dem vorhergehenden Modell besteht hier eine direkte Abhängigkeit der Partner zum Kunden. In der Entwicklungs-Partnerschaft ist definiert, welcher Partner welche Teile des Systems baut und liefert. Durch klar definierte meist standardisierte Schnittstellen funktioniert ein solcher Setup. Die Integration der Teilsysteme zum Gesamt-System geschieht dann beim Kunden. Hier braucht es jedoch eine Koordination und ein Steering der Aktivitäten damit am Ende ein konsistentes und funktionsfähiges Gesamtsystem entsteht.

Dieses Setup ist in folgendem Diagramm veranschaulicht:

Die Erfolgsfaktoren hierbei sind:

• Koordination fachlich und technisch durch ein Projektteam sicherstellen
• Klare idealerweise standardisierte Schnittstellen welche eine einfache Integration der Teilsysteme erlaubt
• Sinnvolle vertragliche Regelungen in Bezug auf Aufgaben und Verantwortlichkeiten sowie allenfalls Prozess- und Qualitätsanforderungen / Vorgaben.

Wie solltest Du vorgehen?

Die hier gezeigten Modelle sind Grundmodelle. In konkreten Fällen können Kombinationen oder Varianten davon sinnvoll sein.

Aus meiner Erfahrung empfiehlt es sich folgendermassen vorzugehen, wenn Du einen Software-Partner benötigst:

1. Mach Dir Deine Gründe und Ziele welche zur Zusammenarbeit mit einem Software-Partner führen klar.

2. Wähle den richtigen Setup basierend auf den Modellen in diesem Beitrag.

3. Visualisiere Deinen Ziel-Setup in einem Diagramm.

Schreibe mir eine E-Mail und ich sende Dir die Diagramme von diesem Beitrag als editierbares Powerpoint.

4. Stelle sicher, dass die Erfolgsfaktoren zu dem gewählten Modell, welche Eure Seite betreffen, erfüllt werden können

5. Suche Dir einen Software-Partner basierend auf Deinem Ziel-Setup

Bei uns in der Schweiz könntest Du z.B. hier mit Deiner Suche beginnen: https://www.swissmadesoftware.org.

6. Verfeinere und konkretisiere zusammen mit dem ausgewählten Partner Euren Ziel-Setup.

7. Stelle zusammen mit dem Software-Partner alle Erfolgsfaktoren sicher

Was noch?

Was natürlich neben diesen Zusammenarbeitsthemen auch wichtig ist, sind die vertraglichen Abmachungen mit dem Software-Partner. Dazu möchte ich in diesem Beitrag nicht weiter eingehen. Aus meiner Erfahrung macht ein transparentes, effizientes und effektives Zusammenarbeitsmodell auch die vertraglichen Verhandlungen und Abmachungen viel einfacher.

Falls Du Fragen zu dem Beitrag hast, dann schreib mir einfach – gerne helfe ich dir weiter. Weiteres zu einer Software-Entwicklung wie eine geölte Maschine findest Du hier: Geölte Softwareentwicklung.

Viel Erfolg bei Deinen Software-Projekten

Matthias