Comment mettre fin à un projet logiciel
Qu’il s’agisse de fermer un projet interne ou de fermer une plate-forme publique, il existe plusieurs façons de mettre fin à un logiciel. Alors que démarrer un projet logiciel pour la première fois est clairement la chose sexy à faire, bien terminer les choses montre un degré supplémentaire de maturité dans votre approche du développement. Dans cet article, j’examinerai les domaines à prendre en compte lorsque vous disposez d’un minimum de temps et d’espace pour réagir ; il peut s’agir de vos responsabilités directes, mais plus probablement de votre ressort.
Ce restaurant où vous êtes allé – il est toujours là mais a maintenant un autre propriétaire. Vous avez remarqué que le menu est resté le même, mais la qualité a semblé baisser. Certains invités semblent un peu extrêmes. La structure des prix a changé. Le propriétaire ne semblait pas s’en soucier mais a promis que l’établissement aurait une cure de jouvence complète. Il a changé son nom en une seule lettre et a placé un signe voyant au-dessus de la porte. Quand vous regardez en arrière, vous vous rendez compte que quelque chose s’est terminé, mais personne ne l’a admis.
Je ne parle bien sûr pas d’un restaurant mais d’une certaine plateforme de médias sociaux. Mettre fin à un projet de manière inappropriée parce que vous voulez garder les utilisateurs, ou simplement parce que vous ne savez pas quoi dire, est insensé. Le lien perdu avec les clients en ruinant vos propres produits ou services fait l’objet de nombreux reportages en ce moment. Un point intéressant soulevé par Andy Piper, une sommité de longue date des relations avec les développeurs sur Twitter, est qu’une fin aurait déjà dû se produire plus tôt.
C’est une grave erreur de penser que montrer de l’intérêt à mettre fin aux choses avant qu’elles ne se terminent fait de vous une sorte de perdant. Les gens se souviennent des chutes, mais ils se souviennent beaucoup plus longtemps des comportements intempérants avec échec. Et cela inclut les personnes qui pourraient autrement travailler avec vous.
Voir la fin, avant que la fin ne vous voie
Même dans les concerts les plus confortables, essayez de conserver le code du samouraï (ou du bushido) ; soyez toujours prêt à mourir.
Le vrai sens est qu’en ayant une conscience constante de la mort, les gens peuvent atteindre un état de liberté qui transcende la vie et la mort.
Une différence entre une start-up enthousiaste et une organisation guindée est que la première ne voit ni n’envisage jamais de fin. Et pourtant, ce n’est pas ainsi que fonctionne l’univers. Comment combattez-vous cela personnellement ? En pratique, cela signifie en tant que développeur être conscient des décisions et des actions qui n’ont de sens que Si rien de mal n’arrive. Ne niez pas les risques par peur, mais imaginez comment les jetons tomberont si les choses tournent mal. Cet accord qui dure plus longtemps que votre projet n’a même existé, est-ce raisonnable ? À quel point devenons-nous étendus ? Combien de temps faut-il pour annuler une action ? Quelles sont les hypothèses faites sur les nombres d’utilisateurs attendus ? Pourquoi dépendons-nous des services d’une entreprise alors que nous ne savons même pas comment elle est financée ? Cette nouvelle direction comprend-elle vraiment ce que nous faisons ? Ce n’est pas du pessimisme inutile, il s’agit simplement d’accepter que le cycle de vie complet d’un projet peut avoir un calendrier plus court que ce qui avait été initialement imaginé.
Une bonne fin
Certains projets se sont terminés de très bonne grâce. Thisismyjam.com a un joli site commémoratif, presque aussi bon dans la mort que dans la vie. Bien que ce type d’acte de préservation relève davantage de la dévotion que d’une bonne pratique commerciale, il aurait fière allure sur un CV. L’autre extrême est Google, qui a tellement de projets morts qu’il a son propre cimetière de logiciels. Mais au moins, cela définit les attentes; vous échouez rapidement et passez à autre chose. Votre objectif devrait simplement être de faire preuve de pragmatisme avec un peu d’empathie quand une fin arrive.
Le pourquoi n’a pas trop d’importance
La raison réelle de la fermeture peut simplement être due au succès, aux dépenses ou à une autre restriction de ressources. Ou il se peut que l’entreprise derrière le produit ait changé de direction. Ou l’installation sera couverte ailleurs. Mais la véritable raison de la fermeture peut ne pas être révélée au personnel ou aux clients de toute façon. En fait, il peut rester caché pendant des années. Ce n’est pas quelque chose dont il faut s’inquiéter – même dans votre propre vie, vous avez probablement été un peu économe avec la vérité en expliquant pourquoi vous avez arrêté de faire quelque chose. Les organisations ont une valeur d’action et des concurrents auxquels il faut penser, donc une fiction raisonnable vaut généralement mieux qu’une incertitude prolongée. Dans tous les cas, vos responsabilités en tant que développeur restent en grande partie les mêmes.
Aller, aller, parti
Presque par définition, il n’y aura pas de « fin » définie. Comme le dernier le Seigneur des Anneaux film, il y aura plusieurs fins. Il y a généralement un gris période pendant laquelle les choses se décident, mais personne ne s’engage à quoi que ce soit. (Je sais que certaines organisations fonctionnent comme ça en permanence.) Ainsi, chaque fois que vous planifiez, vous devez mettre en garde chaque point, que vous vouliez dire le côté gauche de « fin » avant que les choses ne puissent être inversées, ou le côté droit de « fin » quand vous avez pointé vos cieux vers le bas de la falaise et sauté.
Communiquer les intentions aux utilisateurs lors de la temporisation La période où une fin est officielle est difficile parce que vous ne pouvez pas vous empêcher de les traiter comme une meute de gazelles effrayées qui s’enfuiront au premier signe d’ennui. Pourtant, la plupart des utilisateurs ont déjà été piqués par la disparition de services, alors, dans la mesure du possible, tenez-vous-en à dire ce que vous savez. Essayez d’offrir aux utilisateurs un moyen de s’échapper et de récupérer ce dont ils ont besoin. Vous devez exprimer les choses avec force, sinon les utilisateurs espèrent par défaut pouvoir continuer comme avant. Ironiquement, si les gens sont habitués à un bon service, ils auront plus de mal à comprendre ce qui se passe.
Qu’en est-il des données
Parfois, vous pouvez simplement «rendre» les données en termes de rapports clients, mais généralement, quelque chose sera perdu. Un réseau social peut rendre une liste de vos tweets, mais nous savons tous que c’est le réseau qui a une vraie valeur. Dans presque tous les cas, les données détenues doivent être éliminées en toute sécurité, sinon elles deviendront non gérées. Pendant la période de temporisation, essayez d’offrir aux utilisateurs autant d’options d’évasion que vous pouvez raisonnablement prendre en charge. Il peut s’agir simplement d’une exportation d’un fichier de données séparées par des virgules ou d’une intégration complète à un autre service. Un bel article de blog complet peut au moins informer les utilisateurs que vous avez pensé à eux. Notez que les services qui ne verrouillent pas les utilisateurs ont ici un avantage naturel.
Une liste d’actions finales
La première fois qu’un projet se termine de manière inattendue, vous ne serez pas prêt, mais la prochaine fois, vous le serez peut-être. Donc, cette liste ou toute autre liste de points n’est pas destinée à être déployée sur demande ; considérez-les à tout moment et reconnaissez quand ils se produisent ailleurs.
- Travaillez au sein de votre équipe projet si les employés seront directement transférés vers un autre projet, ou si la clôture d’un projet implique que l’équipe sera dissoute. Il peut également y avoir une petite équipe de transition pour gérer les changements. L’astuce ici est de réduire le degré d’incertitude.
- Mettre à jour les parties prenantes et convenir d’un plan de continuation. Cela peut se résumer à fournir un ensemble de réponses fixes à certaines requêtes ou à s’assurer que toute transition suggérée sera prise en charge. Au minimum, il s’agit d’un e-mail adressé à un petit groupe de personnes concernant les décisions et les actions ci-dessous.
- Communication publique. Choisissez un message et respectez-le. La postérité enregistrera la « fin » comme coïncidant avec cette première communication publique. C’est à ce moment que vous relayez ces plans de continuation aux utilisateurs. Il est judicieux d’écouter attentivement les commentaires et d’apporter de petites modifications en fonction de la réaction des utilisateurs à l’annonce de la disparition. Mais tout ce domaine est un sujet bien traité en soi.
- Transférer, archiver ou détruire. Les actifs logiciels du projet doivent être traités de manière systématique. Cela commence simplement par tout éteindre et répondre aux conséquences. Certains actifs doivent être transférés et d’autres supprimés. N’ouvrez pas votre code à moins que vous n’ayez déjà une communauté prête et disposée à le maintenir. Sinon, ce n’est pas plus utile que les pourboires dans GitHub et n’aidera finalement aucun utilisateur bloqué.
- Effectuer des tâches administratives. Il y aura des relations AWS à réduire, des domaines ou d’autres accords externes à fermer, etc. Il y aura de courts e-mails désagréables à envoyer. Et vous savez comment Wikipédia met à jour les choses ? Cela pourrait être vous qui faites cela si votre projet est si bien exposé.
- Tenez cette réunion post-mortem du projet. Même s’il se tient de manière informelle des années plus tard, leçons apprises doit être formellement enregistré. Si vous le pouvez, essayez de le faire plus tôt afin que l’organisation englobante ait une certaine mémoire des événements et ne se contente pas de suivre le même chemin. De nos jours, vous pouvez vivre la fin plusieurs fois dans une variété de podcasts et de vidéos YouTube.
Et sur la prochaine chose
C’est la partie où je dis qu’après une fin, il y a un nouveau commencement. Je ne sais pas combien d’intervieweurs prennent note de la façon dont leurs candidats ont terminé les projets – mais ils devraient le faire. Même si vous êtes personnellement touché, essayez de faire ce qu’il faut avec votre métier. C’est, après tout, ce qui dure.
