Reprise du message précédent :

 
Y'a aussi un peu de ça je l'avoue: si je me donne a fond pour mon boulot, j'aime pas qu'on vienne me demander combien de temps j'ai passé sur quoi exactement. Des fois c'est "pour savoir", mais des fois (souvent) je dois me justifier, et ça me casse les couilles. Si mon chef de projet me fait pas confiance, pourquoi il m'a recruté?

Oui, vu comme ça c'est pas faux. Ce qui me chiffonne avec la publicité c'est que c'est souvent justifié par ce que ça apporte à la victime au consommateur, et au marché. La publicité ça ne rapporte qu'à celui qui l'achète.  
 
Mais tu as raison, l'argument "c'est mauvais pour la société" ne suffit pas. Ce qui fait de la publicité une activité particulièrement néfaste, c'est sa capacité d'une part à conditionner les esprits, et d'autre part à fausser le marché.

J'ai décidé que la prochaine fois que j'écris un technical design (et ça arrivera bientôt), je spécifierai que le soft sera réalisé en WinDev. Juste pour voir si quelqu'un relit vraiment ce que j'écris parce que j'ai des doutes

Oooh technique Van Halen

rencontre avec l'actionnaire
Je sais pas trop comment ça s'est passé.

 
Je pense que tu surestimes grandement les managers de ce pays.
Et le pire, c'est que quand t'en as des bons, ils dépensent une grande partie de leur énergie et de leur temps à minimiser les dégâts des demeurés au-dessus d'eux dans la hiérarchie.

 
le nombre de documents techniques qui sont probablement jamais lus/lus en diagonal sans fournir l'effort intellectuel de comprendre  ...

mais si ils le lisent, tu es prêt a subir du windev ?

 

 
ça me rappelle dans mon ancienne boite (américaine de 1K salariés, une centaine au UK), un jour, un genre de finance controller est venu nous voir pour faire un audit complet des compétences, jobs, coûts  etc...
 
Peu après son départ, un mec trouve sa lettre de licenciement sur son bureau (avec instruction de quitter les lieux dans les deux heures qui suivent - mais ça c'était normal, il y a des clauses de confidentialité énormes dans cette boite).
 
Maintenant la raison pour laquelle le mec s'était fait viré :
 
Le job du mec viré consistait à faire des rapports ultra-détaillés sur certaines de nos activités. Il envoyait son rapport tous les 3 mois par email à un alias qui regroupait plusieurs personnes toutes situées aux USA.
Problème : si l'alias était toujours là, les personnes qui en faisaient partie avaient toutes été licenciées depuis plus de deux ans. En clair, PERSONNE ne lisait les rapports du mec depuis quasi deux ans. Le mec servait à rien, il était complètement useless et n'en savait rien.    
 
Je sais pas ce qui m'aurait le plus déprimé à sa place, m'être fait licencié ou savoir que tout le temps que j'ai passé était complètement inutile. Le pire étant que le mec en question était du genre très sérieux et très appliqué.
 
En même temps, j'ai jamais compris comment le mec a pu continuer à bosser sans jamais recevoir de feedback et sans s'en être inquiété à aucun moment.  

Plot twist, il savait que personne ne lisait ses emails et compilait des lolcats pendant 3 mois.

 
Possible, mais si c'est ça, le mec jouait bien la comédie.  

J'ai compris la référence \o/
 

Avant je sais qu'ils étaient lus parce qu'il y avait un vrai review avec des vrais gens qui connaissent l'architecture. Maintenant je me demande. Si ça se trouve ça sera des nouveaux à qui j'ai tout appris    
 

De ce côté là y'a aucun risque
 

Oulah, c'est des petits joueurs Ici c'est la redoutable efficacité allemande, t'es dehors en 20 minutes, t'as même pas le temps de digérer

Le problème est là, c'est pas lié aux timesheets. T'as une relation malsaine avec tes managers donc visiblement, à raison, t'es en défiance avec ce qu'ils peuvent proposer.
Désolé d'incarner des situations Bisounours, mais c'est ce que j'essaie de faire au quotidien dans mon taff de manager, d'avoir la confiance de mes équipes et de la garder pour qu'on avance ensemble dans le même sens. Je pense pas trop mal bosser vu que 2 des devs de mon équipe étaient dans mon équipe dans ma boîte d'avant et m'ont rejoint qd ils ont démissionné.

Toujours le pb de confiance, je sais pas comment vous faites pour bosser sans relation de confiance...

C'est pas faux, mais c'est aussi, selon moi, le but du manager, de faire "éponge" aux merdes qui arrivent au-dessus (un peu ce qu'on retrouve avec le scrumaster en Scrum, qui a notamment pour but de préserver l'équipe lors des itérations).

 
Je sais pas, j'ai ptêtre aussi le sentiment que le boulot d'un dév c'est de produire du code (grosso modo hein), pas de s'occuper de l'administratif. Ca c'est le boulot des chefs. Ils sont mieux payés parce qu'ils acceptent de faire du reporting chiant, donc c'est à eux de le faire  

'tain je bosse sur les vibrations en ce moment, et je peux pas virer cette putain de chanson des Beach Boys de ma tête

 
https://www.youtube.com/watch?v=6A-IoOEPbUs

Donc si je résume, en forçant le trait, tu veux pouvoir pisser du code à pas cher sans qu'on te fasse chier c'est ça ?
 
Parce que des devs mieux payés que des managers j'en connais (c'est une minorité en France on est d'accord).
Si l'administratif dont tu parles te permet d'être moins sous pression avec des deadlines intenables parce que le capacity planning a pas pu être fait correctement, c'est vraiment si inutile ?
Si l'administratif dont tu parles permet d'embaucher davantage de personnes dans l'équipe de dev parce qu'on se rend compte que les devs peuvent bosser qu'à 50% sur des sujets planifiés (c'est le taux de mon équipe ces derniers mois), c'est vraiment si inutile ?

Mais ça, c'est pas qu'en France.
Le rôle d'un manager aux US (en tout cas, c'était ainsi dans ma grande boite à San Jose), c'était entre autres d'isoler complètement sa team des niveaux supérieurs.
 
A+,

C'est ça    (bon j'aime pas pisser du code spécialement, mais faire mon boulot sans qu'on me fasse chier ce serait cool oui).
J'avais mis le smiley pour montrer qu'il fallait pas le prendre complètement sérieusement, mais il ya une part de vérité. Dans l'exemple dont tu parles, le problème pour moi est qu'on demande a des dévs trop de boulot dans pas assez de teps. Le pb est là, faut le prendre à la base, pas demander aux dévs à suppléer à ce problème en faisant du reporting pour convaincre des chefs pour qu'ils fassent bien leur boulot. Et c'est aussi aux devs de dire: voila notre capacité de production, on a pas fini mais c'est la vie. Et ça passe pas forcément par du reporting.

t'es vraiment parti en couilles là, tu peux pas mettre toutes les réunions et toutes les tâches de la journée, du coup sur la TS il reste que les tâches principales de dev. D'autre part si t'as un problème de bloat de process, tu le corriges en ajoutant du monde ? t'as pas l'impression que le carré du nombre de personne va venir te rattraper ?

c'est quoi le schéma d'attaque ? tu as le hash et tu veux retrouver à quel texte correspond le hash ?  
 
mais pour faire quoi c'est quoi le use-case de l'attaque avec ça ?

 
ça passe par quoi alors ? Tu fais comment pour décider ce qui est juste en terme de prix pour les clients au final ? De toutes manières, le reporting il y en a toujours quand il s'agit de décider du juste prix d'un service délivré par une équipe. Même si tu comptes pas les heures, à un moment donné ou à un autre, t'es bien obligé de dire au client : ça fera tant de jours de dev pour tant de pognon. Vu que le but du jeu des boites, ça reste quand même de pouvoir proposer des prix attractifs pour un service de qualité, en étant rentables pour leurs actionnaires ou ceux qui possèdent la boite, à un moment donné il faut bien des outils pour "mesurer", parce que sinon, ta boite elle va un jour ou l'autre droit dans le mur, sauf bien sûr si tu as un monopole sur un marché et/ou si c'est une situation où le client de toutes manières n'a pas le choix et va payer ce que la boite demande.
 
Et sinon pour ton problème : "on demande a des devs trop de boulot dans pas assez de temps", ben un reporting correctement fait permet de le détecter et de justement relâcher la pression sur les employés alors que sans reporting, c'est un peu la porte ouverte à l'appréciation de ton manager et de son feeling qui peut juste mettre les retards sur le dos de telle ou telle personne, juste parce que le mec a l'air plus détendu ou plus cool par rapport à son boulot... Bref, le reporting c'est chiant, mais pas de reporting, ça peut être pire.

 
Ben ça peut passer par  lire les calculs de vélocité si on est agiles, ou par écouter les stand up meetings pour savoir qui fait quoi. La deuxième question je sais pas y répondre, c'est pas aux dévs de définir ça.
J'ai l'impression que c'est aux managers de s'intéresser à la vie de l'équipe, et pas de simplement attendre un graphe autogénéré par l'outil de reporting  dans leur boîte mail. Mais je me trompe peut-être, j'ai jamais fait chef, alors si ça se trouve le reporting c'est la moins pire des solutions en pratique, mais ça me paraitrait pourri quand même.

 
Je pense que le reporting est indispensable, mais qu'évidemment, c'est la qualité et sa visibilité / son empreinte qui compte.
 
Je ne suis pas manager, je ne supervise que 3 personnes (bientôt 4)  (d'ailleurs un manager c'est à partir de combien de personnes ?) et on a mis en place un comptage du temps effectif que depuis quelques mois. On utilise une app sur osx (mais qui existe aussi sur windows) qui est un genre de "Multi-chronos" connectés aux projets qu'on a :
 

 
Franchement, l'empreinte est minimum. En tout, ça doit prendre au max 2 minutes par jours de sélectionner le projet et/ou la task et d'appuyer sur start/stop.  
ça a quand même bien aidé à voir certains projets qui coutaient bcp plus chers que ce qu'on pensait, et le contraire aussi. On a pu ajuster les prix etc... On a pas du tout fait cela pour mesurer les performances individuelles des employés, même si on voit bien ceux qui bossent 8 heures et ceux qui bossent en dehors de leurs heures. ça permet aussi de compter ses heures le week-end quand un site lâche, ou un travail urgent de maintenant sur une applie arrive... Et ensuite, on peut récup plus facilement ses heures et le boss se rend mieux compte et donc devient plus souple pour les horaires.
 
Grosso merdo, on a eu quand même plus d'avantages que d'inconvénient, mais j'imagine que ça peut être très différent suivant le secteur, les managers, etc...

hello ? un prix ça se calcule par la tolérance du marché, pas par coûts + marge.

 
le coût + marge font largement partie de ce qui crée la tolérance du marché comme tu dis. Après je suis d'accord qu'il y a bcp de contre-exemple. Près de moi, ma femme, bosse dans une boite de matériaux certifiés pour l'aéronautique (des alliages) et ils ont des monopoles de certification sur certains produits... En clair, ils peuvent fixer le prix qu'ils veulent et du coup, ça va complètement changer leur manière de travailler
 
Maintenant, dans un marché (ultra) concurrentiel, la "tolérance du marché" est souvent intrinsèquement lié à l'équation coût/qualité/marge. Et là où je bosse, cette adéquation est totale.

ouai voilà ça dépend de la concurrence

si tu fais partie de l'élite, tu vas pas te mettre dans un boulot qui va naturellement partir en Inde.

Et jamais personne bosse moins de 8h effectives? Je dis bullshit, tu bluffes, all-in. Avec mes anciens collègues on était d'accord qu'on était en général à 5/6h effectives par jour, pour une présence totale de 10h.

PS: Et j'imagine que ceux qui bossent plus par jour seront mieux vus au final, même si c'est pas le but, même si le présentéisme c'est mal.

 
Oui mais moi "j'essaye" juste de pas être trop con tu vois.  

c'est pas plutôt adblock tout court ça ? (deux softs qui n'ont rien à voir)
et puis je m'en tape : comme je dis je n'utilise pas leur listes, j'ai juste une liste manuelle pour les pubs qui m'embêtent

Adblockplus aussi : http://blog.emploi-e-commerce.com/ [...] s-blocage/
 
A partir du moment où tu as une société derrière ce genre d'extension, tu peux t'attendre à tout et n'importe quoi.

Ils disent que Google est dans la liste aussi, or les pubs Google sont bloquées par ADP dans la liste standard

http://thecodist.com/article/my-bi [...] programmer
on va dire que j'essaye de m'en sortir

 
Le but n'est pas de compter le boulot effectif précisément. Les pauses, les parties de ping pong, d'échecs, ou même rien branler parce que justement tu as besoins d'arrêter pour pouvoir réfléchir plus tard, c'est inclus hein. Tu stoppes pas le timer parce que tu vas boire un coup avec un collègue, ou parce que tu vas jouer au ping pong pendant 15 minutes. Enfin nous on fait pas cela.
Tu stoppes le timer quand tu changes de task, d'objectif. Pas PENDANT la task. Si je me sens trop crever pour bosser, le timer, je l'arrête, je rentre chez moi et je le redémarre à la maison. J'arrive à 10 heures bien souvent, la plupart du temps, je tourne à 8 en moyenne, mais je fais absolument pas exprès et je m'en branle en fait. C'est juste pour voir par projet les nombre d'heures passées "dessus" pour pouvoir voir là où on traine, là où on speed etc...
 
Un temps nécessaire pour un projet, ça comprend aussi de laisser reposer le cerveau, de se détendre etc... Les meetings aussi quand c'est sur le projet, ça en fait partie. On est pas là à pointer comme à l'usine si c'est ce à quoi tu pense.

http://fredwu.me/post/142289849178 [...] ou-are-not

Je vais repréciser mon propos dans mon cas perso
J'ai actuellement 3 devs. On a un certains nombre de tâches incompressibles (exploitation des sites, support...) qui "empiètent" sur notre capacité à faire des sprint Scrum sur des évolutions/fix identifiés et planifiables.
J'ai besoin de savoir quel % du temps mes devs passent sur les items du sprint, à la fois pour identifier les erreurs collectives de chiffrage ainsi que pour identifier ce %.
Quand j'ai commencé à faire du Scrum, on avait le burndown mais qui masque en fait des effets qui peuvent se compenser et le graphe t'apprendra rien. Exemple : t'as sous-chiffrés mais en fait t'as + de dispo que prévu, du coup ton burndown est normal alors qu'en fait t'as 2 erreurs (chiffrage pourris + temps dispo mal estimé).

Si on vient me voir en me disant, on a tel projet qu'on voudrait faire, je fais un macro chiffrage avec mon équipe, j'applique le coeff de 50% dans mon calcul et j'ai un estimatif réaliste du temps calendaire à passer pour le projet en question.
Si on vient me dire, en fait il faut le projet 1 mois avant, ben fuck ce sera sans moi, car j'ai des chiffres pour appuyer le planning proposé.
Donc mon process il est pas bloaté du tout, c'est juste que mes devs peuvent bosser à 50% sur les sprint, deal with. Si on vient me dire qu'on veut 80%, pas de pb : on fait plus de support, on fait l'exploit 1 jour sur X. Faut savoir ce qu'on veut Si on veut augmenter la capacité de production, ça passera obligatoirement par + de monde (et la focalisation augmentera à moyen terme car support et exploit, en pratique c'est un coût fixe, donc tout dev que j'ajoute apporte bcp de production possible sur un sprint).
Méthode testée et approuvée dans ma boîte actuelle, avec de 3 à 5 devs et dans ma boîte précédente avec 10 devs dans mon équipe (et 25 l'équipe tech).

Manager, ça commence à 1, t'es manager

Il est des nôtreeeeees  

Edit : fuck je fais des Jubi-post

Moi aussi alors