杂谈研发管理

深圳汉捷研发管理咨询有限公司 靖爽

我们能有的最美妙的经验是神秘感。是这种原始的激情孕育了真正的艺术和真正的科学。不论是谁，如果没有这激情，如果不再感到好奇和兴奋，那就和死去了一样，他的眼睛即失去了光明。这种神秘感，再渗入些恐惧，就形成了宗教。认识到存在某些我们无法洞察的事物，认识到我们只了解最深的理论和最美丽的结构的皮毛，是这种认识和这种情感构成了真正的宗教信仰；在这个意义上，也只是在这个意义上，我是一个深深投入宗教的人。
——爱因斯坦，《The world as I see it》
点评：伟大的爱因斯坦是我们这个星球上迄今最聪明的大脑，即使这样他还是以严谨的态度承认自己的无知；而今的“职业人士”则勇敢的超越了先人：一个咨询公司的范围跨越了战略、经营运作、营销、研发、财经、资本运作、人力资源、甚至包括“吃喝拉撒”的管理方案；一个讲师的网页中列举的培训课程竟有令人乍舌的几十门，仿佛这位牛人的职业生涯在“留辫子”的时代就开始了；一个初出茅庐的年轻人的求职简历上告诉你他“精通A、精通B、精通C、精通……”，其实连那些技术的名字都叫错了。一个在面试英语中铩羽而归的人喃喃的说自己精通的东西没有被问到，到底精通啥？——“how old are you？”！天哪，即使id Software的创始人John Carmack 的简历上才仅仅说自己的专长是“Exhaust 3-D technology”。我提议国家征收这方面的税，谁说“吹牛不上税”？！ 我们评价彼得•德鲁克是“一个真正具有原创性的思想家”，请别忘了前半句话是“在一个充斥着自大狂和江湖骗子的行业中”。我想企业在用人、选择合作伙伴时真的应该拥有一双慧眼，认真考察对方的业务是否聚焦、是否有实际能力：在企业发展运作中，一个有能力有责任心的人会老实承认即将出现的问题和风险，并告诉你是否有解决办法或者是无药可救；而另一群人或是根本意识不到危机、或是拍着胸脯保证自己拥有灵丹妙药，然后在他们的西洋镜被拆穿之前来个胜利大逃亡，编造一个“成功案例”后接着将“卖拐”进行到底。业务和能力的聚焦可以使一个公司或人将精力集中在特定的领域，这是现代管理发展的要求——对社会的分工越来越细，各个领域的管理差异性之大远远超过了个体能力所及，以研发管理领域为例，先进成熟的解决方案包括研发的投资理念、市场和用户导向、结构化研发流程、跨部门组织运作机制、产品平台和货架技术体系的建立、与之匹配的绩效考核机制等等要素，这些要素在实践运作中需要互相协调才能发挥最佳效能，孤立去看或者照本宣科去执行并无法发挥应有的作用，而各个要素如何根据各个公司研发的实际情况去体现则是更加复杂的难题。所以我有理由推测管理学的其他领域也需要深入的探讨，如果说真有人称得上全能，不幸的是他已经停止了思维：德鲁克刚刚走了。


“我等这个机会等了三年，我不是要证明我比别人了不起，而是要证明我失去的东西我一定要亲手拿回来。”
——周润发，《英雄本色》
点评：如果一个项目计划需要12个月完成，然而实际上用了4个月才完成了预计2个月的任务，你说这个项目到底需要多久才能完成？前提是项目条件不变。不同的项目干系人会有不同的答案：一种就是像我一样悲观，估计得增加一倍的时间才行；一种认为前面遇到了一些小麻烦，后面就会好起来，估计得延期2个月；还有一种人会像小马哥一样自信能够将失去的时间“亲手拿回来”，认为会在预期的时间完成项目；不知道是否还有更加激进的经理？

首先要说明的是项目早期估计有误差是正常的，上图是Barry Boehm在《Cost Models for Future Life Cycle Process：COCOMO II》书中勾勒出的估计误差，在项目先期误差甚至达到4倍，随着项目进展估计的误差才逐步缩小，所以对进度和工作量的估计应该是一个范围，在项目中不断根据实际情况去修订，上面例子中合理的答案应该是项目延期一倍。不过遗憾的是这种几十年前的过时理论常常会被人忽略和遗忘，而去追逐先进而耀眼的灵药。
估计就是估计，决不能被当成严肃的承诺。项目经理的“英雄本色”情结经常会鼓励其寻找“银弹”的冲动：利用现有资源按时完成已经超期的项目，当然有时是有领导和用户的重压。根据项目管理中进度、质量、资源和范围的约束关系，这显然是不可能的任务。如果期望在预计的时间内完成，一般会在需求上下功夫：考虑优先实现那些用户业务所必须的需求，力求削减并非必要的需求，或是在后续版本提供——实践证明通过充分沟通大约可以达到目的。当然调整资源也是一个办法，问题是增加人手的时机，搞不好反而会更加延缓进度——“人月神话”的brooks法则。如果想在“质量”上打主意，我个人认为不是好的选择，原因是软件系统对需求的实现程度是二元的——要么实现，要么没有实现，不存在部分实现的情况，换句话说就是系统的质量和所实现的需求是相关的，质量的降低也就意味着需求没有实现。
上面的解释中存在逻辑上问题：将软件系统开发的理论扩展到了系统产品的研发，不过应该还是有些借鉴价值的。


一个荒秃的山坡。
一具血淋淋的尸体仆倒在地上。
从尸体的伤口上判断头颅是被野兽撕掉并叼走的。
“为什么还不提取DNA样本？” 凯瑟琳问到。
“需要等法医来确认他真的已经死亡。” 格雷森无奈的耸耸肩。
——《CSI: Crime Scene Investigation》
点评：原来号称制度建立完善的美国也会闹出这样的笑话！其实无论多么完美的流程制度都不能确保在任何实际情况下是适用的，如何平衡规范和灵活始终是个难题，其原因是你要解决的是现实问题，而不是在纸面上或在头脑中。如何使流程适应当前项目的特点，确定流程中各项活动的先后顺序、执行的程度、乃至是否需要执行这项活动，关键是流程定义者和执行者对活动及其影响的理解程度。
回顾一下软件项目生命周期模型，包括瀑布（线性）模型、V模型、螺旋模型、增量模型、迭代模型、XP极限编程等等，其实包含的活动多是相似的，不同之处在于项目过程中各个活动的取舍、先后顺序、执行的程度——之所以出现如此多种的模型，关键在于无法用一种模型去适应特性各异的项目。如果说有什么模型可以通用，那就是RUP（Rational Unified Process） ，不过它是一个灵活的软件开发流程平台，换句话说，它即指导你如何去做，同时又没有明确告诉你如何去做——如何运用还得靠使用者的聪明才智。
对于研发项目而言、既然流程的定义和裁剪是无法回避的问题，那么就不要避重就轻的将它放在工作的角落里。一般的解决方法是根据项目特点（例如周期、工作量、投入资源、难易程度等等）将项目分类，并分别制定各类项目的开发流程；或者制定流程裁剪的原则，规定哪些活动可以裁剪、哪些活动可以合并。
另一种方法是针对各项活动，列出可裁剪属性、可选项、裁剪指南，明确实践中对单项活动的执行情况。例如对“确定信息采集的方法”可以进行如下定义：

活动 可裁剪属性 可选项 裁剪指南
确定信息采集的方法 技术 用户评审 对于新需求
观察 对于现有操作的充分理解
使用任何现有的应用 如果应用已经存在，并且至少覆盖用户的一些需求

上面两种方法分别从宏观和微观角度来指导流程的裁剪，都是非常必要的。有的QA、项目经理可能会对其工作量提出疑问，我个人认为这项工作是项目管理的关键之一：一个良好的过程很大程度上决定了项目的成败，在这上面花些精力是必要的。而且这项工作不仅在项目之初，更要在过程中进行，对项目的洞察和理解能力、对项目变化的应对能力是项目经理是否称职的主要标志，这当然依赖于实际经验，“别以为看几本黑手党的书就可以学做老大了” ——实践是检验真理的唯一标准！
我认为研发项目成功要素中“人”始终是第一位的，因为他是项目充满活力、直面风险和挫折的原动力。“人”对制度的遵循是以项目（或者）产品成功为出发点的，而不是其他的什么。下面这一句话引自“肖申克的救赎”，值得深思：
“制度这东西，开始你不喜欢它，排斥它，慢慢的，开始接受它，喜欢它，最后你发现自己离不开它，你本身也变成了制度的一部分”。


“詹姆斯，你总得让我穿点什么吧。”浴室的毛玻璃上映出了一个成熟女人的惹火身材，这时候看客总有一种血脉喷张的冲动——显然她什么都没有穿。
“好吧！”邦德先生悠闲的吐着烟圈，懒洋洋的拿起了一双拖鞋。
——《007系列》
点评：用户对产品的需求可不像邦德欣赏女郎一样简单而直接。如此简陋的包装，即使再有内秀的产品，也很难得到用户的青睐。用户对产品的关注点往往包括价格、功能、质量、易用性、维护成本、品牌、外形等等，而不再仅仅局限在产品的质量上；同时对于不同产品、不同关注点的比重也是不同的，就拿操作系统举例吧：微软的windows系列产品面向的是广大普通的用户，强调功能完善并易于操作，与之相对的是面向专业工程师的UNIX系统，强调系统稳定和高效——现在的UNIX系统虽然也“时髦”的提供了类似于Windows的CDE操作界面，不过这对于真正使用UNIX的人士来讲并不是必要的。同是操作系统，一个就像人们乘坐旅游观光车（被关在笼子里）安全的游览野生动物园；另一个仿佛自己扛着猎枪，享受着在原始森林狩猎的乐趣。
既然我们已经知道用户需求涵盖的范围，那么就去带着这些要点去问问用户到底要什么，我们就按照用户的“旨意”开发吧。遗憾的是准确获取用户需求是一件非常困难的事情：如何确定用户范围、如何将用户需求完整的展现出来、如何预见到用户未来的需求，还有就是用户需求会变化。其实解决的方法并不复杂，难点在于如何利用这些“老掉牙”或是“时尚”的方法获得有价值的东西，我认为关键还是研发团队的心态和业务水平。我们或许可以从下面的例子中得到一些启发：
微软在C++市场上正受到来自Borland公司的威胁，McCarthy 所在的开发小组做了大量市场调查，并成立了几个专门小组收集需求，结果发现程序员在使用C++方面的最大挑战不是掌握C++的高级特性，而是如何入门。于是，微软将Visual C++1.0版的主要开发目标定为让程序员不必经过繁杂的学习就能用C++构建应用程序。与此同时，Borland公司仍继续将目光关注于高级C++程序员，增加应用模板和异常处理功能，以及其他一些C++的核心特性。为实现让C++易于使用的目标，Visual C++小组则致力于构造应用程序向导，该工具能够自动创建C++应用程序外壳。结果Visual C++1.0一经问世便抢占了数十个百分点的市场份额。


谁穷了，谁狗熊！谁富了，谁光荣！
——《金光大道》
点评：公司需要盈利是天经地义的事情，但是并不意味着公司里每一个人做的每一件事都直接盈利，毕竟要有人进行技术预言、战略产品开发等非直接盈利却对公司发展至关重要的工作。大多数公司可能会把最多的资源分配在最赚钱的部门里，但微软公司并不是这样做的：例如负责Office产品研发的部门人数并不很多，相反，服务器和工具部门却拥有最多的技术员工。这主要是因为微软在后台服务领域面临着更加激烈的市场竞争，需要投入更多的资源，以尽快开发出领先于IBM、Sun等竞争对手的重量级产品 。我猜测现在盖茨正在为迎击GOOGLE的强劲挑战而筹措资源呐！
如何在众多需要投资的产品中进行组合，兼顾公司短期和长期发展，达到投资收益最大化呢？简单说就是从市场入手，理解市场并进行市场细分，并对各个细分市场的市场空间、竞争强度、盈利情况等方面进行比较，优选出对公司发展至关重要的细分市场，进而制定针对各个细分市场的产品规划和技术规划，根据公司现有和未来的资源状况，确定产品研发计划和业务计划。只有通过这样一系列手段，才可以有效进行公司资源调配，使公司具有持续发展的动力。
以上我们谈及的是如何进行资源分配，另一点很重要的就是在产品线之间核算和利益分配。如果仅仅以盈利状况为依据，将会出现大量人员不安心于本职工作而期望调到盈利高的产品线的情况，进而严重挫伤工作积极性。像华为公司拥有众多的产品线，考核时坚持“一是考潜力的增长，二是考对公司的贡献”，强调均衡，各条产品线齐头并进，整个公司才会保持了良好的发展态势。


“小鸡长大了，就变成了鹅；鹅长大了，就变成了羊；羊长大了，就变成了牛；等牛长大了，共产主义就到了......”
——《活着》
点评：共产主义不会从天降，就像麻雀不会无缘无故变成凤凰，这需要通过艰苦的蜕变，新产品的开发也存在类似的现象。从微软最新旗舰产品Windows Vista的发布一再跳票、功能不断缩水的现象上看的确如此。
从技术角度来讲，新产品开发的主要风险是对于关键技术的实现和对开发周期、资源的控制。我们可以通过提前建立产品开发平台、积累成熟的货架技术模块，将技术开发和产品开发分离，有效降低上述风险，提高研发项目的可控性。即使是这样，对于复杂系统的开发也仍然会遇到新的技术风险，而且需求变化已经成了家常便饭。如何解决？
下面这两张图分别来自Barry Boehm所倡导的螺旋模型方式，和Tom DeMarco在《 Waltzing With Bears：Managing Risk on Software Projects》中为降低软件开发风险所提出的增量开发模式（又是老调重谈），而流行的极限编程则将迭代开发推向了极致。深入理解他们的理论，会发现这是符合人类的思维习惯的——我们会对一个最初的原型或是版本进行不断修改优化，直到满足要求，而无法通过一次的尝试达到终极目的。从实现需求的角度来讲，就是按照需求的优先级划定不同版本，早期版本常常包括基础的需求、急待解决的技术风险、可扩展的基础架构。如果该版本被发布，开发的风险便降低了一大步，对项目进度、所需资源的估计也更有依据，更关键的是项目团队的信心大大提升了。重复上述的过程（前提是要有计划的重复，也就是应明确每次重复的目的），直到项目风险的“桔子皮”都被展示出来，项目也就完成了。

【 发表评论 0条 】