对话 查看内容

从程序员到管理者——与华为IPD一起成长

2016-8-19 08:37| 发布者: admin| 查看: 1798| 评论: 0|原作者: Ann

摘要: 梅先生1999年进华为,从最开始做程序员,到之后做项目经理、技术预研、市场技术支持再到在营销工程部做战略规划和需求管理,可以说他在华为是伴随着IPD的发展一起成长的。在这段经历中,作为一名华为员工,他对IPD有着怎样的感受?IPD给当时的华为带去了怎样的变化,对普通员工的工作又有怎样的影响呢?
       梅先生1999年进华为,从最开始做程序员,到之后做项目经理、技术预研、市场技术支持再到在营销工程部做战略规划和需求管理,可以说他在华为是伴随着IPD的发展一起成长的。在这段经历中,作为一名华为员工,他对IPD有着怎样的感受?IPD给当时的华为带去了怎样的变化,对普通员工的工作又有怎样的影响呢?一起来看看他的体会。

《创新与研发》:华为在国内率先实行了IPD,并取得了巨大成功。您在华为工作期间,正好处于华为IPD体系变革时期。当时您能感觉实施IPD给工作带来了什么改变吗?能和我们分享一下您当时在华为的切实感受吗?
梅先生:华为1998年开始探索IPD,1999年请了IBM来做IPD咨询。我正好是1999年进华为的,但我真正能够开始感受到变化应该是在2000年。刚进去的时候,我就是普通的技术人员,当时的工作方式是——把一个事情交给你,给你一定的时间,你自己去把它搞定,也不管你怎么搞出来的,反正你做完就行了。不懂你就自己找人去问,处于一种自己摸索的状态,不过华为气氛很好,找人请教也都比较顺畅。那时候是没有太多感受到IPD的氛围,可能刚开始的时候高层也要先琢磨一下,搞清楚IPD到底是什么,研究清楚怎么将IPD和华为的实际情况匹配,应该还属于调研和搭建框架的阶段吧,所以我们刚进去的基层员工是没有多大感觉的。
       到2000年就开始能感觉到IPD带来的变化了。2000年我开始做项目经理,第一个能切实感受到的变化是代码检视。要去检视项目成员们写的代码,这对我们来说其实是一件比较痛苦的事情,因为刚开始不规范,他们写代码都不做注释,而且每个人的代码风格都不一样,看起来非常头痛。这就需要自己去找方法,去发现每个人的代码风格,找出他们容易犯的错误,再交由他们自己去规范。
       第二个变化就是,在引入IPD体系之后,我们项目经理的职责和以前不一样了。以前项目经理也得做实际的工作,可能还要写代码,而且项目经理是主力军,技术水平是比一般项目成员要高的。实施IPD流程之后就不一样了,项目经理不用再过多地去做具体的项目工作,更多的是做管理,是把项目成员用起来,让他们发挥能力,去把项目做好。这时候项目经理会花大量的时间去看成员做的东西,看系统的知识、管理的知识,项目经理的视野会大大地打开,能力也会提升得非常快。从这方面来看IPD的好处也很明显,它把项目经理的职责定义好之后,项目经理只要把项目成员培养好了,让他们按照流程走下去,自己就不用花太多的时间去陷入反复的沟通和处理杂事上,项目经理的空间会更大,会有更多时间提升自己,所以IPD对员工能力的培养方面也是很有好处的。
       第三个变化是设计文档的检视。在引入IPD之前,我们是没有文档的。我刚进公司的时候,没有文档,都是先把项目做了,后面再补文档,因为项目时间很紧。2000年左右,就开始要先写设计文档,然后再开始做项目,是一步步来的。刚开始的时候都不懂,文档是写一份还是写两份都不清楚,后来才明白,设计文档还要分概要设计和详细设计;设计文档写完之后还要做检视、做评审。就是这样在做项目的过程中才逐步接触和熟悉IPD的流程。

《创新与研发》:您提到了这三点都是工作中一些比较基础的、比较明显的改变,那这些由IPD变革带来的变化给当时的华为带来了怎样的影响呢,您觉得从您当时的工作角度,有带来怎样的好处?
梅先生:好处其实是有很多的,从我个人体验上来说,感受比较深的可能就以下几点:
       一是产品的可继承性提高了。推行IPD以前,产品和技术的继承性是非常差的,对人的依赖性很高。要找一个东西,都不知道文档在哪里,一旦当时负责的人走了,下一个人都没办法接手,根本不知道以前的人是怎么做的。IPD推行之后,继承性就好很多,按照流程走,相关的文档、说明、记录等都比较齐全,做到有据可循,对人的依赖性就大大减小了。
       二是沟通方面顺畅了,“扯皮”的事儿少了。尤其是在推行IPD之后,规范了需求管理,大大减少了因为需求问题的争论。在推行IPD之前,市场经常把收集到的所有客户需求全部丢给开发,因为市场不懂技术,也不知道需求的可实现性如何,不知道工作量如何,只要是客户要的,就一股脑扔给开发。市场和开发经常会因为某些需求要不要做而争论不休。还有时候在开发进行到一半时,市场又提出需求的变更,要增加功能或者修改某些功能点,这对开发来说是很“要命”的,通常开发都会很不情愿,由此而产生的争吵也非常多。而在推行IPD之后,有建立专门的需求管理部门和变更管理委员会,产品开发流程也相应变得规范。首先都会要过TR1(产品包需求评审,将从市场部、测试部、用服部等收集到的需求进行筛选和协调),过了TR1之后,才能继续往下进行,这样一开始就防止了需求的“泛滥”。另外需求变更管理委员会有懂技术的成员,对需求实现的难度和工作量能有一定的评估,这样在提出变更需求时,通过变更委员会来进行协调和决策。在这样的决策机制下,关于变更的争论也基本上不会发生了。
       三是从单个项目上、从普通员工的角度来讲,感觉项目周期会被拉长,因为要走流程、要规范化,以前可能几个人凑一块儿就把事情做了,但是走IPD流程后就会要花更多的时间或者更多的人力。但是从整个公司的层面来看,从长久来看,研发的周期和成本变少了。因为形成规范的流程之后,公司知道怎么去合理分配资源和优化资源配置,达到资源利用最大化。规范之后,一方面需求变更方面控制得好了,产品重复修改和返工就变少了,产品质量也得到保证,在后期产品的维护上就大大减少了时间;另一方面,产品的继承性和技术的重用得到了保证。IPD流程中,产品都是按照标准来做的,很多模块可以被共用,就不需要所有的功能和技术全部去新开发,可以直接拿已有的标准模块和标准技术来套用,这样可以形成规模性。这就像是做螺丝钉,你按照模具做出来的螺丝钉是标准的,可以随意用,而不是说别人需要一个螺丝钉,你就去现捶一个,那每个都不一样,每个都不能被共用到别的地方去,就很难形成规模效应。

《创新与研发》:IPD是一个大型的、从公司层面进行的体系改革,那作为一名员工,在IPD推行工作中具体可以做些什么?在IPD知识的学习上,您有哪些经验可以分享?
梅先生:关于IPD,公司有做相应的培训。都是比较切合工作的,不会把所有的框架、理论等一次性的全部灌输到每一个人。个人在工作中,也还是要注重实用性,关于IPD大的方向、框架、理论性的知识,大致知道就可以了,主要还是要学习IPD中涉及到我们实际工作的,学以致用,慢慢地将IPD优秀的做法运用到工作中,然后逐步形成一种规范,一种文化,沉淀下来,再流传下去。
       在这过程中一定要注意的很关键一点是,IPD是一个柔性的框架,它不是死板的,你不能把它看成一个硬邦邦的框架去生搬硬套,要寻找到合适的方式来将其运用到你自己的工作中,合适的才是最好的。

《创新与研发》:在IPD推行过程中有没有什么印象深刻,或者有趣的事情?
梅先生:IPD推行中倒是没有什么特别记忆深刻的事情,但有一次我去印度做项目,我对印度人在工作中的严谨印象深刻。在印度的时候,找了印度人来项目组做项目,学他们的CMM。印度人很死板,对文档要求很严谨,格式要求也很严,文档一旦写错了,就要更新版本,第一遍V1.0,写错了就再出一版V1.1,再错了就再出一版V1.2……有一次我印象很深,我的文档制表日期写错了,评审的时候死活不让我过,让我回去重改,当时项目时间很紧,重改就意味着要重新走流程,再重新评审,会耽误项目进度。我说能不能先通过了,这个日期不会影响其他内容,我之后再改。但就是不行,非要让我再改一版。这件事我印象很深刻,让我明白,再好的流程,如果不能严格执行,都是摆设。

鲜花

握手

雷人

路过

鸡蛋

最新评论

关于我们
深圳中天华夏咨询咨询管理咨询有限公司——聚焦产品创新与研发,致力于为企业及研发从业者提供创新和研发领域的专业文章和资讯
联系我们
电话: 0755-8654 9458
邮箱: contact#ztchina.com.cn(请将#替换成@)
邮编: 518052
地址: 广东省深圳市南山区科苑路15号科兴科学园B3栋802
微信二维码
微信号:innovationview
深圳中天华夏企业管理咨询有限公司 版权所有 (粤ICP备12059297号-6) 产品创新与研发管理领域的专业期刊,聚焦产品创新与研发,致力于为企业及研发从业者提供创新和研发领域的专业文章和资讯
返回顶部