05 · Projektmanagement & Nearshore
Salesforce-Programmsteuerung und Nearshore-Teams
Nearshore-Teams können viel zu einem vernünftigen Preis liefern, wenn das Setup stimmt. Die meisten Probleme haben wenig mit Skills zu tun und viel mit Teamgröße, Fluktuation und Kultur. Ich plane und steuere Salesforce-Programme auf Kundenseite, inklusive Nearshore-Teams in Osteuropa und Indien.
Termin vereinbaren (öffnet Microsoft Bookings in einem neuen Tab)Typische Ausgangslage
- Ein Salesforce-Programm braucht mehr Umsetzungskapazität, als das interne Team und die aktuellen Partner liefern können.
- Ein Nearshore-Team ist im Einsatz, aber die Geschwindigkeit bleibt niedrig, und der Kunde verbringt viel Zeit mit Erklären und Korrigieren.
- Entwickler rotieren ins Team und wieder hinaus, und mit jedem Wechsel geht Wissen verloren.
- Mehrere Teams und Partner liefern parallel, und niemand plant Abhängigkeiten und Releases übergreifend.
Was ich mache
- Programmplan mit Streams, Abhängigkeiten, Meilensteinen und Release-Plan
- Team-Setup für Nearshore-Entwicklung, inklusive Größe, Rollen und Senioritätsmix
- Auswahl von Nearshore-Partnern und Vereinbarung von Regeln zu Besetzung und Rotation
- Einarbeitung in Standards, Review-Prozess und Pipeline
- Regelmäßige Steuerung mit Status, Risiken und Entscheidungen für das Management
Was Sie bekommen
- Nearshore-Teams, die stabil bleiben und Wissen über die Org aufbauen
- Planbare Lieferung über Teams und Partner hinweg
- Qualität, die in Reviews geprüft und nicht erst in Produktion entdeckt wird
- Ein Management, das Status und Risiken früh sieht und auf Basis von Fakten entscheidet
So läuft die Zusammenarbeit
- 01
Plan und Team-Setup
Ich plane das Programm mit seinen Streams und Abhängigkeiten und lege das Team-Setup fest: wie viele Entwickler, welche Rollen und welcher Senioritätsmix.
- 02
Partnerauswahl
Gemeinsam mit dem Kunden wähle ich Nearshore-Partner aus und vereinbare Regeln zu Besetzung, Rotation und Kommunikation, bevor der erste Sprint startet.
- 03
Einarbeitung
Neue Teams bekommen vom ersten Tag an Zugang zu Standards, Review-Prozess und Pipeline und arbeiten damit genauso wie alle anderen.
- 04
Steuerung
In der Umsetzung steuere ich Plan, Risiken und Qualität, halte Abhängigkeiten zwischen Teams sichtbar und berichte dem Management in einem Format, das Entscheidungen unterstützt.
Programmsteuerung auf Kundenseite heißt, ein Salesforce-Programm über interne Teams, Umsetzungspartner und Nearshore-Teams hinweg zu planen und zu steuern. Dazu gehören der Plan mit seinen Abhängigkeiten, das Team-Setup, die Steuerung von Risiken und Qualität und ein Reporting, das dem Management Entscheidungen erleichtert. Nearshore-Teams sind oft Teil davon, weil sie Umsetzungskapazität zu einem vernünftigen Preis bringen. Ich habe mit Nearshore-Teams in Osteuropa und Indien gearbeitet, und die Erfahrungen waren in beiden Regionen dieselben.
Warum tun sich Nearshore-Teams schwer?
Liefert ein Nearshore-Team weniger als erwartet, werden oft zuerst die Skills verantwortlich gemacht. Nach meiner Erfahrung liegen die Gründe woanders:
- Rotierende Ressourcen. Werden Entwickler alle paar Monate in andere Projekte verschoben, geht das Wissen über die Org mit ihnen. Jede neue Person braucht Wochen, bis sie produktiv ist.
- Hohe Fluktuation. Der Effekt ist derselbe, und sie bringt zusätzlich Unruhe in den Rest des Teams.
- Zu seniore Teams. Ein Team aus erfahrenen Entwicklern klingt nach einer sicheren Wahl. In der Praxis wollen zu viele entwerfen und zu wenige bauen, und das bremst das Team.
- Fehlender Rückhalt im Management. Ein Nearshore-Team braucht Entscheidungen, Zugänge und Aufmerksamkeit vom Kunden. Ohne das wartet es.
Wie setze ich Nearshore-Teams auf?
Ich halte Teams bei bis zu etwa acht Entwicklern. Größere agile Teams funktionieren selten gut, weil die Abstimmung überhandnimmt. Braucht das Programm mehr Kapazität, bekommt es mehrere Teams mit klaren Verantwortlichkeiten.
Vor dem ersten Sprint vereinbaren Kunde und Partner Regeln zu Besetzung und Rotation. Kultur zählt so viel wie Skills: gemeinsame Werte, Vertrauen und der Wille zu liefern, auf beiden Seiten. Darauf achte ich bei der Partnerauswahl und in den ersten Wochen jedes neuen Teams.
Vom ersten Tag an arbeitet ein Nearshore-Team mit denselben Standards, Pull-Request-Reviews und derselben Pipeline wie alle anderen. In Reviews wird die Qualität geprüft, und neue Teammitglieder lernen dort die Konventionen der Org, wie in warum Pull-Request-Reviews in Großprojekten Pflicht sind beschrieben.
Wie sieht Steuerung über mehrere Teams aus?
Mit mehreren Teams und Partnern hält der Plan nur, wenn Abhängigkeiten und Releases abgestimmt sind. Ich führe einen Programmplan mit Streams und Abhängigkeiten, stimme Releases über einen gemeinsamen Prozess ab und berichte Status, Risiken und Entscheidungen an das Management. Die Regeln, mit denen mehrere Partner zusammenarbeiten, beschreibe ich unter Partnersteuerung, den gemeinsamen Release-Prozess unter DevOps und Release-Management.
Planen Sie ein Nearshore-Setup oder möchten Sie ein bestehendes Team wieder auf Kurs bringen, schreiben Sie mir oder lesen Sie mehr über mich.
Häufige Fragen
Wie groß sollte ein Nearshore-Team für Salesforce sein?
Bis zu etwa acht Entwickler pro Team. Darüber funktionieren agile Teams selten gut: Die Abstimmung nimmt überhand, und Sprint-Meetings werden lang. Braucht ein Programm mehr Kapazität, setze ich mehrere Teams mit klaren Verantwortlichkeiten auf statt eines großen.
Was macht Nearshore-Teams erfolgreich?
Kultur, gemeinsame Werte, Vertrauen und der Wille zu liefern, auf beiden Seiten. Dazu braucht es Rückhalt im Management, weil ein Nearshore-Team Zeit, Aufmerksamkeit und Entscheidungen vom Kunden braucht. Skills zählen, sind aber selten der Grund, warum ein Team kämpft.
Was bremst Nearshore-Teams aus?
Rotierende Ressourcen und hohe Fluktuation, weil mit jedem Wechsel Wissen über die Org verloren geht. Auch zu seniore Teams können Probleme machen: Erfahrene Entwickler, die alle entwerfen wollen, und niemand, der bauen möchte, bringen Unruhe und bremsen das Team.