Métriques - elles sont comme des feutres, chacune à leur goût. Sans métrique, l'existence d'une entreprise rentable en tant que telle est impossible, ils nous entourent constamment, c'est désagréable, mais un axiome. Pour certains, la métrique est le plan de vente du mois, pour d'autres c'est l'achèvement de la commande avant l'échéance convenue, et pour d'autres le nombre d'heures travaillées.
Il n'y a pas de «photos d'attraction» appropriées à ce sujet, alors gardez un chatPour une raison quelconque, le mot «métriques» dans le domaine informatique est étroitement associé à ces «excellents» dans ses pratiques de stupidité, telles que le comptage de lignes de code écrites ou la tâche fermée. Nous pouvons dire avec confiance que ce sont les «outils de gestion» de contrôle les plus inutiles et les plus édentés. En fait, les mesures adéquates ne sont, tout à fait conditionnellement, mais toujours, que de deux types: les mesures pour le projet et / ou le travail, dont le résultat et le temps d'exécution sont clairs et prévisibles dans le temps, et vice versa, les mesures pour le projet et / ou le travail, le résultat et dont le temps d'exécution est physiquement impossible à prévoir. Pour le premier type, des métriques du résultat sont définies, et pour le second - la distance, en d'autres termes, le temps travaillé.
Le premier type de métriques "par résultat"
Il n'existe pas de recette universelle pour définir des paramètres pour un employé - il s'agit toujours d'un phénomène situationnel. La mesure de l'employé est toujours formée d'une réponse simple à la question suivante: peut-on prédire clairement le résultat final et, par conséquent, le temps de travail à courte ou moyenne distance?
Examinons la situation des indépendants. Le plus souvent, les clients établissent des relations avec les artistes interprètes ou exécutants sur la base du paiement de la quantité de travail effectuée. Autrement dit, il y a un budget pour le projet, et la ligne rouge et le délai de livraison sont convenus lors de ce budget de négociation. C'est ainsi que travaillent les concepteurs, les concepteurs de mise en page et un certain nombre de développeurs. Le plus souvent, le budget ne bouge pas, c'est-à-dire que le «temps d'exécution» est la partie mobile.
Mais il est toujours prévisible de plus / moins, c'est-à-dire que le client comprend clairement combien de temps «approximativement» sera consacré à l'exécution de sa commande. Sur la base de ce chiffre, un budget est alloué, après quoi un artiste approprié est recherché.
En général, le principe «peu nous importe combien de temps vous passez à terminer une commande, faites-le bien et dans les délais qui nous conviennent» est clairement prêché dans l'environnement indépendant. Cela supprime beaucoup de questions sur la surveillance du travail d'un pigiste ou d'un employé temporaire embauché, élimine la nécessité de lui verser trois, quatre, dix fois le «salaire», etc. Il y a une tranche de prépaiement, il y a une clôture du compte final pré-convenu.
Une approche similaire s'est répandue dans les petites et moyennes entreprises, où les gens semblent travailler, et à plein temps, mais l'entreprise vit dans un état de concurrence féroce et sur de courtes distances lorsque le résultat est nécessaire à une date précise. Avec des «efforts fous», vous pouvez dessiner un schéma synoptique aussi grossier qui vous guide lorsque vous décidez:
Qu'en est-il des taux horaires UpWork et des autres modèles de temps indépendants?
Peut-être que cette question est née chez vous, le lecteur, au début de l'article, mais nous n'y sommes arrivés que maintenant. Plus précisément, aux réponses, car il y en a plusieurs.
Premièrement: le loueur est habitué au contrôle, car le taux horaire dans 50% des cas implique un tracker, et dans 100% - des rapports périodiques avec un audit du travail effectué. C'est-à-dire que le client transfère une partie des fonctions de gestion à l'entrepreneur lui-même, qui se présente lui-même.
Deuxièmement: l'entreprise a besoin de contrôler le processus de développement, car elle n'a qu'une seule tentative. Si le projet s'étend sur plus de quelques semaines, le client doit comprendre «dans quelle lumière» est le travail. Le plus souvent, le budget n'est alloué qu'une seule fois pour des commandes aussi massives et il n'y a qu'une seule tentative. En fait, il y avait une fois des entreprises sur le marché qui n'exigeaient pas de rapports périodiques et parfois difficiles de la part des exécuteurs sur de grands projets, mais la même chose leur arrivait que pour les éléphants à petites oreilles - ils s'éteignaient (éléphants de surchauffe, mais entreprises - en raison des délais).
Le deuxième type de métriques est "dans le temps"
Mais tout devient beaucoup, beaucoup plus compliqué si nous commençons à parler d'un grand projet, dont les délais de livraison vont de «d'un à trois ans» à «c'est un développement éternel». Dans le cas du «développement éternel», il est presque impossible de prédire le temps pour obtenir le résultat final raisons suivantes:
- non pas une seule personne travaille sur le projet, mais même plusieurs équipes;
- chaque équipe "dans les directions" compte de deux à trois à plusieurs dizaines d'employés;
- quand le travail sur le projet se termine, personne ne sait.
Dans de telles conditions, il est facile de se perdre et de disperser des poires bien connues avec un objet connu. Mais comme l'entreprise n'est pas impliquée dans le travail caritatif, il est nécessaire de passer des métriques «par résultats» à une catégorie plus complexe de métriques «par temps».
L'exemple le plus simple et le plus logique de travailler «à temps» est le bureau habituel à temps plein dans des entreprises de 30 à 50 personnes dans le service de développement. Dans ces conditions, l'entreprise «à terre» est d'accord avec un employé potentiel, c'est-à-dire au stade de l'entretien, non pas sur le moment de l'achèvement du projet, mais sur le coût d'une heure de travail sur la base d'une semaine de travail de 40 heures selon le Code du travail. Pour nous, cela ressemble à un salaire.
En même temps, il faut bien comprendre que les affaires ne sont pas des imbéciles. La taille de la demande de propositions (plus précisément, sa réduction) comprend des crises de personnalité, des tremblements au bureau, des pauses de fumée, 20 à 30 minutes supplémentaires pour le déjeuner (c'est-à-dire une heure et demie au lieu d'une heure) et juste la procrastination sur YouTube. Certaines entreprises peuvent se permettre ces coûts, car l'entreprise est actuellement rentable et il peut se permettre une version «légère» du contrôle en configurant simplement des tâches à court terme avec des délais flous auxquels participent les cadres moyens et intermédiaires.
Mais si l'entreprise est à faible marge ou existe dans un environnement Legacy compétitif, alors tout empire. Et c'est là que commence l'enfer uniforme, pour lequel les développeurs n'aiment pas tellement le mot «métrique».
Une référence vraiment serrée au temps travaillé n'est pas une mesure indépendante de l'efficacité, des béquilles sont nécessaires ici
Si une personne est payée non pas pour le résultat, mais pour le temps travaillé, alors comment évaluer son efficacité? Cette question est constamment posée par les entreprises. Il y a plusieurs variables ici:
- Lier la performance de l'équipe à la métrique «résultat» sur une courte distance.
- L'utilisation de métriques plus petites au niveau des tâches et des sprints.
- Construire une structure claire de responsabilité, de termes et de priorités, appelez cela ce que vous voulez, par exemple, «politique de développement».
En fait, l'entreprise est confrontée à une situation où elle semble être passée à un mécanisme plus que compréhensible d '«achat de temps», mais il est toujours nécessaire de contrôler si quelque chose a été reçu pour payer ce temps sous la forme de résultats de travail. C'est-à-dire que notre concept "d'achat d'un résultat" devient une variable intégrée dans le concept d '"achat de temps".
Le plus souvent, il arrive que la direction ne soit pas en mesure de tracer clairement les besoins des entreprises et des employés en même temps, c'est-à-dire de construire un système et une politique d'application de mesures dans lesquelles les deux parties seraient satisfaites de ce qui se passe. Ce que cela signifie: les mesures doivent à la fois répondre aux intérêts de l'entreprise et être compréhensibles et réalisables par les employés.
Ici, nous sommes confrontés à un autre problème: si lors d'un travail «sur commande» à courte distance, la tâche est le plus souvent claire et compréhensible pour toutes les parties, alors lors du développement d'un grand produit, toute la structure est en mouvement constant. Trite: les concurrents ont sorti un nouveau produit ou une nouvelle boîte à outils est apparue, et tous les plans créés avec amour par la direction ont été perdus.
À ce stade, beaucoup dépend de la gestion. Ici, vous pouvez simplement décrire les approches inadéquates et adéquates pour définir des métriques.
Mesures inadéquates:- nombre de lignes de code et commits;
- nombre de tâches closes sans tenir compte de la complexité;
- priver le développeur du droit de vote;
- ignorer la dynamique et les besoins de développement au cours de la période considérée (mesures dépassant le bon sens);
- long processus d'examen des paramètres, manque de flexibilité, ignorance des opinions de développement.
Ici, j'ai décrit une «galère» typique lorsqu'un développeur se transforme d'une personne en une «machine à écrire du code» et ne se soucie pas de la façon dont il gère les tâches / mesures à court terme qui lui viennent d'en haut. Dans ce cas, le développeur perd toute opportunité d'influencer le développement, même s'il voit "l'intérieur" du problème. En même temps, la complexité des tâches n'est pas prise en compte et tout se résume au travail de singe.
Mesures adéquates:- Tenir compte de la complexité de la tâche;
- La capacité de revoir les mesures après coup lorsque des problèmes surviennent;
- Capacité à commenter la tâche;
- Absence de lien étroit avec les indicateurs quantitatifs des lignes de code / nombre de tâches;
- Ignorer la non-conformité partielle avec les métriques, si nécessaire.
Les mesures adéquates sont celles qui ne sont pas clouées au sol et qui peuvent être déplacées. Si une entreprise recherche une efficacité maximale, cette efficacité doit être à tous les niveaux. Il est clair depuis longtemps que le nombre de tâches ou de lignes de code, en fait, ne signifie pas grand-chose, car certaines tâches peuvent avoir un effet décisif sur le produit et des centaines d'autres coûtent.
De plus, une liaison stricte à la conformité avec les métriques est contre-productive: si le développeur sait qu'il aura des «problèmes» du fait qu'il a fermé 19 tâches en une semaine au lieu de 20, alors la qualité de la tâche passe à l'arrière-plan. Et le dernier minimum, 20 tâches, sera placé sur la «décharge», avec des béquilles et des vélos au lieu de vraiment et une fois pour toutes résoudre la tâche.
La rétroaction en tant que partie intégrante du modèle «achat à temps»
En fait, un modèle de développement bien construit, lié au temps de travail, est beaucoup plus compliqué qu'il n'y paraît à première vue. Pour travailler efficacement sur ce modèle, une rétroaction de haute qualité devrait être organisée entre les interprètes et les dirigeants, qui doivent constamment ajuster la «politique du parti» à tous les niveaux. Après tout, une tâche mal posée, c'est-à-dire une métrique formulée, est loin d'être un problème pour les développeurs, bien qu'il soit habituel de pousser ce problème vers les interprètes. Une métrique mal formulée est un problème, uniquement pour la direction qui a confié cette tâche aux entrepreneurs, à condition que le travail des deux parties soit transparent.
C'est la direction qui doit organiser le travail afin que le temps de travail soit dépensé efficacement, c'est-à-dire que les budgets ne soient pas «brûlés», mais en même temps, les développeurs pourraient faire face à leurs tâches sans épuisement total en quelques semaines. Parce que les ressources humaines, bien que vastes, mais pas infinies, surtout quand il s'agit de personnel qualifié.
C'est la présence de commentaires et la responsabilité des décisions prises par la direction qui diffèrent d'une entreprise qui tient un registre détaillé des heures travaillées, d'une "galerie" explicite où les développeurs se retrouvent dans un hachoir à viande sans signification.
Ce sont les retours d'expérience qui permettent à l'entreprise de trouver des goulots d'étranglement dans le développement. Combien de fois avez-vous rencontré une situation où les employés d'un département étouffaient, travaillant pour l'usure, mais n'ont pas reçu de «renforts» sous la forme d'une paire de nouveaux spécialistes qui remplaceraient une épaule et prendraient en charge une partie de la charge? De telles situations surviennent tout le temps précisément en raison du manque de rétroaction de haute qualité entre le développement et la gestion. Au lieu de suivre clairement l'efficacité de l'équipe et de sa charge, le manager met le doigt dans le nez, et quand quelqu'un «tombe en panne», incapable de supporter un tel rythme, tout pousse les développeurs restants. Ne fais pas ça.
Au lieu de la sortie
La pire chose qui puisse arriver dans le processus d'organisation d'un processus de travail est de «déformer» les mécanismes inhérents d'un modèle à un autre. Par exemple, lorsque des échéances strictes sont fixées pour des projets à long terme sans une bonne évaluation de la complexité et des capacités de l'équipe. Ou lorsque, sur des projets et des tâches autosuffisants à court terme, de telles formes de contrôle sont conçues pour être appliquées dans le domaine de la science des fusées, et nous ne parlons que d'une commande de pigiste.
Une compréhension claire de la pertinence de certaines méthodes de travail dans des entreprises de structures et de tailles diverses contribuera à préserver une énorme partie de la santé et du système nerveux lors de la recherche d'emploi. Et plus les développeurs, les gestionnaires et les propriétaires d'entreprises comprennent ces mécanismes, mieux ce sera pour tous les participants du segment informatique.