2016年6月8日

研发规范化的适度性实践(二)

作者 kevinwang

上一篇分享了对于初创型团队在起步阶段奠定研发规范化的思路和方法,这一篇再分享在成型团队中进行研发规范化改进的思路和方法。

一、研发规范化是一把手工程

这几年接触过不少软件企业,已经经历过初期创业的艰难,有的已经上市,有的准备上市,也有行业中的骨干企业。既然已经渡过了生死期,那么肯定是要求发展上台阶,企业也看到了方向,有了战略性思路。

就软件研发而言,生死期是快而狠的战略,拿单挣钱,只要客户能够验收付款,其他并不考虑太多(虽然我并不赞成这样,考虑到企业初创时期的人员能力、资金和项目情况,也是很正常的现象,绝大部分团队在开始时没有人能够在适度范围内控制软件研发,可参考研发规范化的适度实践一)。那么,这样的方式必然会在后面付出代价,俗话说,出来混迟早要还的,也是这么一个道理。

到了还账时间,企业也希望改进和规范,最为关键的是一把手。研发规范化虽然看起来是技术领域,但实实在在是一个一把手工程。对于软件企业,软件研发就是制造企业的生产部门,另外,软件行业是一个知识工作特点非常明显的行业,从业者都是知识工作者,因此,与研发规范相关的工作,必然涉及到公司层面的支持,包括薪酬体系、绩效评价、组织结构、工作流程,相关的业务涉及到市场、销售,研发(包括开发、测试)、服务(包括技术支持、实施维护等)等。

一把手的决心和方式,是研发规范化执行的可行性的基础。换句话说,没有一把手的坚定支持,研发规范化的事情不可能做成,没有一把手得当的方法推动,研发规范化的事情难以见效。

二、主要问题表现

1、签单不少,验收时还有利润,过了一年再算,也没有挣钱甚至赔钱,维护环节花费高;

2、千辛万苦进入一个行业,好不容易研发几个产品,呕心沥血培养几个骨干,却为他人做嫁衣;

3、客户现场发现问题,小问题,改了,升级;又发现问题,小问题,改了升级;。。。。。。小小问题无穷尽也。正常?!

4、上面还算好的,至少发现问题能够解决,更麻烦的来了,出现个棘手问题,甚至偶尔出现一次,正如飞天大侠,惊鸿一现,不留下一点痕迹,想查?那么来客户现场调试吧,你还不一定能够重现问题,更别提找到原因了。

5、绩效考核,绩效考核,考着烤着,就糊了,考核成了公司“主业”。

6、哪个项目大、合同大、奖金高,就干哪个项目。你说内部研发的项目?那个奖金有没有还没谱,还是不干了吧。

7、好了,代码都有了,谁走都不怕?真的不怕?!谁知道代码是不是客户正在运行的系统?!

8、我们过了ISO9000还有CMMI 三级,研发管理没问题,开发完了我们都会写文档,都进行评审。文档是完事后写?!部门经理是评审主角吗?!

三、问题分析

1、研发过程中的工作不明确:对于企业来说,清楚研发过程包括哪些工作很重要,特别是需要清楚这些工作的成果,再深一步,就是如何确保这些成果的质量(此处暂时不考虑时间性的问题),工程师如何才算完成工作,再进一步,这些成果如何管理、如何评价、如何在技术团队中传承等等。总之,这一系列事情的头,也是基础,就是各方面就研发过程中的工作内容达成一致,根据实际情况,在一致性的原则下进行合理的剪裁。

2、没有默认的工作状态:团队要形成默契,必然要有一些规矩,没有规矩不成方圆,这个规矩不是写着纸上或存在电脑里面、挂在墙上的规章制度,而是渗透在日常工作中的一些习惯,其中最为重要的就是默认的工作状态,简单的说,当任务派发下去后,如果没有人吱声,默认所有人能够按照时间保证质量完成,这不仅仅是公司对工程师的要求,更重要的是工程师对自己的要求,这也是知识工作者管理的一个重要方面,即自我管理的体现。其他的默认工作状态还包括会前早到5~10分钟,保持Email在线等等。

3、技术工作的开放性比较弱:技术工作本身是一件单纯的事情,又必须有人参与,就会人在江湖身不由己,这也是知识工作者的特点,个人的思想、性格、情绪甚至品质,会在工作中以不同形态表现出来。既然是团队工作,多人参与,那么必须服从团队的机制。技术团队中最主要的一个机制,就是技术工作的开放性,即技术问题应该尽早展示给相关的人知道,隐藏问题只会给自己和团队造成更大的伤害,当然了,除非不在这个团队中,后患与我无关,另一种情况就是,有了问题也是工作,那就继续做呗(对于这种现象,企业须明白第1条,哪些是正常的工作,哪些是可以容忍的问题,哪些是不能接受,必须改进的方面)。在工作过程中,都会或多或少的存在隐藏工作任务、技术问题的现象,如果是无意,可能是能力经验有待提高,如果是有意隐瞒,恐怕有必要进一步深入分析原因。

4、工作过程过度依赖于人:研发过程中经常存在离开某个人就无法继续,或者需要多次反复交流需求和问题,甚至团队中已经将这种现象当做正常的现象,经常开会、交流、讨论,任何讨论和交流,至少一个人以上,甚至公司主要领导、技术骨干,需要花很多精力在这方面。必要的交流、沟通、会议是必须的,企业需要明确的是,哪些是必须的活动,如何减少现在认为的“必须的”会议,通过建立简单而有效的交流沟通方法(具体操作的行为),既能够减少不必要的占用多人事情的情况,也能够为公司积累有效的技术资产(知识资本的一部分),更有助于在企业内部形成良性的工作习惯。这也是知识工作者管理的特点之一,即自我管理的能力。不少企业存在这样的怪圈,水平越高的人,越来越忙,忙于一些琐碎的事情,新人很难上手,反而很闲,高手忙于处理简单或事务性工作,而新人却难以上手。

四、研发规范化改进的思路

在一把手推动研发规范化改进的前提下,有必要统一相关高管和中层的思想,在尽量减少对于现有业绩工作影响的情况下,达成思想一致性。在实际操作落地时,首先需要达成思想统一,方法就是培训,然后对工作过程进行调整,而不是大幅度的改变,由点及面,逐步覆盖研发过程的主要方面。

研发团队是典型的知识性工作者团队,具备显著的知识工作的特点,因此,所有参与者,均需要具备知识工作者所需要具备的技能、方法和习惯。在现实情况中,恐怕难以理解并落地这样的词语,简单一句话描述,最基本的就是责任、主动的特性。

研发过程管理的重点是面向结果的过程管理,团队成熟度不够的情况下,过程粒度要细且明确,团队成熟度逐步提高过程中(可能个别人或部分组),逐步加粗粒度。在这个过程中,识别团队成员的能力和习惯,识别上限和有待提高的方面,并加强组织过程资产的建立、评审、形成和应用(绝大多数企业做不到应用)。围绕工作各个环节,把控关键里程碑的成果。工作过程中使用符合管理需要的工具。最为重要的一点,研发规范化的过程,是为了提高效率、降低成本,而不是为了输出文档和记录。

在结合研发规范化的落地过程中,企业老板和高管,需要明确什么是正常的工作状态,什么是不正常的,公司允许出现适度有明确客观原因的不正常,而不能容忍不明原因的正常。