Les ingénieurs logiciels devraient-ils également agir en tant que support technique?
Un ingénieur logiciel doit-il également agir en tant que support technique? Autrement dit, si une entreprise autorise ses ingénieurs à porter à la fois les chapeaux d'ingénieur logiciel et de support technique. Il semble que cela supprimerait la possibilité d'écrire des logiciels si une grande partie du temps d'un ingénieur était occupée par le support technique.
Il s'agit d'un problème classique dans les entreprises qui ont un composant de développement logiciel dans leur travail, qu'elles soient ou non des éditeurs de logiciels. Je lutte avec ça tout le temps.
Faire participer les développeurs au support de production
Avantages
- Combat le syndrome du "développement dans le vide". Il est important de découvrir comment les utilisateurs utilisent l'application. Jusqu'à ce que je voie enfin cela en tant que jeune développeur, je ne savais pas à quel point j'étais mauvais développeur d'interface utilisateur. Tout ce qui m'intéressait, c'était le codage et non la conception, l'analyse ou le point de vue de l'utilisateur.
- Les développeurs qui ne sont pas aussi bons qu'ils le pensent peuvent être humiliés (bien qu'il n'y ait aucune garantie que vous obtiendrez cet avantage; certains développeurs sont vraiment inconscients, égoïstes et têtus).
- Les développeurs acquerront une connaissance du domaine. Cela est essentiel pour que vos développeurs parviennent à mieux identifier et combler les lacunes que la phase d'analyse commerciale (en supposant qu'il y en ait) manquent.
- n bon support est un point marketing. Si vous le faites bien, les clients l'apprécieront. Et un développeur complet avec des compétences en communication et une connaissance du domaine est capable de bien faire cela. Cependant, je préférerais quand même que les applications soient de qualité suffisante pour ne pas avoir besoin de support. La qualité supérieure est sa propre forme de support client (et aussi un point marketing).
Contre
- Facteur d'interruption. C'est la faute numéro un de mélanger le travail de projet et le travail de support, sans exception. Les projets interfèrent avec le support et le support interfère avec les projets. Les projets dépendent des estimations et des progrès des étapes, le soutien est imprévisible et peut impliquer une urgence impromptue. Les projets sont basés sur le calendrier, le support est basé sur les interruptions. Pas une combinaison heureuse, et très frustrant pour les développeurs.
- Tout le monde n'est pas bon en support. Quelqu'un qui est moins expérimenté avec l'application ou l'entreprise, ou quelqu'un dont la personnalité ou les compétences en communication sont telles qu'elles sont mieux protégées de l'accès des utilisateurs peut ne pas bien fonctionner en support.
- tilisation inefficace des ressources. Frank Shearar a noté dans les commentaires qu'un développeur faisant un support trivial peut être plus cher qu'une technologie de support de niveau un.
D'après mon expérience, la plupart des développeurs n'aiment pas le support. Ayant servi à la fois sur le projet et sur le soutien, je peux sympathiser. Lorsqu'ils doivent faire les deux en même temps, le facteur atténuant est souvent des heures supplémentaires, généralement non rémunérées, pour faire face aux urgences de soutien et toujours respecter les délais du projet. Les chefs de projet adorent les heures supplémentaires non rémunérées car cela signifie faire des rendez-vous sans coûter plus d'argent, mais pour les développeurs, c'est juste un gros bol de sucer.
Cependant, je crois également que si les développeurs faisaient un meilleur travail en créant des systèmes fiables et intuitifs, vous auriez moins de support. Cela crée donc un argument circulaire étrange pour mélanger les deux. Ce que je pense que vous devriez faire si vous devez faire les deux, c'est trouver des moyens d'éviter de le faire simultanément.
Je pense que les développeurs portent déjà deux chapeaux. Le support ressemble plus à un filtre utilisé pour protéger le développement contre des problèmes triviaux comme le fait de ne pas brancher l'ordinateur. Cependant, il devrait y avoir un couplage étroit entre le développement et le support. Certains clients ont des problèmes légitimes qui peuvent être le résultat d'un bogue. Il devrait être de la responsabilité du développement d'aider à régler ces problèmes le plus rapidement possible. Donc, dans un sens, les développeurs font déjà partie de l'équipe de support ... appelons cela le support de niveau 2.
Surtout, non.
Nous savons tous combien il peut être difficile d’arrêter ce que vous faites pour demander répondre à une question. Je réponds aux téléphones pour un service d'assistance et j'écris quelques applications utilitaires.
Je ne peux pas me concentrer sur la résolution d'un problème car toutes les 5 minutes je dois décrocher le téléphone. Aucun des deux travaux n'est fait aussi bien qu'il peut l'être parce que je pense constamment à ce que je peux faire pour résoudre un problème, et je ne travaille jamais sur la programmation assez longtemps pour implémenter pleinement toute solution que je pourrais avoir.
Encore une fois, je ne saurais trop insister sur l’importance de pouvoir se concentrer sur un aspect ou l’autre.
Je ne mettrais jamais un développeur comme support de première ligne. Le nombre d'interruptions et le montant que vous devrez répéter inciteront la plupart des développeurs à crier RTFM et à raccrocher la prochaine personne qui appelle. Ce n'est pas quelque chose dont vos clients ont besoin, ni ce que vous voulez que vos développeurs endurent.
Il y a une certaine règle dans tout poste de service à la clientèle. Pour un appelant furieux, la première personne qui répond au téléphone a tort. Qu'ils aient le président de l'entreprise, la personne qui a développé l'application ou le responsable du support, cela n'a pas d'importance. Une fois que le client a la deuxième personne, qui peut ou non savoir ce qu'il fait, le client pourra se calmer et expliquer le problème plus clairement.
Ce n'est pas un environnement que vous souhaitez retenir de bons développeurs. Est-il utile d'avoir un développeur interagir avec un client sur un problème particulièrement difficile qui va au-delà de "pourquoi mon porte-gobelet ne fonctionne plus"? Absolument. Mais c'est après que la demande de support a été vérifiée via les lignes de support de premier et deuxième niveau.
Cela dépend de l'entreprise.
Mon travail est exactement comme ça. Je suis développeur de logiciels, mais comme nous sommes une assez petite entreprise, chaque développeur assume un rôle de support "non officiel" généralement basé sur son propre logiciel. Certains développeurs doivent fournir plus d'assistance que d'autres, en fonction d'un certain nombre de facteurs tels que le nombre de produits qu'ils ont développés/expédiés, le bogue de leurs produits et leur efficacité sont au support. Si vous pouvez fournir au client exactement ce dont il a besoin pour résoudre le problème, il reviendra vers vous pour résoudre les problèmes le plus rapidement possible. Épée à double tranchant? Oui. Vous souffrez d'une productivité réduite, mais le client est satisfait et plus susceptible de rester un client. Ceci est important pour les petites entreprises.
Nous avons une équipe d'assistance aux systèmes, mais en raison de la nature de ce que nous faisons, ils doivent principalement faire face à des problèmes liés au matériel. Personnellement, dans une petite entreprise, ce problème n'est pas aussi perturbateur qu'on pourrait l'imaginer. Bien sûr, vous recevez des appels pendant que vous essayez de trouver une fonctionnalité importante, mais en même temps, le service client est beaucoup amélioré; ils peuvent avoir une voix faisant autorité qui sait (dans de nombreux cas) comment résoudre leur problème au lieu de quelqu'un avec des informations de seconde main et un script de support. Si vous ne pouvez pas résoudre le problème sur-le-champ, rassurez-les personnellement que vous implémenterez un correctif pour leur bogue ou envisagez leur demande de fonctionnalité pour une future version. Vous pouvez obtenir de vrais commentaires directement des utilisateurs de votre logiciel, de sorte que votre prochaine version peut être encore meilleure que vous ne le pensez déjà.
J'aime à penser que les clients satisfaits créent une image plus positive de votre entreprise, ce qui conduit généralement à plus de clients. Et c'est pourquoi, en tant qu'ingénieur logiciel, j'aime le support technique.
Les développeurs devraient être la dernière ligne de support.
Ce n'est que lorsque le service d'assistance et notre service d'assurance qualité ne peuvent pas aider un client que nous serons harcelés. Et même alors, il doit passer par notre système de suivi des bogues priorisé.
Si c'est vraiment un gros problème, nous l'entendrons.
Il n'y a rien de plus frustrant que le support informatique qui ne veut pas vous connecter avec quelqu'un qui comprend vraiment ce qui se passe. J'espère que toute grande entreprise d'application aura des programmeurs qui travailleront le support technique.
Il y a des talents et des compétences dont vous avez besoin pour développer des logiciels, et des talents et des compétences dont vous avez besoin pour être efficace sur le support de première ligne. Je ne sais pas si ces talents ont une corrélation.
Cela signifie que soit vous devez embaucher des développeurs en partie en fonction de leur capacité à fournir une assistance téléphonique, soit vous laissez vos clients parler directement à des personnes qui ne sont pas douées pour gérer les clients et ne veulent pas le faire en premier lieu. Cela peut ou ne peut pas être mieux que de les faire parler à un gars avec un accent indien épais qui lit un script poli.
De plus, lorsque vous rendez le travail désagréable (et je ne connais aucun développeur qui apprécie réellement le support de première ligne), certains de vos développeurs partiront. Ce sont généralement ceux qui peuvent obtenir plus facilement d'autres emplois: c'est-à-dire les bons. Au cours de ce processus, vous vous retrouvez avec une boutique remplie de personnes moins talentueuses, ce qui rend encore moins agréable pour les personnes compétentes de rester au-delà de la première offre d'emploi de quelqu'un d'autre.
En ce qui concerne le développement sérieux, oubliez-le s'il y a des interruptions fréquentes. Ma femme s'est plainte de devoir faire du développement et de soutenir les utilisateurs simultanément.
Mon dernier travail était exactement ça. Nous avons pris en charge les systèmes existants et en avons également écrit de nouveaux au besoin. C'était un désastre total. Je serais constamment interrompu. Mon moral était si bas parce que les projets commencés prenaient une éternité pour se terminer. De plus, nous avons dû transporter un téléavertisseur pour un soutien en dehors des heures de travail sans rémunération supplémentaire (c'était dans le domaine des soins de santé). Je pense que la solution (que j'ai suggérée à mon manager à l'époque) aurait été d'avoir une assistance technique de première ligne, et si c'est un bug logiciel, alors transmettez-la aux développeurs. Inutile de dire que je n'ai duré qu'un an et demi jusqu'à ce que je parte enfin pour un meilleur travail de développement!
Parfois, certainement oui. Faire face au client donne souvent une perspective que la plupart des gens, en particulier les programmeurs, manquent. La façon dont l'utilisateur utilise réellement le produit ou pense réellement est souvent très éloignée de la façon dont le constructeur (l'ingénieur) pense qu'il/elle le fait.
Cela devrait être pour de courtes périodes périodiques, afin de ne pas interrompre la tâche réelle de développement.
Je ne ferais cela que s'il s'agit d'un nouveau développeur ou d'un développeur qui ne connaît pas le domaine et la base de clients. En faire une chose permanente n'est pas une bonne idée.
Bien que je ne pense pas qu'il soit approprié d'utiliser les développeurs comme support tous le temps, je pense qu'il y a quelque chose à dire pour qu'un développeur fasse le support initial d'une application. Cela devrait inclure spécifiquement le support après les heures normales. Je pense également qu'il peut être utile de les programmer régulièrement sur le support après les heures de travail de leurs applications.
Il n'y a rien de tel que plusieurs appels 3AM pour vous faire réaliser quel effet certaines décisions de conception et/ou raccourcis ont sur la capacité des gens à prendre en charge et à maintenir votre code.
Je pense que cela dépend en grande partie de l'entreprise. Votre entreprise BigCo typique peut généralement se permettre d'avoir du personnel de soutien pour isoler les développeurs. D'un autre côté, une startup avec trois personnes total peut tout simplement ne pas avoir les ressources pour fournir des personnes de support distinctes.
Je pense que la meilleure stratégie générale (sans égard à la taille de l'entreprise ou aux ressources) est d'utiliser des équipes de support pour résoudre les problèmes les plus faibles et les problèmes les plus courants ("Avez-vous essayé de l'éteindre et de l'allumer?"). Les ingénieurs devraient travailler avec les clients sur les problèmes les plus délicats qui nécessitent une connaissance du fonctionnement du système et une assistance davantage orientée développeur (API, outils de développement, etc.). Vous pourriez faire en sorte que la personne de soutien agisse comme un "liason", mais je trouve que c'est généralement plus difficile que cela ne vaut.
Idéalement, non pour les raisons évoquées ci-dessus, mais oui alors que le projet est naissant, car les développeurs peuvent fournir des résolutions rapides, souvent attendues par les entreprises, ce qui contribue à l'amélioration continue du logiciel. J'apprécie les développeurs qui fournissent un support intelligent: ceux qui prêtent leurs compétences analytiques par exemple à une équipe de support à temps plein plus formelle, et ceux qui répondent à l'entreprise de manière à montrer un esprit de service et de coopération. Les clés de ce succès incluent cependant la gestion reconnaissant et formalisant le support de premier et deuxième niveau pour décharger rapidement les développeurs de ce qui ne devrait être que leur rôle à court terme. Les développeurs qui montrent un talent à la fois pour le développement et le soutien doivent être cultivés comme un soutien de troisième niveau ou un soutien pour les gens de soutien. Donc devrait dépend du temps, du talent et du désir, et est géré efficacement.
Mon intérêt personnel a été de répondre aux questions difficiles de l'assistance et de tirer parti de ce que j'ai appris de l'expérience pour réduire le besoin d'assistance dans son ensemble, ce qui profite aux utilisateurs finaux et à l'assistance principale.
Je suis tombé dans ce piège lorsque j'ai rejoint une entreprise avec un bon salaire. Pendant l'entretien, on m'a dit qu'il y aurait 70% de développement et 30% de soutien et j'ai accepté l'offre. C'est peut-être l'entreprise ou l'environnement sur lequel je travaille actuellement. Mais en fait, c'est 90% de support et 10% de développement. Cela fait maintenant quelques années que j'ai perdu le contrôle du développement. Je regrette d'avoir accepté cette offre.
Mais j'ai l'impression d'avoir perdu la maîtrise de coder plus là-bas, beaucoup de nouvelles technologies et de nouveaux cadres. Maintenant, je ne sais pas par où recommencer. Je continue de me préparer mais ces exemples helloworld ne suffisent pas pour avoir une bonne expérience pratique et il devient vraiment difficile de mettre à jour mes connaissances et mon expérience. Je ne peux même pas quitter mon travail pour recommencer à cause des engagements familiaux.
Malheureusement, je suis dans une impasse.
Veuillez ne pas accepter les rôles si vous n'aimez pas ou si cela ne vous intéresse pas.