Bei NeuroSYS ist uns mehr als bewusst dass IT-Produktentwicklung immer eine Herausforderung ist, sowohl bei internen Systemen, als auch SaaS-Anwendung. Egal ob Sie Dinge hausintern entwickeln, zuvor ein geeignetes Team rekrutieren oder eine externe Firma dafür anheuern. Letzteres können Sie in Ihrem eigenen Land oder im Ausland tun – sich für Offshoring oder, näher dran, Nearshoring entscheiden. Falls Sie Nearshoring näher erklärt haben wollen – hier ist der entsprechende Post dazu. 

Sollten Sie sich vor Nearshoring fürchten? Mit welchen Bedenken haben CTOs am häufigsten zu kämpfen? Wir wollen auf die häufigsten falschen Vorstellung und Ängste um das Thema eingehen, die wir in Gesprächen mit unseren Partnern erfahren haben. Wir schreiben hier über Nearshoring, aber diese Problematik trifft wahrscheinlich auf jegliche externe Teams zu, die man engagieren möchte.

In diesem Artikel beschreiben wir die fünf häufigsten Befürchtungen in Bezug auf Nearshoring: 

  • Kontrollverlust
  • niedrige Qualität von Dienstleistungen
  • schwache Kommunikation
  • fehlendes Verständnis der Geschäftsanforderungen
  • Abhängigkeit

Ganz nebenbei, eines der Tools welches die Zusammenarbeit mit externen IT-Anbietern fördern kann ist die agile Methodik. In diesem Artikel werden wir mehrmals darauf hinweisen. Wir werden auch agile Fachsprache benutzen, in welcher verschiedene Begriffe möglicherweise ohne SCRUM-Kontext eine andere Bedeutung haben, wie zum Beispiel der Product Owner. Falls Sie mehr über dieses Thema wissen möchten, bitte lesen Sie unsere bisherigen Blogposts über agile Methodik und wie IT funktioniert. 

1. Die Kontrolle über den Entwicklungsprozess verlieren

Wenn man die Entwicklung eines Produktes oder Service einer anderen Firma überlässt, hat man immer einen Anlass zur Sorge. Das ist normal und üblich. Wenn wir fühlen, dass wir die Kontrolle verlieren, kriegen wir Angst und wir stellen uns möglicherweise solche Fragen wie: 

  • Was genau macht mein Nearshoring-Team (und warum braucht das so lange)?
  • Auf welcher Etappe ist mein Projekt gerade?
  • Wie kann ich wissen ob ich mein Geld nicht zum Fenster hinauswerfe?
  • Kann ich die Flexibilität beibehalten und die Richtung in die mein Produkt gehen soll noch ändern?
  • Was ist mit Deadlines? Kann ich meinen Endbenutzern einen Liefertermin versprechen? Wird alles pünktlich fertiggestellt?

Um von Anfang an Klarheit zu schaffen, eine externe Firma zu engagieren bedeutet nicht, dass man die Kontrolle über sein Produkt verliert. Mit dem agilen Ansatz, falls ein Projekt auf diese Weise ausgeführt wird, ist es der Product Owner der die wichtigste Rolle spielt. Er/sie ist es, die entscheiden was für Änderungen am Projekt nötig sind und welche die höchste Kapitalrendite (ROI) einbringen. Die Product Owner haben alle Tools zur Verfügung, die helfen die Produkterwartungen zu definieren und kurzfristige Prioritäten zu setzen, die sich von Sprint zu Sprint verändern können.

Die meisten Tools fürs Projektmanagement, so wie Jira, Redmine, und YouTrack, helfen dabei den Fortschritt des ganzen Projektes und einzelner Issues zu verfolgen. Der Zugang zu einem agilen Board zeigt den Status aller Aufgaben im jeweiligen Sprint auf eine transparente Weise an, inklusive Informationen über Zeit zum fertigstellen, verbrauchte Zeit und kommende Deadlines. Ein professioneller Auftragnehmer wird auch ein Set an Berichten vorschlagen.

Tatsächlich haben wir bemerkt, dass durch die Einstellung eines externen Teams die Geschäftsführer sich motiviert fühlen die Projekte zu durchdenken und ihre ursprünglichen Annahmen zu überprüfen, indem sie Roadmaps erstellen und lang- und kurzfristige Ziele setzen. Wenn das Team agil ist reagiert es auch schnell auf jegliche zwischenzeitliche Veränderungen, verursacht durch den Markt oder Handlungen der Konkurrenz.

In Bezug auf Deadlines arbeiten professionelle Entwicklungsteams auf Basis von Schätzungen. Sie besprechen alle Aufgaben die für die Implementierung vorgelegt wurden mit Ihnen, analysieren diese und schätzen die Zeit und Ressourcen die für den Prozess gebraucht werden. Basierend auf diesen Informationen können sie das Lieferdatum unter bestimmten Umständen ziemlich genau absehen. Falls sich die externen Bedingungen, Aufgaben oder die Prioritäten des Product Owner ändern, ist das vorgeschlagene Datum natürlich nicht mehr gültig. Wenn man das im Hinterkopf behält ist es einfacher Veränderungen zu vermeiden welche die Arbeit des Teams unterbrechen und die Planbarkeit des Projektes reduzieren. Ich rate immer für eine Sicherheitsmarge zu sorgen wenn man den Endbenutzern Lieferdaten verkündet, im Falle von Veränderung die außerhalb unserer Kontrolle sind.

2. Niedrige Qualität von Dienstleistungen

Wenn man kosteneffiziente Lösungen wählt kriegt man immer Bedenken. Die Befürchtungen von Geschäftsführern beziehen sich meisten auf: 

  • Sind die Nearshoring-Entwickler kompetent?
  • Was ist wenn der produzierte Code unlesbar ist oder nicht den Best Practices entspricht? 
  • Werden alle Veränderungen angemessen getestet und dokumentiert?

Als Kunde sollten Sie von Ihrem Anbieter eine detaillierte Strategie zur Qualitätssicherung für Ihr Produkt erwarten können. Professionelle IT-Anbieter setzten viele Mechanismen für Qualitätskontrolle auf jeder Etappe der Produktion ein, unter anderem:

UX/UI Design

Es ist auf der Etappe des UX/UI-Designs die es erlaubt die Transparenz des User Interface, potentielle Interaktionen, Intuitivität und Benutzerfreundlichkeit einzuschätzen. All das passiert bevor die Anwendung in der eigentlichen Entwicklungsphase ist. Diese erste Etappe dient dazu Ihnen zu versichern, dass Ihre Nearshoring-Firma Ihr Business, Ihre Vision und Endbenutzer versteht.

Design von Systemarchitektur 

Um ein gut durchdachtes und einheitliches System zu gestalten müssen wir dessen Architektur und Datenfluss entwickeln. Vor allen Dingen muss es die aktuellen Geschäftsanforderung und potentielle Richtungen für Produktentwicklung in Betracht ziehen. Sonst wird der Code immer für die anfallenden Anforderungen verbogen, anstatt die Muster zu implementieren die von Anfang an entwickelt wurden. Eine gute Praktik ist es alle architektonischen Entscheidungen in einem so genannten Architecture Decisions Records zu dokumentieren. Ein ADR ist ein kurzes Dokument welches die Details der eingeführten architektonischen Entscheidungen festhält, inklusive Kontext, eine Analyse der Alternativen und Konsequenzen. Eine ADR motiviert das Team dazu informierte und wohlüberlegte Entscheidungen zu treffen, sorgfältig alternative Lösungen zu betrachten und es hilft jedem neuen Teammitglied alle Komplexitäten mit größerer Leichtigkeit zu verstehen.

Testplan 

Das Testen von Anwendungen gehört zu den wichtigsten Qualitätssicherungsmechanismen. Dank diesem Prozess kann man prüfen, ob das entwickelte Produkt alle Annahmen und Vorgaben erfüllt, sowohl funktionale als auch nicht-funktionale. Nebenbei, berücksichtigen Sie, dass nur eine Deklaration dass die Anwendung getestet wird nicht genug ist um eine hohe Qualität des Produktes zu garantieren. Nur ein Testplan der vor dem Start des Projektes eingereicht wird kann Ihnen die Details über die folgenden Dinge zeigen: 

  • Unit-Tests und Testabdeckung
  • manuelle Tests von neuen Funktionalitäten und Veränderungen
  • Testfälle als Teil der Dokumentation, sodass sie wiederholbar sind oder im nachhinein automatisiert werden können 
  • Bug Reporting und Abwicklungsverfahren
  • Automatisierte Tests mit den Richtlinien für ihre Gestaltung und Umsetzung
  • Regressionstests 
  • Schwachstellen- und Penetrationstests der Anwendung und des Servers
  • QS als Teil der kontinuierlichen Integration/Lieferung
  • Tests bezüglich Performance und Support für den geforderten Traffic (Leistungsprüfung und Stresstests)
  • Codeüberprüfung (Überprüfung des Sourcecode), sodass jede einzelne Zeile des Codes von mindestens einem anderen Developer in Bezug auf Klarheit, das Anwenden von guten Programmier-Praktiken, Optimierung und der Einhaltung von Design Vorgaben überprüft wird
  • Testumgebung für den Kunden, um die Version des Systems, das zur Freigabe zur Produktion bereit ist, zu prüfen (die sogenannte Staging/Pre-Release-Umgebung).

Wie Sie sehen können gibt es einige Prozeduren die dazu dienen die Qualität Ihrer Anwendung zu sichern. Ich kann nicht abstreiten, dass alle oben genannten Qualitätssicherungsmechanismen höhere Kosten mit sich bringen. Allerdings will ich, dass Sie wissen, dass diese Optionen zur Verfügung stehen, damit Sie eine bewusste Entscheidung treffen können.

nearshoring consultation banner
Kostenlose einstündige Beratung
Haben Sie eine bestimmte Idee im Sinn? Zögern Sie nicht, uns für ein Erstgespräch zu kontaktieren!
Mehr erfahren

3. Schwache (oder fehlende) Kommunikation

Wenn man ein Nearshoring-Team engagiert will man, dass sie den ganzen Entwicklungsprozess übernehmen können. Aber egal wie ausgezeichnet ihre Kenntnisse im Bereich von Geschäftsberatung und Entwicklung sind bringt das alles nichts, wenn sie nicht effektiv kommunizieren können. Potentielle Bedenken in diesem Bereich sind: 

  • Reaktionslosigkeit des Anbieters 
  • Dass Ihre wichtigen Fragen nicht beantwortet werden
  • Widersprüchliche Informationen von verschiedenen Teammitgliedern
  • Sprachliche oder kulturelle Barrieren, die effektive Kommunikation verhindern

In Bezug auf Kommunikation spielen der menschliche Faktor und individuelle interpersonale Skills der Teammitglieder eine wichtige Rolle. Dennoch hilft das Aufstellen von einigen Grundregeln definitiv dabei einige dieser Barrieren zu überwinden.

Zentraler Ansprechpartner 

Das erste Prinzip ist die Festlegung eines zentralen Ansprechpartners (SPOC – Single Point of Contact) auf beiden Seiten – bei Ihnen und beim Anbieter. Diese Rolle wird meistens einfach von Managern übernommen. Auf diese Weise werden die Kommunikation und widersprüchlichen Informationen, die bei mehreren Kommunikationsteilnehmern möglicherweise vorkommen können, begrenzt. Trotzdem schließt dieser Ansatz die Teilnahme der anderen Teammitglieder in der Kommunikation nicht aus, aber die Anwesenheit der zentralen Ansprechpartner ist immer ein Muss.  

Kommunikationskanäle

Die zweite Regel ist die Festlegung der Kommunikationskanäle und die Bestimmung derer Zwecke. Zum Beispiel, für alltägliche Kommunikation kann ich Chat-Tools wie Slack, Google Chat oder MS Team empfehlen. Diese erlauben es schnell anzurufen und größere Videokonferenzen zu organisieren, welche meistens effektiver sind als einfach Nachrichten im Chat auszutauschen. Wenn das Team ihre Arbeit mithilfe von spezifischen Systemen, wie Jira, YouTrack, oder Redmine organisiert, dann lohnt es sich diese ebenfalls zu nutzen. Fragen und Antworten, sowie relevante Informationen über bestimmte Aufgaben sollten als Kommentare in den Tickets gepostet werden. Zum Schluss sollten Sie sich überlegen einen Kommunikationskanal für formellere Angelegenheiten, wie Deadlines, Verzögerungen, Estimations, Risiken, usw. festzulegen, zum Beispiel E-Mail. Diese wichtigen Befunde können dann leicht ausfindig gemacht werden. 

4. Fehlendes Verständnis meines Business

Wenn man eine Nearshoring IT-Firma sucht, will man nicht nur jemanden der den Code schreibt. Man braucht einen echten Geschäftspartner der unsere Anforderungen, Vision versteht und uns bei unseren großen Entscheidungen unterstützen kann. Die größten bedenken hierbei sind: 

  • Die Outsourcing-Firma kennt die Branche nicht
  • Unsere Prozesse sind zu komplex und/oder nicht richtig dokumentiert
  • Ich habe die nicht die Zeit und Ressourcen eine detaillierte Spezifikation für den Anbieter vorzubereiten 
  • Unsere Anforderung/Produkt ist sehr spezifisch, es wird sehr viel Zeit und Geld brauchen bis der Anbieter uns gut kennenlernt 
  • Ich werde erst beim finalen Ergebnis sehen, ob es das war was ich wirklich wollte

Softwarehäuser spezialisieren sich in maßgeschneiderter Software und sie sollten Erfahrung mit einer Vielzahl von Kunden aus verschiedenen Branchen haben. Da sie wissen dass die meisten IT-Projekte sich durch hohe Komplexität und Variabilität auszeichnen, werden sie nicht erwarten, dass Sie direkt umfassende und komplette Spezifikation der Anwendung vorbereiten werden. Stattdessen ist alles was Sie brauchen eine generelle Beschreibung des Systems und eine Liste der Funktionalitäten die, in dem Moment, verfügbar sein sollten. Es ist gut eine Vision der ganzen App zu haben, aber es ist meistens nicht die beste Idee zu versuchen alle Funktionalitäten mit dem ersten Release zu liefern. Stattdessen ist es besser auf ein Minimalprodukt, oder MVP, zu zielen – das Minimum Viable Product, welches eine schnellere Markteinführungszeit hat und schneller das erste Feedback von Endbenutzern und Investoren einbringt. Indem Sie Ihren Kunden nur die Kernfunktionen liefern, können Sie Ihr Projekt viel früher anfangen zu monetarisieren.

Nachdem Sie beschlossen haben welche Funktionalitäten die wichtigsten für die erste Version Ihrer Anwendung sind, muss der Anbieter die Details erfahren um die Entwicklungsphase zu planen. Die Analyse fängt auf der Geschäftsebene an, d.h. mit den Prozessen welche die App einführen oder unterstützen soll. In dieser Phase ist Ihre Mitwirkung als Kunde ausschlaggebend, denn Sie haben das beste Wissen über das Produkt. IT-Analytiker wenden verschiedene Techniken an um sicherzustellen, dass das Wissen des Kunden effektiv erfasst wird, von ordentlich geführten Gesprächen bis hin zu speziellen Gruppenübungen, nicht nur mit den Entscheidungsträgern seitens des Kunden, sondern auch mit Menschen die die bestimmen Lösungen oder Module wirklich benutzen werden, so wie HR-Spezialisten oder Buchhalter. Event Storming ist nur ein Beispiel.

Ein Entwicklungsteam sollte auch einen UX/UI-Designer an Bord haben, welcher, auf Basis Ihrer Anforderungen, professionelle Mockups vorbereiten wird. Diese werden nicht wie das endgültige UI-Design aussehen, aber Sie werden den Inhalt der verschiedenen Screens, die Anordnung der Elemente, Navigation, usw. sehen können. Diese Lösung erlaubt es Ihnen sicherzugehen, dass die App so aussehen wird wie Sie es erwarten und es macht es auch den Entwicklern einfacher alle visuellen Komponenten, basierend auf den Mockups, einzuführen.

5. Völlig abhängig vom Anbieter werden

Zuguterletzt kommt die Angst völlig abhängig von der Nearshoring-Firma zu werden. Die Nearshoring-Beziehung kann zwar langfristig sein, aber das heißt nicht dass Sie Ihre Unabhängigkeit verlieren wollen. Wenn der Vertrag zu Ende ist, dann ist er zu Ende. Sie sollten nicht irgendwelche Verpflichtungen oder Verantwortungen gegenüber der Firma haben. Trotzdem kommen Ihnen vielleicht Bedenken auf ob:

Der Anbieter den Sourcecode zurückgeben wird und Zugriff auf alle Materialien gewährleistet

Die Firma das Wissen über das Projekt teilen wird

Sie Technologien oder Lösungen anwenden die allgemein bekannt sind

Sie ihr Fachwissen ausnutzen indem sie zusätzliche Services aufzwingen

Sourcecode und Copyright 

Bei der Auswahl eines IT-Partners können Sie das Risiko der Entwicklung einer langfristigen, ungesunden Beziehung minimieren. Als erstes müssen Sie sichergehen dass Sie der Eigentümer des Sourcecodes sind, der während der Arbeit an Ihrem Projekt entsteht, inklusive der Übertragung des Urheberrechts. Dies muss vertraglich reguliert sein. Selbst wenn Sie nicht daran denken Ihre Anwendung in dem Moment zu ändern ist es mehr oder weniger sicher, dass Sie das System früher oder später ändern oder modernisieren müssen. Wenn Sie weder den Sourcecode noch das Urheberrecht der Anwendung besitzen, werden Sie gezwungen sein erneut mit demselben Diensteanbieter zu arbeiten.  

Code-Repositorium

Normalerweise hindert den Anbieter nichts daran an Ihrem Code-Repositorium zu arbeiten. Falls Sie keins haben können Sie solche Services wir GitHub, GitLab oder Bitbucket nutzen. Falls der Sourcecode in dem Repositorium des Anbieters während der Entwicklung bewahrt wird, können Sie im Namen Ihrer Mitarbeiter den Zugang dazu anfordern. Es ist auch gut sicherzustellen, dass der geschriebene Code lesbar und vorzugsweise selbstdokumentierend ist. Um dies zu erreichen lohnt es sich gemeinsame Regeln für die Arbeit mit dem Code zu erstellen. Ihre Entwickler können auch in dem vorher erwähnten Code-Review-Prozess teilnehmen, damit sie den Überblick nicht verlieren. 

Bestandsdokumentation

Eine Bestandsdokumentation zu haben, die vorzugsweise auf laufender Basis erstellt wird, hilft dabei sich problemlos vom Anbieter zu lösen. Wenn die Zusammenarbeit gut verläuft hilft solche Dokumentation dabei neue Teammitglieder schneller und günstiger einzubringen und wenn Probleme vorkommen ist es einfacher einen anderen Anbieter zu finden und zu engagieren.

Mainstream-Technologien 

Und finden Sie heraus wie der IT-Markt in Bezug auf Technologien aussieht. Ein Anbieter der Lösung basierend auf Niche-Technologien baut kann Sie effektiv daran hindern nach Alternativen zu suchen, falls die Zusammenarbeit nicht klappen sollte. Derzeit gehören zu den sicheren Auswahlen 

  • für Web-Anwendungen: Node.js, .NET, PHP, Java, React.js, Angular.js 
  • für Mobile-Entwicklung: Java, Objective C, ReactNative (Cross-Plattform-Technologie)
  • für künstliche Intelligenz und Machine Learning: Python. 

Es kann schwierig sein eindeutig einzuschätzen, ob eine Nearshoring-Firma sich Ihr Projekt zum Ziel setzt oder ob sie ihr Vorteil nutzen will, um mehr Geld zu verdienen. Deswegen lohnt es sich eine nahe Beziehung mit dem Anbieter zu führen, Fragen zu stellen falls Zweifel aufkommen und vollständige und klare Erklärungen über unklare Sachverhalte zu fordern. In Ausnahmefällen kann es notwendig sein einen unabhängigen Auditor anzuheuern, um die Legitimität der vom Anbieter erhobenen Bedürfnisse zu prüfen.