Que faire si le patron reporte toujours les décisions importantes concernant les exigences et la conception globale?


12

Lors du démarrage d'un nouveau projet, mon patron évite toujours de prendre des décisions fixes. Il dit généralement: ok, commencez simplement à écrire quelque chose et soyez aussi générique que possible. Lorsque vous avez terminé, nous regardons comment nous continuons. Son argument est fondamentalement que vous ne savez jamais et "développement agile".

Pour garder la question aussi générique que possible: que faites-vous si votre patron n'aime pas prendre des décisions?

Il suffit de s'y tenir et d'écrire du code qui pourrait subir une refactorisation lourde et une réécriture partielle quelques semaines plus tard? Ou continuer à discuter jusqu'à ce que le patron prenne au moins quelques décisions? C'est plus ou moins ma stratégie actuelle. Parce que c'est comme une loi de la physique, à un moment donné, quelque chose doit être livré. Soit parce que le patron du patron veut voir des résultats, soit parce que les choses deviennent ridicules à un moment donné.

J'observe également que mon patron critique presque tout. Même des suggestions basées sur les siennes ...


1
Selon les cours SICP, commencez à écrire du code dans LISP :)
Job

@Job - LISP est-il conçu pour ce flux de travail? ;)
Jimbo

Lisp (mais je recommanderais en fait Clojure) permet d'apporter des modifications drastiques à la conception. Lorsqu'il est utilisé correctement, il permet de construire des couches sur des couches d'abstraction et de changer d'avis, d'ajouter des fonctionnalités, etc. paulgraham.com/avg.html
Job du

Réponses:


12

Construire des prototypes

Commencez simplement à dessiner des écrans qui ne font rien au début (vous en avez probablement assez?)

Vous devriez être en mesure de le rendre partiellement fonctionnel lentement, et éventuellement de remanier une partie du mauvais code lorsqu'il devient plus clair ce que vous essayez de faire.

C'est un problème courant qu'ils ne savent pas ce qu'ils veulent jusqu'à ce qu'ils voient quelque chose et réalisent que ce n'est pas ce qu'ils veulent. J'ai trouvé que lorsque quelqu'un veut que vous commenciez simplement à construire un «cadre» ou quelque chose de «générique» comme ce qu'il vous dit, vous aurez juste des ennuis si vous essayez. Les frameworks sont déjà écrits, vous n'avez pas besoin de le faire.


Ce son est vraiment familier: «un cadre». Je devrais probablement attendre pour mettre les choses en pierre après avoir montré au moins deux ou trois démos / prototypes.
Jimbo

4
+1 Personne ne sait ce qu'il veut. Tout le monde sait ce qu'il ne veut pas. La critique est facile à obtenir et peut être informative.
JohnFx

4

Il y a plusieurs problèmes que j'ai rassemblés à partir de votre message: 0-Ce n'est pas votre travail de gérer le projet et ce n'est pas votre travail de rassembler les exigences des utilisateurs finaux. 1-Le patron ne connaît pas les exigences exactes 2-Le patron ne parle pas aux utilisateurs finaux des exigences 3-Le patron lance une terminologie qu'il ne comprend pas vraiment agile 4-Vous travaillez sur une solution qui écrit plusieurs fois et vous n'êtes pas content

Quant aux 1,2 et 3, il n'y a pas grand-chose à faire si vous n'êtes pas une personne âgée. Cependant, les actions suivantes peuvent être effectuées:

A - Demandez-lui de partager avec vous le plan de projet. Il peut en avoir un ou en construira un indiquant les tâches et les délais. L'un d'eux devrait porter sur l'analyse et la collecte des exigences. Sinon, suggérez-le.

B - Préparer quelques références sur l'importance des exigences pour la réussite d'un projet logiciel

C - Préparez-lui une page de ce qu'est et n'est pas Agile.

D - Préparez-lui une liste d'entrées typiques à l'étape de la conception et convaincez-le de la valeur de chacun.

E - Suggérer l'ajout d'un analyste d'affaires et / ou d'un modélisateur de données à l'équipe. Ces rôles devront appartenir à l'utilisateur final et vous fourniront les informations requises ou au moins une bonne partie de celles-ci.

F - Voyez comment d'autres développeurs ont coopéré avec ce type.

Quant au # 4, vous pouvez lui suggérer d'utiliser une approche de prototypage ou un générateur de code qui l'aiderait, vous et l'utilisateur, à se faire une idée des aspects fonctionnels de l'application. La plupart des outils ne génèrent pas une interface graphique parfaite, mais au moins vous pouvez capturer les fonctionnalités requises.

Dans tous les cas, assurez-vous de documenter clairement chacune des itérations et de lui envoyer un e-mail concernant les informations que vous avez reçues, ce que vous avez fait (en détail) et le résultat. Assurez-vous d'attribuer les résultats à la cause appropriée, par exemple (manque d'exigences, etc.).

Malheureusement, certaines personnes n'acceptent pas les conseils. Faites donc attention à la façon dont vous communiquez avec lui.

Ça ne va pas bien!

Bonne chance.


Merci pour votre réponse détaillée! Ma position actuelle se situe entre junior et senior, du moins c'est comme ça que je me suis décrit pendant le A: il n'a personne qui n'est intéressé par aucun aperçu empirique. B, C: Pas maintenant ;-) Au moins sur le projet en cours, il en sait beaucoup sur les problèmes quotidiens. E est une bonne idée. Aujourd'hui j'ai écrit une petite démo, on en parlait beaucoup aujourd'hui. Bien que j'étais étonné de voir combien de points il n'était pas satisfait. Pouvez-vous expliquer ce que vous voulez dire par D?
Jimbo

La conception nécessite des entrées. Par exemple, modèle de données (créé lors de l'analyse), règles métier, exigences de sécurité, cas d'utilisation, architecture essentielle (s'agit-il d'un site Web, de formulaires Windows ou de quoi). Les entrées diffèrent par le nom de la mehtodologie, cependant, elles conduisent toutes à faire comprendre au développeur à quoi devrait ressembler la conception.
NoChance

4

J'avais un patron comme ça - en fait, je plaisantais que sa devise était "l'indécision est la clé de la flexibilité".

Quel que soit le travail de développement que vous effectuez, vous êtes probablement mieux placé pour résoudre le problème du client que votre patron. Si vous ne savez pas quel est le problème que le client essaie de résoudre (ce qui n'est pas la même chose qu'une spécification), alors quelqu'un ne remplit pas correctement ses exigences.

Esquissez quelques mises en page ou créez un prototype non / semi-fonctionnel. Mais fais quelque chose. Il ne ressort pas clairement de votre message si vous créez un logiciel client complet ou des applications Web, mais la beauté de ces dernières est que vous pouvez publier tôt, publier souvent. Commencez avec les os nus et continuez à partir de là. Un faux départ ne fait pas de mal s'il fait dialoguer et prendre des décisions.

Nous avons un dicton autour de $ WORK (applications Web internes) pour nos clients: "Je vais vous donner quelque chose pour que vous puissiez me dire ce que vous voulez." Soyez prêt à jeter le premier brouillon, mais vous pourriez être surpris de voir à quel point vous en avez rarement besoin.


3

Faites-lui remarquer que les livres Agile suggèrent de reporter les décisions aussi longtemps que vous le pouvez mais pas plus que cela . Chaque décision a un point où elle doit être prise, et peut-être vous êtes là en ce moment.

D'un autre côté, remettez-vous également en question. Avez-vous vraiment besoin de décider quelle couche de persistance vous allez utiliser pour cette application? Ou pouvez-vous commencer à l'écrire dans un fichier CSV et à le conserver suffisamment abstrait pour prendre cette décision plus tard?


Les décisions techniques sont plus ou moins claires pour moi: les langages de programmation, comment choisir les bibliothèques ou les couches de persistance. Il a des opinions bien arrêtées là-dessus, et pour être honnête, je me fiche vraiment que ces choix soient sensés. Il s'agit plus de choses comme: à quoi ressemblera l'écran? Quel genre de choses l'utilisateur pourra-t-il faire et comment? J'ai déjà pensé que c'est beaucoup de mon travail de trouver des idées. Mais il n'est guère possible de proposer des idées abstraites et de lui demander s'il est d'accord avec une idée.
Jimbo

3

Écrivez votre propre document de spécification et tenez un examen où vous l'expliquez et il le signe. Ensuite, vous deviendrez patron, et votre patron abordera plus de problèmes de gestion interpersonnelle que de problèmes techniques.


2

Engagez une discussion sur la `` gestion ascendante '' avec votre patron et vos clients, trouvez des solutions, choisissez la meilleure solution à mettre en œuvre par votre équipe, trouvez les failles dans les autres et `` gérez '' votre manager pour qu'il prenne la `` bonne '' décision.

Et bien sûr, assurez-vous qu'il pense que c'était toute son idée. (surtout quand tout va mal!)


Quand les ingénieurs logiciels deviennent des ingénieurs sociaux .. :)
MattDavey

1
Sérieusement, la plupart des problèmes logiciels sont résolubles, c'est la communication avec d'autres sacs d'eau semi-sensibles qui est souvent le bit problématique ...
NWS

1

Vous devez concevoir et mettre en œuvre quelque chose. Puisque votre patron ne prendra pas de décisions, prenez-les vous-même. Prenez un peu plus de temps pour documenter vos décisions et hypothèses avant de les mettre en œuvre. Envoyez-le à toute personne concernée, y compris votre patron. J'espère que cette liste comprend plus que votre patron car cela lui mettra un peu de pression pour prendre certaines décisions car il sait que d'autres savent que vous êtes prêt à continuer. Vous serez surpris de la rapidité avec laquelle vous obtenez des commentaires lorsque vous mettez des décisions par écrit, surtout si vous prenez des décisions avec lesquelles d'autres personnes ne sont pas d'accord. En attendant, je procéderais avec les décisions que vous avez prises jusqu'à ce que le contraire soit dit.

Si vous avez fini par perdre du temps à mettre en œuvre ce que votre patron ne voulait pas, c'est à lui et non à vous puisqu'il était conscient du chemin que vous alliez emprunter.

De plus, certaines personnes ont du mal à démarrer, mais une fois qu'elles voient quelque chose de tangible, leur esprit entre en jeu. Peut-être que votre patron est comme ça et que vous lui dites ce que vous prévoyez de faire par écrit, ça le fera avancer.


0

Prenez vous-même vos décisions et commencez à coder. Bien sûr, le développement d'une manière flexible aidera (lisez les modèles, principes et pratiques agiles de Robert C Martin si vous ne l'avez pas déjà fait), mais toute la flexibilité du monde n'aidera pas si aucune décision n'est jamais prise. Il se peut que vous deviez simplement développer ce que vous pensezest nécessaire, puis en le modifiant selon les besoins. Souvent, les clients / patrons ne savent pas ce qu'ils veulent tant qu'ils ne le voient pas ou jusqu'à ce qu'ils voient quelque chose qu'ils ne veulent pas. Cela vous mènera probablement hors de la portée d'un développeur, mais c'est la vie. Je trouve souvent que mes collègues et moi prenons effectivement des décisions commerciales. Parfois, ceux-ci ne sont pas remis en question et les décisions que j'ai prises commencent à diriger l'entreprise, uniquement parce que personne d'autre ne prendrait la décision. Assurez-vous de répertorier TOUS vos hypothèses et décisions (sans exception) et de les présenter à votre patron.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.