Comment sortir de l'ornière du support et commencer à rembourser la dette technique!

J'ai un ami". Oui bon début je sais mais honnêtement ce n'est pas moi!

Fondamentalement, il travaille sur un projet réussi depuis environ 4 ans maintenant, la difficulté est que la dette technique a rattrapé et il trouve presque impossible d'arrêter de soutenir le produit (peaufiner ceci et cela) et de passer à un véritable développement.

J'ai fait diverses suggestions, enregistrez tout votre temps, créez des tickets, ne répondez pas aux e-mails, etc. Le problème avec cela est qu'il semble ne servir qu'à rappeler qu'il ne fait rien "d'utile".

La dette technique est en grande partie due au fait que dans un premier temps, c'était un gros avantage pour le produit, de prendre les demandes et les appels téléphoniques des utilisateurs et de les mettre en œuvre rapidement.

Ce que j'aimerais savoir, est-ce que quelqu'un a des suggestions sur la façon dont il pourrait sortir de cette ornière, dont une grande partie changerait les perceptions des utilisateurs afin qu'ils ne pensent pas pouvoir simplement sonner et attendre quelque chose être fait alors et là.

C'est très bien de dire mieux planifier, même si je comprends qu'il est très difficile de planifier le développement réel étant donné l'exigence de support et les pressions relatives des utilisateurs (voir ci-dessus).

L'organisation de votre ami a désespérément besoin de quelqu'un pour gérer le changement. Cette personne ou ce groupe prendrait les demandes de changement et les correctifs de bogues et les hiérarchiserait en fonction de l'impact commercial et de la quantité d'efforts requis. De cette façon, les tâches qui sont plus importantes pour l'organisation dans son ensemble seraient effectuées en premier, par opposition aux tâches qui sont plus importantes pour quiconque dérange votre ami en ce moment.

EDIT: Comme exemple de la façon dont cela fonctionnerait, la plupart des organisations ont une échelle de gravité. Le niveau de gravité le plus élevé est une application ou une fonction critique qui ne fonctionne pas. S'il y a quelque chose que l'entreprise peut faire pour contourner le problème, cela réduit la gravité au niveau suivant. Si l'application n'est pas critique pour l'entreprise, cela rend la gravité encore plus faible. Les demandes de nouvelles améliorations sont normalement hiérarchisées séparément.

Demandez à quelqu'un d'autre de prendre les appels et changez de ligne

Nous y reviendrons tout de suite.

à

Très bonne suggestion. Je vais créer une demande de fonctionnalité pour commencer à travailler dessus dès que possible. Si vous souhaitez suivre l'avancement de votre demande, vous pouvez le suivre ici: [lien vers le ticket de suivi de cas]. À l'avenir, vous pouvez également soumettre des demandes de contrats à terme de la même manière que je suis ici: [lien vers le tracker de cas]

C'est probablement la façon la plus simple et la plus efficace de le faire à mon avis. Le dernier bit essaie de réduire le stress de cette personne qui répond aux appels au fil du temps.

Le problème que vous voyez avec le système actuel de «priorité» est que lorsque tout est une priorité, rien n'est une priorité . Pour cela, votre ami a désespérément besoin de suivre les conseils de @Larry Coleman - des personnes distinctes du développement qui gèrent les demandes de changement. Idéalement, votre ami ne devrait même pas être au courant d'une demande de fonctionnalité, jusqu'à ce que ce groupe distinct ait convenu qu'elle devrait être priorisée pour le travail. Cela pourrait même être cette nouvelle personne qui répond aux appels maintenant qui les priorise - tant qu'ils comprennent l'entreprise et comprennent le développement.

J'ai moi-même vécu une situation similaire. Le produit a été construit sur des cordes de chaussures et a été le premier sur son marché au lancement. Il a d'abord été un succès (pour une entreprise en solo), mais je suppose que tout a fonctionné de 2003 à 2007. J'ai cherché à le doter mais j'ai appris à la dure que l'embauche d'un bon personnel est coûteuse et en aucun cas facile. Je suppose que votre ami est dans une situation similaire.

Dans mon cas, il est devenu clair très tôt que les choses allaient chuter à un moment donné. L'entreprise est toujours en croissance, mais la concurrence monte la tête, le marché semble vouloir se rétrécir, des signes précoces (mi-2006) indiquent un ralentissement économique, etc. Fondamentalement, un certain nombre de facteurs ont conduit moi de décider que le produit mourrait finalement; plus tard, mieux c'est (pour les clients et moi-même).

Rétrospectivement, j'ai probablement pris autant de bonnes décisions que de mauvaises, mais voici un bref aperçu:

1. Le personnel correctement et tôt. Obtenez du financement si vous en avez besoin. (Ne pas en chercher était ma plus grosse erreur.) Si vous avez des ventes, vous trouverez de l'argent.

2. Utilisez le contrôle de version / tests unitaires / tous les hoopla liés aux meilleures pratiques. Ils ont tous l'air idiot / ridicule / inintéressant lorsqu'ils sont enseignés à l'université, mais ils sont généralement les meilleures pratiques pour de bonnes raisons.

3. Embaucher au moins un gars des ventes / marketing, surtout si vous êtes axé sur la technologie. (Parce que si c'est le cas, vous aurez naturellement tendance à consacrer plus de temps aux questions technologiques qu'au marketing, même si vous avez un réseau d'affiliation).

4. Foule-source votre soutien. Créez un forum pour que les utilisateurs puissent s'aider eux-mêmes. Configurez un système de billetterie et invitez vos utilisateurs experts (généralement les utilisateurs fréquents du forum) à plonger dans une section spéciale en tant qu'assistants virtuels. Laissez-les s'occuper de la multitude de clients qui ont besoin de cette petite tâche pour quelques dollars, afin que vous puissiez vous concentrer sur une vue d'ensemble.

5. Maximisez vos efforts pour réduire la quantité de soutien que vous fournissez. Moins vous avez de soutien, plus vous aurez de temps pour faire des choses plus intéressantes. Au moment où le produit est factice, les clients seront reconnaissants, tout comme vos ventes et votre personnel d'assistance.

6. Demandez aux développeurs réels de faire une partie du support (une heure ou deux par jour, afin qu'ils ne perdent pas le contact avec la réalité) et donnez-leur la main libre pour suggérer toute réingénierie / modification du produit (interface utilisateur, fonctionnalité) s'ils identifier tout ce qui les fera passer moins de temps sur le support. L'idée est que, s'ils sont harcelés par les utilisateurs à maintes reprises pour les mêmes raisons, ils voudront corriger les choses dès que possible afin de pouvoir se débarrasser des appels de support. Et les plus intelligents le font, et c'est exactement ce que vous voulez.

7. Si vous pensez que le produit va mourir, décidez de le tuer ici et là et passez à l'étape suivante. Laissez-le mourir, vraiment. Une vache à lait est une vache à lait; quand il a atteint son but, envoyez-le au boucher. Faites-le doucement (pour les clients), mais ne laissez pas sa survie prolongée engloutir trop de votre temps si les frais généraux de maintenance sont tels que vos concurrents, avec l'avantage d'être des retardataires et d'avoir accumulé des dettes techniques , implémentera de nouvelles fonctionnalités plus rapidement que vous ne le pouvez de toute façon.

Une ligne à la fois. Prenez un peu plus de temps pour chaque correction, nettoyez les hacks et ajoutez des tests automatisés au fur et à mesure. Souvent, faire quelque chose de bien finit par être beaucoup plus rapide que d'ajouter un autre correctif. Si la direction pousse votre ami à travailler plus rapidement, comme la direction aime souvent le faire, il devrait développer une peau plus épaisse et passer en mode "quand c'est fait".

La clé est quel type de méthodologie de développement a-t-il autour de lui pour le protéger dans une certaine mesure? Par exemple, dans Scrum, il y a l'idée que le travail qui sera effectué ne change généralement pas pendant le sprint. Il existe donc des règles sur ce qui va être fait et ce qui ne peut pas être fait tout de suite. L'autre question est de savoir dans quelle mesure la direction soutient-elle son désir de ne pas être dans une ornière de soutien? Cela pourrait également être important car une gestion apathique peut être un peu le glas de la mort pour le projet de votre ami.

La meilleure chose à faire est d'arrêter le bus et de regarder en arrière. Votre ami devrait

• Faites un rapport de chaque problème dans le système et expliquez pourquoi il est mauvais. Les problèmes de conception doivent être mis en évidence et la quantité de refactorisation nécessaire.
• Des délais approximatifs doivent être donnés pour résoudre les problèmes
• Le rapport doit être remis à ses managers, puis aux acteurs du système
• Tous les développements de fonctionnalités doivent être interrompus pendant la période de fixation.

De nombreux projets le font. Si la direction ne peut pas être convaincue qu'il s'agit d'un cas perdu, mais si elle est d'accord, le système pourrait être remis en forme à long terme.