Quelles sont les pires fausses économies dans le développement de logiciels?
Quelles sont les pires fausses économies (c'est-à-dire les moyens d'économiser de l'argent qui coûtent finalement plus cher qu'elles n'en économisent) qui prévalent dans l'industrie du logiciel et comment les combattez-vous?
Dette technique
c'est-à-dire "Faites-le rapidement, nous refactoriserons plus tard". D'abord parce que je n'ai pas encore vu quelqu'un s'engager dans ce comportement refactoriser plus tard. Deuxièmement, parce que faire les choses rapidement, au lieu de la bonne façon, il est plus difficile d'ajouter de futures fonctionnalités ou de résoudre de futurs bugs, ce qui vous fait perdre du temps à long terme.
Malheureusement, beaucoup pensent encore qu'il enregistre cycles de développement pour qu'ils fassent quelque chose de rapide. Je suppose que c'est possible, mais je ne l'ai pas encore vu dans la pratique.
Embaucher 2 développeurs bon marché au lieu de 1 vraiment génial. (pour le même prix)
Mon exemple serait l'opposé complet de l'exemple de NimChimpsky , à savoir:
Essayer de développer en interne quelque chose qui peut être acheté sur étagère.
Normalement, cela se produit en raison d'une incapacité à vérifier réellement le marché pour voir si quelque chose existe déjà qui résoudra le problème. Cela peut être aggravé par les développeurs qui aiment "plonger" dans le codage avant de faire des recherches et par les chefs de projet qui ne tiennent pas compte de ce temps = argent.
L'un des exemples les plus courants que j'ai vus dans mon domaine, le développement Web, est celui d'entreprises qui essaient de développer et de développer un système CMS en interne. Ceux-ci commencent invariablement petit, mais deviennent rapidement gonflés et incontrôlables à mesure que les fonctionnalités sont boulonnées, tandis que tout le temps il y a beaucoup de produits et de cadres gratuits là-bas qui seraient beaucoup mieux adaptés.
Pas de ressources dédiées à la gestion de projet
J'ai vécu plusieurs fois quand quelques programmeurs ont été embauchés, et quelqu'un qui a déjà une journée de travail exigeante aurait dû gérer le projet, mais en fait était trop occupé avec d'autres tâches, donc le projet n'a jamais vraiment pris de l'ampleur. Les programmeurs ont fait des "prototypes" et d'autres choses, mais sans piste, la plupart tournaient en rond pour avoir l'air occupés.
Mauvais équipement pour les nouveaux programmeurs
J'ai connu une fois une entreprise où la politique était "les nouveaux programmeurs doivent travailler sur un PC vraiment vieux avec un petit écran jusqu'à ce qu'ils prouvent qu'ils en valent la peine". Pas étonnant qu'une telle politique ait provoqué une sélection négative qui a chassé de bonnes personnes qui ont toujours le choix de travailler dans un environnement plus sain.
Nous pouvons économiser de l'argent en faisant doubler les programmeurs en tant que testeurs/rédacteurs techniques
Si vous payez des salaires de programmeur pour un travail de testeur/rédacteur technique, alors vous perdez de l'argent et obtenez probablement un travail de moins bonne qualité que quelqu'un qui a consacré sa carrière à cette tâche. En outre, lorsqu'un programmeur est confronté à une échéance serrée, les tests et la documentation sont très susceptibles d'être abandonnés ou exécutés à moitié pour y répondre.
BTW: Les développeurs sont TOUJOURS confrontés à un délai serré.
La recherche/lecture/écriture de code non lié au développement du produit est un gaspillage de ressources.
Certains programmeurs et même gestionnaires y croient. Normalement, ils font simplement une programmation basée sur les connaissances dans leur tête, font des recherches et recherchent des réponses lorsqu'ils rencontrent des problèmes. Ils n'améliorent pas continuellement leurs connaissances de manière proactive. À mon avis, nous devons toujours nous tenir à jour et les connaissances que nous avons recueillies nous seront utiles pour résoudre les problèmes actuels et futurs. Bien sûr, vous devez allouer votre temps à bon escient pour le faire.
Ceci est également similaire à réponse de Dan . Certains gestionnaires souhaitent simplement que les développeurs plongent rapidement et développent le produit selon les exigences sans rechercher sur les produits existants sur le marché.
Dans de nombreux cas, la délocalisation coûte plus cher. Dans mon entreprise, il est très difficile d'obtenir de nouvelles places pour les employés, nous sommes fortement poussés à externaliser. Il est également difficile de trouver des entrepreneurs sur place; il y a un rapport de 3: 1 offshore à onshore qu'ils sont censés maintenir. Par conséquent, de nombreuses équipes embauchent une douzaine de personnes à l'étranger et les utilisent à peine, afin de pouvoir obtenir 4 entrepreneurs sur place.
Longues boucles de rétroaction!
Cela arrive à tout le monde: vous construisez quelque chose que vous pensez être génial, et il s'avère que vous aviez tort. Ce n'est pas ça le problème. Le problème est combien de temps vous passez de la construction avant de découvrir que vous devez vous arrêter.
Au niveau élevé, vous voyez ce problème avec les longs cycles de publication. Si vous construisez pendant un an sans feedback, vous jouez toute l'année. Plus vous relâchez souvent, plus vos mises sont petites et mieux vous jouez.
Mais cela se produit également aux niveaux les plus bas. En tant que développeur, j'aime beaucoup les révisions de code fréquentes (ou, mieux, la programmation en binôme) car cela limite le temps que je peux continuer à faire quelque chose de stupide avant que quelqu'un ne dise: "Hé, il y a une manière plus simple!" Pour la même raison, j'aime que mes tests unitaires s'exécutent rapidement et fréquemment, donc je peux attraper et tuer les bugs avant qu'ils ne se développent.
Une fois que vous commencez à remarquer l'importance de courtes boucles de rétroaction, vous le verrez partout. Par exemple, la notion militaire de la boucle OODA .
Fournir postes de travail à écran unique car un deuxième moniteur est trop cher. Même s'il ne vous fait économiser qu'une heure de travail par an, un deuxième écran reste un bon investissement. Je sais avec certitude que le mien m'a sauvé de très nombreuses heures de travail.
Une configuration multi-écrans peut rendre presque toutes les tâches plus efficaces, pas seulement les tâches de développement. Trois moniteurs, c'est encore mieux que deux, mais l'effet devient moins prononcé avec chaque écran supplémentaire.
Configurations multi-écrans:
- réduire les frais généraux de commutation de fenêtre
- vous permet de garder un œil sur les choses qui tournent en arrière-plan (mail, compilation, etc.).
- vous donner un sentiment de liberté. C'est comme être dans un atrium vs être dans un placard à balais.
- etc...
Pas ma propre anecdote, mais j'ai entendu une fois parler d'un magasin qui a cessé de fournir du café gratuit à ses développeurs, leur disant à la place que chaque fois qu'ils voulaient obtenir du café, ils étaient libres de marcher jusqu'au café le plus proche (environ dix minutes voyage dans chaque sens) et en acheter.
À peu près la définition de la fausse économie.
Matériel le moins cher donné à un consultant lorsque le consultant coûte plus de 150 $/heure.
Mettre en perspective un meilleur matériel peut au moins rendre le travail 30 minutes plus efficace par jour. Cela donnerait 30 minutes * 20 jours de travail par mois = 600 minutes/mois = 10 heures/mois> plus de 1 jour de travail = 10 heures * 150 $/heure = 1500 $
Un consultant ne travaillerait-il pas plus efficacement s'il avait un ordinateur à 1500 $? Cela rendrait-il le consultant moins irrité?
Maintenant, le problème semble être qu'il y a deux budgets, un pour le consultant et un pour le matériel PC.
Des mois de travail permettent d'économiser des jours de planification
(Ne pas investir suffisamment de temps dans la planification)
Le plus répandu, je pense, est que les gestionnaires ne fournissent tout simplement pas aux développeurs les outils dont ils ont besoin pour faire leur travail efficacement.
Fondamentalement, point 9 sur le Joel Test .
"Jetez (assez) de corps au problème" peut encore être utilisé à certains endroits, malheureusement. Brook's Law contrecarre cela de Le Mythical Man-Month , bien que certains nécessitent de l'expérience pour apprendre Cette leçon. En général, ce n'est pas quelque chose en mon pouvoir d'arrêter car la direction peut croire la fausse déclaration sur l'ajout de personnes et ne pas avoir à en payer le prix.
Réunions quotidiennes:
(meeting duration in hours) x (Y team members) x (average salary per hour) = ...
Acheter un logiciel standard au lieu de le développer en interne.
J'ai une expérience des systèmes de gestion à l'échelle de l'entreprise, axée à la fois sur les laboratoires RH et biologiques.
Une solution standard coûte entre 50 et 100 000 £ et nécessitait un développement et une personnalisation supplémentaires pour répondre aux exigences de l'entreprise.
La solution développée en interne a pris (<6) mois pour se développer, avec d'autres projets travaillés en parallèle, et a utilisé un développeur déjà employé.
Je suis passé du secteur public où nous avions un LIMS (système de gestion de l'information de laboratoire) développé en interne à un grand pharmaceutique international où la mise en œuvre d'une solution standard avait pris plus d'un an et n'était nulle part terminée.
(6 mois d'un développeur déjà embauché travaillant sur d'autres projets en parallèle. Donc ~ 10k. Et cela n'inclut pas les coûts de support associés à la solution standard). Le point majeur est que le système développé en interne était réellement utilisé! Donc, vous avez alors l'avantage de coût supplémentaire associé à cela, que je ne peux pas calculer.
Je serais d'accord pour les sites Web de base, etc., pourquoi s'embêter à développer le vôtre. Mais pour tous les grands systèmes complexes et si vous avez déjà des compétences internes, je je le construis moi-même.
Acheter des produits prêts à l'emploi coûteux lorsque les alternatives open source sont meilleures et gratuites.
Combien d'entreprises utilisent git? Combien d'entreprises utilisent un contrôle de version d'entreprise pourri?
Utiliser des langages "simples" sans grande expressivité
Oui, il est plus facile de trouver des programmeurs pour maintenir le code, mais il est plus difficile de trouver bon des programmeurs qui n'apprennent pas seulement le dernier mot à la mode qui les fera embaucher. Oui, cela rend le code des bits individuels plus facile à comprendre, mais il le rend également aussi rigide qu'un 2x4 et augmente le volume de code qui doit être compris. Oui, il est soutenu par une énorme société, mais cette grande société innove lentement et bureaucratiquement.
Mauvais chefs de projet/chef d'équipe.
Puisqu'une personne incompétente a le pouvoir de ruiner le travail d'un groupe de personnes. En fin de compte, le projet ferait beaucoup mieux sans décisions de la haute direction (chef de projet/équipe).
Dose le "Faites-le rapidement, nous allons refactoriser plus tard" décide.
Exigences utilisateur manquantes
Une étape importante et difficile de la conception d'un produit logiciel consiste à déterminer ce que le client veut réellement qu'il fasse.
Croyez-le ou non, cette partie est parfois manquante ou obsolète. Ce qu'il en coûte, c'est que l'on crée des fonctionnalités que l'utilisateur final n'a jamais demandées.
La productivité vaut plus que la créativité
La créativité est difficile à mesurer en général, et le plus souvent impossible à observer, même à mesurer, en ce qui concerne le développement de logiciels. En revanche, la productivité peut être mesurée (souvent mal) et peut être observée.
Par conséquent, les développeurs qui peuvent (écrire plus de lignes de code | écrire du code plus rapidement | réciter des technobabbles plus rapidement en réponse aux questions | sont plus visiblement productifs) ont tendance à être plus valorisés que ceux qui (utiliser moins de lignes de code pour résoudre le même problème | prendre plus de temps pour écrire du code, mais produire un produit plus fiable | comprendre le sujet suffisamment bien pour répondre aux questions en clair, facile à comprendre, résoudre les problèmes de manière créative).
Tout ce qui suit peut être mauvais lorsqu'il est utilisé ou non utilisé de manière inappropriée
logiciel externe vs logiciel interne
Conformité ISO 9001 (économie - atténuation du risque de perte du SMS si la qualité du produit baisse)
développement/externalisation de l'assurance qualité
procédures de développement/build/release/support
Avoir trop de gestionnaires de livraison non facturables.
Il y a quelques années, dans notre entreprise, nous avions plusieurs projets à gros budget en cours et le recrutement était au sommet. À cette époque, notre entreprise a embauché trop de directeurs de livraison (dont beaucoup n'étaient pas des TI!) Et très peu de codeurs/testeurs. Le ratio gestionnaire/programmeur était littéralement de 1: 2. Plus tard, après l'achèvement de ces projets, nous avons eu une situation où beaucoup de ces gestionnaires (certains d'entre eux étaient de vrais fainéants) assis sur un banc ne faisaient rien. Nous avons eu un cycle d'évaluation où tout le monde a obtenu peu ou pas d'augmentation (même nous, les programmeurs assidus, soupir) afin que l'entreprise n'ait à licencier personne! Heureusement, la société a réalisé cette situation et a fait le RIGHTSIZING au premier trimestre de cette année!
Accès Internet limité ou inexistant
Parce qu'évidemment, vos employés utiliseront Internet pour jouer à des jeux Facebook sans trop chercher des réponses aux questions techniques sur Stackoverflow.
En réalité, bien sûr, Internet est un énorme gain de productivité, et bien qu'il puisse être approprié d'utiliser une sorte de filtre de site pour les sites vraiment douteux, il y a quelque chose de mal s'il bloque le fichier Lisezmoi de Visual Studio ou bloque les pages du gouvernement local de Telford pour une raison "tourisme sexuel"
Optimisation avant profilage (aka optimisation prématurée).
Trop souvent, j'ai vu quelqu'un chercher une solution intelligente qui complique inutilement la maintenance et la lisibilité au motif qu'elle est plus rapide. Naturellement, le code n'a pas été benchmarké (pas même avec des micro-benchmarks), donc il devient rapidement "plus rapide sur la base de l'argument le plus persuasif" sur une section de code qui n'a probablement pas eu d'impact sur les performances globales de l'ensemble application par beaucoup.
En tant que tel, c'est une très fausse économie, et le genre de fausse économie qui emmêle parfois même les pros chevronnés.
Faire en sorte que vos développeurs utilisent un moniteur 15 pouces et un PC à faible spécification car c'est la norme de l'entreprise.
Les moniteurs de taille raisonnable sont bon marché, rapides à installer et rendent les programmeurs plus productifs tout en faisant croire à vos programmeurs que vous vous souciez d'eux.
Trop de baccalauréats en administration des affaires (ou similaires), organisés de manière hiérarchique, qui essaient d'appliquer ce qu'ils pensent être la gestion moderne: déranger les gens avec des "KPI", des "SLA" et quoi d'autre, nécessitant des "rapports" (sans, bien sûr, en se souciant de l'infrastructure pour les générer), de sorte que les programmeurs perdent leurs journées à remplir des feuilles Excel fantastiques, des rapports du quatrième trimestre et quoi de plus et à copier à partir d'un excellent nouvel outil de gestion et à les coller dans un autre (il semble que la règle soit que ces outils ne sont jamais intégrés ni intégrables les uns aux autres) et assistent à des réunions où les rapports et les chiffres sont présentés (et tout le monde se sent coupable de ne pas avoir rempli tel ou tel KPI).