Trotzdem lohnt sich ein Versuch zweifellos. Wenn ein Machine-Learning-Projekt gelingt können Sie Ihr Geschäft stark ankurbeln, einen Wettbewerbsvorteil gewinnen und ein neues, einzigartiges Produkt herstellen. In diesem Artikel will ich Ihnen zeigen wie man Machine-Learning-Projekte startet und verwaltet, um Risiken und Kosten zu reduzieren, aber dennoch erwartete Resultate geplant liefern kann.
Was ist Machine Learning
Machine Learning ist ein Teilbereich von Artificial Intelligence. Das Ziel ist es Algorithmen zu entwickeln, sodass Computer lernen und sich automatisch, über Zeit verbessern können. Sie sind so programmiert um Muster zu finden und im Endeffekt datenbasierte Prognosen und Entscheidungen zu treffen. Das Stichwort hierbei ist ‘automatisch’, was bedeutet dass es kein weiteres menschliches Eingreifen verlangt. Verschiedene Arten von Machine-Learning-Algorithmen werden in einer Vielzahl von Industrien und Apps angewendet, so wie medizinische Diagnosen, Versicherung, Finanzwesen, Telekommunikation und Produktion.
Die Besonderheit von Machine-Learning-Projekten
Machine-Learning-Projekte sind auf große Veränderung in der Organisation ausgerichtet – Verbesserung der Produktionsprozesse, Optimierung der Lieferkette und das Treffen besserer Geschäftsentscheidungen. Diese Projekte können auch der Grundstein für neue, bahnbrechende Produkte oder einzigartige, neue Features sein. Egal was Sie für ein Ziel haben, ob es nun die Verbesserung der Produktionseffizienz um 10% ist oder eine Prognose wie viele Weihnachtskugeln Sie dieses Jahr bestellen müssen, um den Marktanforderungen gerecht zu werden, es gibt kein Patentrezept dafür.
Unvorhersehbarkeit umfassen
Folglich zeichnen sich Machine-Learning-Projekte, sowie andere AI-Projekte, durch ein relativ hohes Risiko aus. So wie bei jeder anderen Innovation muss man bei Forschungsprojekten auch erst die Hypothesen bestätigen. Wir müssen beweisen, dass das was wir erreichen wollen überhaupt erreichbar ist. Aus diesem Grund ist es praktisch unmöglich ganz am Anfang die Zeitrahmen und Kosten der meisten Machine-Learning-Projekte einzuschätzen. Das bringt offensichtliche Probleme mit sich, wie zum Beispiel wie man den Firmenvorstand davon überzeugt den Kosten und der Unvorhersehbarkeit des Ergebnisses zuzustimmen. Dies bezieht sich nicht auf typische Projekte welche die Vorteile von Machine Learning nutzen, sowie Empfehlungssysteme, welche fertige Tools und Bibliotheken anwenden. Aber solche Projekte würde ich sowieso eher als IT-Projekte einstufen.
Das Risiko minimieren
Der Schlüssel hierbei ist es das Risiko und die Kosten zu minimieren und den Prozess so sicher wie möglich zu machen. Besonders da es außer dem Projekt selbst noch die Frage gibt welche Anbieter man wählt, was das Risiko nur noch steigert, wenn man das erste Mal zusammenarbeitet. Wir haben darüber schon in unserem früheren Blogpost Die 5 häufigsten Bedenken bei der Zusammenarbeit mit einem externen Anbieter geschrieben, wo wir generell über Themen verbunden mit der Zusammenarbeit mit Outsourcing-Firmen reflektieren. Da wir jetzt geklärt haben wie riskant der Prozess ist, reden wir darüber wie man Machine-Learning-Projekte weniger unsicher macht.
Die Stufen unseres Machine-Learning-Entwicklungsprozesses
Firmen wollen keine langfristigen Bindungen mit Anbietern eingehen, bevor sie diese nicht gut kennen – und das ist vollkommen verständlich. Wir vereinfachen dies, indem wir die Grundlage dafür geschaffen haben die Zusammenarbeit schnell abzubrechen falls etwas schief geht und der Kunde unzufrieden ist. Sie müssen keinen mehrjährigen Vertrag am Anfang der Zusammenarbeit unterschreiben und Sie können unsere Dienstleistungen vorerst austesten. Auf diesem Wege können Sie schnell überprüfen, selbst nach einem oder zwei Sprints, ob das Projekt die Chance hat ein Erfolg zu werden.
Hier erklären wir unseren Prozess, der über die Jahre entwickelt wurde, nicht nur während Projekten für Kunden sondern auch für interne Konzepte. Ich glaube dieser Weg R&D-Projekte zu verwalten hilft das Risiko für beide Seiten zu minimieren.
Phase 1: das Problem analysieren
Sie kommen mit einem Problem zu uns. Ihnen erscheint, dass Sie das Problem lösen können oder Dinge besser machen können – schneller, effektiver – z.B. mit neuronalen Netzwerken oder Deep Learning.
Da jeder Fall bei Machine Learning anders ist müssen wir so viel wie möglich über Ihre Organisation und Ihre Herausforderungen lernen. Um dies zu erreichen unterzeichnen wir eine GHV, wir führen Interviews durch und organisieren einen Workshop (der weiter im Artikel beschrieben wird). Dadurch dass wir das Problem, existierende Lösungen und das Equipment, den Bereich der automatisiert werden soll, kennen und Probendaten haben können wir eine anfängliche Idee für eine Lösung oder einen Lösungsansatz vorstellen. Diese Phase des Projektes ist völlig kostenlos und verlangt einige Informationen von Ihnen (vielleicht einige Probendaten) und 2-3 Stunden Ihrer Zeit.
Phase 2: die Durchführbarkeitsstudie
Da wir das Problem schon kennen können wir auf eigene Faust weiter forschen. In Phase zwei verbringen wir unsere Zeit damit unsere anfänglichen Annahmen und Theorien, die in Phase eins entwickelt wurden, zu prüfen. Wir führen eine Durchführbarkeitsstudie durch um einzuschätzen ob bestimmte Algorithmen und Lösungen funktionieren werden. Zum Schluss versuchen wir eine komplette, langfristige Lösung vorzuschlagen. Diese Phase dauert bis zu einer Woche.
Phase 3: in Subprojekte einteilen und mit dem ersten anfangen
Machine-Learning-Projekte können von einigen Wochen bis hin zu mehreren Monaten dauern und es ist schwierig ohne minimale Information dies richtig einzuschätzen. Um so ein Projekt effektiv zu managen versuchen wir es in Subprojekte einzuteilen die ein klares Timing, Deliverables und Einschätzungen haben. Es ist wichtig die 1-2 ersten Sprints zu definieren, denn sie erlauben es die Kernhypothese zu überprüfen. Auf diesem Weg können Sie klar erkennen ob unser gewählter Weg der richtige ist und ob er Ihr Problem lösen kann.
Ohne ein langfristiges Commitment Ihrerseits können Sie die Grundannahmen Ihres ML-Projektes prüfen, zum Beispiel wir viele Trainingsmuster gebraucht werden, wie effektiv das System/die Funktionen sein werden und ob die Resultate die Sie erwarten möglich zu erreichen sind. Zusätzlich erlaubt es Ihnen diese Methode uns schnell kennenzulernen – ob wir uns an unsere Versprechen halten, wie reaktionsfähig wir sind und ob Sie gerne mit uns zusammenarbeiten.
Aus unserer Erfahrung sind der Schlüssel zu jedem ML-Projekt Daten – nicht nur die Quantität, sondern auch die Qualität. Die ersten Sprints erlauben es uns die Herausforderungen, denen wir uns in der Arbeit mit den Daten des Kunden stellen müssen, realistisch einzuschätzen – und das ist besonders wichtig bei der Einschätzung des Projektes. Das können simple Sachen sein wie Fehler und fehlende Standardisierung der Daten bis hin zu Problemen mit der Sammlung von real-live Datensätzen die für das Projekt gebraucht werden könnten.
Auf diese Weise reduzieren wir das Risiko ‘bis aufs Minimum’ – für beide Seiten. Sie müssen keine mehrjährigen Verträge mit externen Anbietern unterschreiben und wir müssen keine Projekte einschätzen die höchst unberechenbar, also auch riskant, sind. Natürlich werden wir die komplette Produktionslösung nicht im ersten Sprint liefern, aber es ist wesentlich günstiger zu prüfen ob die Idee überhaupt machbar ist – und wie lange es dauern könnte ein komplettes System zu bauen.
Machine-Learning-Entwicklungsprozesses > das Problem analysieren (1-2 Tage) > die Durchführbarkeitsstudie (1 Woche) > in Subprojekte einteilen > Sprint → Feature (bis zu einem Monat)
Beispiele von Machine-Learning-Projekten
Machine Learning kann vielen Firmen aus verschiedenen Industrien zum Vorteil kommen. Ein paar größere Beispiele sind Mikrobiologie, Nanoelektronik, Transport (selbstfahrende Autos), Bergbau, Gesundheitswesen, Finanzdienstleistungen und Produktion.
Zum Beispiel haben wir einen Deep-Learning-Algorithmus entwickelt, der Mikroorganismen die auf Zellkulturschalen wachsen zählt und klassifiziert. Um höchste Präzision zu erreichen haben wir solche Methoden wie Deep Neural Networks, Bildverarbeitung und Objekterkennung angewendet. Sie können hier mehr über dieses Objektzählungsprojekt lesen.
Ein anderes Beispiel aus einer anderen Industrie ist unsere AI- und AR-Plattform für industrielle Prozessbegleitung. Es erlaubt Managern die Vorteile von Augmented-Reality-Training zu nutzen indem sie es direkt anwenden. Die komplette Case Study über nsFlow finden Sie hier.
Zusammenfassung
Es ist möglich Machine-Learning-Lösungen ohne hohe Risiken und große Kosten zu entwickeln. Sie brauchen kein Multi-Millionen-Budget um zu entwickelt und das zu erreichen was Sie wollen – indem Sie es Schritt für Schritt machen. Der oben beschriebene Machine-Learning-Entwicklungsprozesses wird Ihnen helfen Ihre Ziele mit einem sichereren Gefühl zu erreichen.
]]>
1. Kopieren Sie das Framework nicht einfach – passen Sie es Ihren Bedürfnissen an
Scrum ist keine fertige Lösung die jedem passt. Es ist ein Werkzeug, dessen Effektivität davon abhängt wie man es einsetzt. Sie müssen einen langen Weg des Lernens und Übens durchstehen, um das Beste daraus zu ziehen (die Shu-Ha-Ri-Philosophie spiegelt den Scrum-Lernweg sehr gut wieder).
Aber bevor Sie zum Scrum-Yoda werden, handeln Sie gemäß dem Framework und dem gesunden Menschenverstand (bedeutet hier = ihren Geschäftsanforderungen). Fangen Sie damit an zu analysieren warum Sie Scrum brauchen: welche Probleme gibt es in Ihrem bisherigen Prozess, wie kann Scrum helfen (und kann es das überhaupt) und was wollen Sie am Ende erreichen. Wenn Ihnen das alles klar ist können Sie die Scrum-Methode der Natur Ihres Projektes und den bestehenden Schwachstellen anpassen. Auf diese Weise wird der Übergang sinnvoller und die Richtung viel offensichtlicher: Sie werden sehen wo Sie starten, welche Punkte mehr Fokus verlangen und so weiter.
2. Einen Prozess einzuführen ist nicht genug. Arbeiten Sie auch an dem Mindset der Menschen
Scrum erfordert eine agile Einstellung. Die Leute im Team sollten aufhören als Einzelpersonen zu denken und anfangen als Team zu denken, die Aufmerksamkeit von ‘Menschen machen Arbeit’ auf ‘Arbeit wird gemacht’ richten, harte Daten anstatt Vermutungen priorisieren, die von Tests und Iterationen gewonnen werden und so weiter.
Wenn Leute über ihre täglichen Leistungen prahlen, anstatt die Sachen anzusprechen die für das Team wichtig sind – dann ist das Meeting eine Zeitverschwendung. Der ganze Prozess macht ohne die richtige Einstellung keinen Sinn. Je eher das Team das versteht, desto besser. Also zögern Sie nicht zu verdeutlichen wie wichtig ein agiles Mindset ist während Sie die Spielregeln erklären (das ist eine der wichtigsten Aufgaben eines Scrum Master).
3. Fangen Sie klein an, aber achten Sie auf die Details
Es ist besser auf einer kleinen Skala anzufangen, aber tiefgründig zu sein und auf die Details einzugehen, anstatt die Sache groß, aber oberflächlich zu betrachten. Fangen Sie mit einem Projekt oder mit einem Team in einem Projekt an. Dies erlaubt es Ihnen zu experimentieren und von Fehlern zu lernen ohne Angst größeren Schaden anrichten. Später können Sie den bewährten Prozess mit kleinerem Risiko hochskalieren.
4. Irgendwann müssen Sie loslassen
Eines der größten Stärken eines Scrum-Teams ist deren Unabhängigkeit und Selbstversorgungsfähigkeit. Dies kann man nur erreichen wenn man dem Team seine Freiheit überlässt. Wenn also das Scrum-Setup fertig ist und das Team die Idee und die Spielregeln verstanden hat, ist es Zeit loszulassen und sich nicht über jeden Schritt des Teams aufzuregen. Hören Sie auf für Ihr Team zu committen, lassen Sie das Team selbst Estimations machen, die Tasks aufteilen und die Verantwortung für ihre Performance zu übernehmen.
Bei diesem Thema lohnt es sich noch anzumerken, dass Sie sicherstellen sollten, dass jeder im Team die Rolle des Scrum Master richtig versteht. Der Scrum Master ist nicht dafür da jedem zu sagen was er oder sie zu tun hat. Tatsächlich besteht die Rolle darin das Team im Prozess zu coachen und die Arbeit des Teams zu fördern, indem er oder sie die Impediments, die das Erreichen der bestmöglichen Resultate beeinflussen, identifiziert und beseitigt.
5. Passen Sie Scrum an Ihre Bedürfnisse an, aber verlieren Sie nicht den eigentlichen Sinn
Obgleich man Scrum an die eigenen Bedürfnisse anpassen kann (sehen Sie Tipp Nr. 1 oben) ist es keine gute Idee die Framework-Regeln so zu verdrehen oder zu vernachlässigen, dass aus dem Prozess ein Scrum-Aber wird. Versuchen Sie diese häufigen Fehler, die bei der Einführung von Scrum auftreten, zu vermeiden:
- zu viele Teammitglieder (es sollten idealerweise zwischen 5 und 9 Leute sein)
- zu lange tägliche Meetings (es sollten um die 15-20 Minuten sein)
- Teammitglieder arbeiten zur selben Zeit an verschiedenen Projekten
- zusätzliche Meetings zu den Scrum Ceremonies
- es versäumen/vergessen sich auf eine Definition von “fertig” zu einigen
- Sprints verlängern wenn etwas noch nicht fertig ist
- den Scope des Sprints während dem Sprint zu ändern.
…Das ist alles für jetzt. Bleiben Sie dabei und lesen Sie den zweiten Teil dieses Posts über Herausforderungen beim Übergang zu Scrum der nächste Woche veröffentlicht wird.
]]>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.
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.
]]>