Comment «vendre» le support comme option de carrière [clôturé]

Nous trouvons qu'il est relativement facile d'embaucher des développeurs pour travailler sur divers projets.

Le problème survient lorsque le projet est terminé mais doit encore être pris en charge.

Nous nous battons vraiment pour amener les gens à rejoindre l'équipe d'assistance. Il est considéré comme une impasse, une limitation de carrière, ennuyeux, de deuxième classe, etc.

Actuellement, nous contournons cela en demandant à l'équipe de projet d'affecter une partie de leur équipe à l'équipe de support pendant un certain temps. Une partie de la mission consiste à faire un "brain dump" du projet afin que l'équipe de support le comprenne. Cela fonctionne tant que l'affectation n'est que pour une période fixe.

Essayer d'embaucher des gens pour travailler à plein temps dans le soutien est un problème. Il y a peu d'applications et le calibre n'est pas particulièrement élevé.

(La réalité financière est cependant que le soutien peut être très lucratif pour une entreprise et une fois que vous obtenez une réputation, vous êtes approché par d'autres entreprises pour apporter leur soutien même si vous n'avez pas été impliqué dans le développement d'origine.)

Ne le fais pas

Pour moi, la meilleure option ici n'est pas de séparer les développeurs en support et non support en premier lieu. À mon humble avis, il y a trois raisons principales:

• les gens qui écrivent des choses difficiles à soutenir n'apprennent pas tant qu'ils ne doivent pas les soutenir.
• les personnes qui n'apportent qu'un soutien prendront généralement le chemin de la moindre résistance pour corriger une erreur même si cela entrave les travaux futurs.
• le gain de temps théorique en respectant le calendrier dans le nouveau développement en ayant les développeurs de support séparés est toujours plus que consommé en ayant à fournir des instructions ou à répéter le travail.

Au sein de l'équipe de développement, vous pouvez avoir des personnes qui ont des tâches de maintenance ou adopter une approche consistant à laisser les tâches de maintenance être le terrain d'entraînement des nouveaux membres de l'équipe, mais si vous essayez de le vendre comme objectif à long terme du poste, vous n'attirerez que les gens qui vous donneront des brûlures d'estomac ou ceux qui seront bientôt sur le point de sortir.

Il doit toujours y avoir un chemin clair pour sortir d'un rôle de développeur de support à 100%, et / ou un certain pourcentage de nouveaux travaux de développement pour garder les bonnes personnes intéressées.

Vous ne voulez pas attirer indéfiniment le genre de personnes qui sont heureuses dans ce rôle et vous ne convaincrez jamais de bons développeurs de prendre ce rôle et de le garder à long terme, sauf si vous offrez le type de rémunération qui ne les ferait jamais envisager un changement de carrière.

Rendez le travail de support amusant et précieux pour vos développeurs.

J'adore faire du support pour les raisons suivantes:

• Je parle avec des gens du monde entier. Je me suis fait beaucoup d' amis comme ça. Il y a quelques années, un de mes clients m'a invité à son mariage! J'avais une carte du monde dans mon bureau avec des épingles qui les localisaient.
• Le soutien est presque le meilleur pour obtenir des gratifications pour votre travail. Lorsque vous rendez les utilisateurs heureux, cela vous rend également plus heureux.
• Les plaintes sont un moyen utile de s'améliorer. Je prends toute plainte au sérieux et, dans la plupart des cas, je peux convertir quelqu'un en colère en un client / utilisateur heureux qui finira par passer le mot.
• Cela m'aide à comprendre ce dont les clients / utilisateurs ont besoin. Ensuite, je peux créer de meilleurs logiciels.

Ce ne sont que quelques raisons.

En ce qui concerne le support lui-même, je suggère de mettre en œuvre un processus facile à gérer.

Lorsque nous recevons un dossier d'assistance, nous procédons comme suit:

• S'il s'agit d'un bug reproductible, nous l'ajoutons dans le backlog et donnons son identifiant au client / utilisateur. Nous prenons également l'ID du client / utilisateur pour l'informer des résolutions et le libérer personnellement. C'est facile si vous récupérez son e-mail directement.
• En cas de problème d'utilisation du logiciel, nous en profitons pour améliorer la documentation. Toute réponse est écrite comme un article de la base de connaissances que nous ajoutons ensuite dans notre base de données. L'écriture prend trois fois plus de temps, mais nous ne répéterons pas la suite plus tard (la plupart des utilisateurs préfèrent naviguer en Ko).
• S'il s'agit d'une demande de fonctionnalité, nous connectons directement l'utilisateur au propriétaire du produit. C'est très précieux. Bien sûr, nous utilisons des systèmes comme uservoice.com, mais parler directement avec l'utilisateur est beaucoup mieux.
• S'il s'agit d'une plainte, nous essayons de gérer cela en dehors du processus. Les personnes qui se plaignent aiment être considérées comme importantes (même si la plainte est insignifiante).

Pourquoi ne pas simplement payer les développeurs de support 5 ou 10k de plus que la version et oublier les développeurs?

En attachant une prime supplémentaire aux rôles de support; en reconnaissance des défis supplémentaires de la "liaison client" et de la "maintenance du code de production"; vous fournirez non seulement une motivation supplémentaire, mais plus important encore, les rôles seront considérés comme ayant plus de prestige. Après tout, un salaire plus élevé doit signifier un rôle plus important et même si ce n'est pas le cas, il sera perçu de cette façon.

Si vous pensez que le soutien est un travail de second ordre, vous aurez probablement du mal à embaucher des gens pour cela. Si vous le traitez comme un emploi à durée limitée et sans issue, vous n'obtiendrez pas de bons candidats.

Le support n'est généralement pas aussi amusant que les nouveaux développements, et si vous avez des équipes de développement et de support distinctes, les équipes de support doivent prendre ce que le développement leur apporte, ce qui n'est souvent pas amusant. (J'ai travaillé une fois dans un endroit où la R&D nous remettait des logiciels qui faisaient quelque chose de cool, mais qui nécessitaient généralement une refonte pour être de qualité production, et nous n'avons pas eu assez de temps pour le faire, pour des raisons politiques. Ce n'était pas amusement.)

Si le support est vraiment critique pour l'entreprise, vous devez le traiter comme tel. Si vous insistez pour avoir des équipes d'assistance distinctes et qu'il est important d'en avoir de bonnes, vous devez résoudre ces problèmes. Assurez-vous qu'il y a un cheminement de carrière. Faites connaître l'argent que vous gagnez grâce au soutien, en partie pour leur estime de soi, en partie pour que les autres réalisent leur valeur, en partie afin qu'ils puissent mettre des chiffres en dollars pour leurs activités sur leur curriculum vitae. Établir des normes et permettre aux équipes d'assistance de savoir si un projet est prêt à passer du développement au support. Puisque le travail est moins amusant et peut-être plus important, payez-les mieux. (J'aurais plus de sympathie avec les gestionnaires qui se plaignent «nous ne pouvons pas obtenir les candidats dont nous avons besoin» si cela ne se traduit généralement pas par «nous ne pouvons pas les candidats dont nous avons besoin à bas prix».)

Bien que je sois d'accord pour dire que le soutien est généralement nul, de nombreux développeurs pourraient en fait profiter du prestige qui accompagne la «propriété» du projet, même s'ils n'ont pas écrit le logiciel eux-mêmes. Ce programmeur devient le goto sur ce projet, et ils deviennent vraiment un expert inestimable sur le système. Bien que je sois principalement impliqué dans les nouveaux développements dans l'entreprise pour laquelle je travaille, beaucoup de mes collègues qui sont plus que compétents sont en fait très respectés pour leur maintenance de nos logiciels les plus critiques. Après tout, le logiciel actuellement pris en charge est probablement celui qui fait actuellement de l'argent (un oiseau à la main en vaut deux dans la brousse).
Je dirais simplement que tout le monde ne voit pas le soutien comme un terrible travail de donjon pour les programmeurs inférieurs à la normale, et je jouerais ce sentiment pour attirer plus de gens.

Quelques réflexions:

1) Vous dites que c'est considéré comme une impasse et une limitation de carrière. Si ce n'est pas vrai et que les gens sont passés à d'autres choses (développement, gestion de projet, gestion de l'équipe), je suis sûr que vous avez des exemples que vous pouvez utiliser. Si vous n'avez pas d'exemples, vous devrez peut-être accepter que c'est une impasse et une limitation de carrière et que vous devez résoudre ces problèmes.

2a) Si le support comprend la correction de bogues, alors pourquoi sont-ils séparés? Si quelqu'un a mal codé pour commencer, alors qu'est-ce que vous leur enseignez en donnant leur désordre à quelqu'un d'autre pour le trier. De plus, si les développeurs de support ne sont pas perçus comme aussi bons que les développeurs, comment pouvez-vous vous attendre à ce qu'ils corrigent ce que les développeurs ne peuvent pas corriger? Sérieusement, la règle devrait être que vous l'avez écrite, que vous la corrigez.

2b) Si le support n'inclut pas la correction de bogues, ce sont des tâches très différentes et mettent l'accent sur différentes compétences. Vous ne devriez pas plus vous soucier du croisement ici que de celui du croisement entre le développement et le nettoyage.

3) Vous dites que c'est lucratif pour l'entreprise - puis faites-le pour les personnes impliquées. Cela pourrait être grâce à un meilleur argent, une meilleure formation, un meilleur équipement et en leur donnant tout ce dont ils ont besoin pour faire ce genre de choses vraiment très bien. S'il y a de l'argent disponible, faites-en un excellent travail.

Le problème de la lecture de votre message est que vous ne semblez pas croire que c'est un bon travail. Si c'est vrai, il n'est pas étonnant que vous ne puissiez pas le vendre comme tel.

Le soutien est un travail difficile, aucun organisme n'aime écouter les gens se plaindre toute la journée. Trouver de bonnes personnes peut prendre du temps, mais une fois que vous en avez, vous devez les garder en

1. Payez beaucoup d'argent, même bien au-dessus des tarifs de l'industrie pour garder de bonnes personnes
2. Fournir un bon environnement de travail, de petites choses comme le déjeuner et les boissons fournis par le travail
3. Ne pas entasser tout votre personnel de soutien dans une petite pièce bruyante

Je pense que zappos.com a montré qu'un travail n'a pas à être merdique lorsque vous travaillez pour une bonne entreprise. Le pire aspect du soutien est de ne pas pouvoir aider quelqu'un. Si vous avez foutu les utilisateurs avec un contrat de service en petits caractères ou expédié un logiciel de buggy qui ne sera pas résolu de sitôt, le support sera nul. Ils doivent être encouragés à trouver des solutions aux problèmes; un peu comme la programmation.

J'ai soutenu pendant quelques années ma première entreprise à la sortie de l'université. Ce qui m'a amené à m'inscrire pour quelques années était:

1. Le cheminement de carrière requis pour devenir ingénieur logiciel.
2. J'avais besoin de temps pour parfaire la langue principale de l'entreprise (Fortran, Circa 1989)
3. Je n'étais pas mariée, donc je pouvais démissionner si je découvrais que je n'aimais pas l'entreprise ou le travail.

Que diriez-vous d'un mélange de développement et de soutien (rôles partagés)? Je pense que vous aurez toujours du mal à obtenir l'adhésion pour cela pour les raisons déjà mentionnées (développeurs! = Personnes de support produit). Mais si votre produit repose sur une large compréhension de la technologie interne, peut-être 80% de développement, un support de 20% serait un compromis équitable. Ou une sorte de mentorat / d'observation pour les nouveaux employés afin de s'assurer qu'ils obtiennent des informations correctes sur le produit.