如何让研发工作的管理更加简单高效

cloudtopo

如何让研发工作的管理更加简单高效？这是多数研发管理工作者的期望，下面的内容来自“畅想网”的一位“风清扬”的研发管理者的困惑，我这里保持原样写到这里，作为与大家共同探讨研发管理思路的一个切入点：

“原来是从事顾问类的工作，对别人工作中存在的问题指指点点（即咨询顾问的工作内容），后来在一次偶然的机会中转行做了研发类工作的管理，刚入此行，困难重重！
首先，对技术人员的管理就是一个非常严峻和现实的问题。由于原来的技术人员中有一位在该环境中工作时间比较长，资历自认为很老。在他的带领和影响下，几个技术人员都采取不合作的态度。虽然经过一段时间的努力与尝试，但还是收效甚微。在这段工作中，为了后期的工作便于开展，仓促间招了一些人，良莠不齐，但有人干活总比没有干活的强。艰难中工作了一段时间，幸好这段时间的工作过程中与老板保持着充份的沟通，使得老板非常理解本人的处境和工作进展。但原来的那帮人一直没有太多的改观，我也无暇估计他们的工作情况和感受，多次努力改善与他们之间的相处之后还是没有得到好的结果，在征得老板的同意后，把他们全部干掉（因为在此过程中，他们也犯了一个不可饶恕的错误，把公司的产品代码转卖给别人）。

这样一来，内部的工作暂时理顺了，但是实际遇到的困难还是存在的，人员的技术素质和对该技术的积累使得对项目的把握能力很差，于是又在寻找更高素质的人加入。就这样不停地循环和反复，到了现在，这个问题得到一定的好转。

目前面临的问题就是如何使这些人能够更高效地工作，其中也找了一家研发咨询公司做了相关的工作，可是还是没有得到很好的效果。所以就陷入了一个新的困惑中：如何让研发工作的管理更简单、更有效，这也将是我下步工作中的主要解决难点，也希望能够得到各位高手的指点。”


这位仁兄遇到了遇到的困境也正是大多数研发管理者可能经常会遇到的：

1：研发管理理念与研发管理实施。
研发管理咨询师能够为客户提供管理理念和思想，但是对如何将这些先进的管理理念付诸实施经常显得无能为力。多数情况下告诉你哪些做法不对，哪些做法是对的是比较容易的；但是却很难告诉你具体如何做？就算具体告诉你如何做？你也不知道如何应对实施过程中的困难？或者很多情况下你的团队可能根本不具备实施这些管理理念的条件！目前国内对研发管理的咨询很多基于IPD，CMM的思路，但是这些管理思路多数情况下也就是看起来很美，要真正实施起来遇到的困难和能够切实带来的效果很值得让人再三衡量。没有人买鞋时不将鞋穿上脚并走几步试试，但是我见过有些公司采购管理系统后发现根本“穿不上脚”的失败案例，因工作的原因，笔者总是偶尔能耳闻一些公司耗近百万采购“咨询＋IT管理系统”后的悲惨结局，听来让人惋惜。

2：人员流失尤其是资深技术人员的流失对公司的影响。
任何公司的研发人员流失特别是资深技术人员的流失都会或多或少的给公司带来一些影响。对于小公司而言，有时这种人员流失足以让一个公司停摆。但是人员流动又不可避免，因此研发管理者应该对此采取相应的预防措施。必要的文档，关键岗位的备份，资深人才的长期激励等都是方法，但是最怕的就是没有采取任何预防措施。这里说一个真实案例，杭州一家为制袜企业提供织花控制产品的公司，由于公司比较小，只有3个研发人员，1个硬件，1个软件和1个项目经理，结果这个做软件工程师离职后，新来的人员发现这个离职的软件人员连公司产品的软件代码都没留下，只得再从零开发！在CTO俱乐部里，也听闻有个公司的经理被研发人员要挟到连代码都不敢要求提供。看到这些事例真是让人感到惋惜，其实做老板的只需要做一点点工作，就可以避免这种悲剧的发生。对这些小型企业，我只有一个建议：花几千元钱买个台式机做服务器，在该计算机上安装一个代码管理系统（SVN,SourceSafe），安装一个文档管理系统；然后要求公司所有代码和文档，都必须归类存放到该服务器上，当然，出于安全考虑，这个服务器最好将硬盘配置成双备份模式。

cloudtopo

3：公司的核心研发机密如何能够被保护。
对大公司来说，核心机密往往存在于人的头脑中，但是由于往往涉及的产品都比较复杂，一两个开发人员的离职并不会导致核心机密的泄漏，但是对中小型公司而言，核心开发人员的离职很可能导致核心机密被竞争对手窃取。因此必要的权限管理还是需要的，对于能够接触到的文档和代码，最好在不影响开发工作的前提下，尽量启用较为严格的权限控制。如果是采用信息化管理系统，最好对系统的权限控制这一块仔细评估一下。时而听到一些小公司的老总开玩笑，研发资料放到到处都是，反而不容易泄密，至少不会被内贼一锅端走，如果整理得很好，反而容易被搞走。

4：如何让研发工作的管理更加简单高效。
让研发管理工作更加简单高效，我想这是所有研发管理者的心声。然而研发工作自身的规律决定了研发管理工作并不简单，即并不存在简单的管理。姑且不说CMM的实施，很多团队在实施SCRUM方面都困难重重。有一位研发主管在听我介绍TOPO研发管理系统后问了一个问题，你怎么能够保证研发人员填写的信息的真实性？他指的是研发人员完成某个任务后，会将该任务的状态更改为完成状态，他的意思是如果研发人员没完成某个工作却直接将任务改成了完成状态怎么办。记得还有一次一位研发主管问了类似问题：你这个系统好是好，要是研发人员不愿意用这个系统咋办？这类问题同样让我想到另外一个同样的问题:中美两国举办一个法律体制方面的研讨会，出席研讨会的中国法官问美国大法官的问题是，你们如何避免一个法官的腐败，如何保证法庭的判决能够得到执行。

对于前3个问题，看得出这位老兄经过一段困难期后总算勉强度过去了，能够挺过去很大程度上是得到了老板的强力支持。对于如何让研发工作的管理更加简单高效的这个问题，个人认为不是方法太少而是方法太多，唯一需要的是需要仔细评估哪些方法适合引入团队，引入的方法如何才能够被长期坚持并得到持续改善。笔者个人看法是中小企业在研发管理方面可以注重下面三个方面：

1：研发文件体系的建立。
这个包括文档管理和代码管理。文档很好理解，但是要注意，这里的文档不仅仅包括诸如用户使用手册，产品白皮书等容易看到的正式文档，也包括所有的过程文档，例如设计文档，技术文档，竞争对手资料，产品测试文档等等。注意这里的文档一定是所有而不是部分，将公司所有文档存放到一个统一的文件体系下永远都是必要的。代码管理其实并不仅仅是指软件人员编写的代码，硬件人员的PCB,原理图，CPLD，测试人员写的测试用例脚本，对外发布的版本等文件都是代码管理的范畴。可以说，无论是何种性质的研发团队，研发文件体系的建立都是必须的，否则隐患太大。

2：过程信息化体系的建立。
过程信息化体系的建立，尽管不是必须但却很有必要。研发工作是包含了各种各样的复杂活动，相对于其它类型而言，研发工作者对信息的依赖更加大些。在授权管理下研发相关的各项信息的最大化共享对促进研发工作高效开展非常重要。借助于信息化系统，通过提供统一的工作入口，完全一致的工作方式，最大化的知识共享与沉淀等来高效的提升研发效率显得尤为必要。如果贵公司正好有研发过程信息化方面的需要，不妨评估一下集成式研发管理协作平台，如TOPO研发管理系统。

3：开发自动化体系的建立。
相对于过程信息化而言，开发自动化体系的建立容易被忽视。其实，随着计算机技术的不断发展，在开发自动化支持方面已经有了不少成熟的解决方案。对软件开发而言，最典型的莫过于自动构建与持续集成，其它还包括代码自动走查，自动测试工具等。对硬件而言，也有不少自动测试手段，研发在生产加工的自动化支持方面同样有不少工作可做。其实，这里之所以提出自动化体系的建立，是指研发团队应该不停审视所有的研发过程，尽量将能够自动化的过程自动化。如果能够通过一个系统或计算机自动完成，就不要用人工的方法来完成这个工作。尽管很多研发过程自动化的建立相对而言比较耗费时间，但是为企业研发团队带来的效率的提升却往往非常明显。当然，自动化体系的建立是一个长期而艰苦的过程，但是真正优秀的公司的研发核心竞争力也往往会体现在这个方面。

cloudtopo

对于文档体系和信息化体系的建立，我想不用过多的阐述大家都很容易理解，但是对于“开发自动化体系的建立”的这个概念，或许只是我的一点个人看法，为了便于大家理解，我这里就用一个对电子通讯和仪器仪表等行业研发团队在嵌入式软件开发领域非常适用的具体实例来阐述一下何谓开发自动化思想，如果您负责的团队正好也包含嵌入式软件研发，我想你会更加容易理解下面的内容：

对嵌入式软件来说，堆栈空间有严格的大小限制，而堆栈的使用状况对编程人员来说又不能够直观的被观察，这直接导致在嵌入式软件系统中经常会遇到堆栈溢出问题，一些低水平的开发人员总是容易在这上面犯错。而这种问题一旦被引入到最终的产品中，其隐蔽性强，导致的后果严重，且不易跟踪重现。我们具体来分析一下原因，从事过嵌入式软件开发的人都知道，函数参数和函数内的局部变量以及函数的递归调用层次等在函数运行时都会对堆栈的占用产生影响，而一些编程经验不足的开发人员往往容易在函数实现时在内部定义空间要求过大的局部变量（诸如多维数组)。大多数研发团队的解决思路是：将这个定义成编程规范，或者写成经典案例，或者将这个检查作为代码审查的CheckList的一部分。但是，我要说的是这些方法都不是最优的终极解决方案。这里我推荐我以前负责的研发团队中采用的一种做法给大家参考：函数对堆栈的大小依赖是可以被静态检查的，在函数编译的中间过程文件中，你可以分析一下里面的汇编语言，然后通过正则表达式匹配找出函数实现的地方，并分析出函数对堆栈的使用情况。通过写一小段堆栈使用检测的扫描脚本，在每次软件编译后，自动运行该脚本，然后将扫描的异常结果发给相关人review。这个自动处理的过程在我们的系统中引入后，几乎再也没有出现过堆栈耗尽溢出问题。我总结一下上面的过程：开发人员checkin代码->自动构建脚本运行->构建完成后自动运行代码静态扫描脚本（这里可以是任何静态检查工具，如PCLINT和C++Test以及我上面提到的堆栈检测扫描代码）->自动运行测试脚步（如冒烟测试，Unit测试等）->自动保存build结果供后续人工测试。上面的任何步骤失败都会自动通知相关人。 以上过程说复杂也有些复杂，说简单也简单，毕竟你要做的仅仅是整合各种现成的工具，然后开发一点点自动脚本，但是这条自动生成线一旦建立，却能够切实提升研发效率。

我上面只提到一个软件开发的实例，其实在开发过程中，有很多具体的环节都可以通过一些自动化的手段显著提高研发效率。如何发现哪些研发过程需要或可以自动化呢？这个需要仔细观察团队的实际工作情况，找出开发过程中重复的手工劳动比重大的工作，然后研究一下自动化是否可行，然后实施推广。

上述三个方面的内容谈的都非常笼统，任何一方面的工作展开来探讨都是一大堆内容，希望今后有机会能够与大家共同探讨一下这些方面的工作如何开展。

dummies2010

同意楼上的，手机有机密？扯淡！操作系统是机密？扯淡！PS协议STACK是机密？扯淡！

newzyf

my god !这就是所谓的管理！！

好肤浅啊！
怪不得是人都能当管理者。

walkonthesky

确实肤浅

musiccdg

bullshit[em10]

youqing

楼猪很显然的是SVN,SourceSafe公司的托嘛

yulu2007

引用看过的一句话“又想马儿跑 ，又想马儿不吃草”

andy_youjun

谁人没有过往，要身体力行，无论那个方案公司都会存在一些问题，关键是领军人，要指引的好，用人得当，记住：量要大，要用全局观，能听取不同意见，当今的方案公司，利润已经快到头了，要生存一定要用一个质的变化，也可以说是转型，成败在些一举，走好每一步。

blue_2005

看看  有可取的一些方面

反应一些现实状况

superjet

还是有些可取之处的

sling2003

也有可取之处

tangzzbb

一将无能，累死千军！

joelwang

不懂技术，却直接面对和管理一个研发团队，不可能管理好吧。华为和中信如果也以这样的方式去管理研发，外行领导内行，那非倒闭不可。

maicaly

楼上的说得有道理！

popzeus

文章还是有很大的借鉴意义的，但是里面过多的强调了怎么样建立一个体系，一种流程，忽略了怎么去开发个人的主观能动性。

northljw

谢谢，有点价值

lmlnet

看了一半就看不下去了。。

sweetboy_123

楼主的这种经历在很多企业比比出现，说白了就是内耗，新人和旧人的较量，空降和土著的较量，一副人斗人其乐无穷的场面。我想这不是大家愿意看到的局面，但围绕着利益，权利和实现自我价值的核心问题，却又不能避免这样的现象出现。但无论如何，公司股东必将为这场斗争的残局买单，人各有志，能和股东利益占到一起的人我不敢多说，排除那些口是心非者，屈指可数！所以咎由自取，还是股东的眼力问题，识人问题，用人问题！
至于如何对付自己的竞争对手，楼主看似成功者，实际上也是颇有不妥，和老板的多沟通没错，是为了取得信任和进一步的支持；但缺乏和下级的沟通就不对了，下级越是有情绪，越是不服管，说明他们已经把你当做“敌人”看待了，在中国这个情商丰富的国家，得罪一个人是要付出很大代价的，既然他们这样就已表明其心已死，没有必要再进行挽救，但做人的风格还是要体现出来的，换位思考一下，他们最关心什么，我想是N+1赔偿问题，是钱的问题，在不影响原则的前提下，速战速决，给钱走人，他感谢你，你也感谢他，各得其所，心照不宣，何乐而不为！