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


48

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.



2
Par support technique, voulez-vous dire soutenir les applications spécifiques qu’ils développent ou un type général d’administrateur système? Je peux vous dire que travailler dans une petite entreprise est agaçant et que des personnes vous demandent de vous installer Excel.
Carlos

12
Devrions nous? Non, nous? Oui. Je déteste ça.
Rachel

7
Un ingénieur doit toujours s’efforcer de commettre des erreurs apparemment innocentes qui occasionnent plus de travail pour la personne qui pense que ce serait une excellente idée de les utiliser pour du support technique.
Erik Reppen

Réponses:


74

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


1
Je pense que soutenir un projet en développement n'est pas mauvais. Parler avec le client, c'est bien. Mais si vous travaillez sur 7 projets avec 7 délais différents et une urgence différente ... Au bout d’un moment, ce n’est vraiment pas très bon. ça craint très mal.
Loïc Faure-Lacroix le

4
J'ai également vu des magasins dans lesquels les développeurs qui respectent leurs échéances se contentent de hausser les épaules et de dire "J'ai eu beaucoup de temps de support cette semaine. Pas de bugs, les utilisateurs avaient juste besoin d'une prise en main". En règle générale, il était impossible de savoir si cela se produisait ou si le développeur était simplement lent cette semaine-là. Tant que vous contrôlez pour cela, je suis en faveur des développeurs prenant en charge leur code, mais pas en tant que support téléphonique de première ligne.
Kate Gregory

10
Il devrait y avoir une couche de support de première ligne pour répondre aux questions RTFM, ne laissant que les questions avec un contenu technique / feedback utile pour les développeurs.
Robert Harvey

4
@Christopher: Les systèmes auto-descriptifs sont un idéal idéal, mais difficile à réaliser en pratique. De nombreux facteurs liés aux personnes et aux pressions des parties prenantes s'opposent à leur bien-être, et il y aura toujours des utilisateurs qui «ne l'obtiennent pas».
Robert Harvey

1
Une excellente réponse. Mon entreprise trouve un bon compromis: chaque développeur consacre une journée au support technique de troisième ligne, en alternant avec l'équipe. Si vous êtes sur la technologie, vous pouvez être interrompu dans des limites raisonnables, mais tout le monde est à l'abri à moins qu'un événement majeur ne survienne. Pendant nos journées sur la technologie, nous avons tendance à faire des corrections de bugs, des trucs d'administrateur, etc. plus légers pour éviter d'être dans quelque chose de complexe quand ils sont interrompus ... Donc, fondamentalement, nous avons tous une journée pour faire la merde, les développeurs détestent mais doivent le faire, mais sachez que nous recevons des appels de support occasionnels pour le séparer. Plus important encore, il est bon de savoir que vous êtes immunisé le reste du temps!
Jon Story

18

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.


18

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.


+1 je peux rapporter à tout ce que vous avez dit. J'étais dans une position similaire il y a quelques semaines. Maintenant, nous n'avons pas de téléphone, mais ils frappent quand même à la porte, même pour des choses comme: "Hé les gars, avez-vous vu X autour?" Décidément!
jasonco

1
Vous pouvez réserver des «heures de bureau» pour éviter les interruptions. Le support sur appel n’est pas une bonne idée.
JeffO

2
D'accord, les programmeurs semi-dysfonctionnels ne font pas de très bons assistants :)
Homde

6
C'est une mauvaise réponse à mon avis. Un développeur qui ne prend JAMAIS en charge ne peut jamais apprendre comment leurs décisions affectent l'utilisateur, qu'il soit bon ou mauvais. Regarder quelqu'un essayer d'utiliser le logiciel peut être un appel au réveil, même si vous pensez que cela correspond aux spécifications. Il existe des moyens d'atténuer les aspects négatifs de celui-ci, en alternant les calendriers entre les développeurs, le support technique pour gérer les appels de désactivation afin que vous ne supportiez que votre application, etc. sont vraiment s'ils ne peuvent même pas parler à l'utilisateur. Supervisez si nécessaire pour qu'ils puissent apprendre.
Jay

1
@ BryanOakley: avoir un plan qui obtiendra un support technique. Bien que je soutienne toujours ma réponse, il n’est pas réaliste d’espérer qu’une start-up dispose de tout le personnel nécessaire pour assurer un support et un développement clients adaptés . Je recommanderais toujours que la tâche principale du développeur soit le développement - pas le support client. Le problème est que, lorsqu'un développeur entretient des liens étroits avec un client, celui-ci: a) sera toujours contacté directement par le client plutôt que par les canaux techniques appropriés, ou vaste champ de développement nécessaire.
Résumé de l'étape

10

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.


Zappos a construit un empire qui va à l'encontre de la règle de la première personne.
JeffO

Je ne sais pas à propos de Zappos, mais cela semble assez vrai pour la plupart des entreprises. Tout ce que je sais, c'est que si je suis suffisamment frustré pour appeler le support technique, je me sens mal pour la personne à l'autre bout de la ligne.
Berin Loritsch

Jamais? Comme jamais, jamais? Même si vous étiez une petite entreprise composée de vendeurs et d'un ou deux développeurs? Pas même si vos développeurs étaient des communicateurs très forts et aimaient parler avec les clients?
Bryan Oakley

Vous souhaitez que vos développeurs soient perçus comme compétents - faites-en la deuxième personne à laquelle le client s'adresse. D'ici là, le client va se calmer et se comporter un peu plus raisonnablement. Maintenant, s'il s'agit d'un client avec lequel vous entretenez de bonnes relations et que ce n'est pas la première introduction que le développeur a à faire au client, tout irait parfaitement. Le premier contact doit être examiné par quelqu'un d'autre en premier.
Berin Loritsch

En tant que support de première ligne, je pense que la règle selon laquelle "l'appelant en colère pensant que la première personne qui répond au téléphone est mauvaise" n'est pas correcte. Bien que je ne puisse parler que de ma propre expérience . Les appelants occasionnellement en colère qui pensent que cela soit réalise leur erreur ( tant que la ligne de front est réellement informée ) ou ne cherchent tout simplement pas une solution, mais plutôt une personne à blâmer - ce qui signifie que personne ne peut les aider. Je suis toujours d'accord dans l'ensemble - les développeurs devraient être le dernier contact, une fois qu'il aura été déterminé qu'il existe un bogue quelque part (ou très
susceptible d'

9

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.


Je suis dans le même bateau que toi et je suis tout à fait d'accord avec toi. Cependant, il devrait être possible et plus souvent qu'un réceptionniste prenne l'appel et rédige une note pour vous permettre de rappeler ce client. De cette façon, vous pouvez continuer à ne pas être interrompu dans votre travail et rappeler si cela vous convient le mieux. Toutefois, rappelez-vous le jour même, de préférence dans les 2 heures qui suivent l'appel.
Htbaa

3

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.


4
Il existe une certaine loi avec le support technique: le premier type que vous recevez est toujours dans l'erreur. Il peut être la personne la plus technique de l'équipe et, du fait qu'il a pris le téléphone en premier, le client ne pourra pas leur faire confiance. Fondamentalement, le premier type existe pour laisser le client s'exprimer et dégager de la fumée afin que le suivant puisse être le "sauveur". C'est le cas dans n'importe quelle profession du service clientèle - pas seulement le support technique.
Berin Loritsch

@BerinLoritsch C'est une loi tirée de l'expérience, pas un préjugé injustifié comme vous semblez le laisser supposer. Je ne sais pas ce qu'il faudrait pour convaincre le centre d'assistance que, oui, j'ai essayé les solutions habituelles. Évidemment, cela ne peut pas être basé sur ce que je demande, mais j'ai remarqué qu'en 20 mots ou moins, je peux savoir si la personne a effectué son dépannage de base.
Milind R

3

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.


2

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.


2

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!


2

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.


2

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.


1

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.


1

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.


2
Correction: il n’existe pas de multiples appels 3AM pour vous faire comprendre l’effet de certaines décisions de conception et / ou raccourcis imposés par votre responsable sur la capacité des utilisateurs de prendre en charge et de gérer votre code. Une mauvaise conception et un mauvais code résultent plus souvent d'une mauvaise gestion que de mauvais programmeurs.
David Thornley

0

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.


0

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


-1

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.


3
Mettez-les sur la hotline pendant un mois. Ensuite, recherchez un développeur de remplacement, car ce type ne sera pas long. En outre, recherchez quelqu'un qui soit bon dans les relations avec la clientèle pour apaiser ceux qui ont parlé à une personne qui était de mauvaise humeur avant d'être assignée à faire quelque chose qu'elle déteste et qui ne montre aucun respect de la part de la société.
David Thornley

D'accord avec David. Si vous devez gérer votre équipe comme une salle de classe, vous voudrez peut-être reconsidérer vos pratiques d'embauche et / ou votre environnement de travail.
Matthieu

-1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.