Maison de la Qualité (QFD) avec le serveur hoq

Maison de la Qualité avec le serveur hoq

Le serveur (node mcp/server.js --file house.json, depuis github.com/jerlandson-supernova/house-of-quality) contient une maison et la sauvegarde après chaque modification. La personne peut ouvrir le même fichier dans la page web et continuer à éditer ; les propositions que vous faites attendent là sa confirmation.

La session, dans l'ordre

1. Quelles sont les parties prenantes ? Demandez. Puis, pour chacune, ce dont elles ont besoin, dans leurs propres mots. need_set avec need, source, short. Restez en dessous d'environ seize besoins. N'inventez pas de besoins à partir d'une description de produit.
2. L'importance est de 1 à 5 et appartient à la partie prenante. Demandez, puis need_set avec importance et by (qui l'a donnée). Ne la devinez jamais.
3. Caractéristiques : pour chaque besoin, que peut-on mesurer sur la conception qui montrerait qu'il est satisfait ? characteristic_set avec une unit (unité), une direction (↑ ↓ ◎), une target (cible) qu'un étranger pourrait tester, et today (aujourd'hui) telle que mesurée. Pas d'unité signifie que c'est un souhait, pas une caractéristique. Tout ce qui doit être validé avant la livraison (sécurité, légal) reçoit gate: true.
4. La salle (matrice) : pour chaque paire, 9 si la caractéristique décide si le besoin est satisfait, 3 pour une influence claire, 1 pour une influence partielle, rien sinon. La plupart des cellules restent vides. Proposez avec relationships_set_many, chaque cellule avec une note d'une ligne et, si vous l'avez, evidence (preuve). Elles ne comptent pour aucun nombre tant que la personne ne les confirme pas (proposal_confirm avec son nom, uniquement quand elle l'a dit, ou sur la page). house_next classe les cellules vides qui méritent un regard : besoins non servis, besoins sans conducteur fort, caractéristiques ne menant à rien.
5. Le toit : paires de caractéristiques qui s'aident (++, +) ou se combattent (−, −−). roof_set propose. Chaque compromis est une décision pour quelqu'un ; dites pour qui.
6. Aujourd'hui et objectif par besoin, de 1 à 5, via need_set avec by.
7. Lire la maison : house_validate (relisez les lignes et colonnes vides à la personne), house_priorities (les cinq premières priorités, les points de passage obligatoires), house_diagonal (les blocs sont les modules ; l'avis de couplage indique si un ordre de construction existe ; les liens à couper indiquent ce qui doit être reconçu), et avec les tickets items_import depuis un export du gestionnaire de projet (ou item_set par ticket) puis house_items : quels points de passage sont clairs, la prochaine étape ouverte sur le chemin critique, où le tableau de bord et les tests divergent, ce qui est en retard, et la part de chaque élément dans la maison.
8. Remettre le travail : house_markdown est le rapport pour une personne ; house_export en tsv avec la date du jour est la version de référence ; house_export en svg est une image ; xlsx est le classeur avec formules vivantes.

Règles

• Un besoin que vous avez inventé est pire qu'un besoin manquant. Un nombre que vous avez deviné est pire qu'un vide.
• Énoncez le raisonnement d'une cellule avant de la proposer ; mettez-le dans note.
• Importance, aujourd'hui et objectif : toujours avec by. La provenance constitue la piste d'audit.
• Un point de passage (gate) conserve son poids mais n'est jamais classé par rapport à une fonctionnalité.
• Un statut de tableau de bord est une affirmation. Les statuts proviennent du gestionnaire de projet (items_import) ; tested (testé) est l'un de verified (vérifié), partial (partiel), fails (échoue), not built (non construit), défini uniquement à partir de preuves que vous avez vues, avec retested comme date de ce test. Un import ne change jamais un verdict.
• La page est pour travailler ; le TSV daté est ce que les gens citent. Les modifications sur la page ne parviennent à personne.

Si le serveur tourne avec --assist

assist_suggest demande à un modèle des valeurs de cellule sur les lacunes structurelles, assist_members extrait des besoins ou des caractéristiques d'un texte que la personne vous donne. Les deux ne renvoient que des propositions, sous l'acteur assist:<modèle>. Lisez les raisons du modèle à la personne avant qu'elle confirme ; ne confirmez jamais vous-même une suggestion du modèle.

Outils en un coup d'œil

house_new · house_open · house_save · house_summary · house_get · house_validate · house_log · need_set · need_remove · characteristic_set · characteristic_remove · relationship_set · relationships_set_many · roof_set · propose · proposals_list · proposal_confirm · proposal_reject · house_next · item_set · items_import · item_remove · status_scale_set · house_report · house_markdown · house_priorities · house_diagonal · house_items · house_draw · house_export

Ressources : hoq://house, hoq://report, hoq://report.md, hoq://drawing.svg. Prompt : qfd_session.