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

13

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).

MrEdmundo
la source
2
Si je comprends bien votre question, votre ami est trop occupé à gérer les demandes d'assistance / de modification des utilisateurs pour ranger le code. Y a-t-il des nouvelles fonctionnalités que les utilisateurs demandent qui sont bloquées en conséquence?
Larry Coleman
@larry coleman, oh ouais c'est un cercle visqueux, les nouvelles demandes sont retardées ce qui est aussi déprimant que le soutien constant.
MrEdmundo

Réponses:

13

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.

Larry Coleman
la source
Compris, en quoi cela aide-t-il avec les tâches quotidiennes qui doivent en principe être effectuées et semble-t-il ralentir toute hiérarchisation qui est mise en place.
MrEdmundo
2
Je suppose que d'après votre question, il n'y a pas une seule personne ou un seul groupe responsable de l'établissement des priorités qui ait suffisamment d'autorité pour les faire respecter. C'est un gros problème. J'irais même jusqu'à suggérer que votre ami cherche un nouvel emploi s'il ne peut pas être résolu.
Larry Coleman
hmmmm, je vois votre point, mais encore une fois, je ne sais pas comment cela contribue à changer la perception des entreprises étant donné que la plupart des tâches qu'il travaille sont considérées comme une priorité. Comment changez-vous l'idée qu'une demande de personne a toujours été une priorité absolue mais n'est plus sans faire pipi de cette personne. Peut-être que la réponse, il a besoin de plus de personnel.
MrEdmundo
2
La seule façon dont cela fonctionne est si une personne de rang de l'entreprise établit les priorités. Si le chef de l'unité commerciale définit les priorités, par exemple, le reste de l'entreprise l'acceptera s'il apprécie son travail. Ils peuvent ne pas l'aimer, mais ce ne sera pas le problème de votre ami.
Larry Coleman
10

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.

Steven Evers
la source
3
+1 pour "quand tout est une priorité, rien n'est une priorité"
Larry Coleman
2

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.

Denis de Bernardy
la source
1

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".

tdammers
la source
0

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.

JB King
la source
0

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.

Tjaart
la source
Cela semble bon en théorie, mais si l'application est essentielle à la mission, le gel des fonctionnalités peut ne pas être une option.
tdammers
Ensuite, il peut être temps de créer une branche et d'ajouter un autre développeur pour effectuer la maintenance.
Tjaart