![\"Swing](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
Source de l'image : perfectdigital.com<\/em><\/p>\n Je pense que cela montre tr\u00e8s bien que de grandes divergences et un manque de vision peuvent appara\u00eetre au sein de l'Union europ\u00e9enne. d\u00e9veloppement de logiciels<\/a> entre tous les participants et toutes les personnes impliqu\u00e9es.<\/strong> Les probl\u00e8mes surgissent souvent d\u00e8s le d\u00e9but, lorsque le client arrive avec un projet (th\u00e9oriquement) d\u00e9finitif. produit<\/a> et la pr\u00e9sente \u00e0 la Commission europ\u00e9enne. \u00e9quipe<\/a>. Viennent ensuite d'autres malentendus, des interpr\u00e9tations erron\u00e9es et, finalement, la projet<\/a> s'engage rapidement sur la mauvaise voie du d\u00e9veloppement.<\/p>\n En analysant le graphique ci-dessus, je vais pr\u00e9senter \u00e9tape par \u00e9tape toutes les menaces possibles et sugg\u00e9rer comment les combattre. Entrons dans le vif du sujet !<\/p>\n Il y aura des divergences dans les vision du produit<\/a> depuis le d\u00e9but. Pourquoi ? La raison est tr\u00e8s simple : chacun interpr\u00e8te la r\u00e9alit\u00e9 \u00e0 sa mani\u00e8re, a une id\u00e9e de quelque chose en t\u00eate et peut ne pas pr\u00e9senter cette vision avec pr\u00e9cision \u00e0 l'autre partie. Si vous d\u00e9crivez avec des mots un produit que vous aimeriez fabriquer, il y a de fortes chances pour que l'autre partie ne puisse pas le faire. \u00e9quipe de d\u00e9veloppement<\/a> comprendront votre vision d'une mani\u00e8re diff\u00e9rente de celle que vous aviez pr\u00e9vue.<\/p>\n Bien s\u00fbr, il est possible d'\u00e9viter cela. Vous devez commencer \u00e0 visualiser d\u00e8s que possible et discuter des \u00e9l\u00e9ments individuels des fonctionnalit\u00e9s du produit sur la base d'esquisses. Il est int\u00e9ressant de noter que les premi\u00e8res esquisses n'ont g\u00e9n\u00e9ralement rien \u00e0 voir avec le produit final. Toutefois, \u00e0 ce stade, le plus important est de rendre la vision coh\u00e9rente.<\/p>\n Vous vous demandez pourquoi la premi\u00e8re et la deuxi\u00e8me image sont si diff\u00e9rentes ? Le chef de projet examinera toujours de plus pr\u00e8s la vision du produit. Cependant, le chef de projet ne peut pas se contenter de regarder de plus pr\u00e8s la vision du produit, il est important qu'une telle personne, essentiellement responsable de l'ensemble de l'activit\u00e9 de l'entreprise, soit en mesure d'assurer la continuit\u00e9 de l'activit\u00e9 de l'entreprise.<\/strong> logiciel processus de d\u00e9veloppement<\/a><\/strong>, comprend parfaitement le probl\u00e8me et les besoins li\u00e9s au produit<\/strong>. Le chef de projet doit avoir une vision d'ensemble claire. Comme vous pouvez le constater, les deux images ne diff\u00e8rent pas en termes de fonctionnalit\u00e9. Elles ont simplement un aspect diff\u00e9rent. Pour mieux comprendre ce point, revenons \u00e0 la premi\u00e8re image. Au d\u00e9but du projet, il n'y avait pas de croquis, ce qui a d\u00e9j\u00e0 donn\u00e9 lieu \u00e0 un malentendu. La fonctionnalit\u00e9 du produit est correcte, mais le design est compl\u00e8tement diff\u00e9rent.<\/p>\n Parfois, les analystes et les d\u00e9veloppeurs ne connaissent pas les besoins des utilisateurs ou les objectifs commerciaux \u00e9tablis. Ils ne voient qu'une petite partie de l'ensemble du projet, qui capte leur attention principale. Ils ne sont pas en mesure d'adopter une perspective plus large, ce qui est particuli\u00e8rement vrai pour les projets de grande envergure, o\u00f9 de nombreux d\u00e9veloppeurs travaillent en m\u00eame temps.<\/p>\n Nous pouvons \u00e9galement utiliser un autre exemple. Il peut arriver que le probl\u00e8me \u00e0 r\u00e9soudre soit mal d\u00e9crit, par exemple par le propri\u00e9taire du produit. Il s'agit alors de fournir des informations incompl\u00e8tes sur lesquelles le d\u00e9veloppeur<\/a> ou le concepteur cr\u00e9ent leurs propres interpr\u00e9tations, et le produit s'\u00e9carte de plus en plus de la voie de d\u00e9veloppement pr\u00e9vue.<\/p>\n Comment changer cela ? Je pense qu'une bonne solution consiste \u00e0 s'assurer que les personnes qui jouent un r\u00f4le cl\u00e9 dans le projet ont une connaissance d\u00e9taill\u00e9e de celui-ci - ce que l'on appelle la \"vue d'ensemble\". En cas de malentendus, il leur sera plus facile d'apporter la solution au probl\u00e8me. processus de d\u00e9veloppement de logiciels<\/em> de revenir sur la bonne voie. Par cons\u00e9quent, n'oubliez pas que si chacun ne voit que son petit fragment de la fonctionnalit\u00e9 d\u00e9velopp\u00e9e, les malentendus dans la vision deviennent une menace probable.<\/p>\n Ici, l'affaire est simple. Le produit doit se vendre. Vous devez vous d\u00e9marquer d'une mani\u00e8re ou d'une autre, de sorte que, par exemple, une simple balan\u00e7oire pour votre jardin devienne un \u00e9l\u00e9ment extraordinaire. L'id\u00e9e est de convaincre un acheteur potentiel. Le service marketing et commercial fera certainement tout pour montrer que le produit est unique.<\/p>\n L'absence de documentation est un probl\u00e8me tr\u00e8s courant. Parfois, la cr\u00e9ation d'une documentation pendant d\u00e9veloppement de produits<\/a> semble \u00eatre une perte de temps inutile. C'est une erreur. Je dis tr\u00e8s souvent que les changements se font plus rapidement sur le papier que dans l'entreprise. code<\/a>et il y a de quoi faire. En outre, il est plus facile de se r\u00e9f\u00e9rer \u00e0 la documentation pour suivre les changements. Croyez-moi, un projet sans documentation risque fort de passer \u00e0 c\u00f4t\u00e9 de sa vision.<\/p>\n Cette \u00e9tape consiste \u00e0 placer l'environnement sur le serveur. Comme pour le point concernant les programmeurs et les analystes, sans un environnement de travail complet, il n'est pas possible de mettre en place un syst\u00e8me de gestion de l'environnement. donn\u00e9es<\/a> et avec des lacunes en mati\u00e8re de communication, il peut s'av\u00e9rer que seule une partie de l'environnement n\u00e9cessaire a \u00e9t\u00e9 cr\u00e9\u00e9e.<\/p>\n C'est le r\u00e9sultat d'une mauvaise communication, d'un manque d'information et d'un manque de confiance en soi. UX<\/a> etc. L'apparition d'erreurs augmente le temps de d\u00e9veloppement. Et le temps, c'est de l'argent, n'est-ce pas ? Mon conseil est de mener le projet conform\u00e9ment \u00e0 la m\u00e9thode Agile.<\/a><\/strong>Je suis persuad\u00e9 qu'en agissant ainsi, vous \u00e9viterez de tels probl\u00e8mes. Je ne doute pas qu'en proc\u00e9dant ainsi, vous \u00e9viterez de tels probl\u00e8mes.<\/p>\n Souvent, les clients se concentrent uniquement sur la cr\u00e9ation d'un produit et s'en tiennent l\u00e0. Cependant, nous vivons \u00e0 une \u00e9poque marqu\u00e9e par de nombreux changements et innovations technologiques, c'est pourquoi il est n\u00e9cessaire de maintenir une assistance technique constante. L'id\u00e9e est d'\u00e9viter une situation dans laquelle quelque chose cesse soudainement de fonctionner parce qu'il devient obsol\u00e8te et que le produit perd de sa valeur. Cet aspect ne doit pas non plus \u00eatre oubli\u00e9.<\/p>\n Nous avons atteint le dernier point. Observez l'\u00e9cart entre le premier et le dernier graphique. Apr\u00e8s tout, ils se rapportent tous deux au point de vue du client. Pourquoi en est-il ainsi ? Tout le monde dit que c'est aussi simple que cela \ud83d\ude42 Les r\u00e9sultats d'une enqu\u00eate diff\u00e8rent toujours des besoins r\u00e9els des personnes interrog\u00e9es. En r\u00e9pondant \u00e0 la question de l'enqu\u00eateur, les utilisateurs veulent se montrer sous leur meilleur jour. C'est pourquoi, ILS NE R\u00c9PONDENT SOUVENT PAS FRANCHEMENT<\/strong>mais plut\u00f4t d'une mani\u00e8re qu'ils pensent devoir r\u00e9pondre. En fait, ils ne veulent pas \u00eatre expos\u00e9s \u00e0 l'\u00e9valuation n\u00e9gative des autres. Voici un petit conseil pour vous : mentionnez dans les instructions qu'il n'y a ni bonnes ni mauvaises r\u00e9ponses.<\/p>\n O\u00f9 se situent les autres diff\u00e9rences ? Souvent, les gens ne savent pas ce qu'ils veulent vraiment. Tr\u00e8s souvent, les utilisateurs disent au d\u00e9part qu'ils ont besoin de 10 fonctionnalit\u00e9s dans le produit, alors qu'ils n'en utilisent en r\u00e9alit\u00e9 que 3, par exemple.<\/p>\n Comment r\u00e9soudre ce probl\u00e8me ? En plus de demander aux utilisateurs ce qu'ils veulent et ce dont ils ont besoin, permettez-leur de tester le produit, de pr\u00e9f\u00e9rence sur des articles authentiques pour maintenir la cr\u00e9dibilit\u00e9. Plus il y a de tests lors de la cr\u00e9ation des produits, plus il y a de chances que le r\u00e9sultat soit exact.<\/p>\n Si vous devenez membre d'une d\u00e9veloppement de logiciels<\/a> Dans le cadre de votre projet, souvenez-vous de mes exemples et tirez-en des conclusions afin de ne pas reproduire les erreurs susmentionn\u00e9es. Et n'oubliez pas que ces concepts sont tr\u00e8s importants dans la construction d'un produit (application) \u00e0 partir de z\u00e9ro :<\/p>\n - de l'UX et des tests, afin que vous puissiez savoir ce dont vos utilisateurs ont r\u00e9ellement besoin,<\/p>\n - la communication au sein du projet, de sorte que les personnes cl\u00e9s du projet disposent d'une compr\u00e9hension approfondie du probl\u00e8me et des besoins,<\/p>\n - d\u00e9velopper le produit conform\u00e9ment aux Agile<\/a>,<\/p>\n - n'oubliez pas l'assistance technique.<\/p>\n En savoir plus :<\/strong><\/p>\n - Comment g\u00e9rer efficacement les d\u00e9veloppeurs \u00e0 distance ? Le guide pour les CTO<\/a><\/p>\n - Python ou Ruby ? Quelle technologie utiliser pour le d\u00e9veloppement de produits ?<\/a><\/p>\nVous connaissez cette photo, n'est-ce pas ?<\/h2>\n
1. Comment le client a-t-il expliqu\u00e9 son id\u00e9e ?<\/strong><\/h2>\n
2. Comment le chef de projet l'a-t-il compris ?<\/strong><\/h2>\n
3. Comment l'analyste l'a-t-il con\u00e7u ? et<\/em><\/strong> 4. Comment le programmeur l'a-t-il \u00e9crit ?<\/strong><\/h2>\n
5. Comment le conseiller d'entreprise l'a-t-il d\u00e9crite ?<\/strong><\/h2>\n
6. Comment le projet a-t-il \u00e9t\u00e9 document\u00e9 ?<\/strong><\/h2>\n
7. Quelles op\u00e9rations ont \u00e9t\u00e9 install\u00e9es ?<\/strong><\/h2>\n
8. Comment le client a-t-il \u00e9t\u00e9 factur\u00e9 ?<\/strong><\/h2>\n
9. Comment a-t-il \u00e9t\u00e9 soutenu ?<\/strong><\/h2>\n
10. De quoi le client avait-il vraiment besoin ?<\/strong><\/h2>\n
R\u00e9sum\u00e9<\/strong><\/h2>\n