透明是件好事。它通常与检视、适应一起被视为敏捷的三大支柱。
但是，如果透明度过度会不会对团队造成伤害呢？
是的，我认为这是有可能的。请让我作出解释。
定量和定性的透明
首先，让我们将“透明”定义为对团队工作情况的可见性。在最简单的层面上，是可以对它们进行度量的，例如:
- 迭代速率
- 工作小时数
- 人均故事点数
- 燃尽图
- 每个迭代缺陷数
- 等等
其中一些数据可能值得跟踪，而另一些则可能不值得跟踪。一个完全透明的团队会让所有这些数据都可见。
但是，透明并不仅限于度量数据，还可以包括团队成员的对话、作出的决策……等等。
由于团队透明中包含这类非数字信息，因此我们可以将透明内容分为定性和定量这两类信息。
在团队内和在团队外的透明
除了透明内容，我们还可以考虑团队信息透明的对象，这也是很有用的。
这个信息要透明给其他团队成员吗？要透明给团队外人员吗?
综合考虑两种维度的透明
我们可以采用这种方式思考透明——“在团队内/在团队外”和“定量信息/定性信息”——让我们创建如下所示的典型2×2矩阵:
于是，问题就变成了：在这些不同的象限中，团队的透明是否存有差异。
定量信息
让我们从“在团队内-定量信息”象限开始，它位于左下角。我认为团队应该完全透明这些信息。因为这是客观存在的数据——通常情况下，就算不分享，其他人也会心知肚明。
移动到右下角，我们继续讨论“定量信息”，这次是“在团队外”分享信息的场景。
但是，我认为可能存在一些团队不想对外透明的信息。通常是因为这些数字可能会被团队外人员（通常是干系人）曲解或误用。
例如，一个团队有理由不对外透明这些领域的情况:
- 如果存在由于开发人员处理极其复杂代码而造成的异常时，不要透明“每个程序员产生了多少缺陷”的数据。
- 不要透明“每个开发人员交付的故事点数”。我一直反对这个度量指标，因为我根本不知道当一个典型的产品待办事项由三到四个人共同完成时，该如何把故事点数分摊到每个开发人员头上。
- 不要透明“每位团队成员承担工作的工时数”。事实上，我收到过一封关于这个指标的电子邮件，这也是我写这篇博文的原因。如果一位团队成员要把时间花在帮助他人成长上，可能就不得不少承担一些迭代任务的工时数。
我不愿意把结论描述为:团队不能把这类数据透明到团队外。但我认同：在正当情况下(或者更准确地说，是“错误语境下”)可以对信息有所保留。如果一个数据被提交给老板或干系人时，他们可能会误判或滥用；这种情况下，最好将数据保留在团队内部。
定性信息
让我们移动到上面这一行，从左上角开始，在“在团队内”共享“定性信息”。虽然我不愿意这么说，但有时候一些定性信息最好还是要保密。
例如，假设团队中最资深的技术人员和Scrum Master就某位团队成员的表现进行了一次对话。他们认为对该团队成员的辅导完全是白费劲，需要向老板建议让其离开项目组，甚至让他走人。
当另一个团队成员问道:“你们两个刚才关着门在谈什么呢?”时，这不是那种值得完全透明的谈话。
团队成员应该对大多数定性信息和观察结果完全透明，但也可能会存在一些罕见但又有足够理由不能完全透明的情况，即使是在团队成员之间也是如此。
在右上方象限，我们“在团队外”共享“定性数据”。既然有些对话或决策不能与团队中的所有人分享，自然就有会更多的对话或决策不应该对团队外人员分享。
我依然认为“不透明”不应该是常态，即使是在右上象限也是如此；但确实有些决策和讨论应该保留在团队内部。与保留定量信息的私密性一样，关键是：谁是干系人，以及信息被误解或误用的可能性有多大。
下面的图表总结了我对团队成员应该如何把握透明的看法。
我不是说要刻意不透明
在您给我发抗议邮件或指出我错了之前，请记住我说的是：在某些情况下，完全的透明是有害而不是有益的。
如果您问自己是否在所有方面都愿意对每个人完全透明，就有助于在此语境中的理解。如果您的老板或团队成员想让您手机上与他们共享您的位置信息，您会愿意吗?
毕竟，在老板晚上想拉您一起放松前，他可能会想要查看您的手机位置信息，以确定您在家。在这种情况下，分享您的位置是很有用的。但对于大多数团队来说，我认为这不是一个适当的透明。(不过，如果所有团队成员都真心同意分享这些信息，我也不会有任何异议。)
因此，我不是说团队要不透明。我只是想说，团队应该尽可能地透明，但不要分享一些可能恶化关系或影响团队成功的事情。
您怎么看？
您怎么看?您总是对队友开诚布公吗?对您的干系人也是如此吗?请在下面的评论中分享您的想法。
作者：Mike Cohn
译者：李洁（Jerry Li）
原始链接：https://www.mountaingoatsoftware.com/blog/can-there-be-too-much-transparency
