Équipez vos développeurs ! (petit guide de rentabilité à l'usage des décideurs)

Tout bon artisan vous le dira : la qualité de ses outils est primordiale pour la réussite de son art. Le peintre sélectionne avec soin son pinceau, l'ébéniste son rabot, le boulanger son four.

Il n'est qu'en informatique que le développeur se voit imposer son outil de travail. Ce qui ne poserait aucun problème si celui-ci n'était pas, la plupart du temps, complètement obsolète, limité, ou simplement inadapté aux tâches à réaliser.
Le développeur éprouve alors une légitime frustration devant son incapacité à exprimer son plein potentiel au travail, et que son matériel personnel est bien meilleur que son matériel professionnel - un comble !

Le plus souvent, le constat est partagé par les développeurs, le chef de projet, les architectes, et dans un certaine mesure par tous ceux qui suivent l'avancement du projet. Mais voilà : l'acquisition d'équipement informatique est soumis à l'approbation des Achats, entité toute-puissante mais aux oeillères bien ajustées.
L'équipement coûte cher, paraît-il. Et aucun budget n'est prévu cette année pour ce poste. Réessayez l'année prochaine, en remplissant le formulaire 27B en quatre exemplaires. Fin de l'histoire.

Pourtant, tout développeur apprend vite que le temps perdu à attendre la machine se compte en heures, en jours, en semaines ! Et que la perte de productivité est en réalité bien plus importante que cette simple mesure horaire : la perte de contexte mental, la frustration et le stress des deadlines, l'abandon des tests trop longs à passer, minent les projets et les équipes. Le problème est que cet élément est inchiffrable, et donc difficilement opposable aux décisions des Achats.

Rentabilité des outils de travail

Puisque les Achats ne sont sensibles qu'aux arguments financiers[1], faisons donc un petit calcul simple de rentabilité.

Un environnement de travail professionnel

Aujourd'hui, l'environnement de travail standard est le suivant :

  • 1 écran en 1280 x 1024
  • CPU et mémoire : CPU moyen de gamme, 2 Go de RAM (4 chez certains, mais voir point suivant)
  • Disque HDD 7200 RPM
  • OS : Windows XP, 32bits
  • IDE : Eclipse
  • Clavier et souris de série (Dell / HP)

Voici l'environnement de travail que je considère idéal (en termes de confort et productivité) :

  • 2 écrans 1920x1080 (22" ou 24")
  • CPU bi- ou quad-core, 8+ Go de RAM
  • Disque SSD
  • OS : Linux, 64 bits (gestion de la mémoire, stabilité, shell, bureaux multiples, pas de spywares d'entreprise...)
  • IDE : IntelliJ (performance, détection des bugs, intégration des frameworks et outils)
  • Clavier et souris au libre choix du développeur

Calcul de rentabilité

Voyons combien il coûterait à l'entreprise de fournir ce matériel à différentes populations de développeurs (facturés 400, 500, 600 et 700 €/jour).

On admettra que le travail moyen d'un développeur est de 8 heures / jour.
A raison de 220 jours travaillés par an, on obtient un volume annuel de :
44 semaines/homme = 220 j/homme = 1760 h/homme.

400 €/j = 50   €/h =  88000 €/an
500 €/j = 62.5 €/h = 110000 €/an
600 €/j = 75   €/h = 132000 €/an
700 €/j = 87.5 €/h = 154000 €/an

Voici donc le prix des différents matériels ou logiciels, rapportés à la force de travail nécessaire pour les rembourser.

Poste de travail fixe
                  400   €/j     500   €/j    600   €/j    700   €/j
                   50.0 €/h      62,5 €/h     75.0 €/h     87,5 €/h

Ecrans    500 €    10.0   h       8.0   h      6.7   h      5.7   h
Tour     1000 €    20.0   h      16.0   h     13.3   h     11.4   h
Linux       0 €     0.0   h       0.0   h      0.0   h      0.0   h
IntelliJ  230 €     4.6   h       3.7   h      3.1   h      2.6   h
Input       0 €     0.0   h       0.0   h      0.0   h      0.0   h

Total    1730 €    34.6   h      27.7   h     23.1   h     19.8   h

Pour rembourser l'achat du nouveau poste de développement, il suffit :

  • qu'un développeur junior (à 400 €/jour) gagne 35h de travail dans l'année, c'est-à-dire environ +1.98% de productivité.
  • qu'un développeur expert (à 700 €/jour) gagne 20h de travail dans l'année, c'est-à-dire environ +1.13% de productivité.

Soit moins de 9.5 minutes par jour dans le premier cas, et 5.5 minutes dans le second.

Actuellement, combien de temps par jour perdez-vous à attendre votre machine ?
Que votre IDE auto-complète votre code ?
Que le projet compile ?
Que les tests passent ?
A faire Alt-Tab pour jeter un oeil aux spécifications entre deux lignes de code ?
A scroller dans tous les sens pour lire votre code, sans jamais réussir à en avoir une vue d'ensemble ?
A maudire l'antivirus / anti-spyware d'entreprise qui scanne les jars ?

Qui pense y perdre moins de 10 minutes par jour ?

Et encore, vous noterez que les prix retenus sont généreux - à l'exception du clavier et de la souris, comptés pour zéro car chaque développeur devrait avoir le droit d'amener son propre matériel de saisie, pour des questions d'ergonomie.

Si l'on ajoute à l'équation le fait que certains éléments s'amortissent sur plusieurs années... Les écrans par exemple se conservent plusieurs années ; le CPU et la RAM, deux ans ; la licence IntelliJ, à vie (mettons 2 à 3 ans, pour bénéficier des nouveautés toutes les 2 versions).

Poste de travail mobile

Certaines sociétés pourraient préférer vous fournir un bon ordinateur portable :

                   400   €/j    500   €/j    600   €/j    700   €/j
                    50.0 €/h     62,5 €/h     75.0 €/h     87,5 €/h

Laptop    1500 €    30     h     27.2   h     22.7   h     19.4   h

J'ai pris 1700€ car il s'agit du prix (TTC) de mon ordinateur portable professionnel, armé d'un quad-core i7-2760QM, 8Go de RAM, d'un disque SSD 256Go et d'un écran full HD 1920x1080.
Les coûts sont comparables à ceux d'un ordinateur fixe, les conclusions sont donc similaires, avec le bonus de mobilité : télétravail, organisation souple des équipes...

Serveur d'équipe

Pour finir, voyons le prix d'un serveur en libre-service pour votre équipe de développement (pour l'intégration continue, etc.) :

		          400   €/j     500   €/j    600   €/j    700   €/j
		           50.0 €/h      62,5 €/h     75.0 €/h     87,5 €/h

Serveur   800 €    16     h      12.8   h     10.7   h      9.1   h

Le prix de revient d'un serveur est d'autant plus faible que votre équipe est nombreuse, car il bénéficie à tous ses membres. Alors pourquoi hésiter ?

Conclusion

Fournir un environnement de travail de qualité à un développeur a un coût ; mais si l'on se penche sur l'aspect rentabilité, on s'aperçoit vite que le coût initial est très rapidement amorti, et apporte ensuite plus-value importante.

Mieux, certains aspects non monétaires s'en trouvent également améliorés : moral et implication des équipes, attractivité du poste (recrutement facilité), image globale de la société parmi la communauté des développeurs... Qui n'est jamais revenu d'un entretien de mission en disant "la mission proposée est moyenne, mais ils ont deux grands écrans par poste !" ?

Alors, n'hésitez pas, équipez vos développeurs ! Le jeu en vaut la chandelle sur tous les plans. Et vos développeurs vous en remercieront !

Une petite affiche militante pour votre openspace

Disponible en PDF A4, ou au format Impress (éditable)

preview.png


Egalement, l'ami Pierre-Yves Ricau (@piwai) a développé le Gâchomètre, une application Android qui permet de calculer dynamiquement le montant perdu en fonction de la facturation et du temps perdu quotidien.
Jouez un peu avec le slider, ça fait peur...

Quelques lectures supplémentaires pour achever de vous convaincre :

A second screen can increase your productivity by 9 to 50 percent and make your work day easier.

Using 24-inch Widescreen Displays Cuts 76 Days of Work, Translates to $8,600 of Annual Savings Per Employee versus 18-inch Standard Format

IntelliJ is unquestionably one of the smartest choices a Java developer can make to be as productive and prepared for the broadest range of work as possible.

Et quelques témoignages de développeurs (merci Twitter !)

@ugobourdon

J'ai calculé pour ma part le remboursement d'une bonne machine en moins d'un mois juste sur le gain dû à la compilation

@glaforge

Un exemple sur le build et l'antivirus : build time x 2 => 5 to 10 min à cause de l'Antivirus. Sur Mac, avec MacAffee, mon build time est passé de 12 min à 5 min en enlevant l'antivirus censé protéger les windows users.

@Abderrazakk

projet perso build 6' (thinkpad i7/8G/SSD/Win7) #grails/#angular. +antivirus (avast la totale) ~8'

@BlogDevNet

Les vieux pc incapables de faire tourner un environnement de dev correctement (perte: au moins 30 min / jour)

@agoncal

Ce qui me fait perdre du temps c'est un OS 32 bits avec 3.2Go de RAM et un fichu disque 5400 tours/min

@ygrenzinger

XP 32 bit + disque dur lent + saloperies qui surveillent ton PC = 1h de perdue par jour

@pingtimeout

j'ai divisé par 3 mon temps de build total en changeant d'OS, et par 15 en changeant aussi la machine

Notes

[1] Les sous, pas les gâteaux aux amandes. Quoique...


Commentaires

1. Le lundi 27 août 2012, 07:46 par vince

Tout à fait d'accord sur l'absolue nécessité d'un vrai poste développeur, la difficulté étant de calculer le ROI pour convaincre les décideurs.
Un point à ajouter, la virtualisation des postes de travail (y compris poste développeur) associée au BYOD s'imposant de plus en plus, il faut aussi l'approbation de la prod/infra, et là ça devient déjà plus compliqué que convaincre le service achat...

2. Le lundi 27 août 2012, 07:52 par Sylvain

> Il n'est qu'en informatique que le développeur se voit imposer son outil de travail.
Oula, belle perle de nombrilisme professionnel :) Cette problématique est inhérente à la plupart des jobs non indépendants reposant sur un outil de travail. Et l'informaticien est privilégié en cela que ce n'est pas lui qui pâtit directement des défaut de son outil de travail. Dans d'autres métiers (bâtiment, agriculture, secteur industriel, ...), ça peut causer des risques de sécurité, des charges de travail en plus, etc.

Mais complètement d'accord sur le fond et sur ta démonstration. Pour moi l'aspect "moral et implication des équipes" que tu abordes en conclusion est primordial, un poste qui rame fait perdre en productivité aussi indirectement car il met le développeur dans un faux rythme et dans un état d'énervement/frustration qui nuit encore plus à sa productivité (situation vue et vécue).

3. Le lundi 27 août 2012, 08:00 par ygrenzinger

Tu travailles chez mon grand compte et tu as craqué, c'est ça ? :)

Mais je ne sais pas si les décideurs vont comprendre vu que pour eux le développement de logiciel n'est qu'un coût et ne représente pas de la création de valeur.

4. Le lundi 27 août 2012, 08:03 par dadoonet

Excellent. J'ajouterai une petite licence JRebel à tout ce bonheur ;-)

5. Le lundi 27 août 2012, 08:05 par Olivier Croisier

@dadoonet Ah oui tiens, j'ai oublié JRebel. Il fait pourtant partie de mon arsenal. Allez, mettons que cela fait passer le seuil de rentabilité à 10mn par jour.

6. Le lundi 27 août 2012, 08:25 par Alexis

D'accord avec l'essentiel de ton article. Par contre l'éternel parallèle avec l'artisanat où tout semble parfait me désole. Il y a autant de charlatans et de dysfonctionnements dans ce métier. Non, le boulanger ne choisit pas son four, c'est son patron qui lui fournit. J'ai encore vu la semaine dernière 3 maçons perdre leur journée à cause d'un vieux compresseur défaillant.

D'accord, tu as précisé "bon artisan". Et tout "bon développeur" sera d'accord avec toi. Ce que tu soulignes n'est pas propre à notre métier, c'est juste que l'organisation de la plupart des grosses structures (et de celle qui veulent se faire aussi grosse que...) impose ces contraintes. C'est aussi que des métiers qui ne produisent pas peuvent même aller contre la production !

Si tu observes bien les artisans, le "bons" sont souvent indépendants ou dans des petites SARL. Je te laisse conclure avec ton parallèle...

7. Le lundi 27 août 2012, 11:26 par Dridi

Je savais qu'IntelliJ serais au rendez-vous, et sur ce point je ne suis pas d'accord. On ne devient pas plus productif juste en changeant d'outil. Mais là il est question de laisser au développeur le choix de ses outils, donc rien n'oblige le-dit développeur d'utiliser IntelliJ, ça peut être Eclipse ou un autre outil payant. Lorsqu'on commence à multiplier les licences (différentes) ça devient compliqué à gérer.

Lorsque tu as un gros parc, tu ne vas généralement pas acheter des licences individuelles, le plus gros que j'ai vu étant il y a quelques années une clé de licence pour 10000 postes XP. Donc le passage à Linux n'entraîne pas de baisse des coûts de licences, mais il n'entraîne pas non plus de hausse. Le gain caché (très difficile à quantifier) qu'on a tendance à oublier c'est que le développeur est au quotidien plus proche de l'environnement de production (souvent un unix-like). Après il ne faut pas non plus négliger la charge d'administration d'un poste de travail non standard.

Un autre problème, ça coûte cher de changer le hardware de tout un service, d'un coup. C'est un processus qui peut prendre du temps malheureusement.

Maintenant je suis convaincu que laisser le choix des outils peut entraîner un gain énorme de productivité. Pour ma part, c'est devenu très difficile de travailler sous windows, ou avec SVN par exemple. Avoir un OS 32 bits est vraiment dommage (et anachronique =). Un autre usage de la RAM : lancer une ou plusieurs VM directement en local pour faire des tests d'intégration.

Un calcul qui me semble donc incomplet, mais suffisamment représentatif.
En espérant être mieux équipé à l'avenir :)

8. Le lundi 27 août 2012, 11:37 par arn

JRebel: Quand je debug Tomcat depuis Eclipse (ex: sysdeo plugin), je peux editer le code Java, ça remplace à chaud le code dans la plupart des cas (ça utilise JDPA je crois), pas besoin de relancer Tomcat. D'après vos expériences, est-ce que JRebel apporte beaucoup plus?

"IDE auto-complète": n'est-on pas tous sensé utiliser un des ces nouveaux langages dynamiques à la mode où l'auto-completion est quasiment impossible ;)

9. Le lundi 27 août 2012, 13:44 par Nicolas

@Olivier : superbe article et complètement d'accord avec toi. +1 comme toi pour IDEA IntelliJ, simple et productif (et je sais que tu es un convaincu qui maitrise aussi très bien Eclipse).
Concernant le nombre de jour travaillé, c'est 218 j/an, je pense que l'on doit plutôt utiliser sa machine 6h par jour (sur les 8h) mais pour le reste je suis complètement d'accord.

10. Le lundi 27 août 2012, 17:17 par Olivier Croisier

@arn : le hot-swap de la JVM est terriblement limité. Il ne peut remplacer que le code de méthodes existantes. JRebel te permet d'ajouter, supprimer, refactorer des méthodes et des champs, bref de tout changer dans ta classe - sauf sa hiérarchie. Impossible de modifier la classe mère ou les interfaces implémentées, c'est là l'unique limitation de JRebel. Même les classes internes et anonymes sont gérées !

11. Le lundi 27 août 2012, 17:38 par BlogDevNet

Magnifique article qui dit tout haut ce qu'un grand nombre de développeur réclame à leur chef de projet.
Article à fournir aux achats sans hésiter (pour ma part, le mail vient d'être envoyé).

12. Le lundi 27 août 2012, 19:17 par Dam

Super article, que j'aurai partagé avec plaisir. Sauf que l'url contient un accent qui ne passe pas dans les raccourcisseurs....

13. Le lundi 27 août 2012, 19:29 par dnr

C'est tellement évident... Sauf pour ceux qui tiennent les cordons de la bourse.

Il suffit de voir le matos des développeurs indépendants (relativement nombreux en Belgique), quand on leur laisse le choix : généralement du haut de gamme souvent renouvelé. Le freelance ne peut pas se permettre les pertes de temps, d'efficacité et de confort décrits dans le billet.

@arn: je bosse en Grails donc Groovy, avec IJ11 et c'est l'assistance qu'il apporte est *très* impressionante.

14. Le lundi 27 août 2012, 21:21 par Gabriel K.

@arn : JRebel fait aussi gagner beaucoup de temps en rechargeant les configurations Spring et Hibernate. Ce n'est pas tellement le lancement d'une apli sur Tomcat qui est pénalisante, mais surtout le rechargement des beans et des services. Sur le dernier projet où j'étais, c'était à peu près 5 sec pour Tomcat et 50s pour le reste...

Bon, je vais tout de même être un peu corrosif, mais quel intérêt que des développeurs aillent vite? S'ils sont au forfait chez un client qui paye à la truelle, ton patron a simplement pas intérêt à ce que ton ordinateur aille trop vite. Assez vite pour ne pas que le développeur devienne fou/parte à la concurrence/que tu te fasses moquer par les autres prestataires. Mais pas trop vite non plus.
Si tu termines un projet un jour une semaine, un mois plus tôt parce que tu as du bon matériel, tu seras facturé un jour une semaine ou un mois de moins. Quelle perte pour la ssii!
Bon j'imagine que peu de patron de ssii pense comme ça , en tout cas pas le patron de ... ni de ... Bref :)
Mais simplement pour souligner un truc, ça n'est pas du tout une priorité pour ton employeur, c'est une priorité pour toi, pas pour ton patron. Si tu ne demandes rien tu n'as rien. Ecco...

15. Le mardi 28 août 2012, 07:57 par vroum

Un disque SSH ? :D

16. Le mardi 28 août 2012, 09:22 par zorbac

Petite erreur sur l'affiche car il est noté disque SSH alors qu'il devrait y avoir SSD.

Bonne infos pour justifier le passage à un environnement confortable.

17. Le mardi 28 août 2012, 09:45 par David

Pas mal comme argumentaire pour justifier l'investissement dans de meilleurs outils de production.
Mais bon après, tu prends pas en compte:
- Le temps passé devant la machine à café
- Le temps passé à être interrompu au téléphone
- Le temps à blablater avec les collègues,etc...
La productivité, ca se pense au global et pas juste au temps devant l'outil de production.

Mais bon c'est sur que la logique "plus ca va vite, mieux c'est"...
Enfin un argumentaire parmi d'autres pour justifier ou pas un meilleur matériel auprès du patron, pourquoi pas.

C'est un tout, il faut de bons outils, mais encore faut il que les personnes savent bien se servir de l'outil. Bon mix outils-personnes.

18. Le mardi 28 août 2012, 10:08 par Alex B

Attention dans votre affiche "militante", SSD et non SSH, de plus les les SSD ne sont pas des disques.

19. Le mardi 28 août 2012, 11:02 par Sentulebonson

Le cas s'est posé dans mon entreprise, sauf que c'était pour les commerciaux, dont les pcs mettaient 10-15 min à s'allumer et à s'éteindre. 10-15min payées mais inutiles.

20. Le mardi 28 août 2012, 12:29 par Olivier Croisier

Oui oui, j'ai corrigé sur les documents PDF et ODP, mais pas sur l'image de preview...

21. Le mardi 28 août 2012, 13:32 par jal

Quelle belle démonstration !
Pour ma part, il aura fallu plus de 10 ans de travail et pas moins de 4 boites différentes pour que je puisse bénéficier de deux écrans et du choix de mon matériel. Dingue non ?
Je me souviens d'une des entreprises dans laquelle je travaillais en tant que développeur qui ne comprenait pas la dépense inutile que représentait ce type d'achat : une station de travail avec un peu plus de mémoire devait suffire...
Mais oui, bien sûr...
Heureusement, je suis autrement mieux loti avec ma nouvelle boite.
Je crois que cela est assez révélateur des capacités de l'entreprise et/ou de sa bienveillance quand aux conditions de travail de ses équipes.

22. Le mardi 28 août 2012, 15:02 par reven

Manque plus qu'un petit lien vers l'article sur l'affiche et se sera nickel :)

23. Le mercredi 29 août 2012, 09:48 par arno

le fin du fin reste la boite où les développeurs ont des machines de 3/4 ans qui peinent à la tache, alors qu'à coté de cela le manager s'achète le dernier mac/dell/xxx avec toutes les options(cpu/ram/...) pour faire ...
du traitement de texte ou du tableur.
Ça c'est LE truc qui agace....

24. Le mercredi 29 août 2012, 10:32 par Rémi

Merci pour cet article dont l'idée initiale est très importante.

Par contre, les calculs me semblent assez inexacts. Quand une entreprise facture un client 400€HT, il y a déjà près de la moitié qui va partir d'une manière ou d'une autre dans les caisses de l'état (CIPAV, RAM, URSSAF, etc). A la fin de la journée, il vous reste donc 200€HT, et vous n'avez encore rien dépensé pour vous. Avec ces 200€HT, il vous faut désormais payer votre salarié, puis les salariés qui lui apportent du travail mais ne produisent rien (chefs de projet, commerciaux, DRH, managers, etc), et puis tous les frais liés à la vie de l'entreprise (loyer, électricité, eau, et aussi, on y vient, le matériel).

Au final, l'entreprise aura quand même largement de quoi acheter du matériel. Mais là encore, c'est dans le cas d'une entreprise qui tourne bien et qui vend 100% des jours disponibles de ces salariés.

Donc dans l'idée, cet article est vraiment intéressant, et c'est vraiment très important pour un développeur d'avoir du bon matériel à disposition, renouvelé régulièrement. Mais les calculs présentés sont trop déconnectés de la réalité pour être pris au sérieux, et risquent plus de faire sourire votre patron qu'autre chose.

25. Le mercredi 29 août 2012, 14:53 par Piwaï

Et hop, pour aller de pair avec cette article, une appli Android pour calculer le gachis en temps réel : le Gâchomètre !

https://play.google.com/store/apps/...

26. Le mercredi 29 août 2012, 17:42 par steeve

les entreprises qui négligent leurs salariés sont condamnés à échouer de toute facon
un employé qui ne se sent pas considéré rechignera au travail et ne prendra plus d'initiatives
ca permet de faire des économies à court terme (et encore), mais à long terme c'est désastreux, la boite perd les meilleurs employés

27. Le jeudi 30 août 2012, 09:50 par freem

Dans l'idée, je suis d'accord: le matos améliore considérablement la productivité.

Dommage que cet article soit centré sur le développeur d'applications web en java, ce qui tire considérablement le besoin matériel vers le haut, et ignore le fait que d'autres travailleurs sur écran ont aussi des problèmes pour s'équiper.

Le dual screen, tout "travailleur sur écran" devrait l'avoir, et pas juste les dev.
Je connais un directeur de services techniques qui a été séduit quand je lui ais fait une démo avec mon matos perso (qui est pourtant pourris, les écrans sont complètement différents).
Peut-être même que des secrétaires auraient cet intérêt, puisque l'usage c'est généralement: tâche principale/ponctuelle sur l'un, tâches secondaires, permanentes mais ne nécessitant pas d'attention continue sur l'autre.

Pour le reste:
_ 8Gio de ram, je n'ai jamais réussi à les bouffer. Si c'est pour des VM, il est plus intelligent de monter un serveur dédié contenant les VM de tous les dev, qui saura équilibrer la charge.
_ développer sous linux, c'est valide si on déploie une application linux. Malheureusement, je ne suis pas sûr que ce soit le cas de la majorité. C'est pas le mien en tout cas.
_ gros CPU pour compiler, ok, mais certains nécessitent aussi un gros GPU pour tester. D'ailleurs, le gros GPU pourrait être négligé si l'architecture réseau utilisais le calcul distribué.

Bref, fond intéressant, mais forme trop superficielle.

28. Le jeudi 30 août 2012, 10:05 par Olivier Croisier

@freem : l'article était centré sur mon expérience personnelle, c'est-à-dire principalement du développement Java. Mais il est vrai que les exigences matérielles varient en fonction des secteurs.

Pour les 8Go de RAM, certes ça peut paraître excessif, mais un RAD + Firefox + Word + ... ça prend déjà pas mal, alors quand arrive le moment où on lance l'application et la base de données pour tester localement, on dépasse largement les 3.2 Go d'un système 32bits. Et après, ça swappe sur disque...

Quant au développement sous Linux, à moins de travailler sur des applications spécifiques à Windows (ou iOS), c'est une plateforme relativement universelle en termes de compatibilité.

29. Le dimanche 2 septembre 2012, 21:17 par Martin

Bonjour,

Je suis l'un des décideurs dont vous parlez dans ce post... :-) Je crois qu'il y a 2 choses à distinguer : le besoin légitime d'outils de travail adéquats, et la plus-value que l'entreprise (ou le client) peut retirer de fournir des outils "top-notch".

Pour le premier, c'est clair : de bons outils favorisent le confort, la concentration, la productivité.

Pour le second, la difficulté réside dans le fait de communiquer, de montrer les avantages pour l'entreprise ou le client de fournir des outils de qualité : comment démontrer que le travail se fait plus rapidement, est de meilleure qualité (moins d'erreurs, plus lisible, répondant mieux aux specs, etc.) ? Très souvent, le client n'a pas la formation, le temps ou l'intérêt (si, si, ça arrive...) pour apprécier d'abord le travail informatique, ensuite pour voir les avantages qu'il retirerait d'avoir des professionnels mieux outillés. Je crois qu'une piste à explorer est de (mieux ?) communiquer.

Par ailleurs, le fait de fournir de meilleurs outils est une décision managériale, avec tout ce qu'elle implique. Au plan budgétaire d'abord : quels sont les priorités de l'entreprise... car il y a toujours souvent plus de demandes que de moyens financiers, et vous le savez, il n'y a pas que l'informatique. Au plan organisationnel ensuite : quel service privilégié, quelles personnes doivent être servies en premier ? Et finalement au plan humain : quelle portée "symbolique" veut-ton donner à l'attribution de ce matériel : une promotion ? une égalisation des moyens ? un "rattrapage" ?

Bref, il n'est pas toujours facile d'allouer du matériel performant, même quand on est un décideur qui en connait les multiples avantages...

30. Le lundi 10 septembre 2012, 12:58 par Niko

Boulette sur l'affiche militante : c'est SSD pas SSH

31. Le mardi 11 septembre 2012, 08:51 par Arnaud

Relativement d'accord. Ceci dit, je pense qu'il est judicieux de prendre uniquement la différence de prix avec l'environement pourris, en général tu pars pas de zero et un avantage d'une tour est la possibilité d'upgrade.
Note aussi que je suis contre la course à l'armement. Je trouve désolant d'avoir besoin d'un quad-core pour coder, ca reste du texte.
De mon coté, je n'ai pas à me plaindre, je travaille dans une multi-nationnale et j'ai un desktop quad-core avec 4Go de ram et deux écrans 19" (au total: 3200x1200). Je code en TCL, dans VIM sous linux (c'est un choix) mon pc est donc encore bon pour quelques années. J'ai accès à près de 400 environements de tests partagé parmis près de 300 personnes. Et je peux travailler à la maison quand je veux. Il faut donc faire un peu attention au cliché, toutes les entreprises ne sont pas à blâmer.

32. Le jeudi 11 octobre 2012, 07:39 par Cremsou

Exactement dans le cas enoncé, j'attend sur mon PC de longue minutes au fil de la journée. J'aimerais estimer ces minutes de "sablier", qq'un connait il un soft qui fasse compteur par hasard ?!? (je ne sais pas le quantifier exactement aujourd'hui ;) ).
Merci.

33. Le vendredi 12 octobre 2012, 08:55 par Olivier Croisier

Le plus simple est sans doute de trouver un "timer" avec un bouton poussoir sur le dessus, comme pour jouer aux d'échecs : une pression et le compteur se met en route, une autre pression et il s'arrête.

A la fin de la journée, on a ainsi une vision précise du temps réellement perdu.

34. Le jeudi 18 octobre 2012, 16:17 par hysteria

Parce que pendant une compilation ou tout autre tâche longue vous ne faite rien d'autre?! C'est peut être là que vous pourriez gagner du temps... ;)

35. Le mercredi 17 juillet 2013, 13:42 par HakShinKen

Je suis absolument d'accord, je travail chez mon employeur avec un pc qui à presque 4 ans, core i3, 2go de ram, disque dur 7200 trm ecran 15 pouces.

Chez moi je travail sur un MacPro Quad Core 2.93, disque dur SSD, 8 Go Ram DDR3.

Chaque fois que j'allume le PC du travail j'ai l'angoisse.

Je ne peut pas travaillez avec Eclipse, IntelliJ ou PHPStorm sans que le PC bloque, et bloqué n'est pas un mauvais mot, ma souris ce bloque 10 secondes si je défile une longue page de code etc etc

J'en viendrais même à m'acheter ma propre machine portable et l'emmener au travail juste pour être tranquille.

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.