Expédiez des unités logicielles plus petites et limitez la taille de vos branches hôtes locales

Au cours de la dernière décennie à la tête de HackerNoon , j'ai travaillé avec de nombreux développeurs de logiciels talentueux, et au début de leur mandat, je finis généralement par dire la même chose : expédier des unités de logiciels plus petites et limiter la taille de vos succursales hôtes locales. Pourquoi? Voici les deux raisons principales et une grande histoire, mais :

1. Les utilisateurs tirent davantage d'avantages de votre travail et donnent leur avis sur celui-ci pendant que vous continuez à travailler pour mener à bien le projet.

Si vous avez un projet qui représente 6 mois de travail et qui n'est pas mis en ligne avant 6 mois, cela représente 5 mois et 30 jours pendant lesquels les utilisateurs ne récoltent aucun bénéfice de votre travail. Ce n'est que lorsqu'il est en ligne que le reste d'Internet peut avoir une chance de bénéficier de ce que vous expédiez. Et même alors, c’est justement à ce moment-là que commence la bataille difficile pour l’adoption. Si vous deviez plutôt expédier une partie du projet chaque semaine, les utilisateurs commenceraient à gagner de la valeur tout au long du cycle de vie du projet.

Dane Lyons , mon ancien collègue, m'a dit un jour : « nous devrions continuer à ajouter des unités de valeur atomique et faire autant de versions que nécessaire. Nous pourrions facilement avoir 10 versions sur [fonctionnalité] avant d'en être satisfaits et prêts à passer à autre chose.

En tant que PDG, je juge souvent les nouvelles recrues en fonction du temps qu'il leur faut pour devenir des contributeurs rentables. Dans les ventes, c'est plus simple, leurs ventes ont-elles dépassé leur rémunération ? Il y a bien sûr d'autres éléments à prendre en compte, comme les coûts marginaux de marketing, d'infrastructure, etc., mais quelle que soit la manière dont on les découpe, il est plus difficile de mesurer l'impact d'un développeur de logiciels sur les résultats financiers qu'un vendeur. Si vous vous lancez dans un nouveau rôle en tant que développeur de logiciels, je vous recommande d'essayer avec succès d'enchaîner les célibataires avant de vous lancer dans des circuits.

Dans le jeu du développement logiciel, il n’existe pas de règles universelles concernant le score. Bien sûr, certaines personnes attribuent des systèmes de points et d'autres définissent des KPI, mais en fin de compte, ce sont les personnes qui utilisent votre produit qui déterminent si et comment vous créez de la valeur ou non. En expédiant plus tôt, vous recevez des commentaires plus tôt. Les personnes utilisant votre logiciel expliqueront plus clairement comment construire et non la prochaine unité atomique du projet.

2. Plus votre branche s'écarte de la réalité de la production, plus il est difficile pour les coéquipiers de contribuer à votre projet et de faire avancer les projets adjacents.

Les externalités liées à la non-livraison de la version la plus récente peuvent être plus difficiles à percevoir au début. Tout est connecté. Dans un produit comme HackerNoon par exemple, la page de profil et la page d'histoire n'existent pas dans le vide ; ils existent sous forme de pages connectées au sein d'un même produit. Si des changements surviennent dans le fonctionnement d’une page, cela affecte le fonctionnement de toutes les pages qui y sont connectées.

Si votre branche locale est très grande, les autres changements qui se produisent sur les pages ou les fonctions qui y sont connectées ne fonctionneront souvent pas une fois que votre branche obèse sera finalement mise en production. Cela casse les choses. Cela crée des bugs. Cela oblige à refaire le travail. Cela crée une envie chez vos coéquipiers de ne pas vouloir travailler avec vous. Cela pourrait même créer une expérience produit pire que celle que vous aviez déjà vécue, avant tout le travail que vous avez consacré à votre succursale locale.

En apportant de petits changements plus régulièrement, vous donnez aux autres les moyens de contribuer. Ils pensent que ce qu’ils expédient fonctionnera également parce que vous êtes déjà tous les deux d’accord sur la base de production. L'incrémental est votre meilleur ami. Cela vous connecte à la réalité. Si les changements progressifs affectent négativement le produit, qu’est-ce qui vous fait penser que des changements plus importants dans la même direction affecteront positivement l’expérience produit ?

Et le grand mais c'est : n'ayez pas peur des projets audacieux qui peuvent devenir des branches trop grandes parce que vous êtes un mauvais mofo capable de faire une différence dans la façon dont cette putain de chose fonctionne pour les gens.

Certains projets doivent simplement être de grandes succursales. Par exemple, les éléments comportant des dépendances massives, comme les nouvelles bases de données, peuvent être tellement ancrés dans l'utilisation existante qu'il est préférable de revenir en arrière et d'aborder le projet comme une version annuelle 2.0 sur site. Et d'autres technologies révolutionnaires, comme ChatGPT, ont mis si longtemps à être développées qu'il ne serait tout simplement pas logique d'adopter une version UX non entraînée, incomplète et merdique de la nouvelle technologie. Faites de grands sauts. Quand tu as la piste. Quand vous avez l’équipe à bord. Mais ne vous faites pas de grandeur. La plupart du temps, le développement de logiciels ne réinvente pas la roue. Il s'agit simplement d'expédier la prochaine unité atomique.