背景：

我们公司有一位COO，Yahoo过来的，做产品经理出生。下面有2个SVP，一个技术，一个产品经理。技术的SVP性格比较温和，不强势，最看重的是make things done。产品经理的SVP性格强势，是COO从Yahoo招过来的。

网站的流量也不大，一个站点16台应用服务器就搞定了，不是那种技术要求非常高的公司。

以上的背景就决定了，我们公司文化并不是工程师导向。很多事情，还是PM话语权比较大，公司策略，开发资源调动，主要是由PM来驱动。甚至有时候需要多少开发人员，也是PM那边直接给建议。

　　我们出现过的一些问题：

1. 我们有一个页面，是网站最重要的页面，因为长期在这个页面添加各种功能，这个页面的代码已经非常复杂，每次做一个小改动，开发人员会不经意间弄坏其他功能，而QA测试跟bug修复的时候都要几周。

2. 我们有个功能很独立的组件，作为本地代码放在我们网站应用里面，于是出现了这个组件跟整个网站的代码耦合很深，代码互相牵扯。屡次想花时间把这个组件分离成单独的web service，但是总是因为business需求的紧迫性，这个项目分不到人手。

3. 诸如此类的，以上种种的技术负债，就导致了我们有时候会在正式环境上出现一些很严重的技术问题，或者有一些简单的需求却花费了巨大的开发代价。而最终为这些问题买单的，还是技术部门。

4. 有些PM会给一些所谓的“完成”的需求文档，或者以我们要agile为借口写一些不够详细的文档。在开发过程中，开发人员花了很大的精力来讨论这些需求，导致项目不断拖延，开发人员因为工期拖长，出现人员变更，而新来的开发人员又带来了更多的bug，于是更加拖延了项目，结果就是，项目合作很不愉快。

去年美国那边来了一位技术副总，在Oracle跟Collabnet呆过，我跟他一同负责Platform的开发工作。经过大半年的合作，经常可以在跟他的谈论中，感受到他一些对我们很有用的想法：

　　1. 技术需要marketing

我的部门除了有Platform开发的团队，还有一个团队是负责架构的，跟Platform不一样的是，架构要做的项目都是技术部门自己催生出来的，所以经常PM端，COO都不太了解我们做的项目。不知道为什么做这个项目，有什么好处。我相信在一个工程师驱动的公司，这样的问题并不是大问题。但是问题是我们是业务型公司。

比如我们最近在做的一个组件化的项目。

于是有一回，这个VP在跟我打电话的时候，谈到这个组件化项目，他说，”XXX，你知道，你们现在在做的这个组件化项目，很危险!“

我说，”怎么讲?“

他说，”你觉得XXX(Platform的PM，是个VP)知道你们在做什么吗?“

我说，”他应该知道一些，我有跟他说过。“

他又说，”你觉得XXXX(我们的COO)知道你们在做什么吗?“

我说，”他应该不清楚，这个太技术了。“

他又说，”那你觉得XXXX(PM的SVP)知道你们在做什么吗?“

我说，”他应该也不清楚。“

他说，”那如果你这项目出现一些问题需要帮助的时候，或者说需要resource的时候，你觉得他们会帮助你吗?“

我说，”看来不会。“(我心里想，肯定不会，现在就出现问题了。)

他说，”如果有其他项目需要人，你觉得他们会第一个从你这个项目中抽调人手，还是从其他他们了解的项目抽调人手。如果现在他们发现开发部门的开发资源不足，他们第一个challenge的项目是哪个?“

我沉默。

他又接着说，“我们都是XXXXX(技术的SVP)的人没错，但是说白了还是XXXX(COO)的人，你现在拿COO的人，在做一些他不懂你们在搞什么的事情，你觉得这样是不是很危险?”

我说，“嗯。”

他说，“我可以帮你。首先，你应该以PM能够懂的语言，解释这个项目能给他们带来的好处。你说说，你这个项目可以带来什么好处?”

我俩Balabalabala了一阵子。

(用XXXX代人名太痛苦了，之后我还是直接用职位吧。)

然后他说，“所以你这个项目，Front End的PM VP，Platform的PM VP都可以从中带来这个益处对不对?“

我说，”是的。“

他说，”所以你现在不用他们的人手，却在做对他们有好处的项目，对于这样的好事，他们欢迎还来不及呢，对不对?“

他又说，“如果COO知道了，哇，原来架构组还做一件对公司这么有好处的事情，那很好啊，这个组很棒!”

他继续说，”可是，现在没有一个人知道这件事情，所以，很明显，你们做的marketing不够。“

他说的很对。只要稍微懂技术的人都知道架构的重要性，但是以前我们一直没有固定的人员去做我们架构组自己想改进的东西，直到去年，我才说服我们技术的SVP，腾出固定的人员做架构自己的项目。而如果我们有人能够为我们架构的项目做好marketing的话，我相信业务负责人会主动为我们增加改进架构的resource，支持我们的项目而不是像目前这样睁一只眼闭一只眼的不管不问。而且也不会出现，个别PM以他一知半解的技术知识，把我们网站的架构错误的描述给公司的业务负责人。

　　2. 处理技术负债

我们技术部门跟PM有约定，在制定roadmap的时候，会给出20%的时间解决一些技术负债。但是我们一直没有一个合理的流程来使用这20%。

最近技术部门在想办法促成一件事情，就是从每个产品线的开发部门里面抽出一些比较强的开发人员，组成一个团队，专门用来处理技术负债。这可能是一种变相的使用20%的方法。但是这件事情一直不好推进，因为从业务端来说，这个团队做的事情对他们不透明。

而这位VP的做法是这样子的。把处理技术负债的项目加到PM的roadmap进去。

(我们的Roadmap其实就是每个产品线的年度工作计划，什么时间做什么项目。)

我们以20%的时间，算出每一年用来解决这些技术负债的人周。然后根据这些总人周，列出用这些人周可以完成的项目再制定计划。这其实跟PM要做的项目很类似，从什么时间到什么时间，花多少人，做哪些事。但是我们在提议这些重构项目时，要清清楚楚的以PM能够理解的语言写出我们具体要做什么，这个项目做了有什么好处。

这个方法，跟前者我们提议的方法比起来，从开发管理来看，更透明，也更可控。也更容易让业务端接受。

　　3. 约定大家都接受的规则，然后大家严格按照规则来做事

比如说在项目管理里面，他会先说好，我们用SCRUM的方式来跑，大家同意了。于是就严格的按照SCRUM的方式来跑。当在一些问题上有分歧的时候，就参照SCRUM流程来解决。

我们在准备这个spirit的时候，PM必须要提前准备好足够的backlog给大家看。这样我们就不用再从一个很粗略的很大的PRD去痛苦的找出开发人员要做的需求。

每个backlog都要有acceptance criteria。还要有对应到PRD的地方。这样开发人员就可以直接去了解他要做的任务。

开发人员在把功能交付给QA测试的时候，必须运行QA提供的一些基本测试。这样就防止了开发人员交付没完成的功能。

这样大家都有了清楚的，自己要达到的标准，做得好，做不好，也很清楚。

　　最近他还做了一件让我很赞成的事：

我们很多项目都会有一些所谓的consultor的角色，他们并不做具体的事情，所以很难界定他们做得好不好。但是在说明每个project花费的时间的时候，他们又说有30%之类的时间在这个项目上。我注重实际的产出，所以我不太喜欢这样子光说不做的角色。表面上很忙，但是具体对项目有多少的帮助，又很难说清。

于是我们在谈论某个“consultor”要做什么的时候，他会问清楚，这一位，扮演的是鸡还是猪的角色。(不懂猪或鸡的，请去了解SCRUM流程)如果是猪，那就是具体的开发人员。如果是鸡，却又找不出他是鸡这个角色的理由。于是最终界定，他是猪的角色，也就是要参与具体的开发。我相信，这样就避免了前者我说的那种不喜欢的角色。

我经常在想，他为什么可以把很多事情推动起来，而且让大家都认可，即使他有时候是赞同了一些人，而反对了另一些人，但是所有人还是都对他信服的。

我们再把上面一条一条的回顾。

1. 我们在跟业务沟通的时候，用扩展性，稳定性，易维护性，但是这不是双方都能有个直观印象的语言。做了对公司有什么好处，不做对公司有什么坏处，这才是双方都有直观印象的语言。

2. 如何处理技术负债。成立一个专门的小组去处理负债，这并不是一个双方都能理解的做计划的方式。Roadmap才是双方都有个直观印象并且都认可的做年度计划的方式。

3. 需求清不清楚，这是个很不直观的判断，每个人判别的方式不一样，得出的结论也不一样，但是有没有acceptance criteria就很明了;

开发人员做到什么程度才算完成呢?跑完QA提供的基本测试才算;

SCRUM里面有个Consultor要做什么?人们可以很容易的说，他要帮助什么……，推进什么……解决什么……，可以说出一堆一堆。直接问一下，是鸡?还是猪的角色?非常的清楚明了。

这就是我想说明的这位VP的特质，不管跟什么人沟通，CEO，COO，还是PM，开发人员，他都是以双方可以有直观印象的语言来做沟通，他想知道你的意见的时候，提出的问题，尽可能的，不是给你出主观题，而是选择题。而要达到这个目标，我相信他在问每一个问题，每一次谈话之前，都会先把思路理得井井有条。

VIA:难得简单