{"id":26393,"date":"2020-06-19T12:46:27","date_gmt":"2020-06-19T12:46:27","guid":{"rendered":"https:\/\/cityfalcon.com\/blog\/?p=26393"},"modified":"2020-06-25T07:10:56","modified_gmt":"2020-06-25T07:10:56","slug":"9-product-and-technology-sins-of-a-founder-who-learnt-to-code","status":"publish","type":"post","link":"https:\/\/www.cityfalcon.ai\/blog\/de\/the-startup-journey\/9-product-and-technology-sins-of-a-founder-who-learnt-to-code\/","title":{"rendered":"9 Produkt- und Technologies\u00fcnden eines Gr\u00fcnders, der Programmieren gelernt hat"},"content":{"rendered":"

Zur Feier unseres 6-j\u00e4hrigen Jubil\u00e4ums und als eine Art Erg\u00e4nzung zu meinem Artikel <\/span>15 Lektionen aus 15.000 Stunden FinTech-Unternehmertum<\/span><\/a>, m\u00f6chte ich einige meiner gr\u00f6\u00dften Fehler ver\u00f6ffentlichen, damit andere Unternehmer sie vermeiden k\u00f6nnen.\u00a0<\/span><\/p>\n

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!<\/em><\/p>\n

 <\/p>\n

Wenn Sie ein Techpreneur werden wollen, m\u00fcssen Sie vor der Liste lernen, zu programmieren. Vielleicht ist das offensichtlich, vielleicht auch nicht.<\/span> \u00a0Programmieren zu lernen hat mir erlaubt<\/span> um die erste Version zu bauen, und erlaubt mir t\u00e4glich 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\u00e4nde schmutzig zu machen. Ein Kurs zum maschinellen Lernen hat es mir erm\u00f6glicht, noch selbstbewusster nicht nur mit unseren Datenwissenschaftlern, sondern auch mit CTOs von Kunden und Partnern zu interagieren.<\/span><\/p>\n

Ich habe Fehler gemacht und erfahrenere Menschen haben mir beigebracht, warum es Fehler waren. Viele Gr\u00fcnder k\u00f6nnen \u00dcberlegenheitskomplexe entwickeln, aber wenn Sie Ihre eigenen Fehler kennen, bleiben Sie f\u00fcr Ihre Mitarbeiter nahbar und behalten einen klaren Kopf.<\/span><\/p>\n

Kommen wir nun zur Liste.<\/span><\/p>\n

 <\/p>\n

1. MVP ist eine Schlampe<\/b><\/h2>\n

Sie brauchen Geld, um das Gesch\u00e4ft aufzubauen, aber jeder Investor m\u00f6chte ein Minimum Viable Product (MVP) sehen. Ohne eine ist Ihre nur eine Idee \u2013 oder aus Investorensicht ein Traum. Tr\u00e4ume sind toll, werden sie sagen, aber sie sind keine Investition wert.\u00a0<\/span><\/p>\n

Sie versuchen also, so schnell wie m\u00f6glich ein MVP aufzubauen. Es ist schlie\u00dflich das Minimum.<\/span><\/p>\n

Sie werfen Dinge zusammen; Du lernst, w\u00e4hrend du gehst, und jeder Tag f\u00fchlt sich an, als h\u00e4ttest du so viel erreicht. Dann stellen Sie fest, dass Sie eine Codezeile geschrieben und zwei neue Fehler erstellt haben. Sie nehmen Abk\u00fcrzungen, und da Sie es nur f\u00fcr wenige Benutzer in der MVP-Phase ben\u00f6tigen, \u00fcberspringen Sie die Skalierbarkeit. Sie sind Computer, sie k\u00f6nnen Dinge schnell erledigen. Wie schlimm kann es werden, von 50 auf 5.000 Benutzer zu gehen?<\/span><\/p>\n

F\u00fcr 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\u00e4chst vern\u00fcnftig, 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\u00e4t nicht vorhanden waren und dies zu einer Benutzererfahrung mit langen Ladezeiten f\u00fchrte. Die Ineffizienz bedeutete auch hohe Cloud-Hosting- und Verarbeitungskosten. Ganz zu schweigen davon, Entwicklern meinen eigenen Code zu erkl\u00e4ren (und wiederzuentdecken), da meine Dokumentation minimal war und Fintech-Konzepte f\u00fcr Programmierer ohne Finanzkenntnisse recht komplex sein k\u00f6nnen.<\/span><\/p>\n

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\u00fcssen Sie Mittel beschaffen, aber die Investoren wollen nur Traktion und Einnahmen sehen. Um den allm\u00e4chtigen Umsatz und die Zugkraft zu generieren, werden viele neue Gr\u00fcnder versuchen, von einem MVP direkt zu Unternehmensqualit\u00e4t \u00fcberzugehen. Aber dann verpuffen die Verkaufsgespr\u00e4che, weil es keine Enterprise-Qualit\u00e4t ist, aber immer noch nur minimal tragf\u00e4hig.\u00a0<\/span><\/p>\n

Wenn Sie Ihr MVP erstellen, planen Sie zumindest Skalierbarkeit und Effizienz ein. Niemand kann von vornherein zukunftssicher sein, weil man nicht wei\u00df, ob es \u00fcberhaupt funktioniert. Aber behalten Sie immer die zuk\u00fcnftigen technischen Herausforderungen im Auge und entsch\u00e4rfen Sie sie so gut Sie k\u00f6nnen von Anfang an.\u00a0\u00a0<\/span><\/p>\n

Nachdem Sie Spenden gesammelt und Entwickler eingestellt haben, m\u00f6chten Sie m\u00f6glicherweise den Code umgestalten und die Architektur neu bewerten, bevor Sie sich auf mehr Funktionen, Benutzer und Einnahmen konzentrieren. Diese Vorabinvestition von Zeit k\u00f6nnte sp\u00e4ter mehrere gr\u00f6\u00dfere Probleme verhindern. Du hast eine gebaut <\/span>minimal <\/span><\/i>lebensf\u00e4higes Produkt, kein endg\u00fcltiges optimales Produkt.<\/span><\/p>\n

Eine M\u00f6glichkeit, die MVP-Phase und die erforderliche Produktentwicklung von Anfang an zu vermeiden, besteht darin, Millionen ausschlie\u00dflich f\u00fcr eine Idee zu sammeln, eine im Silicon Valley sehr verbreitete Praxis. Nat\u00fcrlich ist es nur f\u00fcr wenige ein Privileg \u2013 Serienunternehmer mit einer starken Erfolgsbilanz, Freunde eines VC oder gro\u00dfen Angel-Investors oder ein erfahrener Branchenprofi mit vielen Kontakten. F\u00fcr den Rest von uns, <\/span>etwas <\/span><\/i>Eine Art MVP wird notwendig sein, bevor man \u00fcberhaupt Investorengelder oder -interessen sieht.<\/span><\/p>\n

 <\/p>\n

2. Einloggen mit jedem Tom, Dick und Harry \u2013 ich meine Facebook, Twitter, Linkedin, Google und jetzt Apple<\/b><\/h2>\n

Sie k\u00f6nnten im inklusiven Geist sein. Vielleicht hat ein Benutzer Sie per E-Mail gefragt, wann er sich \u00fcber Facebook anmelden kann. Sie sehen sich also die Dokumentation an, und, gro\u00dfartig, es sind nur ein paar Zeilen Code. Aber Sie haben die B\u00fcchse der Pandora ge\u00f6ffnet. Sobald die \u201ewenigen Codezeilen\u201c zu vielen werden und der Authentifizierungsprozess endlich mit Ihren Systemen funktioniert, m\u00fcssen Sie ihn in alle Ihre Bereitstellungskan\u00e4le 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\u00fcssen Sie die Anmeldefunktion f\u00fcr alle hinzuf\u00fcgen.<\/span><\/p>\n

Dann m\u00fcssen Sie m\u00f6glicherweise andere hinzuf\u00fcgen, z. B. Apple-Anmeldung f\u00fcr iPhone-Benutzer (siehe <\/span>Ziffer 4.8 ihrer AGB<\/span><\/a>), wenn Sie Ihre Dienste weiterhin \u00fcber ihre Plattform anbieten m\u00f6chten.\u00a0<\/span><\/p>\n

Jetzt, da Sie 6 verschiedene Codeteile haben, einen f\u00fcr jeden Bereitstellungskanal, sind Sie fertig. Bis sich eine der APIs \u00e4ndert und Sie Ihren Code \u00fcber alle Kan\u00e4le hinweg korrigieren m\u00fcssen. Google und Apple machen sich keine Sorgen dar\u00fcber, dass ihre \u00c4nderungen Ihre winzige App besch\u00e4digen k\u00f6nnten \u2013 aber Sie werden in hei\u00dfem Wasser sein, wenn dies der Fall ist.<\/span><\/p>\n

Manchmal sind sogar Benutzer verwirrt dar\u00fcber, wie sie sich angemeldet haben \u2013 war es \u00fcber Facebook oder Twitter? Wenn es f\u00fcr den Benutzer verwirrend ist, stellen Sie sich vor, wie es ist, all diese Anmeldemethoden zu erstellen und sie dann alle zu verwalten \u2013 und die Verwirrung des Kunden, wenn sein Konto nicht die letzte \u00c4nderung widerspiegelt, die er vorgenommen hat, weil er sich angemeldet hatte eine andere Methode.\u00a0<\/span><\/p>\n

\"\"<\/a>

Anmeldeintegrationen laden immer zu weiteren Anmeldeintegrationen ein<\/p><\/div>\n

Wenn Sie keine Daten ben\u00f6tigen, die \u00fcber 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\u00dfen Sie die verschiedenen anderen Anmeldemethoden aus. Wenn Sie einen positiven Cashflow haben und sich einen Entwickler nur f\u00fcr die Authentifizierung leisten k\u00f6nnen, k\u00f6nnen Sie dar\u00fcber nachdenken, mehrere Authentifizierungsmethoden hinzuzuf\u00fcgen.\u00a0<\/span><\/p>\n

 <\/p>\n

3. Die Versuchung, Funktionen unn\u00f6tig neu zu codieren\u00a0<\/b><\/h2>\n

So wie mehrere Authentifizierungsmethoden \u201enur ein paar Codezeilen\u201c sind, werden Sie Entwickler sagen h\u00f6ren: \u201eDer Code ist zu komplex. Lass es mich umbauen und es wird viel effizienter sein.\u201c Dr\u00fccken Sie den Panikknopf!<\/span><\/p>\n

Entwickler haben den Ehrgeiz, ihren Code effizient und sauber zu gestalten, und je mehr Funktionen hinzugef\u00fcgt werden, desto komplexer wird der Code. Aber die Codierung ist nur ein Teil, und in komplexen Systemen wie dem menschlichen K\u00f6rper und dem Klima k\u00f6nnen kleine \u00c4nderungen an einer Stelle im Code sp\u00e4ter oder anderswo drastische Auswirkungen haben.<\/span><\/p>\n

Dar\u00fcber hinaus ist richtiges Produktmanagement nicht nur Codierung. Sobald der Code fertig ist, muss ihn das Qualit\u00e4tssicherungsteam (QA) testen. Dieser Prozess f\u00fchrt unweigerlich zu einem zeitraubenden Hin und Her (siehe S\u00fcnde 6 unten). Dann muss es stabilisiert werden. Wenn sich etwas Wichtiges \u00e4ndert, m\u00fcssen Messaging und Design m\u00f6glicherweise angepasst werden. Unvorhergesehene Effekte treten auf, und pl\u00f6tzlich h\u00e4ufen sich Kundenbeschwerden.\u00a0<\/span><\/p>\n

Reparieren Sie nichts, was nicht kaputt ist. Wir haben dies getan und einen hohen Preis f\u00fcr die Einf\u00fchrung, Stabilit\u00e4t und Qualit\u00e4t gezahlt.\u00a0<\/span><\/p>\n

 <\/p>\n

4. Nicht verstehen, wie man Entwickler verwaltet und motiviert<\/b><\/h2>\n

In der Technik machen (und brechen) Entwickler Ihr Produkt buchst\u00e4blich. Die Art von Menschen, die von der Softwareentwicklung angezogen werden, sind eine besondere Rasse, und Sie m\u00fcssen verstehen, wie sie arbeiten. Sie sind vielleicht 20 Jahre in der Branche t\u00e4tig und haben Hunderte von Nicht-Technikern geleitet, aber all dieses Wissen und diese Erfahrung helfen m\u00f6glicherweise nicht bei der Zusammenarbeit mit Entwicklern.\u00a0<\/span><\/p>\n

Ihre Beweggr\u00fcnde und ihre Funktionsweise nicht zu verstehen, ist ein gro\u00dfer Fehler. Es f\u00fchrt zu Missverst\u00e4ndnissen, Verz\u00f6gerungen und Kopfschmerzen. W\u00e4hrend des Einstellungsprozesses werden Sie viele Entwickler treffen, die eine hohe Bezahlung, hohe Autonomie und Gleitzeit w\u00fcnschen. Die meisten werden keine t\u00e4glichen \u00dcberpr\u00fcfungen, feste Fristen und \u00dcberstunden wollen. Nehmen Sie diese \u00dcberlegungen ernst.<\/span><\/p>\n

Remote-Arbeit ist heute mehr denn je eine reale M\u00f6glichkeit f\u00fcr Entwickler, und die ganze Welt stellt ein. Die Besten arbeiten dort, wo sie am besten behandelt werden. Und Sie m\u00f6chten kein Produkt von schlechter Qualit\u00e4t, das von unzufriedenen Mitarbeitern am laufenden Band produziert wird, insbesondere wenn Sie in letzter Minute eine L\u00f6sung ben\u00f6tigen, bevor Sie es den Investoren pr\u00e4sentieren. Zufriedene Entwickler machen f\u00fcr Sie eine \u00dcberstundenausnahme; Ungl\u00fcckliche k\u00f6nnten einfach verschwinden.\u00a0<\/span><\/p>\n

Du kannst lesen <\/span>mein gesamter Artikel \u00fcber die Zusammenarbeit mit Entwicklern<\/span><\/a>.<\/span><\/p>\n

 <\/p>\n

5. Das Testen nicht von Anfang an automatisieren<\/b><\/h2>\n

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\u00e4t das Testen erzwingen. Sie k\u00f6nnen 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\u00e4ngt, Fehlercodes an die Benutzer auszuspucken.<\/span><\/p>\n

Wir haben immer Komponententests durchgef\u00fchrt \u2013 das hei\u00dft, jede einzelne Komponente f\u00fcr sich getestet \u2013 bevor wir sie an das Gesamtsystem angeh\u00e4ngt 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\u00fcrde.\u00a0<\/span><\/p>\n

Die Automatisierung Ihrer Tests, insbesondere f\u00fcr die Integration, macht es viel einfacher, jeden Teil der Website f\u00fcr jede Integration zu testen und erneut zu testen. Da in der Regel nicht bekannt ist, was sich durch das neue Modul im gesamten System \u00e4ndert, m\u00fcssen Integrationstests die gesamte Site abdecken. Ohne Automatisierung ist dies sehr m\u00fchsam und QAs verbringen viel Zeit mit allt\u00e4glichen Aufgaben. Aber sobald sie automatisiert sind, werden sie befreit.<\/span><\/p>\n

Dies f\u00fchrt zu einer kontinuierlichen Integration, bei der st\u00e4ndig neuer Code hinzugef\u00fcgt wird, anstatt in gro\u00dfen Updates. Wenn Ihre Tests nicht automatisiert sind, warten Sie, bis viele kleine \u00c4nderungen 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\u00fchrt werden, ohne QA-Ressourcen f\u00fcr wiederholte Tests zu verschwenden.<\/span><\/p>\n

 <\/p>\n

6. Time-to-Release untersch\u00e4tzen: Kodierung (1x), QA (2-3x), Stabilisierung (2-3x)<\/b><\/h2>\n

Beim Umgang mit Technik, insbesondere wenn Sie von au\u00dferhalb der Tech-Welt kommen, scheint das Programmieren im Vordergrund zu stehen. Sie m\u00f6chten ein technisches Produkt erstellen, Sie codieren es und los geht's, richtig? Klar, wenn du es nicht zum Arbeiten brauchst.<\/span><\/p>\n

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\u00fcck. Dann erhalten die QAs den modifizierten Code und der Prozess beginnt von vorne, was im Allgemeinen das 2-3-fache der urspr\u00fcnglichen Entwicklungszeit in Anspruch nimmt. Sobald Sie bereit sind, den neuen Code in die Produktion zu bringen, m\u00fcssen Sie im Falle von Big Data und komplexen Funktionen das 2-3-fache der urspr\u00fcnglichen Entwicklungszeit aufwenden, um Stabilit\u00e4t und Qualit\u00e4tsleistung sicherzustellen.\u00a0<\/span><\/p>\n

Zusammengenommen sind Sie von 1 Woche Ver\u00f6ffentlichungszeit (urspr\u00fcngliche Sch\u00e4tzung f\u00fcr 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 \u00fcberschritten wird.\u00a0<\/span><\/p>\n

Dies setzt voraus, dass Sie \u00fcberhaupt eine ordnungsgem\u00e4\u00dfe Dokumentation f\u00fcr den Code hatten und die Entwickler bereits verstehen, was UX, UI und Produktmanagement ben\u00f6tigen.<\/span><\/p>\n

Die Entwicklung eines hochwertigen technischen Produkts erfordert mehr Zeit, als sich die meisten Menschen vorstellen.<\/span><\/p>\n

 <\/p>\n

7. \u00dcbersehen des Produktivit\u00e4tsunterschieds zwischen guten und schlechten Programmierern<\/b><\/h2>\n

Der Druck in der Anfangsphase ist gro\u00df, so wenig Geld wie m\u00f6glich zu bluten. Dies f\u00fchrt dazu, dass Junior-Entwickler f\u00fcr Projekte eingestellt werden, die nicht Junior-Entwicklern anvertraut werden sollten. Es ist gro\u00dfartig, sp\u00e4ter Junior-Entwickler einzustellen, um bei kleineren Aufgaben zu helfen, aber der Kern Ihres Gesch\u00e4fts ist Ihre Technologie \u2013 ein guter, erfahrener Entwickler ist notwendig. Andernfalls verbringen Sie viel Zeit damit, alten Code f\u00fcr Skalierbarkeit, Stabilit\u00e4t und Effizienz zu \u00fcberarbeiten. F\u00fcr einen guten Entwickler mit ausreichend Erfahrung extra zu bezahlen, wird sich sp\u00e4ter lohnen.<\/span><\/p>\n

Dazu braucht es beide Eigenschaften: Erfahrung <\/span>und <\/span><\/i>F\u00e4higkeit. Einige Junior-Entwickler sind gro\u00dfartige Programmierer, sie \u00fcbersehen einfach zuk\u00fcnftige Probleme, die erfahrene Programmierer nicht tun. Umgekehrt bedeuten 10 Jahre Erfahrung nicht unbedingt gute Programmierf\u00e4higkeiten. Sie m\u00fcssen sicherstellen, dass beide Qualit\u00e4ten vorhanden sind. Wir haben daraus gelernt und verbringen jetzt viel mehr Zeit w\u00e4hrend des Einstellungsprozesses, um sicherzustellen, dass wir den richtigen Kandidaten an Bord holen. Dann, w\u00e4hrend der Probezeit, evaluieren wir ihre Arbeit gr\u00fcndlich und alle roten Flaggen werden sofort behandelt.<\/span><\/p>\n

Mit der Menge an zus\u00e4tzlicher Arbeit, die beim Debuggen, Neucodieren, QAing und Redesign aufgrund von schlechtem Code erforderlich ist, k\u00f6nnte der Produktivit\u00e4tsunterschied zwischen einem guten und einem schlechten oder unerfahrenen Entwickler das 1000-fache betragen.<\/span><\/p>\n

 <\/p>\n

8. Die Versuchung, alle \u201eErfahrungen\u201c intern zu erstellen<\/b><\/h2>\n

Jedes Unternehmen m\u00f6chte seinen Nutzern ein qualitativ hochwertiges Erlebnis bieten. Wenn Sie sich auf den Weg machen, diese Erfahrung aufzubauen, haben Sie m\u00f6glicherweise 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?<\/span><\/p>\n

Die Daten zu bedienen, klar, das ist einfach. Eigentlich das Frontend bauen? Das ist eine andere Geschichte. Frontend ist umst\u00e4ndlich. Zuerst gibt es Grafiken \u2013 Sie brauchen einen Designer, um diese Grafiken zu erstellen. APIs sind nur Endpunkte, alles Text und Code. Oh, und die Grafiken m\u00fcssen skaliert werden, um auf verschiedenen Bildschirmaufl\u00f6sungen und Browsern korrekt angezeigt zu werden. Und wer m\u00f6chte keine mobile App? Das bringt eine Reihe von Problemen mit sich, wie z. B. erzwungene Anmeldetypen (siehe 2 oben), mehrere Betriebssysteme und unterschiedliche Hardware.<\/span><\/p>\n

Meine Empfehlung: Sie m\u00fcssen einen Gro\u00dfteil des Frontends bauen, aber wenn Sie vorgefertigte Komponenten von Drittanbietern kaufen k\u00f6nnen, mit denen Sie die meisten Szenarien abdecken k\u00f6nnen (Betriebssystem, Hardware, Bildschirmgr\u00f6\u00dfe 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\u00f6nnen, \u00fcberspringen Sie die Kopfschmerzen beim QA-Testen von 15 verschiedenen Browsern, Tablets und Telefonen. Sie m\u00fcssen nicht alles selbst bauen; M\u00f6glicherweise gibt es eine L\u00f6sung zum Kauf zu einem vern\u00fcnftigen Preis. Oder sogar Open Source, wenn Sie Gl\u00fcck haben. Aber glauben Sie nicht, dass Open Source immer die Einsparungen wert ist, denn manchmal erf\u00fcllt die Premium-Version Ihre Anforderungen genau ohne zus\u00e4tzliche Entwicklungszeit.\u00a0<\/span><\/p>\n

 <\/p>\n

9. Rollenunterschiede in einem technischen Kontext nicht verstehen<\/b><\/h2>\n

Ein weiteres Missverst\u00e4ndnis von Personen ohne technischen Hintergrund ist, dass alle technischen Rollen mehr oder weniger gleich sind. Sicher, Entwickler sind Backend\/Frontend, die Benutzeroberfl\u00e4che 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\u00e4chst, sind Differenzierung und Spezialisierung notwendig, und es kann ein kostspieliger Zeit- und Qualit\u00e4tsfehler sein, sie zu verwechseln.\u00a0<\/span><\/p>\n

Der erste Fall: Design. Es gibt Designer f\u00fcr die Benutzeroberfl\u00e4che (UI) und es gibt Designer f\u00fcr die Benutzererfahrung (UX). Die Benutzeroberfl\u00e4che ist sehr kreativ und macht alles glatt und angenehm anzusehen. Bei UX geht es mehr um Struktur: Wie flie\u00dfen 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?<\/span><\/p>\n

Den Unterschied zwischen UX und UI nicht zu kennen, kann zu optisch ansprechenden Produkten f\u00fchren, 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.<\/span><\/p>\n

Ich habe auch Softwareentwickler und DevOps-Mitarbeiter verwechselt, was zu mehr Arbeitsdruck auf unsere Entwickler gef\u00fchrt hat. Technologiesysteme, insbesondere solche, die so komplex sind wie unsere eigenen, sind nicht nur Code (wie in S\u00fcnde 6 erw\u00e4hnt). Big Data verschiebt auch die Grenzen dessen, was Systeme leisten k\u00f6nnen, sodass Stabilit\u00e4t und Zug\u00e4nglichkeit oberste Priorit\u00e4t haben. In der heutigen Welt wird die Betriebszeit des 100% nat\u00fcrlich als selbstverst\u00e4ndlich angesehen, und wenn diese nicht eingehalten wird, f\u00e4llt dies sofort auf. Wir haben bereits 1,5 DevOps und m\u00fcssen m\u00f6glicherweise einen weiteren einstellen, um weitere KI-Dienste hinzuf\u00fcgen zu k\u00f6nnen.<\/span><\/p>\n

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\u00fchren, und es muss stabil genug sein, um die Kunden zufrieden zu stellen. Verwechseln Sie DevOps nicht mit Softwareentwicklung.<\/span><\/p>\n

 <\/p>\n

9a. S\u00fcnden eines anderen<\/strong><\/h2>\n

Wir haben einige aufschlussreiche Vorbehalte von Jelle van Mourik, einem Leser auf Facebook, erhalten. Wir werden sie hier nur in dieser einen \u00dcberschrift auslegen (wir haben ein wenig paraphrasiert und nat\u00fcrlich unsere eigene Note hinzugef\u00fcgt):<\/span><\/p>\n