Pour célébrer notre 6e anniversaire et en quelque sorte en complément de mon article 15 leçons tirées de 15000 heures d'entrepreneuriat FinTech, Je souhaite publier certaines de mes plus grosses erreurs afin que d'autres entrepreneurs puissent les éviter. 

Note de l'éditeur: 3 * 2 = 6 et 3 ** 2 = 9, donc le titre est toujours lié à notre 6ème anniversaire. C'est pourquoi il est important d'apprendre le codage!

 

Avant tout, avant la liste, si vous voulez être un techpreneur, vous devez apprendre à coder. C'est peut-être évident, peut-être que ce n'est pas le cas.  Apprendre à coder m'a permis construire la première version et, au quotidien, me permet de comprendre pourquoi les développeurs font ce qu'ils font. Sur une période de temps, j'ai vraiment aimé coder et me salir les mains avec les API, etc. Un cours d'apprentissage automatique m'a permis d'interagir encore plus en toute confiance non seulement avec nos data scientists mais aussi avec les CTO de clients et partenaires.

J'ai fait des erreurs et des gens plus expérimentés m'ont appris pourquoi c'était des erreurs. De nombreux fondateurs peuvent développer des complexes de supériorité, mais connaître vos propres erreurs vous permet de rester en contact avec vos employés et lucide.

Passons maintenant à la liste.

 

1. MVP est un B * tch

Vous avez besoin d'argent pour développer l'entreprise, mais chaque investisseur souhaite voir un produit minimum viable (MVP). Sans un, le vôtre n'est qu'une idée - ou un rêve, du point de vue de l'investisseur. Les rêves sont formidables, diront-ils, mais ils ne valent pas l'investissement. 

Vous essayez donc de créer un MVP le plus rapidement possible. C'est le minimum, après tout.

Vous jetez les choses ensemble; vous apprenez au fur et à mesure et chaque jour vous donne l'impression d'avoir accompli tellement de choses. Ensuite, vous réalisez que vous avez écrit une ligne de code et créé deux nouveaux bogues. Vous prenez des raccourcis et, comme vous n'en avez besoin que pour quelques utilisateurs au stade MVP, vous sautez l'évolutivité. Ce sont des ordinateurs, ils peuvent faire les choses rapidement. À quel point cela peut-il devenir grave de passer de 50 à 5 000 utilisateurs?

Pour moi, je ne connaissais pas toutes les meilleures pratiques, comme les tests, la documentation et la préparation à l'évolutivité. L'objectif était d'avoir un produit de base pour collecter des fonds, pas de construire l'édition d'entreprise. J'ai écrit le backend en utilisant le framework Ruby on Rails mais le frontend en JavaScript et jQuery. Cela semble raisonnable au début, et à l'époque, les frameworks frontaux n'étaient pas aussi populaires. Mais ne pas utiliser de framework sur le frontend nous a probablement coûté un an de refactoring et de repenser, car l'évolutivité et la flexibilité étaient inexistantes et cela s'est traduit par une expérience utilisateur de longs temps de chargement. L'inefficacité signifiait également des coûts élevés d'hébergement et de traitement dans le cloud. Sans parler d'expliquer (et de redécouvrir) mon propre code aux développeurs, car ma documentation était minime et les concepts fintech peuvent être assez complexes pour les codeurs non experts en finance.

Vous aurez probablement besoin de 3 à 6 mois pour accéder au MVP à partir de zéro, et de plusieurs mois supplémentaires pour gagner du terrain. Dans le même temps, vous devez lever des fonds, mais les investisseurs veulent juste voir la traction et les revenus. Pour générer des revenus et une traction tout-puissants, de nombreux nouveaux fondateurs essaieront de passer d'un MVP directement à la qualité d'entreprise. Mais alors, les arguments de vente tomberont à plat car ce ne sera pas la qualité de l'entreprise, mais encore peu viable. 

Lorsque vous créez votre MVP, prévoyez au moins l'évolutivité et l'efficacité. Personne ne peut assurer la pérennité dès le départ, car vous ne savez pas si cela fonctionnera même. Mais gardez toujours à l'esprit les défis technologiques futurs et atténuez-les au mieux dès le départ.  

Après avoir collecté des fonds et embauché des développeurs, vous souhaiterez peut-être refactoriser le code et réévaluer l'architecture avant de vous concentrer sur plus de fonctionnalités, d'utilisateurs et de revenus. Cet investissement de temps initial pourrait éviter plusieurs problèmes majeurs sur la route. Vous avez construit un au minimum produit viable, après tout, pas un produit final optimal.

Une façon d'éviter l'étape MVP et la création de produit requise dès le départ est de lever des millions entièrement pour une idée, une pratique très courante dans la Silicon Valley. Bien sûr, ce n'est un privilège que pour quelques-uns - des entrepreneurs en série avec de solides antécédents, des amis avec un capital-risque ou un investisseur providentiel majeur, ou un professionnel senior de l'industrie avec beaucoup de contacts. Pour le reste d'entre nous, certains type de MVP sera nécessaire avant de voir les dollars ou les intérêts des investisseurs.

 

2. Connexion avec chaque Tom, Dick et Harry - je veux dire Facebook, Twitter, Linkedin, Google et maintenant Apple

Vous pourriez être dans l'esprit inclusif. Peut-être qu'un utilisateur vous a envoyé un e-mail pour vous demander quand il peut se connecter via Facebook. Donc, vous regardez la documentation, et, génial, ce ne sont que quelques lignes de code. Mais vous avez ouvert la boîte de Pandore. Une fois que les «quelques lignes de code» se sont développées à plusieurs et que le processus d'authentification fonctionne enfin avec vos systèmes, vous devez l'intégrer dans tous vos canaux de distribution. Si vous avez une seule application sur iOS, ce n'est peut-être pas si mal. Mais lorsque vous avez un site Web, des applications Android et iOS et des systèmes vocaux comme Alexa et Google Home, vous devez ajouter la fonctionnalité de connexion pour tous.

Ensuite, vous serez peut-être obligé d'en ajouter d'autres, comme la connexion Apple pour les utilisateurs d'iPhone (voir Clause 4.8 de leurs CGU) si vous souhaitez continuer à fournir vos services via leur plateforme. 

Maintenant que vous disposez de 6 morceaux de code différents, un pour chaque canal de diffusion, vous êtes prêt. Jusqu'à ce que l'une des API change et que vous deviez corriger votre code sur tous les canaux. Google et Apple ne s'inquiètent pas de ce que leurs modifications brisent votre petite application, mais vous serez dans l'eau chaude si c'est le cas.

Parfois, même les utilisateurs ne savent pas comment ils se sont inscrits - était-ce via Facebook ou Twitter? Si cela est déroutant pour l'utilisateur, imaginez ce que c'est que de créer toutes ces méthodes de connexion, puis de les gérer toutes - et la confusion du client lorsque son compte ne reflète pas la dernière modification qu'il a effectuée parce qu'il s'était connecté avec une méthode différente. 

Les intégrations de connexion invitent toujours plus d'intégrations de connexion

Sauf si vous avez besoin de données au-delà de l'authentification (comme des images de Facebook ou des informations utilisateur de Google), soyez exclusif: utilisez uniquement un nom d'utilisateur ou un e-mail et excluez les différentes autres méthodes de connexion. Lorsque vous avez un flux de trésorerie positif et que vous pouvez vous permettre un développeur uniquement pour l'authentification, vous pouvez penser à ajouter plusieurs méthodes d'authentification. 

 

3. La tentation de recoder inutilement les fonctionnalités 

Tout comme plusieurs méthodes d'authentification ne sont «que quelques lignes de code», vous entendrez les développeurs dire «le code est trop complexe. Permettez-moi de le reconstruire et ce sera beaucoup plus efficace ». Appuyez sur le bouton panique!

Les développeurs ont la volonté de rendre leur code efficace et propre, et à mesure que de nouvelles fonctionnalités sont ajoutées, le code devient complexe. Mais le codage n'est qu'une partie, et dans des systèmes complexes, comme le corps humain et le climat, de petits changements à un endroit du code peuvent avoir des effets d'entraînement drastiques plus tard ou ailleurs.

De plus, une bonne gestion des produits ne se résume pas au codage. Une fois le code prêt, l'équipe d'assurance qualité (QA) doit le tester. Ce processus entraîne invariablement des va-et-vient chronophages (voir Sin 6 ci-dessous). Ensuite, il doit être stabilisé. Si quelque chose d'important change, la messagerie et la conception devront peut-être être modifiées. Des effets imprévus surgissent et les plaintes des clients arrivent soudainement. 

Ne réparez pas quelque chose qui n'est pas cassé. Nous l'avons fait et avons payé un lourd tribut à temps pour le lancement, la stabilité et la qualité. 

 

4. Ne pas comprendre comment gérer et motiver les développeurs

Dans le domaine de la technologie, les développeurs créent (et cassent) littéralement votre produit. Les types de personnes attirées par le développement de logiciels sont une race particulière, et vous devez comprendre comment ils fonctionnent. Vous avez peut-être 20 ans dans l'industrie et géré des centaines de personnes non technologiques, mais toutes ces connaissances et cette expérience peuvent ne pas vous aider à travailler avec des développeurs. 

Ne pas comprendre leurs motivations et leur fonctionnement est une grave erreur. Cela conduit à des malentendus, des retards et des maux de tête. Au cours du processus de recrutement, vous rencontrerez de nombreux développeurs qui souhaitent un salaire élevé, une grande autonomie et des horaires flexibles. La plupart ne voudront pas d'examens quotidiens, de délais serrés et d'heures supplémentaires. Prenez ces considérations au sérieux.

Plus que jamais, le travail à distance est une réelle possibilité pour les développeurs, et le monde entier recrute. Les meilleurs travailleront là où ils sont le mieux traités. Et vous ne voulez pas qu'un produit de mauvaise qualité soit produit par des employés mécontents, surtout lorsque vous avez besoin de cette solution de dernière minute avant de le présenter aux investisseurs. Les développeurs heureux feront une exception d'heures supplémentaires pour vous; les malheureux pourraient tout simplement disparaître. 

Tu peux lire tout mon article sur le travail avec les développeurs.

 

5. Ne pas automatiser les tests dès le début

Tout comme la sécurité, les tests de code sont souvent considérés comme facultatifs et comme une perte de temps. Mais à mesure que l'équipe et le produit grandissent, la complexité forcera les tests. Vous ne pouvez pas intégrer un composant dans un système complexe sans aucun test, de peur d'être prêt à faire face aux retombées du client lorsque la production s'emballe et commence à cracher des codes d'erreur aux utilisateurs.

Nous avons toujours effectué des tests unitaires - c'est-à-dire tester chaque composant en soi - avant de le connecter au système complet. Cependant, nous n'avons commencé les tests d'intégration automatisés holistiques qu'à partir de 2019. L'une des principales raisons était le manque de ressources pour retester l'ensemble du système pour chaque mise à jour. Tant que la partie mise à jour fonctionnait, nous avons supposé que tout le système fonctionnerait. 

L'automatisation de vos tests, en particulier pour l'intégration, facilite grandement le test et le retest de chaque partie du site pour chaque intégration. Comme on ne sait généralement pas ce qui changera dans tout le système en raison du nouveau module, les tests d'intégration doivent couvrir l'ensemble du site. Non automatisé, c'est très fastidieux et les QA passent beaucoup de temps sur des tâches banales. Mais une fois automatisés, ils sont libérés.

Cela conduit à une intégration continue, dans laquelle un nouveau code est ajouté en permanence, plutôt que dans de grandes mises à jour. Si vos tests ne sont pas automatisés, vous attendez que de nombreux petits changements soient prêts, puis les publiez tous ensemble, vous testez donc l'ensemble du système une fois. Mais une fois que les tests banals à l'échelle du produit sont automatisés, l'intégration continue peut être adoptée sans gaspiller les ressources d'assurance qualité en tests répétitifs.

 

6. Sous-estimation du délai de sortie: codage (1x), QA (2-3x), stabilisation (2-3x)

En ce qui concerne la technologie, en particulier si vous venez de l'extérieur du monde de la technologie, le codage semble au premier plan. Vous voulez créer un produit technologique, vous le codez et c'est parti, non? Bien sûr, si vous n'en avez pas besoin pour fonctionner.

Vous passerez 1 semaine sur le temps de développement. Ensuite, le contrôle qualité teste tout (ce qui ne peut pas être automatisé), les tickets sont écrits et le code revient aux développeurs pour des corrections de bogues. Ensuite, les QA obtiennent le code modifié et le processus recommence, prenant généralement 2-3 fois le temps de développement initial. Une fois que vous êtes prêt à pousser le nouveau code en production, en cas de big data et de fonctionnalités complexes, vous devez consacrer 2 à 3 fois le temps de développement d'origine pour garantir la stabilité et les performances de qualité. 

En plus, vous êtes passé d'une semaine de sortie (estimation originale pour les nouveaux techpreneurs) à 5-7 semaines. Ne pas être préparé à ce genre de délais excessifs vous fera surprendre les clients et pousser votre équipe trop fort lorsque la date limite est manquée. 

Cela suppose que vous disposiez de la documentation appropriée pour le code en premier lieu et que les développeurs comprennent déjà ce dont l'UX, l'interface utilisateur et la gestion des produits ont besoin.

Construire un produit technologique de qualité nécessite plus de temps que la plupart des gens ne l'imaginent.

 

7. Surplombant la différence de productivité entre les bons et les mauvais codeurs

Il y a beaucoup de pression dans les premiers stades pour saigner le moins d'argent possible. Cela conduit à embaucher des développeurs juniors pour des projets qui ne devraient pas être confiés à des développeurs juniors. Il est bon d'embaucher des développeurs juniors plus tard pour vous aider dans des tâches plus petites, mais le cœur de votre entreprise est votre technologie - un bon développeur expérimenté est nécessaire. Sinon, vous passerez beaucoup de temps à retravailler l'ancien code pour l'évolutivité, la stabilité et l'efficacité. Payer un supplément pour un bon développeur avec une expérience suffisante en vaudra la peine.

Cela nécessite deux qualités: l'expérience et aptitude. Certains développeurs juniors sont des codeurs géniaux, ils ignorent simplement les problèmes futurs que les codeurs expérimentés ne font pas. À l'inverse, 10 ans d'expérience ne se traduisent pas nécessairement par une bonne capacité de codage. Vous devrez vous assurer que les deux qualités sont présentes. Ayant appris de cela, nous passons maintenant beaucoup plus de temps pendant le processus de recrutement pour nous assurer que nous avons le bon candidat à bord. Ensuite, pendant la période de probation, nous évaluons minutieusement leur travail et tout signal d'alarme est traité immédiatement.

Avec la quantité de travail supplémentaire requise pour le débogage, le recodage, le contrôle qualité et la refonte en raison d'un mauvais code, la différence de productivité entre un bon et un mauvais développeur ou inexpérimenté pourrait être de 1000x.

 

8. La tentation de créer toutes les «expériences» en interne

Chaque entreprise souhaite offrir une expérience de qualité à ses utilisateurs. Lorsque vous vous lancez dans la création de cette expérience, il se peut que le backend soit déjà construit. Peut-être que vous avez même quelques clients qui utilisent votre API. Il devrait être très facile de servir ces données à un frontend consommateur, non?

Servir les données, bien sûr, c'est facile. Construire réellement le frontend? C'est une autre histoire. Le frontend est encombrant. Tout d'abord, il y a les graphiques - vous aurez besoin d'un concepteur pour créer ces graphiques. Les API ne sont que des points de terminaison, tout le texte et le code. Oh, et les graphiques devront être mis à l'échelle pour s'afficher correctement sur différentes résolutions d'écran et navigateurs. Et qui ne veut pas d'application mobile? Cela vient avec sa propre foule de problèmes, comme les types de connexion forcée (voir 2 ci-dessus), plusieurs systèmes d'exploitation et divers matériels.

Ma recommandation: vous devrez construire une grande partie du frontend, mais si vous pouvez acheter des composants préfabriqués auprès de tiers, cela vous permettra de couvrir la plupart des scénarios (système d'exploitation, matériel, taille d'écran, etc.), achetez les composants préfabriqués. Votre produit est différencié par le code backend et la conception du frontend, pas par le code de base du frontend. Si vous pouvez l'acheter, évitez les maux de tête liés au contrôle qualité de 15 navigateurs, tablettes et téléphones différents. Vous n'avez pas à tout construire en interne; il peut y avoir une solution d'achat à un prix raisonnable. Ou même open source, si vous avez de la chance. Mais ne vous laissez pas entraîner à croire que l'open source vaut toujours les économies, car parfois la version premium résoudra votre besoin exactement sans temps de développement supplémentaire. 

 

9. Ne pas comprendre les différences de rôle dans un contexte technologique

Une autre idée fausse de ceux qui n'ont pas d'expérience en technologie est que tous les rôles technologiques sont plus ou moins les mêmes. Bien sûr, les développeurs sont backend / frontend, l'interface utilisateur est différente de l'infrastructure. Au tout début, cela peut même être vrai. Quand il n'y a que vous (et peut-être quelques autres), les rôles se mélangent tous. Mais à mesure que l'entreprise grandit, la différenciation et la spécialisation sont nécessaires et les confondre peut être une erreur coûteuse en temps et en qualité. 

Le premier cas d'espèce: le design. Il existe des concepteurs pour l'interface utilisateur (UI) et il existe des concepteurs pour l'expérience utilisateur (UX). L'interface utilisateur est lourde de créativité, ce qui rend tout élégant et agréable à regarder. L'UX est plus une question de structure: comment les utilisateurs circulent-ils dans le système? Que se passe-t-il si une erreur se produit ici, l'utilisateur accède-t-il à l'écran A ou à l'écran B? Cette conception a-t-elle un sens dans le contexte d'où vient juste l'utilisateur ou est-elle simplement source de confusion?

Ne pas connaître la différence entre UX et UI peut conduire à des produits visuellement attrayants qui frustrent et déroutent les utilisateurs. Vous ne vendez pas seulement le look, vous vendez l'expérience. Assurez-vous que cela vaut la peine pour les clients, sinon ils iront ailleurs.

J'ai également confondu les développeurs de logiciels et le personnel DevOps, ce qui a entraîné une pression de travail accrue sur nos développeurs. Les systèmes technologiques, en particulier ceux qui sont aussi complexes que les nôtres, ne sont pas uniquement du code (comme mentionné dans Sin 6). Le Big Data repousse également la limite de ce que les systèmes peuvent faire, de sorte que la stabilité et l'accessibilité deviennent la priorité absolue. Bien sûr, dans le monde d'aujourd'hui, la disponibilité de 100% est prise pour acquise, et ne pas y parvenir est immédiatement perceptible. Nous avons déjà 1,5 DevOps et nous devrons peut-être en embaucher un de plus pour pouvoir ajouter d'autres services d'IA.

Vos développeurs, à la fois backend et frontend, se concentrent sur le code et l'algorithme. Vous avez besoin de DevOps pour vous assurer que la puissance de calcul est là pour exécuter ce code, et il doit être suffisamment stable pour satisfaire les clients. Ne confondez pas DevOps et développement logiciel.

 

9a. Péchés d'autrui

Nous avons reçu quelques mises en garde perspicaces de Jelle van Mourik, une lectrice sur Facebook. Nous allons simplement les exposer ici dans cette seule rubrique (nous avons paraphrasé un peu et bien sûr ajouté notre propre saveur):

  • Ne forcez pas les codeurs à coder ce qu'ils ne codent pas. En d'autres termes, n'essayez pas de faire travailler un programmeur backend sur le code d'interface utilisateur et vice versa. Comme l'USD et le RMB sont tous deux des devises que vous n'utilisez pas de manière interchangeable, il peut s'agir de lignes de code, mais les approches, les structures et l'expérience diffèrent d'un aspect à l'autre. Des erreurs, des retards et des maux de tête considérables attendent quiconque essaie de faire coder par un codeur ce qu'il / elle ne code pas
  • Concevez avant de coder - il n'y a rien de tel que de faire fonctionner l'intégralité de la base de code et de réaliser que la nouvelle conception est incompatible ou nécessite une refonte importante du code
  • Passez au test utilisateur dès que possible, car les utilisateurs sont ceux que vous ne pouvez pas contrôler et ils casseront des choses ou les rejetteront, et c'est mauvais pour les affaires
  • Traitez les commentaires négatifs dans l'application afin que les utilisateurs mécontents expriment ce mécontentement à vous, pas au grand public sur les magasins d'applications iOS et Android
  • Conservez une seule branche stable pour le déploiement, et non plusieurs branches «libérables» qui divergeront, puis dérouter tout le monde et manquer des éléments critiques qui vous prendront une semaine à intégrer à votre branche libérée
  • Gardez un backlog explicite des choses techniques à faire et planifiez des sprints en l'utilisant. Ces choses ont tendance à échapper à l'esprit. En fait, si vous pouvez vous le permettre, vous voudrez peut-être même embaucher une personne pour gérer cela

 

Et ce sont les 9 péchés (plus les péchés des lecteurs). Avez-vous des expériences similaires que vous aimeriez partager avec nous? Y a-t-il d'autres écueils dont vous aimeriez avertir vos collègues entrepreneurs? Veuillez commenter ci-dessous.