Les ingénieurs en logiciel doivent-ils également faire fonction de support technique? [fermé]

Un ingénieur logiciel doit-il également agir en tant que support technique? En d’autres termes, si une entreprise permettait à ses ingénieurs de porter à la fois les chapeaux de l’ingénieur logiciel et du support technique. Il semble que cela supprime la possibilité d'écrire des logiciels si le support technique prend beaucoup de temps à un ingénieur.

C’est un problème classique dans les entreprises qui ont un composant de développement logiciel dans leur travail, qu’il s’agisse de sociétés de logiciel ou non. Je lutte avec cela tout le temps.

Avoir des développeurs impliqués dans le support de production

Avantages

• Combat le syndrome "Développement sous vide" . Il est utile de se familiariser avec la manière dont les utilisateurs utilisent l'application. Jusqu'à ce que je voie enfin cela en tant que jeune développeur, je ne réalisais pas à quel point j'étais un développeur de l'interface utilisateur merdique. Tout ce qui m'importait é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 obteniez 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 puissent finalement mieux identifier et combler les lacunes de la phase d'analyse commerciale (en supposant qu'il en existe).
• Un bon support est un point de marketing. Si vous le faites bien, les clients vont l'apprécier. Et un développeur chevronné doté de compétences en communication et d'une connaissance du domaine est capable de le faire correctement. Cependant, je préférerais quand même que les applications soient de qualité suffisante pour ne pas avoir besoin de support. Une qualité supérieure est sa propre forme de support client (et également un point de marketing).

Les inconvénients

• Facteur d'interruption . C’est la faute numéro un du mélange de travail de projet et de support, sans exception. Les projets interfèrent avec le soutien, et le soutien interfère avec les projets. Les projets dépendent d’estimations et de progrès jalons, l’assistance est imprévisible et peut impliquer une urgence impromptue. Les projets sont basés sur un calendrier, le support est basé sur des interruptions. Pas une combinaison heureuse et très frustrante pour les développeurs.
• Tout le monde n'est pas bon en soutien . Une personne moins expérimentée dans l'application ou l'entreprise, ou une personne dont la personnalité ou les compétences en communication sont telles qu'elle est mieux protégée de l'accès des utilisateurs, risque de ne pas bien fonctionner en matière de support.
• Utilisation inefficace des ressources . Frank Shearar a noté dans ses commentaires qu’un développeur qui assurait une assistance triviale pouvait coûter plus cher qu’une technologie d’assistance de niveau 1.

D'après mon expérience, la plupart des développeurs n'aiment pas le support. Ayant servi à la fois du projet et des côtés de soutien, je peux sympathiser. Lorsqu'il faut faire les deux en même temps, le facteur atténuant est souvent le temps supplémentaire, généralement non rémunéré, pour faire face aux urgences liées au support tout en respectant les délais du projet. Les chefs de projet adorent les heures supplémentaires non rémunérées, car cela signifie que vous devez prendre des rendez-vous sans coûter plus cher, mais pour les développeurs, ce n'est qu'un gros bol de sucer.

Cependant, je pense aussi que si les développeurs réussissaient mieux à créer des systèmes fiables et intuitifs, leur assistance serait moindre. Cela crée donc un étrange argument circulaire 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 rendre simultané.

Je pense que les développeurs portent déjà deux casquettes. La prise en charge s'apparente davantage à un filtre utilisé pour protéger le développement contre des problèmes triviaux, tels que le fait de ne pas avoir l'ordinateur branché. Cependant, il devrait exister un lien étroit entre développement et prise en charge. Certains clients ont des problèmes légitimes résultant peut-être d'un bogue. Le développement devrait avoir la responsabilité d'aider à résoudre ces problèmes le plus rapidement possible. En un sens, les développeurs font déjà partie de l'équipe de support technique ... appelez cela un support de niveau 2.

Catégoriquement non.
Nous savons tous combien il peut être difficile d’arrêter ce que vous faites pour poser une question. Je réponds aux téléphones pour un service d'assistance et j'écris des applications utilitaires.

Je ne peux pas me concentrer sur la résolution d'un problème car toutes les 5 minutes, je dois prendre le téléphone. Aucune de ces tâches ne peut être accomplie aussi bien que possible car je réfléchis constamment à ce que je peux faire pour résoudre un problème et je ne travaille jamais assez longtemps à la programmation pour mettre pleinement en œuvre 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 en première ligne. Le nombre d'interruptions et le nombre de fois que vous devrez répéter vous incitera 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 quelque chose que vous voulez que vos développeurs subissent.

Il existe une certaine règle dans tout poste de service à la clientèle. Pour un appelant en colère, la première personne qui répond au téléphone se trompe. Qu'ils aient le président de l'entreprise, la personne qui a développé l'application ou le responsable du support, peu importe. Une fois que le client aura trouvé la deuxième personne, qui peut ou non savoir ce qu’il fait, il sera capable de se calmer et d’expliquer le problème plus clairement.

Ce n'est pas un environnement dans lequel vous voulez conserver de bons développeurs. Y a-t-il avantage à ce qu'un développeur interagisse avec un client sur un problème particulièrement difficile qui dépasse le cadre "Pourquoi mon porte-gobelet ne fonctionne-t-il plus"? Absolument. Mais cela intervient une fois que la demande de support a été validée via les lignes de support de premier et deuxième niveaux.

Cela dépend de la compagnie.

Mon travail est exactement comme ça . Je suis un 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 / livrés, le niveau de bug de leurs produits et l'efficacité de leur prise en charge . Si vous pouvez fournir au client exactement ce dont il a besoin pour résoudre le problème, il continuera à vous contacter 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 reste plus susceptible de rester client. Ceci est important pour les petites entreprises.

Nous avons une équipe de support système, mais en raison de la nature de ce que nous faisons, ils sont principalement confrontés à des problèmes liés au matériel. Personnellement, dans une petite entreprise, ce problème n’est pas aussi perturbant qu’on pourrait l’imaginer. Bien sûr, vous recevez des appels lorsque vous essayez de définir une fonctionnalité importante, mais en même temps, le service clientèleest 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 d'assistance. Si vous ne pouvez pas résoudre le problème sur-le-champ, rassurez-les personnellement que vous allez implémenter un correctif pour leur bogue ou prendre en compte leur demande de fonctionnalité pour une version ultérieure. Vous pouvez obtenir de réels commentaires directement des utilisateurs de votre logiciel, de sorte que votre prochaine version puisse être encore meilleure que ce que vous pensez déjà.

J'aime penser que des clients satisfaits créent une image plus positive de votre entreprise, ce qui conduit généralement à davantage de clients . Et c’est pourquoi, en tant qu’ingénieur logiciel, j’aime le support technique.

Il n’ya rien de plus frustrant que le support technique informatique ne voulant pas vous mettre en contact avec quelqu'un qui comprend vraiment ce qui se passe. J'espère que toute grande entreprise d'applications aura des programmeurs qui travailleraient avec 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 pourront aider un client que nous serons harcelés. Et même dans ce cas, il doit passer par notre système de suivi des bogues hiérarchisé.

Si c'est un très gros problème, nous l'entendrons.

Je ne ferais cela que s'il s'agit d'un nouveau développeur ou d'un utilisateur qui n'est pas familier avec le domaine et la clientèle. En faire une chose permanente n'est pas une bonne idée.

Mon dernier travail était exactement cela. Nous avons pris en charge les systèmes existants et en avons également écrit de nouveaux si nécessaire. C'était un désastre total. Je serais constamment interrompu. Mon moral était si bas parce que les projets commencés prendraient une éternité. De plus, nous devions transporter un téléavertisseur pour les heures creuses sans salaire supplémentaire (dans le domaine des soins de santé). Je pense que la solution (que j'avais suggérée à mon responsable à l'époque) aurait été d'avoir un support technique de première ligne, et s'il s'agit d'un bogue logiciel, transmettez-le aux développeurs. Inutile de dire que je n'ai duré qu'un an et demi avant de finalement partir pour un meilleur travail de développement!

Une partie du temps, certainement oui. Faire face au client donne souvent une perspective qui manque à la plupart des gens, en particulier aux programmeurs. La façon dont l'utilisateur utilise réellement le produit ou pense réellement est souvent très éloignée de celle du constructeur (l'ingénieur).

Ce doit être pour de courtes périodes périodiques, afin de ne pas interrompre la tâche de développement actuelle.

Il vous faut des talents et des compétences pour développer des logiciels, et des talents et des compétences pour être efficace sur le support de première ligne. Je ne sais pas si ces talents ont une corrélation.

Cela signifie que vous devez engager des développeurs en partie en fonction de leur capacité à assurer une assistance téléphonique ou laisser vos clients parler directement à des personnes qui ne sont pas douées pour la gestion des clients et qui ne veulent pas le faire en premier lieu. Cela peut être ou ne pas être mieux que de les avoir parler à un gars avec un fort accent indien qui lit à partir d'un script poli.

De plus, lorsque vous rendrez le travail désagréable (et que je ne connais aucun développeur qui bénéficie réellement d'un support de première ligne), certains de vos développeurs partiront. Ce sont généralement ceux qui peuvent obtenir un autre emploi plus facilement: les bons. Au fur et à mesure que ce processus se poursuit, vous vous retrouvez avec un magasin rempli de personnes moins talentueuses, ce qui le rend encore moins agréable pour les personnes compétentes qui veulent éviter la première offre d'emploi de quelqu'un d'autre.

En ce qui concerne le développement sérieux, oubliez cela s'il y a de fréquentes interruptions. Ma femme s'est beaucoup plainte de devoir faire du développement et de la prise en charge simultanée des utilisateurs.

Je pense que tout dépend de la société. Votre entreprise typique de BigCo peut généralement se permettre d’avoir du personnel de soutien pour isoler les développeurs. D'autre part, une startup avec trois personnes au total peut tout simplement ne pas avoir les ressources nécessaires pour fournir des personnes de soutien distinctes.

Je pense que la meilleure stratégie générale (sans égard à la taille ou aux ressources de l'entreprise) consiste à utiliser des équipes de support pour résoudre les problèmes les plus courants et les problèmes les plus courants ("Avez-vous essayé de l'éteindre et de l'activer?"). Les ingénieurs doivent travailler avec les clients pour résoudre les problèmes plus complexes qui nécessitent une connaissance du fonctionnement du système, ainsi qu'un support plus orienté développeur (API, outils de développement, etc.). Vous pouvez faire en sorte que la personne de soutien agisse en tant que "liaison", mais je trouve que c'est généralement plus de problèmes que cela ne vaut.

Bien que je ne pense pas qu'il soit approprié d'utiliser les développeurs en tant que support tout 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 notamment inclure le support après les heures normales. Je pense aussi qu’il peut être utile de les programmer régulièrement dans le service de soutien après les heures normales de travail pour leurs applications.

Il n'y a rien de tel que plusieurs appels 3AM pour vous faire comprendre l'effet de certaines décisions de conception et / ou de raccourcis sur la capacité des utilisateurs à prendre en charge et à maintenir votre code.

Idéalement non pour les raisons indiquées ci-dessus, mais oui, alors que le projet est naissant, car les développeurs peuvent fournir des 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 apportent leurs compétences analytiques par exemple à une équipe de support à temps plein plus formelle et ceux qui répondent aux besoins de l'entreprise de manière à faire preuve d'un esprit de service et de coopération. Les clés de ce succès incluent cependant la direction reconnaissant et formalisant le support de premier et deuxième niveau pour permettre aux développeurs de se décharger rapidement de ce qui ne devrait être que leur rôle à court terme. Les développeurs qui ont un don pour le développement et le soutien doivent être cultivés en tant que soutien de troisième niveau, ou soutien pour le personnel de soutien. Donc devrait dépend du temps, du talent et du désir, et est géré efficacement.

Mon propre intérêt a été de répondre aux questions de support difficiles et de mettre à profit ce que j'ai appris de cette expérience pour réduire le besoin de support en général, ce qui profite à la fois aux utilisateurs finaux et au support principal.

Je suis tombé dans ce piège lorsque j'ai rejoint une entreprise bien rémunérée. Au cours de l'entretien, on m'a dit qu'il y aurait 70% de développement et 30% de soutien, et j'ai accepté l'offre. Peut-être que c'est l'entreprise ou l'environnement sur lequel je travaille actuellement. Mais en réalité, il supporte 90% et 10% de développement. Cela fait quelques années maintenant que j'ai perdu le contrôle du développement. Je regrette d'avoir accepté cette offre.

Mais j’ai le sentiment que j’ai perdu l’emprise de coder davantage là-bas beaucoup de nouvelles technologies et de nouveaux frameworks. Maintenant, je ne sais pas par où recommencer. Je continue à me préparer, mais ces exemples du monde obscur ne suffisent pas pour acquérir 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 obligations familiales.

Malheureusement, je suis dans une impasse.

S'il vous plaît ne pas accepter les rôles si vous n'aimez pas ou pas intéressé po

Inconvénients - en supposant que vous devez traiter directement avec les clients.

1) Gâter vos clients

S'il s'agit d'un support de première / deuxième / troisième ligne (je veux dire réellement du support de ligne floue) dans lequel les développeurs traitent directement avec les clients, il s'agit d'un gros problème. Les développeurs possèdent les compétences requises pour déboguer des problèmes ou développer des solutions pour les résoudre. Si les clients ont un accès complet aux développeurs (ligne floue), rien n'empêche les clients d'abuser de ce privilège, ce qui se traduit par des clients gâtés, exigeants et privilégiés qui ne paient pas plus que tout autre client.

2) Conditionner vos développeurs à mentir et à inventer des histoires.

Quiconque a traité avec des clients sait que le fait de pouvoir leur mentir est une condition préalable. Il y a un bug avec un correctif d'une ligne qui peut être corrigé en 5 minutes. Un membre du service clientèle aurait été formé pour gérer les attentes du client, ce qui prendrait jusqu'à 3 jours pour le résoudre.

En tant que développeur, si vous devez traiter directement avec les clients, vous devez penser à des moyens créatifs d'apaiser ou de tromper les clients lorsque votre tâche principale consiste à résoudre des problèmes techniques et à vous assurer que le système fonctionne correctement.

3) Votre Curriculum Vitae Souffre.

Sauf si vous passez de l’ingénieur logiciel à l’analyste commercial / consultant informatique / gestion de projet, votre CV souffrira d’un aspect technique.

Le travail d'assistance rémunéré qui tourne au sein de l'équipe est une autre histoire.

Avantages

1) Stop Whiners de pleurnicherie

Les développeurs qui font ce qu’ils détestent leur feront apprécier le codage beaucoup plus. Avoir un programmeur qui est constamment en colère? Mettez-les sur la hotline pendant un mois.

Oui de cause ils font. J'ai lol'd quand j'ai lu cette question? Je me demandais en quoi cela constituait une question (non pas que je remette en question votre droit de poser la question OP), mais c’est assez rhétorique, car presque tous les Dev que j’ai rencontrés ont eu un type de travail de support technique implicite dans leur sa fonction de travail. Vous ne pouvez simplement pas l'éviter. Dans la plupart des cas, vous êtes la personne la plus techniquement compétitive, pas seulement dans votre domaine fonctionnel, mais également en termes d’informatique. C'est très difficile à éviter complètement.