Reprise du message précédent :
https://tech.slashdot.org/story/16/ [...] lashdot%29
 
Nraynaud, on t'a vu.

la liberté d'expression devrait être interdite à certaines personnes
 
cordialement

ma compréhension d'un daily meeting c'est que c'est un standup meeting, et qu'il doit être bref. En imaginant une équipe scrum de 8 dev, je veux bien les interviewer un par un durant le meeting pour savoir ce qu'ils ont fait la veille avec une précision à l'heure, mais je pense que ça va vite pourrir le timing du meeting, et que les gens vont râler (à juste titre). La timesheet c'est un moyen assez cost effective d'obtenir le même détail d'information, et ça a l'avantage d'être asynchrone (tu peux la replir le soir en allant chier, à 11h du matin, à 22h, c'est comme tu veux), donc c'est vachement plus simple à organiser.
Et je crois que ça fait aussi 2 pages que j'essaye d'expliquer en quoi c'est utile, sachant que le postulat de base ici ça a été  : c'est nul ça sert à rien. Alors oui je suis un peu défensif, parce que ça me gonfle toujours un peu quand les gens critiquent ça sans chercher à comprendre. Surtout quand après plus de 8 ans à être manager, je pourrais remplir 15 jubi pavés d'exemples où ça a servit les gens meme qui critiquent le plus.
Dans mon ancienne équipe (25 personnes donc, je te laisse imagine le bordel si je devais les interviewer 1 par 1 pour chopper l'info, tous les jours) j'avais expliqué à quoi servaient les timesheets, et je leur avais démontré l'utilité. Y'avait plusieurs utilisations :  
- reporting project : ça sert à suivre les "actuals", et toutes les méthodologies projet se basent sur la comparaison de la progression effective vs le forecast a un instant T. C'est d'ailleurs pareil en scrum, puisque c'est exactement ce que fait un burn down chart. En méthode waterfall classique, ça te permet de suivre la progression "à la tache". Pour être franc c'était pas l'usage premier, mais comme les timesheets drivaient le reporting projet, le PM devait quand meme checker que les chiffres ne partaient pas en vrille, parce que que c'était sur sa gueule (et la mienne) que ça tombait si jamais c'était le cas, et jamais sur celle des devs soit dit en passant
- base de données historique : chaque année, pendant la phase de préparation budgétaire, on se servait de l'historique des timesheets pour faire les estimations. C'était à mon sens l'usage le plus utile, parce que ça nous donnait des estimations de super bonne qualité (quand t'as 30 projets ou la business analysis prend entre 15 et 20% du temps de dev, tu peux te dire qu'en mettant 20% tes chances de te gauffrer sont super minimes).
- vente des demandes d'extension d'équipe au management : le management c'est beaucoup du bluff, et le premier qui vient avec des faits gagne. Quand tu demandes +5personne, le management te répond en général non, comme un réflexe pavlovien. Si tu sors des chiffres montrant que typiquement un projet prend 90 jours (sur un historique à 3 ans, oy'a plus trop de place pour contester le chiffre, ça devient un fait); on sait qu'une personne, c'est 180 jours effectifs de travail si tu sors les congés et les meetings; on peut donc dire que sous réserve que les projets puissent se faire séquentiellement, une personne fait 2 projets par an. Donc tu sais que si y'a 6 projets qui arrivent dans le pipeline, si t'as que 2 personnes t'es short d'une, et que ça marchera pas. Je mets au défi n'importe quel manager sur terre de résister à cette explication, parce que le gars sait que si ton projet foire, tu lui ressortiras la présentation plus les minutes dans la gueule et qu'il passera pour un gland. Dans les faits, j'ai avec succès justifié de passer de 20 personnes à 120 sur 3 ans, et les timesheets ça a été 80% de ma réussite (pour justifier les ressources en plus, et surtout pour me permettre de pas me planter en ayant des forecasts réalistes). (les 20% restant c'est mon charisme et ma grosse bite). Et d'ailleurs quand mon équipe a compris ça, j'ai plus eu aucune bataille à ce sujet, curieusement.
- justification de moyens / d'outil : là encore, les timesheets me permettant de calculer des durées moyennes de tache, ainsi que de compter le nombre de fois que la tache est faite dans l'année, j'ai pu trivialement justifier d'avoir des moyens : sur des volants horaires aussi énorme, même 5% de productivité gagné ça paye souvent 4-5 fois l'outil. Le plus bel exemple a été les voyages : grace aux timesheets, j'ai pu démontrer la plus-value de faire certaines étapes du projet (pré-study, tests) sur site sur les marchés, ce qui a permis à mon équipe de voyager aux 4 coins du monde pendant 3 ans, tout en étant plus efficace.
 
Les timesheets pour la facturation ça me choque pas, c'est un usage "légitime" : c'est domage de se cantonner à ça comme finalité, mais c'est très compréhensible d'un point de vue équité du client : si je suis ton client, et que tu bosses pour moi que 15h, je veux payer 15h, pas 30 ou 5 ou 12. Et si t'es engagé en time & material, y'a pas vraiment le choix, on doit donner le détail au client de toute façon. Après si ta charge est fixe toutes les semaines (genre 2j par semaine chez le client X), alors oui timesheeter pour ça est une perte de temps. Mais là encore si tu creuses tu verras que y'a des gens à la compta qui s'occupent de la facturation, qui ne vous connaissent pas, et que donc pour eux facturer sur base de timesheet c'est simple et rapide. La vraie question se pose donc de savoir si le temps que ça leur fait gagner justifie le temps que ça vous fait perdre. Passé une certaine taille de boite, c'est souvent un gain d'argent de facturer sur base des timesheets. Et du coup là il y a un intéret au niveau de la boite, même si du point de vue de l'équipe qui timesheet il n'y en a pas.
Mais si t'as une proposition pour garantir cette équité sans timesheet, je suis sérieusement intéressé
 

on est absolument d'accord : j'ai jamais dit que le manager avait pas le devoir d'expliquer le pourquoi des timesheets, bien au contraire. C'est juste que si il/elle ne le fait pas (ce que je considère être un manque), au lieu d'imagine immédiatement que c'est un con et que les timesheet ça sert à rien, on peut lui demander.
 

merci
 
le fait de devoir gérer un gros team ça m'a vachement poussé à faire ces réflexions. Et aussi le fait que je me suis fixé un seul dogme en tant que manager, c'est d'essayer d'être un manager que j'aimerais avoir. Et moi aussi j'ai été non manager, et ça me gonflait quand les managers faisaient de la merde. J'ai aussi eu des bons managers, et j'ai donc essayé de comprendre et d'appliquer ce qui faisait la différence entre les deux.
 

j'ai pas vocation à t'apprendre à coder (j'aurais l'air d'un con en plus), mais par contre je crois être assez bien placé pour parler de management, et pour expliquer pourquoi certaines pratiques de manager sont pas forcément que débiles si on cherche à comprendre pourquoi elles sont faites.
J'imagine que tu as des façons de bosser qui t'ont servies à plusieurs reprises, et qui dans ta tête sont des choses automatiques à mettre en place tellement tu en connais les bienfaits (tu en as d'ailleurs parlé récemment). Ben moi c'est pareil, et pouvoir faire des stats sur le temps de mon équipe ça m'a tellement servi que je le met en place à chaque fois. Là je suis en train de reconstruire une équipe, je vais le mettre en place direct. Et du coup je sais que je vais devoir expliquer pourquoi, mais je suis très confortable avec ça.
 

1/ jamais dit le contraire, on est tout à fait d'accord : j'ai jamais dit qu'il fallait imposer les timesheets, par contre une fois que l'utilisation est justifiée et la granularité ajustée, je vois pas de raison de s'y opposer par principe, alors que ça donne au manager un énorme pouvoir pour aider l'équipe
2/ j'ai pris ça comme exemple parce que ça en parlait quelques posts plus haut. Les levées de bouclier c'est toujours rigolo, j'adorais gérer ça avec mon équipe. C'est souvent très déstabilisant parce que ça tombe pas toujours là où on l'attend.
 
 

jubi pâté

En plus de servir de pop corn, le débat est intéressant. Je vais noter quelques éléments si jamais on grossit trop chez Vates (pour l'instant c'est useless ce genre de chose parce que je peux piloter à vue vu le taille de l'équipe).

Là on parle de piloter « aux instruments » en fait, ce qui est logique dans des phases complexes

Après, je pense qu'on a aussi un problème en // qui pourri le time reporting : trop de projet en même temps, et le "context switching" brûle beaucoup d'énergie. Et avoir de surcroît à noter les différentes tâches « pour de vrai », ça en devient horrible.

Autre point, il me semble que le rôle primordial du manager c'est de protéger son équipe de situation de surcharge/bottleneck. Une fois que c'est possible, le reporting devient beaucoup plus simple car moins de détail à noter : chacun va avoir peu de projets.

Jubi : sur la granularité, tu penses que ça vaut le coup de descendre sous la demi-journée ? Pour moi, si t'évite le « trop de projet », il n'y aurait pas vraiment besoin de descendre en dessous (mon expérience à moi en tout cas)

edit : ça rejoint mes lectures, le manager doit être celui qui coordonne la « ligne de production » de son équipe, et il doit s'organiser au mieux pour ça. Mieux c'est fait, moins de reporting individuel est nécessaire je pense.

(dsl pour les accents, qwerty + flemme)

Merci pour ta reponse.

Je ne pense pas que le contenu de la timesheet ne serve a rien, mais mon postulat de base etait que de le faire remplir par les devs etait pas la seule solution.
J'etait parti aussi du principe implicite que ca servait a rien d'avoir une granularite a l'heure, mais que les phrases dites durant le stand up du genre "hier j'ai passe la moitie de la journee a mettre en place un serveur Git et l'autre a creer une maquette" auraient suffi. Si c'est pas le cas ben t'as raison, y'a pas d'autre choix, mais les exemples que tu donnes me laissent penser que t'avait pas besoin d'une granularite aussi fine dans ton acienne equipe.

Quand aux timesheets pour la facturation, perso ca me choque quand c'est facture a la journee en AT: mon client est pas capable de dire qui est present dans ses locaux chaque jour? Ca me fait rire jaune, et je pense que c'est juste de la paresse. Serieux, il suffit de voir qui s'est loggue sur son poste. Meme sur les projets en interne (granularite 1 journee) ma boite est capable de me faire remplir des timesheet alors que je badge pour rentrer dans la salle de dev et que je me loggue sur l'AD.
Apres quand c'est facture a l'heure j'ai rien a dire je trouve ca logique, c'est au dev de faire le choix du temps passe dans une certaine mesure.

Peut etre que j'ai l'impression que ca viole le SRP et le Tell don't ask, et que j'essaie d'appliquer des principes de prog a du management. Ou alors c'est des bons principes tout court.

et surtout n'oublions pas que tout est parti d'une boite de 3 personnes toutes manager ( ) et toutes dans le même bureau et où aucune facturation à la journée n'est effectuée.

 
C'est un des trucs que je me suis attelé à éliminer quand j'ai pris mon nouveau job.
Temps perdu à cause du context switching et perte de visibilité sur la date de livraison sinon.
 

 
Il n'y a en général pas beaucoup de vraies tâches qui prennent moins d'1/2 jours AMHA.

En fait comme reporting idéal en temps « qu'utilisateur », ça serait un truc pré-mâché par le manager au maximum : voilà sur quoi t'es affecté comme tâche, juste à confirmer oui/non si ça a été vrai dans la journée, et si non un truc trivial genre drag and drop parmi des tâches possibles.

Pour le manager, un truc un peu « trello » like ou tu glisses les gens dans des « bulles » qui correspondent à des projets avec des tâches « récurrentes » (au sens habituelles) à l'intérieur.

En plus ça permettrai de visualiser les projets qui mobilisent le plus, avec des poupées russes pour les tâches à l'intérieur des projets. Et que l'outil fasse le calcul réel au final avec les confirmations des utilisateurs.

edit : devenu Sciforma, peut être moins merdique aujourd'hui, car ça remonte à 5 ans maintenant http://www.sciforma.com/fr-fr/
Ça doit peut être exister, mais j'ai utilisé deux outils de time report en tant qu'user, et je les ai trouvé les deux horribles en terme UI (et bien trop complexes). PSNext je crois l'un des deux.

va me falloir des cornichons et du pain frais pour digérer de tels pâté
 
Au passage bash actif sous la dernière insider  de windows

 
j'aime bien ton image...et en effet, j'avais 25 personnes sous mes ordres directs, mais on était pas loin de 120 à bosser sur l'ecommerce, et je devais rendre compte de l'activité projet globale
 
Notre granularité de timesheet c'était :  
Timesheeting à la semaine pour tout le monde, je me foutais de la granularité quotidienne
- pour les PM, BA, Testeurs, Infra, etc... : phase projet / tache (de sorte que sur une semaine, les gens avaient typiquement 1-3 taches, avec un max de 5 je dirais
- pour les devs : support ou projet, et pour les projets, ils timesheetaient dans JIRA à la tache (on avait une division simple : un projet avait 1..n requirements, un requirement avait 1..n plateforme cible, et chaque requirement/plateforme cible avait un item JIRA dédié, et c'était le niveau de timesheeting
 
Après comme toujours, il faut partir de ton besoin : tu veux faire quoi des chiffres ? si c'est pour prouver la charge (vu que tu es ton propre boss) je présume que tu sais déjà si ton équipe est sous l'eau ou pas (après tu peux vouloir quantifier de combien, et là les timesheets vont te servir)
 
Pour ton histoire de ligne de Prod, ça rejoint ce qui se fait dans les méthodes projets, qui est aussi la meme chose que les méthodes qualités : PDCA, la timesheet c'est clairement l'outil de Check : si t'as planifié que Josianne doit bosser 8h sur un sujet, c'est sympa de voir si ça a été le cas ou pas. Si ça a pas été le cas (en plus ou en moins), c'est intéressant de comprendre pourquoi (ce que la timesheet ne te dira pas, là il faut investiguer). Mais la timesheet va t'aider à pointer les delta, et à voir dans le temps si ils sont récurrents. A la fin quand tu maitrises bien ton team et ton process de forecast, les timesheets te permettent d'arriver à connaitre le biais d'estimation de chaque personne
 

on est d'accord
la journée c'est trop granulaire juste pour faire des stats à mon sens. Mensuel ça m'irait mais en fait les gens ne se souviendrait plus suffisament précisément de ce qu'ils ont fait
 

tout à fait d'accord, passé un certain niveau de parallelisme, c'est très contre productif (je suis en plein là dedans d'ailleurs )
 

faudra que je teste...tu peux faire un apt-get zsh par hasard ?

En parlant de timesheet, vu qu'on book sur les projets en fonction du budget et pas vraiment en fonction de l'activité réelle ici, mon PM a dû s'expliquer sur le fait que des activités de tests aient eu lieues (au sens de la timesheet) alors que les specs sont à peine en phase de discussion Je crois qu'il s'en est sorti à base de "too many supplier projects to book on... everybody is working on everything... that's the easiest solution we've found"

J'ai plus envie de travailler  
 
Chaque jour y'a des conneries jubijubiennes qui s'empilent et des problèmes techniques.
 
En fait je suis pas fait pour se monde, je veux aller ailleurs un endroit où je me sente pas comme un extra-terrestre arrivé là par erreur
 
Et y'a aucun espoir de trouver plus adapté, toutes les issues sont bloquées, les petites boîtes font comme les grosses par mimétisme, les grosses sont gérées par des jubi, l'artisanat ça fait bouffer personne
 
J'ai juste envie de partir.

t'es fragile

Mon manager gère 3 équipes, 5 produits, des clients pas particulièrement faciles, tout ça sans utiliser de méthodes jubijubiennes.

dites, y'a un équivalent français à amazon S3 ?

 
On y travaille mais c'est pas pour cette année à priori

OVH Object Storage  ?

Ovh mais c'est sans doute trop petit pour ton patron  
 
Sinon Numergy et Cloudwatt ont des choses et ont été réintégrés dans nos fleurons plus ou moins nationaux

je viens d'ouvrir un compte chez OVH, j'y comprends déjà rien.
j'ai créé un projet, j'ai créé un "Stockage objet", j'ai uploadé vite fait un fichier par l'interface pour tester, maintenant je veux créer une paire de clefs que je vais filer à mon appli pour uploader dans le répertoire, mais je capte pas où c'est dans l'interface.

edit: https://forum.ovh.com/showthread.ph [...] ot-allowed je me sens pas seul

c'est un service super récent j'ai l'impression, donc surement loin d'être aussi au point qu'amazon

https://en.wikipedia.org/wiki/Amazo [...] g_services
OVH c'est de l'Openstack donc l'API a l'air compatible

sauf que j'arrive pas à créer un user pour accéder à openstack.

Appel le 1007, pour les dédiés c'est relativement rapide, j'imagine que c'est la même chose pour le cloud...

le truc c'est que tant que tu reconnaitras pas comme légitime toute contrainte qui ne vient pas de toi ou du domaine technique, ça va toujours etre difficile de bosser avec d'autres gens.
 
Après n'excluons pas l'idée que ton management fait peut etre n'importe quoi, mais pour moi c'est un problème de personne, pas de management. Si je devais gérer 3 personnes, j'emploierai surement pas les mêmes méthodes que maintenant. Mais j'aurais pas non plus le même set de contraintes.
 

 
cf plus haut : donne moi le même set de contraintes (ou absence de, en l'occurence) y'a beaucoup de mes méthodes que je n'aurais plus à appliquer. Et réciproquement.
Attention grosse révélation : le management, c'est comme le dev : t'as une boite à outil, tu utilises l'outil qui va bien. Et en dev comme en management, si t'utilises l'outil comme un gland, ou que tu n'utilises pas le bon outil pour le bon problème, ben tu vas faire de la merde.
Je ne vois aucune différence entre les deux là dessus.
 

+1

bof, je sais bien que j'ai un problème, sauf que ni 2 psychiatres ni les médocs ne l'ont résolu

Je veux bien te croire. C'était juste pour donner un contre-exemple à nray. Ici jusqu'à lead/principal engineer on nous fait pas trop chier niveau reporting, donc j'imagine que ça se trouve ailleurs aussi.

oh yeah le "c'est qu'un outil", c'est ma phrase préférée.

 
D'où mon conseil de ne pas rester coincé dans le grand bassin d'emploi montpelliérain

peut-être pour l'instant je sais pas si j'ai vraiment envie de bosser.
J'ai à moitié envie de démissionner et de me laisser dériver.

 
en quoi est-ce que ce serait une situation plus désirable si tu partais ? t'arrives quand meme à faire des trucs chouettes (tex expérimentations plasturgiques), et je suis sur que tu vas finir par le faire marcher ce bordel, à force de sarcasme (je reste convaincu qu'on devrai inventer la centrale à sarcasme, rien qu'avec le topic on éclaire Paris )
 
et surtout tes fins de mois sont garanties, et tu risques plus l'éviction pour défaut de paiement. A tout prendre, ça me parait préférable à ta situation antérieure

zsh , comme apache/nginx ne fonctionnent pas pour le moment sous windows 10 , un pb avec cgroup-lite

Demande à t'en occuper toi-même. J'ai un pote qui a fait ça et a pu s'acheter la config qui allait bien. et c'était dans une grosse COGIP.

Bon, moi, je me suis fait avoir sur une mission où je ne fais que du dev et ça me saoûle profondément, j'en ai marre de ce boulot complètement alimentaire et fatiguant.
La triste vérité est que manager est moins fatiguant que développer (sur un projet un tant soit peu complexe). Quand je manageais, je ne passais pas tout le w-e à me remettre de la semaine.

C'est ça qui fausse gravement le calcul. Donc les "timesheets" de 8h, c'est moyennement utile. Mais les boîtes ont tellement peur de se faire prendre à devoir payer des heures sup qu'elles obligent à mettre des multiples de 8h. Auquel cas je ne m'emmerde pas, je mets le temps réel passé, arrondi aux 8h supérieures, même si ça compte des journées supplémentaires.

Vos devs ne sont pas au forfait jour ?

Le forfait c'est une facilité pour compter, ça ne dispense pas de respecter la loi. S'il y a une trace écrite que les mecs font plus de 35h, les heures sup sont dues (ou alors il y a des rtt en conséquence).

le support OVH est toujours aussi bon je vois.
 
Je vais donc utiliser AWS, parce qu'au moins on peut googler les problèmes.

Euh... non ?

Tu dois juste garantir 11h de repos quotidien et 35h d'affilée hebdo
http://travail-emploi.gouv.fr/droi [...] de-forfait

L'idée c'est qu'il y a un temps de travail annualisé, forfaitaire, mais conforme à la législation. Si le salarié peut prouver que son temps de travail effectif est supérieur à la législation (ça fait 1600 et quelques heures dans l'année je crois) c'est quand même pas bon pour la boite