Maîtriser de nombreuses technologies et savoir construire des services complexes et très chargés ne suffit pas lorsque l'on est développeur dans une startup ou un projet en pleine croissance. Au cours de ma carrière, j'ai été impliqué dans de nombreux projets en pleine croissance et j'ai créé deux startups à partir de zéro. Dans cet article, je partagerai mes expériences sur les points sur lesquels se concentrer pendant le développement et pourquoi le perfectionnisme gâche même les meilleures idées. Les outils sont un moyen, pas une fin Pour tout développeur, lancer seul un projet est un défi de taille. Il est très naturel de ressentir le besoin de tout faire à la perfection. Il m'a fallu un certain temps pour réaliser que le désir de perfectionnisme est le plus souvent le reflet de la peur que mes collègues me jugent pour une « impression » supplémentaire ou pour ne pas utiliser un modèle ou un outil ; et voilà : le serveur de production va s'effondrer, les clients vont se plaindre, je serai viré et le monde prendra fin. Tout outil, modèle ou langage de programmation n'est , pas un objectif. Question plus souvent : Pourquoi ai-je besoin de cela maintenant ? Que va-t-il apporter ? Quelles mesures cela va-t-il améliorer ? Par exemple : pourquoi configurer un linter maintenant ? Pourquoi personnaliser CI/CD maintenant ? Si vous effectuez un déploiement 10 fois par jour, vous en avez probablement besoin. Si vous déployez une version une fois par semaine ou par mois, ce n'est probablement pas le cas. Si la personnalisation CI/CD prend beaucoup de temps, mais n’accélère pas le développement ou n’apporte pas de valeur au projet et aux clients, doit-elle être mise en œuvre maintenant ? qu'un outil Dans un projet favori, il est logique d'essayer quelque chose de nouveau : améliorer sans cesse la structure du référentiel et du code, expérimenter des modèles, etc. . L'objectif principal d'un projet de production est d'apporter de la valeur aux clients. Les clients ne sauront jamais que nous utilisons des guillemets doubles au lieu de guillemets simples et de singletons, et qu'il n'y a pas de code en dur. Dans ce cas, les outils que nous mettons en œuvre sont l'objectif La refactorisation n'est nécessaire que lorsqu'elle permet d'augmenter la vitesse et les performances de développement, de réduire les bogues ou de débloquer le retard. L'engagement envers la qualité doit poursuivre les objectifs du produit, et non votre désir de perfectionnisme. Il est donc important de se rappeler : un développeur dans un projet en pleine croissance n'est jamais perfectionniste. La valeur commerciale passe avant tout Pour un développeur travaillant sur un projet en pleine croissance, il est essentiel d'en comprendre la valeur commerciale. Lorsque vous avez l'habitude d'être un développeur régulier qui code uniquement selon des spécifications toutes faites, cela peut être difficile au début. Lorsque le produit vient de naître, la valeur pour les utilisateurs n'est pas encore prouvée, mais la valeur à prouver existe dans l'esprit des parties prenantes. À ce stade, vous pouvez commettre l’erreur de surcharger la base de code avec une logique inutile. Par exemple, vous devez écrire un gestionnaire de commandes. Vous créez une table avec les commandes dans la base de données et une deuxième table avec les types de commandes, bien qu'il n'existe encore qu'un seul type. Disons que vous faites cela parce que la partie prenante insiste sur le fait qu'un jour cette logique pourrait être nécessaire. En réalité, cela ne sera peut-être jamais nécessaire. Ne créez pas d'entités inutiles si elles n'ont aucune valeur pour le moment, et plus important encore, ne perdez pas de temps et d'argent pour votre entreprise. Une question raisonnable pourrait être posée : « Est-ce que je vais discuter avec une partie prenante ? » Eh bien, parfois vous le ferez. Les parties prenantes attendent une analyse détaillée. Les spécificités des projets en croissance sont le plus souvent le manque de ressources, les développeurs doivent donc avoir des compétences analytiques. Vous devez constamment valider la valeur des fonctionnalités du produit, car sa viabilité en dépend littéralement. Si vous vous dispersez, l'entreprise manquera de ressources et vous archiverez le référentiel. Posez beaucoup de questions : « Pourquoi implémenter cette fonctionnalité maintenant ? Devrions-nous résoudre ce problème maintenant ? Ce problème existe-t-il réellement ? » C'est exactement la même chose que celle décrite ci-dessus avec les technologies. Être capable de poser les bonnes questions révèle votre professionnalisme. Vous devez consacrer votre temps et vos ressources commerciales uniquement à des choses qui apportent réellement de la valeur à vos clients. Les hackathons sont un excellent exemple montrant comment la compréhension de la valeur commerciale influence le résultat. Dans un délai limité, une solution non idéale mais réalisable à un problème clairement défini doit être présentée. Lorsque les développeurs s'inspirent du projet et comprennent clairement pourquoi ils le font, le résultat est bon même en 2 jours. Le plan dépend des risques Imaginez un jeu de stratégie : vous avez un bûcheron et une recrue. Le but est de créer un guerrier. Premièrement, le bûcheron doit ramasser du bois et construire des casernes, où la recrue peut suivre une formation militaire. Pour récolter le bois, le bûcheron doit atteindre la forêt en passant par une partie inexplorée de la carte. À en juger par la carte, la forêt peut être atteinte en une journée de jeu, la coupe de bois prendra environ une demi-journée et la construction de la caserne prendra une semaine. La caserne apparaîtra donc dans une dizaine de jours. Le bûcheron met presque une journée pour arriver dans la forêt, mais soudain la rivière bloque le chemin. L’objectif change : il faut construire un barrage, un pont ou un bateau pour passer de l’autre côté, ou peut-être vaut-il mieux chercher des forêts ailleurs. Une évaluation prématurée conduit à un effondrement de la stratégie. Si l'éclaireur avait d'abord exploré une partie non découverte de la carte, ce risque aurait pu être évité. Un développeur expérimenté reconnaît les risques qui ne sont pas évidents pour la partie prenante : les intégrations avec des services tiers, la complexité de l'extension de la base de code, etc. Il est de votre responsabilité d'évaluer les risques et d'en avertir. Le plus souvent, les parties prenantes ignorent ces risques, mais ils affectent l’évaluation, qui leur tient à cœur. intégrer votre service à un service de paiement. Tout d’abord, configurez le service de paiement, accédez-y et recherchez les endroits où les choses peuvent mal tourner. Avant d’intégrer, comprenez comment intégrer. Il est préférable de consacrer une journée à la recherche plutôt que de découvrir après deux ou trois semaines de développement que la fonctionnalité ne peut pas être terminée à temps ou que l'intégration a échoué parce que le service de paiement a modifié les conditions ou désactivé le support pour la fonctionnalité nécessaire. . Un exemple de tâche : Après avoir évalué les risques, vous devez planifier le travail et fournir une estimation du temps nécessaire à la tâche. Voici le framework que j'utilise : Écrivez des scénarios ou visualisez-les à bord : par exemple, l'utilisateur clique sur un bouton et le document est téléchargé. Choisissez des approches que vous comprenez. Analysez comment le script pourrait fonctionner d'un point de vue plus technique. Plus il y a d'options, mieux c'est. J'évalue les options et choisis une solution potentiellement évolutive avec des risques minimisés qui résoudrait le problème le plus rapidement possible. Décomposez les scénarios en parties logiques qui doivent être codées. Estimez chaque partie en jours, puis multipliez par le coefficient 1,11. C'est mon coefficient magique personnel, qui correspond à mon anniversaire le 11 octobre. C'est bien sûr une blague (ou pas). Mon conseil est d'ajouter quelques jours, voire semaines, à l'estimation, en fonction de la portée du projet. Même si nous essayons de prévoir autant de risques que possible, certains ne sont pas prévisibles. Il est préférable de faire avancer les choses plus tôt que de ne pas réussir. N'ayez pas peur de donner une estimation plus élevée : lorsqu'une partie prenante demande : « Ne pouvez-vous pas le faire plus rapidement ? » ne vous contentez pas de répondre « Non », mais justifiez pourquoi. Parlez des risques, démontrez des scénarios et donnez des exemples. La partie prenante doit comprendre que vous avez analysé le problème et que vous ne l’avez pas simplement évalué au hasard. Aspect important : votre état d’esprit est aussi un risque. Planifiez vos vacances, et surveillez votre santé mentale pour rester motivé et ne pas vous épuiser : c'est votre responsabilité. MVP n'est pas un vaisseau spatial La question m'a dérangé toute ma carrière. Cela semble simple – Produit minimum viable. « Comment créer un MVP ? Définition Wikipédia : Un produit minimum viable (MVP) est une version d'un produit avec juste assez de fonctionnalités pour être utilisable par les premiers clients qui peuvent ensuite fournir des commentaires pour le développement futur du produit. J'ai souvent observé que lorsque vous devez construire un MVP, cela finit parfois par ressembler davantage à la construction d'un vaisseau spatial qui prend un temps ridiculement important. L'objectif principal au stade MVP est d'obtenir un retour rapide du client et, sur la base de ce retour, de convenir avec la partie prenante si nous « allons tout droit » ou « prenons un virage à droite ». La meilleure façon de recueillir des commentaires consiste à utiliser des mesures. C'est bien s'ils réussissent sans eux, mais si ce n'est pas le cas, vous saurez au moins pourquoi. Je vais vous parler de mon premier MVP. J'ai trouvé de nombreux outils et frameworks : J'ai décidé d'utiliser tout cela parce que ces frameworks sont utilisés dans les grandes entreprises et j'en ai entendu parler lors de conférences, de conférences et sur YouTube. UML, modèles de conception, feuille de route, points d'histoire, spécification des exigences système, ADR, tests d'interface utilisateur, etc. Le but du service était de stocker des données sur les tests. J'ai élaboré une feuille de route pendant un an, dessiné une architecture détaillée en , passé beaucoup de temps à choisir un framework pour le backend, mis en place un système de tests et de journaux dans Sentry et calculé la charge sur de nombreux utilisateurs au lieu des 10 attendus. -15. Je voulais réaliser le projet parfait. UML La première version a duré 6 mois. Vous pouviez consulter tous les lancements et graphiques et télécharger des rapports, mais il y avait un problème avec la collecte de données. Deux ou trois fois par semaine, un rapport erroné apparaissait, ce qui rendait le service impossible à utiliser, mais j'ai obstinément suivi le plan. Au cours des années suivantes, j'ai eu de nombreux projets différents et j'ai essayé de lancer ma startup. J'ai découvert le marketing, les ventes et la douleur des clients. L’expérience a changé mon état d’esprit et m’a permis de développer les approches que je partage dans cet article. Je vais décrire une tâche récente pour démontrer comment ils ont fonctionné dans la pratique. J'avais besoin d'accélérer la méthode API, ce qui agaçait les utilisateurs par sa lenteur. Le plan était de le déplacer vers un service distinct du monolithe, où il y avait des difficultés dues à de nombreuses intégrations avec les services internes et les structures de données. Ce projet était expérimental : personne ne savait si l'accélération était possible. Bien sûr, je pourrais continuer et suggérer de tout réécrire et de le rendre parfait. J'ai commencé par faire des recherches sur le monolithe et les services internes et j'ai étudié les risques des intégrations. Ensuite, j'ai créé une stratégie à l'aide d'un diagramme simple dans Miro, j'ai tout décomposé en itérations et c'est seulement ensuite que j'ai commencé à travailler. De temps en temps, il y avait des problèmes d'intégration dont la partie prenante était la première informée. Tout d’abord, nous les avons résolus. Oui, il y avait encore une dette technique dans le projet : linters, tests incomplets, anciens schémas dans la base de données - mais le problème des clients a été résolu. À chaque itération, j'ai collecté des métriques sur les performances de la méthode API : Lent et avec des erreurs, sans relâche. 2x plus rapide et avec erreurs, sans release. 5x, 1 % d'erreurs sur toutes les demandes. 6x plus rapide, sans erreurs. Toutes les itérations ont atteint la cible, et au 4ème essai, nous avons atteint 100 %. Il faudrait 10 itérations pour tout réécrire à partir de zéro, mais même en moins de temps, nous avons obtenu un service évolutif qui a résolu le problème. La seule question est l'approche. Codex d'un développeur dans un projet en pleine croissance Abandonnez le perfectionnisme. Même si le monde regorge de technologies permettant de résoudre des problèmes, il n’est pas nécessaire de tout savoir pour rendre les projets utiles aux gens. Utilisez des solutions toutes faites lorsque cela est possible. La valeur commerciale passe avant tout. Les utilisateurs ne viennent pas chercher un produit, ils viennent chercher une solution à leur problème. Évaluez les risques dès le départ et communiquez-les aux parties prenantes de manière claire. Faites des plans à court terme. Si la tâche est en attente depuis deux ans, il est fort probable que les utilisateurs n'en aient pas besoin. Recueillez des commentaires et des mesures de toutes les manières possibles. Les métriques sont un moyen fiable de trouver des points de croissance. Des solutions évolutives peuvent être obtenues même lorsque les « bons » modèles d’ingénierie ne sont pas utilisés au départ.
