Reprise du message précédent :

Avec une équipe comme ça, les devs ils feraient pas de télétravail remarque

Oui mais c'est assez récent : http://www.legifrance.gouv.fr/affi [...] rieLien=id
 
Ca me fait réaliser que ça fait plus d'un an que j'ai pas eu à m'occuper d'un marché public, et que j'avais sous-estimé à quel point cet aspect de mon nouveau boulot est appréciable

voilà
ma structur a décrété que le seuil de 4K , c'est bien
 

qu'est ce que ça peut me gonfler  
je crois que le pire est de ne pas avoir le droit de discuter du projet avec les candidats avant la clôture. Tu vois qu'ils font une connerie, mais tu ne peux pas leur dire s'il ne veulent pas poser la question par écrit

Dans un MAPA tu peux prévoir une phase de négociation. C'est un peu lourd mais ça permet de rectifier le tir

nanananananananananananana
 
http://ladistance.fr/Batman/Elancourt
 

J'ai dû prendre congé pour le faire parce que les banques prennent pas congé aujourd'hui
 
Et je dois quand même me connecter pour suivre deux trucs importants

la suisse produit  

A ce niveau là, il faut que tu essayes de restructurer un minimum  l'organisation de ton équipe
 
Essaies d'avoir qq point de repères fixes, où vous êtes tous là
 
 
Pas besoin de ne faire que ça, juste qquns, ça permettra de restructurer un peu les choses

C'est surtout une conséquence, quand on aime pas quelque chose, on a tendance à l'éviter, c'est humain

Quand une équipe se monte, avant qu'elle ait acquis tous ses automatismes et que tout (ou partie) soit huilé,
il faut passer par une phase où on apprend à se connaître, où on découvre ses points forts/faibles,
où on met en place les procédures, les automatismes de fonctionnement arrivent à la fin de tout ça

Sans cette phase là, ça ne peut pas marcher, et la situation que tu décris me fait penser à des personnes livrées à elle
même, pas à une équipe

L'histoire du déploiement traité par dessus la jambe sur le serveur (pas maintenu) est symptomatique d'une personne complètement
démotivée (c'est ça ou c'est vraiment une chèvre)

Vous avez pas de moment de référence en tant qu'équipe, qui donne le sentiment qu'on ne surnage/survit pas tout seul dans son coin,
dans l'indifférence totale

 
Merci pour vos réponses, je pense aussi que je vais rester sur un salaire correct et qu'en fonction de la valeur des Stocks options, ils n'ont qu'à me faire plaisir en primes à moindre frais.
C'est une startup qui à un pied dans les banques, faudrait que je regarde le potentiel d'une telle société sur le marché.

C'est bien connu, pas de bras, pas de chocolat  

 
Alors:
1. No matter how hot she looks, somebody somewhere is tired of her shit.
2. J'exige d'avoir l'avis de 0x90. Et pas que sur les bars à putes.

Niveau contexte de travail, on avait un équipe un peu petite + un énorme changement technique
à faire sans réel apport de fonctionnalité , du coup y'a pas mal de pression pour qu'on "se dépêche"
et qu'on puisse recommencer à améliorer/innover. (la définition du terme "se dépêcher" reste libre...)

C'est rien de très original mais ça veut dire que l'équipe doit faire des compromis, et si on est pas là
quand le compromis a été décidé on peut avoir l'impression que la décision finale est stupide ou issue
d'un manque de soin. Chacun a une perception différente de ce qui compte, de ce sur quoi on peut
temporairement fermer les yeux, de la réalité ou non du coté temporaire, de ce qui fait perdre du temps...
bref, chacun aurait fait le compromis différemment. Rien de tout cela ne s'améliore en ne venant pas
au bureau ou en ne participant pas aux débats ou en les écourtant.

Dans ce cas par exemple, nico arrive sur un serveur, voit du code de gestion de backup de qualité assez basse
(mais rien n'était cassé et on a du monitoring), directement dans le dossier du cron et divergent de la tête du repo stable.
Bah en fait :
- C'est dans le cron parce que l'alternative qu'on avait c'était d'exécuter le code dans le dossier checkouté par
le serveur, dossier qui appartient à un utilisateur de niveau plus faible que celui qui exécute le cron, la séparation
entre les deux était volontaire pour des raisons de sécurité et pour éviter que le script ne soit dépendant d'un autre
script qui change la version dans le dossier checkouté (un problème que l'on a eu, mais qui est résolu depuis, on a
plusieurs dossiers suivant l'usage).
- La divergence sur un serveur venait du fait que la version du serveur était plus ancienne, elle existait sous forme
versionnée mais c'était pas la dernière version. C'est quand même gênant, prévisible parce qu'on a découplé ce code du
repo, sans mettre de système d'alerte pour savoir quand les deux divergent, et qu'on a pas automatisé le déploiement
sur tout les serveurs des scripts cron. Le process est donc largement améliorable. Une raison de la non-amélioration
est la décision consciente que c'était pas suffisamment mauvais pour être problématique et qu'on pouvait apporter
plus de valeur en bossant sur autre chose, c'était peut-être un mauvais choix mais pas du jem'enfoutisme.

Sur d'autres pb c'est souvent comme ça, y'a une estimation différente de l'importance relative des paramètres
à prendre en compte, souvent dépendante d'une divergence dans les valeurs censées être communes.
Donc à chaque décision d'améliorer ou pas un point, soit y'en a la moitié qui est énervée qu'on perde du temps sur un
point secondaire, soit l'autre moitié gueule ou déprime parce qu'on a baissé la qualité sur ce point essentiel...
Et généralement, quand ça gueule c'est sur le problème en cours et pas sur les raisons d'origines qui font qu'on a pas
tous envie de prendre la même décision, ça va donc repéter le lendemain et petit à petit la frustration s'installe jusqu'à
ce que certains se désengagent de la discussion (et soient d'autant plus frustrés que leur opinion soit encore moins
représentée).

Pour le coup je pense que c'est un peu au chef de propager les valeurs et de les rappeler quand on les a oublié,
ça peut arriver de zapper un truc quand on a le nez dans le guidon ou que ça fait longtemps qu'on a pas eu besoin
d'exercer un point particulier des méthodes de travail. Sans devoir pour autant nous fliquer, il est normalement plus
en position que nous pour maintenir la vision d'origine et identifier les trucs qui ne se voient que de loin.
(D'ailleurs les anciens bureaux avaient des posters avec des valeurs XP/agile/scrum/..., ils n'y sont plus... et on pourrait
ptêtre aussi ajouter les accords toltèques.)

un énorme changement technique à faire sans réel apport de fonctionnalité => vous faites un rewrite sans apport fonctionnel du tout ? depuis combien de temps ?

J'ai moi-même eu à piloter une refonte complète de nos outils fin 2008 et je confirme le "political suicide"

Les autres termes mis en gras > ça manque clairement de cohésion. Faut vous mettre d'accord sur des bases communes qui soient discutées et acceptées (imposées si jamais il n'y a pas de consensus).
Dernier exemple en date chez nous : on est en train de généraliser la mise en oeuvre du code review dans toutes les équipes (pour l'instant mon équipe en faisait seule depuis le début de l'année).
On a fait une réu pour en discuter entre équipe et ça a bien chauffé Parce que nos critères n'étaient pas forcément les leurs. Au final on est arrivé à un consensus et depuis l'arrivée des autres équipes sur l'outil de CR se passe bien.

nraynaud > si t'as du budget pour ça, je peux te conseiller notre coach en communication.

A mon avis y'a trop peu d'interactions entre vous pour y avoir de la cohésion. Tout le monde se dit: "l'autre s'en fout, alors pourquoi je m'impliquerait". C'est pas pour rien que les devs aiment les écrans de reporting avec du vert quand ça marche.

 
On passe de Drupal à Django, on tente de faire ça progressivement (en gros controller par controller, avec bases de données communes).
Il reste des big-bangs, principalement l'interface utilisateur où on va passer publiquement d'un coup à une nouvelle version,
par contre les cdp ont déjà accès à cette nouvelle UI et peuvent la tester/valider (pour certaines tâches ils la préfèrent déjà...).
Pendant ce temps on bosse quand même sur les fonctionnalités quand ça touche pas un truc qu'on est entrain de migrer,  
en tentant de limiter la quantité pour réduire la durée du grand écart. On a pas trop envie de se battre sur un bout de code pour
des raisons qui mélangeraient à la fois technique et fonctionnel, donc on tente de tenir une migration technique à fonctionnalité égale,
ensuite on se ira se battre pour changer/ajouter/supprimer des fonctionnalités.
C'est la théorie en tout cas, y'a des trucs très très pourris dans l'existant et c'est toujours dur pour le moral de migrer tel quel,
surtout quand on a l'impression que "corriger" un problème sera moins couteux que de reproduire un comportement existant insatisfaisant.
 
C'est un changement énorme et risqué, mais quelque part j'aurais pas envie de me retrouver dans la situation de Facebook avec une
pile de PHP à peine gérable et surtout pas remplaçable (même si économiquement ils se démerdent mieux que nous), je pense
pas non plus qu'on soit dans une situation à la Netscape.
 
Accessoirement, c'est grâce au rewrite que les dev savent ce qu'est censé faire le produit. On a pas une culture de spec, on en veut pas
vraiment, mais par contre les comportements existants sont tels que parfois personne n'est capable de déterminer s'il s'agissait d'un bug
ou d'un comportement attendu, des customs faites pour certains clients dans Drupal en dehors de l'équipe de dev n'ont pas aidé non plus.

1) j'ai lancé en connaissance de cause le rewrite, je suis de toutes façons plus ou moins au bout dans cette boîte. On est encore en état de livrer et de corriger des bugs.
2) je ne crois pas que faire des modifs en live sur le serveur sans les committer fasse partie des compromis acceptables et non, j'ai pas pensé qu'il était necessaire de le préciser.

Je sais pas hein, mais vu comment vous avez l'air de dire que tout va à vau-l'eau et que vous êtes en plein rewrite, sans specs vous allez bien en chier sur le moyen terme. "Mais attends, ça marchait comme ça avant ? Je sais pu... mais du coup, c'est bien ce qu'on veut ?"

encore une fois, leve tes fesses et va le dire en face.  
 
je suis pas un bon developeur et pas forcement un excellent PM mais y a un truc qui marche mieux que n'importe quoi, c'est d'aller voir la personne et discuter ou passer un coup de fil, plutot qu'un mail ou un message sur un forum.

</ 2 cents>

Pour le point 2, sur un projet, on faisait une clean install pour éviter ce genre de chose. On supprime tout et tant pis pour les modifs locales

Je pense qu'un regard extérieur (et neutre) serait le bienvenue, en effet, coach en comm ou pas

je l'ai l'ai dit déjà à celui qui a fait ça.

La question n'est pas trop précisément ce point de commit de script, mais la dérive globale du merdier.

1) je me doute que tu l'as pas lancé pour le plaisir Mais c'est usant un rewrite. J'ai failli quitter la boîte suite à celui que j'ai mené
2) on est encore dans la croyance et dans le relatif. Tant que c'est pas marqué, ça rentrera pas dans la culture. Je reprends mon exemple des codes reviews. Y a un moment donné où des gars mettaient des commentaires et on savait pas d'où ils sortaient la règle => du coup on est en train de rédiger les règles à respecter. Ca donne une référence absolu et moins de débats inutiles.

Tu peux régler ça par du testing fonctionnel et unitaire.
 

Ce n'est que l'accumulation de petites choses je pense.
Comme qd tu fais du scrum et que tu commences à faire sauter des morning meetings.

Oui, et, à condition que ce soit bien fait, ce sera structurant et ça obligera à bien définir les modules/unités/etc ...
Et du coup, ça permettra de savoir où on va (à défaut de savoir d'où on vient), et de mesurer le travail accompli

ça peut aussi te servir à la non-régression lors de rewrite.

de mesurer le travail accompli

tiens, l'IHM de VS 2012 a été développée avec GTK

kadreg.org is baque \o/

Torchlight II
 
L'Alchemist s'est pris une bastos, le seul "invocateur" avec des pets un peu sérieux est l'Engineer et ils sont super nerfés (le pet niveau 1 est un medbot avec une AoE heal, le suivant est niveau 14 et ce sont des mines mobiles qui vivent ~30s avant d'exploser spontanément, puis niveau 21 un bot tourelle/autocanon, et enfin niveau 42 un truc qui peut ptet tanker, plus moyen d'avoir une chiée de trucs tout autour qui se font les trash mobs pendant qu'on se tourne les pouces )
 
(en plus les fishing holes hors des villes ont des charges limitées maintenant )

Y'a des choses qui ne changeront jamais avec Windows... J'ai beau ête sous Win8, il faut quand même redémarrer le PC après avoir installé ... un pad

kadreg.org is basque et il va faire tout péter  

C'est là que ça se corse  

Merci a tous pour les 3 dernières pages, c'était vraiment intéressant à lire

Hum...
T'es un manager : ton job c'est de spécifier un résultat, pas forcément le moyen d'y parvenir.
C'est une des choses que je trouve le plus dur à faire (surtout si tu connais leur job et que tu as donc une opinion forte sur l'approche), mais c'est aussi un des points les plus intéressant du management : les gens sont intelligents, et si tu les laisses libre du moyen, tu seras surpris (en bien) des idées que tu va voir. Par contre le résultat est pas négociable .

Après t'as un devoir de formation / développement de ton équipe, donc rien t'interdis de discuter leur approche / proposer des améliorations .
Sur ton exemple de Backup, spécifie exactement ce que tu voudrais que ça fasse, et laisse les proposer une approche.  Un truc que j'aime bien faire c'est prendre un gars de l'équipe et le rendre responsable de collecter / proposer l'approche, et de leader le sujet. Si tu marques ta confiance et montre que tu suis les propositions, tu les verras se sortir les doigts comme jamais
Teste le, tu seras surpris.

Si tu es confronté au problème qu'ils se satisfont de procédures que tu juges faible c'est que tu es pas assez précis sur ta description du résultat à atteindre (si c'était précis les gars verraient en quoi leur procédure est faible)

Dsl, jamais eu ce besoin...
Tout ce qu'on a chez nous est home made, avec du cognos

+1000

A voir aussi le talk de talgram sur le style de leadership

Ecoute p'tit, rien ne remplace l'école de la vie.