Les études secondaires et le boulot (pas l'arbre !)

Ca fonctionne un peu comme dans notre labo... sauf que les leads (nous) ont personne en dessous, parfois un thesard mais qui est plus complementaire de nos competence que redondant ! La chef, bien qu'elle a une comprehension totale de nos manips, n'a plus l'experience pour aller a la paillasse (un chercheur titulaire, ca passe ses journees derriere un ordinateur).

Swede risque de repondre que c'est une mauvaise organisation... mais ca le serait s'il n'y avait pas une gestion du copyright. Publier un article dans une revue scientifique prend 2-3 ans de travaux, soit la duree de nos contrats. Un thesard se doit d'avoir un article en premier auteur pour pouvoir presenter sa these, un post doc se doit d'avoir un article en premier auteur dans des journaux renomees pour avoir l'espoir d'avoir un poste de titulaire... Ce qui veut dire que chacun doit avoir son propre projet.

Ce qui fait que l'absence du thesard et du post doc ne peut pas etre compensee sauf dans des trucs routiniers.

Oxytan, tu m'expliques l'organisation d'une équipe de 26 personnes avec 3 niveaux de hiérarchie (toi, les leads, les développeurs) quand je te parle d'une équipe de 7 automaticiens (dont 1 chef qui a ses propres projets à gérer, et qui n'a pas le temps d'être au courant de tout ce que l'on fait) et personne au-dessus de nous qui est techniquement capable de mettre les mains dans notre code. 
Cela n'a rien à voir

Nini a écrit: ... (dont 1 chef qui a ses propres projets à gérer, et qui n'a pas le temps d'être au courant de tout ce que l'on fait)...

un chef qui fait le même taf que ses collaborateurs, bah... c'est ce que tu veux, mais c'est pas un chef
ça me rappelle des "chefs des ventes" qui gardaient leurs propres clients après leur promotion et qui du coup, ne restaient que des commerciaux de base, parfaitement ignares niveau management. ça aussi relève aussi de l'organisation de l'entreprise.

Tu parlais des brasseurs d'air. Chez nous, les chefs ils bossent aussi.

Nini a écrit:Tu parlais des brasseurs d'air. Chez nous, les chefs ils bossent aussi.

tu le fais exprès ?
un chef, ça bosse, bien évidemment, et souvent beaucoup. mais son rôle est de gérer, contrôler, former, veiller la concurrence, enfin, plein de trucs.

Ah pas tout le temps swede, la mienne c'est celle qui brasse le plus d'air du bureau

C'est un coup à choper la crève ça fais gaffe !

Ce qui est bien avec les brasseurs d'air c'est qu'on les reconnais facilement, car ils brassent vraiment de l'air.
pas uniquement avec les bras, mais aussi avec leurs déplacements tout aussi fréquents qu'inutiles au milieu des openspace, afin de se diriger vers la personne qui les aidera a répondre à la question ( rarement justifiée ) dans laquelle ils s'investissent sans retenue.

superswede a écrit:

Nini a écrit:Tu parlais des brasseurs d'air. Chez nous, les chefs ils bossent aussi.

tu le fais exprès ?
un chef, ça bosse, bien évidemment, et souvent beaucoup. mais son rôle est de gérer, contrôler, former, veiller la concurrence, enfin, plein de trucs.

Si on parle d'une startup ou de cette taille la alors j'imagine que le chef est aussi investi dans le meme type de travail que le salarie en un peu plus reduit pour mener a bien sa fonction d'organisateur.

Nini a écrit:Oxytan, tu m'expliques l'organisation d'une équipe de 26 personnes avec 3 niveaux de hiérarchie (toi, les leads, les développeurs) quand je te parle d'une équipe de 7 automaticiens (dont 1 chef qui a ses propres projets à gérer, et qui n'a pas le temps d'être au courant de tout ce que l'on fait) et personne au-dessus de nous qui est techniquement capable de mettre les mains dans notre code. 
Cela n'a rien à voir

Ce n'est pas normal que 7 développeurs n'aient pas de chef technique capable de comprendre leur taf, même si il ne le réalise pas lui même.
j'ai jamais vu ça, et pourtant j'en ai vu des boites organisées à l'arrache.

Du coup, qui fait les devis ? les expertises ?, évalue les développeurs à l'embauche ? s'occupe de la veille techno ?

superswede a écrit:

Nini a écrit:Tu parlais des brasseurs d'air. Chez nous, les chefs ils bossent aussi.

tu le fais exprès ?
un chef, ça bosse, bien évidemment, et souvent beaucoup. mais son rôle est de gérer, contrôler, former, veiller la concurrence, enfin, plein de trucs.

Tous les boulots de chef ne sont pas les mêmes. Il affecte les projets aux gens, participe aux réunions planning, donne les priorités, certains choix techniques, nous aide techniquement... 

A côté de ça, quand je dis qu'il bosse, c'est dans le sens productivité. Il est plus utile à gérer ses propres projets pour sortir des machines, qu'à être derrière notre dos à surveiller tout ce que l'on fait et à être au courant de tout. 
D'une part, parce que suivre 6 projets suffisamment en détails pour être opérationnel sur tous, ce ne serait pas possible, et d'autre part comme je l'ai déjà dit, il ne serait pas forcément disponible en cas de défaillance du "spécialiste" de la machine 

Et c'est la même chose pour les autres chefs dans les autres services. Ils gèrent leurs mecs, mais ils font aussi leur part du boulot. En gros, c'est 10% de gestion pour 90% de productivité.

FFFF a écrit:(un chercheur titulaire, ca passe ses journees derriere un ordinateur).

ah si seulement c'était vrai partout, je respirerais beaucoup plus au boulot

oxythan a écrit:

Nini a écrit:Oxytan, tu m'expliques l'organisation d'une équipe de 26 personnes avec 3 niveaux de hiérarchie (toi, les leads, les développeurs) quand je te parle d'une équipe de 7 automaticiens (dont 1 chef qui a ses propres projets à gérer, et qui n'a pas le temps d'être au courant de tout ce que l'on fait) et personne au-dessus de nous qui est techniquement capable de mettre les mains dans notre code. 
Cela n'a rien à voir

Ce n'est pas normal que 7 développeurs n'aient pas de chef technique capable de comprendre leur taf, même si il ne le réalise pas lui même.
j'ai jamais vu ça, et pourtant j'en ai vu des boites organisées à l'arrache.

Du coup, qui fait les devis ? les expertises ?, évalue les développeurs à l'embauche ? s'occupe de la veille techno ?

Il y a un directeur technique (le fameux irremplaçable) qui connaît tous nos outils de développement, puisque c'est lui qui les a créé
Après, le plus dur n'est pas de comprendre le code, mais surtout connaître le process et ce que doit faire la machine. Ça, ce n'est pas du tout de son ressort. 
Ce serait plutôt celui des chargés d'affaires (qui sont en réalité plus nos donneurs d'ordre que notre chef de service, sur chaque projet) 
Et pour leur part, bien que ce soit à la base des anciens automaticiens, ils sont un peu dépassé sur les outils actuels pour nous remplacer complètement.

Crouzz a écrit:

FFFF a écrit:(un chercheur titulaire, ca passe ses journees derriere un ordinateur).

ah si seulement c'était vrai partout, je respirerais beaucoup plus au boulot

J'aurais du dire " un chercheur DR2/1/0" passe ses journees derriere un ordi

FFFF a écrit:

Crouzz a écrit:

FFFF a écrit:(un chercheur titulaire, ca passe ses journees derriere un ordinateur).

ah si seulement c'était vrai partout, je respirerais beaucoup plus au boulot

J'aurais du dire " un chercheur DR2/1/0" passe ses journees derriere un ordi

ah vi, un équivalent professeur des universités, alors. là d'accord, leur rôle, c'est de la gestion beaucoup, de la recherche de contrats et un peu d'écriture.

Crouzz a écrit:

FFFF a écrit:

Crouzz a écrit:

FFFF a écrit:(un chercheur titulaire, ca passe ses journees derriere un ordinateur).

ah si seulement c'était vrai partout, je respirerais beaucoup plus au boulot

J'aurais du dire " un chercheur DR2/1/0" passe ses journees derriere un ordi

ah vi, un équivalent professeur des universités, alors. là d'accord, leur rôle, c'est de la gestion beaucoup, de la recherche de contrats et un peu d'écriture.

De toute facon, ce que tu dis va dans le sens de Nini.

Moi, Oxy, ca ne me choc pas du tout qu'un chef ne connaisse pas dans les detail la maniere de faire le truc. Comme disait mon ancient chef, il y a l'idee (son boulot) et il y a la cuisine (notre boulot). Evidemment que mon chef savait comment fonctionnait ce que je faisais mais pour le faire lui meme c'est une autre histoire... puisque pour cela il faut pratiquer souvent, et comme Swede le dit, un chef ca a autre chose a faire.

Au final, tout depend de la taille de la structure ou sous-structure en question. Et pour revenir au sujet, dans une sous-structure, notamment petite, si tu es recrute pour des competences "uniques"alors forcement lorsque tu t'absentes pour X ou Y raison, tu es difficilement remplacable. Tout simplement parce qu'il existe des boites ou chacun a une tache totalement differente de ses collegues du genre, tu as 7 machines totalement differentes a gerer par 7 personnes. Une personne connaitra parfaitement sa machine mais ne connaitra que les rudiments des machines des autres.

Disons que ce ne sont pas les personnes qui doivent etre complementaires mais les savoirs. Chez nous pour eviter les problemes de vacances, chacun participle au travail d'un autre avec ses propres competences, ce qui fait qu'une personne ne peut realiser un projet entierement seule et a besoin de puiser dans le savoir de l'equipe.
En somme, sur son projet, monsieur A dirige messieurs B et C, mais monsieurs B, sur son projet dirige monsieur A et C. Et donc, si B part en vacances, son projet continue a advancer avec la charge qu'il a donne a monsieur A... bien sur sa part proper, stagne.
En somme, je dirais que 60-70% de mon temps est dedie a mon projet, et 30% de mon temps est dedie a la realisation de manips pour un autre projet. Et sur mon propre projet, 40% des taches sont realises par les autres personnes de l'equipes et 60% par moi seul et donc lorsque je m'en vais en vacances, mon projet continue a tourner a 40%

Je suis effectivement en accord avec FFFF

Oxytan à l'habitude de gérer des projets avec des architectures très modulaires où un chef gère des développeurs qui bossent chacun sur leur bout de code indépendant des autres. Je ne sais pas quel est le temps de développement moyen de chaque module ou fonction en charge par le développeur, mais je suppose que c'est de l'ordre de la semaine, voire moins. 
Lorsqu'un gars est en congé, les autres continuent à bosser sur les autres fonctions et le projet avance. 
C'est du "temps homme" assez facile à gérer. 

Dans nos projets, on est très souvent seul à bosser dessus, et parfois à 2 ou 3 maximum sur des projets plus gros, mais souvent dans nos propres domaines de compétences, en ne maîtrisant pas forcément à 100% ce que fait notre collègue.

Exceptionnellement sur des projets très longs, on s'est déjà relayé à 3 pour ne pas stopper des essais en cours chez un client, mais ça restait sur des machines assez courantes chez nous, que l'on connaissait déjà plus ou moins. 
Mais il faut quand même chaque fois faire du doublon le temps de se passer des informations, ce qui n'est pas très productif.

C'est quel type de machine ?

Bancs d'essais pour l'automobile, principalement

c'est programmé dans quel langage vos automates ?

C'est un automate maison. En très bas niveau, il y a de l'assembleur et du C. (Accessible principalement par le seul mec qui l'a créé) 

Pour les automaticiens, nous utilisons également un langage maison (proche du VB) qui est compilé une première fois pour générer du code C, puis recompilé (avec d'autres librairies en C) pour être téléchargé. 
Ça c'était "à l'ancienne" (avec même un autre langage maison plus vieux, que les plus jeunes ne connaissent pas, ou mal) sinon on a un autre progiciel maison, pour faire tourner des machines plus simples sans taper de code automate (en utilisant des plugins déjà écrits précédemment)

ok, donc vous utilisez le C comme langage intermédiaire.
Et quand il faut utiliser un debuguer, vous cherchez les bugs directement en traçant avec le source C ?

Evidemment !

oxythan a écrit:ok, donc vous utilisez le C comme langage intermédiaire.
Et quand il faut utiliser un debuguer, vous cherchez les bugs directement en traçant avec le source C ?

Je me suis déjà assez étendu sur le sujet, plus de détails en MP ce soir