Comment convaincre la direction de jeter un prototype?

J'adore le prototypage comme moyen efficace et rapide de mettre une interface utilisateur devant un utilisateur.

Bien souvent, la direction se met en travers du chemin et le prototype est traîné à coups de pied et à crier dans le développement du flux principal.

Comment gérez-vous la gestion pour ne pas faire cela?

Utilisez un outil comme Microsoft SketchFlow ou créez votre prototype dans un autre langage ou plate-forme, ce qui rend presque impossible l'intégration dans le développement principal.

Il y a aussi un essai de joelonsoftware sur la présentation de captures d'écran et de prototypes, où il fait apparaître les aspects non implémentés et non travaillés comme manifestement cassés / non implémentés, indiquant clairement où le travail doit encore être fait.

Corollaire important deux. Si vous montrez à un non-programmeur un écran qui a une interface utilisateur 100% belle, il pensera que le programme est presque terminé.

...

Que pouvez-vous y faire? Une fois que vous comprenez le secret de l'iceberg, il est facile de travailler avec lui. Sachez que toutes les démos que vous faites dans une pièce sombre avec un projecteur vont être uniquement des pixels. Si vous le pouvez, créez votre interface utilisateur de telle sorte que les pièces inachevées semblent inachevées. Par exemple, utilisez des gribouillis pour les icônes de la barre d'outils jusqu'à ce que la fonctionnalité soit là. Lorsque vous créez votre service Web, vous pouvez envisager de supprimer les fonctionnalités de la page d'accueil jusqu'à ce que ces fonctionnalités soient créées. De cette façon, les gens peuvent regarder la page d'accueil passer de 3 commandes à 20 commandes à mesure que de nouvelles choses sont construites.

Essayez donc de créer vos prototypes dans Photoshop au lieu de Visual Studio, ou quelque chose du genre.

Ne faites pas de prototype avec du code fonctionnel. Prototype au crayon et papier ou équivalent logiciel .

L'utilisation de maquettes ressemble à du dessin, mais comme c'est numérique, vous pouvez modifier et réorganiser facilement. Les équipes peuvent proposer un design et le parcourir en temps réel au cours d'une réunion.

L'utilisation du papier a l'avantage que les membres de l'équipe peuvent facilement intervenir, et tout le monde comprend que ce n'est qu'une feuille de papier vierge. Cela le rend moins précieux.

Ne compromettez jamais la qualité de votre code.

L'écriture de code indésirable est une fausse économie.

Comme d'autres affiches l'ont suggéré, vous pouvez y parvenir en utilisant des outils spécifiques pour les maquettes.

Cependant, il existe différentes raisons pour construire des prototypes. Parfois, vous pouvez montrer ce dont vous avez besoin sans écrire de code, mais ce n'est souvent pas le cas. Un intervenant peut souhaiter que vous démontriez la faisabilité technique d'une fonctionnalité.

Créez la chose la plus simple possible pour démontrer la fonctionnalité / prouver le concept. Oubliez tout le reste.

Pour une fonctionnalité d'interface utilisateur, assurez-vous de ne rien développer sur le serveur - ne le touchez pas du tout. Développez à nouveau les faux / faux intégrés.

Si vous devez vous efforcer de rendre l'interface utilisateur conforme au style du reste de l'application, ne vous embêtez pas. S'il semble assez bon sans aucun effort, changez les couleurs pour le faire ressortir, ou peut-être même un filigrane pour montrer qu'il s'agit d'un prototype.

J'ai trouvé que les contrevenants les plus susceptibles de transformer des prototypes en code de production sont des vendeurs. Ils vendront votre produit à un nouveau client - sans cette nouvelle fonctionnalité, le client n'aurait pas signé. Vous ne pouvez pas leur en vouloir, ils ont des cibles. Soyez prudent avec eux; assurez-vous qu'ils ne vous obligent pas à retirer les éléments qui indiquent qu'il s'agit d'un prototype. Vous devez tenir tête - ils ne devraient probablement pas induire les clients en erreur de toute façon.

Votre direction peut commencer à vous forcer à transformer un prototype en code de production pièce par pièce, si vous avez suivi mon premier conseil de ne jamais écrire de code merdique, il ne devrait y avoir aucun problème. Petit à petit, vous construisez le logiciel, sans compromis.

Ensuite, si la direction commence à vous forcer à réduire la qualité, vous devez vous demander pourquoi. Sont-ils passifs? faible? désespéré? Aucune de ces choses n'est une bonne raison de rester dans une entreprise.

Assez simple vraiment. Dites-leur qu'ils finiraient par perdre leur client préféré s'ils finissaient par mettre ce bazar pour spectacle.

Et oui, demandez-leur de tenter leur chance s'ils savent vraiment mieux.

Enfin: veuillez ne pas dire que le prototype a des bogues spécifiques A, B et C. Ensuite, vous seriez obligé de corriger ce bogue, et la direction prétendra qu'elle a canalisé l'énergie pour préparer la production de logiciels.

Il y a des chances avec ces bonus de performance et les futures attributions d'actions ces jours-ci, ils écouteront.

Éliminez le problème en premier lieu. NE LE TERMINEZ PAS. J'entends par là ne pas le rendre joli ou comme il correspond aux styles existants sur le site. L'objectif est simplement d'en obtenir la version de travail la plus brute possible afin que vous puissiez voir que le flux d'interface utilisateur très basique fonctionne. Si vous y ajoutez un style de site existant ou si vous le polissez excessivement, ils vont supposer que vous pouvez simplement le "brancher". La gestion est comme Pakleds de Star Trek. Ils veulent juste que vous «fassiez ça». Plus vous êtes prêt à le faire paraître, plus ils seront prêts à le croire.

Si cela ne résout pas votre problème, obtenez un emploi dans au moins une entreprise avec une marque bien connue pendant un an. Mettez votre e-mail et votre numéro sur un CV en ligne et vous combattrez les recruteurs avec un bâton, ce qui vous permettra de leur dire "absolument pas" avec la confiance d'un développeur qui sait ce qu'il fait et peut obtenir un nouvel emploi demain où, espérons-le, votre expertise en la matière sera prise plus au sérieux.

Je travaille actuellement sur une base de code qui n'en a pas deux mais un triple stack de Rails, .NET et Java. La raison pour laquelle nous avons fait clouer les Rails, c'est parce qu'un prototype a été fait dans Rails et que le meilleur chien de la société a dit "fais-le." Nous devons parfois dire non. Tant que nous ne le faisons pas tout le temps, ils devraient nous prendre au sérieux.

Mais oui, quoi que vous fassiez avec un prototype, assurez-vous qu'il démarre vraiment moche.

Ne vous en faites pas.

Si vous vous asseyez et lancez des contrôles d'interface utilisateur pour un "prototype", il n'y a aucune raison pour que vous jetiez automatiquement cette conception. Si c'était assez bon pour montrer la gestion, alors c'est un bon endroit pour commencer quand coder le "vrai" programme.

Passer d'un prototype à une interface utilisateur plus «raffinée» ne devrait être rien d'autre qu'une série d'étapes entièrement justifiables. Vous deviez ajouter un deuxième bouton. Vous avez reçu des commentaires d'utilisateurs qui ont trouvé la commande déroutante. Le groupe des normes de votre organisation a dicté un changement mineur. Vous avez dû modifier la taille d'une zone de texte pour l'internationalisation.

Pas une seule de ces raisons n'est "eh bien, c'était juste un prototype". Dans la conception de l'interface utilisateur ou dans le code ou par écrit, TOUT peut finir par vivre à jamais. Et ceux qui ne sont pas tous devraient avoir de très bonnes raisons de les tuer.

Et la direction s'en fiche probablement.

De façon réaliste, si la raison pour laquelle vous n'avez pas simplement déposé votre interface utilisateur dans le code existant était "j'ai dû le réécrire dans notre cadre correct", cela devrait être une raison suffisante. Et si ce n'était pas le cas, vous devriez probablement avoir une discussion sur le cadre d'interface utilisateur lui-même, mais c'est une autre question.

J'avais ce problème jusqu'à ce que je réalise que ce n'était pas un problème mais un moyen de me libérer des normes de développement plutôt obsolètes imposées à la plupart des magasins.

Vous dites donc à votre direction que vous écrivez un prototype, vous choisissez les technologies qui vous conviennent le mieux, pour ce domaine problématique, puis vous écrivez le logiciel en sachant qu'il ira en production.

Vous échappez à l'ennui des «applications doivent être en java 1.6 en utilisant le Web (insérer le moteur J2EE coûteux du choix de gestion)» et des normes de nommage inutiles, etc.

Mes prototypes actuels de langages de choix sont "php" (qui s'adapte totalement aux environnements de production lourds - il suffit de demander à Facebook) et la combinaison très élégante de Groovy / Java avec Tomcat ou Jetty.

La combinaison groovy / java est idéale pour un développement rapide. Groovy est agréable à utiliser, rapide à développer, mais fonctionne comme un escargot gériatrique, mais il est très facile de re-factoriser les sections critiques des performances en Java pur. Marier l'application à Tomcat ou Jetty signifie ne plus jamais avoir à faire face aux EJB et autres horreurs J2EE.

Le principal avantage d'avoir un prototype fonctionnel par opposition à un croquis tel que proposé par plusieurs affiches est la rétroaction des utilisateurs. Les prototypes sont un excellent moyen d'impliquer réellement l'entreprise dans la conception. Une fois qu'ils ont réalisé qu'ils peuvent dire des choses comme "ce champ ne devrait-il pas être sur l'écran principal" et hé hop! là, c'est sur l'écran principal à la prochaine démo qu'ils s'ouvrent et s'impliquent dans la conception apportant des années d'expérience commerciale précieuse au projet.