Du coup, on se rend compte que Jira est devenue une décharge. Chaque deuxième RP configurait Jira car c'était plus pratique pour lui de façon incontrôlable. Et lorsque le projet a commencé à brûler, il a commencé à éteindre les incendies manuellement, laissant les tâches dans le tracker dans un certain état, loin d'être terminées. Si le projet a créé un CI / CD complet, la plupart des tâches de développement seront dans le bon état final, mais le reste ...
Certains projets ont gelé, certains sont tombés, les PR ont été expulsés, mais les tâches à Jira n'ont pas été nettoyées. Vous avez 10 à 20 «projets» en cours et vous devez comprendre rapidement où cela fait le plus mal.
En comparant l'expérience des participants aux rassemblements du KiFB (Francis Bacon Club) pour résoudre ce problème, nous avons présenté cette expérience sous forme enregistrée (pour laquelle merci à tous les participants).
Au début, vous êtes arrivé à une organisation avec plus de 50 projets, où un tracker a été introduit avec un vif désir d'établir une gestion de projet systématique, y compris un reporting transparent.
Une compréhension de l'état du projet, basée sur autre chose que l'opinion du chef de projet (RP), est investie dans l'objectivité.
Pourquoi Les RP, comme la plupart des gens, ont l'habitude d'être battus pour des erreurs. Que fait RP? Cache ses erreurs jusqu'à ce qu'il soit trop tard.
Certains rapports sont fournis par la direction financière et juridique. Paiements, contrats, dépenses, actes, etc. Mais ces fonds sont peu utiles pour le diagnostic précoce des problèmes si des problèmes surviennent dans le processus de travail lui-même. Si le workflow est contrôlé via le tracker de tâches, il est possible d'en obtenir des informations.
(Mais bien sûr, cela fonctionne si un membre du RP lit ces rapports, tire des conclusions et prend des décisions dont il est responsable).
Pourquoi ai-je besoin de rapports
Rapport non nécessaire pour le rapport
Tiré du film "The Pentagon Wars". L'auditeur a apporté des rapports. TOUS les rapports.
Un gestionnaire confronté à une masse de données dans une masse de rapports peut tomber dans la stupeur. (Forme de grève: si vous voulez des rapports - obtenez des rapports).
L'entreprise reçoit de l'argent en effectuant des tâches.
Les rapports devraient montrer principalement le flux entrant d'argent futur, le capital associé, le taux de génération de bénéfices et les dépenses d'exploitation. Si le suivi est utilisé pour gérer les changements, c'est également le taux de changement.
Il existe différents types d'activités (se déroulant conjointement et se complétant): conception, processus, organisation et recherche, dont l'analyse varie quelque peu.
Activités du projet
Dans les projets à coût fixe, il est important de suivre le taux de combustion d'un travail. Si le travail est démarré en tant que tâches dans Jira, les rapports (que nous ne traiterons pas dans cet article) peuvent vous aider. Une autre façon courante consiste à suivre l'état d'un projet à l'aide d'un diagramme de Gantt, ainsi qu'un fait de plan budgétaire (hélas, les tâches dans Jira sont souvent oubliées de fermer).
La recherche
L'activité de recherche ne nécessite pas la solution de toutes les tâches assignées d'une part, d'autre part, les tâches résolues ne génèrent généralement pas de revenus. Les organisations pour lesquelles ce n'est pas l'activité principale mènent des recherches en petites équipes et en cycles courts, dans lesquelles la gestion est effectuée «sur les doigts» du résultat. Les rapports Jira aident peu à la gestion.
Activités de processus
Considérez l'activité de processus - c'est l'exécution du flux entrant de tâches avec un paiement lié à leur mise en œuvre, tandis que les tâches arrivent constamment avec une certaine régularité (en d'autres termes, il n'y a pas de portée fixe). Par exemple, des améliorations au système informatique. Dans ce cas, les rapports peuvent refléter directement l'état du processus.
La tâche entrante est l'argent futur. Tâche suspendue = suspendre de l'argent. Un problème pourri (dont on n'a plus besoin) = perte d'argent. La tâche pour laquelle le travail a été effectué, mais qui n'est pas clôturée = capital associé, qui peut être rejeté si la tâche va mal.
Quel est votre chiffre d'affaires futur? Ce sont de nouvelles tâches, avec une évaluation convenue avec le client. Mais pour voir cela, vous devez nettoyer les scories - tâches obsolètes et non pertinentes.
Quel est le capital associé? Dans les prix de vente, ce sont des tâches qui ont été mises en œuvre et non terminées. Dans les prix de revient, il s'agit des coûts de main-d'œuvre pour de telles tâches en heures ou en valeur de paie. Moins de scories.
Quel est le taux de génération de revenus? Le montant d'argent pour résoudre le problème dans le sprint moins le coût de possession de l'équipe. Mais pour cela il faut que les tâches changent de statut + les gens notent le temps passé sur le projet. Cependant, avec ces indicateurs de problèmes, en règle générale, le moins se pose.
L'activité organisationnelle est avant tout une activité de changement.
À quelle vitesse changez-vous? Vous avez le temps de changer? C'est la vitesse des tâches organisationnelles et le taux d'accumulation de nouvelles tâches. Et des rapports sur les tâches qui pesaient sur les employés, vous permettant de vous souvenir de mettre en œuvre les décisions prises.
Le chemin supplémentaire vers le Lean est soutenu par des rapports plus complexes (qui n'ont pas été très abordés lors des rassemblements et ne signent pas en détail).
Quelles idées me viennent à l'esprit:
- Perte de temps due à l'attente. Le rapport entre le temps passé entre l'embauche et la mise en œuvre. Délai d'expiration du backlog.
- Les pertes dues au transport inutile. Le nombre de retours sur le cycle de vie avec le calcul de la perte de temps d'attente en traitement
- Pertes dues à des étapes de traitement inutiles. Temps d'arrêt dû à des étapes inutiles dans la coordination des tâches avec les superviseurs ou les superviseurs.
- Pertes dues à des stocks excédentaires. Temps d'arrêt pour les employés non chargés de formation, de relations publiques ou de prévente
- Pertes dues à des mouvements inutiles. Perte de temps pour organiser des réunions, trouver des contacts, attendre la compilation du code et exécuter des tests unitaires et autres.
- Pertes dues à la libération de produits défectueux. Le ratio d'erreurs trouvées dans la bataille contre celles trouvées lors du test. La quantité de travail pour corriger les erreurs. La quantité de travail sur les modifications dues à une mauvaise mise en scène.
- Pertes de surproduction. Implémentation de fonctionnalités qui n'ont pas affecté les performances de l'entreprise. Pertes pour tester des fonctionnalités non critiques ou non affectées. Prise en charge des navigateurs obsolètes ou de leurs versions.
Mais avant cela, vous devez nettoyer le tracker des scories.
Nous nettoyons Jira
Étape 1. Nous ne configurons rien
Ne modifiez pas le flux de travail, les statuts, les résolutions. Bien qu'il soit inhabituel de traiter des statuts inhabituels, ce sont des données dans lesquelles les gens ont investi un certain sens.
Étape 2. Nous supprimons les anciens projets
Rapport au format (Projet, Dernière date du dernier changement d'état de la tâche).
Les projets pour lesquels il n'y a pas eu de mouvements sont candidats au transfert aux archives.
Si le responsable du projet travaille toujours, il dira le statut, sinon, la quête de la fin commence.
Nous transférons les tâches des projets d'archivage à l'état final avec ne sera pas corrigé. Il y a des projets gelés. Le statut de ces tâches se traduit par figé.
Étape 3. Nous supprimons les anciennes tâches
Rapport sur les tâches non fermées avec le dernier changement de statut inférieur à X (deux ans de plus que suffisant. Mais généralement, si la tâche se bloque pendant 90 jours - elle «va mal») jours, regroupés par cessionnaire. Très probablement, ils sont pourris, dira le responsable (s'il est nommé et non révoqué).
Étape 4. Supprimez les types de tâches inutiles
Un rapport de la répartition des tâches non fermées par type de tâche pour supprimer les types inutiles.
Étape 6. Nous analysons les tâches des licenciés
Nous distinguons les tâches avec des artistes licenciés.
Il est particulièrement intéressant d'examiner les tâches des employés mis à pied par leurs supérieurs. Le chef de l'employé a permis la «vidange» du capital associé du temps consacré à la tâche et n'a pas organisé l'achèvement de la tâche.
Nous inscrivons dans le règlement sur le licenciement l'obligation de l'emporter / de clore les tâches non pertinentes.
Étape 5. Recherchez et analysez le plus grand tas
Rapport sur les statuts des tâches non fermées. Nous identifions dans quel état le plus de tâches.
Si le statut est une tâche en cours, nous construisons un rapport sur la répartition des tâches dans ce statut par les interprètes. Nous distinguons les tâches sans exécuteur désigné, nous examinons les tâches par des exécuteurs «en direct». Sur certains artistes, 2000 tâches se sont accumulées. Hmm ...
Étape 7. Nous normalisons les statuts, les résolutions, les cycles de vie
Une occasion de regarder également n'importe quel projet. Nous rencontrons et brisons la résistance du RP. Hélas, les gens n'aiment pas penser à leur interchangeabilité, un argument typique: "Je suis unique dans la gestion d'un projet, j'ai besoin d'un cycle de vie unique."
Étape 8. Nous recherchons les projets les plus problématiques. Nous regardons les rapports de combustion
Jira - il peut y avoir deux types de projets
- Projets avec une étendue de tâches connue (cela arrive) où les rapports de combustion sont applicables. Cela arrive parfois.
- Processus: traitement des tâches continues
Les projetsSi le pool de tâches est démarré, nous examinons les prévisions d'achèvement et prenons des mesures si les prévisions ne sont pas rassurantes.
Les processusNous examinons les problèmes résolus par rapport aux tâches entrantes.
Les tâches divisées sont divisées en externes et internes (formation, refactoring, etc.), nous affichons uniquement les externes sur le graphique.
Comment lire les graphiques
Il existe trois graphiques conditionnels:
La réalité de l'informatique est que le travail impliqué dans la libération des tâches a une répartition statistique importante (à moins bien sûr qu'il s'agisse de tâches telles que l'octroi de droits).
Par conséquent, pour garantir le SLA de support nécessaire, les ressources doivent être planifiées avec une marge, sinon cela entraînera l'accumulation de tâches dans les tampons de tâches entrants, ce qui rendra les délais irrecevables. Les gens ne seront pas toujours occupés avec les tâches entrantes, la formation ou tout autre travail non essentiel pendant les pauses.
Dans le processus de développement de produits, ils essaient d'empêcher les développeurs de s'arrêter pour assurer une vitesse de développement maximale = faire de l'argent. Pour ce faire, vous devez toujours disposer d'une réserve de tâches dans le backlog, ce qui signifie qu'une partie de la tâche ne sera le plus souvent pas effectuée, et comme les tâches perdent progressivement de leur pertinence, cela signifie que les tâches ne seront jamais effectuées.
Option A
C'est normal s'il s'agit d'une implémentation de fonctionnalités. Plus de fonctionnalités saisissent l'entrée que l'équipe ne peut en digérer.
S'il s'agit de support (administration et correction de bugs), la situation est mauvaise. Plus il y a d'erreurs, plus leur correction est lente. Plus la correction est lente, plus les erreurs s'accumulent. Quelque chose tourne sous le canon de poudre à canon. Tick-to-tick-to-tick ....
Option B
Si une équipe effectue exactement autant de tâches que dans le backlog, cela signifie que
- soit l'arriéré est conservé dans un autre projet / lieu et, par conséquent, vous ne voyez pas de chiffre d'affaires futur dans les rapports et ne pouvez pas prendre une décision basée sur des rapports sur l'importance d'augmenter la taille de l'équipe,
- ou les gens s'inventent des tâches au moment des temps d'arrêt (sur les sensations et l'intuition, sans custdev, analyse de marché, etc.); combien de telles tâches ne sont pas claires et cela est alarmant (et s'il y en a déjà 90%),
- ou les rapports sont truqués.
Option C
OK si c'est du support. L'équipe doit avoir des temps d'arrêt afin de pouvoir résoudre rapidement et efficacement les problèmes et les tâches.
S'il s'agit d'une implémentation de fonctionnalités, la situation n'est généralement pas normale. Une fois l'arriéré de tâches accumulé, qui comprend plus vite que les nouvelles. Pourquoi est-ce possible?
- Par exemple, l'équipe a considérablement augmenté et elle analyse la dette, mais en même temps, les besoins de l'entreprise n'augmentent plus. L'entreprise ne réagit pas (n'a pas réussi à réagir) à la croissance des opportunités ou pire, le produit a pris sa place et a cessé de croître.
- Ou le produit stagne et ne nécessite pas de développement.
- Ou le marketing a cessé de créer de nouvelles opportunités.
Étape de sécurité d'accès à l'étape
Nous attrapons des tâches avec des liens sur Internet vers Google Dox. Tous les documents doivent être à l'intérieur du périmètre, nous fixons la tâche de transfert des matériaux vers l'intérieur
Étape de contrôle de l'analyste
Les étapes se font où?
Option A. En plein dans la graisse.
Option B. Chez l'employé personnel de Google Doks.
Option correcte: Un changement de fonctionnalité devrait le plus souvent être accompagné d'un changement dans la documentation technique et de travail dans Confluence. Comment le contrôler?
Nous lions la page de relevé à la tâche en gras (il suffit d'insérer le lien, cela conduira automatiquement à la création de liens bidirectionnels).
Nous construisons un rapport sur les changements de page en confluence et le résumons sur l'analyse avec les rapports Jira sur les améliorations des coûts de main-d'œuvre. Toutes les améliorations avec des coûts de main-d'œuvre importants doivent être corrélées avec les modifications apportées aux articles.
Remerciements
Merci aux membres actifs du KiFB pour le matériel préparé et l'organisation de la discussion, et à toutes les personnes qui ont participé à la discussion.