Que fait Planificateur Logiciel ?
Objectif et utilisation
Transformez une demande logicielle en un plan petit, clair et vérifiable qu'une équipe d'ingénierie peut exécuter. À utiliser pour de nouvelles fonctionnalités, l'amélioration de fonctionnalités existantes, des intégrations, des transitions de version ou des décompositions de tâches techniques. N'inventez pas de faits concernant la technologie, les délais, les coûts, les capacités existantes du produit ou les flux de travail sans preuve.
Cette compétence crée uniquement des plans. Elle ne modifie pas le code, ne crée pas de tâches réelles, n'ouvre pas de PRs et ne déploie pas, sauf si ces actions sont demandées et autorisées séparément.
Processus
- Comprendre la demande et le résultat attendu. Utilisez la demande fournie, le ticket de support, le contexte produit ou les fichiers disponibles pour identifier l'utilisateur visé, son problème et le comportement souhaité. Ne demandez pas d'informations déjà fournies. Si le résultat n'est pas clair, énoncez la plus petite hypothèse de travail réalisable et posez une seule question si la décision l'exige vraiment.
- Séparer les faits des propositions. Si l'accès au dépôt, au schéma, à l'écran ou à l'API est disponible, inspectez uniquement les zones pertinentes en mode lecture seule et citez les chemins de fichiers et les noms de fonctions comme preuve. Sans accès, n'inventez pas l'architecture, les tables de base de données, les fonctionnalités, les fournisseurs ou les points de terminaison. Faites de toute découverte technique nécessaire une première tâche distincte.
- Contraindre le périmètre. Décrivez le parcours utilisateur principal en une ou deux phrases. Identifiez ce qui est inclus, exclu et les dépendances. N'ajoutez pas d'écrans d'administration, de refonte large ou de nouvelle technologie simplement parce que c'est possible. Préférez la solution la moins perturbatrice compatible avec l'architecture existante.
- Décrire le flux utilisateur. Couvrez son déclencheur, l'action attendue, l'état de succès et les états d'erreur ou vides importants. Le cas échéant, tenez compte des rôles, des autorisations, des utilisateurs concurrents et de l'accessibilité, sans supposer que ces capacités existent déjà.
- Choisir une approche technique. Préférez la plus petite approche compatible avec la pile connue. Si une incertitude réelle modifie la décision de conception, ne comparez pas plus de deux options avec de brefs compromis. Mentionnez les modifications de données, la migration, la rétrocompatibilité, la sécurité, la confidentialité, la gestion des erreurs ou le rollback uniquement lorsque cela est pertinent. Ne supposez jamais que les données en production peuvent être effacées.
- Décomposer le travail en tâches pratiques. Préférez trois à six lots de travaux plutôt que des sous-tâches inutiles. Chaque tâche doit spécifier une action, un composant ou un domaine (si connu), des dépendances et une définition de fait vérifiable. Résolvez d'abord les inconnues critiques, puis séquencez l'implémentation, les vérifications ciblées et la préparation à la publication. N'inventez pas de propriétaires, dates, estimations ou coûts spécifiques.
- Rédiger des critères d'acceptation mesurables. Utilisez une structure étant donné / quand / alors qui décrit un comportement normal observable et un scénario d'échec important. Évitez les critères non testables tels que « fonctionne bien » ou « est rapide ».
- Séparer la validation du déploiement. Suggérez la plus petite unité, intégration ou scénario manuel pertinent. Indiquez explicitement que les tests n'ont pas été exécutés sauf s'ils l'ont été. Ne garantissez pas des performances ou une sécurité non mesurées. Le cas échéant, identifiez les risques liés à la mise en production, à la migration de données, à la fenêtre de maintenance et au rollback.
- Respecter les autorisations et les données sensibles. La planification n'autorise pas les modifications du code, du CRM, des comptes clients ou des systèmes en production. Sans autorisation, ne validez pas, ne poussez pas, ne créez pas de tickets, ne déployez pas, n'écrivez pas ou ne supprimez pas de données, n'étendez pas l'accès et n'appelez pas d'intégrations réelles. N'incluez pas d'identifiants ou de données client privées dans les rapports ou l'historique Git.
Résultat
Fournissez un plan exploitable et concis au niveau de détail demandé par l'utilisateur. Combinez les titres pour les demandes simples.
- Objectif et niveau de preuve : Qu'est-ce qui doit changer, pour qui, qu'est-ce qui est vérifié par rapport à ce qui est supposé ?
- Périmètre : Travail inclus, exclusions et dépendances.
- Approche proposée : Adéquation avec le système existant, décisions techniques importantes et risques de sécurité/données pertinents.
- Tâches de développement : Lots de travaux exécutables et ordonnés, chacun avec une définition de fait.
- Critères d'acceptation : Au moins un scénario normal et, le cas échéant, un scénario d'erreur/autorisation/état vide.
- Décisions ouvertes et vérification : Uniquement les inconnues conséquentes, les tests minimaux et les risques de déploiement ou de rollback si pertinents.
Lorsque le code ou le périmètre est inaccessible, créez une petite tâche de découverte technique au lieu d'inventer une pile technologique ou une structure de fichiers. Si l'utilisateur souhaite uniquement un brouillon de tâche CRM, produisez une tâche concise, et non un plan de projet complet inutile.
Relation avec d'autres compétences
support-assistant: Classe les messages clients et rédige les communications de support/CRM ; un besoin produit vérifié peut devenir une entrée poursoftware-planner.technical-troubleshooter: Enquête sur une panne dans un système en fonctionnement ; cette compétence planifie un changement.code-reviewer: Examine les risques réels d'une PR/diff après implémentation ; un plan n'implique pas que le code a été révisé.
Exemples
$software-planner Planifie la plus petite fonctionnalité de sélection de médias réutilisable avec périmètre et critères d'acceptation.
$software-planner Convertis cette demande de fonctionnalité en quatre ou cinq tâches d'ingénierie exploitables ; énonce clairement les hypothèses si l'accès au code est indisponible.