对话《精益软件度量》作者张松：共享上下文，对目标和方法达成共识

个人简介 张松，ThoughtWorks中国区总经理，《精益软件度量》作者。在此之前，他曾先后作为交付和咨询总监负责中国区项目组合的交付保障，并为多家知名企业的产品研发机构，以及IT组织提供咨询服务。张松拥有华中理工大学计算机工程学士学位和英国Warwick大学MBA学位。

作为InfoQ主办的全球顶级盛会，QCon在伦敦、北京、东京、纽约、圣保罗、 杭州、旧金山举办过多次，这次是首次走进中国首都北京。希望能给当 地的公司、技术社区和技术人员提供一流的学习、交流平台。

   

1. 张松老师您好，感谢您参加我们这次在QCon大会上的采访，也恭喜您《精益软件度量》新书的发布。

张松：也谢谢InfoQ能给我这样的一次机会能够跟大家共享一些我的经验。

   

2. 第一个问题有关量化。您的《精益软件度量》涉及到的问题，量化，是一直以来的一个很大的问题，不管在任何行业都有。量化产生的一个东西，就是企业里头的KPI：虽然您提到说我们的软件开发里头提到度量，不是说打算直接去跟KPI挂钩，但它还是一个不可避免会发生的现象。想问一下，你们这个精益软件度量的体系，它是否也存在类似限制，就是说大家会去搞KPI，而不是搞一个眼前一亮的产品？

张松：就像您说的这个现象，在很多的企业组织当中，我们都观察到了。确实存在着把KPI本身当成目标，当成执行方向的一个现象。我写这本书的一个初衷，就希望能够帮助一些组织，特别是软件开发组织，能够把目标重新关注到这个组织的业务目标上面。根据我们在很多企业服务的经验，我们发现，当一个企业设立KPI的时候，他希望员工能够产生一种ROI，或者说是投入产出比，这个投入的方向，是对企业目标、业务目标的投入。但是由于沟通、执行的问题，导致当目标和KPI自上而下传下来之后，就变成了：在下面这个层面上大家只关注一个具体的KPI，而失去了对于最原始的目标的关注。我们相信，要达成对企业目标的关注，需要通过两个手段：第一个是共享上下文，第二个是对目标和方法达成共识。在这种情况下，我希望通过一套相对更有实效性的度量体系来帮助读者。在这方面产生一些想法，产生一些自己的方案，这是我写本书的初衷。

   

3. 其实目标牵涉到一个企业的透明度问题。你有没有见过有些企业，他可能不太愿意跟所有的人沟通这些事，有点像军事化管理的那种思路？

张松：确实有一些企业有，我们叫命令和控制性的企业组织文化。他们可能对于透明度不是很关注。但是我觉得站在公司领导的角度来讲，他们并不是希望降低企业的透明度，而是希望能够尽可能减少企业内部信息流通的成本来提高企业运行的效率。那么在这种情况下，我们就要去权衡一下，在多大程度上，通过什么样的技术手段，在一方面提高信息的透明度，提高自上而下和自下而上的可视度，同时不会由于实施过多的度量体系——或者说工具，或者说流程——导致降低企业运作的效率。这个是需要去权衡，需要去实施，去思考的。这个绝对不是两者只能取其一的方式，是完全可以——起码在现在的这个水平上——有提升的空间的。

   

4. 看这个实施者自己怎么想的。他如果想要去做，总是有一些办法能够在透明度和运营的效率上有一个双赢的一个局面。像您提到目标，那其实对一个企业来说，不管是大团队也好，小团队也好，他可能有大的目标，还会有些小的目标。我作为一个业务部门的负责人，我只关心我这一块，这个大的目标是跟我没有什么关系。您对这方面的沟通有什么样的建议呢？

张松：这个涉及到我前面提到的，如果你希望大家都被一个目标吸引，能够有所投入的话，那么你需要在两个方面做出努力。第一个方面是上下文的共享。我相信，产生局部优化的一个原因，比如说业务部门，他只关注他的这个业务的领域，研发部门有自己的研发组织的目标，那么当他们各自独自改进的时候，就容易产生局部的优化。如果我们希望能够产生全局的优化，能够为整个公司的目标努力的时候，比较重要的一点就是共享上下文，让大家所具备的信息、所具备的知识能够在同一个情景范围之内。第二个就是达成共识。要达成共识，我们也有一些技术手段。在共享上下文的情况下，通过讨论也好，通过制订一个达成共识和决策的规则也好，我相信总有一些办法能够帮助站在不同利益角度的人坐在一起，能够通过一个大家同意的办法达成一个共识。在实施度量也好，在企业决策也好，可能需要多注意，而不仅仅是大家都是自说自话，站在自己的角度去考虑问题。

   

5. 有没有一个比较好的例子，比如在某一个团队里头，这样的情况有所改善呢？

张松：我可以举一个我们客户的例子。客户的名字我就不提了，是一个很大型的跨国企业。业务部门是他们的销售，是市场营销部门；产品的提供者是他们的研发组织。以往，因为他们甚至都属于不同的法律实体（公司），他们之间的沟通实际上是非常有限的，通常是通过总部的指导，或者是他们内部的合同，来达成这种决策和沟通的目的。我们经过考察之后，发现在这个过程当中出现了非常多的误解，但是我们又不能直接说你们出现了误解——一定是希望他们自己能发现误解，并且在这方面达成共识。我们就组织了一个研讨会，把销售部门的人和研发部门的领导拉到同一间屋子里面。我们找了一个很偏僻的地方，让他们不太容易去收发Email和打电话，大家通过一个都能够认可的过程，然后商量，我们到底希望达成一个什么样的目的；为了要达成这样的目的，我们还欠缺一点什么；为了能够弥补这个欠缺的地方，站在业务部门的角度，站在研发部门的角度，各自应该做什么。那么通过一系列的讨论，他们就会发现，原来你们是这么想的，其实你们也不是不可以商量，有些地方我可以让步，但是我希望你能够给我一些什么样的东西。通过这一系列的沟通，大家最后形成了一个相对来说大家都能够接受的一套行动方案。这样的一个结果，实际上是我们希望看到的结果，大家通过充分的沟通上下文，然后获取自己所需要的，在一起把优先级、把目标能够放在桌面上，能够进行比较充分的讨论。最后，虽然看上去像是对立的两个组织，但是实际上，达成共识的可能性是非常高的。我们的经验当中，几乎没有出现过反例。

   

6. 这样听起来，好像软件里头，两个模块之间需要有一些共同语言？

张松：当大家在一起进行商量的时候，更容易达成一致。这个像敏捷里面所提倡的，大家坐在一起，进行面对面的沟通。这个确实是对消除误会，在目标上、方法上达成共识非常有帮助。

   

7. 所以这个活动，你们扮演一个组织者？

张松：我们其实并不是组织者。我们只是在过程当中充当一个catalyst，辅助整个讨论的过程。因为我们并不是领域的行家，我们的客户才是真正的这个领域的行家。

   

8. 好的。下面的问题跟您个人比较相关：您个人有比较多的背景，一开始做过研发，也做过售前售后，现在又做咨询，包括写作这些，那其实这几项行为是不太一样的，那么又有一些相关性。就您个人的经验来说，您感觉它们之间对您有什么促进的作用吗？

张松：首先，从我的以前的背景来看，我以前做过研发工程师，应用开发工程师，也做过售前售后，销售，也做过咨询师。我觉得：首先，这些职责或者说这些工作，基本上都是在软件相关的领域，它们帮助我了解一个软件开发组织前前后后上上下下不同的领域，能够为我提供更完整的场景和信息。那么现在呢，我可能更多的是一个组织的负责人，那么这些经历就能够帮助我理解不同的人，他在看待一个问题的时候，他所思考的角度，他所发表的言论，他所谈论的这个情景。这个对我来讲是一个很有帮助的职业背景。说到协作，说老实话，我并不是一个擅长写作的人，我的朋友、我的同事看到我写这本书都非常的惊讶，原因是我平时既不写博客，微博上也属于潜水，基本上我们公司的人都知道我除了写邮件和写技术文档以外，基本上不写什么其他的东西。写这本书的动力主要来源于几个方面，第一个是我们公司，有一个重要的责任，或者说一个重要的理念，就是希望能够为这个行业，为这个社区，多做一些正面的影响。写书其实是一个非常重要的方面，能够把自己的积累，把自己的经验以及所学，分享给更多的人。这个跟我们公司追求的目标是比较一致的。第二个，也跟我现在所处的角色有关。我现在负责ThoughtWorks在中国区的业务。ThoughtWorks并不是一家大的公司，他主要是靠优秀的人员所做的事情，达到口口相传的宣传效果。作为这个组织的一个负责人，我们公司的这个模式是叫lead by example，就是你要吸引大家做一件事情，那么你最好带头做一件事情。为了鼓励我们公司的人写书写文章，作为一个负责人，最好的办法是自己先写一个。这是这本书最直接的一个动因，并不是因为我多么有文才，特别想写东西才写的这本书。

   

9. 在您写作的过程，您感觉和其他经历还是很不一样的？

张松：写作过程当中确实是。虽然我意识到它的困难，但是感觉在一开始写的时候，还是低估了。特别是我这种不太常写东西的人，要写这么长的内容，中间确实遇到了很多的挑战。这里面也需要感谢我的同事，我的编辑，他们提供了非常多的、有益的、非常犀利的反馈，经常把我批的劈头盖脸的，这才能够督促我一轮一轮的修改，达到了一个可以出版的质量。那么从这个过程当中，我个人也感觉到非常的受益，以前很多东西都是经验性的，都纯粹是我感觉应该这样做，因为我以前做过类似的事情；在写这个书的过程当中，给我了一个机会进行提炼，把我的一些想法、把我的经验能够体系化。我觉得经过这样的一个过程，使我能够更加容易的去跟不同的人来去沟通这方面的知识，这个是非常大的一个收获。

   

10. 您有没有觉得，写作也是一个沟通的方式。对于研发工程师，他们可能不直接跟客户沟通，他们只需要跟同事沟通，甚至是自己写一个软件。你觉得写作对他们的帮助会在哪里？

张松：我觉得帮助会很大。我可以举个例子，我们公司有一个同事，他就是做研发的，他在我们公司也主要是在公司内部做开发，跟客户接触也比较少。但是他就是非常积极的写博客，最近也写了一本小书，是技术方面的书。我问他，你为什么会这么喜欢写这些内容？你从中感受到了什么？他说，第一，他个人来讲，他非常喜欢分享他的所学所做，这个过程使他梳理思路，进一步提升，进一步发现新的追求、更高的提升目标和途径；第二，通过写这些东西，他能够跟更多的人交流，比如他的博客发表在网络上，就有人来找到他，跟他去交流他们的经验，然后能够提出认可或者是批评。在这个过程当中，一方面是督促他进一步提升自己的能力，同时也交了更多的朋友。他感觉到这样非常有得到认同感的感觉，他觉得这是一件非常愉悦的事情。另外，他在这个网站上发布了这种文章、这种书籍，也使他在业界建立了一定的声誉。说老实话，这种声誉对他未来的发展也能够提供一个帮助。我非常鼓励研发工程师能够把自己所学所做的东西积累下来，积极的跟社区、跟行业进行分享，这个不仅对自己，对社区对行业都是非常有价值的事情。

   

11. 回到度量这个话题。从你们团队的经验来说，你们自己进行度量的过程中，有哪一些经验分享？我理解，它应该不会是一蹴而就的过程，而应该是分不同的阶段？

张松：在我们公司倒还没有很明确的阶段，因为我们公司是一个比较扁平化的组织，也就是说，团队有足够的自主性来去设定自己的达成目标的手段。比如说度量的方式，如果大家读过我这本书，可以看到里面很多方式方法，都是在ThoughtWorks实际的团队运作当中提取出来的，但实际上他们都是来自不同的团队，因为每个团队都是根据自己的需要而设计度量。比如说，有的团队他设计度量的方式，是为了达到提升团队个人能力的需要而做的；有的团队，他面临的更迫切的问题是质量上的问题，他就会设定质量上的目标；另外一些团队，可能他的客户是互联网公司，他对市场的响应速度就有非常高的要求，那么他就会在这个领域设定他的度量手段，加以提升。所以在我们公司，可能情况可能略有不同，因为我们团队有很强的自主性，每个团队服务的客户都不太一样，面临的要求和挑战也不太一样，所以他们在选择和剪裁度量方法的时候，通常会有自己的思考和实施方法。我们更加鼓励团队去创新，去寻找更加适合自己的方式方法。

   

12. 比如说我在一个公司工作，可能我就是一个负责某一个模块开发的团队，我的目标是相对明确的。那我应该从什么途径去找到合适自己的方法？

张松：首先他需要跟他的领导，和他的周边的利益相关者——比如跟他对口的业务部门的相关人员，他周边的团队——比如跟他有依赖关系的团队，第三方的厂商——比如有涉及到跟第三方的集成，进行相互的讨论，知道各个方面对他们团队的期望，根据这种期望，才去设定他自己团队的提升目标和努力的方向。依据这样的目标和方向，才去设定自己的度量手段和方法。这个才是在团队内部实现一个大家都能够认可的度量模型的一个有效手段。如果只是等着领导来说，你该度量这个，你应该度量那个，那么通常就晚了：你要么接受，要么就去扛，这两者都并不是很好的方法。作为团队的领导人，他应该更加积极和主动，去告诉领导，去告诉周边的对他有希望的这些人，说，你希望我做到什么，我能不能够通过一些度量的手段，展现一些数字和信息，看看达没达成你的期望。度量的结果是一个沟通的媒体，而不是追求的一个结果。

   

13. 这对团队领导人来说，也是很大的挑战。您还有什么希望和大家分享的？

张松：我知道很多的程序员、开发人员，都把度量当成一个很“邪恶”的、是领导用来达成自己的“邪恶”目标的一个手段。还是希望大家不要这样想。虽然在执行过程当中，确实很多公司的度量会在落实过程当中出现偏差，但是度量本身并没有罪，如果能够好好利用，能够自己去努力的寻找合适的度量方法，我相信能够为团队，能够为个人达成目标提供有效的帮助。