Comment une personne non technique peut-elle apprendre à rédiger des spécifications pour de petits projets?
Un de mes amis essaie d'externaliser certains développements sur un projet de statistiques.
En particulier, il fait beaucoup de travail dans Excel et veut externaliser la création de scripts pour faire ce qu'il fait maintenant à la main.
Cependant, mon ami est extrêmement non technique. Il est pauvre en rédaction de spécifications techniques.
Quand il écrit une spécification, elle est écrite de la manière que vous décrivez en faisant quelque chose dans Excel (allez dans cette cellule puis copiez la valeur dans cette cellule). Il est également trop verbeux et fait des exemples plusieurs fois. Je ne sais pas s'il décrit correctement les cas d'angle.
Le premier projet qu'il a externalisé a été un échec. Je pense qu'il a sur-décrit certains détails, mais sous-décrit les cas d'angle. Cela et / ou le codeur qu'il a embauché n'ont pas réfléchi aux cas d'angle et posé les questions appropriées. Je ne suis pas sûr. Je suis allé sur IM avec lui et il m'a fallu une demi-heure pour trouver une description qui aurait dû prendre cinq minutes ou moins pour la décrire. J'ai écrit les scripts pour lui à la fin, mais je n'ai pas examiné pourquoi son processus avec le codeur a échoué.
Il m'a demandé de l'aide. Cependant, je refuse de m'impliquer, car prendre sa spécification et la traduire en exigences claires représente 10 fois plus de travail que l'exécution sur une spécification clairement écrite.
Quelle est la bonne façon pour lui d'apprendre? Y a-t-il des ressources qu'il pourrait utiliser? Y a-t-il des moyens d'apprendre des petits projets d'entraînement à basse pression avec des codeurs?
La plupart de ses scripts sont orientés statistiques et informatiques. par exemple, prenez cette colonne et exécutez une moyenne dessus. Supprimez ces lignes dans ces conditions. Le défi est donc différent de celui d'une application Web.
la source
Réponses:
Je vois deux bonnes approches possibles à ce problème. Cependant, il est important de réaliser deux choses. Premièrement, l'ingénierie des exigences est un travail difficile - transformer une idée en une spécification formelle suffisante pour construire un système prend beaucoup de temps, d'efforts et de pratique. Deuxièmement, si vous avez de bonnes exigences (dans n'importe quel format, d'une spécification formelle à des user stories et des cas d'utilisation moins formels), il sera beaucoup plus facile, moins cher et plus rapide de réellement construire le logiciel (et de le construire juste plus tôt).
Si votre ami va demander la construction de nombreux outils logiciels ou a l'intention de les sous-traiter, il doit apprendre à rédiger les exigences logicielles, au moins au niveau des objectifs commerciaux et du concept des opérations. Les deux principaux livres sur l'ingénierie des exigences logicielles sont de Karl Wiegers - Software Requirements (2nd Edition) et More About Software Requirements: Thorny Issues and Practical Advice . Je m'attendrais à ce que la plupart des personnes qu'il embaucheraient voudraient une sorte de document décrivant le système, au moins à un niveau d'objectifs commerciaux ou de concept d'opérations, et ces livres y vont. Ils expliquent également comment et pourquoi d'autres aspects de l'ingénierie des exigences que je soupçonne qu'un bon développeur traverserait au début du projet.
La deuxième option consisterait à embaucher une personne ayant de l'expérience en développement de logiciels et en ingénierie des exigences (et peut-être même une sorte d'ingénierie des systèmes ou d'architecture de systèmes) pour comprendre l'espace problématique et déterminer où les solutions logicielles sont nécessaires et où les solutions logicielles ne le seraient pas. bénéfique, rédiger les documents et peut-être même superviser ou mener à bien l'effort de développement. Cependant, cela coûterait probablement plus cher et reviendrait à embaucher un développeur de logiciels à temps plein pendant une période prolongée pour développer non seulement le système demandé, mais aussi les exigences et l'architecture nécessaires.
Honnêtement, je ne pense pas que ce que vit votre ami soit si rare pour quelqu'un qui ne comprend pas le processus de développement logiciel. Je ne pense pas non plus que le blâme lui incombe entièrement. Si le premier projet logiciel n'avait pas de bonnes exigences, le ou les développeurs auxquels il avait été externalisé auraient dû clarifier, affiner et documenter les exigences. Franchement, je ne suis pas sûr que vous soyez la bonne personne pour vous impliquer, si vous n'êtes pas prêt à consacrer du temps ou à l'effort de travailler avec l'utilisateur / client non technique et d'élaborer de bonnes spécifications techniques (ce est un rôle clé de toute personne effectuant l'ingénierie des exigences dans n'importe quelle discipline d'ingénierie).
Je pense que la solution optimale est vraiment une combinaison de mes deux options. Je pense que votre ami (et peut-être vous aussi) devrait en savoir plus sur ce qui est impliqué dans l'ingénierie des exigences et les avantages que peuvent avoir des exigences solides pour un projet. En tant que développeur de logiciels, vous devez également vous familiariser avec l'ingénierie des exigences et comment obtenir, documenter, analyser et gérer les exigences en fonction des projets logiciels - c'est vraiment une compétence précieuse pour quiconque travaille à n'importe quelle partie du cycle de vie du logiciel.
la source
Lorsque j'ai besoin de spécifications d'un client non technique, je lui demande généralement d'écrire en langage clair ce qu'il veut exactement accomplir. Comme dans "l'application devrait faire A à B lorsque j'appuie sur C, mais seulement si D". Bonus supplémentaire pour "parce que D signifie que ...".
En fait "prenez cette colonne et faites une moyenne dessus." est un pas dans la bonne direction. Une meilleure explication serait "La table contient ceci et cela" (si la structure est prédéfinie); "Obtenez une moyenne de X". Fondamentalement, la manière la moins technique possible sans perdre les détails.
En d'autres termes, décrivez l'idée, pas la mise en œuvre.
Ensuite, un programmeur attentionné devrait être en mesure de comprendre le but réel de ce qu'il a demandé de faire et de choisir lui-même les bonnes étapes, en posant des questions pour tout ce qui n'est pas évident.
S'il n'y a personne qui se soucie suffisamment et comprend le processus, le projet échouera dans tous les cas.
la source
Il peut essayer d'utiliser l' approche du storyboard .
Demandez-lui d'écrire une liste de choses ( histoires ) que l'application va devoir faire et, dans cette liste, de développer davantage la fonctionnalité de chaque histoire.
Il peut utiliser un outil comme Asana pour étendre la portée et les fonctionnalités du projet, et même interagir avec son développeur.
la source
Amen. Cela explique également pourquoi:
La compréhension des exigences est la partie la plus difficile (et la plus coûteuse) de la plupart des projets de programmation. Lorsqu'une personne non technique écrit des exigences, elle ne documente souvent que les solutions de rechange qu'elle souhaite remplacer ("ouvrez Excel, cliquez sur la cellule B3 ..."). Le mieux qu'ils puissent espérer est un double exact de leur difficulté actuelle!
La manière la plus productive que je connaisse pour contourner ce problème est d'encourager cette personne à écrire des cas d'utilisation («utiliser» rime avec «lâche»). Au lieu d'écrire des exigences, décrivez comment le système sera utilisé. Cela laisse au développeur une marge de manœuvre pour suggérer une meilleure solution que ce que l'utilisateur fait actuellement.
Il semble que ce problème soit exacerbé par de mauvaises compétences en communication écrite de la part de votre ami. Il / elle doit soit mettre le travail dans la communication efficace de leurs idées, soit payer le programmeur pour en extraire les informations. Les deux processus sont douloureux et prennent du temps, mais le faire vous-même coûte moins cher que de payer quelqu'un pour le faire avec vous.
Dans tous les cas, il s'agit d'une difficulté courante et frustrante où les créatifs ont une idée incomplète ou sont incapables de la décrire en moins d'un million de mots. Cette personne devrait essayer de trouver un programmeur extrêmement patient et perspicace qui est prêt à aller au fond de ce qu'ils essaient vraiment de faire et à y arriver.
la source
C'est une recette pour un désastre. Cela, et aussi l'espoir que codeur volonté demander. Les codeurs aiment coder, pas communiquer, s'attendre à ce qu'ils rompent leurs habitudes sans incitation est assez irréaliste.
Si votre ami veut faire le travail, il vaut mieux établir un processus impliquant une communication continue avec le codeur - et c'est votre ami qui doit jouer un rôle actif à cet égard, pas le codeur. "Montrez-moi ce qui se fait tous les lundis et organisez deux heures pour en discuter tous les mardis", des trucs comme ça.
D'après mon expérience, le moyen le plus fiable pour faire fonctionner le logiciel comme souhaité avec les clients non techniques était de communiquer et d'itérer en permanence les descriptions des fonctionnalités, sans essayer de le spécifier à mort en une seule fois.
la source
C'est différent - cela semble beaucoup plus simple que de spécifier une application Web. C'est un processus logique. C'est la chose facile.
Votre ami a tout simplement besoin d'écrire les étapes qu'il prend lorsqu'il exécute ce processus. Il peut le faire comme il le souhaite, mais les éléments clés sur lesquels se concentrer sont la précision, la concision et la clarté. Il n'y a aucune raison que cela ne puisse pas être fait purement dans le texte comme un manuscrit; il bénéficierait d'une certaine division logique des composants ou des tâches et fonctionnerait probablement bien comme organigramme ou diagramme.
Maintenant, votre ami devrait trouver un analyste / développeur compétent et engager ses services pièce par pièce. Il doit définir ses attentes - quotidiennement ou au moins plusieurs fois par semaine, votre ami devrait rencontrer le développeur et voir une démonstration pratique des progrès. Votre ami paiera le développeur pour son temps lors de ces démonstrations, mais cela vaudra la peine de s'assurer que le projet est exécuté selon les spécifications. Toute modification des spécifications - c'est-à-dire des choses que votre ami a omises - doit être négociée et probablement ajoutée au prix indiqué.
Notez que j'ai dit «compétent» - ce n'est pas la même chose que «moyen», car il y a beaucoup de développeurs «moyens» qui ne sont pas compétents. Si votre ami trouve le codeur le moins cher ou trouve quelqu'un en ligne, il devrait s'attendre à des problèmes. Cela ne veut pas dire que les gens qui trouvent du travail en ligne ne sont pas bons, mais vous n'emploieriez pas quelqu'un sans recommandation.
Votre ami doit simplement trouver la bonne personne. Dans tout projet logiciel, il faut des analystes, des programmeurs, des administrateurs système, des testeurs et des chefs de projet. Plus votre ami veut externaliser ces rôles, plus le fournisseur sera compétent et plus votre ami devrait s'attendre à payer.
la source
Désolé d'être le seul à vous en parler, mais ce n'est pas le travail d'une personne non technique d'apprendre à rédiger des spécifications formelles. C'est le travail du développeur d'interviewer la personne non technique, d'essayer de distiller ce que la personne vous dit sur ce qu'elle recherche, de déterminer ce que le client veut vraiment (par opposition à ce qu'il pense vouloir, ce qui n'est pas toujours la même chose), créez un document d'exigences relativement informel (qui est bien structuré mais qui essaie d'éviter le jargon que le client ne comprendra pas) et examinez ce document avec le client.
Une fois que le client est satisfait du document informel des exigences, vous pouvez l'utiliser comme base pour rédiger une spécification d'exigences plus formelle qui commence à entrer dans plus de détails techniques sur ce qui est nécessaire.
L'ensemble de ce processus est connu sous le nom de «capture des exigences» et il constitue la première étape du processus d'ingénierie logicielle. En fait, l'écriture du logiciel n'est qu'une partie relativement petite de l'ingénierie logicielle, un fait que beaucoup de développeurs de logiciels oublient malheureusement. Une autre chose qu'ils semblent oublier, c'est qu'il y a un fort besoin de communiquer avec le client et de maintenir un dialogue avec lui pendant tout le processus pour s'assurer que les choses restent sur la bonne voie.
En ce qui concerne la communication avec des personnes non techniques, il est extrêmement important que vous essayiez d'éviter d'utiliser le jargon des ordinateurs et du développement de logiciels lorsque vous leur parlez. S'ils utilisent des termes de jargon de leur propre domaine, il est important de comprendre ce que ces termes signifient, de sorte que vous souhaiterez peut-être rédiger un glossaire de projet pour obtenir des définitions formelles de ces termes. Vous travaillez pour eux après tout, il est donc important de comprendre d'où ils viennent.
au lieu de jargon, vous devriez essayer d'utiliser des moyens non intimidants de communiquer avec votre client, les documents écrits en anglais simple sont une aide, mais beaucoup de gens dans le secteur des logiciels sont habitués à écrire pour les ordinateurs plutôt que pour les humains et peuvent donc trouver cela difficile. De plus, les clients n'aiment pas lire à travers de gros tas de papier, quelle que soit la clarté de leur langue, vous pouvez donc avoir recours à des aides visuelles. Les diagrammes, les wireframes et les storyboards sont des outils utiles ici.
Mais en bref, l'essentiel est que ce n'est pas le travail de votre client d'apprendre votre langue, c'est le vôtre d'apprendre sa langue.
la source