Développer sa première application, pas facile ! Voici 6 erreurs et conseils pour ne pas reproduire les miennes à mes débuts 🙂
J’avais la pression, un gros objectif et aucune expérience en tant que développeur professionnel.
Et si je vous dis qu’en plus je n’était pas dans une équipe de développement, que que j’étais seul, que l’application à déjà été “vendue” et la date de livraison déjà fixée… 🙂
Dans cet article je vais vous partager quelle à été ma première application professionnelle et surtout quelles ont été mes erreurs pour vous aider à ne pas les reproduire.
Vous pouvez également consulter podcast ci-dessous :
Ecouter le podcast
Ainsi que la vidéo :
C’est parti !
Sa première application professionnelle OUI, mais dans quelle type de société ?
Il existe globalement trois types de structures dans lesquelles vous allez évoluer pour réaliser votre première application professionnelle.
Le premier type de structure : le cadre idéal
La première structure et bien c’est la structure idéale : vous arrivez dans un cadre où vous avez une équipe de développement que vous intégrez.
Vous avez un chef de projet, peut-être un expert technique qui va vous accompagner s’il y a des difficultés et vous aider dans votre montée en compétence.
ça c’est le premier cas de figure que vous pouvez rencontrer assez facilement en ESN ou par exemple chez un éditeur logiciel / service informatique interne.
Dans ce schéma vous disposez d’ un cadre pour démarrer et vous savez exactement ce que vous avez à faire. Vous avez des spécifications et n’avez plus qu’à créer votre écran ou votre futur fonctionnalité pour démarrer dans le projet client.
Le deuxième type de structure : les jeunes pousses
Le deuxième cadre dans lequel vous allez pouvoir vous inscrire c’est par exemple celui des start-up où un socle technique a déjà été mis en place. Cependant il va évoluer très rapidement au fur et à mesure que la start-up va grossir.
Cela à été le cas pour Stéphanie aujourd’hui CTO, qui à ses débuts chez Deezer à du “prendre le train en marche” dans l’aventure en tant que nouvelle développeuse.
Vous pouvez d’ailleurs retrouver son interview ici : Stéphanie : développeuse web, puis CTO à la campagne !
Suivant la taille de l’entreprise, vous intégrez peut-être une équipe de dix personnes qui va monter rapidement à 50 personnes (peut-être 100 personnes et plus si c’est une start-up a du succès bien sûr) et là vous allez avoir besoin d’être beaucoup plus polyvalent, peut-être un peu moins expert.
C’est beaucoup plus riche mais finalement vous n’allez pas travailler une expertise bien précise que vous pourrez valoriser sur votre cv.
En contrepartie vous allez pouvoir bien sûr valoriser une expérience en start up avec une polyvalence qui va vous permettre de toucher plusieurs outils, plusieurs langages peut-être plusieurs technologies et plusieurs points de vue très enrichissants.
Le troisième type de structure : l’agence tous risques !
C’est celui par lequel j’ai commencé : l’agence tous risques 🙂
C’est un schéma où la créativité est au rendez-vous (c’est le moins qu’on puisse dire…).
Vous êtes seul aux manettes…
Point positif (très !) : On peut choisir tout ce qu’on veut comme technologie et se faire plaisir..
mais le problème c’est qu’il va falloir être au rendez-vous des impératifs qui ont été pris auprès du client et ça c’est un stress énorme.
Quand on est développeur débutant, qu’on ne sait pas par où prendre le problème, qu’on a une forte envie au corps mais qu’on n’a pas forcément encore toute l’expérience et toutes les compétences nécessaires… pas facile
On va faire finalement beaucoup d’erreurs…et par conséquent beaucoup apprendre.
Comment ne pas reproduire ces erreurs (et gagner du temps, sans la boule au ventre)
?
Justement dans cet article je vais vous expliquer les erreurs que j’ai commises et comment ne pas les reproduire.
Pour cela je dois vous décrire rapidement quelle était ma première application professionnelle.
Ma première application professionnelle
Si vous suivez le blog depuis un moment vous devez savoir j’ai commencé ma carrière en tant que technicien systèmes et réseaux c’est à dire que je configurerais des serveurs en entreprise, des réseaux vpn pour mettre ces entreprises en réseau sur différentes sites distants, les sauvegardes, les déploiement mutualisés les déploiements généraux d’applications à travers tous les postes et bien d’autres choses encore.
Alors comment ai-je fait finalement pour basculer développeur et comment est venue cette opportunité de première application professionnelle ?
Mon patron de l’époque avait détecté une opportunité chez un client (société de transport), un sujet qui pouvait être automatisé.
Il s’est aperçu qu’il y avait des retours de tournées (circuit de livraison) fait par les chauffeurs routiers avec plusieurs bons de livraison dont le numéro était à saisir manuellement par des opératrices de saisie.
Mon patron s’est dit… avec un code barre généré, représentant le numéro saisi… on peut sûrement éviter cette saisie et faire gagner un temps précieux aux opératrices.
À son retour, il est venu me voir et m’à dit :
Nicolas ça t’ intéresserait de développer une application super sympa pour un client dans le monde du transport… ça va être génial !
Je me suis dis : oui !! Les étoiles brillaient dans mes yeux.
Le développement est une passion, c’était l’occasion de vraiment mettre le pied à l’étrier !
Il m’a sorti un dessin fait en réunion avec le client qui m’à servi de spécification pour commencer à réfléchir à un chiffrage sur quelque chose que je n’avais jamais fait avec des technologies que je ne connaissais pas !
Surprise : la date de livraison étant quant à elle fixée à l’avance…
Comment démarrer en partant de zéro, sans expérience avec une date de livraison déjà fixée ?
j’avais lu justement que Microsoft avait sorti quelque chose de prometteur : le langage C# en version 1.1 et avec Winforms on pouvait créer des applications de bureau aussi rapidement qu’en Visual Basic. Intéressant !
On pouvait également ajouter des fonctionnalités en achetant différents composants comme par exemple un composant de reconnaissance de codes-barres, encore plus intéressant !!
Comment je le savais ? En tant que lecteur du magazine “Programmez !” je testais des composants fournis sur CD dans le magazine, à titre personnel.
Souvent appelés “sharewares” en ce temps, c’était un bon moyen de se faire une idée à l’époque où internet n’était pas aussi rapide qu’aujourd’hui.
Si on m’avait qu’un jour j’aurais l’honneur d’interviewer le rédacteur en chef du magazine lui-même : François Tonic !
Vous pouvez la retrouver en cliquant ici : Programmez !
Avoir les bons outils, les bonnes technologies et la partie la plus complexe disponible sur étagère c’est super (sur le papier) !
Avec ce composant (.OCX) et C# + le framework .Net je partais de zéro, mais en confiance.
Cela n’à pas été suffisant…
L’erreur de débutant quand on est seul développeur sur un projet (son premier)
Une des premières erreurs que j’ai fait c’est de partir directement dans le technique en me disant que le temps que j’allais passer était uniquement le temps ou j’allais coder…
Eh ça c’est une grave erreur !
J’ai sous-estimé complètement le temps nécessaire pour réellement réaliser l’application.
L’interface graphique de l’application se présentait comme outlook (version 2003).
Ainsi, les bons de livraisons scannés apparaissent comme des e-mail à l’écran avec une image miniature des scans, j’étais content de moi !
L’opératrice pouvait scanner 20 bons en même temps avec une détection automatique des numéros sans avoir à les saisir… très apprécié !
Je m’éclatais et surtout je me disais que finalement si on arrivait à tenir les délais et les engagements nous pourrions peut-être embaucher d’autres développeurs et ouvrir une branche développement dans l’entreprise où je travaillais.
Je suis parti sur mes lignes de code, tête baissée.
J’avais installé un scanner manuel, vous savez les petits scanner A4 et faisais mes tests, sans lever la tête du guidon… à l’image d’un shadock :
[image de shadock]
Je passais beaucoup de temps les soirs et week-end… pour me former et rattraper le retard car forcément, j’apprenais en faisant.
Souvenez-vous : le délai était fixé à l’avance… sans chiffrer le temps nécessaire à la montée en compétence sur la technologie…
Dans ma tête, plus je codais et plus j’avançais. Comme je m’éclatais tout allait bien.
Mais…
1 ère erreur : imaginer les conditions réelles (sans les tester)
le jour de la livraison : tout va bien (au début)
J’ai livré un package d’installation à l’équipe en place chez le client et puis les tests commencent… et l’on voit les bons de livraison s’afficher sur le poste de l’opératrice, ça commence à fonctionner puis
… patatra … !
Une erreur mémoire s’affiche sur l’écran et là c’est le drame.
Gros bug en production et mes collègues ne sont présents que 2 jours chez le client.
Et surtout : je n’ai pas la moindre idée d’où vient le problème, car je n’arrive pas à reproduire le problème sur mon poste.
Le client commence à douter, mes collègues également… je sens petit à petit que la nuit va être longue… (et elle l’à été).
Cette fuite mémoire venait tout simplement des images qui étaient scannées.
j’utilisais un composant image qui choisissait par défaut la meilleure qualité venant du scanner, ce qui fonctionnait sur mon poste de développement avec un petit scanner…
Rien de comparable avec les scanners du client qui pouvait glisser facilement 60 bons de livraison dans le chargeur… et qui faisait saturer mon code…
j’avais « simplement » besoin de corriger mon code pour travailler sur des miniatures et utiliser l’image de haute résolution pour la détection des codes barres.
C’est simple après coup… mais difficile à trouver quand le bug ne se produit pas sur son poste, et que l’on dispose seulement d’un partage d’écran de quelques minutes sur le poste du client pour trouver une piste…
Conseil : n’imaginez pas que vous disposez des conditions suffisantes pour développer, si possible testez au plus tôt les conditions réelles.
2 ème erreur : sous estimer les phases de tests
Vous l’avez compris, vous aurez sûrement la chance d’arriver soit dans un cadre déjà pré établi, soit dans une ESN, soit dans une start-up ou au sein d’un service informatique.
Il y a très peu de chances que vous commenciez seul en tant que développeur débutant.
Mais vous n’êtes pas pour autant à l’abri de ce ce type de problème et pour le diminuer au maximum, il faut reproduire le plus tôt possible les conditions réelles. Parfois ce n’est pas possible, pensez alors à ne pas sous-estimer la phase de test ainsi que les délais qui en découlent.
L’idéal étant un environnement de “pré-production” copie de la production (modulo les données).
Les outils et méthodes d’aujourd’hui permettent d’avoir des conditions quasi identiques entre le poste de développement et la cible en production, mais ce n’est pas toujours le cas…
L’intégration continue, les tests unitaires et les scénarios de retours arrière (rollback) sont autant de points à prévoir au plus tôt, pour ne pas aller au travail chaque matin avec la boule au ventre vers la fin du projet…
Croyez-moi, ce n’est pas agréable 😉
Si il n’y à pas de chef de projet (tous les projets n’ont pas la taille suffisante), pensez-bien à inclure ces étapes dans le planning du projet.
3 ème erreur, ne surestimez pas vos capacités (même si “ça passe”)
Ne pas surestimer vos capacités même si vous êtes passionné.
Même si vous avez la passion, si vous avez l’envie c’est toujours utile de ne pas partir tête baissé et de réaliser un POC.
Un “Prof Of Concept” est un socle minimal applicatif qui fonctionne sans avoir toutes les fonctionnalités mais qui vous permet de vous assurer qu’un scénario (minimal) fonctionne du début à la fin.
Si depuis une saisie utilisateur les données arrivent en base de données en passant toutes les étapes techniques avec succès, vous sécurisez alors vos engagements (validation des choix techniques).
Vous vous assurez également que vous avez le niveau minimal de compétences nécessaires pour réaliser l’application et vous engager sur des temps de réalisation.
C’est du temps bien investi…
Les technologies évoluent constamment, vous pouvez parier sur vos capacités à apprendre rapidement, mais il y à toujours des trous dans la raquette et le temps est la première chose qui commence à manquer quand ça déraille.
Avoir un socle minimal technique en amont du projet, c’est résoudre les problèmes à la source avant qu’ils ne se transforment parfois en naufrage.
4 ème erreur : évaluez votre montée en compétence (avant de démarrer)
Pensez à évaluer votre montée en compétence. Il est important de savoir quel est votre niveau sur une technologie pour une typologie de projet donné.
Et si vous avez besoin de monter en compétences et bien il faut le dire en amont, l’anticiper et le chiffrer.
C’est important pour ne pas passer des soirs et des weekend (surtout quand on est tout seul).
Si le projet ne comporte pas de temps alloué à la formation (ou autoformation le plus souvent) alors vous pouvez augmenter le temps de développement estimé pour chaque tâche.
Pour un projet avec plusieurs membres, vous pouvez utiliser un ratio en fonction de la séniorité des personnes (par uniquement basé sur leur expérience, mais également sur leur niveau actuel par rapport aux technologies utilisées sur le projet).
5 ème erreur : ne sous estimez pas l’importance de la gestion de projet
Erreur supplémentaire à ne pas reproduire : ne sous estimez pas l’importance de la gestion de projets même si le projet est petit.
Elle permet d’avoir une application qui fonctionne dans les temps et qui correspond aux besoins du client.
Souvenez-vous: les spécifications étaient inexistantes dans mon premier projet… croyez-moi, c’est une fausse bonne idée.
Mon responsable est revenu d’un rendez-vous client avec au final des dessins de ce que “devait faire” l’application.
Je disposais donc d’une feuille A3 avec des dessins et c’est là dessus que je devais baser toute la conception de l’ application.
Vous vous en doutez, pas de signature d’engagement client sur le document… 😉
Résultat : il y a eu beaucoup d’allers et retours avec le client pour spécifier les trous dans la raquette.
Dans une gestion de projet standard vous disposez d’ une expression du besoin en amont.
Vous travaillez également dans un cadre. Les projets plus importants bénéficient entre autres d’un document d’architecture, vous pouvez consulter les spécifications fonctionnelles détaillées, des spécifications techniques; etc…
Ne sous-estimez pas cette partie de gestion parce qu’elle fait partie du chiffrage globale (souvent entre 15% et 20%)
Elle est nécessaire et garantit que le client est satisfait du début jusqu’à la fin de la livraison d’applications avec une réelle expérience de satisfaction.
En tant que client, pouvoir s’appuyer en confiance sur une équipe professionnelle est primordial.
Quand vous reprenez votre voiture chez le garagiste, vous n’allez pas vérifier que les freins sont bien serrés ?
Il en va de même pour la réalisation d’un logiciel, et cela passe par le gestion de projet.
Concernant les méthodologies de gestion de projet, nous avions pu échanger avec Thibault sur les forces et les faiblesses de plusieurs méthodologies de gestion de projet, je vous invite à consulter l’article et la vidéo disponibles ici :
Développeur : 7 notions projet simples (qui font la différence)
Vous pouvez également retrouver ses précieux conseils en gestion de projet sur sont blog : Réussir ses projets
6 ème conseil : s’appuyer sur un mentor pour grandir
C’est une aide que j’aurais vraiment apprécié. Avoir un mentor, un référent technique sur lequel m’appuyer pour grandir m’aurait vraiment fait gagner beaucoup de temps et de confiance.
Oui, il faut savoir sortir de sa zone de confort…
Mais pas au risque de mettre en danger le projet et soi-même par la même occasion.
Il est préférable d’apprendre et grandir plutôt que de subir pour apprendre. Les deux peuvent amener au même résultat, mais il y a un chemin quand même plus agréable que l’autre, vous ne croyez pas ?
Avoir quelqu’un pour vous épauler, un senior qui vous accompagne, vous donne des raccourcis et vous évite de faire les mêmes erreurs : c’est précieux.
Que retirer de tout ça ?
Que retirer de cette première expérience professionnelle, de ma première application ?
c’était quelque chose de formidable parce qu’ on a réussi à livrer l’application !
Je suis monté en compétences sur le langage c# et le framework dotnet.
Dans la société suivante, j’ai pu valoriser ces compétences et rejoindre un centre d’expertise Microsoft dans un grand groupe.
J’ai appris de mes erreurs, d’autres projets ont vu le jour et quand j’ai quitté cette société un pôle développement était en place avec plusieurs applications en cours de développement et d’autres développeurs ont renforcé l’équipe qui s’était montée (6 développeurs).
Créer une application en partant de dessins sur une feuille A3 pour sa première expérience en tant que développeur (seul sur le projet) c’est Rock & Roll !
J’ai vraiment eu l’impression de réaliser un projet en mode « agence tout risque » mais finalement j’en garde vraiment un super souvenir et le sentiment que tous ces efforts ont permis de mettre en place une équipe de développement.
Bonne nouvelle, Il y a peu de chances que vous débutiez dans une agence tous risques 🙂
Vous allez sûrement démarrer dans un cadre déjà défini et c’est tant mieux.
Petits conseils que j’aurais apprécié recevoir: n’hésitez pas à dire que vous ne savez pas, prévoyez du temps pour monter en compétence et surtout prenez beaucoup de plaisir à coder (mais sans vous épuiser, ce n’est pas productif) !
Si vous souhaitez suivre d’autres conseils et retours d’expérience vous êtes libre de rejoindre la newsletter en cliquant ici.
Envie de tester le monde du code ?
Et pour découvrir les témoignages vidéos des membres qui ont déjà rejoint “Vivre du Code” => c’est par ici.
Bonne journée, bon code et à bientôt sur la chaîne Youtube, en podcast ou sur le blog pour un nouvel article 🙂
Nicolas.
Merci !
En complément, vous êtes libre de recevoir GRATUITEMENT mon livre "GUIDE D'UN AMI pour démarrer une carrière de DÉVELOPPEUR en 6 étapes". Vous y découvrirez :
Les clefs pour comprendre le métier de développeur et vous permettre de changer de vie.
Des astuces pour monter facilement en compétence sur des nouvelles technologies.
Des conseils pour choisir et apprendre votre premier langage de programmation.
Une vue d'ensemble sur les formations et le marché de l'emploi pour vous aider à faire le premier pas dans votre apprentissage et votre changement de vie.
Je hais les spams : votre adresse email ne sera jamais cédée ni revendue. En vous inscrivant ici, vous recevrez des articles, vidéos, offres commerciales, podcasts et autres conseils pour vous aider à coder et changer de vie. Voir mentions légales complètes en bas de page. Vous pouvez vous désabonner à tout instant.
