Zur Feier unseres 6-jährigen Jubiläums und als eine Art Ergänzung zu meinem Artikel 15 Lektionen aus 15.000 Stunden FinTech-Unternehmertum, möchte ich einige meiner größten Fehler veröffentlichen, damit andere Unternehmer sie vermeiden können. 

Anmerkung der Redaktion: 3 * 2 = 6 und 3 ** 2 = 9, also ist der Titel immer noch mit unserem 6. Geburtstag verbunden. Deshalb ist es wichtig, Programmieren zu lernen!

 

Wenn Sie ein Techpreneur werden wollen, müssen Sie vor der Liste lernen, zu programmieren. Vielleicht ist das offensichtlich, vielleicht auch nicht.  Programmieren zu lernen hat mir erlaubt um die erste Version zu bauen, und erlaubt mir täglich zu verstehen, warum Entwickler tun, was sie tun. Im Laufe der Zeit habe ich es wirklich genossen, zu programmieren und mir mit APIs usw. die Hände schmutzig zu machen. Ein Kurs zum maschinellen Lernen hat es mir ermöglicht, noch selbstbewusster nicht nur mit unseren Datenwissenschaftlern, sondern auch mit CTOs von Kunden und Partnern zu interagieren.

Ich habe Fehler gemacht und erfahrenere Menschen haben mir beigebracht, warum es Fehler waren. Viele Gründer können Überlegenheitskomplexe entwickeln, aber wenn Sie Ihre eigenen Fehler kennen, bleiben Sie für Ihre Mitarbeiter nahbar und behalten einen klaren Kopf.

Kommen wir nun zur Liste.

 

1. MVP ist eine Schlampe

Sie brauchen Geld, um das Geschäft aufzubauen, aber jeder Investor möchte ein Minimum Viable Product (MVP) sehen. Ohne eine ist Ihre nur eine Idee – oder aus Investorensicht ein Traum. Träume sind toll, werden sie sagen, aber sie sind keine Investition wert. 

Sie versuchen also, so schnell wie möglich ein MVP aufzubauen. Es ist schließlich das Minimum.

Sie werfen Dinge zusammen; Du lernst, während du gehst, und jeder Tag fühlt sich an, als hättest du so viel erreicht. Dann stellen Sie fest, dass Sie eine Codezeile geschrieben und zwei neue Fehler erstellt haben. Sie nehmen Abkürzungen, und da Sie es nur für wenige Benutzer in der MVP-Phase benötigen, überspringen Sie die Skalierbarkeit. Sie sind Computer, sie können Dinge schnell erledigen. Wie schlimm kann es werden, von 50 auf 5.000 Benutzer zu gehen?

Für mich kannte ich nicht alle Best Practices wie Testen, Dokumentieren und Vorbereiten auf Skalierbarkeit. Das Ziel war, ein Basisprodukt zu haben, um Spenden zu sammeln, und nicht die Enterprise Edition. Ich habe das Backend mit dem Ruby on Rails-Framework geschrieben, aber das Frontend in reinem JavaScript und jQuery. Das erscheint zunächst vernünftig, und damals waren Frontend-Frameworks noch nicht so beliebt. Aber kein Framework auf dem Frontend zu verwenden, hat uns wahrscheinlich ein Jahr Refactoring und Umdenken gekostet, weil die Skalierbarkeit und Flexibilität nicht vorhanden waren und dies zu einer Benutzererfahrung mit langen Ladezeiten führte. Die Ineffizienz bedeutete auch hohe Cloud-Hosting- und Verarbeitungskosten. Ganz zu schweigen davon, Entwicklern meinen eigenen Code zu erklären (und wiederzuentdecken), da meine Dokumentation minimal war und Fintech-Konzepte für Programmierer ohne Finanzkenntnisse recht komplex sein können.

Sie brauchen wahrscheinlich 3-6 Monate, um von Grund auf zum MVP zu gelangen, und einige weitere Monate, um an Boden zu gewinnen. Gleichzeitig müssen Sie Mittel beschaffen, aber die Investoren wollen nur Traktion und Einnahmen sehen. Um den allmächtigen Umsatz und die Zugkraft zu generieren, werden viele neue Gründer versuchen, von einem MVP direkt zu Unternehmensqualität überzugehen. Aber dann verpuffen die Verkaufsgespräche, weil es keine Enterprise-Qualität ist, aber immer noch nur minimal tragfähig. 

Wenn Sie Ihr MVP erstellen, planen Sie zumindest Skalierbarkeit und Effizienz ein. Niemand kann von vornherein zukunftssicher sein, weil man nicht weiß, ob es überhaupt funktioniert. Aber behalten Sie immer die zukünftigen technischen Herausforderungen im Auge und entschärfen Sie sie so gut Sie können von Anfang an.  

Nachdem Sie Spenden gesammelt und Entwickler eingestellt haben, möchten Sie möglicherweise den Code umgestalten und die Architektur neu bewerten, bevor Sie sich auf mehr Funktionen, Benutzer und Einnahmen konzentrieren. Diese Vorabinvestition von Zeit könnte später mehrere größere Probleme verhindern. Du hast eine gebaut minimal lebensfähiges Produkt, kein endgültiges optimales Produkt.

Eine Möglichkeit, die MVP-Phase und die erforderliche Produktentwicklung von Anfang an zu vermeiden, besteht darin, Millionen ausschließlich für eine Idee zu sammeln, eine im Silicon Valley sehr verbreitete Praxis. Natürlich ist es nur für wenige ein Privileg – Serienunternehmer mit einer starken Erfolgsbilanz, Freunde eines VC oder großen Angel-Investors oder ein erfahrener Branchenprofi mit vielen Kontakten. Für den Rest von uns, etwas Eine Art MVP wird notwendig sein, bevor man überhaupt Investorengelder oder -interessen sieht.

 

2. Einloggen mit jedem Tom, Dick und Harry – ich meine Facebook, Twitter, Linkedin, Google und jetzt Apple

Sie könnten im inklusiven Geist sein. Vielleicht hat ein Benutzer Sie per E-Mail gefragt, wann er sich über Facebook anmelden kann. Sie sehen sich also die Dokumentation an, und, großartig, es sind nur ein paar Zeilen Code. Aber Sie haben die Büchse der Pandora geöffnet. Sobald die „wenigen Codezeilen“ zu vielen werden und der Authentifizierungsprozess endlich mit Ihren Systemen funktioniert, müssen Sie ihn in alle Ihre Bereitstellungskanäle integrieren. Wenn Sie eine einzelne App auf iOS haben, ist es vielleicht nicht so schlimm. Aber wenn Sie eine Website, Android- und iOS-Apps und Sprachsysteme wie Alexa und Google Home haben, müssen Sie die Anmeldefunktion für alle hinzufügen.

Dann müssen Sie möglicherweise andere hinzufügen, z. B. Apple-Anmeldung für iPhone-Benutzer (siehe Ziffer 4.8 ihrer AGB), wenn Sie Ihre Dienste weiterhin über ihre Plattform anbieten möchten. 

Jetzt, da Sie 6 verschiedene Codeteile haben, einen für jeden Bereitstellungskanal, sind Sie fertig. Bis sich eine der APIs ändert und Sie Ihren Code über alle Kanäle hinweg korrigieren müssen. Google und Apple machen sich keine Sorgen darüber, dass ihre Änderungen Ihre winzige App beschädigen könnten – aber Sie werden in heißem Wasser sein, wenn dies der Fall ist.

Manchmal sind sogar Benutzer verwirrt darüber, wie sie sich angemeldet haben – war es über Facebook oder Twitter? Wenn es für den Benutzer verwirrend ist, stellen Sie sich vor, wie es ist, all diese Anmeldemethoden zu erstellen und sie dann alle zu verwalten – und die Verwirrung des Kunden, wenn sein Konto nicht die letzte Änderung widerspiegelt, die er vorgenommen hat, weil er sich angemeldet hatte eine andere Methode. 

Anmeldeintegrationen laden immer zu weiteren Anmeldeintegrationen ein

Wenn Sie keine Daten benötigen, die über die Authentifizierung hinausgehen (wie Bilder von Facebook oder Benutzerinformationen von Google), seien Sie exklusiv: Verwenden Sie nur einen Benutzernamen oder eine E-Mail-Adresse und schließen Sie die verschiedenen anderen Anmeldemethoden aus. Wenn Sie einen positiven Cashflow haben und sich einen Entwickler nur für die Authentifizierung leisten können, können Sie darüber nachdenken, mehrere Authentifizierungsmethoden hinzuzufügen. 

 

3. Die Versuchung, Funktionen unnötig neu zu codieren 

So wie mehrere Authentifizierungsmethoden „nur ein paar Codezeilen“ sind, werden Sie Entwickler sagen hören: „Der Code ist zu komplex. Lass es mich umbauen und es wird viel effizienter sein.“ Drücken Sie den Panikknopf!

Entwickler haben den Ehrgeiz, ihren Code effizient und sauber zu gestalten, und je mehr Funktionen hinzugefügt werden, desto komplexer wird der Code. Aber die Codierung ist nur ein Teil, und in komplexen Systemen wie dem menschlichen Körper und dem Klima können kleine Änderungen an einer Stelle im Code später oder anderswo drastische Auswirkungen haben.

Darüber hinaus ist richtiges Produktmanagement nicht nur Codierung. Sobald der Code fertig ist, muss ihn das Qualitätssicherungsteam (QA) testen. Dieser Prozess führt unweigerlich zu einem zeitraubenden Hin und Her (siehe Sünde 6 unten). Dann muss es stabilisiert werden. Wenn sich etwas Wichtiges ändert, müssen Messaging und Design möglicherweise angepasst werden. Unvorhergesehene Effekte treten auf, und plötzlich häufen sich Kundenbeschwerden. 

Reparieren Sie nichts, was nicht kaputt ist. Wir haben dies getan und einen hohen Preis für die Einführung, Stabilität und Qualität gezahlt. 

 

4. Nicht verstehen, wie man Entwickler verwaltet und motiviert

In der Technik machen (und brechen) Entwickler Ihr Produkt buchstäblich. Die Art von Menschen, die von der Softwareentwicklung angezogen werden, sind eine besondere Rasse, und Sie müssen verstehen, wie sie arbeiten. Sie sind vielleicht 20 Jahre in der Branche tätig und haben Hunderte von Nicht-Technikern geleitet, aber all dieses Wissen und diese Erfahrung helfen möglicherweise nicht bei der Zusammenarbeit mit Entwicklern. 

Ihre Beweggründe und ihre Funktionsweise nicht zu verstehen, ist ein großer Fehler. Es führt zu Missverständnissen, Verzögerungen und Kopfschmerzen. Während des Einstellungsprozesses werden Sie viele Entwickler treffen, die eine hohe Bezahlung, hohe Autonomie und Gleitzeit wünschen. Die meisten werden keine täglichen Überprüfungen, feste Fristen und Überstunden wollen. Nehmen Sie diese Überlegungen ernst.

Remote-Arbeit ist heute mehr denn je eine reale Möglichkeit für Entwickler, und die ganze Welt stellt ein. Die Besten arbeiten dort, wo sie am besten behandelt werden. Und Sie möchten kein Produkt von schlechter Qualität, das von unzufriedenen Mitarbeitern am laufenden Band produziert wird, insbesondere wenn Sie in letzter Minute eine Lösung benötigen, bevor Sie es den Investoren präsentieren. Zufriedene Entwickler machen für Sie eine Überstundenausnahme; Unglückliche könnten einfach verschwinden. 

Du kannst lesen mein gesamter Artikel über die Zusammenarbeit mit Entwicklern.

 

5. Das Testen nicht von Anfang an automatisieren

Wie die Sicherheit wird das Testen von Code oft als optional und als Zeitverschwendung angesehen. Aber wenn das Team und das Produkt wachsen, wird die Komplexität das Testen erzwingen. Sie können eine Komponente nicht ohne Tests in ein komplexes System integrieren, damit Sie nicht bereit sind, sich den Folgen des Kunden zu stellen, wenn die Produktion stockt und anfängt, Fehlercodes an die Benutzer auszuspucken.

Wir haben immer Komponententests durchgeführt – das heißt, jede einzelne Komponente für sich getestet – bevor wir sie an das Gesamtsystem angehängt haben. Wir haben jedoch erst ab 2019 mit ganzheitlichen automatisierten Integrationstests begonnen. Ein wesentlicher Grund war ein Mangel an Ressourcen, um das gesamte System bei jedem Update erneut zu testen. Solange der aktualisierte Teil funktionierte, gingen wir davon aus, dass das gesamte System funktionieren würde. 

Die Automatisierung Ihrer Tests, insbesondere für die Integration, macht es viel einfacher, jeden Teil der Website für jede Integration zu testen und erneut zu testen. Da in der Regel nicht bekannt ist, was sich durch das neue Modul im gesamten System ändert, müssen Integrationstests die gesamte Site abdecken. Ohne Automatisierung ist dies sehr mühsam und QAs verbringen viel Zeit mit alltäglichen Aufgaben. Aber sobald sie automatisiert sind, werden sie befreit.

Dies führt zu einer kontinuierlichen Integration, bei der ständig neuer Code hinzugefügt wird, anstatt in großen Updates. Wenn Ihre Tests nicht automatisiert sind, warten Sie, bis viele kleine Änderungen fertig sind, und geben sie dann alle zusammen frei, sodass Sie das gesamte System einmal testen. Aber sobald produktweite, banale Tests automatisiert sind, kann Continuous Integration eingeführt werden, ohne QA-Ressourcen für wiederholte Tests zu verschwenden.

 

6. Time-to-Release unterschätzen: Kodierung (1x), QA (2-3x), Stabilisierung (2-3x)

Beim Umgang mit Technik, insbesondere wenn Sie von außerhalb der Tech-Welt kommen, scheint das Programmieren im Vordergrund zu stehen. Sie möchten ein technisches Produkt erstellen, Sie codieren es und los geht's, richtig? Klar, wenn du es nicht zum Arbeiten brauchst.

Sie verbringen 1 Woche mit Entwicklungszeit. Dann testen QAs alles (was nicht automatisiert werden kann), Tickets werden geschrieben und der Code kehrt zur Fehlerbehebung an die Entwickler zurück. Dann erhalten die QAs den modifizierten Code und der Prozess beginnt von vorne, was im Allgemeinen das 2-3-fache der ursprünglichen Entwicklungszeit in Anspruch nimmt. Sobald Sie bereit sind, den neuen Code in die Produktion zu bringen, müssen Sie im Falle von Big Data und komplexen Funktionen das 2-3-fache der ursprünglichen Entwicklungszeit aufwenden, um Stabilität und Qualitätsleistung sicherzustellen. 

Zusammengenommen sind Sie von 1 Woche Veröffentlichungszeit (ursprüngliche Schätzung für neue Techpreneurs) auf 5-7 Wochen gestiegen. Wenn Sie auf diese Art von Zeitrahmen nicht vorbereitet sind, werden Sie Ihren Kunden zu viel versprechen und Ihr Team zu sehr unter Druck setzen, wenn die Frist überschritten wird. 

Dies setzt voraus, dass Sie überhaupt eine ordnungsgemäße Dokumentation für den Code hatten und die Entwickler bereits verstehen, was UX, UI und Produktmanagement benötigen.

Die Entwicklung eines hochwertigen technischen Produkts erfordert mehr Zeit, als sich die meisten Menschen vorstellen.

 

7. Übersehen des Produktivitätsunterschieds zwischen guten und schlechten Programmierern

Der Druck in der Anfangsphase ist groß, so wenig Geld wie möglich zu bluten. Dies führt dazu, dass Junior-Entwickler für Projekte eingestellt werden, die nicht Junior-Entwicklern anvertraut werden sollten. Es ist großartig, später Junior-Entwickler einzustellen, um bei kleineren Aufgaben zu helfen, aber der Kern Ihres Geschäfts ist Ihre Technologie – ein guter, erfahrener Entwickler ist notwendig. Andernfalls verbringen Sie viel Zeit damit, alten Code für Skalierbarkeit, Stabilität und Effizienz zu überarbeiten. Für einen guten Entwickler mit ausreichend Erfahrung extra zu bezahlen, wird sich später lohnen.

Dazu braucht es beide Eigenschaften: Erfahrung und Fähigkeit. Einige Junior-Entwickler sind großartige Programmierer, sie übersehen einfach zukünftige Probleme, die erfahrene Programmierer nicht tun. Umgekehrt bedeuten 10 Jahre Erfahrung nicht unbedingt gute Programmierfähigkeiten. Sie müssen sicherstellen, dass beide Qualitäten vorhanden sind. Wir haben daraus gelernt und verbringen jetzt viel mehr Zeit während des Einstellungsprozesses, um sicherzustellen, dass wir den richtigen Kandidaten an Bord holen. Dann, während der Probezeit, evaluieren wir ihre Arbeit gründlich und alle roten Flaggen werden sofort behandelt.

Mit der Menge an zusätzlicher Arbeit, die beim Debuggen, Neucodieren, QAing und Redesign aufgrund von schlechtem Code erforderlich ist, könnte der Produktivitätsunterschied zwischen einem guten und einem schlechten oder unerfahrenen Entwickler das 1000-fache betragen.

 

8. Die Versuchung, alle „Erfahrungen“ intern zu erstellen

Jedes Unternehmen möchte seinen Nutzern ein qualitativ hochwertiges Erlebnis bieten. Wenn Sie sich auf den Weg machen, diese Erfahrung aufzubauen, haben Sie möglicherweise das Backend bereits erstellt. Vielleicht haben Sie sogar ein paar Kunden, die Ihre API verwenden. Es sollte sehr einfach sein, diese Daten an ein Verbraucher-Frontend zu liefern, oder?

Die Daten zu bedienen, klar, das ist einfach. Eigentlich das Frontend bauen? Das ist eine andere Geschichte. Frontend ist umständlich. Zuerst gibt es Grafiken – Sie brauchen einen Designer, um diese Grafiken zu erstellen. APIs sind nur Endpunkte, alles Text und Code. Oh, und die Grafiken müssen skaliert werden, um auf verschiedenen Bildschirmauflösungen und Browsern korrekt angezeigt zu werden. Und wer möchte keine mobile App? Das bringt eine Reihe von Problemen mit sich, wie z. B. erzwungene Anmeldetypen (siehe 2 oben), mehrere Betriebssysteme und unterschiedliche Hardware.

Meine Empfehlung: Sie müssen einen Großteil des Frontends bauen, aber wenn Sie vorgefertigte Komponenten von Drittanbietern kaufen können, mit denen Sie die meisten Szenarien abdecken können (Betriebssystem, Hardware, Bildschirmgröße usw.), kaufen Sie die vorgefertigten Komponenten. Ihr Produkt unterscheidet sich durch Backend-Code und Frontend-Design, nicht durch Frontend-Grundcode. Wenn Sie es kaufen können, überspringen Sie die Kopfschmerzen beim QA-Testen von 15 verschiedenen Browsern, Tablets und Telefonen. Sie müssen nicht alles selbst bauen; Möglicherweise gibt es eine Lösung zum Kauf zu einem vernünftigen Preis. Oder sogar Open Source, wenn Sie Glück haben. Aber glauben Sie nicht, dass Open Source immer die Einsparungen wert ist, denn manchmal erfüllt die Premium-Version Ihre Anforderungen genau ohne zusätzliche Entwicklungszeit. 

 

9. Rollenunterschiede in einem technischen Kontext nicht verstehen

Ein weiteres Missverständnis von Personen ohne technischen Hintergrund ist, dass alle technischen Rollen mehr oder weniger gleich sind. Sicher, Entwickler sind Backend/Frontend, die Benutzeroberfläche unterscheidet sich von der Infrastruktur. Am Anfang mag das sogar stimmen. Wenn es nur Sie sind (und vielleicht ein paar andere), verschmelzen die Rollen alle miteinander. Aber wenn das Unternehmen wächst, sind Differenzierung und Spezialisierung notwendig, und es kann ein kostspieliger Zeit- und Qualitätsfehler sein, sie zu verwechseln. 

Der erste Fall: Design. Es gibt Designer für die Benutzeroberfläche (UI) und es gibt Designer für die Benutzererfahrung (UX). Die Benutzeroberfläche ist sehr kreativ und macht alles glatt und angenehm anzusehen. Bei UX geht es mehr um Struktur: Wie fließen Benutzer durch das System? Was passiert wenn hier ein Fehler auftritt, kommt der User zu Screen A oder Screen B? Macht dieses Design im Zusammenhang mit der Herkunft des Benutzers Sinn oder stiftet es nur Verwirrung?

Den Unterschied zwischen UX und UI nicht zu kennen, kann zu optisch ansprechenden Produkten führen, die Benutzer frustrieren und verwirren. Du verkaufst nicht nur den Look, du verkaufst das Erlebnis. Stellen Sie sicher, dass es den Kunden das Geld wert ist, sonst gehen sie woanders hin.

Ich habe auch Softwareentwickler und DevOps-Mitarbeiter verwechselt, was zu mehr Arbeitsdruck auf unsere Entwickler geführt hat. Technologiesysteme, insbesondere solche, die so komplex sind wie unsere eigenen, sind nicht nur Code (wie in Sünde 6 erwähnt). Big Data verschiebt auch die Grenzen dessen, was Systeme leisten können, sodass Stabilität und Zugänglichkeit oberste Priorität haben. In der heutigen Welt wird die Betriebszeit des 100% natürlich als selbstverständlich angesehen, und wenn diese nicht eingehalten wird, fällt dies sofort auf. Wir haben bereits 1,5 DevOps und müssen möglicherweise einen weiteren einstellen, um weitere KI-Dienste hinzufügen zu können.

Ihre Entwickler, sowohl Backend als auch Frontend, konzentrieren sich auf den Code und den Algorithmus. Sie brauchen DevOps, um sicherzustellen, dass die Rechenleistung vorhanden ist, um diesen Code auszuführen, und es muss stabil genug sein, um die Kunden zufrieden zu stellen. Verwechseln Sie DevOps nicht mit Softwareentwicklung.

 

9a. Sünden eines anderen

Wir haben einige aufschlussreiche Vorbehalte von Jelle van Mourik, einem Leser auf Facebook, erhalten. Wir werden sie hier nur in dieser einen Überschrift auslegen (wir haben ein wenig paraphrasiert und natürlich unsere eigene Note hinzugefügt):

  • Zwingen Sie Programmierer nicht, etwas zu programmieren, was sie nicht programmieren. Mit anderen Worten, versuchen Sie nicht, einen Backend-Programmierer dazu zu bringen, an Frontend-UI-Code zu arbeiten und umgekehrt. Da USD und RMB beide Währungen sind, die Sie nicht synonym verwenden, kann es sich bei allen um Codezeilen handeln, aber Ansätze, Strukturen und Erfahrungen unterscheiden sich zwischen verschiedenen Aspekten. Beträchtliche Fehler, Verzögerungen und Kopfschmerzen erwarten jeden, der versucht, einen Programmierer dazu zu bringen, etwas zu codieren, was er/sie nicht codiert
  • Entwerfen Sie, bevor Sie programmieren – es gibt nichts Besseres, als die gesamte Codebasis zum Laufen zu bringen und zu erkennen, dass das neue Design inkompatibel ist oder eine umfassende Überarbeitung des Codes erfordert
  • Gehen Sie so schnell wie möglich zu Benutzertests, denn die Benutzer sind diejenigen, die Sie nicht kontrollieren können, und sie werden Dinge kaputt machen oder sie ablehnen, und das ist schlecht fürs Geschäft
  • Gehen Sie auf negatives Feedback in der App ein, damit die unzufriedenen Benutzer diese Unzufriedenheit Ihnen gegenüber ausdrücken und nicht der breiten Öffentlichkeit in den iOS- und Android-App-Stores
  • Behalten Sie einen einzigen stabilen Zweig für die Bereitstellung bei, nicht mehrere „freisetzbare“ Zweige, die auseinanderlaufen, dann alle verwirren und fehlende kritische Teile haben, für die Sie eine Woche brauchen integrieren zu Ihrem freigegebenen Zweig
  • Halten Sie einen expliziten Rückstand an technischen Dingen, die zu erledigen sind, und planen Sie Sprints damit. Diese Dinge haben die Tendenz, dem Verstand zu entgleiten. Wenn Sie es sich leisten können, möchten Sie vielleicht sogar eine Person einstellen, die dies verwaltet

 

Und das sind die 9 Sünden (plus die Sünden der Leser). Haben Sie ähnliche Erfahrungen, die Sie mit uns teilen möchten? Gibt es weitere Fallstricke, vor denen Sie andere Unternehmer warnen möchten? Bitte kommentieren Sie unten.