如何让研发工作的管理更加简单高效？这是多数研发管理工作者的期望，下面的内容来自“畅想网”的一位“风清扬”的研发管理者的困惑，我这里保持原样写到这里，作为与大家共同探讨研发管理思路的一个切入点：
“原来是从事顾问类的工作，对别人工作中存在的问题指指点点（即咨询顾问的工作内容），后来在一次偶然的机会中转行做了研发类工作的管理，刚入此行，困难重重！
首先，对技术人员的管理就是一个非常严峻和现实的问题。由于原来的技术人员中有一位在该环境中工作时间比较长，资历自认为很老。在他的带领和影响下，几个技术人员都采取不合作的态度。虽然经过一段时间的努力与尝试，但还是收效甚微。在这段工作中，为了后期的工作便于开展，仓促间招了一些人，良莠不齐，但有人干活总比没有干活的强。艰难中工作了一段时间，幸好这段时间的工作过程中与老板保持着充份的沟通，使得老板非常理解本人的处境和工作进展。但原来的那帮人一直没有太多的改观，我也无暇估计他们的工作情况和感受，多次努力改善与他们之间的相处之后还是没有得到好的结果，在征得老板的同意后，把他们全部干掉（因为在此过程中，他们也犯了一个不可饶恕的错误，把公司的产品代码转卖给别人）。
这样一来，内部的工作暂时理顺了，但是实际遇到的困难还是存在的，人员的技术素质和对该技术的积累使得对项目的把握能力很差，于是又在寻找更高素质的人加入。就这样不停地循环和反复，到了现在，这个问题得到一定的好转。
目前面临的问题就是如何使这些人能够更高效地工作，其中也找了一家研发咨询公司做了相关的工作，可是还是没有得到很好的效果。所以就陷入了一个新的困惑中：如何让研发工作的管理更简单、更有效，这也将是我下步工作中的主要解决难点，也希望能够得到各位高手的指点。
这位仁兄遇到了遇到的困境也正是大多数研发管理者可能经常会遇到的：
1：研发管理理念与研发管理实施。
研发管理咨询师能够为客户提供管理理念和思想，但是对如何将这些先进的管理理念付诸实施经常显得无能为力。多数情况下告诉你哪些做法不对，哪些做法是对的是比较容易的；但是却很难告诉你具体如何做？就算具体告诉你如何做？你也不知道如何应对实施过程中的困难？或者很多情况下你的团队可能根本不具备实施这些管理理念的条件！目前国内对研发管理的咨询很多基于IPD，CMM的思路，但是这些管理思路多数情况下也就是看起来很美，要真。
2：公司的核心研发机密如何能够被保护。
对大公司来说，核心机密往往存在于人的头脑中，但是由于往往涉及的产品都比较复杂，一两个开发人员的离职并不会导致核心机密的泄漏，但是对中小型公司而言，核心开发人员的离职很可能导致核心机密被竞争对手窃取。因此必要的权限管理还是需要的，对于能够接触到的文档和代码，最好在不影响开发工作的前提下，尽量启用较为严格的权限控制。如果是采用信息化管理系统，最好对系统的权限控制这一块仔细评估一下。时而听到一些小公司的老总开玩笑，研发资料放到到处都是，反而不容易泄密，至少不会被内贼一锅端走，如果整理得很好，反而容易被搞走。
3：如何让研发工作的管理更加简单高效。
让研发管理工作更加简单高效，我想这是所有研发管理者的心声。然而研发工作自身的规律决定了研发管理工作并不简单，即并不存在简单的管理。姑且不说CMM的实施，很多团队在实施SCRUM方面都困难重重。有一位研发主管在听我介绍TOPO研发管理系统后问了一个问题，你怎么能够保证研发人员填写的信息的真实性？他指的是研发人员完成某个任务后，会将该任务的状态更改为完成状态，他的意思是如果研发人员没完成某个工作却直接将任务改成了完成状态怎么办。记得还有一次一位研发主管问了类似问题：你这个系统好是好，要是研发人员不愿意用这个系统咋办？这类问题同样让我想到另外一个同样的问题:中美两国举办一个法律体制方面的研讨会，出席研讨会的中国法官问美国大法官的问题是，你们如何避免一个法官的腐败，如何保证法庭的判决能够得到执行。
对于前3个问题，看得出这位老兄经过一段困难期后总算勉强度过去了，能够挺过去很大程度上是得到了老板的强力支持。对于如何让研发工作的管理更加简单高效的这个问题，个人认为不是方法太少而是方法太多，唯一需要的是需要仔细评估哪些方法适合引入团队，引入的方法如何才能够被长期坚持并得到持续改善。笔者个人看法是中小企业在研发管理方面可以注重下面三个方面：
1：研发文件体系的建立。
这个包括文档管理和代码管理。文档很好理解，但是要注意，这里的文档不仅仅包括诸如用户使用手册，产品白皮书等容易看到的正式文档，也包括所有的过程文档，例如设计文档，技术文档，竞争对手资料，产品测试文档等等。注意这里的文档一定是所有而不是部分，将公司所有文档存放到一个统一的文件体系下永远都是必要的。代码管理其实并不仅仅是指软件人员编写的代码，硬件人员的PCB,原理图，CPLD，测试人员写的测试用例脚本，对外发布的版本等文件都是代码管理的范畴。可以说，无论是何种性质的研发团队，研发文件体系的建立都是必须的，否则隐患太大。
2：过程信息化体系的建立。
过程信息化体系的建立，尽管不是必须但却很有必要。研发工作是包含了各种各样的复杂活动，相对于其它类型而言，研发工作者对信息的依赖更加大些。在授权管理下研发相关的各项信息的最大化共享对促进研发工作高效开展非常重要。借助于信息化系统，通过提供统一的工作入口，完全一致的工作方式，最大化的知识共享与沉淀等来高效的提升研发效率显得尤为必要。如果贵公司正好有研发过程信息化方面的需要，不妨评估一下集成式研发管理协作平台，如TOPO研发管理系统。
3：开发自动化体系的建立。
相对于过程信息化而言，开发自动化体系的建立容易被忽视。其实，随着计算机技术的不断发展，在开发自动化支持方面已经有了不少成熟的解决方案。对软件开发而言，最典型的莫过于自动构建与持续集成，其它还包括代码自动走查，自动测试工具等。对硬件而言，也有不少自动测试手段，研发在生产加工的自动化支持方面同样有不少工作可做。其实，这里之所以提出自动化体系的建立，是指研发团队应该不停审视所有的研发过程，尽量将能够自动化的过程自动化。如果能够通过一个系统或计算机自动完成，就不要用人工的方法来完成这个工作。尽管很多研发过程自动化的建立相对而言比较耗费时间，但是为企业研发团队带来的效率的提升却往往非常明显。当然，自动化体系的建立是一个长期而艰苦的过程，但是真正优秀的公司的研发核心竞争力也往往会体现在这个方面。
对于文档体系和信息化体系的建立，我想不用过多的阐述大家都很容易理解，但是对于“开发自动化体系的建立”的这个概念，或许只是我的一点个人看法，为了便于大家理解，我这里就用一个对电子通讯和仪器仪表等行业研发团队在嵌入式软件开发领域非常适用的具体实例来阐述一下何谓开发自动化思想，如果您负责的团队正好也包含嵌入式软件研发，我想你会更加容易理解下面的内容：
对嵌入式软件来说，堆栈空间有严格的大小限制，而堆栈的使用状况对编程人员来说又不能够直观的被观察，这直接导致在嵌入式软件系统中经常会遇到堆栈溢出问题，一些低水平的开发人员总是容易在这上面犯错。而这种问题一旦被引入到最终的产品中，其隐蔽性强，导致的后果严重，且不易跟踪重现。我们具体来分析一下原因，从事过嵌入式软件开发的人都知道，函数参数和函数内的局部变量以及函数的递归调用层次等在函数运行时都会对堆栈的占用产生影响，而一些编程经验不足的开发人员往往容易在函数实现时在内部定义空间要求过大的局部变量（诸如多维数组)。大多数研发团队的解决思路是：将这个定义成编程规范，或者写成经典案例，或者将这个检查作为代码审查的CheckList的一部分。但是，我要说的是这些方法都不是最优的终极解决方案。这里我推荐我以前负责的研发团队中采用的一种做法给大家参考：函数对堆栈的大小依赖是可以被静态检查的，在函数编译的中间过程文件中，你可以分析一下里面的汇编语言，然后通过正则表达式匹配找出函数实现的地方，并分析出函数对堆栈的使用情况。通过写一小段堆栈使用检测的扫描脚本，在每次软件编译后，自动运行该脚本，然后将扫描的异常结果发给相关人review。这个自动处理的过程在我们的系统中引入后，几乎再也没有出现过堆栈耗尽溢出问题。我总结一下上面的过程：开发人员checkin代码->自动构建脚本运行->构建完成后自动运行代码静态扫描脚本（这里可以是任何静态检查工具，如PCLINT和C++Test以及我上面提到的堆栈检测扫描代码）->自动运行测试脚步（如冒烟测试，Unit测试等）->自动保存build结果供后续人工测试。上面的任何步骤失败都会自动通知相关人。 以上过程说复杂也有些复杂，说简单也简单，毕竟你要做的仅仅是整合各种现成的工具，然后开发一点点自动脚本，但是这条自动生成线一旦建立，却能够切实提升研发效率。
我上面只提到一个软件开发的实例，其实在开发过程中，有很多具体的环节都可以通过一些自动化的手段显著提高研发效率。如何发现哪些研发过程需要或可以自动化呢？这个需要仔细观察团队的实际工作情况，找出开发过程中重复的手工劳动比重大的工作，然后研究一下自动化是否可行，然后实施推广。
上述三个方面的内容谈的都非常笼统，任何一方面的工作展开来探讨都是一大堆内容，希望今后有机会能够与大家共同探讨一下这些方面的工作如何开展。
上一篇：论项目管理中的量化管理
下一篇：通过有效沟通实现管理工作价值最大化 |
service@step365.com
0571-87357690
狗仔卡
发表于 2012-4-18 15:47:31
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡