Je discute avec des élèves-ingénieurs et je vois passer de ces commentaires qui me font sourire. Leurs premières réactions à la vie en entreprise... ;-)
« Moi qui croyais qu'une réunion, c'était pour prendre des décisions ! »
Alors je reviens sur ce sujet qui me tient à cœur et qui fonde mon style de management, l'empowerment des collaborateurs.
En France, comme dans la majeure partie du monde latin, notre culture du management est une culture du commandement. On ne cherche pas quelle est la meilleure solution mais qui est le chef pour en décider. Cela a encore été renforcé par la centralisation, l'administration bonapartiste, le jacobinisme, etc. Le chef demande des informations et on les lui apporte, puis donne ses ordres. Point. Les collaborateurs s'exécutent et gare à celui qui remet les ordres en cause !
C'est un modèle largement suboptimal. Le chef n'explique pas les raisons des ordres, coupant ses collaborateurs de leurs capacités d'initiative et d'alignement. L'ordre est sujet à interprétation et l'interprétation la plus simple et la plus évidente est toujours celle choisie car on ne peut contrevenir à un ordre direct ; les collaborateurs sont donc coupés de leur volonté d'initiative. Le tout est égal au minimum des parties.
Un meilleur modèle est le management par la décision. Si l'on ne donne plus des ordres mais des directives, s'il n'y a plus un chef qui décide mais un cheminement connu de l'ensemble des collaborateurs vers une décision, alors on arrive à rentabiliser les capacités des différents acteurs. Et le tout se rapproche de la somme des parties.
Ce n'est pas chose facile, il faut se couper de certaines habitudes de secret (dans l'absolu, une équipe travaille pour son chef, il est donc raisonnable de lui faire confiance sur une grande majorité de sujets). Et il faut beaucoup de cohérence et de probité. Car si l'équipe connaît les raisons d'une décision, elle peut les contester et il faut reconnaître que, certaines fois, elle aura raison de le faire ! Il faut permettre aux collaborateurs de comprendre les objectifs à atteindre et leur montrer en quoi les décisions prises concourent à la satisfaction de ces objectifs. À ce prix seulement, les collaborateurs prendront l'habitude de l'initiative adjuvante et apporteront régulièrement à leurs chefs les rapports de bonnes idées qu'ils ont eues et exploitées.
Revenons aux réunions : « Moi qui croyais qu'une réunion, c'était pour prendre des décisions ! » Une réunion peut très bien être un lieu de prise de décision, à condition que les objectifs et les critères de décision ne soient pas secrets mais partagés. Enlevons les œillères ! Si dans certaines réunions, les chefs ne prennent pas de décisions et les collaborateurs s'abstiennent de contribuer, c'est tout simplement parce que les critères de décision sont l'apanage du chef, qu'ils deviendraient apparents si une décision était prise en direct par celui-ci et que les collaborateurs craignent de trahir le peu qu'ils en savent (et donc de trahir leur chef) en dévoilant leurs idées contribuant aux objectifs. De plus, les collaborateurs craignent souvent de se voir opposer un refus non-justifié, qui les frustre et les convainc un peu plus que, vraiment, ils n'ont pas à participer à la prise de décisions.
Dans une réunion productive, comme j'en ai vu, le chef n'explique pas seulement les objectifs à court-terme avant de recueillir les contributions de ses collaborateurs, il explique ses objectifs à moyen- ou long-terme et listes ses contraintes, avec un ordre de priorité qui permet aux collaborateurs de comprendre les critères de décision finaux et d'adhérer à la décision.
Thursday, April 25, 2013
Friday, April 5, 2013
A Suggestion for MediaWiki
A Suggestion for MediaWiki, useful for multi-language wikis, based on my experience from Wikipedia.
The idea is to add multi-language search (exact) matches on the left panel of pages showing search results. Though this may not be feasible with the current data architecture within MediaWiki, there's no reason why it should be impossible to implement.
That would ease the look for information for people who can speak several languages. That would also stimulate the creation of articles by translation of articles from other languages. As a reminder, a big part of mankind speaks two or more languages, I'd say more than half of it.
Let's see an illustration. Figure 1: what you get when you search for "xades" on the English Wikipedia.
Figure 2: what you get when you search for "xades" on the French Wikipedia, no direct results.
Figure 3: What I suggest adding onto the search page (the French one, in this case).
The idea is to add multi-language search (exact) matches on the left panel of pages showing search results. Though this may not be feasible with the current data architecture within MediaWiki, there's no reason why it should be impossible to implement.
That would ease the look for information for people who can speak several languages. That would also stimulate the creation of articles by translation of articles from other languages. As a reminder, a big part of mankind speaks two or more languages, I'd say more than half of it.
Let's see an illustration. Figure 1: what you get when you search for "xades" on the English Wikipedia.
Figure 2: what you get when you search for "xades" on the French Wikipedia, no direct results.
Figure 3: What I suggest adding onto the search page (the French one, in this case).
Tags:
comments,
mediawiki,
suggestion,
wikipedia
Thursday, April 4, 2013
On Client-Side Model Data Validation
Reversing an online Flash application is sometimes not needed if you can access the data inside the model directly.
When you're developing an online application that's running client-side with data server-side, you're faced with the localization of data. For clarity, let's assume you're developing it in a MVC design pattern. Basically, you'd want to put most of data on the server and only give the client a controller on it. The problem starts when you need high transfer rates and reactivity: you just can't go to the server and back for every tiny piece of data. That's when you need to have the model split between the server and the client. Either split or duplicated.
What I'm going to say may come as an obviousness for people used to security, but it may as well come as a shock for casual application developers: if some part of your data model is located on the client, you need not only do user input validation on the inputs from the controller but also on the inputs from the client-side model.
You can't trust the client's terminal to keep data stored in the model safe. So you need to protect it either through integrity or through server-side re-validation.
I just hacked into putting whatever score I wish for myself onto an online gaming platform, which inspired me to write this article. The same could be applicable for more critical applications.
When you're developing an online application that's running client-side with data server-side, you're faced with the localization of data. For clarity, let's assume you're developing it in a MVC design pattern. Basically, you'd want to put most of data on the server and only give the client a controller on it. The problem starts when you need high transfer rates and reactivity: you just can't go to the server and back for every tiny piece of data. That's when you need to have the model split between the server and the client. Either split or duplicated.
What I'm going to say may come as an obviousness for people used to security, but it may as well come as a shock for casual application developers: if some part of your data model is located on the client, you need not only do user input validation on the inputs from the controller but also on the inputs from the client-side model.
You can't trust the client's terminal to keep data stored in the model safe. So you need to protect it either through integrity or through server-side re-validation.
I just hacked into putting whatever score I wish for myself onto an online gaming platform, which inspired me to write this article. The same could be applicable for more critical applications.
Subscribe to:
Posts (Atom)