Comment les «éditeurs de logiciels personnalisés» gèrent-ils la dette technique?

Que sont les «sociétés de logiciels personnalisés»?

Par "éditeurs de logiciels personnalisés", j'entends les entreprises qui gagnent leur argent principalement en créant des logiciels personnalisés et uniques. Par exemple, des agences ou des entreprises intermédiaires, ou des entrepreneurs / consultants comme Redify .

Quel est le contraire des «éditeurs de logiciels personnalisés»?

À l'opposé du modèle commercial ci-dessus, les entreprises se concentrent sur les produits à long terme, qu'il s'agisse d'applications de bureau / mobiles déployables ou de logiciels SaaS.

Un moyen sûr de se constituer une dette technique:

Je travaille pour une entreprise qui tente de se concentrer sur une suite de produits SaaS. Cependant, en raison de certaines contraintes, nous finissons parfois par plier à la volonté de certains clients et nous finissons par créer des morceaux de logiciels personnalisés qui ne peuvent être utilisés que pour ce client.

C'est un moyen sûr d'engager une dette technique. Nous avons maintenant un logiciel à entretenir qui n'ajoute rien à notre produit principal.

Si le travail personnalisé est un moyen sûr de constituer une dette technique, comment les agences le gèrent-elles?

Donc, cela m'a fait réfléchir. Les entreprises qui n'ont pas un produit de base au centre de leur modèle commercial, eh bien, elles font toujours un travail logiciel personnalisé. Comment gèrent-ils la notion de dette technique? Comment cela ne les conduit-il pas à la faillite technique ?

Si vous pouvez plier les exigences spécifiques à l'utilisateur en quelque chose qui sera utile pour tout le monde, tant mieux. Si le client est prêt à payer les frais de support continus pour la fonctionnalité, c'est super aussi. Mais si vous êtes une petite équipe et que vous avez du mal à prendre en charge toutes vos fonctionnalités, il n'y a rien d'autre à faire que de prendre des décisions difficiles sur les fonctionnalités dont vous avez le moins besoin, puis consacrez un peu de temps à les éliminer de votre base de code.

Le SaaS vous met en bonne position pour collecter des statistiques d'utilisation. Vous devriez envisager d'outiller vos fonctionnalités si vous ne l'avez pas déjà fait afin de pouvoir garder une trace de qui utilise quoi. D'après notre expérience, les clients les plus idiomatiques sont généralement aussi les plus dysfonctionnels; ce gars qui a tapé du pied et a retenu son souffle jusqu'à ce que vous lui donniez un bouton d'exportation vers MS-Access ne l'ait probablement pas utilisé depuis plus d'un an. Certaines fonctionnalités sont maintenues en vie même si un seul client les utilise, car ce client est bruyant et menace d'emmener son entreprise ailleurs chaque fois que quelque chose n'est pas à sa satisfaction. L'arrêt de la fonctionnalité peut vous coûter un client maintenant, mais le temps consacré à la prise en charge de cette fonctionnalité peut vous coûter des dizaines de clients au fil des ans. C'est une mesure de la qualité de votre équipe de direction,

Lorsque vous interrompez une fonctionnalité, assurez-vous d'annoncer la décision à vos clients (ou au moins à ceux concernés) bien à l'avance, n'importe où entre six mois et trois ans est raisonnable. En fait, si vous acceptez de créer des fonctionnalités spécifiques à l'utilisateur, vous pouvez essayer de faire en sorte que votre personnel de vente établisse une date d'expiration dès le début. Appelez cela la "durée de vie du support" et indiquez clairement que plus ils le souhaitent, plus cela coûtera cher. Essayez de fournir des solutions de contournement à vos clients afin qu'ils ne soient pas laissés pour compte quand une fonctionnalité disparaît, par exemple un script qui convertit vos fichiers XML exportés au format MS-access, ou un petit conseil sur le choix d'un meilleur SGBDR.

Quelque chose qui a fonctionné pour nous en tant que mesure préventive est d'obtenir un rapport de notre équipe commerciale envoyé à notre équipe de développement et à la direction sur une base mensuelle. Ce rapport couvre les commentaires des clients - quelles fonctionnalités sont les plus populaires, quelles fonctionnalités sont les plus demandées, quelles fonctionnalités proposées génèrent le plus de buzz. C'est intéressant si vous êtes développeur, mais le véritable avantage est pour l'équipe de vente, qui réfléchit maintenant un peu plus à chaque fonctionnalité dans le contexte d'une image plus large, au lieu d'envoyer un flux infini de demandes de fonctionnalités et de hiérarchiser les priorités sur quel client était le plus fort. L'effet a été de rendre nos vendeurs plus intransigeants lorsqu'il s'agit de demandes de nouvelles fonctionnalités dans une négociation, car ils sont plus conscients de la place de chaque fonctionnalité dans la proposition de valeur globale de notre produit.

Avoir du code modulaire avec de nombreux tests automatisés vous aidera lorsque vous piraterez des fonctionnalités dans votre produit et les piratera à nouveau, mais finalement ce n'est pas une question de programmation mais une question de gestion. Écrire du code pour faire une vente est un jeu de dupes.

Lorsque je suis confronté à des demandes de développement personnalisées, je les filtre à travers le filtre cool qui divise les demandes en 3 piles:

1. des choses géniales qui seront utiles à tout le monde et qui sont relativement faciles à mettre en œuvre
2. des choses géniales qui seront utiles à tout le monde et difficiles à mettre en œuvre
3. une des choses stupides qui ne sont nécessaires que pour ce client qui n'en a pas vraiment besoin de toute façon

• La catégorie 1 est implémentée dans le cycle de développement actuel.
• La catégorie 2 est implémentée dans le prochain cycle de développement.
• La catégorie 3 obtient un devis d'un mois-homme de temps de développement, après quoi la plupart des clients se rendent compte que leur demande n'en vaut pas la peine.

Honnêtement, cela n'a jamais échoué et je ne pense pas que nous ayons fini par implémenter les fonctionnalités de catégorie 3. Et bien sûr, aucun des clients n'a marché (les ventes ne m'auraient pas permis de retirer cela autrement :)

(cette expérience était dans une entreprise ISV)

en raison de certaines contraintes, nous finissons parfois par plier à la volonté de certains clients et nous finissons par créer des morceaux de logiciels personnalisés qui ne peuvent être utilisés que pour ce client.

Votre problème n'est pas que vous créez du code utilisé pour un seul client. Le problème est que vous incorporez du code utilisé uniquement pour un client dans un produit que vous vendez à de nombreux autres clients qui n'ont pas besoin de cette fonctionnalité.

Les entreprises qui n'ont pas un produit de base au centre de leur modèle commercial, eh bien, elles font toujours un travail logiciel personnalisé. Comment gèrent-ils la notion de dette technique? Comment cela ne les conduit-il pas à la faillite technique?

Ils livrent le produit. Et puis ils avancent. Lorsque vous développez un produit sous contrat, tout ce que vous faites sur ce projet est pour ce seul client. Toute dette technique qui peut s'être accumulée pendant le développement devient le problème du client après la fin du contrat et le développeur passe à un autre projet pour un autre client.

Cela ne veut pas dire que c'est bien de faire un boulot de merde, bien sûr. Votre objectif numéro un est de donner envie à votre client de continuer à travailler avec vous, et faire un travail de qualité est le moyen d'y arriver. Cela ne signifie pas non plus que la dette technique n'est pas un problème pour les développeurs de contrats. Même si vous écrivez régulièrement du code propre vous-même, il est probable que vous serez embauché à un moment donné pour travailler sur un projet qui a déjà accumulé un tas de dettes. Cela peut être bon (le client veut vous payer pour nettoyer le gâchis) ou non (le client n'a aucune idée de la gravité du code et ne comprend pas pourquoi «juste» l'ajout de quelques fonctionnalités supplémentaires va prendre si longtemps ).

Je ne suis pas d'accord avec l'hypothèse selon laquelle le travail personnalisé est garanti pour générer une dette technique. Éviter la dette technique ne signifie pas éviter certains types de fonctionnalités - cela signifie éviter une rigidité inutile, des problèmes de dépendance et des choses qui rendent une base de code difficile (c'est-à-dire coûteuse) à changer. La fonctionnalité personnalisée n'implique rien de tout cela - cela implique simplement une base étroite pour la fonctionnalité. Donc, la clé est de tenir compte de la mise en œuvre autant de logique réutilisable que possible, en laissant les éléments personnalisés uniques comme son propre module autonome qui peut être déployé pour le client demandeur.

Par exemple, supposons que vous disposiez d'un livrable qui était une application Web interne que vos clients installeraient sur un intranet. Un jour, un client arrive et propose de conduire un camion-benne plein d'argent jusqu'à votre entreprise si vous lui faites une version qui a une application de bureau "client riche" au lieu d'une interface de navigateur. Eh bien, si votre système est bien architecturé et vos dépendances bien gérées, il s'agit simplement de réutiliser le domaine, l'accès aux données et les composants de service tout en créant un nouveau composant de présentation. La dette technique n'est pas une considération, même si vous n'avez qu'un seul client qui souhaite revenir en 1999 et avoir une application de bureau pour cela.

Il s'agit d'une question quelque peu complexe à répondre car, comme beaucoup de choses, cela dépend vraiment des circonstances du projet, du niveau de contrôle de l'entreprise sous-traitée, de la gestion du logiciel personnalisé par l'entreprise sous-traitée pendant tout son cycle de vie, du montant "d'interférence" par d'autres personnes avec l'accès à la base de code, l'attitude de toutes les personnes impliquées, la complexité du projet et les méthodologies utilisées ... Je pourrais vraiment continuer.

Tous les systèmes ont une certaine dette technique. Dans certains cas, cela peut ne pas être particulièrement visible en raison des efforts diligents des développeurs qui s'efforcent de toujours maintenir une base de code propre, mais aucun système n'est parfait et une refonte majeure peut faire apparaître un problème apparemment innocent mais de longue date. Alors, comment les entreprises sous contrat gèrent-elles cela?

Dans de nombreux cas, ce n'est pas le cas. Souvent, les logiciels seront écrits par une entreprise, puis modifiés par une autre, et il n'est pas rare de voir la base de code vraiment gâchée car chaque entreprise sous contrat travaille dans un délai serré et ne justifiera pas le temps de garder le code propre ( et parfois à peine testés) si cela signifie qu’ils risquent de manquer un délai.

Dans d'autres cas, vous trouvez des entreprises qui non seulement gèrent bien leur projet sous-traité, mais trouvent également en quelque sorte le temps de laisser la base de code existante dans un meilleur état qu'elles ne l'ont trouvé. Ils le font souvent avec une planification minutieuse, en identifiant les sources de dette technique - généralement celles qui auront le plus d'impact sur les nouveaux travaux - et ils élaborent des stratégies pour fournir des cas de test et des modifications qui contribuent à gérer la dette technique et intégrer tout cela dans le calendrier de leur projet .

Le fait d'être un logiciel personnalisé garantit-il une dette technique au lieu d'écrire un produit central? La réponse courte est non, mais il est probable que la dette technique s'accumulera si elle n'est pas activement traitée. C'est la même chose que pour tout autre projet logiciel. Si vous contrôlez entièrement le projet tout au long de son cycle de vie, vous avez une meilleure opportunité de faire face à la dette technique. Sinon, vous devrez faire face à la dette technique qui aurait pu résulter du code que la société précédente a laissé.

D'un autre côté, si votre question était de savoir si l'écriture de logiciels quel que soit votre modèle d'entreprise est une garantie de dette technique. La réponse serait absolument. La vraie question est de savoir comment une entreprise gère la dette technique. Le laisser s'accumuler et le traiter à une heure programmée, ou gérer une base de code propre de manière continue afin de rembourser la dette technique dès que possible? Cette réponse se résume aux priorités individuelles d'une entreprise et à la pertinence financière de la dette technique contractée.

Un logiciel personnalisé n'est pas une garantie de dette technique, mais au service de deux maîtres l'est.

Une société de logiciels personnalisés construira un logiciel parfaitement adapté à la tâche à accomplir, le livrera et le maintiendra si nécessaire. Les logiciels vraiment personnalisés n'ont souvent pas besoin de nouvelles fonctionnalités ajoutées très souvent.

Le problème décrit dans cette question est lorsque les sociétés de produits créent des fonctionnalités personnalisées dans un produit par ailleurs générique. Si le produit était entièrement personnalisé, il ne bougerait que lorsque les exigences d'un client changeraient. Si le produit était entièrement générique, il ne bougerait que lorsque de nouvelles fonctionnalités seraient ajoutées pour le rendre plus attrayant. Mais lorsque vous avez une fonctionnalité personnalisée dans un produit par ailleurs générique, vous avez deux morceaux de code, en contact étroit, qui se déplacent à des vitesses différentes. Comme les plaques tectoniques qui provoquent des tremblements de terre, l'interface entre ces morceaux de code est un «point chaud», mûr pour des problèmes.