Framework d'entretien

Root Cause AnalysisIssue Tree + 5 Whys

Questions d'exécution, d'analyse et de diagnostic

Quand y recourir

Tout « la métrique X a chuté ou bondi », revue d'incident, ou « pourquoi le tunnel est-il cassé ».

2 672 questions de ce type, réparties sur 1 411 des 1 964 entreprises de notre banque d'entretiens.

Qu'est-ce que l'analyse de cause racine en entretien ?

L'analyse de cause racine répond à "la métrique X a bougé, pourquoi ?" en structurant la recherche au lieu de deviner. Vous énoncez le problème précisément, vous segmentez, vous construisez un arbre MECE dont les branches ne se recouvrent pas, vous posez cinq pourquoi le long de chaque branche vivante, puis vous nommez une hypothèse testable et le test qui la confirmerait. Le framework existe pour vous empêcher de deviner dès la première phrase.

Regarder l'explication de Root Cause Analysis

Trois minutes : la même réponse faible réécrite en réponse solide, et les chiffres de notre base sur qui y est vraiment confronté.

L'analyse de cause racine répond à "la métrique X a bougé, pourquoi ?" en structurant la recherche au lieu de deviner. Soixante-dix-neuf pour cent des entreprises de notre base posent une question de type root-cause. Comptage sur 100 000+ vraies questions d'entretien de 1 800+ entreprises, par type de question. Mesuré, pas estimé. Source : la base de questions d'entretien JobMentis.

Les étapes de Root Cause Analysis

Chaque étape est un mouvement, et l'ordre compte. Brûler une étape est ce qui rend une réponse désordonnée, même quand le fond est bon.

  1. 1

    Énoncer le problème avec précision

    Qu'est-ce qui a changé, quand, de combien, pour qui ?

  2. 2

    Segmenter

    Interne contre externe, géographie, plateforme, cohorte, étape du tunnel.

  3. 3

    Construire un arbre MECE

    Les branches de premier niveau doivent être mutuellement exclusives et collectivement exhaustives.

  4. 4

    Poser cinq pourquoi sur chaque branche vivante

    Creusez jusqu'à une hypothèse testable.

  5. 5

    Prioriser et tester

    Choisissez l'hypothèse à plus fort impact, proposez le test qui la confirme.

Une réponse Root Cause Analysis faible, réécrite

L'acronyme est sur tous les blogs d'entretien. Le contraste noté, non : c'est la partie à relire deux fois.

Question

“Le taux d'ouverture des notifications a chuté de 8 % d'une semaine sur l'autre. Débuggez.”

Réponse faible

C'est peut-être que le texte des notifications est devenu banal, ou que les gens saturent. J'essaierais de changer le texte pour voir si le taux d'ouverture remonte. On pourrait aussi les envoyer à une meilleure heure.

Réponse solide

Énoncer précisément d'abord : taux d'ouverture, pas envois, en baisse relative de 8 % d'une semaine sur l'autre, à partir de quand exactement, et pour qui. Puis segmenter avant d'émettre une hypothèse : interne contre externe, iOS contre Android, par langue, par type de notification, par ancienneté de cohorte. Disons que cela ressort Android uniquement, à partir de mardi. Maintenant un arbre MECE à trois branches : moins de notifications délivrées, les mêmes notifications moins ouvertes, ou la mesure a changé. Cinq pourquoi le long de "délivrées" : une version de l'app est-elle sortie mardi, a-t-elle changé le canal FCM, ce canal était-il silencieux par défaut ? Voilà une hypothèse testable. Le test consiste à comparer les accusés de réception avant et après la sortie sur Android, ce qui la confirme ou l'élimine en une heure.

Pourquoi la version forte gagne: La réponse forte segmente avant d'émettre une hypothèse, garde des branches mutuellement exclusives pour qu'un utilisateur ne puisse pas être dans deux à la fois, et termine par un test concret exécutable aujourd'hui. La réponse faible devine une cause dès sa première phrase et propose un correctif pour celle-ci, exactement ce que le framework existe pour empêcher.

Ce qui aplatit une réponse Root Cause Analysis

Les réflexes qui transforment un bon framework en réponse oubliable.

  • Deviner la cause avant de segmenter.

  • Des branches qui se recouvrent, par exemple « utilisateurs iOS » contre « utilisateurs payants » : on peut être les deux.

  • Aucun test concret à la fin.

Qui reçoit vraiment des questions Root Cause Analysis

Compté sur l'ensemble des questions de notre banque d'entretiens, pas estimé. Les questions de type Root Cause Analysis ne sont pas réparties uniformément : voici les métiers et les secteurs dont les processus s'y appuient le plus.

Métiers

Secteurs

Entraînez Root Cause Analysis à voix haute, pas dans votre tête

Testez sur cette question

“Le taux d'ouverture des notifications a chuté de 8 % d'une semaine sur l'autre. Débuggez.”

Lire un framework crée une fausse confiance. Le simulateur vocal pose une question de type Root Cause Analysis, écoute la réponse entière et note la structure, le signal et la longueur, pour que vous repériez où votre récit dérive avant qu'un recruteur ne le fasse.

Lancer un entretien blanc

Les entreprises qui posent des questions Root Cause Analysis

Ces entreprises posent des questions de type Root Cause Analysis dans leur processus. Chaque banque contient les vraies questions et la grille sur laquelle nous notons.

Root Cause Analysis : questions fréquentes

Quelles sont les étapes de l'analyse de cause racine en entretien ?

Énoncer le problème précisément (ce qui a changé, quand, de combien, pour qui), le segmenter (plateforme, géographie, cohorte, étape du tunnel), construire un arbre MECE, poser cinq pourquoi le long de chaque branche vivante jusqu'à une hypothèse testable, puis prioriser une hypothèse et proposer le test qui la confirme.

Que signifie MECE ?

MECE signifie mutuellement exclusif et collectivement exhaustif. Chaque branche de votre arbre doit être séparée des autres, et ensemble elles doivent couvrir toutes les possibilités. "Utilisateurs iOS" et "utilisateurs payants" n'est pas MECE, car une personne peut être les deux, et des branches qui se recouvrent rendent l'analyse impossible à clore.

Quelle est l'erreur la plus courante en analyse de cause racine ?

Deviner la cause avant de segmenter. Une fois un suspect nommé dès la première phrase, le reste de la réponse devient une recherche de preuves qui l'étayent. Les deux autres sont des branches qui se recouvrent, et une conclusion sans test concret.

Quels métiers reçoivent des questions de cause racine ?

Dans notre banque d'entretiens, les ingénieurs logiciels font face au plus grand nombre de questions de type cause racine et debugging, suivis des product managers puis des commerciaux. C'est une technique issue du conseil, mais tout métier censé expliquer pourquoi un chiffre a bougé la rencontrera.

Les six autres frameworks

Root Cause Analysis n'est qu'un framework sur sept. Si la question que vous préparez n'a pas cette forme, l'un de ceux-ci correspond.