Le gestionnaire continue de changer les spécifications des exigences après chaque démonstration [fermé]


21

Contexte de mon environnement de travail

Mon responsable n'a aucune expérience ni aucune compréhension des ordinateurs ou des logiciels. Il est fort probable qu'il n'ait vu aucun code sous aucune forme (même à une distance physique de 10 pieds ou moins) dans sa vie.

Personne ne comprend la complexité de ce qu'on me demande de mettre en œuvre. Au point que si je semi-hardcode personne ne le saurait.

Au test de Joel, nous obtenons un score incroyable de 0.

Les problèmes

  • Le gestionnaire et parfois d'autres «hauts responsables» continuent de modifier les spécifications des exigences. Modifications qui, si une bonne ingénierie est effectuée et non des "correctifs" inégaux, nécessitent un changement dans la conception sous-jacente.
  • Il n'y a absolument personne qui regarde le code (probablement parce que personne ne sait comment, ou même si cela doit être fait), ce qui signifie que personne ne pourra jamais:
    • Appréciez la complexité du problème ou l'élégance de la solution.
    • Suggérer une amélioration de l'approche.
    • Appréciez la qualité du code.
    • Indiquez où le code peut être amélioré.
  • Beaucoup de jargon est utilisé, ce qui a un sens grammatical mais ne parvient à aucun sens d'une autre manière.
  • Ne se sent pas, ne se comporte pas ou ne fonctionne pas comme une entreprise de logiciels.

La question

Qu'est-ce qui devrait être fait? Surtout en ce qui concerne le fait qu'il n'y ait personne pour signaler des améliorations dans mon code.

Mise à jour

Pour répondre à la question de HLGEM (et peut-être d'autres) sur ce que j'ai fait pour essayer de le réparer. J'ai proposé de configurer Redmine et d'introduire le contrôle de code source à tout le monde. J'ai dit que je recommanderais la distribution (git ou mercurial) mais je parlerai également de celles centralisées et laisserai l'équipe décider. La réponse a été que les choses se font et le seront dans quelques semaines. Je n'ai pas vu cela et je ne sais pas si d'autres parties de l'entreprise l'utilisent.


36
pour anticiper la réponse évidente: RUN !!
keppla

3
À moins qu'il y ait quelque chose d'important, vous ne nous dites pas de commencer à chercher un nouvel emploi.
Zachary K

11
"Le manager et parfois d'autres" seniors "continuent de changer les spécifications des exigences." Eh bien, avoir une spécification vous marquerait 1 sur le test de Joel. : P
R. Martinho Fernandes

11
Aucune organisation n'obtient moins de 2 au test Joel uniquement en raison de gestionnaires non techniques. Il y a un certain nombre de choses que vous et les autres membres techniques de l'équipe pouvez faire sans la contribution de gestionnaires non techniques pour augmenter votre score. Vous n'avez aucune excuse pour blâmer cela uniquement sur le gestionnaire.
maple_shaft

6
On dirait que vous avez aussi l'équipe de vente en tant que gestionnaire de logiciels, je sympathise.
Wildpeaks

Réponses:


30

La version courte :

Courir.


La version un peu plus longue :

Si le gestionnaire ne sait pas comment gérer un projet, et si le senior le suit, vous n'avez pratiquement aucune chance de réparer les choses.

Pour gérer des projets logiciels, un gestionnaire doit comprendre quelque chose sur les logiciels. Si les gestionnaires ne le font pas, ils doivent d'abord apprendre. Quelles sont vos chances de persuader votre direction et vos cadres supérieurs qu'ils se sont trompés? Quelles sont les chances que vous leur appreniez quelque chose?

J'ai déjà été dans une situation similaire (seulement il n'y avait pas de senior). J'ai arrêté après une année terrible et je n'ai jamais regardé en arrière (sauf avec dégoût).


3
+1 pour cette citation: "Si le gestionnaire ne sait pas comment exécuter un programme, et si la personne âgée l'accepte, alors vous n'avez pratiquement aucune chance de réparer les choses."
maple_shaft

17

... continuez à modifier les spécifications des exigences. Modifications qui, si une bonne ingénierie est effectuée et non des "correctifs" inégaux, nécessitent un changement dans la conception sous-jacente.

Cela ressemble au monde réel. Cela arrive tout le temps, partout. Oui, ça craint, mais c'est supportable avec une sorte d'attitude agile. En outre, une des qualités du logiciel est sa malléabilité. Prenez-le comme un défi.

Beaucoup de jargon est utilisé, ce qui a un sens grammatical mais ne parvient à aucun sens d'une autre manière.

Encore une fois, cela ne semble pas si inconnu ;-)

Personne ne comprend la complexité de ce qu'on me demande de mettre en œuvre.

Pas même toi? Si vous comprenez cela, alors il y a une personne dans le miroir qui comprend cela. Votre responsabilité pour le bien-être de votre entreprise est donc probablement plus lourde que ne l'indique votre titre officiel. Si vous comprenez les problèmes et que votre directeur ne le comprend pas, il vous incombe de clarifier les choses à la direction afin qu'elle puisse correctement diriger l'entreprise. Il pourrait être raisonnable de supposer que vos managers les plus proches devraient être techniquement compétents (pas nécessairement aussi compétents que vous - alors qu'ils sont managers, vous êtes l'expert - mais au moins un tout petit peu compétent), mais s'ils ne le sont évidemment pas et vous pourriez les aider, pourquoi pas vous?

Une solution d'évasion simple consiste à changer d'entreprise. Mais comme une autre option, envisagez d'implémenter les éléments du test Joel. Bien que les éléments à partir de 5 nécessitent une plus grande coopération avec la direction, les éléments 1 à 4 sont tels que vous pouvez simplement les configurer sans demander à personne.

Cela dit, personne ici à SE ne peut connaître votre situation exacte. Il est possible que vous soyez dans une entreprise encombrée de secousses incompétentes, et que faire quelque chose de bien à partir d'un tel gâchis soit trop pour tout le monde. Vous devez évaluer la situation vous-même.


Qu'en est-il quelqu'un pour signaler mes torts? M'aider à m'améliorer et à apprendre.
Jungle Hunter

4
@Jungle Hunter: Il serait bien sûr plus facile d'être dans une entreprise où tout a été facilement mis en place, tout le monde suit déjà toutes les meilleures pratiques imaginables, etc. afin que vous puissiez simplement être l'apprenti et imiter les autres. Mais vous pouvez également vous améliorer et apprendre beaucoup en prenant la responsabilité et en étant vous-même actif dans l'amélioration de votre entreprise. L'amélioration et l'apprentissage sont finalement entre vos mains. D'autres personnes peuvent vous aider, mais votre patron n'a pas à être l'un d'entre eux.
Joonas Pulakka

Oui vous avez raison. J'essaie de m'améliorer, mais je pense que mes efforts sont davantage perçus comme des plaintes que des tentatives d'amélioration. Honnêtement, mes efforts sont les deux, mais voyons si je peux les amener à voir la seconde moitié - essayer de s'améliorer.
Jungle Hunter

@Jungle Hunter: Je vois, la frontière entre se plaindre et s'améliorer peut être floue . Mais cela ne fait jamais de mal de pencher vers le côté constructif.
Joonas Pulakka

4
@Joonas: J'ai été dans des entreprises où j'ai introduit VCS, des revues de code, donné des séminaires C ++, et ainsi de suite, pour améliorer la qualité du code. Et j'ai été dans une entreprise à peu près comme le décrit l'OP. Si c'est un cas désespéré, vous devez admettre la défaite et chercher un emploi où votre lutte est récompensée en vous permettant de réussir.
sbi

16

Vous dites dans l'un des commentaires que c'est votre premier travail. Les gestionnaires ne sont souvent techniques nulle part, sauf une boutique de logiciels dédiée selon mon expérience. Cela fait partie de la vie, il suffit de s'y habituer.

Vous pleurez et gémissez parce qu'il n'y a personne pour apprécier l'élégance de vos solutions. Le vrai problème ici n'est pas qu'il n'y a personne pour apprécier l'élégance de vos solutions, mais qu'il n'y a personne pour vous apprendre que vos solutions ne sont pas aussi bonnes que vous le pensez. Pratiquement tous les nouveaux programmeurs surestiment leurs compétences réelles. Sans mentor, il n'y a personne pour vous aider à améliorer vos pratiques. S'il n'y a personne pour vous encadrer, rejoignez des groupes d'utilisateurs locaux, participez activement et demandez à quelqu'un de vous encadrer. Encore mieux, cela vous aidera éventuellement à trouver un meilleur emploi.

Vous marquez un zéro au test Joel? Si vous êtes le seul codeur (et il semble que vous l'ayez écrit), pourquoi n'utilisez-vous pas le contrôle de code source? Qu'est-ce qui vous empêche? Si vous n'êtes pas le seul codeur, pourquoi personne ne peut-il réviser le code? Tous nos développeurs font de la révision de code, ce n'est pas une fonction de gestion, surtout lorsque les gestionnaires ne sont pas techniques.

Les exigences changent à peu près partout. Les besoins des entreprises changent continuellement et les non-programmeurs ne peuvent souvent pas visualiser ce que le programme fera jusqu'à ce qu'ils voient quelque chose. Ensuite, ils réalisent que ce n'est pas ce dont ils ont besoin. C'est pourquoi Agile a vraiment vu le jour parce que les anciennes méthodes ne géraient pas bien ce changement.

Configurez le suivi des bogues même si la direction ne souhaite pas saisir elle-même les données. Soyez responsable de la saisie de nouveaux bogues / fonctionnalités lorsque quelqu'un vous les mentionne. Cela aide vraiment de pouvoir dire au manager quand il veut un changement que l'on vous a attribué 27 autres choses et voici la liste, laquelle voulez-vous que je descende dans la liste des priorités pour accueillir ce nouveau changement. Cela vous aidera au moment de la révision, car vous pourrez compter le nombre de corrections de bogues et de fonctionnalités que vous avez mises en œuvre. Si tout le monde ne l'utilise pas, vous pouvez au moins le faire pour votre propre travail. S'ils ne vous permettent pas d'installer un logiciel, utilisez une feuille de calcul Excel. Prenez une initiative. Une fois que vous pourrez montrer les résultats, d'autres seront plus intéressés. Si vous pensez qu'il y a trop de travail pour une seule personne, le traqueur de bogues vous aidera à le prouver.

Ne fournissez pas de démos élégantes! Les démos doivent avoir l'air d'être gribouillées au stylo sur une feuille de papier. Plus l'interface est soignée, plus la personne non technique pense qu'elle est terminée.

Même si personne ne saurait si vous ne suivez pas les meilleures pratiques et le code semi-dur par exemple, vous le saurez et vous aurez de mauvaises habitudes. Cela ne vous servira pas bien dans votre prochain emploi. Faites donc les choses aussi près que possible de la bonne façon dans les circonstances. Assurez-vous d'écrire des tests (considérez cela comme faisant partie du temps de développement et mettez le temps de le faire dans toutes les estimations que vous donnez à la gestion même si vous ne dites pas spécifiquement que cela fait partie de l'estimation) et utilisez ces tests pour vous assurer les changements ultérieurs ne cassent pas autre chose.

Vous devez voir cela comme une opportunité inestimable de croître et de s'améliorer. Vous avez plus de liberté dans le codage réel que beaucoup de gens en ont à ce stade de votre carrière. Considérez donc cela comme une opportunité de créer un portefeuille de projets mis en œuvre avec succès. Lorsque vous allez chercher ce prochain travail, être capable de souligner des réalisations telles que le contrôle de source institué, le suivi des bogues institué, le nombre X créé d'implémentations de projet réussies, etc., vous fera vous démarquer du reste.

Vous avez également une excellente occasion ici d'apprendre à gérer les attentes à la hausse. C'est un atout qui vous sera utile pour le reste de votre carrière. Vous n'avez rien à perdre en essayant de faire cela ici, les choses ne sont déjà pas bonnes. Mais vous pouvez apprendre plus tard les compétences politiques qui vous aideront dans de meilleurs endroits. Apprenez à faire une analyse coûts-avantages. Apprenez à comprendre le domaine des affaires afin d'être convaincant lorsque vous leur parlez. Apprenez à parler en termes d'avantages pour l'entreprise et de profit. Faites des estimations pour chaque tâche qui vous est assignée et même si elles ne correspondent pas à ce que la direction vous donne, gardez une trace de ce que vous avez estimé et de ce qu'il a réellement fallu pour améliorer votre propre capacité à estimer le travail. Une fois que vous pouvez montrer que vos estimations ont toujours été plus précises que celles de la direction, ils seront plus susceptibles d'écouter lorsque vous leur direz que l'estimation est trop basse. Mais vous devez d'abord établir des antécédents à la fois d'estimations plus précises et, surtout, de la capacité de livrer les projets et de les faire fonctionner. Encore une fois, c'est une bonne compétence à avoir lorsque vous progressez dans votre carrière.

Surtout ne soyez pas passif et attendez-vous à ce que l'amélioration vienne d'en haut.


1
Cette réponse comporte des parties très utiles. Et certaines choses que je ressens sont incorrectes quant à la compréhension de ma situation. Comme, je mentionne les deux cas, personne à apprécier quand c'est bon. Personne pour signaler quand je me trompe. J'utilise le contrôle de code source, mais dans une équipe de 2-3 personne ne le fait. Le code, quand est partagé, est partagé à l'aide de clés USB et d'Airdrop. Si vous lisez le commentaire, je pense que j'ai également mentionné que j'ai configuré Redmine sur mon ordinateur portable qui finit par être utilisé uniquement par moi. Et même avec git. J'ai essayé de les mettre en œuvre pour tout le monde. Mon niveau, tout juste sorti de l'université. Senior est censé coder mais ne le fait pas.
Jungle Hunter

Je vais suivre les conseils pour construire un track-record. Je me souviendrai que j'ai plus de liberté à mon stade que d'une manière générale. Je pourrais apprendre à gérer les attentes et d'autres compétences politiques et générales.
Jungle Hunter

3
Arrêtez de leur donner du code sur les clés USB. S'ils veulent votre code, dites-leur qu'il est en contrôle de code source et montrez-leur comment l'utiliser.
Hugo

1
@JungleHunter Lorsqu'ils vous demandent votre code, dites-leur que vous êtes à mi-chemin d'un changement qui ne fonctionnera pas, mais ils peuvent obtenir la dernière version stable du contrôle de code source.
Kirk Broadhurst

1
@HLGEM "Tu pleures et tu gémis"? Beaucoup trop sévère, downvoting pour cela seul.
Ben H

6

Si j'étais vous, j'essaierais de trouver un autre travail. Pourquoi? Je pense que vous savez que, malheureusement, votre manager est "pas bon". Vous devriez cependant essayer de travailler avec votre manager.

Si vous ne voulez pas partir et / ou que vous n'allez parler à personne, alors vous devrez trouver quelque chose vous-même. Si personne dans l'entreprise ne connaît votre code, comment votre responsable est-il censé savoir que vous répondez aux exigences? Je dis juste.


Il regarde juste une démo. Dit, changeons ceci de cette façon et cela de cette façon. Et puis il y a un flot de jargons.
Jungle Hunter

2
@Jungle, je ne mettrais donc pratiquement pas de travail dans les démos, car elles vont changer énormément une fois qu'il les aura vues. Il ressemble à une personne visuelle avant tout. Avez-vous essayé de lui faire des captures d'écran de différents cas d'utilisation? Cela peut être beaucoup plus facile à assembler que les prototypes fonctionnels.
maple_shaft

@maple_shaft: Je pense que c'est une excellente idée.
Jungle Hunter

1
@maple_shaft: Ou peut-être au lieu de livrer beaucoup à l'avance, livraison juste vers la fin. ;)
Jungle Hunter

1
Conseil d'emploi d'un

4

Parlez-en à votre manager et aux seniors. Expliquez vos problèmes et proposez des solutions. Préparez un peu la conversation afin de connaître le message général que vous souhaitez transmettre.

Après la conférence, donnez-lui un peu de temps . Voyez si les choses changent ou non. Si ce n'est pas le cas, essayez de mettre en œuvre les changements vous-même et montrez au gestionnaire et aux personnes âgées les résultats positifs de vos changements .

Si la discussion n'aide pas et que vos modifications sont rejetées, vous devez évaluer par vous-même combien vous aimez travailler à cet endroit. Oui, le travail peut être mauvais, mais peut-être que le salaire est bon et que vous n'avez qu'un trajet de 5 minutes? Les aspects positifs de votre travail l'emportent-ils sur les négatifs? Si ce n'est pas le cas, je commencerais à chercher un nouvel emploi.


1
J'ai parlé. J'ai proposé de mettre en place un système de billetterie, un contrôle de version introduit mais il s'en fiche. Ou comprenez. Ou les deux. Je lui ai demandé de lui parler d'une spécification fiable et il est d'accord. Le change néanmoins. Il n'est pas axé sur les données. (Oh et supprimé l'accent mis sur le texte de ma question.)
Jungle Hunter

2
@Jungle: Exécutez ensuite ASAP.
sbi

1
Je suis d'accord avec sbi, si vous n'aviez pas déjà demandé de vous faire abattre, vous auriez pu légitimement sortir et le faire vous-même. Vous avez déjà perdu la chambre et si j'étais dans votre situation, je commencerais à chercher.
maple_shaft

3

Votre problème est que les systèmes de billetterie et le contrôle de version sont des questions TECHNIQUES et vous devriez le faire indépendamment de l'entrée d'un responsable non technique. Cela devrait être considéré comme une meilleure pratique sur le plan technique et s'ils n'ont pas cette configuration, vous devez vous en charger pour que cela se produise.

Vous ne pouvez pas vous attendre à ce qu'un responsable non technique comprenne les avantages du suivi des défauts, du contrôle des sources et de l'intégration continue. C'est pourquoi ils ne sont pas techniques, ils ne sont pas censés le savoir ou s'en soucier, ils sont des experts en connaissance de domaine et en affaires. La seule chose qu'ils devraient fournir est une direction et des exigences de haut niveau.

J'ai également un manager non technique et j'ai pu augmenter le score du test Joel de 4 à 8 simplement parce que je suis allé les faire et que je n'ai pas demandé la permission.

Votre groupe a besoin d'un solide leader technique et personne n'est intervenu.

Consultez http://community.rallydev.com/ ils ont une édition communautaire qui fait un excellent travail de gestion de projet Agile et de suivi des défauts. Cela seul augmentera votre score Joel et ne vous coûtera AUCUN espace ou temps de serveur pour la configuration.


Oui! C'est, je pense, le problème majeur. Nous n'avons pas de leader technique solide.
Jungle Hunter

2

S'il s'agit d'un petit magasin où vous et l'autre "senior" êtes fondamentalement les seules personnes à coder, alors il pourrait en fait être de votre responsabilité d'indiquer au responsable ce qui doit être fait pour satisfaire le "test Joel".

Les changements dans les exigences seront toujours là, et votre travail consiste à les adopter, ce qui est l'un des principes de base du développement agile :

Bienvenue aux exigences changeantes, même en retard de développement. Les processus agiles exploitent le changement pour l'avantage concurrentiel du client.

Mais s'adapter aux exigences changeantes signifie également suivre d'autres principes agiles. Au niveau de la direction, cela signifie que le gestionnaire doit être en mesure de présenter de manière transparente au client que tous ces changements ont un coût: soit la portée du projet doit être modifiée pour respecter les délais, soit les délais doivent être décalés (ce dernier n'est pas recommandé).

S'il s'agit d'une sorte de projet où votre manager est celui qui répond à toutes les exigences, alors vous devez agir comme s'il était votre client agile et leur expliquer la même chose (portée <--> compromis sur les délais ).

Mais au niveau du développeur dans une petite entreprise, je dirais qu'il est de votre responsabilité de vous assurer que la partie codage est conforme aux recommandations agiles.

Voici quelques étapes que vous devez absolument faire, et vous devrez probablement les faire vous-même:

  • vous devez avoir un système de contrôle de version (prend un jour pour le configurer pour une petite équipe)
  • vous devez avoir des scripts de construction pour vous assurer que vous pouvez faire des versions souvent (assez rapide à configurer également)
  • vous devez utiliser des tests unitaires automatisés (c'est une façon de coder, et cela dicte radicalement toute votre conception, il peut donc être difficile de les ajouter au milieu d'un projet étroitement couplé)
  • vous pouvez également mettre en place un système d'intégration continue pour assurer des builds et des tests automatisés, ainsi que des tests fonctionnels et GUI (qui sont un peu plus difficiles à écrire)

N'oubliez pas que vous pouvez avoir un référentiel SVN localement sur votre propre machine. Une simple liste TODO pourrait servir de système de suivi des bogues du pauvre (un peu extrême, mais bon). Et il n'y a aucune excuse pour ne pas avoir de scripts de construction.

De plus, avant de faire des déclarations sur les compromis de portée / échéance, quelqu'un doit également faire des prédictions sur le temps que prendra une certaine fonctionnalité. Cela se fait généralement dans les "jours idéaux" dans un monde agile, ce qui signifie que vous devez faire de votre mieux pour prédire l'effort relatif de chaque fonctionnalité, puis utiliser votre vitesse de codage réelle pour voir dans quelle mesure vous avez prédit (et mettre à l'échelle la "courbe" en conséquence ).


Pour "l'avantage concurrentiel du client" est la clé. Plus tard dans la journée, je lui ai demandé pourquoi il faisait cela, dit-il, pour impressionner le client. : |
Jungle Hunter

J'ai git / mercurial en place pour moi. Mais je fais les tests manuellement en ce moment. Je devrais me pencher sur les tests unitaires automatisés.
Jungle Hunter

1

Je pense qu'il manque des niveaux de responsabilité dans votre équipe. Il devrait y avoir un chef de projet, un analyste des systèmes, un analyste commercial et des développeurs. Le rôle de chef de projet est responsable de la définition et de l'application de la stratégie de communication client-projet (entre autres tâches).

Les gestionnaires ne sont pas tenus de comprendre le code ou les complexités. La nécessité de comprendre, les ressources, les coûts et les risques.

Les versions du code source, la qualité du code, la complexité, etc. sont sous la responsabilité du gestionnaire de projet ou du développeur principal.

La solution consiste à:

1-Définir la structure de l'équipe projet et ses responsabilités

2-Eduquer le manager en cas de pannes logicielles dues à une mauvaise gestion - Restez à l'écart des détails techniques. Vous pouvez trouver quelques exemples en recherchant sur Google.


"Restez à l'écart des détails techniques." J'essaierai de résister. ;) Merci d'avoir fait remarquer cela.
Jungle Hunter

0

Surtout en ce qui concerne le fait qu'il n'y ait personne pour signaler des améliorations dans mon code.

Ne pourriez-vous pas essayer de configurer des révisions de code afin que des personnes consultent le code? Existe-t-il des conventions et des normes qui aideraient à structurer le code? Cela suppose que vous n'êtes pas le seul développeur là-bas bien sûr.

Bien que vous soyez probablement dans un endroit peu génial, semble-t-il que cela fonctionne à la fin? Les projets se font-ils et les choses avancent-elles? Les choses se font-elles? Le Duct Tape Programmer serait l'article de Joel que vous voudrez peut-être lire.


J'ai pensé à changer mon équipe en une équipe qui a des gens qui peuvent consulter mon code. Ou essayez d'entrer en contact avec les gens là-bas pour revoir mon code. Comme je l'ai dit dans les questions, à l'heure actuelle, personne ne peut le faire.
Jungle Hunter

0

Option 1 - dites-leur «avec toutes les modifications que vous apportez à ce projet, au moment où nous le déployons, le système fonctionnera très lentement» ou «le client ne pourra pas le comprendre». Vos managers ne se soucient pas du code spaghetti mais ils se soucient du client. Présentez-leur le problème en termes de ce qu'ils comprennent, pas en termes d'écriture de code.

Option 2 - donnez-leur ce qu'ils veulent. Quand ils se plaignent de quelque chose que vous dites "mais c'est ce que vous avez demandé"


Avant de "courir", je vais faire exactement cela. S'ils veulent du changement, je leur ferai savoir que ce n'est pas un changement mineur ici et là, donc cela prendra beaucoup plus de temps. Lorsque le client ne semble pas heureux, il n'a rien à redire car je lui ai donné ce qu'il voulait.
Jungle Hunter

@jungle hunter - Tout le monde n'a pas la possibilité de quitter son emploi, il faut parfois transcender la situation. J'ai trouvé que la meilleure façon de gérer la folie est de la renvoyer aux fous. Seuls les très fous peuvent argumenter contre leur propre folie. bonne chance.
jqa
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.