Reprise du message précédent :

 
C'est pas comme si y avait pas plein d'études montrant les taux de bonne compréhension ridicule dans les échanges d'information non physique...

 
Nous on fait pourtant des meetings à plusieurs sur Skype sans aucun problème. Dans la salle de meeting, il y a un grand écran sur lequel on a Skype divisé entre tous les participants qui ont fait le choix de rester chez eux ce jour là. Rien à signaler.
 
 

 
Pourquoi l'ambiance de merde ?    
 

 
Ben oui, nous aussi et alors ? Comme je l'ai dit, si tu veux slacker quelqu'un, tu peux toujours le faire, mais lui n'est pas obligé de te répondre. Hors des slots réservés pour converser avec ses collègues (1 h tous les matins dans notre cas), on a la possibilité de se concentrer sur notre tâche si on le veut et de ne pas être dérangé. C'est un CHOIX individuel. Si tu préfères que tes collègues te parlent c'est TON choix. Mais si tu ne veux pas être dérangé, c'est un choix que nous respectons également.
 
Avec le recul et ayant connu un avant et un après cela, je dirais qu'au contraire on a évité BCP de problèmes relationnels avec les gens car quand les employés sentent qu'ils sont juste niveau temps et qu'en plus tu les déconcentres, ben, ils ont tendance à mal réagir... Donc moi je dirais que notre système est plutôt une anti-ambiance de merde.
 

 
   
 
En fait, tu pas pas lu ce que j'ai écrit. Tu sautes sur une ligne sans voir le contexte et sans faire aucun effort de compréhension. C'est comme ça que tu fais avec tes collègues aussi ? Ben tu vois, notre système nous protège justement de gens comme toi qui réagissent au 1/4 de tour sans faire l'effort d'analyser un peu la situation ou ce dont on parle.   Tu dois t'assurer d'abord que tu vas pas aller faire chier le collègue pour rien. Après comme je l'ai dit, tu peux très bien partager ta vidéo de vacance ou tu caresses des hamster hein... C'est juste que ton collègue a le droit qu'on lui foute la paix et peut ignorer ta belle vidéo sur skype. Idem quand tu veux parler physiquement à ton collègue, il a le droit de te dire : "Nope, je bosse" et c'est très bien. Après si tu estimes que c'est urgent, et bien oui, tu t'adresses au SCRUM master.

 
Je connais ces études et effectivement, il faut faire attention à ne pas sur-réagir et prendre le temps de comprendre. En même temps, le contraire est également vrai. J'ai certains collègues qui n'arrivent PAS à se comprendre quand ils se parlent en tête à tête parce qu'ils sont trop speed, réagissent au 1/4 de tour etc... Et une fois qu'ils posent par écrit ce qu'ils voulaient en fait dire, ça va tout de suite bcp mieux, je pense en particulier à une personne de notre groupe.

chez nous c'est exactement parce qu'on n'a jamais mis ce genre de système en place (même moins poussé) qu'on se retrouve avec une ambiance de merde  

Ouais donc en fait Hermes t'appliques les beaux principes sauf quand tu le fais pas
Je preferes.

 
Je connais ça aussi (je me force d'ailleurs souvent à écrire pour ces raisons ; j'avais une collègue, je la forcais parfois à écrire un résumé de nos discussions, pour vérifier - non pas qu'elle était bête mais elle avait des problèmes de concentration assez dingues parfois) .  
Mais bon, globalement, sur la moyenne, sur 10 conversations entre 10 personnes tirées aléatoirement, t'auras un meilleur résultat en physique que par mail/téléphone/mattermost/etc  .

 
Je pense que le contact physique est bien sûr supérieur,  je ne me voile pas la face, mais il pose aussi bcp d'autres problèmes tels que ceux que j'ai exposés. Et puis au fond, un mec enrhumé qui se crève pour aller au bureau, il sera 2 fois moins efficace que s'il reste à la maison, et tes problèmes de communication à côté, c'est pas comparable. les bienfaits du TT surpassent très largement les inconvénients. Dans notre boite c'est flagrant. La boite stagnait avant qu'on passe au TT. Les gens sont deux fois plus heureux de savoir qu'ils peuvent bosser depuis la maison s'ils le veulent et l'immense majorité continue de venir au bureau de leur plein gré.

Pour ceux qui ont déjà installé Sharepoint Server, il lui faut une instance SQL dédiée ? Il est plutôt gourmand côté DB ou pas trop ?

 
PI, dans mon équipe, seul les devs sont "interdits" de TT. Ce qui ne m'empêche pas de le faire parfois parce que ma chef est pas débile...  
Petit inconvénient : mon PC est moins puissant que les fixes des dev qui ne font jamais de TT.  Par ex. je perds plus de temps au build, au boot des webapp en local, au passage des tests avec spring, ...

Gné ??? pourquoi ???

Parce que ce sont des feigniasses
 
Plus sérieusement, peut-être que sa boîte ne sait pas quantifier le travail d'un dév ?

 
si une boîte sait pas quantifier le travail d'un dev, on se demande comme elle fait une marge sur les j/h, tout est au pifomètre ?

 
Toute notre infra a été délocalisée sur AWS. On a plus aucun serveur en interne à part un windows server avec quelques shared drives qui contiennent essentiellement d'ancien fichiers. On utilise pas/très peu java. On a uniquement des XPS récents en machine cliente et des iMac 27 pouces un peu vieux maintenant (3 ans). Mais on ne renouvelle plus les machines Apple, on les remplace par des XPS 15 pouces et des écrans 27 pouces externes qui restent au boulot ainsi que les petits écrans 15" portable en USB-C que les gens peuvent emmener chez eux (ou ailleurs).
Mais comme je l'ai dit, ce n'est pas parce que la cage est ouverte que les oiseaux s'envolent. Quasi tous mes N-1 sont au bureau 5 jours par semaine.

 
C'est extrêmement courant ceci dit les boites qui font payer ce que leurs clients sont prêts à payer sans être capable de quantifier le travail.  

Tout sur AWS, ah wé quand même.

 
Ben c'est pratique et pour le TT c'est parfait

L'élément important, c'est bien de voir le télétravail dans la communication et l'ambiance globale de/des équipes.
Le télétravail seul et sans accompagnement sera "merdique".

Simplement, vous savez tous qu'au boulot, vous avez besoin de :
- phases d'échanges d'information (tant pro que perso)
- phases d'interactions
- phases de calme et de concentration sur vos tâches

Une structure des journées et/ou de la semaine pour organiser ces échanges, ça laisse du temps pour faire le reste.

L'exemple simple que vous connaissez tous :
"le manager/chef qui est toujours en retard aux réunions"

Y avez-vous réfléchi ?
Une structure (équipe, service, BU, ...) a besoin de communication.
Généralement, cette communication passe principalement par un manager qui "organise" cette transmission d'informations, ne serait-ce que par ses échanges et ses réunions.
Et des réunions, on en fait de plus en plus ...

Sauf que ... quand on fait une réunion, on fait un CR et une diffusion.
Or la méthode actuelle des 90+% managers c'est de coller les réunions (9h-10h, 10h-11h, ...).
Donc ... sans arrêts aux stand, sans temps pour faire les CR, sans temps pour compter les déplacements et les débuts de réunion, sans compter les débordements des sujets.
+ les demandes en passant des gars + le blabla au café ...

Bref, techniquement, il ne pourra jamais tout faire et ne pas être en retard.
Et en plus, en open space, un mec tout le temps au téléphone, c'est super pénible.

=> organisation des échanges (et donc certains jours de la semaine pourront être en TT puisqu'un autre jour aura servi à diffuser le niveau d'information à tous)

edit: il nous faudrait un slack ... vous causez trop les gars

Alors qu'il y'en a qui installent des MSSQL
 
XaT

Mais c'est quoi la tendance ? Tout au cloud ?

télétravail ok mais quand tu as un taf purement opérationnel (peu de chose planifiable), c'est compliqué de faire ça plus d'un jour semaine.
 
Après tu as des contraintes, dans mon cas, c'est impossible hors du territoire pour des raisons légales et le problèmes c'est que 80% du staff est frontalier.
 
Au delà de la mentalité, ce n'est pas possible partout ni dans tous les métiers de l'IT.  
 
J'ajoute que SCRUM, c'est pareil, ce n'est pas applicable à tout

 
ça dépend en fait ...
je bosse chez un infogérant mais tout est dans notre cloud privé ou dans un cloud publique (aws, azure majoritairement).
donc plus besoin de se déplacer pour gérer les serveurs physiques.
(et on ne fait pas de téléphone/imprimantes/bobologie IT)
 
Les mecs ont accès aux outils de pupittrage, console d'incident et cmdb, et peuvent s'y connecter de chez eux.
Les contrats ont de toute façon dû être prévus pour autoriser des personnes hors France à se connecter aux serveurs vu qu'on a des agences dans d'autres pays.
 
Donc le TT est possible même pour le helpdesk.
Après la méthodo scrum, c'est très orientée dev/équipe de réalisation d'un projet/produit.
Donc évidemment, ça ne s'applique à pas à tout, loin de là.
 
Le ticket est loin d'être mort

 
Ça dépend ©
 
Il y a eu une « course » au Cloud ces dernières années (surtout aux US), c'est indéniable. Est-ce que ça veut dire que tout le monde passera au 100% cloud : clairement non. Bien entendu, Amazon fait son max pour convaincre, il y a de bons arguments mais aussi parfois des moins bons
 
L'idée reste de dire que ton IT est 100% flexible et payable en récurrent. Forcément, ça fait bander les comptables (on revient au CAPEX vs OPEX).
 
Dans mon cas c'est pas possible par exemple (truc en interne pas critique et mon labo de test) mais ma production ça pourrait oui (c'est pas le cas car j'ai besoin d'utiliser en prod l'outil que je vends qui marche sur XenServer).

Désolé de vous déranger dans votre débat
 
C'est quoi déjà le trick sur W10 qui fait ralentir le réseau quand il DL des MaJ ou autre ?
 
Chez moi ça bloque tout le réseau. (PC unique pas sur WSUS)

C'était aussi ma vision de choses, mais des fois que j'ai de la merde dans les yeux, préfère prendre un peu de recul

 
La course actuelle est au 100% "simplifié" / moins cher.
 
La mode des cloud permet de s'affranchir de toute la partie physique/DC/remplacement de disque/d'alim/de cartes/... et de payer à la consommation, simplement.
Un projet a besoin de +4vcpu, hop c'est fait par la console.
 
En parallèle, la mode du devops. Livraisons et déploiements continus et tout automatisés.
 
Next step pour moi : "infra as a code" & Cloud Foundry/Openshift
 
Et oui, je pense que les orchestrateurs de container vont arriver en force quand les équipes d'exploitation auront enfin réalisé leur force première.
 
Un container est volatile et impose au développeur de prévoir sa disparition/redémarrage/...
De plus, avec les docker registry, on peut versionner facilement les images déployées.
 
Donc la gestion d'incident en est extrêmement facilitée :
* service non rendu = on redémarrage le container (et c'est fait en auto dans les orchestrateurs)
* fail complet = retour à l'image précédente
* sinon vraiment = mise en maintenance et "escalade"
 
=> ça réduit beaucoup les coûts.

Y a un truc dont je me pose la question par rapport à cette "mode" de container.
 
Comment vous gérez la partie "base de données" au niveau licensing par ex et ressources ?
 
Dans notre "prod" actuelle, on a un serveur MSSQL "standalone" et il est mutualisé pour chacune de nos plateformes applicatives.
 
En docker, comment ça se passerait ? On monte le conteneur contenant la plateforme applicative + la BDD ? On peut faire 2 VM séparées ?
 
Dans ma tête, le conteneur doit contenir tout l'environnement de l'application, donc BDD compris (avec plan de maintenance, etc), mais j'ai peut être une mauvaise vision des choses.

Tu passes à des BDD managées:
https://aws.amazon.com/rds/sqlserver/
 
Pareil, t'es facturé à l'utilisation.
 
Les conteneurs c'est fait pour des applications sans état, que tu peux détruire et relancer à la volée, pas pour une BDD.

Salut, je me joint a la discution sur le TT.
 
 
Chez nous (grand groupe de presse papier): pas de TT. Car la direction est contre et le DSI est contre.
Sauf que 2/3 personne à l'informatique en ont car il on negocié (changement de lieu de travail, il a y 15ans).
On est en open space, mais on ne travaille pas ensemble (16 personnes), on est chacun a bosser de notre coté sur nos compétence technique/métier differente.
Aucun insonorisation, bureau des année 80, multitude de personne qui passe voire tous le monde sans réel nécessité, certain mette meme de la musique....
 
 
Bref c'est complètement contre productif et le positionnement de la boite c'est un peu du foutage de geule.
 
2 semaine sur 8 je bosse en support utilisateur avec horaire contraint (début de soirée/nuit). => Donc la je doit etre sur place
 
Le reste du temps, je bosse sur des projet (inffras, scripts, flux, documentation, amoa, etc) sans aucun besoin de contact physique. (mail+tel me suffise)
 
J'habite assez loin du boulot (40min à 1h de voiture, pas de TEC disponible).
depuis 1 ans j'ai des pb de santé qui font que j'ai des pb pour conduire et encore plus quand je prend bcp de medoc (morphine, etc). J'ai une reconnaissance travailleur handicapé depuis décembre dernier. (poste adapté, etc)
 
Début de cette année avec mon N+1 on demande du TT pour que je puisse limiter mes arrêt(souvent je suis en arret car je peu pas conduire, mais je peu bosser...). Le médecin du travail en interne est ok    
 
 
il y a 2 mois, le médecin du travail part à la retraite . Le nouveau considère que le TT n'est pas utile   => retrait de la proposition de TT de la part de ma hiérarchie qui le fesait al a base a contrecoeur.  
 
 
Moralité pour moi: je suis en arrêt en ce moment (encore....), soit je contourne le médecin du travail avec la mdph pour avoir du TT forcé comme moyen de maintient de l'emploi, soit je change de taff...
 
C'est déprimant d'avoir un telle manque d'intelligence des fois de sa hiérarchie qui préfère que je soit en arrêt chez moi, que de faire du TT.
 

Et dans ce scénario là, c'est quoi qui est plutôt préconisé ?
Une grosse instance mutualisée ou plusieurs petites déployables (ça m'a l'air d'être faisable quand je regarde rapidement l'offre AWS) ?

 
ou faire une reduction de masse salariale à moindre de frais

 
 
nous on est certifiés PCIDSS ou encore Santé donc tout balancer chez des prestataires ça va être compliqué.
 
Presque tout est virtualisé, mais chez nous ou dans des filiales du groupe. Le groupe a d'ailleurs plusieurs "cloud" en concurrence, et chacun essaye de tirer la couverture pour lui en captant des gros clients, au détriment des autres filiales    
 
Donc on a encore de l'hébergement. On en a également sur des plate-formes qui supportent mal la virtu et la mutualisation.
 

Je suis aussi dans la santé, et pour l'instant c'est ce qui nous "limite" à ne pas voir le cloud "publique". On passe par un prestataire "de confiance" que l'on peut auditer sur place.

AWS a plein de clients qui sont PCI DSS, je vois pas le problème.
 
Pour la santé même si c'est pas encore le cas en France, ça arrivera probablement un jour comme dans plein d'autres pays où AWS est déjà conforme.

Oui mais comme tout tendance, ça reste une tendance. Je vois bien à chaque déplacement pour les LinuxCon :

* en 2013 c'était OpenStack qui allait tout défoncer (raté )
* en 2014 l'arrivée de Docker, ça va tout défoncer et remplacer toute la virtu du monde entier (raté )
* en 2015 orchestration de containers avec le tooling qui va enfin tout manger du jour au lendemain la virtu (raté )
* en 2016 la blockchain ça va tout changer « dès cette année promis » ( )

Bref, entre les annonces, et la réalité du terrain… C'est normal ! Ça prend du temps et faut aussi attendre la maturité des technos (et que la formation des gens suivent).

Faut pas non plus oublier le marché US est plus prompt à tester de nouvelles technos.

2017, l'année du desktop pour linux !

En effet, en générale le principe c'est plutôt 1 processus par container... donc la BDD n'est pas dans le même container.
Pour l'instant les BDD c'est qqchose qui est plutôt chiant à mettre en container, surtout si tu veux du cluster/etc. Mieux vaut commencer par dockeriser les trucs simples et voir ensuite au fur et à mesure

 
on aura half life 3 avant

Pour l'instant je suis loin d'en être là, je m'instruis

t'instruis pas trop, c'est de la merde

 
C'est déjà le cas chez nous depuis 2012