{"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\/fr\/the-startup-journey\/9-product-and-technology-sins-of-a-founder-who-learnt-to-code\/","title":{"rendered":"9 P\u00e9ch\u00e9s produits et technologiques d'un fondateur qui a appris \u00e0 coder"},"content":{"rendered":"

Pour c\u00e9l\u00e9brer notre 6e anniversaire et en quelque sorte en compl\u00e9ment de mon article <\/span>15 le\u00e7ons tir\u00e9es de 15000 heures d'entrepreneuriat FinTech<\/span><\/a>, Je souhaite publier certaines de mes plus grosses erreurs afin que d'autres entrepreneurs puissent les \u00e9viter.\u00a0<\/span><\/p>\n

Note de l'\u00e9diteur: 3 * 2 = 6 et 3 ** 2 = 9, donc le titre est toujours li\u00e9 \u00e0 notre 6\u00e8me anniversaire. C'est pourquoi il est important d'apprendre le codage!<\/em><\/p>\n

 <\/p>\n

Avant tout, avant la liste, si vous voulez \u00eatre un techpreneur, vous devez apprendre \u00e0 coder. C'est peut-\u00eatre \u00e9vident, peut-\u00eatre que ce n'est pas le cas.<\/span> \u00a0Apprendre \u00e0 coder m'a permis<\/span> construire la premi\u00e8re version et, au quotidien, me permet de comprendre pourquoi les d\u00e9veloppeurs font ce qu'ils font. Sur une p\u00e9riode de temps, j'ai vraiment aim\u00e9 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.<\/span><\/p>\n

J'ai fait des erreurs et des gens plus exp\u00e9riment\u00e9s m'ont appris pourquoi c'\u00e9tait des erreurs. De nombreux fondateurs peuvent d\u00e9velopper des complexes de sup\u00e9riorit\u00e9, mais conna\u00eetre vos propres erreurs vous permet de rester en contact avec vos employ\u00e9s et lucide.<\/span><\/p>\n

Passons maintenant \u00e0 la liste.<\/span><\/p>\n

 <\/p>\n

1. MVP est un B * tch<\/b><\/h2>\n

Vous avez besoin d'argent pour d\u00e9velopper l'entreprise, mais chaque investisseur souhaite voir un produit minimum viable (MVP). Sans un, le v\u00f4tre n'est qu'une id\u00e9e - ou un r\u00eave, du point de vue de l'investisseur. Les r\u00eaves sont formidables, diront-ils, mais ils ne valent pas l'investissement.\u00a0<\/span><\/p>\n

Vous essayez donc de cr\u00e9er un MVP le plus rapidement possible. C'est le minimum, apr\u00e8s tout.<\/span><\/p>\n

Vous jetez les choses ensemble; vous apprenez au fur et \u00e0 mesure et chaque jour vous donne l'impression d'avoir accompli tellement de choses. Ensuite, vous r\u00e9alisez que vous avez \u00e9crit une ligne de code et cr\u00e9\u00e9 deux nouveaux bogues. Vous prenez des raccourcis et, comme vous n'en avez besoin que pour quelques utilisateurs au stade MVP, vous sautez l'\u00e9volutivit\u00e9. Ce sont des ordinateurs, ils peuvent faire les choses rapidement. \u00c0 quel point cela peut-il devenir grave de passer de 50 \u00e0 5 000 utilisateurs?<\/span><\/p>\n

Pour moi, je ne connaissais pas toutes les meilleures pratiques, comme les tests, la documentation et la pr\u00e9paration \u00e0 l'\u00e9volutivit\u00e9. L'objectif \u00e9tait d'avoir un produit de base pour collecter des fonds, pas de construire l'\u00e9dition d'entreprise. J'ai \u00e9crit le backend en utilisant le framework Ruby on Rails mais le frontend en JavaScript et jQuery. Cela semble raisonnable au d\u00e9but, et \u00e0 l'\u00e9poque, les frameworks frontaux n'\u00e9taient pas aussi populaires. Mais ne pas utiliser de framework sur le frontend nous a probablement co\u00fbt\u00e9 un an de refactoring et de repenser, car l'\u00e9volutivit\u00e9 et la flexibilit\u00e9 \u00e9taient inexistantes et cela s'est traduit par une exp\u00e9rience utilisateur de longs temps de chargement. L'inefficacit\u00e9 signifiait \u00e9galement des co\u00fbts \u00e9lev\u00e9s d'h\u00e9bergement et de traitement dans le cloud. Sans parler d'expliquer (et de red\u00e9couvrir) mon propre code aux d\u00e9veloppeurs, car ma documentation \u00e9tait minime et les concepts fintech peuvent \u00eatre assez complexes pour les codeurs non experts en finance.<\/span><\/p>\n

Vous aurez probablement besoin de 3 \u00e0 6 mois pour acc\u00e9der au MVP \u00e0 partir de z\u00e9ro, et de plusieurs mois suppl\u00e9mentaires pour gagner du terrain. Dans le m\u00eame temps, vous devez lever des fonds, mais les investisseurs veulent juste voir la traction et les revenus. Pour g\u00e9n\u00e9rer des revenus et une traction tout-puissants, de nombreux nouveaux fondateurs essaieront de passer d'un MVP directement \u00e0 la qualit\u00e9 d'entreprise. Mais alors, les arguments de vente tomberont \u00e0 plat car ce ne sera pas la qualit\u00e9 de l'entreprise, mais encore peu viable.\u00a0<\/span><\/p>\n

Lorsque vous cr\u00e9ez votre MVP, pr\u00e9voyez au moins l'\u00e9volutivit\u00e9 et l'efficacit\u00e9. Personne ne peut assurer la p\u00e9rennit\u00e9 d\u00e8s le d\u00e9part, car vous ne savez pas si cela fonctionnera m\u00eame. Mais gardez toujours \u00e0 l'esprit les d\u00e9fis technologiques futurs et att\u00e9nuez-les au mieux d\u00e8s le d\u00e9part.\u00a0\u00a0<\/span><\/p>\n

Apr\u00e8s avoir collect\u00e9 des fonds et embauch\u00e9 des d\u00e9veloppeurs, vous souhaiterez peut-\u00eatre refactoriser le code et r\u00e9\u00e9valuer l'architecture avant de vous concentrer sur plus de fonctionnalit\u00e9s, d'utilisateurs et de revenus. Cet investissement de temps initial pourrait \u00e9viter plusieurs probl\u00e8mes majeurs sur la route. Vous avez construit un <\/span>au minimum <\/span><\/i>produit viable, apr\u00e8s tout, pas un produit final optimal.<\/span><\/p>\n

Une fa\u00e7on d'\u00e9viter l'\u00e9tape MVP et la cr\u00e9ation de produit requise d\u00e8s le d\u00e9part est de lever des millions enti\u00e8rement pour une id\u00e9e, une pratique tr\u00e8s courante dans la Silicon Valley. Bien s\u00fbr, ce n'est un privil\u00e8ge que pour quelques-uns - des entrepreneurs en s\u00e9rie avec de solides ant\u00e9c\u00e9dents, 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, <\/span>certains <\/span><\/i>type de MVP sera n\u00e9cessaire avant de voir les dollars ou les int\u00e9r\u00eats des investisseurs.<\/span><\/p>\n

 <\/p>\n

2. Connexion avec chaque Tom, Dick et Harry - je veux dire Facebook, Twitter, Linkedin, Google et maintenant Apple<\/b><\/h2>\n

Vous pourriez \u00eatre dans l'esprit inclusif. Peut-\u00eatre qu'un utilisateur vous a envoy\u00e9 un e-mail pour vous demander quand il peut se connecter via Facebook. Donc, vous regardez la documentation, et, g\u00e9nial, ce ne sont que quelques lignes de code. Mais vous avez ouvert la bo\u00eete de Pandore. Une fois que les \u00abquelques lignes de code\u00bb se sont d\u00e9velopp\u00e9es \u00e0 plusieurs et que le processus d'authentification fonctionne enfin avec vos syst\u00e8mes, vous devez l'int\u00e9grer dans tous vos canaux de distribution. Si vous avez une seule application sur iOS, ce n'est peut-\u00eatre pas si mal. Mais lorsque vous avez un site Web, des applications Android et iOS et des syst\u00e8mes vocaux comme Alexa et Google Home, vous devez ajouter la fonctionnalit\u00e9 de connexion pour tous.<\/span><\/p>\n

Ensuite, vous serez peut-\u00eatre oblig\u00e9 d'en ajouter d'autres, comme la connexion Apple pour les utilisateurs d'iPhone (voir <\/span>Clause 4.8 de leurs CGU<\/span><\/a>) si vous souhaitez continuer \u00e0 fournir vos services via leur plateforme.\u00a0<\/span><\/p>\n

Maintenant que vous disposez de 6 morceaux de code diff\u00e9rents, un pour chaque canal de diffusion, vous \u00eates pr\u00eat. Jusqu'\u00e0 ce que l'une des API change et que vous deviez corriger votre code sur tous les canaux. Google et Apple ne s'inqui\u00e8tent pas de ce que leurs modifications brisent votre petite application, mais vous serez dans l'eau chaude si c'est le cas.<\/span><\/p>\n

Parfois, m\u00eame les utilisateurs ne savent pas comment ils se sont inscrits - \u00e9tait-ce via Facebook ou Twitter? Si cela est d\u00e9routant pour l'utilisateur, imaginez ce que c'est que de cr\u00e9er toutes ces m\u00e9thodes de connexion, puis de les g\u00e9rer toutes - et la confusion du client lorsque son compte ne refl\u00e8te pas la derni\u00e8re modification qu'il a effectu\u00e9e parce qu'il s'\u00e9tait connect\u00e9 avec une m\u00e9thode diff\u00e9rente.\u00a0<\/span><\/p>\n

\"\"<\/a>

Les int\u00e9grations de connexion invitent toujours plus d'int\u00e9grations de connexion<\/p><\/div>\n

Sauf si vous avez besoin de donn\u00e9es au-del\u00e0 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\u00e9rentes autres m\u00e9thodes de connexion. Lorsque vous avez un flux de tr\u00e9sorerie positif et que vous pouvez vous permettre un d\u00e9veloppeur uniquement pour l'authentification, vous pouvez penser \u00e0 ajouter plusieurs m\u00e9thodes d'authentification.\u00a0<\/span><\/p>\n

 <\/p>\n

3. La tentation de recoder inutilement les fonctionnalit\u00e9s\u00a0<\/b><\/h2>\n

Tout comme plusieurs m\u00e9thodes d'authentification ne sont \u00abque quelques lignes de code\u00bb, vous entendrez les d\u00e9veloppeurs dire \u00able code est trop complexe. Permettez-moi de le reconstruire et ce sera beaucoup plus efficace \u00bb. Appuyez sur le bouton panique!<\/span><\/p>\n

Les d\u00e9veloppeurs ont la volont\u00e9 de rendre leur code efficace et propre, et \u00e0 mesure que de nouvelles fonctionnalit\u00e9s sont ajout\u00e9es, le code devient complexe. Mais le codage n'est qu'une partie, et dans des syst\u00e8mes complexes, comme le corps humain et le climat, de petits changements \u00e0 un endroit du code peuvent avoir des effets d'entra\u00eenement drastiques plus tard ou ailleurs.<\/span><\/p>\n

De plus, une bonne gestion des produits ne se r\u00e9sume pas au codage. Une fois le code pr\u00eat, l'\u00e9quipe d'assurance qualit\u00e9 (QA) doit le tester. Ce processus entra\u00eene invariablement des va-et-vient chronophages (voir Sin 6 ci-dessous). Ensuite, il doit \u00eatre stabilis\u00e9. Si quelque chose d'important change, la messagerie et la conception devront peut-\u00eatre \u00eatre modifi\u00e9es. Des effets impr\u00e9vus surgissent et les plaintes des clients arrivent soudainement.\u00a0<\/span><\/p>\n

Ne r\u00e9parez pas quelque chose qui n'est pas cass\u00e9. Nous l'avons fait et avons pay\u00e9 un lourd tribut \u00e0 temps pour le lancement, la stabilit\u00e9 et la qualit\u00e9.\u00a0<\/span><\/p>\n

 <\/p>\n

4. Ne pas comprendre comment g\u00e9rer et motiver les d\u00e9veloppeurs<\/b><\/h2>\n

Dans le domaine de la technologie, les d\u00e9veloppeurs cr\u00e9ent (et cassent) litt\u00e9ralement votre produit. Les types de personnes attir\u00e9es par le d\u00e9veloppement de logiciels sont une race particuli\u00e8re, et vous devez comprendre comment ils fonctionnent. Vous avez peut-\u00eatre 20 ans dans l'industrie et g\u00e9r\u00e9 des centaines de personnes non technologiques, mais toutes ces connaissances et cette exp\u00e9rience peuvent ne pas vous aider \u00e0 travailler avec des d\u00e9veloppeurs.\u00a0<\/span><\/p>\n

Ne pas comprendre leurs motivations et leur fonctionnement est une grave erreur. Cela conduit \u00e0 des malentendus, des retards et des maux de t\u00eate. Au cours du processus de recrutement, vous rencontrerez de nombreux d\u00e9veloppeurs qui souhaitent un salaire \u00e9lev\u00e9, une grande autonomie et des horaires flexibles. La plupart ne voudront pas d'examens quotidiens, de d\u00e9lais serr\u00e9s et d'heures suppl\u00e9mentaires. Prenez ces consid\u00e9rations au s\u00e9rieux.<\/span><\/p>\n

Plus que jamais, le travail \u00e0 distance est une r\u00e9elle possibilit\u00e9 pour les d\u00e9veloppeurs, et le monde entier recrute. Les meilleurs travailleront l\u00e0 o\u00f9 ils sont le mieux trait\u00e9s. Et vous ne voulez pas qu'un produit de mauvaise qualit\u00e9 soit produit par des employ\u00e9s m\u00e9contents, surtout lorsque vous avez besoin de cette solution de derni\u00e8re minute avant de le pr\u00e9senter aux investisseurs. Les d\u00e9veloppeurs heureux feront une exception d'heures suppl\u00e9mentaires pour vous; les malheureux pourraient tout simplement dispara\u00eetre.\u00a0<\/span><\/p>\n

Tu peux lire <\/span>tout mon article sur le travail avec les d\u00e9veloppeurs<\/span><\/a>.<\/span><\/p>\n

 <\/p>\n

5. Ne pas automatiser les tests d\u00e8s le d\u00e9but<\/b><\/h2>\n

Tout comme la s\u00e9curit\u00e9, les tests de code sont souvent consid\u00e9r\u00e9s comme facultatifs et comme une perte de temps. Mais \u00e0 mesure que l'\u00e9quipe et le produit grandissent, la complexit\u00e9 forcera les tests. Vous ne pouvez pas int\u00e9grer un composant dans un syst\u00e8me complexe sans aucun test, de peur d'\u00eatre pr\u00eat \u00e0 faire face aux retomb\u00e9es du client lorsque la production s'emballe et commence \u00e0 cracher des codes d'erreur aux utilisateurs.<\/span><\/p>\n

Nous avons toujours effectu\u00e9 des tests unitaires - c'est-\u00e0-dire tester chaque composant en soi - avant de le connecter au syst\u00e8me complet. Cependant, nous n'avons commenc\u00e9 les tests d'int\u00e9gration automatis\u00e9s holistiques qu'\u00e0 partir de 2019. L'une des principales raisons \u00e9tait le manque de ressources pour retester l'ensemble du syst\u00e8me pour chaque mise \u00e0 jour. Tant que la partie mise \u00e0 jour fonctionnait, nous avons suppos\u00e9 que tout le syst\u00e8me fonctionnerait.\u00a0<\/span><\/p>\n

L'automatisation de vos tests, en particulier pour l'int\u00e9gration, facilite grandement le test et le retest de chaque partie du site pour chaque int\u00e9gration. Comme on ne sait g\u00e9n\u00e9ralement pas ce qui changera dans tout le syst\u00e8me en raison du nouveau module, les tests d'int\u00e9gration doivent couvrir l'ensemble du site. Non automatis\u00e9, c'est tr\u00e8s fastidieux et les QA passent beaucoup de temps sur des t\u00e2ches banales. Mais une fois automatis\u00e9s, ils sont lib\u00e9r\u00e9s.<\/span><\/p>\n

Cela conduit \u00e0 une int\u00e9gration continue, dans laquelle un nouveau code est ajout\u00e9 en permanence, plut\u00f4t que dans de grandes mises \u00e0 jour. Si vos tests ne sont pas automatis\u00e9s, vous attendez que de nombreux petits changements soient pr\u00eats, puis les publiez tous ensemble, vous testez donc l'ensemble du syst\u00e8me une fois. Mais une fois que les tests banals \u00e0 l'\u00e9chelle du produit sont automatis\u00e9s, l'int\u00e9gration continue peut \u00eatre adopt\u00e9e sans gaspiller les ressources d'assurance qualit\u00e9 en tests r\u00e9p\u00e9titifs.<\/span><\/p>\n

 <\/p>\n

6. Sous-estimation du d\u00e9lai de sortie: codage (1x), QA (2-3x), stabilisation (2-3x)<\/b><\/h2>\n

En ce qui concerne la technologie, en particulier si vous venez de l'ext\u00e9rieur du monde de la technologie, le codage semble au premier plan. Vous voulez cr\u00e9er un produit technologique, vous le codez et c'est parti, non? Bien s\u00fbr, si vous n'en avez pas besoin pour fonctionner.<\/span><\/p>\n

Vous passerez 1 semaine sur le temps de d\u00e9veloppement. Ensuite, le contr\u00f4le qualit\u00e9 teste tout (ce qui ne peut pas \u00eatre automatis\u00e9), les tickets sont \u00e9crits et le code revient aux d\u00e9veloppeurs pour des corrections de bogues. Ensuite, les QA obtiennent le code modifi\u00e9 et le processus recommence, prenant g\u00e9n\u00e9ralement 2-3 fois le temps de d\u00e9veloppement initial. Une fois que vous \u00eates pr\u00eat \u00e0 pousser le nouveau code en production, en cas de big data et de fonctionnalit\u00e9s complexes, vous devez consacrer 2 \u00e0 3 fois le temps de d\u00e9veloppement d'origine pour garantir la stabilit\u00e9 et les performances de qualit\u00e9.\u00a0<\/span><\/p>\n

En plus, vous \u00eates pass\u00e9 d'une semaine de sortie (estimation originale pour les nouveaux techpreneurs) \u00e0 5-7 semaines. Ne pas \u00eatre pr\u00e9par\u00e9 \u00e0 ce genre de d\u00e9lais excessifs vous fera surprendre les clients et pousser votre \u00e9quipe trop fort lorsque la date limite est manqu\u00e9e.\u00a0<\/span><\/p>\n

Cela suppose que vous disposiez de la documentation appropri\u00e9e pour le code en premier lieu et que les d\u00e9veloppeurs comprennent d\u00e9j\u00e0 ce dont l'UX, l'interface utilisateur et la gestion des produits ont besoin.<\/span><\/p>\n

Construire un produit technologique de qualit\u00e9 n\u00e9cessite plus de temps que la plupart des gens ne l'imaginent.<\/span><\/p>\n

 <\/p>\n

7. Surplombant la diff\u00e9rence de productivit\u00e9 entre les bons et les mauvais codeurs<\/b><\/h2>\n

Il y a beaucoup de pression dans les premiers stades pour saigner le moins d'argent possible. Cela conduit \u00e0 embaucher des d\u00e9veloppeurs juniors pour des projets qui ne devraient pas \u00eatre confi\u00e9s \u00e0 des d\u00e9veloppeurs juniors. Il est bon d'embaucher des d\u00e9veloppeurs juniors plus tard pour vous aider dans des t\u00e2ches plus petites, mais le c\u0153ur de votre entreprise est votre technologie - un bon d\u00e9veloppeur exp\u00e9riment\u00e9 est n\u00e9cessaire. Sinon, vous passerez beaucoup de temps \u00e0 retravailler l'ancien code pour l'\u00e9volutivit\u00e9, la stabilit\u00e9 et l'efficacit\u00e9. Payer un suppl\u00e9ment pour un bon d\u00e9veloppeur avec une exp\u00e9rience suffisante en vaudra la peine.<\/span><\/p>\n

Cela n\u00e9cessite deux qualit\u00e9s: l'exp\u00e9rience <\/span>et <\/span><\/i>aptitude. Certains d\u00e9veloppeurs juniors sont des codeurs g\u00e9niaux, ils ignorent simplement les probl\u00e8mes futurs que les codeurs exp\u00e9riment\u00e9s ne font pas. \u00c0 l'inverse, 10 ans d'exp\u00e9rience ne se traduisent pas n\u00e9cessairement par une bonne capacit\u00e9 de codage. Vous devrez vous assurer que les deux qualit\u00e9s sont pr\u00e9sentes. 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 \u00e0 bord. Ensuite, pendant la p\u00e9riode de probation, nous \u00e9valuons minutieusement leur travail et tout signal d'alarme est trait\u00e9 imm\u00e9diatement.<\/span><\/p>\n

Avec la quantit\u00e9 de travail suppl\u00e9mentaire requise pour le d\u00e9bogage, le recodage, le contr\u00f4le qualit\u00e9 et la refonte en raison d'un mauvais code, la diff\u00e9rence de productivit\u00e9 entre un bon et un mauvais d\u00e9veloppeur ou inexp\u00e9riment\u00e9 pourrait \u00eatre de 1000x.<\/span><\/p>\n

 <\/p>\n

8. La tentation de cr\u00e9er toutes les \u00abexp\u00e9riences\u00bb en interne<\/b><\/h2>\n

Chaque entreprise souhaite offrir une exp\u00e9rience de qualit\u00e9 \u00e0 ses utilisateurs. Lorsque vous vous lancez dans la cr\u00e9ation de cette exp\u00e9rience, il se peut que le backend soit d\u00e9j\u00e0 construit. Peut-\u00eatre que vous avez m\u00eame quelques clients qui utilisent votre API. Il devrait \u00eatre tr\u00e8s facile de servir ces donn\u00e9es \u00e0 un frontend consommateur, non?<\/span><\/p>\n

Servir les donn\u00e9es, bien s\u00fbr, c'est facile. Construire r\u00e9ellement 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\u00e9er ces graphiques. Les API ne sont que des points de terminaison, tout le texte et le code. Oh, et les graphiques devront \u00eatre mis \u00e0 l'\u00e9chelle pour s'afficher correctement sur diff\u00e9rentes r\u00e9solutions d'\u00e9cran et navigateurs. Et qui ne veut pas d'application mobile? Cela vient avec sa propre foule de probl\u00e8mes, comme les types de connexion forc\u00e9e (voir 2 ci-dessus), plusieurs syst\u00e8mes d'exploitation et divers mat\u00e9riels.<\/span><\/p>\n

Ma recommandation: vous devrez construire une grande partie du frontend, mais si vous pouvez acheter des composants pr\u00e9fabriqu\u00e9s aupr\u00e8s de tiers, cela vous permettra de couvrir la plupart des sc\u00e9narios (syst\u00e8me d'exploitation, mat\u00e9riel, taille d'\u00e9cran, etc.), achetez les composants pr\u00e9fabriqu\u00e9s. Votre produit est diff\u00e9renci\u00e9 par le code backend et la conception du frontend, pas par le code de base du frontend. Si vous pouvez l'acheter, \u00e9vitez les maux de t\u00eate li\u00e9s au contr\u00f4le qualit\u00e9 de 15 navigateurs, tablettes et t\u00e9l\u00e9phones diff\u00e9rents. Vous n'avez pas \u00e0 tout construire en interne; il peut y avoir une solution d'achat \u00e0 un prix raisonnable. Ou m\u00eame open source, si vous avez de la chance. Mais ne vous laissez pas entra\u00eener \u00e0 croire que l'open source vaut toujours les \u00e9conomies, car parfois la version premium r\u00e9soudra votre besoin exactement sans temps de d\u00e9veloppement suppl\u00e9mentaire.\u00a0<\/span><\/p>\n

 <\/p>\n

9. Ne pas comprendre les diff\u00e9rences de r\u00f4le dans un contexte technologique<\/b><\/h2>\n

Une autre id\u00e9e fausse de ceux qui n'ont pas d'exp\u00e9rience en technologie est que tous les r\u00f4les technologiques sont plus ou moins les m\u00eames. Bien s\u00fbr, les d\u00e9veloppeurs sont backend \/ frontend, l'interface utilisateur est diff\u00e9rente de l'infrastructure. Au tout d\u00e9but, cela peut m\u00eame \u00eatre vrai. Quand il n'y a que vous (et peut-\u00eatre quelques autres), les r\u00f4les se m\u00e9langent tous. Mais \u00e0 mesure que l'entreprise grandit, la diff\u00e9renciation et la sp\u00e9cialisation sont n\u00e9cessaires et les confondre peut \u00eatre une erreur co\u00fbteuse en temps et en qualit\u00e9.\u00a0<\/span><\/p>\n

Le premier cas d'esp\u00e8ce: le design. Il existe des concepteurs pour l'interface utilisateur (UI) et il existe des concepteurs pour l'exp\u00e9rience utilisateur (UX). L'interface utilisateur est lourde de cr\u00e9ativit\u00e9, ce qui rend tout \u00e9l\u00e9gant et agr\u00e9able \u00e0 regarder. L'UX est plus une question de structure: comment les utilisateurs circulent-ils dans le syst\u00e8me? Que se passe-t-il si une erreur se produit ici, l'utilisateur acc\u00e8de-t-il \u00e0 l'\u00e9cran A ou \u00e0 l'\u00e9cran B? Cette conception a-t-elle un sens dans le contexte d'o\u00f9 vient juste l'utilisateur ou est-elle simplement source de confusion?<\/span><\/p>\n

Ne pas conna\u00eetre la diff\u00e9rence entre UX et UI peut conduire \u00e0 des produits visuellement attrayants qui frustrent et d\u00e9routent les utilisateurs. Vous ne vendez pas seulement le look, vous vendez l'exp\u00e9rience. Assurez-vous que cela vaut la peine pour les clients, sinon ils iront ailleurs.<\/span><\/p>\n

J'ai \u00e9galement confondu les d\u00e9veloppeurs de logiciels et le personnel DevOps, ce qui a entra\u00een\u00e9 une pression de travail accrue sur nos d\u00e9veloppeurs. Les syst\u00e8mes technologiques, en particulier ceux qui sont aussi complexes que les n\u00f4tres, ne sont pas uniquement du code (comme mentionn\u00e9 dans Sin 6). Le Big Data repousse \u00e9galement la limite de ce que les syst\u00e8mes peuvent faire, de sorte que la stabilit\u00e9 et l'accessibilit\u00e9 deviennent la priorit\u00e9 absolue. Bien s\u00fbr, dans le monde d'aujourd'hui, la disponibilit\u00e9 de 100% est prise pour acquise, et ne pas y parvenir est imm\u00e9diatement perceptible. Nous avons d\u00e9j\u00e0 1,5 DevOps et nous devrons peut-\u00eatre en embaucher un de plus pour pouvoir ajouter d'autres services d'IA.<\/span><\/p>\n

Vos d\u00e9veloppeurs, \u00e0 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\u00e0 pour ex\u00e9cuter ce code, et il doit \u00eatre suffisamment stable pour satisfaire les clients. Ne confondez pas DevOps et d\u00e9veloppement logiciel.<\/span><\/p>\n

 <\/p>\n

9a. P\u00e9ch\u00e9s d'autrui<\/strong><\/h2>\n

Nous avons re\u00e7u 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\u00e9 un peu et bien s\u00fbr ajout\u00e9 notre propre saveur):<\/span><\/p>\n