👌🏽 🍭 👎🏻 Comment faire une tâche technique simple et ne pas perdre d'argent et de nerfs 👑 🔧 ➖

Bonjour, Habr! J'adresse cet article à moi-même, jeune et inexpérimenté, ainsi qu'à toute personne qui n'est pas sûre de l'approche de la documentation technique. Bien que si elle aide quelqu'un du bison de l'industrie du design, je serai doublement heureux.

Il existe de nombreuses normes et spécifications pour la rédaction des savoirs traditionnels , mais si les jeunes studios, tout en développant une simple boutique en ligne, essaient de s'y conformer, ils n'auront pas le temps de mettre en œuvre quelques projets, car ils feront faillite, se creusant dans un tas de documents incompréhensibles.

Ce qui était avant

Nous sommes une petite entreprise régionale engagée dans le développement web sur mesure qui, comme beaucoup d'autres, a au tout début pris en charge des projets, ne sachant pas vraiment comment les réaliser. Mais une telle «croissance forcée» a eu un effet extrêmement positif sur les membres de l'équipe, grâce à une grande envie de se développer, et a contribué à pomper les compétences et la tête. Le développement s'améliore, mais le mandat reste au niveau le plus bas. Comme la plupart des studios pour débutants, nous avons utilisé l'approche descriptive habituelle des savoirs traditionnels: quelles pages, ce qui devrait être affiché, quelques points techniques, et c'est tout, peut-être.

Sur de nombreux projets, cela a entraîné les problèmes suivants:

L'apparence est décrite, mais pas le principe de fonctionnement. Un exemple simple avec un panier d'achat en ligne. Dans l'énoncé des travaux, le bouton «Passer une commande» a été écrit. Mais que doit-il se passer lorsque l'utilisateur clique sur ce bouton? Selon quelles règles le numéro de commande est-il formé? Quel statut lui est attribué? Où va le transfert? Et si l'une des marchandises était épuisée pendant que l'utilisateur passait une commande? Il n'y avait pas de réponses à ces questions et à bien d'autres dans les TdR, mais ce n'est qu'un petit élément. De tels moments non décrits ont entraîné des litiges avec le Client, une forte sortie du budget et d'autres conséquences désagréables.
Manque de blocs réutilisables. De nombreux sites ont les mêmes blocs utilisés à différents endroits, par exemple, les aperçus de produits. Mais ce bloc en conséquence a été décrit dans chaque page. C'est très mauvais pour plusieurs raisons. Premièrement, si nécessaire, des modifications doivent être apportées à plusieurs endroits à la fois, vous pouvez manquer quelque chose et il y aura un écart. Deuxièmement, même avec les mêmes éléments dans l'aperçu, le client peut exiger de les faire différemment, ce qui entraîne des coûts supplémentaires.
Les savoirs traditionnels ne sont pas en corrélation avec les tâches de l'équipe. Plus la formulation du problème est éloignée de la réalité, plus la qualité de la sortie sera faible. C'est un autre problème que je voulais résoudre.

Nouvelle approche

Après avoir déterminé les objectifs, nous avons développé un nouveau concept assez simple mais efficace.

Les savoirs traditionnels se composent des sections suivantes:

Présentation
Statique
Dynamique
Les tâches
Panneau d'administration
Exigences techniques générales

D'un projet à l'autre, la composition de ces sections peut varier, mais la structure de base demeure. Examinons de plus près.

Introduction et préparation pour la mise en œuvre

Nous décrivons brièvement le projet, ses objectifs, l'AC, laissons des liens vers des analyses pré-projet.
Nous décrivons le processus d'initialisation du projet: la mise en place de l'environnement pour les développeurs et l'approche pour développer un concept de design pour les concepteurs.
Les principes d'adaptabilité ou de versioning. Récemment, dans notre travail, nous adhérons au principe suivant - «adapter tout ce qui s'adapte». En d'autres termes, au début des travaux sur les savoirs traditionnels, nous comprenons les fonctionnalités complexes dont nous avons besoin (ou pouvons être nécessaires dans un proche avenir) et, avec le concepteur et le développeur front-end, nous trouvons des moyens de l'adapter. Avec la nouvelle approche, il n'y a eu aucun résultat négatif, par conséquent, les versions séparées n'ont pas dû être décrites.

Cette section vise à mettre à jour l'équipe et à préparer le terrain pour le développement immédiat du projet.

Statique

Comme nous le savons tous, les pages peuvent contenir des informations statiques ou des informations dynamiques envoyées par le serveur. Sous-sections statiques - pages de projet. Nous divisons chaque page en blocs. Si le bloc est statique, nous décrivons son essence et son type de contenu. Par exemple, une description de l'un des blocs sur la page À propos de la société peut ressembler à ceci. «Les principaux avantages de l'entreprise. 5-6 icônes descriptives. " Il s'agit d'une description très brève mais suffisante pour une évaluation précise du bloc. Lors de la description de la statique, l'objectif principal est de définir un cadre clair. Faire des icônes adaptatives n'est pas difficile, mais avec un graphique ou un tableau, tout n'est pas si simple et sans ambiguïté. Mais en même temps, peu importe le type d'icônes et de signatures.

Si la page contient un bloc qui peut être «retiré des crochets», alors à la place de son intégration, nous écrivons «La fonctionnalité NAME est en cours d'intégration, et la fonctionnalité elle-même est décrite dans la section Dynamique.

En plus des pages, Statics comprend une description des fenêtres contextuelles et des lettres. À mon avis, cela n'a aucun sens de les placer dans une grande section séparée et de gonfler la structure.

Dynamique

Tout ce qui concerne la dynamique que nous appelons fonctionnelle. Peut-être qu'une autre division apparaîtra plus tard, car Déjà ici, différents types de tâches appartiennent:

Bloquer Nous faisons la dynamique:
- Blocs utilisés dans différentes parties du site.
- Blocs qui ont du sens à évaluer séparément. Premièrement, il simplifie le processus d’évaluation lui-même et la compréhension par le client de la complexité d’un élément individuel. Deuxièmement, les blocs qui ne sont pas vitaux pour un projet entrent souvent dans cette catégorie, et avec cette approche, il est plus facile de les exclure du budget.
- Processus qui se produisent lors d'une action utilisateur spécifique. Tout d'abord, cela inclut les actions qui se produisent lors de la commande, du paiement, de l'ajout au panier, etc. Une telle fonctionnalité pendant le développement du projet est souvent finalisée, et donc ces améliorations sont beaucoup plus commodes à décrire.
- Intégration de services tiers. Selon la complexité de l'intégration, elle peut être décrite comme une seule fonction, ou vice versa divisée en plusieurs fonctions différentes pour décrire des requêtes individuelles.

Les tâches

Cette section est utilisée pour les œuvres qui ne peuvent être attribuées à aucune des autres sections: dessiner une bannière, définir un compteur métrique, analyser les marchandises, etc.

Panneau d'administration

Nous décrivons ici la structure, les modèles et les champs. La répartition est divisée en sections, par exemple, «Produits», «Catalogue», «Commandes», etc. Nous décrivons que différents rôles d'utilisateur peuvent afficher les éléments à modifier.

Exigences techniques générales

Il comprend un certain nombre de sous-sections, qui ne sont pas toutes vraiment des exigences techniques, mais encore une fois, il n'était pas logique de les séparer:

Exigences relatives aux balises SEO et aux micro marquages
Règles de translittération
Test manuel et automatique
Navigateurs pris en charge
...

Nouvelles versions

Lors de la description de nouvelles versions, il est nécessaire d'apporter des modifications aux éléments existants. Nous avons examiné les façons suivantes de décrire les améliorations: au début de chacune des sections (Statique, Dynamique, AP), écrivez «Amélioration de la fonction« NOM », ou créez une section distincte« Améliorations »dans laquelle toutes les tâches changeantes seront vidées en même temps. Jusqu'à présent, nous avons opté pour la deuxième option, mais cela est plutôt lié à la commodité de projets spécifiques. Dans d'autres conditions, la première méthode est meilleure.

Après avoir écrit les spécifications techniques de la nouvelle version, nous les fusionnons en une seule afin que la suivante puisse être écrite sur la base d'un document.

Exemple

Pour plus de clarté, analysons la structure des savoirs traditionnels sur la base d'une page simplifiée dans la section catalogue.

Statique

Page de la section Annuaire

Utilisé pour afficher les marchandises appartenant à une section de catalogue de tout niveau sauf la racine.

Les fonctionnalités suivantes sont intégrées:

«Chapelure»
«Arbre de répertoire»
«Filtrage. Dispositions générales »
«Filtrage. Texte "
«Filtrage. Texte et image "
«Filtrage. Gamme "
«Trier. Par défaut "
«Trier. Prix ascendants “
«Trier. Prix décroissant »
«Aperçu du produit. Tile ”
«Pagination. Page "
«Bloc de texte». S'intègre comme un bloc de texte SEO devant le sous-sol

URL: / c / 1745-nom, où 1745 est l'ID de la catégorie de répertoire actuelle et nom est le nom translittéré de cette catégorie.

Dynamique

Étant donné que la page contient de nombreuses intégrations, je vais donner des exemples pour les deux plus intéressantes d'entre elles.

Fonctionnalité «Filtrage. Dispositions générales »

Extérieurement, le filtrage est une série (ou plusieurs rangées) de boutons portant le nom du filtre. Lorsque vous cliquez sur le bouton, une liste déroulante s'ouvre avec des cases à cocher avec des valeurs de filtre (valeurs des caractéristiques de produit correspondantes). La largeur de la liste déroulante dépend de la longueur maximale de la valeur dans cette liste. Dans la zone visible de la liste déroulante, pas plus de 10 éléments sont affichés. S'il y a plus de valeurs de filtre, une barre de défilement apparaît. Sous les valeurs de filtre se trouve le bouton Appliquer. Si au moins une valeur est sélectionnée et que l'utilisateur clique sur le bouton Appliquer, en dehors de la zone de filtre ou sur le bouton avec le nom du filtre, alors:

la liste déroulante se ferme et le filtre est appliqué. Seuls les produits correspondant aux filtres actifs actuels restent dans la section actuelle
le nom du bouton de filtre prend la forme: «Nom du filtre: K», où K est le nombre de valeurs de filtre sélectionnées, s'il y en a 2 ou plus, ou «Nom du filtre: valeur» si une valeur a été sélectionnée.
la couleur du bouton de filtre change selon le type de filtre utilisé
dans les valeurs des autres filtres, seules les options qui satisfont les filtres actuellement actifs restent. Si une valeur reste dans l'un des filtres inactifs, son bouton devient inactif et le nom s'affiche au format «Nom du filtre: valeur»
pour tous les filtres actifs, une croix est ajoutée après le nom, lorsque vous cliquez dessus, seul ce filtre est réinitialisé
la pagination est réinitialisée

Si au moins un filtre est actif, après tous les boutons avec filtres, le bouton «réinitialiser les filtres» apparaît, lorsque vous cliquez dessus, la valeur de tous les filtres est réinitialisée.

Lors du passage de la catégorie actuelle à une autre, une vérification est effectuée pour la coïncidence des filtres actifs et des valeurs sélectionnées avec les filtres correspondants et les valeurs de la catégorie vers laquelle la transition a été effectuée. Dans la catégorie nouvellement sélectionnée, les filtres et les valeurs sélectionnées qui y sont identiques restent actifs.

Le filtrage peut être intégré de 2 manières: dynamique et statique. L'intégration dynamique vous permet de définir la caractéristique selon laquelle le filtrage est effectué dans le panneau d'administration. De telles intégrations sont indiquées sans paramètres supplémentaires. L'intégration statique est appliquée à la page par défaut. Lors de la description de l'intégration, un paramètre supplémentaire est indiqué - la caractéristique par laquelle le filtrage est effectué.

Les filtres sélectionnés sont ajoutés à l'URL via les paramètres de requête.

Fonctionnalité «Aperçu du produit. Tile ”

Il s'agit d'une tuile (rectangle) contenant les informations produit les plus importantes pour l'utilisateur. Dans la version tuile, les informations clés sont l'image du produit. L'aperçu contient:

Prix (entier en roubles russes)
Nom du produit
Libellé «En magasin» ou «Depuis la fenêtre»
Image
La taille
Bouton "To Cart" (Intégration de la fonctionnalité "Add to Cart")
Bouton «Ajouter aux favoris» (Intégration de la fonctionnalité «Ajouter aux favoris»)

Lorsque vous cliquez sur une zone de l'aperçu, en plus du bouton "Ajouter au panier", vous serez redirigé vers la page du produit.

Sur une ligne, vous devez placer 3-4 carreaux avec des aperçus de produits.

Comme vous pouvez le voir, une autre fonction est intégrée à cette fonction, ce qui vous permet de faire des partitions très pratiques. Par exemple, «Ajouter au panier» et «Ajouter aux favoris» sont également utilisés dans la carte du produit.

Panneau d'administration

Une page nécessite un grand nombre de sections de l'AP, je vais en décrire une.

Produit

Liste de tous les produits avec filtrage. Lorsque vous modifiez / ajoutez un élément, les champs suivants sont disponibles:

Titre (texte)
Marque (radio)
Les images
Prix (entier)
Description (bloc de texte)
Type (magasin / vitrine, radio)
Condition. La signification comprend le titre (texte) et l'explication (texte).
Statut Les options sont les suivantes:
1. en vente
2. avec modération
3. en cours de révision
4. rejeté
5. épuisé
6. échec de la vérification
7. annulé par le vendeur
Taille du tag (facultatif). Champ de texte sans validation
...

Il y a plus de 30 champs et, pour ne pas gonfler l'article, nous les omettons.

Conclusions

Avantages de la nouvelle approche:

Complétude . Ce savoir traditionnel vous permet de décrire clairement les exigences, qui sont le paramètre principal et nécessaire de tout savoir traditionnel.
Clarté . Environ la moitié de nos clients n'ont pas de spécialiste technique de leur côté et sont confrontés pour la première fois au développement. Par conséquent, il était très important de rendre les savoirs traditionnels aussi clairs et lisibles que possible. Et nous l'avons fait! Même les clients non avertis en technologie comprennent comment cela fonctionne, ils peuvent facilement le lire et donner d'excellents commentaires.
Molécularité TK satisfait pleinement à nos exigences de division en éléments individuels, ce qui simplifie et résout considérablement les problèmes décrits ci-dessus. Les blocs TK correspondent directement aux tâches effectuées par les développeurs, ce qui a été rencontré avec fracas. TK s'intègre également parfaitement dans le système de conception (un article à ce sujet sera publié la semaine prochaine).
Facilité d'estimation et de configuration des coûts . Des tâches bien décrites et brisées sont devenues simples et agréables à évaluer. Si, lors de l'évaluation, nous comprenons que les exigences sont incomplètes, nous les ajoutons. Pour chaque projet (étape), nous créons un tableau Google dans lequel le client peut essayer différentes configurations de projet et déterminer l'option la plus appropriée pour lui par prix / fonctionnalité.
L'interaction avec les clients a atteint un nouveau niveau . Les modifications apportées vous permettent de définir clairement les limites du projet. Si des changements sont nécessaires en ce qui concerne les savoirs traditionnels, cela est évalué comme une nouvelle tâche, bien qu'avec l'ancienne approche, cela ait suscité beaucoup de controverses.
Rentabilité . Parce que il s'agit avant tout d'une entreprise, cet indicateur, avec le précédent, est l'un des plus importants. Une étude détaillée a permis de minimiser le nombre de tâches mal évaluées. Aucun des projets mis en œuvre dans le cadre de la nouvelle approche n'avait un excédent budgétaire.

Inconvénients:

Apporter des améliorations . Dans l'un des projets, il a fallu introduire le statut des marchandises. En conséquence, un grand nombre d'améliorations de 2-3 lignes se sont avérées. Cela ne peut pas être appelé un inconvénient clair, car l'exhaustivité des exigences est une priorité, mais l'approche de données idéale ne peut pas être appelée.
La complexité de la perception dans l'automatisation des processus métier . Si vous prenez les processus commerciaux de certaines entreprises du moment de la vente à la réception de la marchandise par l'acheteur, il n'y a pas toujours la possibilité (ou le besoin dans les premières étapes) de couvrir l'ensemble du processus au détriment de la statique, de la dynamique et de l'AP, car de nombreuses tâches sont effectuées manuellement, discutées avec les clients par téléphone, etc. Cela complique légèrement la perception des savoirs traditionnels dans leur forme pure et nécessite une description supplémentaire des processus.
Coût et temps de développement . La vente de savoirs traditionnels, bien sûr, est devenue plus difficile, car tout le monde au premier contact avec le développement n'est pas prêt à payer 10 à 20% du projet, tandis que beaucoup de nos concurrents en facturent 10 à 20 000. Mais un tel travail est pleinement rentable lors de la mise en œuvre, réduisant ainsi risques du projet et amélioration de la qualité.

Les avantages de la nouvelle approche ont eu un effet très positif sur tous les aspects de notre travail et ont permis d'identifier des faiblesses auxquelles nous n'avions pas prêté attention auparavant. Les inconvénients, bien qu'il y en ait, sont insignifiants, surtout en comparaison avec les pros.
Chaque projet apporte quelque chose de nouveau, polit les coins et vous permet de le changer pour le mieux.

Nous sommes tellement satisfaits du résultat que nous avons décidé d'abandonner les suiveurs de tâches standard au profit de la finalisation de Google Docs pour travailler pleinement avec les tâches basées sur les savoirs traditionnels. Si l'expérience réussit, nous écrirons un article séparé à ce sujet. En attendant, nous attendons des critiques et des conseils objectifs de votre part, dans l'espoir que cet article a aidé quelqu'un).

Comment faire une tâche technique simple et ne pas perdre d'argent et de nerfs