Vous pouvez rédiger des spécifications techniques sans faille, mais à quoi bon si votre développeur pleure?

Un propriétaire de produit sphérique travaille dans une galaxie lointaine, très lointaine. Il écrit couramment des notes sur une serviette et les donne silencieusement aux développeurs. Et bientôt il reçoit un produit fini qui répond à 100% à ses attentes. Même si ce produit est un service multiplateforme complexe avec blackjack et adaptabilité.



Est-ce possible en pratique?



«Non, frère, vous ne pouvez pas nous tromper! Les termes de référence doivent être rédigés longuement et méticuleusement », disent les aînés aux cheveux gris. "TK est sérieux!" - les Jun à la bouche jaune leur font écho. «Ma femme m'a quitté à cause d'une courte mission technique», admet un analyste d'affaires chevronné.



Je ne suis pas d’accord.



La rédaction d'une spécification ne doit pas prendre du temps. De plus, les bons termes de référence sont plus faciles à rédiger que les mauvais. Si vous connaissez quelques astuces, bien sûr. Je vais vous en parler aujourd'hui. Cependant, au lieu de serviettes, je recommande toujours d'utiliser la confluence .

Qu'est-ce qui ne va pas?

J'écris des problèmes pour les développeurs depuis plus de 11 ans. Des applications, des jeux, des services Web, des systèmes CRM, des plates-formes de formation et d'autres produits ont été créés à partir d'eux. Pendant ce temps, je suis passé de la rédaction de documents de conception de 200 pages à des termes de référence laconiques en plusieurs étapes. Et, bien sûr, il a comblé toutes les bosses possibles.



Année après année, dans différentes entreprises, j'ai observé comment les produits, les concepteurs de jeux et les spécialistes du marketing définissaient les tâches. Et quelles sont les conséquences des différentes «caractéristiques» de la conception de ces tâches. Comment le début du sprint est décalé d'une semaine, en déterminant exactement ce que veut le client. Comme dans la panique, ils corrigent à chaud la fonctionnalité qui vient d'être versée dans le produit. La vitesse à laquelle le score de l'application est supprimé en raison de cas non comptabilisés. Comment les ventes chutent et les utilisateurs fidèles partent. Comment les développeurs s'épuisent lorsqu'ils doivent bricoler des tâches problématiques.



J'ai eu l'impression que trop de ceux qui définissent des tâches de développement ne savent pas comment bien le faire . Et la question de la qualité des savoirs traditionnels eux-mêmes n'est pas au centre de l'attention: ils disent, ils ont écrit une tâche et des normes, ils ne le comprendront pas, ou quoi? De plus, il y a toujours des choses plus intéressantes à faire: discussion de nouvelles hypothèses, rencontres, pauses café. En conséquence, tout le monde en souffre: clients, développeurs et entreprises.

Il y a deux extrêmes lors de l'écriture de savoirs traditionnels

Plus le produit sur lequel vous travaillez est gros, plus le coût d'une erreur est élevé et plus la qualité de la spécification technique est importante (merci, cap!). Par conséquent, les deux options ne conviennent pas si vous faites quelque chose de plus sérieux qu'une page de destination. Dans les produits de grande taille et compétitifs , l'écriture des savoirs traditionnels doit être rapide, intelligente, rock and roll . Voyons comment y arriver.

,

1. 
   
   – , , . , ( ).
2. 
   
   – , . , – , . .. , , . , – , .
3. PM-
   
   – , , . «», , .
4. QA
   
   – , . user journey . , , , .
5. Les savoirs traditionnels doivent plaire au chef d'équipe,
   
   ce qui signifie qu'ils ne nécessitent aucun rituel ni explication particuliers pour être transférés au développement. Par exemple, si un produit a terminé la mission technique et qu'il a été heurté par un bus juste là, en plein bureau, cela ne doit pas l'empêcher d'effectuer la mission technique de la meilleure façon possible.

Est-il difficile de répondre à toutes ces exigences? Pas du tout.



Au contraire, si vous vous en souvenez, vous ne pourrez pas écrire franchement de mauvais savoirs traditionnels. Parce que toutes ces exigences se résument à une seule chose: prendre soin des personnes qui interagissent avec ces savoirs traditionnels.

Mon format TK

Ce format est un mélange assez vague de user story + définition de done .



Il est apparu à la suite de nombreuses années d'évolution: chaque fois que je voyais un problème systématique, je changeais le format de mes savoirs traditionnels pour que ce problème ne se pose plus à l'avenir. Le résultat est un format laconique et visuellement propre que même les junes peuvent facilement saisir. De plus, il répond aux exigences décrites ci-dessus.



Voici à quoi ressemble une histoire typique dans mes savoirs traditionnels:







et quelle que soit la taille et la complexité du produit que nous développons, tout savoir traditionnel sera composé d'histoires aussi simples (leur nombre ne fera qu'augmenter).





Important: les histoires ne doivent pas décrire des fonctionnalités trop volumineuses (par exemple, plusieurs écrans) ou trop petites (par exemple, un bouton). En règle générale, une histoire est une fonctionnalité ou un mécanisme de produit. Par exemple, une histoire peut décrire en détail l'enregistrement d'un nouvel utilisateur. Pour définir une tâche pour la mise en page d'une nouvelle page de destination, en règle générale, une histoire me suffit également.



Si la spécification technique est grande et significative, alors avant la liste des histoires, j'écris brièvement: pourquoi nous le faisons et quels résultats nous voulons obtenir . Juste pour que les développeurs aient une vue d'ensemble.

En général, il s'avère quelque chose comme ceci:

Exemple

D'accord, pour comprendre comment cela fonctionne - décomposons un produit en de telles histoires. Par exemple, nous avons décidé de créer une application appelée "neural boot". Dans celui-ci, le réseau neuronal mènera des conversations intimes avec des produits qui n'ont pas eu une journée (et n'ont pas d'amis).



Pour simplifier, nous supposons que nous avons déjà un réseau de neurones entraîné et que nous devons en faire une interface sous la forme d'une application.



Probablement, le TK comprendra les lignes suivantes:

1. Autorisation utilisateur
2. Profil de l'utilisateur
3. Écran de communication avec le neuroboot
4. Écran "Catalogue Neuroboot"
5. Écran de profil et de paramètres
6. Popup de paiement
7. Connexion Analytics

Il reste à peindre chaque histoire (dans le format ci-dessus) et à l'envoyer au développement. Je vous ai dit que ce serait facile.

---

Astuces de vie délicates

Il existe un certain nombre de techniques qui m'aident à travailler quotidiennement sur un produit. Voici ceux qui concernent la rédaction des termes de référence.

Life Hack # 1: Détaillez de manière itérative

Maintenant, je n'écris pas du tout de spécifications techniques - elles-mêmes, en arrière-plan, apparaissent dans le processus de travail. Lorsqu'une nouvelle tâche apparaît, je comprends immédiatement: quelles sous-tâches sont nécessaires pour cela? Et puis je corrige chaque sous-tâche dans le format de l'histoire (seul le nom, les détails viendront plus tard).



Ainsi, j'ai immédiatement un mandat généralisé prêt. Il ne reste plus qu'à détailler l'histoire dans la mesure où il sera possible de confier la mission technique au développement.



Le détail passe aussi en arrière-plan: pendant que je recherche et réfléchis aux détails, je prends immédiatement des notes à l'intérieur des lignes correspondantes. Au lieu de la conception, j'insère des prototypes de NinjaMock .



Cette approche accélère considérablement le travail. De plus, cela vous permet de ne pas rater la vue d'ensemble et de ne pas creuser les détails à l'avance.

Life hack # 2: ne pas travailler avec des génies

Il y avait un tel vieux film où le génie exauçait ses souhaits de la manière la plus merdique.



Bien sûr, un développeur sensé ne cherchera pas spécifiquement une occasion de nuire. Mais parfois, les gens ne se soucient pas de ce sur quoi ils travaillent. Ensuite, ils font la tâche "telle qu'elle est écrite", sans vraiment se demander pourquoi elle est nécessaire. Périodiquement, cela entraînera des fichiers petits et grands. Eh bien, oui, la production a posé ... mais personne n'a prescrit dans la tâche ce qui doit être vérifié - si une telle implémentation casserait tout le reste.



Je ne parlerai pas de l'externalisation, mais cette approche n'est pas acceptable dans le produit. Un bon développeur construit un temple, pas seulement des briques. Autrement dit, il voit la situation dans son ensemble et se penche sur ce qui se passe. Ces types proposent souvent des solutions alternatives et mettent eux-mêmes en garde contre les écueils.



Par conséquent, si vous voulez que vos savoirs traditionnels soient réalisés de la meilleure façon possible, vous devez parfois améliorer non pas les savoirs traditionnels, mais la culture de développement au sein de l'équipe. En général, c'est la tâche du PM, mais le produit peut également influencer la situation. Surtout si l'équipe lui fait confiance (grâce à ses spécifications techniques réfléchies et bien conçues, par exemple).

Life Hack # 3: Séparer la mission technique de la documentation

Le mandat répond à la question "que faut-il faire?" Et la documentation - à la question "comment est-ce fait / comment ça marche?" Le savoir traditionnel est écrit avant la mise en œuvre de la tâche et la documentation est écrite après.



Si j'ai besoin de réorganiser le cabinet, j'écrirai une tâche dans l'esprit de «réorganiser d'ici -> d'ici». Mais je ne dessinerai pas le plan architectural de la maison dans laquelle se trouve une armoire.



Parfois, on estime que les savoirs traditionnels devraient être rédigés de manière à ce qu'ils soient , pour ainsi dire, la documentation . C'est une théorie pernicieuse. Une documentation complète ne fonctionnera toujours pas, car on ne sait pas à l'avance comment exactement les termes de référence seront mis en œuvre. De plus, les développeurs ont besoin d'une marge de manœuvre, ce que la documentation ne fournit pas. Et l'essentiel est d'écrire un tel savoir traditionnel plusieurs fois plus longtemps et cela s'avérera fastidieux.



Il existe différents produits et différentes startups. Quelqu'un peut se passer de documentation. Mais si vous avez encore besoin de documentation, engagez un juin qui décrira la fonctionnalité en détail après sa mise en œuvre. Vous n'avez pas besoin de compétences particulières pour décrire les fonctionnalités existantes, mais vous économiserez du temps et des nerfs pour les employés compétents - développeurs de produits et développeurs.

Life Hack # 4: Apprenez à programmer

Un constat purement empirique: les produits qui savent programmer sont meilleurs pour formuler des tâches. De plus, il n'est pas nécessaire de devenir un opérateur backend senior, il suffit de maîtriser n'importe quel langage de programmation et de comprendre l'essence de la pensée algorithmique.



À un moment donné, je codais encore de manière incontrôlable sur le spectre chthonique , et pendant mes années d'étudiant, j'ai même dû écrire des pilotes dans Assembler. Autrement dit, je suis familier avec la programmation de première main - et cela, bien sûr, aide à trouver un langage commun avec les développeurs.

Life Hack # 5: Penser beaucoup, écrire un peu

Les plus gros problèmes surviennent toujours avec des tâches que le client lui-même ne comprend pas pleinement. Par exemple, il a besoin d'un nouveau rapport dans la zone d'administration, mais il ne comprend pas très bien comment ce rapport sera formé. Par exemple, vous les programmeurs le découvrirez. Non, ça ne marche pas comme ça.



La seule façon d'écrire un bon problème qui est bien fait est de comprendre. Idéalement, comprenez suffisamment le problème pour pouvoir le faire vous-même ... si vous saviez programmer.



Mais lorsque vous l'avez compris, vous n'avez pas besoin de vider toutes les informations contenues dans les savoirs traditionnels. C'est juste une compréhension profonde de la tâche qui vous permet de jeter les choses inutiles et d'écrire uniquement ce qui compte.

---

PS TK est un moyen, pas une fin. Par conséquent, le meilleur savoir traditionnel est parfois son absence. Un jour, je vous raconterai comment j'ai lancé quelques produits sans aucune spécification technique.



PPS Si vous avez votre propre format de termes de référence ou de hacks de vie lors de leur rédaction - veuillez les partager dans les commentaires.