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

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.

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).

... 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.

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.

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.

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.

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.

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 ).

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.

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.

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é"