Faire face à une gestion qui ne voit pas la valeur des améliorations qui ne sont pas immédiatement visibles pour l'utilisateur

90

Je peux comprendre la pression de l'horaire. Vous voulez faire plaisir à vos utilisateurs, car ils sont la pierre angulaire de l'entreprise. Cependant, il est également vrai que certains changements faciliteront les choses à long terme. Malheureusement, la direction de mon organisation a une résistance instinctive à de tels changements et cette résistance est si forte qu'elle empêche des améliorations à long terme.

Par exemple, Apple a récemment introduit le comptage automatique des références pour les programmes iOS. Il s'agit d'une amélioration majeure par rapport aux appels avec rétention / libération manuelle que l'on utilisait auparavant. Le code est plus facile à écrire et à maintenir. Le passage lui-même est susceptible de produire des accidents. Mais une fois que ceux-ci seront résolus, le nombre d'accidents étranges et aléatoires diminuera probablement.

J'ai récemment mentionné à mon patron que je voulais passer au comptage automatique des références. Il a répondu qu'il souhaitait se concentrer sur des améliorations visibles. Il est probable que cette réponse a été motivée par la pression qu'il subit de haut en bas - et probablement du PDG.

Il y a beaucoup d'exemples similaires. Le point commun est que quelque chose doit être corrigé, mais que les coûts à court terme du correctif l'emportent sur les avantages à court terme, où "à court terme" est défini comme "dans les prochaines semaines".

Comment dois-je gérer la situation?

EDIT: Merci pour les réponses. Laissez-les venir. En raison de la pertinence de ma situation, je devrais préciser que mon directeur et le directeur général sont tous deux des programmeurs - même si le directeur général a peut-être déjà oublié comment cela se passe. Apparemment, leurs programmeurs ont été submergés par d’autres pressions.

nameWithHeldToProtectTheGuilty
la source
2
Parlons-nous d'applications critiques à longue durée de vie? Peut - être que la mise sur le marché est plus importante que la maintenabilité et la qualité du code?
Andres F.
Je pense que ce n'est pas seulement un problème dans le développement de logiciels, mais dans l'industrie en général. Les clients paient uniquement pour ce qu'ils voient. Et comme la plupart des clients ne comprennent pas comment les produits sont fabriqués, ils ne sont pas disposés à payer pour des améliorations de qualité réelles mais non quantifiables. Et les gestionnaires pensent souvent de la même manière.
Giorgio

Réponses:

141

Vous parlez vraiment de dette technique. Peut-être qu'une métaphore aiderait vos gestionnaires. Je compare souvent l’effet de la dette technique en logiciel à la cuisson dans une cuisine sale. Si l'évier, les comptoirs et la cuisinière sont remplis de vaisselle sale et qu'il y a des déchets sur le sol, la préparation du repas prend plus de temps. Cependant, le moyen le plus rapide de préparer le prochain repas est de contourner le désordre. Nettoyer la cuisine et la garder propre retardera le prochain repas, mais améliorera la livraison de tous les repas suivants. Et tout comme la personne affamée dans la salle à manger ne peut pas voir la cuisine en désordre, et ne comprend pas pourquoi vous voulez nettoyer avant de commencer à cuisiner, votre direction ne peut pas voir le désordre dans le code. Vous devez soit leur montrer le désordre, soit montrer les problèmes de qualité et les retards causés par le désordre.

Peut-être pourriez-vous aussi parler de tâches urgentes et de tâches importantes. Lorsque des tâches importantes ne sont pas terminées, les tâches urgentes prennent plus de temps et coûtent plus cher.

kevin cline
la source
2
J'ai traité ce problème à plusieurs reprises dans de nombreux emplois. Je recommande de lire "Driving Technical Change" de Terry Ryan pour avoir des idées sur la manière dont vous pourriez mieux aborder vos managers avec ces problèmes. pragprog.com/book/trevan/driving-technical-change
Adrian J. Moreno
2
En fait, de la question, je ne sais pas combien de dette est réellement contractée. Bien que le comptage automatique des références ressemble à une mise à niveau requise, je ne connais pas suffisamment le domaine pour savoir si "le nombre de collisions aléatoires aléatoires va probablement baisser" ou non. <p> Ce n’est pas parce que la nouvelle syntaxe de Razor dans MVC 3 est plus propre que mon entreprise doit s’y installer aujourd’hui, ni même le mois prochain.
Joshua Drake
3
@Zenon Le terme "dette technique" n'est pas nouveau ...
Andres F.
5
+1: J'ai toujours aimé l'analogie de la "dette technique", qui semble parfaitement correspondre à notre métier. Vous n'êtes pas obligé de le cibler, mais vous paierez des intérêts sur le solde restant à payer. Cependant, nous devrions nous rappeler que cette analogie s'étend encore plus loin. Presque toutes les personnes / entreprises / pays ont des dettes en souffrance. Il est donc clair que les dettes ne sont pas aussi mauvaises que certains le prétendent. Je suis un développeur qui croit fermement aux pratiques de codage propres, mais je commence aussi à voir que la direction ne se trompe pas toujours et que la bonne solution consiste parfois à contracter un nouveau prêt.
DXM
2
Comme pour tout niveau de dette nationale, la meilleure solution consiste à l'ignorer et à laisser la prochaine génération s'occuper du gâchis
Gareth
47

Vous avez trébuché sur quelque chose qui affecte tous les programmeurs à un moment de leur carrière: ce code doit être remanié, il y a des problèmes d'architecture là-bas, ce module est en train de devenir intolérable, etc. En raison de la culture actuelle de votre organisation, on vous force à vous concentrer sur un travail qui ne produit que des avantages directement visibles .

C'est encore le classique Iceberg Secret . Le secret réside dans le fait que, tout comme un iceberg est à 90% sous l'eau, la majorité de tout projet de développement l'est aussi: 90% du travail sera totalement invisible pour l'utilisateur final. Ce code aura un impact sur l'utilisateur final, mais la direction a du mal à comprendre pourquoi vous avez passé six heures à refactoriser les appels de mise à jour / libération et de référencement automatique lorsqu'ils ne peuvent voir aucune différence et que tout fonctionne correctement.

Voici quelques faits que vous pouvez prendre avec vous sur cette question.

  • Les gestionnaires, à moins qu’ils ne soient eux - mêmes des programmeurs , ne comprendront pas le secret de l’iceberg.
  • C'est un problème d'ignorance, pas de malice. Le PDG veut un bon produit - il ne comprend tout simplement pas tout ce qui entre dans un bon produit.
  • Le PDG (et votre supérieur hiérarchique) ne sont pas stupides - étudiez et préparez des faits et des données concrètes expliquant pourquoi vous devriez consacrer votre temps à cela et à d’autres problèmes liés à Iceberg.

N'oubliez pas que vous êtes un homme ou une femme de compagnie. Pas un homme de code. Vous développez ce produit pour une entreprise intéressée par son succès ou son échec - vos projets et propositions de projet doivent en tenir compte. Montrez votre passion pour l'entreprise et le produit, montrez vos connaissances et prouvez à votre patron et à votre PDG qu'ils doivent vous faire confiance lorsque vous venez à eux et leur dire que Something Needs Work fonctionne. Montrez-leur en quoi cela contribuera au résultat final - que ce soit en ajoutant de la valeur au produit (plus de gens achètent des copies) ou en gagnant du temps (moins de clients en colère lorsque votre produit tombe en panne).

Jarrod Nettles
la source
1
C'est une excellente réponse, et certainement la voie à suivre. En fin de compte, vous devez être le PDG de votre travail et justifier votre travail en fonction de sa valeur pour l'entreprise. Une bonne chose à faire pour tout type de projet de type "refactoring" est d’articuler le retour sur investissement en termes de gain de temps de développement, d’opérations, de bugs, etc. Et avec les accidents, il semble que vous êtes sur la bonne voie.
katemats
Le problème n'est pas nécessairement l'ignorance. Parfois, la pression pour obtenir un produit sur le marché, satisfaire les besoins du client et un budget fortement réduit dépassent la nécessité de traiter des problèmes qui aboutiront finalement à une dette technique. Les besoins à court terme qui paient les factures seront toujours prioritaires par rapport aux besoins visionnaires à long terme qui ne donneront pas un retour sur investissement instantané. Tout ce que nous, les simples mortels, pouvons faire est de marcher doucement et d’essayer d’injecter chaque fois que nous le pouvons des modifications raisonnables, dans l’espoir que nous pourrons alléger le fardeau de la dette technique sans y contribuer trop lourdement.
S.Robins
36

Vous pas.

Je vois cette question et toutes les questions du même genre comme une impasse. Vous ne pouvez "convaincre" les gens de rien. S'ils ne sont pas déjà au courant de ce genre de choses ou s'ils n'enquêtent pas, il y a de fortes chances qu'ils ne cèdent pas. Et aucune quantité de données ne les convaincra autrement. Le changement doit venir de l'intérieur. Vous pouvez conduire un cheval à l'eau mais vous ne pouvez pas le faire boire.

Je dis que citez vos modifications souhaitées dans votre prochain devis technique. Soyez comme, hé, nous "devons" mettre à niveau ce nouveau framework introduit par Apple. Ne laissez pas ne pas utiliser ARC figurer sur votre feuille de route. Il n'y a pas d'options. migrer vers ARC est le seul moyen.

Mark Canlas
la source
10
Ce x100. C'est toujours comme ça que ça marche. S'ils ne comprennent pas que vous ne pouvez pas continuer à vous battre pour une base de code semi-active, ils ne comprendront jamais. Le mieux est de passer à autre chose et de trouver un endroit assez intelligent pour en prendre soin.
Wayne Molina
2
+1 Vous communiquez ce genre de choses par le biais d'estimations. Ce que vous devez faire, c'est définir l'espoir que vous fournirez des estimations tout au long du projet (en commençant dès que possible) afin que toutes les personnes impliquées puissent comprendre le retour sur investissement. Indiquez clairement qu'il s'agit d'estimations (elles ne changent donc pas sans davantage d'informations) et que vous les communiquez afin que les dirigeants puissent prendre de meilleures décisions. Ensuite, vous laissez les estimations démarrer la conversation pour vous. "Pourquoi l'estimation de cette phase est-elle plus élevée que la dernière?" "Bien ..."
nlawalker
1
vous pouvez réveiller une personne qui dort, mais vous ne pouvez pas réveiller une personne qui fait semblant de dormir
ViSu
2
si vous ne pouvez pas expliquer la dette technique au responsable, vous devez améliorer vos compétences en communication. Penser "ils sont idiots, je ne peux pas le comprendre" ne vous mènera pas loin ... Je soutiens le deuxième paragraphe selon lequel vous devriez vous affirmer et énoncer clairement les avantages pour l'entreprise.
siamii
1
Vous ne pouvez pas expliquer les choses aux personnes qui n'écoutent pas. Vous avez raison de dire que les compétences en communication sont importantes, mais c'est une voie à double sens. Aucune quantité de "compétences" en communication ne permettra de surmonter une gestion dysfonctionnelle.
Mark Canlas
28

J'ai déjà répondu à une question similaire ici, donc cela pourrait être considéré comme un doublon. En gros, vous n'allez pas avoir l'approbation de faire un "effort de refactoring". Pour rendre le code plus propre, vous devez suivre la règle du scoutisme: laissez toujours le code plus propre lorsque vous le quittez que lorsque vous êtes arrivé.

Tout comme rembourser une dette réelle peut sembler une tâche insurmontable (ou nettoyer une maison en désordre). Le truc est de le rendre meilleur morceau par morceau jusqu'à ce que vous commenciez à voir des "îlots de propreté". Une fois que vous aurez pris un élan significatif, les autres développeurs de l’équipe commenceront à remarquer et contribueront éventuellement à la tâche.

Je suggère de lire le Clean Coder de "Uncle" Bob Martin. Écrire un bon code fait partie de votre travail. Vous ne demandez pas la permission de faire votre travail, vous le faites simplement.

Michael Brown
la source
+1 pour "Vous ne demandez pas la permission de faire votre travail, vous le faites juste." Je trouve de plus en plus qu'être un bon développeur, c'est apprendre suffisamment pour avoir confiance en de tels besoins et affirmer son assurance.
leokhorn
7

Comme pour d’autres questions de cette nature, vous devez fournir des chiffres que la direction comprendra. Chiffres indiquant combien de temps sera économisé en appliquant ces améliorations, combien moins de "collisions bizarres aléatoires" se produiront, etc. Convainquez-les que les collisions sont visibles pour l'utilisateur final et que tout ce qui est fait pour les prévenir est bon pour les affaires.

Vous pouvez également essayer de mettre en œuvre ces améliorations sur votre propre temps (c'est-à-dire en dehors des heures de travail) et ensuite en montrer les avantages à la direction. Je ne le ferais que quand il est clair que la direction ne comprend pas ce que vous essayez de transmettre et / ou qu’elle ne veut pas vous laisser le temps de la tenter.

Bonne chance!

Bernard
la source
6
J'ajouterais que non seulement les pannes sont visibles par l'utilisateur final, mais qu'elles en éloignent également les utilisateurs . Il est bien connu dans l’industrie du marketing qu’il est beaucoup plus difficile de reconquérir un client précédent que de conserver les clients existants. Comment conservez-vous les existants? Assurez-vous que les choses qu'ils utilisent fonctionnent!
cdeszaq
Dans votre recherche d’une présentation convaincante, voici quelques documents de référence: en.wikipedia.org/wiki/Software_entropy , pragprog.com/the-pragmatic-programmer/extracts/software-entropy , codinghorror.com/blog/2009/02/ …
Abbaye de Macy le
7

Présenter une analyse de rentabilisation

Les recommandations des ingénieurs sont souvent ignorées pour de nombreuses raisons. La meilleure façon de traiter presque toutes les raisons est de présenter l’analyse de rentabilisation de la raison pour laquelle cela devrait être fait. L'analyse coûts / avantages classique. Cela constitue non seulement un argument convaincant, mais donne également à vos patrons quelque chose à apporter à leurs supérieurs hiérarchiques.

  • Quel est le coût initial?
  • Quel est le coût en cours?
  • Quelles sont les économies d'argent / de temps prévues et d'où viennent-elles?
  • Combien de temps faudra-t-il avant de voir le retour sur investissement?

Lors de l'analyse de rentabilisation, vous devez toujours sauvegarder vos arguments avec des données.

  • Combien de temps le développement consacre-t-il actuellement aux problèmes que cela éliminerait ou atténuerait?
  • Combien de plaintes des utilisateurs avez-vous liées aux problèmes que cela va supprimer ou atténuer?
  • Quels sont les autres avantages?

Alignez les nombres et faites-en une équation grossière mais simple. Cela coûtera à X et profitera à la société Y.

Remarque: Ne soyez pas surpris s'il est extrêmement coûteux de mettre en œuvre une bonne idée sur le plan académique.

dietbuddha
la source
6

Ce genre de changement tombe dans la catégorie refactoring. L’approche Agile consisterait à intégrer le temps de refactoring AMPLE à chaque récit que vous estimez et c’est exactement pourquoi. Mis à part les ingénieurs, personne ne comprendra pourquoi vous voulez faire cela et ce n'est pas grave, ce n'est pas leur travail de déterminer comment coder correctement, c'est à vous.

Alors, la prochaine fois que vous aurez du pain sur la planche, assurez-vous que ces changements en font partie. Si vous fournissez des estimations, veillez à ajouter 30% à votre estimation pour la refactorisation. Si vous ne fournissez pas d'estimations, effectuez simplement la refactorisation dans le cadre de votre travail.

Cela peut vous ralentir - eh bien non, ce n'est pas la bonne façon de voir les choses, mais votre vitesse actuelle est une illusion, essentiellement un mensonge que vous faites passer dans la chaîne, vous devriez plutôt être une peu plus lent à cause de ce travail qui, vous le savez, doit être fait.

Vous pourriez probablement construire des maisons plus rapidement si vous n’utilisiez pas le béton comme fondation - et elles sembleraient aussi bonnes au client mais - eh bien - même si le client ne voit pas le besoin de la fondation, le constructeur a besoin de. (Il s’agit en réalité d’un parallèle intéressant car il s’avère que les constructeurs ne font pas toujours ce qu’ils savent qu’ils devraient faire. Nous devons donc adopter des lois pour les y obliger; il n’existe pas de telles lois régissant le développement de logiciels, même si nous sommes confrontés aux mêmes problèmes. décisions et font souvent les mauvaises ...)

Bill K
la source
5

Vous dites que vous avez la chance que votre directeur et votre PDG soient tous deux des programmeurs. Ils comprennent donc probablement ce qu'est la dette technique.

Vous devez gérer la situation en essayant de résoudre la situation sur la base de faits, ce qui signifie qu'il est fort possible que vous ne finissiez pas par apporter les améliorations techniques souhaitées (les faits peuvent être agaçants de cette façon).

Votre travail consiste à vous assurer qu'ils comprennent les coûts et les avantages du remboursement de toute dette technique particulière que vous contractez. Leur travail consiste à décider si la meilleure utilisation des ressources consiste à les payer ou à faire autre chose.

Tout comme il peut être difficile pour des personnes non impliquées dans le code de voir les avantages de l'amélioration des éléments "cachés", il peut être difficile pour les programmeurs de voir les avantages des modifications de code visibles lorsque les avantages profitent quelque peu aux secteurs de l'entreprise " caché "des développeurs.

C'est bien si votre direction peut vous expliquer pourquoi les fonctionnalités visibles valent plus que votre temps à payer la dette technique, mais en réalité, ce n'est pas à vous de décider de toute façon. Donc, vous l'expliquer ne fait pas beaucoup pour l'entreprise, sauf vous garder heureux. Et d'une certaine manière, insister pour qu'ils le fassent, c'est ne pas leur faire confiance pour faire leur travail. Si vous n'aimez pas quand ils vous micro-gèrent, alors vous devriez comprendre.

Donc, tant que vous les tenez au courant de l'état de toutes les dettes techniques et des coûts et avantages de les ignorer plutôt que de les rembourser, vous avez fait votre travail. Sauf si vous ne faites pas vraiment confiance à la direction pour faire la leur, dans ce cas, vous avez un problème beaucoup plus important qui serait une toute autre question à résoudre.

psr
la source
2

Peut-être que ce n'est pas une réponse, mais une réponse basée sur des erreurs que j'ai faites. Également un désaccord avec certaines des philosophies que je lis ici.

  • Ne craignez pas que le programmeur sache mieux.
  • Être honnête. Re-factorisez au fur et à mesure mais ne mentez pas et ne calculez pas les estimations pour vos propres besoins.
  • Vous ne possédez pas le code. N'entreprenez pas de travail non approuvé par le responsable.
  • Vous pourriez avoir raison sur quelque chose; vous pourriez vous tromper ... mais vous devriez faire ce que vous êtes payé pour le faire.

Mais suivez certainement les excellents conseils donnés pour améliorer les choses.

utilisateur46558
la source
Oui, si vous voulez être un code-singe, allez-y et faites ce que vous "pensez" vous êtes payé pour le faire. Merci de perpétuer les mythes sur la programmation.
Zoran Pavlovic
2

Vous travaillez évidemment pour un patron aux cheveux pointus (PHB). Il ne programme plus, si jamais, et s'il l'a fait, il ne serait probablement pas vraiment bon (même s'il aime bien ajouter des phrases telles que "const correct" et "faute de segmentation" pour que les gars sachent qu'il a gagné ses galons ) - c’est comme ça qu’il s’est distingué pour la gestion.

Le PDG (qui a pratiquement un Mohawk) aime le PHB parce que le PHB offre des fonctionnalités . À chaque sprint, il affiche fièrement une nouvelle case à cocher (légèrement décalée, avec une étiquette ambiguë), une icône scintillante (ne fonctionnant pas encore dans n'importe quel environnement mais une couleur 8 bits sur Citrix) et une forme (avec des plantages aléatoires dus aux conditions de course base de données locale implémentée basée sur le C basé sur une variante xml implémentée que personne de l’équipe de dev n’ose toucher, car elle a été écrite par l’un des anciens légendes du dev dev il y a 10 ans et fait TOUT avec des macros avec 5 noms de lettre, qu’ils aient besoin de 5 lettres ou ne pas).

Les programmeurs qui font réellement le "travail" (vous savez ce qui se passe, ce qui est peu pratique après tout le travail réel, comme dessiner des cercles sur des tableaux blancs, crier et manger des Battenburgs miniatures) savent que, dans un système sain , le travail 10 gars, 10 jours à sortir péniblement de la jungle non entretenue, correspondraient probablement à un ou deux jours d’homme, tests inclus. Mais obtenir le système où il est sain d' esprit risque de prendre 6 mois de travail réellement difficile, avec très peu de récompense externe évidente.

Le PHB sait qu’en 6 mois, il pourra intégrer dans l’application trente ou quarante nouvelles fonctionnalités permettant aux vendeurs (qui doivent être des magiciens d’offrir ce qu’ils vendent) de tenter de nouveaux achats et d’améliorer .

Cependant, pour donner sa part au PHB: sans ces cases à cocher et formulaires, les ventes pourraient bien stagner ou baisser, un concurrent pourrait gagner des parts de marché, ce qui pourrait être pire que l’alternative.

La conclusion à laquelle je suis arrivé est que le seul moyen de sortir du bourbier est de travailler dans une nouvelle start-up, avec quelques personnes partageant votre vision de la manière dont les logiciels doivent être conçus, puis s'en tenir fermement à cette philosophie (I travaille encore pour y arriver!)

utilisateur23157
la source
1

Il existe un autre coût caché non mentionné dans les autres réponses. À savoir que les bons ingénieurs ont tendance à partir dans le type d'environnement décrit. En fin de compte, quiconque ayant l'ambition ou la capacité de refactoriser a quitté la société, la situation sera alors très pénible, probablement irréprochable. Malheureusement, vous ne pouvez pas dire cela à votre responsable sans paraître arrogant ("Je suis l'un de vos meilleurs programmeurs") et un imbécile perspicace ("Je partirai si vous ne faites pas ce que je veux"). Cependant, n'oubliez pas de le mentionner dans votre entretien de départ, pour vous assurer de ne pas être réembauché.

Kevin
la source
1

Vous avez raison et tous les deux tort. C’est pourquoi ces questions perdurent et créent des sentiments durs.

Les raisons pour lesquelles sont clairement énoncées ci-dessus: la direction pense en argent; ou même plus spécifiquement: les revenus. Pour eux, quelque chose qui a un coût mais pas de visibilité directe pour le client n'ajoute pas de revenus, donc c'est un mauvais plan.

Votre vision est également juste: ce sera bénéfique pour les clients mais à plus long terme. Vos actions pourraient générer des revenus encore plus importants à l’avenir par rapport aux plans à court terme.

Vous n'êtes pas le responsable, vous n'êtes pas directement responsable du revenu (je suppose bien sûr). Donc, vous vous mêlez (c'est ce que vous ressentez pour la direction) avec leurs problèmes et vous ne vous concentrez pas sur votre travail: développez davantage le logiciel.

Tous les mots durs et clairs, mais c’est comme cela que la plupart des problèmes se posent, en dehors des erreurs de communication. Vous voulez tous les deux la même chose, mais vos décisions à court terme sont prises différemment. Tout cela parce que le développeur a une perspective différente de celle du manager.

Comment résolvez-vous ce problème? Vous communiquez et vous comprenez assez bien sur un certain nombre de questions. Ce sera probablement l'accent mis sur l'engagement et la satisfaction des clients.

Pour résoudre ce problème de manière stable et future, mettez-vous d’accord sur un point: mesurer le coût de la correction de bogues dans l’ancien code. Mesurez également le temps nécessaire pour utiliser l’ancien logiciel et son utilisation avec la nouvelle base de code.

Pour prouver cela, vous pouvez faire par exemple cette chose très simple: branchez le logiciel dans votre versioning. Tout d'abord, faites ce que la direction veut, alors créez cette fonctionnalité. Vous faites cela, mais l'accord vous donne le temps de montrer la manière différente. Ensuite, faites la même chose dans la nouvelle catégorie, mais corrigez d’abord les problèmes que vous souhaitez résoudre. Ensuite, développez également la solution.

Maintenant, vous avez la même solution mais totalement développé différemment. Créez un dossier à partir de celui-ci, mettez les solutions les unes à côté des autres, y compris des informations de gestion telles que la stabilité, la quantité de code nécessaire et le code lui-même.

Maintenant, prenez un café ensemble et commencez à jeter un coup d’œil, sans vous demander qui a raison, mais quelle serait l’influence des deux directions pour la société. Cela créera une réunion vraiment utile et non pas une discussion meilleure, car cela ne créera pas l’atmosphère dont vous aurez besoin. Cela ne rendra pas votre produit meilleur.

Luc Franken
la source
0

Si vous avez une révision de code, créez un ticket technique indiquant que le code doit être amélioré à l'aide d'ARC et attribué au responsable.

Le convaincre. Expliquez-lui quelques exemples d'améliorations techniques similaires que vous avez apportées et ses avantages pour les projets.

java_mouse
la source
0

Vous devez vendre ces modifications de la seule manière que la direction est disposée à acheter:

Trouvez une fonctionnalité orientée utilisateur si convaincante que la direction doit la posséder, mais serait impossible à réaliser sans quelques améliorations de bas niveau du code.

Elad
la source
0

Il appartient à votre responsable de s’assurer que l’entreprise concentre son développement sur la fourniture de ce que les clients perçoivent comme une valeur ajoutée. Deux facteurs peuvent modifier cette perception:

  1. Combien de temps faut-il pour répondre à une demande client?
  2. Livrez-vous quand vous dites que vous allez?

La plupart préfèrent vous dire que cela prendra 6 semaines et que vous livrerez en 5 plutôt que de dire que vous livrerez en 3 mais que vous prendrez 4.

Disposer d'une base de code actuelle plus facile à gérer et à améliorer vous permet de livrer plus rapidement et d'améliorer la prévisibilité. Si vous passez trop de temps à corriger des bogues, vous disposez de moins de ressources pour ajouter de nouvelles fonctionnalités. Évaluez la quantité de ressources consacrées à la correction du code et la précision de vos promesses. C'est un moyen de déterminer si votre code actuel (selon la philosophie de votre patron) coûte trop cher.

JeffO
la source
En réalité, un responsable technique devrait s’occuper de la qualité du code et de la conception, et un responsable produit doit faire pression au nom des entreprises / des clients. Dans ce cas, il semblerait qu’un seul responsable fasse les deux avec un fort parti pris pour le produit.
Kevin
0

Permettez-moi de vous parler d'une opportunité de 2 milliards de dollars qui nous a presque échappé à cause de l'inertie de la direction.

Certains d'entre nous ont à cœur d'écouter la voix du client, c'est-à-dire de comprendre ce qu'il veut. Ce n'est pas toujours ce qu'il demande, mais si vous êtes en mesure d'entretenir des conversations avec votre client, vous finissez par arriver à une compréhension mutuelle de ce qu'il veut. (Ensuite, il peut explicitement commencer à le demander.)

Cela étant dit, il est important de comprendre qui devrait avoir cette conversation avec le client. En règle générale, vos collaborateurs chargés du développement des affaires sont accompagnés de certains concepteurs principaux. Si vous avez un concurrent, vous pouvez vous attendre à ce que le client ait également cette conversation avec lui.

Dans le même temps, il est important que les développeurs se tiennent au courant de leurs domaines, car il y aura une concurrence qui vous battra si vous ne l'êtes pas.

Dans notre cas, nous avions un client existant et un produit quelque peu efficace basé sur une technologie ancienne et le client avait besoin de mises à niveau rapides. Ce dont ils avaient vraiment besoin, c’était d’un produit de remplacement complet, mais l’esprit de notre société était que cela nous obligerait immédiatement à nous positionner, alors que la modification du produit existant permettait à notre client de continuer avec nous sans être légalement tenu de le rendre compétitif. Notre direction pensait qu'ils possédaient ce marché. Le problème était qu'ils ne pouvaient pas suivre les demandes de mise à niveau, car la structure du produit existant n'était pas suffisamment flexible pour effectuer la mise à niveau.

Le client est devenu impatient et a commencé à avoir des conversations avec des sources concurrentes. Nous avons perdu notre "propriété" de ce marché et quelques milliards de dollars de revenus. Cependant, une fois que le marché nous a mis dans une position concurrentielle, la direction n’a eu d’autre choix que de fermer ses portes ou de faire concurrence. (La plupart de ceux qui étaient des barrages routiers ont finalement été licenciés.) Nous avons participé à la compétition et avons pu reprendre l'entreprise par le fil le plus fin.

J'ai dit au début que cette opportunité nous avait presque échappé. Nous avons récupéré l'entreprise pour les revenus que j'ai mentionnés. Si nous avions été plus disposés à nous adapter aux préoccupations du client au début, il n'y aurait pas eu de concurrence réelle.

Voici ce que je vous propose: essayez toujours de rester à la pointe de vos capacités personnelles. Développez toujours un produit flexible et adaptable rapidement aux besoins de vos clients. Si vous travaillez trop longtemps pour une entreprise qui ne pense pas de la sorte, vous vous fanerez et votre motivation personnelle diminuera. Je l'ai vu arriver.

Lorsque vous avez une idée pour améliorer votre produit pour quelque raison que ce soit, posez-vous ces questions: - Est-ce ce que je pense que le client veut? Puis-je valider mes réflexions sur le développement du produit par rapport à la voix du client? Mon entreprise est-elle en mesure de répondre aux besoins de ses clients? Si c'est le cas, comment? - Vous devriez alors être en mesure de présenter des arguments convaincants concernant vos propositions de développement de produits.

Jim
la source
0

Le langage commun des affaires dans tous les domaines et industries est l'argent. Le problème que vous décrivez n'est pas un problème de programmation: c'est un problème commercial. Si vous souhaitez obtenir une réponse appropriée à une proposition commerciale, vous devez l'encadrer dans le langage de l'entreprise. Cela signifie que vous devez être en mesure de présenter un autre plan de projet incluant tous les coûts et avantages.

Vous devez en apprendre davantage sur des aspects tels que les coûts d'opportunité, le retour sur investissement (retour sur investissement) et la valeur actualisée nette (VAN). Vous n'avez pas besoin d'un MBA pour cela, mais vous avez besoin d'accéder à des données qui ne sont peut-être pas disponibles, telles que les coûts de main-d'œuvre, les frais généraux et le potentiel de revenus. Si vous pouvez expliquer clairement qu'un chemin fournira plus de valeur qu'un autre à l'aide de nombres exacts, vous retenez toute l'attention de la direction.

Jarrod Nettles
la source
0

Quand j'étais nouveau développeur dans une très petite équipe, j'ai beaucoup amélioré ce genre de choses pendant mon temps libre. J'ai aimé ça; Je me connectais et essayais de nouvelles techniques intéressantes tout en restant assis dans le salon avec ma femme le soir. Alors que je devenais un développeur plus expérimenté puis un manager d’une plus grande équipe, mon temps libre a disparu. Nous travaillions des heures supplémentaires pour obtenir les fonctionnalités et les correctifs critiques. Il devenait vraiment difficile de justifier de passer du temps à qui que ce soit à ce travail d’entretien ménager régulier, même si nous savions tous à quel point c’était important.

Vos chefs n’ont pas besoin d’expliquer à quel point il est important de réduire les coûts de maintenance, de réduire les coûts de croissance, d’engager une équipe de développement talentueuse, etc. S'ils le font, vous avez de gros problèmes. Ce dont ils pourraient avoir besoin, cependant, c'est d'un plan. En ce moment, je suppose qu'ils ont toutes sortes de plans, d'horaires, de feuilles de route, de promesses et de pressions sur le côté "ajout de fonctionnalités", qui sont en concurrence avec de simples rêves illusoires et des demandes ouvertes de l'équipe de développeurs.

Une chose que vous pourriez essayer est de préparer un plan documenté. Voyez si vous pouvez le lier à des éditions ou quitter les critères de nouvelles fonctionnalités. Une demande de "passer du temps à refaire le comptage de références" peut être difficile à approuver par votre patron, mais il peut être plus facile de programmer un bloc de 5 jours à 4 semaines à partir de maintenant. En gros, peu importe la façon dont vous voyez que les nouvelles fonctionnalités sont planifiées et planifiées, essayez d’en reproduire le sens ou injectez-y une partie «sous le capot».

Commencez petit en demandant 5% de temps alloué à ce genre de choses, puis établissez progressivement vos propres priorités de feuille de route technologique, et continuez à vous attarder pour justifier l'analyse de rentabilisation, le retour sur investissement, les niveaux de risque, etc. Bientôt, vous aurez même un aperçu des défis de vos patrons, car vous trouverez rapidement beaucoup plus d’idées géniales que vous n’avez le temps de faire.

Bonne chance!

Joecullin
la source
-1

Voici pourquoi votre demande de comptage automatique des références est rejetée:

  1. Ce n'est pas une amélioration . Une fois que vous avez quelque chose de plus grand que bonjour le monde, tout changement va dans la mauvaise direction. Aucune refactorisation ne changera le fait que si vous devez faire des changements, cela ira toujours dans la mauvaise direction. L'astuce consiste à savoir quand vos modifications sont suffisamment importantes pour que le risque de nouveaux problèmes en vaille toujours la peine. Votre direction a clairement indiqué que si les utilisateurs finaux ne peuvent pas le voir, le risque n’en vaut pas la peine.
  2. Le comptage de références est une fonctionnalité complètement folle. Vous avez vu certaines grandes entreprises existantes implémenter certaines fonctionnalités, et vous avez immédiatement pensé que vous aviez besoin de la même fonctionnalité. Eh bien, il est fort probable que votre base de code soit complètement différente de celle utilisée par Apple. Le comptage de références ne va probablement pas fonctionner, ou c'est juste une perte de temps. Vous devriez trouver un moyen différent qui n'exige pas d'étendre les primitives de comptage de références partout dans votre code. Votre plan de refacturation nécessite probablement des milliers de modifications dans la base de code, la plupart de ces modifications ne sont pas nécessaires. Juste une perte de temps et d'argent.
  3. Vous résolvez le mauvais problème. La direction sait généralement quels types de problèmes existent dans le système. Un problème de fuite de mémoire non pertinent que la solution de refcounting est en train de résoudre n’en fait pas partie. Concentrez-vous sur de vrais problèmes et non pas sur des problèmes imaginaires liés à la gestion de la mémoire par les ordinateurs.
  4. Cela prend trop de temps pour le mettre en œuvre. Apple est un peu plus grand que votre petite équipe avec peu de programmeurs et quelques gestionnaires. Ils peuvent faire de grands changements en payant simplement le prix. S'il faut quelques millions pour mettre en œuvre quelque chose, ce sont des cacahuètes. Si les petites entreprises essaient de faire la même chose, elles vont vite manquer d'argent. Le développement de logiciels est déjà très coûteux. l'ajout de coûts inutiles ne va pas aider un bit. Une fonctionnalité non pertinente telle que la gestion de la mémoire va ouvrir les vannes: après l'avoir approuvée, la moitié de vos programmeurs souhaitent que leur propre "amélioration" soit mise en œuvre. C'est une histoire sans fin et l'entreprise pourrait faire quelque chose d'utile à la place.

Voici quelques étapes que vous pouvez utiliser pour gérer le problème:

  1. Déposer la fonctionnalité
  2. Découvrez quel est le vrai problème
  3. Commencer à faire quelque chose d'utile
  4. Planifiez soigneusement la façon dont vous utilisez votre temps
  5. Découvrez comment vos améliorations rapportent de l'argent
  6. Choisissez uniquement les fonctionnalités qui rapportent le plus d'argent
  7. Réalisez que l'aspect programmation du développement logiciel ne représente qu'une petite partie de l'ensemble du système - les améliorations ne seront jamais rentables
tp1
la source