Dépendances et retards

Annuler une tâche ne signifie pas livrer ce que son successeur attend

Pour qui : Un travail abandonné est marqué terminé pour nettoyer le plan et la tâche dépendante paraît alors autorisée.

Recherche documentaire le 8 novembre 2026 ; aucune application testée.

Notre avis

Conserver un état d’annulation distinct et faire requalifier la condition de démarrage du successeur avant de le libérer.

Dans l’ordre

  1. Terminé peut déclencher un travail qui attend un résultat
  2. Le fichier absent doit rester visible dans le test
  3. Comparer le démarrage de B après livraison de A et après annulation de A sans le résultat attendu.

Pourquoi

  • Une annulation ne produit pas le livrable attendu par le successeur ; distinguer les états empêche un démarrage autorisé à tort.

Ce qui change le choix

Si le besoin de B disparaît avec A, annuler aussi B peut être la bonne décision ; ce n’est pas une livraison fictive.

Terminé peut déclencher un travail qui attend un résultat

Une tâche abandonnée n’a pas forcément produit ce que la suivante attend. Nous conserverions un état d’annulation et ferions requalifier la condition de démarrage. Marquer terminé pour nettoyer la vue peut envoyer un signal d’exécution faux au successeur ou à une règle.

Décrivez la condition concrète : fichier reçu, accès disponible, décision obtenue. Le travail suivant peut parfois continuer sans l’ancienne tâche, mais cette exception mérite une décision. Il ne faut pas la déduire du seul changement de couleur ou d’état.

Le fichier absent doit rester visible dans le test

Dans un projet fictif, A produit un fichier nécessaire à B. Terminez A avec un fichier, puis recommencez dans une autre copie en annulant A sans fichier. Comparez notification, état et possibilité de démarrer B. Le protocole attendu doit signaler la différence, ou la procédure manuelle doit la traiter explicitement.

Si le besoin de B disparaît aussi, annuler B peut être la bonne décision. Si un autre fichier le remplace, liez cette nouvelle condition. Nous préférerions un arbitrage visible à un achèvement fictif qui rend l’ensemble du plan plus vert.

Les dépendances Asana décrites relient des tâches bloquantes et bloquées ; l’achèvement d’un antécédent peut notifier le responsable du successeur.

Limites

Analyse documentaire et méthode éditoriale. Les protocoles sont proposés, pas exécutés sur les logiciels. Les exemples chiffrés sont fictifs ; les fonctions dépendent du produit, du forfait, des droits et de la configuration.

Prochaine action

Comparer le démarrage de B après livraison de A et après annulation de A sans le résultat attendu.

Preuves et sources

Ce qui relève d’un fait lu, d’une déclaration, de notre calcul, de notre méthode ou de notre avis. Notre méthode

  • Déclaration de l’éditeur. Les dépendances Asana décrites relient des tâches bloquantes et bloquées ; l’achèvement d’un antécédent peut notifier le responsable du successeur.

    Relevé du 8 novembre 2026. Édition ou périmètre : Documentation publique du 8 novembre 2026 ; produit et périmètre nommés dans le constat.

  • Notre méthode. Créer A produit un fichier attendu par B ; terminer A puis, dans une copie, annuler A sans fichier ; comparer déclenchement et notification de B, puis fixer l’exception autorisée.

    Daté du 8 novembre 2026. Édition ou périmètre : Protocole éditorial proposé ; aucune observation de compte client.