POSS Chap 5 Part 4
Un article de Framalang Wiki.
[modifier] Be Open About Your Motivations / Ne cachez pas vos motivations
Be as open about your organization's goals as you can without compromising business secrets. If you want the project to acquire a certain feature because, say, your customers have been clamoring for it, just say so outright on the mailing lists. If the customers wish to remain anonymous, as is sometimes the case, then at least ask them if they can be used as unnamed examples. The more the public development community knows about why you want what you want, the more comfortable they'll be with whatever you're proposing.
Soyez aussi clair à propos des buts de votre organisation que possible, sans révéler de secrets commerciaux. Si vous voulez que le projet incorpore une certaine fonctionnalité parce que, par exemple, vos clients la réclame à corps et à cris, annoncez le clairement sur les listes de diffusion. Si les clients souhaitent rester anonymes, comme c'est parfois le cas, alors demandez leur au moins s'ils peuvent être cités comme exemples sans les nommer. La communauté de développeurs acceptera d'autant mieux vos propositions qu'ils en connaissent les raisons.
This runs counter to the instinct—so easy to acquire, so hard to shake off—that knowledge is power, and that the more others know about your goals, the more control they have over you. But that instinct would be wrong here. By publicly advocating the feature (or bugfix, or whatever it is), you have already laid your cards on the table. The only question now is whether you will succeed in guiding the community to share your goal. If you merely state that you want it, but can't provide concrete examples of why, your argument is weak, and people will start to suspect a hidden agenda. But if you give just a few real-world scenarios showing why the proposed feature is important, that can have a dramatic effect on the debate.
Cela va à l'encontre de l'idée instinctive, si facile à acquérir, si difficile à chasser, que la connaissance est un pouvoir et que plus vous jouez carte sur table plus les autres ont de contrôle sur vous. Mais cette idée instinctive serait fausse ici. En défendant publiquement les fonctionnalités (ou correctifs de bogues ou quoique ce soit d'autre), vous avez déjà dévoilé votre jeu. La question qui reste en suspend est de savoir si vous arriverez à mener la communauté à partager vos objectifs. Si vous dites simplement ce que vous désirez mais sans fournir d'exemple, votre défense est faible et les gens vont commencer à vous soupçonner d'avoir des buts cachés. Mais donner des exemples concrets montrant pourquoi la fonctionnalité proposée est importante pourra beaucoup peser dans le débat.
To see why this is so, consider the alternative. Too frequently, debates about new features or new directions are long and tiresome. The arguments people advance often reduce to "I personally want X," or the ever-popular "In my years of experience as a software designer, X is extremely important to users / a useless frill that will please no one." Predictably, the absence of real-world usage data neither shortens nor tempers such debates, but instead allows them to drift farther and farther from any mooring in actual user experience. Without some countervailing force, the end result is as likely as not to be determined by whoever was the most articulate, or the most persistent, or the most senior.
Pour comprendre cela, pensez à la situation inverse. Trop souvent, les débats à propos de nouvelles fonctionnalités ou de nouvelles orientations sont longs et fatigants. Les arguments que chacun avance se résument en général à « Moi je veux ceci ou cela » ou encore à cette phrase extrêmement populaire « D'après mes années d'expérience en tant qu'architecte logiciel, ceci ou cela est important pour les utilisateurs / n'est qu'une fonction inutile qui ne plaira à personne. » Comme vous pouvez vous y attendre, l'absence de données concrètes n'aident ni à raccourcir, ni à tempérer de tels débats. Au contraire, cela les pousse à s'éloigner toujours plus du point d'ancrage qui est la satisfaction de l'utilisateur. Sans force pour faire contrepoids il est très probable qu'au final le résultat ne soit pas déterminé par qui aura montré le plus de logique ou qui aura été le plus tenace ou le plus expérimenté.
As an organization with plentiful customer data available, you have the opportunity to provide just such a countervailing force. You can be a conduit for information that might otherwise have no means of reaching the development community. The fact that that information supports your desires is nothing to be embarrassed about. Most developers don't individually have very broad experience with how the software they write is used. Each developer uses the software in her own idiosyncratic way; as far as other usage patterns go, she's relying on intuition and guesswork, and deep down, she knows this. By providing credible data about a significant number of users, you are giving the public development community something akin to oxygen. As long as you present it right, they will welcome it enthusiastically, and it will propel things in the direction you want to go.
En tant qu'organisation possédant un grand nombre de données clients, vous avez la possibilité d'exercer cette force pour faire contrepoids. Vous pouvez être le fil conducteur qui transmettra les informations qui autrement n'auraient pas de moyen d'atteindre la communauté de développeurs. Utiliser ces informations pour appuyer vos souhaits n'est en rien embarrassant. La plupart des développeurs n'ont pas individuellement une grande expérience de l'utilisation qui est faite du logiciel qu'ils écrivent. Chaque développeur utilise le logiciel d'une manière qui lui est propre, vous apportez à la communauté de développement public quelque chose proche d'une bouffée d'oxygène. Tant que vous y mettez les formes ils l'accueilleront avec enthousiasme et cela propulsera les choses dans la direction que vous souhaitez.
The key, of course, is presenting it right. It will never do to insist that simply because you deal with a large number of users, and because they need (or think they need) a given feature, therefore your solution ought to be implemented. Instead, you should focus your initial posts on the problem, rather than on one particular solution. Describe in great detail the experiences your customers are encountering, offer as much analysis as you have available, and as many reasonable solutions as you can think of. When people start speculating about the effectiveness of various solutions, you can continue to draw on your data to support or refute what they say. You may have one particular solution in mind all along, but don't single it out for special consideration at first. This is not deception, it is simply standard "honest broker" behavior. After all, your true goal is to solve the problem; a solution is merely a means to that end. If the solution you prefer really is superior, other developers will recognize that on their own eventually—and then they will get behind it of their own free will, which is much better than you browbeating them into implementing it. (There is also the possibility that they will think of a better solution.)
La clé, bien sûr, est de bien présenter. Il ne sera jamais efficace d'insister uniquement parce que vous avez affaire à un grand nombre d'utilisateurs et que parce qu'ils ont besoin (ou pensent avoir besoin) d'une fonctionnalité en particulier votre solution devrait être ajoutée. Vous devriez de préférence concentrer vos premiers messages sur le problème plutôt que sur une solution particulière. Décrivez avec force de détails les problèmes que rencontrent vos clients, donnez autant d'analyses que vous pouvez et autant de solutions viables que possible. Quand les gens commencent à spéculer sur l'efficacité de plusieurs solutions vous pouvez continuer à dérouler vos données pour appuyer ou réfuter ce qu'ils disent. Vous avez peut-être déjà une solution depuis le début, mais ne la mettez pas au premier plan tout de suite. Ce n'est pas une tromperie, c'est simplement l'attitude standard du « courtier honnête ». Après tout, votre véritable but est de régler le problème, une solution n'est qu'un moyen pour arriver à cette fin. Si la solution que vous privilégiez est effectivement meilleure, d'autres développeurs le remarqueront par eux-même finalement et ils s'y rangeront de leur propre volonté, ce qui vaut bien mieux que de les intimider pour qu'ils l'ajoutent (La probabilité qu'ils proposent une meilleure solution n'est pas nulle non plus).
This is not to say that you can't ever come out in favor of a specific solution. But you must have the patience to see the analysis you've already done internally repeated on the public development lists. Don't post saying "Yes, we've been over all that here, but it doesn't work for reasons A, B, and C. When you get right down to it, the only way to solve this is..." The problem is not so much that it sounds arrogant as that it gives the impression that you have already devoted some unknown (but, people will presume, large) amount of analytical resources to the problem, behind closed doors. It makes it seem as though efforts have been going on, and perhaps decisions made, that the public is not privy to, and that is a recipe for resentment.
Cela ne veut pas dire que vous ne pouvez jamais prendre position pour une solution particulière. Mais vous devez avoir la patience de voir l'analyse que vous avez déjà menée personnellement être répétée sur les listes de développement publiques. Ne répondez pas « Oui, on y a déjà réfléchi, mais ça ne marche pas pour les raisons A, B et C. Si vous y pensez bien, la seule solution pour régler ce problème est... » Ce n'est pas tant parce que ça paraît arrogant, mais cela donne l'impression que vous y avez déjà dévoué une quantité inconnue (mais les gens la présumeront importante) de ressources d'analyse derrière des portes fermées. Les gens auront l'impression que des efforts importants ont déjà été fournis, et peut-être des décisions prises, auxquelles le public n'a pas été mêlé et c'est la meilleure voie vers la rancœur.
Naturally, you know how much effort you've devoted to the problem internally, and that knowledge is, in a way, a disadvantage. It puts your developers in a slightly different mental space than everyone else on the mailing lists, reducing their ability to see things from the point of view of those who haven't yet thought about the problem as much. The earlier you can get everyone else thinking about things in the same terms as you do, the smaller this distancing effect will be. This logic applies not only to individual technical situations, but to the broader mandate of making your goals as clear as you can. The unknown is always more destabilizing than the known. If people understand why you want what you want, they'll feel comfortable talking to you even when they disagree. If they can't figure out what makes you tick, they'll assume the worst, at least some of the time.
Naturellement, vous connaissez la quantité d'efforts dévoués en interne et ce savoir est, d'une certaine manière, un désavantage. Vos développeurs se retrouvent dans un état d'esprit légèrement différent des autres participants de la liste de diffusion et cela réduit leur habilité à appréhender les choses du point de vue de ceux qui n'ont pas encore beaucoup pensé au problème. Vous réduirez ce fossé en réussissant à amener tout le monde à voir les choses comme vous le plus tôt possible. Cette logique s'applique non seulement à des problèmes techniques isolés mais aussi à la tâche plus générale consistant à exposer aussi clairement que possible vos objectifs. L'inconnu fait toujours plus peur que le connu. Si les gens comprennent pourquoi vous voulez ce que vous voulez ils se sentiront plus à l'aise pour vous parler, même si c'est pour exprimer leur désaccord. S'ils ne peuvent pas cerner ce qui vous motive ils s'imagineront le pire, enfin, c'est possible.
You won't be able to publicize everything, of course, and people won't expect you to. All organizations have secrets; perhaps for-profits have more of them, but nonprofits have them too. If you must advocate a certain course, but can't reveal anything about why, then simply offer the best arguments you can under that handicap, and accept the fact that you may not have as much influence as you want in the discussion. This is one of the compromises you make in order to have a development community not on your payroll.
Vous ne serez pas capable de tout rendre public vous-même évidemment et les gens n'attendent pas que vous le fassiez. Toutes les organisations ont leur secrets, peut-être celles à but lucratif en ont plus, mais les organisations à but non-lucratif en ont aussi. Si vous devez défendre une certaine orientation, mais que vous ne pouvez rien dévoiler sur le pourquoi, alors donnez les meilleurs arguments que vous avez malgré ce handicape et acceptez le fait que vous n'aurez peut-être pas autant d'influence que vous le souhaiteriez dans la discussion. C'est l'un des compromis à faire pour avoir une communauté de développement dont vous ne supportez pas la masse salariale.
