Ceci est une histoire où « toute ressemblance avec des événements ou des personnes réels serait purement fortuite », plus quelques bêtises. Ne le prenez pas personnellement. C'est parti...

Je tenais un verre d'eau, me sentant un peu mal à l'aise. En face de moi, directement, se trouvait notre invité, le président Wang. Il avait fait son chemin ailleurs et, ces dernières années, on disait qu'il s'en sortait plutôt bien. Voyant l'essor d'Internet mobile, il voulait naturellement en profiter. Bien que le domaine d'activité du président Wang soit quelque peu lié à l'informatique, il n'avait pas touché à la technologie depuis si longtemps que certaines choses ne lui étaient pas familières, alors il voulait toujours me consulter — moi, un vieux programmeur qui avait passé plus de dix ans en développement de première ligne. Plus de dix ans de développement pouvaient signifier plusieurs choses, mais là n'est pas la question, alors ignorons temporairement ce détail.

La raison pour laquelle je me sentais mal à l'aise était que je ne savais pas trop comment répondre à la demande du président Wang, comme si j'étais tombé dans une sorte de contemplation habituelle.

Le président Wang se leva, me tendit son téléphone et dit : « Regardez, juste une application comme celle-ci. » Il fit défiler l’écran quelques fois, un peu maladroitement. Je ne regardai pas très attentivement, car je savais que cette question était difficile — c’est le genre qu’on pose à tout développeur, et probablement la plus fréquente : « Combien de temps faut-il pour développer une application comme celle-ci ? » J’avais vraiment envie de dire « Je ne sais pas », ce qui serait peut-être la réponse la plus directe et la plus exacte, mais face au président Wang, un vieil ami, répondre ainsi aurait pu être un peu impoli. Alors, à ce moment-là, en plus de réfléchir vaguement aux aspects que l’application qu’il montrait impliquait, je devais aussi organiser mes mots pour lui dire poliment que je ne pouvais pas l’estimer. « Vous voyez, juste une application aussi simple », poursuivit le président Wang en manipulant encore l’écran quelques fois, puis il me regarda avec une certaine attente dans les yeux.

Je dis avec prudence : « Franchement, je ne peux pas l’affirmer. Je n’ai pas non plus beaucoup d’expérience dans ce domaine. Même si j’ai déjà fait du développement d’applications, c’est très différent de ceci. Il faudrait que j’analyse toute la logique en détail avant de pouvoir estimer le temps. »

Le président Wang ne sembla pas convaincu par mes paroles. Il agita son téléphone et dit : « Je n’ai pas beaucoup d’exigences ; c’est en fait plus simple que ceci. » En désignant certains endroits de l’écran, il poursuivit : « Ceci, ceci et ceci peuvent tous être retirés. J’ai juste besoin d’une liste comme celle-ci, avec des détails dedans, où l’on peut consulter et modifier... »

Naturellement, je pensai qu’il s’agissait d’une attitude typique consistant à « supposer que c’est simple ». Je me dis qu’il fallait que je lui fasse prendre conscience de la complexité du problème, alors je demandai en retour : « Faut-il se connecter ? »

Après une brève pause, le président Wang dit : « Bien sûr. »

« Quel type de connexion ? Nom d’utilisateur et mot de passe, ou connexion par téléphone, ou connexion tierce comme QQ, Weibo ou WeChat que l’on peut emprunter ? »

Cette fois, le président Wang sembla réfléchir un instant : « En tant que produit d'Internet mobile, je pense qu'une connexion par téléphone est absolument nécessaire. QQ, Weibo — oh, WeChat, WeChat est certainement nécessaire aussi... Oh, vous avez mentionné le nom d'utilisateur et le mot de passe plus tôt ; cela devrait aussi être nécessaire. »

Je continuai sans peine à demander : « Alors vous aurez besoin d'une inscription. Si vous prévoyez d'utiliser la connexion par téléphone, vous devrez trouver une plateforme SMS. Pour la connexion WeChat, vous devez d'abord effectuer la vérification de l'identité de l'entreprise. De plus, avec la connexion et le mot de passe, vous aurez besoin d'une fonction de récupération de mot de passe, n'est-ce pas ? »

« Cela va de soi. »

« Avec plusieurs méthodes de connexion, vous devez trouver une logique raisonnable pour les “intégrer”. L'approche la plus courante est, bien sûr, la liaison de compte — par exemple, lier votre compte à un numéro de téléphone afin de pouvoir utiliser le numéro de téléphone pour vous connecter au même compte. Il en va de même pour la connexion WeChat. Mais les utilisateurs de l'Internet mobile d'aujourd'hui détestent vraiment les processus d'inscription, ils demandent donc souvent de se connecter directement avec leur téléphone ou WeChat, et que le processus d'inscription soit effectué automatiquement. Compte tenu de cette situation, si un utilisateur se connecte d'abord avec WeChat, puis plus tard avec son numéro de téléphone au lieu de lier, cela créerait deux comptes différents qui ne pourraient plus être “intégrés”. Nous devons élaborer une solution relativement complète... »

Le président Wang semblait quelque peu impatient face à ce que je disais : « Est-ce que ça doit vraiment être aussi compliqué ? Regardez cette application — n'a-t-elle pas déjà toutes ces choses ? »

« Avez-vous essayé pour voir si le problème que j'ai décrit plus tôt existe ? »

Mais le président Wang ne semblait pas préoccupé par le problème. Il voulait seulement savoir combien de temps il faudrait pour construire une telle application, et bien sûr combien cela coûterait — c'était aussi quelque chose qui lui tenait à cœur. Il dit d'un ton confiant : « Qu'y a-t-il à craindre des problèmes ? Quelles sont les difficultés ? Je crois qu'elles peuvent toutes être résolues. Mais le temps est critique ; nous devons aller vite. Nos concurrents ne nous attendront pas. C'est juste une chose comme ça — réfléchissez-y, combien de temps cela prendra-t-il ? »

À en juger par son attitude, il était exactement le genre de personne à succès qui avait réussi, et en tant que simple programmeur, j'avais vraiment du mal à m'exprimer devant lui. J'avais voulu continuer à lui dire combien les détails étaient importants, mais il m'interrompit : « Non, pas besoin d'être aussi précis. Estimez juste une fourchette — deux semaines ? Ou deux mois ? »

Je sentis qu'il n'y avait plus besoin de cacher quoi que ce soit : « Je ne sais vraiment pas. Peut-être qu'une équipe excellente pourrait le faire en deux semaines, même si je ne crois pas vraiment qu'une telle équipe incroyable existe, mais je ne suis clairement pas celui qui pourrait créer un tel miracle. » Je me disais que même une fourchette humoristique comme « deux semaines à deux ans » pourrait être fausse.

Le président Wang sembla très déçu de ma réponse. Mais c'est une personne dotée d'une grande capacité d'exécution — s'il veut faire quelque chose, il passera certainement à l'action, agira rapidement et obtiendra des résultats. J'admire vraiment ce style décisif, mais pour son projet, je ne pouvais vraiment pas être utile. Pourtant, par politesse, je dis : « S'il y a des problèmes techniques, vous pouvez toujours venir me demander. »

====================== Un séparateur pas très glamour ======================

« Combien de temps faut-il pour construire une application ? » Cette question est probablement plus difficile à répondre que de prédire combien de jours il reste à vivre à une personne. Comment peut-on répondre à une telle question avec si peu d'informations ?

Dans l'ensemble, plus les exigences sont claires et plus l'équipe est mature, plus l'estimation du temps est précise. Mais le développement logiciel — quel que soit le nombre d'années qu'il évolue, quelles que soient les méthodologies proposées — ne peut pas avoir ses « heures-homme » calculées avec autant de précision que dans la fabrication traditionnelle, en raison des relations logiques complexes à l'intérieur. Le génie logiciel ne pourra jamais être produit en masse.

Les utilisateurs ne voient qu'une application. S'ils utilisent iOS, ils pourraient ne jamais entrer en contact avec Android et ne pas réaliser qu'en plus d'une version iOS, les développeurs doivent aussi créer une version Android, ou bien pourrait-il également y avoir une version Windows ? Cela signifierait sans aucun doute encore plus de travail. Ou peut-être qu'une version web peut tout faire ? Peut-être ne penseriez-vous pas ainsi après en avoir réellement construit une. D'ailleurs, un modèle comme la mini-boutique de WeChat peut-il vraiment s'appliquer à toutes les situations ? De plus, à moins d'une anomalie réseau, les utilisateurs ordinaires ne remarqueront même pas l'existence des serveurs. Les serveurs travaillent toujours silencieusement pour les utilisateurs 24 heures sur 24, et leur difficulté de développement n'est probablement pas inférieure à celle de l'application elle-même. Et maintenir l'application nécessite de la main-d'œuvre ; une fois qu'elle prend de l'ampleur, vous pourriez même devoir constituer une équipe professionnelle. Ils ont besoin d'un « backend » pour consulter et traiter les données à tout moment. Si vous devez consulter et traiter des données n'importe quand et n'importe où, vous devrez peut-être créer une application dédiée pour le backend.

Ce principe est quelque peu similaire : nous voyons un avion de chasse accomplir magnifiquement sa mission de destruction d'ennemis dans le ciel, et supposons que c'est simplement parce que l'avion lui-même est impressionnant, en ignorant souvent les systèmes de soutien qui l'entourent. Sans pilotes qualifiés, centres de commandement, radars au sol, avions d'alerte avancée, approvisionnements, bases aériennes ou porte-avions, équipes au sol, etc., l'avion de chasse perdrait sa capacité de combat. Il en va de même pour une application : ce n'est pas quelque chose de terminé simplement parce qu'elle fonctionne. L'infrastructure de soutien et le travail de maintenance ne sont pas moins simples que l'application elle-même.

Outre ces aspects majeurs, il existe également beaucoup d'incertitude dans les détails, c'est pourquoi une équipe mature est particulièrement importante. Un développeur expérimenté saura — au moins approximativement — quels problèmes seront rencontrés pendant le développement, lesquels sont simples et lesquels peuvent prendre beaucoup de temps. Cela dépend de l'expérience. Je dis souvent une phrase, qui est :""Ne dites pas à la légère que quelque chose est simple si vous ne l'avez jamais fait."L'attitude consistant à "supposer que c'est simple" n'apporte rien de bon à un projet. Si vous n'êtes pas sûr, allez consulter quelqu'un qui a de l'expérience dans ce domaine. Même si vous n'obtenez pas de réponse précise, vous obtiendrez au moins une direction générale. Faites des recherches dans ces directions, et vous découvrirez les problèmes auxquels vous serez confronté — même si, souvent, ce ne sera toujours pas tous.

À propos de « sous-estimer la difficulté », il y a une histoire classique de mon ancienne entreprise. À l'époque, il y avait un petit projet : nous prévoyions d'ajouter la prise en charge de plusieurs langues à un programme qui tournait déjà sur des instruments et ne prenait en charge que l'anglais. Le programme n'était pas volumineux, et le contenu concerné n'était pas non plus trop important. Les ingénieurs ont d'abord pensé qu'il s'agissait d'une simple tâche de traduction qui pourrait être réalisée en deux semaines au maximum. Mais une fois lancés, ils ont découvert que ce n'était pas simple du tout. D'abord, la traduction devait être faite par des professionnels ; nous ne pouvions pas bien la faire nous-mêmes—aucun de nous ne maîtrisait les langues européennes. Ensuite vint la conversion d'unités : certains pays utilisent le système métrique, d'autres le système impérial, il fallait donc en tenir compte, y compris les formats d'affichage des dates. Du coup, impossible de dire combien de travail supplémentaire était apparu. Quand tout cela fut en grande partie terminé, ils ont découvert que les mots allemands étaient trop longs et ne tenaient pas sur les écrans des instruments—ils dépassaient la zone d'affichage. Ils ont donc ajusté les polices et réduit le contenu, et ont tenu des réunions pour en discuter N fois dans un sens et dans l'autre. Enfin, au moment de publier, ils ont constaté qu'avec tous ces changements, la taille du programme était devenue beaucoup plus importante, et que le stockage de certains instruments ne pouvait pas la contenir. Là, tout le monde est resté bouche bée. Ils ont donc optimisé et simplifié, et le programme a commencé à devenir un peu désordonné. Au final, ils ont à peine passé l'inspection du service de contrôle qualité et l'ont enfin publié—pour se rendre compte que cela avait pris six mois en tout. Avec le recul, une raison importante de ce temps passé était un manque d'expérience ; la méconnaissance du multilinguisme et de l'internationalisation les a conduits sur de nombreuses mauvaises pistes. Donc, comme je l'ai mentionné plus tôt, avoir une équipe mature est particulièrement important.

Lorsqu'on estime le temps d'un projet, on ne compte souvent que « le temps passé à écrire du code », en laissant de côté le temps passé à se disputer avec des patrons ou des clients, à faire l'analyse des besoins, la conception, les tests et la correction des bugs. Additionnés, ces temps dépassent généralement de beaucoup le temps passé à écrire du code. Personnellement, je ne donne pas facilement un délai d'achèvement court juste pour faire plaisir à mon patron. Pourquoi ? Parce que ce n'est tout simplement pas faisable—alors pourquoi mentir ? Si le développement d'une nouvelle fonctionnalité prend une semaine, je double généralement ce temps, et c'est déjà relativement « non conservateur ».

Même si l'on ne compte que le temps passé à écrire du code, celui-ci est souvent sous-estimé. Le patron ou le client peut être mécontent de ce que vous avez développé—peut-être avez-vous mal compris ses exigences fonctionnelles, ou l'interface est saccadée, ou la couleur de l'icône n'est pas jolie. Vous êtes développeur, pas graphiste. Même si vous pouvez éventuellement passer pour un graphiste en cas de besoin, vous n'êtes après tout pas professionnel. Plus important encore, concevoir l'UI et créer des images prend aussi beaucoup de temps. Quand vous vous battez désespérément pour « un seul pixel », n'aspirez-vous pas à avoir un designer dans l'équipe ? Dans ces moments-là, vous devez rappeler au patron qu'il faut faire des compromis entre le temps et les fonctionnalités. Le patron sera certainement mécontent, mais il n'a pas d'autre choix que de faire des compromis sur certaines fonctionnalités. Même si cela permet à un projet en difficulté d'être lancé plus tôt, cela donne aussi au patron une excellente excuse pour l'échec futur du projet : « Nos ingénieurs étaient trop mauvais ; ils n'ont pas fait ce que je leur avais dit. »

Outre le fait de se plaindre que ce que vous avez fait n'est pas assez beau, les patrons ou les clients soulèveront aussi beaucoup d'autres choses : Peut-on faire en sorte que cette interface permette la sélection multiple ? Peut-on ajouter une fonctionnalité de notification ? Il devrait y avoir un statut lu/non lu. Peut-on rendre l'interface un peu plus fluide ? Pourquoi le programme a-t-il fait un « crash » une fois hier soir... Les exigences listent juste des fonctionnalités, mais ne disent pas à quel point cette UI doit être belle, ni que la stabilité du programme doit être bonne, encore moins quel débit doit être atteint. Et bien sûr—ce qui est peut-être plus important—la sécurité n'est pas mentionnée non plus. Vous êtes alarmé : c'est vrai, s'il y avait des hackers—non, tant qu'un utilisateur malveillant avec un minimum de connaissances techniques voudrait inonder notre serveur, ce serait trop facile, et je n'ai pris aucune de ces mesures de protection ! Heureusement, le projet est encore trop méconnu, donc pas besoin de s'en préoccuper pour l'instant. (Il semble que la plupart des applications ne vivent jamais assez longtemps pour avoir besoin d'envisager cela.)

Toutes ces choses—que vous les appeliez fonctionnalités, détails ou robustesse—ne sont pas des choses qui peuvent pousser automatiquement du sol ; elles demandent toutes du temps de réflexion et de mise en œuvre. Certaines relèvent même d'un travail d'« ingénierie système ». Si vous traitez la tête quand la tête fait mal et le pied quand le pied fait mal, le système sera plein de « fils volants » partout, ce qui laissera sans aucun doute de nombreux dangers cachés pour la maintenance future. Vous, l'ingénieur, les avez-vous tous pris en compte ? Sans parler de la question « insignifiante » de l'ordinateur peu performant que le patron vous a acheté pour réduire les coûts, qui vous rend fou toute la journée.

====================== Ligne de séparation pas très sophistiquée ======================

Ainsi, après que le patron Wang m'a dit au revoir, il a créé une entreprise à la vitesse de l'éclair, a enregistré un nom de domaine, a obtenu un bureau, et a même rassemblé un groupe de personnes et fait démarrer les choses à plein régime. Je ne pouvais que sentir que je n'étais pas de taille face à cette dynamique et cette motivation. J'ai bien un peu regretté de ne pas avoir poursuivi une carrière avec lui, mais ce n'était qu'un flash émotionnel ; la rationalité m'a ramené dans les quelques centaines de millisecondes suivantes : mieux vaut ne pas y aller—lui et moi, nous n'arrivons tout simplement pas à communiquer.

Le projet du patron Wang a ensuite décollé et s'est développé rapidement, et aujourd'hui il est le PDG d'une entreprise évaluée à plusieurs centaines de millions. Quant à moi, je me sens de plus en plus comme un loser, assis seul dans mon bureau, tenant encore cette tasse d'eau, plein de dépit—arrête ! Ne serait-ce pas plus dramatique ? Mais bien que j'aie déclaré au tout début que « toute ressemblance dans cette histoire est purement fortuite », je ne peux pas simplement inventer les choses. La vraie fin est : ils ont bien bossé pendant quelques mois, puis d'un coup, plus un mot. Je voulais initialement appeler le patron Wang pour demander ce qui se passait, mais malheureusement il était devenu une autre personne super occupée, sans aucun intérêt à discuter avec moi. Bon, la fin est à peu près la même—je suis toujours le programmeur qui continue de rester assis au bureau à galérer. Pff, arrête de réfléchir, au travail !

Source : http://www.cnblogs.com/guogangj/p/4676836.html