En suivant la méthode du chapitre précédent, l'analyse des bugs peut toujours progresser. Cependant, il y a toujours des moments où les idées s'épuisent, et l'aide des autres est particulièrement importante à ce moment-là.
En tant que FAE, j'aide souvent les autres à résoudre des bugs. J'ai constaté que beaucoup de gens ne peuvent pas communiquer et qu'ils ne peuvent pas comprendre ce qui s'est passé après avoir parlé pendant longtemps. Aujourd'hui, je vais parler des compétences en communication lors de la recherche d'aide.
-1- Décrivez clairement le bug
Changez simplement la langue écrite dans le chapitre précédent " Analyzing BUG (2) " en langue parlée. Je n'entrerai pas dans les détails ici.
-2- N'induisez pas les autres en erreur
Lorsque nous décrivons des bogues à d'autres, nous devons les baser sur des faits et ne faire aucune suppression, sinon nous dirigerons les idées des autres vers les vôtres. Votre propre façon de penser ne peut plus résoudre le bogue, et les autres ne peuvent pas le résoudre en pensant selon votre façon de penser. Je reçois souvent des appels de clients comme celui-ci, et avant que je puisse comprendre ce qui se passe, le client commence sa tirade. Si ce n'était pas pour mon expérience, j'ai arrêté le client à temps, ou je serais certainement entraîné dans le fossé par ses idées. Souvent, plus c'est le cas, plus la cause finale du bogue doit être différente de la pensée du client. Parce qu'un tel client a une certaine capacité d'analyse et une certaine patience de travail pour analyser avec soin, s'il ne trouve pas d'indice sous son opération, il y a une forte probabilité que sa pensée soit dans la mauvaise direction. (Remarquez que non, il s'agit d'un exemple utilisant l'analyse de probabilité). Nous recherchons l'aide des autres afin d'avoir des idées différentes et ne devons pas induire les autres en erreur.
-3- Nous sommes là pour corriger les bugs, pas pour convaincre les autres
En tant que support technique, quelqu'un essaie souvent de me convaincre de son point de vue. Certains ingénieurs estiment que leur code est correct et que leur matériel est correct. Si un bogue survient, il y a un problème avec la puce de votre fournisseur. Trouvez ensuite diverses raisons pour expliquer qu'il s'agit d'un problème de votre puce.
Cela devient persuader les autres.
"J'ai vérifié la configuration ici, ça doit être bon, y a-t-il un bug dans votre puce ?"
J'ai entendu cela plusieurs fois, et chaque fois que je rencontre cette situation, il s'avère que leur propre code est erroné, pas notre puce.
Certaines personnes veulent jeter le blâme et nous lancer des bogues, et dans certains cas, ce sont les caractéristiques des habitudes personnelles et de la personnalité de l'ingénieur. Il n'y en a pas beaucoup, mais chaque entreprise en a quelques-uns. Lorsque nous cherchons de l'aide auprès des autres, nous ne les persuadons pas d'être d'accord avec vos idées, et encore moins de les amener à être d'accord avec vos émotions, afin de gagner du confort. Nous sommes là pour résoudre des problèmes, pour avoir une perspective différente sur le problème. Même si vous pensez que le point de vue de l'autre partie est erroné, vous devez rechercher des preuves basées sur la situation réelle.
Sur la route de DEBUG, tout peut arriver, et le monde réel est tellement bizarre, nous devons donc nous fier aux faits. Ouvrez votre esprit pour obtenir les indices que vous voulez.
Aujourd'hui, ce chapitre a fait un peu grogner, alors c'est parti.
Si vous l'aimez, s'il vous plaît aimez, "regardez" et suivez-le
Bienvenue à partager, laissez plus de gens découvrir "le huitième frère"