Faites utiliser Yammer par votre organisation

Traduction de l'image originale de post du blog de Yammer 

En espérant qu'elle vous aide dans votre démarche d'utilisation de Yammer 

Comme il est dit : un image et quelques phrases peuvent avoir un fort impact

Merci à Virpi Oinonen de Business Illustrator

Licence et utilisation

Téléchargement du PSD editable par PhotoShop (Licence commom creative)

Qu'est que la transparence peut vous apporter ?

Préambule : Ce post est la traduction d’un autre post de Chris DeVore Investisseur dans le Web et la mobilité à Seattle.
Merci à Chris de m'avoir autorisé à traduire et publier cet article

Article original : [What does transparency buy you?]


J'ai eu une intense conversation avec un patron de Startup sur les avantages et les coûts d’une communication régulière et transparente avec ses investisseurs et ses proches conseillers.

Mon point de vue - que j’ai exprimé avec force, à défaut d’être très efficace - était que la transparence dans un cercle limité d'initiés est extrêmement précieuse et créé bien plus d’avantage qu’elle ne coûte en efforts et en temps.

Le point de vue du dirigeant – qu’il a défendu calmement et rationnellement - c'est que son travail consistait à maximiser la valeur de l’entreprise, et que communiquer est très coûteux - et pas seulement en elle-même, mais plus encore dans la gestion des réactions parfois vindicative de investisseurs vis-à-vis de celle-ci.
Après ne pas avoir réussi à bien expliquer mon point de vue, j'ai pensé que pourrait essayer de l'écrire...

Premièrement, la transparence, c’est quoi ? 

Ce n’est peut ne pas être un échantillon très complet, mais aussi parmi nos plus de 30 investisseurs, les entreprises qui ont prisent de la valeur le plus rapidement, et qui ont attirés les meilleurs investisseurs, clients et collaborateurs, sont tous dirigés par des patrons qui ont une certaine façon de faire :

1. Fréquent rapport de situations aux investisseurs (hebdomadaire ou mensuel) 

La plupart des fondateurs utilisent « Thinkfuse »  (un service de communication partagée) pour gérer le reporting investisseur (Quelques-uns sont devenus des évangélistes passionnés par ce produit qu'ils ont propagés dans d’autres portefeuilles de fonds de capital-risque).

Quoi qu’il en soit, le contenu compte plus que l'outil, utiliser le courriel ou un pigeon voyageur si vous cela vous chante.

Certains de ces rapports hebdomadaires sont très bref, certain rivalise avec Moby Dick pour la longueur et l'exhaustivité, mais tous inclus ces éléments:

• Les chiffres : Où en sommes-nous sur les chiffres clefs et sur leurs progressions ?

• Faits : Que s’est-il passé d’important, bon, mauvais ou autre, depuis le dernier rapport ?

• En cours : Quels sont les points importants sur lesquels l’équipe travaille actuellement ?

• Besoin d’aide : Où pourrions-nous utiliser les compétences de nos investisseurs et conseillers (ex Recrutement, levée de fond, développement du business et de l’entreprise, stratégie) ?

En développant cette règle d’un rapport régulier et léger, le dirigeant peut garder informé ses plus importantes partenaires non-salariées sur les besoins et les priorités de l'entreprise.

Non seulement, cela lui permettra de maintenir une attention soutenue au sein d'un groupe important d’influenceur (qui conduit souvent à des contacts fortuits et des connexions pour le business), mais aussi, cela ouvre une voie de communication naturelle pour  des demandes spécifiques, ce qui complètent et soutient les efforts de l'équipe en  interne.

2. Tableaux de bords automatisés et accessibles depuis le web 

Comme notre portefeuille est composée d’entrepreneur très « geek », ils ont tous fait des trucs d’enfer concernant les processus d'affaires les plus importantes.

Grâce à un petit effort supplémentaire, la plupart ont également construit des tableaux de bord privés, mais accessible à distance, qui donnent à des « initiés », d’un coup d'œil, comment la société se comportent au travers de ses indicateurs de performance clés.

Les meilleurs élèves de la classe ont été jusqu'à automatisés  l’envoi d’e-mails quotidiens qui fournissent un instantané des dernières 24 heures sur les éléments-clés financiers et les mesures du client.

Le plus « confortable » pour un PDG est de partager des tableaux de bord internes, plus les employés et les partenaires sont informés sur les éléments clef de l'entreprise et ses tendances, mieux c’est.

Cela peut être difficile quand les choses ne vont pas si bien, mais c'est extrêmement motivant lorsque l'entreprise est en progrès, et (peu importe comment les choses vont) cela sert aussi de rappel quotidien sur l'engagement de la direction dans une  culture de la confiance et la prise de responsabilités.

3. Point régulier en “face-to-face” ou téléphonique avec les “parties prenantes” 

Les e-mails et les tableaux de bord sont très bien, mais rien ne remplace pas les rencontres régulières, en face-à-face, pour maintenir la dynamique émotionnelle et relationnelle complexe qui existent entre les équipes fondatrices, employés, investisseurs et conseillers.

Lorsque vous dirigez une entreprise en pleine croissance avec des ressources limitées, que votre cerveau est en ébullition toute la journée et que vous veillez tard dans la nuit sur des trucs dont vous avez besoin pour faire face maintenant, il peut être difficile de prendre le temps nécessaires pour les conversations imprévues et spontanées avec quelqu'un qui ne fait partie du chemin critique de la journée.

Mais les fondateurs qui prennent le temps d’approfondir ces relations – qui s'efforcent d'atteindre [les personnes] de manière proactifs, même quand ils n'ont pas besoin de rien, qui sont présent à des dîners et des événements, et qui tente de connaître toutes les personnes qui touchent et influencent leur activité humainement - ce sont ceux-là qui ont tendance à tenir la barre dans les moments vraiment difficiles dans leurs affaires (et vies personnelles)  avec le plus de succès.

4. Une promotion active de ce que font les membres clefs de l’équipe

Tous les traits de caractère et les habitudes énumérés ci-dessus sont la mise de table minimum  pour un PDG de startup compétents – si vous ne les avez pas, mon conseil serait de commencer à réfléchir à la manière, et dans quelle mesure, vous voulez les ajouter à votre routine de management.

Mais la plus grande marche à franchir pour le fondateur/PDG - en particulier ceux qui n'ont jamais été dans une position de leader dans le passé - est la transformation pour le devenir.

Une première indication de cette capacité, c'est quand les fondateurs commencent à embaucher des gens qui sont nettement meilleur qu’eux dans un domaine d’importance critique de l'entreprise, en leurs faisant confiance et en leurs donnant une bonne part de responsabilité.

Un signal encore plus fort : c'est quand le fondateur prend soin d'attirer l'attention sur la performance ou les contributions des autres membres de l'équipe dans des zones qu’ils contrôlaient par le passé. C'est une chose d'avoir la confiance nécessaire pour engager meilleur que vous - c'est une autre d’attirer l'attention de vos investisseurs sur ce point, et savoir qu'ils vous apprécient d'autant plus de construire une équipe qui peut mener l'entreprise encore plus loin.

Quel est le coût de la transparence ?

Les startups sont d’avantage conscientes du « coût d'opportunité » que n'importe quel autre type d'organisation - il n'y a jamais assez de temps, d'argent ou de main-d’œuvre pour faire tous ce qui doit être fait, et chaque choix nécessite un compromis douloureux entre les myriades d’autres choses qui reste à faire.

Dans ce contexte d’arbitrage brutal et quotidien, Les activités imprévues, non-structurées - incluant la plupart de ce que j'ai décrit ci-dessus - sont les premiers à disparaitre.

L'argument que j’essaye de faire passer de mes conversations d'aujourd'hui - et je suis maintenant en de me relire et de corriger soir - est que les petits, mais constants investissements en matière de transparence, sur le développement des relations et dans l'équipe de développement sont les fondations de la création de valeurs dans votre organisation.

Rien de tout cela ne semble évident sur le moment, mais au fil du temps, une connaissance approfondie, une meilleure compréhension et une intensité dans les relations que cette transparence, dépassera largement la valeur des chèques que vos investisseurs ont faits pour financer votre entreprise.

Cela ne signifie pas les choses n'iront pas mal - je peux pratiquement garantir qu’elles iront mal - mais lorsque cela arrivera, les fondateurs qui ont fait ces investissements auront une armée qui les épaulera  au lieu de leur mettre le couteau sous la gorge.

Test Manager : Trucs et actuces

Après notre session des TechDays 2012 : MS TechDays 2012 - Mise en place d'une usine logicielle avec TFS et Test Manager 2010, et suite aux questions de fin de séance, nous avons eu l’idée de collecter les différentes « bonnes » pratiques ainsi que les trucs et astuces au sein de notre équipe de test.

Merci à Jean Dieu (QA Manager) et Marc Huhardeaux qui sont les auteurs des conseils ci-dessous

Recommandations générales
Stratégie des tests

Dans le Test Manager, séparez les tests de bases des tests fonctionnels.

Tests de base
Les tests de base regroupent :

• Tous les ‘clics’ possible sur un écran de l’application 
• Chasser toutes les erreurs de type « erreur 404, 403, … »

Ce qui revient à parcourir l’ensemble des écrans de l’application. Ainsi nous sommes sur que l’utilisateur final n’aura pas d’écran non désiré (écran d’erreurs, mauvais écran,…)

Tests fonctionnels
Les tests fonctionnels regroupent

• Tous les points fonctionnels décris par la maitrise d’ouvrage
• Valider le comportement  correct de chaque point

Conclusion
Ce qui revient à valider l’ensemble des comportements et le résultat obtenu.
Cette stratégie possède un avantage certain, les tests de base peuvent être intégrés dans le Build, car nous considérons que l’apparition d’un écran d’erreur ou d’un écran non désiré est inacceptable pour le client/utilisateur final.
Alors il restera ensuite que les tests fonctionnels à passer.

Pratiques 

1. Faire un découpage au maximum des actions. Ainsi les méthodes générées sont réutilisable par la suite.
2. Construire une base de données pour les jeux de test
3. Exiger de la part des développeurs des Identifiant Unique à chaque élément cliquable de l’application
1. Si l’application change de forme -> Pas de codage à refaire
2. On est sûr de tester le bon élément
3. Déclarer comme Bug, tout élément cliquable sans identifiant
4. RIEN NE DOIT LAISSER INDIFFÉRENT ! Une faute d’orthographe, un mauvais alignement ou un comportement erratique…
5. Avant de commencer les phases de tests il est préférable d’installer Visual Studio 2010 feature pack 2, ce qui permettra d’apporter plus d’options pour les phases de test.
1. Ce pack permettra de pouvoir modifier avec facilité les noms des méthodes déjà enregistré.
2. De pouvoir les supprimer
3. De pouvoir déplacer les méthodes vers le fichier Uimap.cs afin de pouvoir coder à l’intérieur de ses méthodes, car dans certains le codage et obligatoire lorsque l’on veut effectuer certains cas de test.

Us et coutumes
Le piège est donc de rester enfermé dans ses habitudes d’internautes et de se contenter du rendu d’un seul navigateur. Avec 2 moniteurs différents il est possible d’ouvrir sur chacun une session avec un navigateur différent, et de tester alternativement sur l’un puis sur l’autre ce qui permet en plus de rester bien mieux conscient de ce que l’on fait

Découverte d’un BUG
Le piège est de ne pas anticiper sur la correction d’un bug même mineur et de ne pas être assez explicite sur ce que j’attendais dans la correction.

Exemple : on repère un indicateur oublié et on le signale. Se contenter de signaler une erreur sans donner une ébauche de solution ou de comportement complet attendu n’est pas suffisant, car la correction du BUG peut très bien (fréquent) ne pas répondre à 100% à ce qu’on désire, ainsi cela induit une perte de temps

Spécifications
Le piège est de traiter à la légère les éventuelles spécifications de développement. S’il est écrit que tel ou tel chose doit être faite, même en dépit du bon sens, il faut s’assurer ensuite que cela a été fait.
Nous ne sommes pas les utilisateurs finaux du produit, et peut-être que cette fonctionnalité inutile pour nous ne l’est pas pour l’utilisateur. Et en cas de doute, il ne faut jamais hésiter à déranger ceux qui ont la réponse : c’est pour eux que l’on travaille.

Tips
Astuce pour le calendrier javascript FullCalendar

Pour automatiser un test sur le calendrier

1. Enregistrer l’ensemble des actions nécessaires sur le JQuery dans une seule capture.
2. Copier cet enregistrement dans le fichier de classe partiel UIMap.cs
3. Modifier la méthode pour qu’elle fasse ce que vous souhaitez.
4. Appeler cette nouvelle méthode pour effectuer les actions.

Gestion des décalages d’une semaine (en positif et négatif).  

1. Mis en arguments de « ma fonction » 
1. un élément date (sous forme de string)
2. un booléen disant si j’effectue un décalage ou un retour en arrière
3. un entier indiquant le nombre de jours (valeur par défaut fixée à 7).
2. Dans les modifications  de la fonction,
1. Vérifier s’il s’agit d’un changement
2. Ensuite Vérifie qu’il n’y a pas eu de changement de mois (Important).
3. De la nouvelle date, on récupère le numéro du jour qui nous servira pour déclencher l’action correspondante.

En affinant la partie gestion de la date, il est possible d’affiner encore plus le changement de date.

Astuce pour les éléments JQuery
L’enregistrement d’actions sur des éléments JQuery peut se faire de deux manières

1. d’un seul tenant
2. action par action indépendante

Préférez la solution 2 car en choisissant d’enregistrer chaque action de manière  indépendante dans un enregistrement voici les avantages :

1. La forte ré-utilisabilité
2. Le déroulement de l’ensemble des actions concernées est plus rapide que pour l’enregistrement d’un seul tenant.

Convention de nommage
Cet aspect représente un point central pour le bon déroulement lors de la phase de création de test. Pensez avant même de commencer à votre convention de nommage, car le découpage va vite générer beaucoup de méthode
Il est préférable d’avoir un nom à rallonge qu’un nom peu explicite, il est plus aisé de comprendre « une phrase ». Car au moment de passer dans le Test Manager, lors de la création du plan, on s’y retrouve facilement.

Exemple : on a 2 pages web : Accueil et Login.

Nous avons codé l’action « transition » entre la page « Accueil » et « Login ». Cette méthode (généré par Visual Studio) est nommée : TransitionPageAccueilVersPageLogin

Nous mettrons cette rubrique Tips à jour régulièrement

« On arrive bientôt ? » ou la maitrise du temps et agilité

Préambule : Ce post est la traduction d’un autre post d'Aaron Bjork Principal PM chez Microsoft.
Merci à Visual Studio Magazine et Aaron de m'avoir autorisé à traduire et publier cet article

Article original : Remaining Work is Key for Agile



Aaron Bjork nous explique pourquoi le travail restant à faire est la mesure la plus importante sur nos projets agiles.

L'été dernier, avec ma famille, sur la route des monts Cascade, dans l'État de Washington, nous avions six heures de route devant nous.
Pour ceux d'entre vous qui ont une famille, vous savez que six heures, c'est long en voiture, notamment avec des enfants âgés de 6, 7 et 9. Nous étions sur la route depuis environ 30 minutes quand ma fille de 6 ans, Lily, me pose la question, que tous les parents ne connaissent que trop bien : « on arrive bientôt ? »

Calmement, Je lui réponds  «Non, nous n’y sommes pas encore », Lily me rétorque  «Combien de temps encore ?"
Cette conversation, je suis sûr que tous les  parents l’ont eu.

Après ce voyage, j'ai réfléchi sur l'interaction avec ma fille et j’ai réalisé qu’il y avait un vrai parallèle avec le suivi des projets logiciels. Ma réponse à Lily était assez simple. Quand elle a demandée combien de route il restait, je lui ai donné ma meilleure estimation de la quantité en temps de route restant : cinq heures.

Sans surprise, elle n'était pas particulièrement heureuses de cette réponse, cinq heures, c’est un temps long quand on a 6 ans.
Dans le même temps, la réponse était satisfaisante car elle définissait correctement ce qui nous attendait. Elle peut ne pas aimer le fait que nous avons encore cinq heures de route, mais au moins elle est informée et peut anticiper le reste de l'après-midi.

A partir de là, notre conversation aurait été complètement différente si j'avais répondu par : «Nous voyageons depuis 30 minutes".

Elle m’aurait probablement regardé  d’un air curieux. Elle n'était pas particulièrement intéressée par la distance parcourue. Cela ne répond pas à sa question. Elle veut juste savoir quand nous arriverons à notre destination. Elle voulait savoir combien de temps encore elle devrait rester dans la voiture.

La réponse « 30 minutes de conduite » est de nature à souligner notre effort, mais ne lui donne aucune réel appréhension de « quand arriverons-nous ? », « en avons-nous encore pour 1 heure ? », « pour 10 heures ? »

Les équipes de développement ont ce genre de conversations lors de la discussion autour des tâches restant à faire et du travail que cela représente.

Je sais que l’estimation des temps fait partie du quotidien de des équipes de développement.

C'est même une partie importante et essentielle du processus.

L'estimation fournit un point de départ qui peut être utilisée pour commencer à avoir des indicateurs de progression. Sans l'estimation, l'équipe avance à l'aveuglette.

Toutefois, Je vois beaucoup d'équipes accorder trop d'importance estimations, tout en oubliant le point le plus important : le travail restant.
La plupart des équipes sont conditionnés à suivre trois indicateurs:

• Les estimations originales
• La somme des travaux réalisés
• La somme des travaux restant

Je crois qu'il y a une place pour chacun de ces trois points dans un projet, mais je dirais qu’un seul compte vraiment : le travail restant.

Pourquoi ? Le travail restant est le seul indicateur qui aide l'équipe à mesurer la distance qui les sépare de la ligne d’arrivée.

Les estimations

Démarrons avec le suivi des estimations. L'argument commun pour le suivi des estimations initiales, c'est qu'il permet à l'équipe au fil du temps à améliorer leur capacité à estimer.

Il est assez commun de vouloir revenir sur l’estimation des tâches et de les comparer avec le temps passé à réaliser ces tâches. Le problème avec cette approche est qu'elle met l'accent sur la précision de l'estimation, au lieu de se concentrer sur l'accomplissement de la tâche.

« Agile » nous dit que les choses vont changer en cours de développement. C'est une partie normale du processus. A cause de cela, les estimations ne devraient pas être parfaites.

Rappelez-vous: l'objectif est de terminer le projet et offrir de la valeur aux clients.

Le but n'est pas de produire des estimations parfaites. 

Je ne prétends pas rejeter les estimations ou de mal faire le travail d’estimation. Je dis plutôt qu'une fois une estimation créée, l'équipe devrait focaliser son attention sur le travail restant. L'estimation est juste le point de départ pour savoir combien de travail il reste.

Travail Terminé

La plupart des équipes réagissent mal la première fois qu'on leur demande de laisser tomber l'indicateur "travail achevé".

Ils l'ont suivi de près pendant des années et sont formatés pour y faire attention. En réalité, suivre le temps de travail terminé n’apporte rien à la réussite du projet. Qu’importe si l’équipe a terminé en 100 heures de travail, sur 150 heures nécessaires au respect de son engagement. Ce qui est important, ce sont les 50 heures restantes.

Se focaliser sur le travail accompli peut conduire à un jeu dangereux, où l'équipe commence à plus se concentrer sur ses efforts, plutôt que sur son résultat.

Encore une fois, je ne dis pas que suivre ce qui se fait n'est pas important. Les équipes doivent absolument suivre ce qu'ils ont fait et se réjouir de l'achèvement de chaque élément du Backlog.

Mais ne laissez pas ce suivi détourner l'équipe de son but.

Revenons à mon voyage en famille l'été dernier.

Finalement, il nous a fallu près de sept heures pour arriver à destination. Et quand nous sommes arrivés, nous étions tous ravis et prêts à profiter de nos vacances.
Personne ne se souciait plus que mon estimation de cinq heures était un peu sous-évaluée. Nous avions décidé, à mi trajet, de nous s'arrêter pour prendre un repas et aussi de voir quelques curiosités le long du chemin.

Après notre départ, Il y a eu des changements, et nous nous sommes adaptés à ces changements.

Nous étions arrivés, voilà ce qui était important.

Motiver des équipes agiles (et les autres...)

Préambule : Ce post est la traduction d’un autre post d'Aaron Bjork Principal PM chez Microsoft.
Merci à Visual Studio Magazine de m'avoir autorisé à traduire cet article

Article original : Motivating an Agile Team


Aaron Bjork nous  parle de la façon de motiver vos équipes agiles sans les entraver.

La première, et probablement la plus importante déclaration dans le Manifeste Agile, parle directement aux équipes de développement: 

Les individus et leurs interactions sont plus important que les processus et les outils.

En résumé, les gens sont plus importants que toute autre chose.

Etrange introduction de la part d'un 'tools guy', puisque je travaille chez Microsoft en tant que Program Manager sur Team Foundation Server et Visual Studio. Il ne fait aucun doute que je veux que les équipes de développement utilisent ces outils que je fabrique.

Toutefois, il serait idiot de suggérer que les équipes vont réussir grâce aux outils à leur disposition.

Comme le Manifeste Agile l’indique clairement, le succès de l'équipe est d'abord assuré par la valorisation des membres de l'équipe et par leurs interactions. Les  outils et processus sont importants, mais ils ne sont pas plus importants que l'équipe elle-même.
 

Cet accent mis sur les gens est une raison majeur pourquoi j'aime la méthode Agile.

Elle nous dit de sortir les outils de nos esprits et de regarder l'équipe qui nous entoure.

Elle nous dit que si nous voulons trouver ce trésor au pied de l’arc en ciel du développement de logiciels, nous devons travailler ensemble et valoriser chacun d’entre nous.

Elle nous dit que le succès dépend de l'équipe.

L'année dernière, j'ai lu un livre écrit par Dan Pink intitulé "Drive: The Surprising Truth About What Motivates Us".

Ce fut une lecture fascinante, un de ces livres que l’on ne peut pas refermer; je le recommande à tous. Je me souviens de nombreuses soirées où je m'arrêtais mi-chapitre pour dire à ma femme: "Ecoute ça", avant de lui lire à haute voix une partie de l'ouvrage. Elle m’a finalement dit qu'elle le lira quand je l’aurai terminé, et m'a donc demandé d'économiser ma salive.

Ce livre m'a captivé, et il m'a ouvert les yeux sur certaines vérités concernant la motivation.

Dans Drive, Pink met en opposition les techniques de motivations traditionnelles (récompenses et punitions), avec trois nouveaux principes essentiels à la motivation dans les industries innovantes : autonomie, maitrise et objectif.

L'idée, c’est que les gens recherchent ces trois caractéristiques dans tout ce qu'ils font, et quand ils les trouvent, des bonnes choses se réalisent.

Dans ce post, je veux expliquer rapidement pourquoi  l'autonomie, la maîtrise et l'objectif sont essentiels à la  constitution d’une équipe agile saine.

Autonomie.

Le premier principe présenté par Pink est l'autonomie: la capacité de chacun à prendre ses propres décisions.

Pour une équipe de développement de logiciels, c’est essentiel.

Une équipe a besoin de se sentir responsable, et une équipe a besoin d'être responsabilisés. Pourquoi? Parce Agile nous enseigne que le changement est inévitable lors du processus de développement logiciel.

Dès le moment où l’équipe a démarré, elle va apprendre sur le produit,  sur l'architecture, et sur les clients. L'équipe doit se sentir habilitée à réagir au changement et à communiquer sur ce qu'elle est en train d’apprendre.

Cela ne signifie pas que l'équipe doit pouvoir faire ce qu'elle veut, mais plutôt, qu’elle a la liberté de faire ce qui est juste.

Une équipe manquant d'autonomie est plus susceptible de suivre aveuglément un plan transmis par le haut, tout en ignorant la réflexion critique.

Maîtrise.

Le concept de maîtrise est assez simple: les gens veulent apprendre à mieux faire ce qu'ils font.

Nous trouvons cela dans tous les domaines de la vie.

Une partie de notre ADN nous donne l’envie de nous améliorer. Les tout-petits travaillent sans relâche pour maîtriser l'art de la marche. Ils n’ont, généralement, besoin que d’un peu d'encouragements. Par nature, ils ont un réel désir de maîtriser la marche, et ils y travaillent jusqu'à ce que ça devienne une seconde nature.

Cela ne change pas en vieillissant. J'aime jouer au golf, et j'aimerais être un meilleur golfeur, année après année. Cette amélioration est une partie de mon amour pour ce jeu. Je ne suis certainement pas un maître (ma carrière sur le PGA Tour ne s’est pas encore concrétisée), mais je continue à m'entrainer pour m’améliorer, trou après trou, tour après tour, et année après année. Le processus et les résultats sont tous deux exaltants.

Les équipes de développement ne sont pas différentes.

Toute équipe dispose d'un goût naturel pour trouver des nouvelles et meilleures façons pour accomplir son objectif.

Les membres de l'équipe aiment écrire des logiciels et ils aiment résoudre des problèmes difficiles. S’ils n’aimaient pas cela, ils ne travailleraient pas dans un secteur difficile.

Ils sont motivés par le défi et l'art de bâtir une solution élégante et fonctionnelle.

Cependant, trop souvent, nous traitons les équipes et leurs membres comme s'ils étaient des pions sur un échiquier qui peuvent être déplacés, décalés et changés sans conséquences. Nous remanions les ressources, nous changeons les objectifs et nous chamboulons leurs priorités. En faisant cela, nous enlevons leur capacité à devenir maîtres. C'est un modèle que je vois répété encore et encore dans notre industrie.

Objectif.

Ce dernier principe énoncé par Pink est l’Objectif.

Les équipes ont un profond désir de comprendre comment leur travail s'inscrit dans une vue d’ensemble. En tant qu'ingénieur, je veux comprendre à quoi le logiciel que je vais construire va servir.

Nous avons besoin d'une raison et d’un objectif.

En tant que leader dans votre organisation, trouver des façons de vous assurer que votre équipe sait que ce qu'elle produit est de contribuer au business.

Communiquer à propos de l'importance des nouvelles fonctionnalités livrées dans le dernier sprint. Montrez-leur les clients ravis utilisant leurs solutions. 

Trop souvent, nous déconnectons  nos équipes de développement du business et des clients.

Nous le faisons parce que nous pensons cela ne les intéresse pas, ou nous ne voulons les distraire avec ça.

Mais, le plus souvent, nous finissons par les aliéner et par détruire leur sens de l’objectif.

Conclusion

A mesure que vos équipes grandissent, mûrissent et s'efforcent d'être plus agile,  travaillez pour créer un environnement « autonomie, maîtrise et objectif ».

Je n'ai aucun doute que vous témoignerez, à mesure que vous avancerez, d’améliorations sur le moral, dans l’innovation et l'efficacité.

Data is like gold

Is your gold safer at home or in a bank?

Logically, your banker is a monetary security specialist and security deposit box or vault should resist intrusion better than a simple home security method.
The defensive measures applied to prevent burglary are much more stringent, more efficient and more consistent than yours. And the more gold a bank secures, the more significant its defensive measures..

Data is like gold. Your data is safer in a professional cloud datacenter than in your server room.
The defense measure implemented by the cloud datacenter professional are tougher, more resilient, and rightly so because it's part of their investment. The monitoring of professional cloud datacenters is constant, 24 hours a day/ seven days a week, and   incident management handled rapidly and often by a more qualified staff.

Entrusting your data (and apps) to a professional cloud operator, is like entrusting your gold to a banker, it’s in good hands. Your data is less likely to be stolen in a cloud datacenter, where it’s their job to care for data, rather than concern yourself with its constant protection.

Les données, c’est comme l’or

L’or que vous possédez est-il plus en sécurité chez vous? Ou dans une banque ?
 

En toute logique, chez votre banquier, il est un spécialiste de la sécurité, et son coffre résistera bien plus longtemps que le vôtre.
 

Les contre-mesures appliquées lors des tentatives de cambriolage sont bien plus nombreuses, plus efficientes et plus constantes que les vôtres.
 

Plus un banquier détient d'or, plus ces mesures de défenses sont importantes.
Il en va des données comme de l’or. Vos données sont bien plus en sécurité dans un datacenter que dans votre salle serveur.
 

Les défenses mises en œuvre par les datacenters sont plus fortes, plus nombreuses, cela fait partie de leurs investissements de bases. Le monitoring des datacenters est contant, 24heures sur 24, 7jours sur7, avec une réactivité bien plus rapide et plus qualifié.
 

Confier ses données (et ces programmes) à un opérateur du cloud , c’est comme confier son or à son banquier, une forme de tranquillité.
 

Vos données ont moins de chance d’être volé chez quelqu’un dont le métier est la garde de ses dites données  que chez vous, de même que votre or a moins de chance d’être volé chez un banquier que chez vous dans votre coffre.