Coûts cachés et agilité réelle dans le processus de développement des produits

Le clan Wu-Tang avait raison

L'argent liquide domine tout ce qui m'entoure. Même les organisations les plus turquoises ne peuvent le nier. Le développement des projet Les méthodes de gestion, l'ajustement et l'optimisation des processus ou la motivation des employés sont fondamentalement déclenchés par le besoin universel d'argent. L'agilité en matière de conception comporte certains risques.

Nous voulons tous être minces et agile afin que le résultat de nos activités, mesuré en chiffres, soit le plus élevé possible. Même si nous concentrons l'essentiel de notre énergie sur la réduction des pertes, nous prenons en compte, au final, le bénéfice qui a augmenté grâce aux économies générées.

Ces économies tombent dans la même poche que les autres facteurs et ne sont accessibles qu'aux plus curieux. De cette manière, nous perdons de vue notre objectif et omettons involontairement un grand nombre de données précieuses et, en fin de compte, d'informations.

Les leçons tirées des échecs

Apprendre de ses propres erreurs est une compétence particulièrement utile (bien que coûteuse), mais les la culture organisationnelle et la diplomatie inhérente à cette capacité ne sont pas toujours d'un grand secours. Nous cachons souvent l'impact négatif des finances avec des mots "écran de fumée". Lorsqu'un investisseur s'écrie "J'ai perdu mon argent !", le gestionnaire le communique à l'ensemble de l'entreprise. équipe Nous sommes tous à la recherche de nouvelles solutions et d'améliorations - au lieu de regarder en arrière, nous cherchons constamment des moyens d'aller de l'avant.

En même temps, les pertes sont souvent la clé pour tirer les bonnes conclusions. Si nous reprenons certaines étapes du processus sans y avoir réfléchi, les solutions suivantes seront très probablement infectées par les mêmes erreurs.

Exemple : 

Une petite équipe de développeurs JS seniors ne fournit pas de fonctionnalités dans les délais prévus. L'investisseur, désireux d'accélérer le développement, ordonne l'embauche d'un nouveau programmeur. L'introduction d'une nouvelle personne dans le projet distraira l'équipe, ce qui ralentira encore l'avancement du projet.

Si l'investisseur comprenait mieux les raisons de l'inefficacité de l'équipe, il en conclurait qu'elle n'exploite son potentiel qu'en 60-70%. Un meilleur équipement et quelques jours de travail consacrés à l'automatisation du travail résoudraient le problème.

Malheureusement, il doit maintenant payer un autre développeur qui travaillera sur le même équipement et dont l'efficacité sera également de 60-70%.

Solution A :

• Équipe (2 x JS dev senior) : $20k / mois
• Nuage services : 200$ / mois
• Nouveau matériel pour les développeurs : $10k

À partir de maintenant, le projet coûte $20.200 / mois

Dépenses totales en 12 mois : 12 * 20 200 + 10 000 = $252 400

Solution B :

• Équipe (2 x JS dev senior) : $20k / mois
• Nouveau développeur (1 x développeur JS senior) : $10k / mois

A partir de maintenant, les coûts du projet : $30 000 / mois

Dépenses totales en 12 mois : 12 * 30 000 = $360 000

Deux développeurs travaillant à 100% font à peu près la même chose que trois développeurs travaillant à 60-70%. L'investisseur paiera plus de $ 100 000 euros de plus pour la même capacité de traitement par an en raison d'une décision de conception erronée !

Construire un produit parfait, c'est comme chasser le lapin

L'agilité dans le processus ne signifie pas nécessairement qu'il faille s'efforcer d'atteindre une couverture de test de 100% ou de battre le record de performance. Bien que ces mesures donnent un aperçu de l'état technique du projet, elles sont tellement insignifiantes du point de vue du client final qu'il n'est pas nécessaire de les amener à un état idéal dans le cadre d'un processus véritablement agile, car elles n'apportent rien de concret à l'entreprise. marché valeur.

Le développement de solutions techniques parfaites nécessite un engagement important de la part de l'équipe et une communication beaucoup plus poussée. En conséquence, les correctifs sont plus lents et le projet devient plus lourd en raison d'un développement excessif.

Le développement agile a pour but de fournir un code avec un minimum d'effort. Les tests de code sont sans aucun doute une bonne pratique et les tests en disent long sur le fonctionnement du code, mais ils ne doivent pas être effectués uniquement pour le plaisir de les faire et de s'en vanter. équipe de développement et le maximum limité par le budget.

En fin de compte, la perfection ne mène nulle part. Il est intéressant de noter que même la question de la sécurité est soumise à cette règle - théoriquement, tout système peut être piraté. Cependant, le minimum de développement mentionné ci-dessus doit être plus élevé et correspondre au poids, à l'échelle et au coût des conséquences potentielles des erreurs de code. Souvent, au lieu d'écrire le module de connexion à partir de zéro, ce qui comporte toujours un risque élevé d'erreur et d'introduction de failles de sécurité, il est préférable d'utiliser, par exemple, le bouton "Se connecter avec Google", dont l'implémentation correcte est relativement rapide et sûre.

Tant que l'objectif est de raccourcir les délais de mise sur le marché, des hypothèses trop ambitieuses s'avèrent contre-productives. Dans un processus apparemment parfait, l'enthousiasme excessif peut être un gaspillage de ressources.

Il est bon de tout savoir sur quelque chose et de savoir quelque chose sur tout

La conception centrée sur l'utilisateur est cool. La coopération centrée sur l'homme est plus importante. Lorsque l'équipe communique sur la même longueur d'onde, elle peut spontanément réduire les pertes potentielles.

Un UX designer qui est au fait des technologies frontales ne proposera pas de solution à l'étape de la conception. MVP qui prendront un temps déraisonnable au stade de la mise en œuvre.

Un développeur frontal qui connaît l'heuristique de l'utilisabilité sera en mesure d'adapter l'interface à une résolution d'écran donnée sans impliquer le concepteur UX - correction rapide, prévisualisation, acceptation.

Travailler sur une application nécessite de synchroniser les activités de personnes ayant des profils de compétences complètement différents. Vous devez connaître la répartition des compétences au sein de votre équipe pour apporter une valeur ajoutée à vos clients.

Une équipe engagée et synchronisée est un facteur clé d'économies. Ce type d'agilité nécessite un développement optimal des produits.

Il est extrêmement difficile d'obtenir de bonnes performances en équipe, surtout à l'ère de l'économie de marché. travail à distance. Les entreprises qui ont été "conviviales à distance" pendant des années ont un avantage significatif dans ce domaine par rapport à celles qui ont été forcées d'accorder l'organisation pendant le lockdown et qui apprennent tout juste à connaître les nouvelles méthodes et formes de communication.

Un équipement puissant avant de partir

Dans le contexte des besoins croissants de communication, des outils tels que Whimsical, Miro, Mural, Figma et Balsamiq enregistrent une augmentation impressionnante de leur popularité.

L'enfermement et la nécessité de travailler à distance ont certainement joué un rôle dans cette explosion du nombre d'utilisateurs. Je pense que le choix de l'outil doit correspondre aux préférences individuelles, mais jetons un coup d'œil à Miro :

La popularisation de ces outils entraîne naturellement une augmentation de la popularité des méthodologies elles-mêmes. Une personne qui a acheté Miro pour travailler sur les personas a accès à des dizaines d'autres modèles qui peuvent s'avérer intéressants et influencer positivement le travail quotidien de l'équipe.

Vous devez toujours vous équiper d'outils qui rationaliseront le flux d'informations dans le projet. L'ouverture à de nouveaux outils et méthodes est également l'un des fondements d'un projet efficace. développement de produits.

Vous pouvez (et devez) être paresseux

Les concepteurs expérimentés de l'interface et de l'architecture logicielle remarquent généralement plusieurs solutions potentielles qui devraient être vérifiées au début de la coopération et recherchent efficacement des inspirations appropriées ou même des solutions prêtes à l'emploi sur le marché. Un bon exemple est le cadre Material UI, qui est généralement une valeur sûre au stade du prototype.

Parfois, il suffit d'examiner quelques réalisations sur Behance ou Dribble et de s'en inspirer pour développer un mood board et le transmettre au développeur. Celui-ci s'en servira pour créer un prototype cliquable qui pourra être présenté aux premiers utilisateurs afin de recueillir leurs commentaires. Cette recherche organique d'un processus efficace par des personnes engagées et soucieuses de la conception est naturelle.

Si vous souhaitez fournir des produits numériques de manière efficace, vous devez laisser les gens faire leur travail. Vous savez quelle valeur/quel service vous voulez offrir à vos clients - cela suffit. Une équipe de projet compétente et bien gérée saura mieux que quiconque comment fournir cette valeur/ce service aussi rapidement que possible, avec le rapport coût-efficacité nécessaire.

Montrez votre confiance, partagez les responsabilités et ouvrez-vous à une véritable communication à double sens afin que votre produit sera meilleure et vous n'aurez plus à supporter le fardeau de tout faire tout seul, ce qui s'avère souvent être un parcours épuisant pour les fondateurs et les entrepreneurs ! Au The CodestNous appliquons ce principe non seulement dans les projets, mais aussi dans les processus internes - c'est probablement la raison pour laquelle nous bénéficions d'un taux élevé de fidélisation des clients et des employés (histoire vraie, les deux> 90%).

Faites preuve d'un peu de paresse, transférez audacieusement les responsabilités et abandonnez tout travail redondant qui n'est pas nécessaire pour aller de l'avant - les fonctionnalités qu'il serait "agréable d'avoir" peuvent toujours attendre.

Se concentrer sur la recherche des bonnes réponses

Le processus de création d'un produit numérique est une collision constante entre différentes perspectives, expériences et sources d'information - chacune de ces collisions comporte le risque de prendre une mauvaise décision en matière de conception.

Une bonne communication interne réduit ce risque, mais ce n'est qu'un côté de la médaille. La question de savoir comment rester en contact avec le marché reste encore sans réponse.

Business Intelligence, Customer Support, UX research departments et bien d'autres encore - tout comme le équipe de développementIls doivent s'efforcer d'obtenir le minimum nécessaire pour fournir des réponses spécifiques aux questions posées par le propriétaire du produit ou l'équipe UX.

La marque elle-même et la stratégie de communication de la marque sont également importantes. Elles permettent d'établir une relation qualitative avec les clients, qui se traduit ensuite par leur engagement. Si vous souhaitez poser des questions à vos clients, vous devez vous assurer qu'ils sont prêts à y répondre. Le ton de votre voix est important.

Il est certain qu'être en contact permanent avec le marché permet de définir les bonnes trajectoires du projet pour le faire décoller. Ce qui est moins évident, c'est que la nécessité de ce contact doit être envisagée dès le début du projet, autour de l'anticipation des bonnes compétences dans l'équipe (pour poser les bonnes questions et y répondre) et de la construction d'une stratégie produit qui impliquera les groupes cibles.

Conclusions

Compte tenu de toutes les questions susmentionnées, nous pouvons observer plusieurs problèmes qui apparaissent régulièrement dans le processus de conception :

- être trop axé sur le profit et éviter d'examiner les échecs,

- l'inexactitude et ne pas radiographier ses propres erreurs,

- la poursuite d'un produit parfait que vous avez en tête, mais qui n'est pas ce dont le marché a besoin,

- une mise en œuvre trop zélée des processus liés aux manuels - développement et conception excessifs,

- la rigidité du travail en équipe et le fait de forcer les employés à rester uniquement dans leur domaine de spécialisation,

- une communication inefficace,

- tendance à réinventer la roue.

L'optimisation des processus à l'échelle macro comprend la somme des économies. Pour relever correctement les défis susmentionnés, vous devez impliquer vos collègues afin qu'ils présentent ouvertement des idées pour améliorer le processus.

Il suffit parfois de parler moins et d'écouter plus attentivement ses subordonnés, ses clients, ses partenaires - en fonction du rôle et de la responsabilité de chacun - pour réussir.

Si vous n'en avez pas assez, c'est que vous surinvestissez.. Avez-vous trop d'argent ?

Taisez-vous et prenez votre argent ! Oh, et en plus :

1. N'introduisez pas Scrum uniquement pour pratiquer Scrum.
2. Accorder plus d'attention aux lacunes dans le processus.
3. Fixez des objectifs plus modestes, réalisables et mesurables à court terme - en général, contentez-vous du minimum.
4. Parfois, un bon feuille de route suffit à donner à l'équipe le sentiment d'un objectif commun et à l'engager dans un travail efficace ici et maintenant.
5. Constituez une bonne équipe pour pouvoir lui donner la liberté dont elle a besoin.
6. Remettez toujours en question l'ensemble des outils actuels - recherchez des améliorations possibles dans votre atelier.
7. Concevez le processus du point de vue de la personne paresseuse - comme si vous vouliez en faire le moins possible.

En savoir plus :

Défis CTO - mise à l'échelle et croissance des produits logiciels

Quelle base de données choisir pour un type de données spécifique dans votre projet logiciel ?