La folie est l'incapacité de voir les coutures reliant délire et réalité. Stephen E. King
Après avoir été interviewé à la fin de l'année en tant que chef de projet, j'ai rencontré beaucoup de questions qui peuvent sembler être le dernier non-sens de la part de hr'ov et de la part de spécialistes qualifiés. Bien sûr, chaque entreprise est étrange à sa manière, mais l'objectif de certains problèmes est toujours un mystère pour moi.
Un chef de projet est un spécialiste qui doit toujours être en contexte. Il est impossible de comprendre les objectifs commerciaux et le contexte de leur mise en œuvre sans poser de questions: pourquoi? pourquoi? comment? Lors de l'entretien, l'objectif du manager est de donner une réponse claire à la question posée en entrant dans son contexte. Par conséquent, j'essaie toujours de ne pas prêter attention au «jeu» qui est présent lors des interviews, et de raisonner même sur les questions les plus stupides.
Tous les managers sont bien conscients que l'entretien est une marche d'une heure à travers le champ de mines. Cette déclaration est parfaitement démontrée par l'ancien vélo du manager: «La première entreprise m'a demandé ce que je ferais si l'équipe n'avait pas le temps pour la sortie: est-ce que je demanderais à l'équipe des heures supplémentaires ou est-ce que j'écrirais le code moi-même? J'ai répondu que je m'asseyais pour écrire le code moi-même, et ils m'ont refusé avec motivation: "ce n'est pas accepté avec nous". La deuxième entreprise m'a posé la même question, et j'ai répondu que je demanderais à l'équipe de faire des heures supplémentaires, et le rejet ultérieur de cette entreprise était motivé par le fait qu'ils ne l'ont pas fait. Dans la troisième entreprise, j'ai de nouveau fait face à cette malheureuse question, et la réponse a été la question - comment est-ce habituel pour vous? »
Par conséquent, en particulier pour les lecteurs de Habr, j'ai noté les questions les plus intéressantes à mon avis et j'ai décidé d'analyser les réponses possibles. Les questions seront délirantes et sensées.
1) Vous avez une équipe de développeurs et de testeurs scrum. Les développeurs travaillent, évaluent les tâches dans les points historiques et les testeurs en heures. Le testeur a été chargé de programmer le bouton, mais il ne sait pas comment utiliser les points d'historique. Comment lui expliquer la méthodologie d'évaluation de la tâche qu'il va utiliser?Parfois, la mêlée atteint le point d'absurdité. En répondant à cette question, il convient de noter que dans la mêlée, les équipes sont universelles, mais dans un sens différent du mot. Le contexte dans cette affaire dans son ensemble n'est pas très important. Il vous suffit d'expliquer à l'employé comment les points de l'histoire sont pris en compte. Vous devez reprendre ses tâches précédentes, les écrire sur une feuille de papier et proposer de les comparer à l'échelle de fibonacci, en lui expliquant le concept même de point d'histoire: la quantité de travail * la complexité * les risques. Après cela, le testeur sera en mesure de comparer la tâche de développement du bouton avec ses tâches terminées passées en termes de complexité et, en conséquence, avec la valeur des points d'historique.
2) Que dois-je faire si un employé distant a perdu ses performances?
La question la plus abstraite que vous puissiez poser. La culture et les valeurs de l'entreprise sont principalement responsables du travail confortable de l'éloigné. Si une entreprise a une communication de haute qualité, par exemple, des discussions conjointes actives sur les tâches et les problèmes dans un messager pratique permettent à un employé distant de ressentir leur valeur et leur entrée dans le travail d'une équipe et d'une entreprise, lorsque la communication est limitée à une lettre par jour aller-retour, une personne ne se sent pas connectée avec ses collègues . De plus, lorsque les tâches s'envolent simplement vers le maître et sont mises en vente sans rétroaction et ne marquent pas le succès de chaque employé pendant des mois, l'employé commence à se sentir isolé de l'équipe, il met sa force et ses émotions dans son travail, mais ne les reçoit pas en réponse, À cet égard, l'épuisement émotionnel commence même sans travail excessif. Par conséquent, il est nécessaire de se poser la question non pas pourquoi l'employé est mauvais, mais ce qui atténue sa motivation à travailler sur ses tâches, puis à les résoudre.
3) Un employé est en retard tous les jours lors d'une réunion quotidienne, que dois-je faire?"Il ne partage pas les valeurs de l'équipe et de l'entreprise, pourquoi avons-nous besoin d'un tel employé?" - Une fois que j'ai entendu une telle phrase de hr, et j'ai pensé, cela vaut-il vraiment la peine de garder une personne qui habite à 80 kilomètres du bureau, ils ne lui donnent pas de télécommande, et le matin il est constamment en retard pour les embouteillages à 9 heures?
Quand je réponds, je veux dire que vous, en tant que Scrum Master ou chef de projet, avez essayé d'expliquer à deux reprises à l'employé l'importance des rallyes quotidiens pour le mouvement global de l'équipe vers l'objectif dans un flux continu.
Les rallyes, en plus des règles internes pour une conduite efficace, devraient également avoir des règles pour leur nomination pour leur visite confortable:
- Découvrez auprès des participants du rallye un moment commode pour tout le monde, peut-être que quelqu'un a un risque élevé d'être en retard de 10 à 15 minutes, pendant lesquelles le rallye se terminera, ou peut-être que les participants au rallye ont des fuseaux horaires différents et que quelqu'un aura votre temps à 9h00, heure de Moscou, 5 heures du matin;
- Préparez un lieu pour les rassemblements afin que les membres de l'équipe ne se détachent pas des réunions où ils doivent crier pour s'entendre au milieu de l'espace ouvert;
Toutes les personnes sont différentes - c'est un truisme. Quelqu'un est moins organisé, encore plus, si toutes les conditions pour assister à des réunions confortables sont réunies, mais qu'un employé séparé, légèrement organisé ne cherche toujours pas à arriver à l'heure à la réunion, des déclencheurs non violents peuvent être introduits pour augmenter la motivation d'un tel employé, par exemple:
- Donner un peu de dopamine au début du rallye en racontant une réalisation de l'entreprise ou du département, en félicitant quelqu'un pour la réalisation ou les vacances, de bonnes nouvelles dans l'industrie. Les jours aléatoires, vous pouvez mettre un petit gâteau sur la table au début de la réunion (et pourquoi pas?);
- Jouez au jeu "qui n'a pas eu le temps - il était en retard". Qui est en retard - qui mène la réunion note les 2 réunions suivantes, par exemple. Cela vous permet d'apporter un sentiment de malice comique au début de la réunion, et de confirmer à ceux qui sont arrivés à l'heure que leur arrivée ponctuelle est le bon comportement dans l'équipe et l'entreprise.
- La principale chose à laquelle vous ne devriez pas recourir est peut-être les amendes financières. Selon la législation du travail de la Fédération de Russie, vous ne pouvez pas effectuer de déduction sur le salaire et la composante motivationnelle est, en règle générale, suffisamment faible pour «frapper» la poche de l'employé et, par conséquent, le motiver.
4) Différence entre cascade avec onde libre et mêlée?Travaillant constamment avec des méthodologies, il n'est pas difficile de répondre à cette question. Waterfall et Scrum concernent les processus. La méthode des ondes libres est une méthode de planification. Par conséquent, nous obtenons une question piège dans laquelle la méthode des vagues incidentes est une condition inutile, et la question est conçue pour votre compréhension claire des méthodologies de cascade et de mêlée. Scrum est un modèle itératif qui vous permet de faire fonctionner un projet jusqu'à ce que vous obteniez la quantité complète d'exigences, au cours de laquelle vous pouvez modifier les exigences du produit, et le processus d'itération se répète. La cascade est une indication claire des besoins futurs en produits et leur déviation rompt les processus. Et vous pouvez tout planifier par la méthode d'approche par vagues. Soit dit en passant, quiconque parle de l'inertie de la cascade, mais même PMBOK n'interdit pas d'utiliser Rolling Wave Planning avec.
5) Lors des rassemblements debout, plusieurs de vos collègues ne parlent pas à l'équipe des succès syndicaux d'hier, mais vous «rendent compte», que dois-je faire?Pour répondre à la question, vous devez vous appliquer la situation si vous ne tombez pas dans une telle situation. Pour résoudre le problème, vous pouvez déplacer l'attention. Si votre collègue parle d'hier, regardez simplement les autres membres de l'équipe et votre collègue déplacera sans le savoir son attention sur celle que vous regardez. De plus, chaque réunion peut changer son emplacement entre collègues.
6) Supposons que l'employé ait un manager + un supérieur hiérarchique + 2 autres managers d'autres projets (l'employé travaille sur plusieurs projets en même temps), et que deux ou trois de ses managers lui confient des tâches urgentes ponctuelles, par quoi commencer?
Une question de la catégorie d'un problème mathématique: "Vasya a acheté 1000 bananes ...". Pourquoi?
Avec de telles hiérarchies dans l'entreprise, les désaccords entre la composante managériale sont inévitables, le développeur ne doit pas se livrer à de telles situations et se lancer dans un démontage indépendant entre 10 managers, dont la tâche est plus prioritaire, pour cela il y a un manager de son équipe ou un supérieur immédiat.
7) La différence entre le chef d'équipe et le chef d'équipe?De toute évidence, le leader technique est le spécialiste technique le plus puissant. Avec un chef d'équipe, c'est de plus en plus difficile dès lors que le poste de chef d'équipe n'est pas interprété d'entreprise à entreprise. C'est peut-être l'une des spécialités les plus subjectives de l'informatique. Supposons qu'un développeur vienne pour une entrevue et qu'ils lui demandent: «Que pensez-vous, que fait l'équipe principale?» Et le chef du développeur au travail précédent, non seulement a envoyé l'équipe et dans ces parties était un spécialiste cool, mais a également réussi à servir la machine à café et à dessiner pour le chef de projet de la feuille de route. Qui ne demande pas - chacun a sa propre interprétation. La seule bonne réponse qui puisse être donnée à cette question est: "Montrez-moi vos descriptions de travail pour le chef d'équipe et le chef d'équipe, et je vous dirai quelle est la différence."
8) Comment expliquer aux développeurs la valeur des points de construction?Quiconque dit n'importe quoi, mais pour les développeurs, les valeurs principales des points de construction sont la facilité de calcul et l'inclusion des risques dans cette évaluation, par opposition à une évaluation horaire. Lors de l'évaluation avec des points de construction, le développeur n'a pas à assumer l'obligation de terminer la tâche, par exemple, en 2 heures, de sorte qu'immédiatement après l'expiration du temps, il commence à tirer avec la demande du résultat. Le temps investi dans l'évaluation pour résoudre les problèmes qui peuvent survenir vous permet de travailler dans un mode confortable sans stress inutile et visites constantes du manager avec l'exigence de remettre la tâche.
9) Comment expliquer la valeur de Scrum aux développeurs?En tant qu'ancien développeur, je peux écrire toute une ode à l'approche Agile, y compris le framework SCRUM, car la vie des membres de l'équipe devient beaucoup plus facile, prenons quelques points:
- Une présence rare exceptionnelle de gestion directive et uniquement en situation critique. Autrement dit, toutes les tâches sont planifiées pour le sprint à venir, et en théorie, personne ne peut les changer, dans la pratique, la force majeure se produit parfois, mais personne n'est à l'abri de cela.
- Responsabilité collective, l'équipe scrum ne pourra pas transférer la responsabilité de la qualité des produits à un participant individuel.
- Le propriétaire du produit priorise uniquement les tâches dans le backlog, mais ne gère pas les tâches de l'équipe au sens classique de ces mots. L'équipe, en collaboration avec le propriétaire du produit, décide elle-même des tâches que le prochain sprint prendra.
Vous pouvez écrire beaucoup de points sur la valeur de scram, si les points principaux n'ont pas convaincu le développeur de votre équipe, alors vous pouvez recourir à l'opinion d'autres collègues sur cette approche, par exemple, l'un de mes anciens collègues a répondu à cette question:
«Dans les commandes Scrum, les processus sont débogués. Vous avez un plan de sprint et, en règle générale, il n'y a pas de push-ins de directive urgents du formulaire: "tout laisser tomber, de nouvelles tâches urgentes sont arrivées". L'équipe surveille le calendrier et le développement devient prévisible, vous pouvez planifier. Pour cette raison, les tâches en cours dans le sprint ont peu de verrous. En tant que développeur, je veux que lorsque j'entreprends ma tâche, tout soit prêt: le dos et le design sont dessinés. Pas besoin de courir et de secouer les autres. »
Si la valeur de Scrum n'est toujours pas acceptée, alors la lecture du Scrum Guide sera le dernier recours. Et peut-être que votre équipe Scrum a une mauvaise décision (pensez-y).
En résumé , je veux donner une recommandation aux gestionnaires de toutes les spécialités sur le comportement lors de l'entretien - prendre n'importe quel «jeu» comme un nouveau cas d'analyse, parce que le «jeu» apparaît souvent non seulement dans les affaires mais aussi dans la vie, puis au fil du temps, ce sera pour vous la phrase pertinente est: "Celui qui a travaillé avec le pm ne se moque pas du cirque".
PS Si vous avez des questions intéressantes sur pm, assurez-vous de les laisser dans les commentaires!