技术领导人需要的一些特质(2)

　　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，开发人员，他都是以双方可以有直观印象的语言来做沟通，他想知道你的意见的时候，提出的问题，尽可能的，不是给你出主观题，而是选择题。而要达到这个目标，我相信他在问每一个问题，每一次谈话之前，都会先把思路理得井井有条。

原文转自：http://blogread.cn/it/article/6477?f=wb