研发管理_研发管理工具 - CSDN
精华内容
参与话题
  • 研发管理心得整理

    千次阅读 2019-02-20 12:34:36
    研发管理心得整理 在现在的公司工作了快5年了。陪伴着公司从创业初期一直走到现在, 公司业务也从0发展到注册用户5000W+、月流水4000万,年流水5个亿。 研发团队从我一个人的单打独斗扩张到现在几个团队。一路走来...

    https://www.toutiao.com/a6658151816229814791/

     

    2019-02-16 11:37:55

    研发管理心得整理

    在现在的公司工作了快5年了。陪伴着公司从创业初期一直走到现在, 公司业务也从0发展到注册用户5000W+、月流水4000万,年流水5个亿。 研发团队从我一个人的单打独斗扩张到现在几个团队。一路走来,从高级研发到架构师,从架构师到项目总监的转型,临时接手大数据组种种的经历。接下来以个人的经验来总结下技术研发团队的管理心得。

    研发管理心得整理

     

    经历几个阶段:

    第一阶段: 对于我们这样一个创业公司来说,刚开始人不多,而且要求产品赶快上线进行第一轮验证,因此以产品灵活、响应快、研发与产品配合度高的情况就体现出来了。但这种模式是以产品快速响应用户需求为导向,对研发质量的不重视也为后来埋下了巨大的隐患。无论是代码规范性、性能的要求都缺乏足够的重视,导致后来很多代码无人能接手,很多技术瓶颈完全无法解决,最终没办法只能重构。

    第二阶段: 是纯粹的直线职能制的流程化开发模式,按产品出需求、研发实现、测试验收的流程化进行的。这种模式的好处是各司其职,每个部门把自己的事做好就行,而且各部门在质量上都有提高,无论是产品的需求完整度,研发的代码和架构质量以及测试对细节的把控都有很大的提高。但也不是没有问题。这种模式对市场和用户的响应程度上就明显慢很多,而且没有人对整体项目的结果负责,产品也缺乏真正的核心功能和亮点。还有一方面是在团队协作上效率极低,相互推诿,相互攻击,不利于团结的情况时有发生,对公司整体团队氛围也影响很大。

    第三阶段: 项目制度的模式,由产品发起需求,进行需求评审确定功能有价值进行研发,评估研发成本后,从各个部门调配研发、设计和测试人员资源。整个项目成员属于一个团队,每个人对自己负责的工作负责。产品做为对整体项目的结果负责,会把好最后的验收关。团队协作上的效率得到提升,大家目标一致,为了最终的项目交付积极努力工作。

    做为研发管理者的总结了如下几点:

    • 技术架构(技术视野)。技术能力仍然是基础,但是要格局更宽阔、视角更全面,既要能关注到未来的技术发展方向和趋势,也对公司的技术储备和路线心中有数,能够进行技术的落地和创新。公司什么阶段该用什么样的技术,哪些新的技术需要引进来,在不同的阶段,引入什么样的技术力量,这些都是技术管理者的职责。
    • 建立公司主营业务中技术框架和实施模式
    • 建立技术体系标准
    • 流程制度(管理能力)。在技术岗上,你的成功就只是决定于你做得有多好;在管理岗上,你的成功决定于别人做得有多好。成为管理者,一定要有这个思维方式的转变,重点是让团队做好,而不是自己亲自动手。而想让团队具备高战斗力是需要很多「道」与「术」的,比如打造团队文化、团队激励是「道」,沟通技巧、考核方式是「术」,而这些如果不想在实践中通过各种挫折来走弯路,那就一定要多学习和了解一些行业大拿的成功经验。
    • 建立高效率的技术团队
    • 建立健全的项目管理体系
    • 建立员工能力发展体系
    • 知识体系
    • 知识库管理体系,技术培训和分享体系
    • 视野&执行(商业嗅觉)。其实这考验的是对于业务和公司战略的理解程度,作为技术管理者一定要明白,技术最终还是要通过业务来产出价值,想要制定技术战略,首先要了解企业战略,了解行业趋势,了解公司在行业中的位置和地位,然后再去考虑技术团队如何支持和配合公司的战略,在这个过程中,优秀的技术管理者要学会跨界,跳出技术人的思维,从产品、市场甚至CEO的视角去思考问题,从而培养自己的战略思考能力。
    • 具备技术前瞻性、战略落地能力

    题外话:

    当我还是个单纯直男癌程序员的时候,觉得做技术应该是最复杂的,时不时想要搞个客户端技术,网络、SQL、架构设计、Java,操作系统, 什么都要懂;Python,Js, shell要学的东西很多;还不断的有新的东西出来,今天 React Native,kotlin ,明天又大数据,后天人工智能,区块链等等。。学无止境呐。

    在看看那些高管和老板们,不参与具体的版本开发,不需要找bug,天天就是开开会,发发邮件,今天跟测试撕逼,明天和产品讨论版本计划,后天和项目经理讨论人力安排,半年来个总结汇报,多轻松啊。

    只有当我做了leader后,有些事我才真正开始明白

    1. 决策者永远比执行者累,要负的责任和要做的事的大小的影响都是完全不同的概念。
    2. 想要招聘个心仪的下属,不知道要花掉多大的力气还有运气才行。
    3. 管理方法是可以学的,但是责任,担当,格局这些内在是需要修炼的!
    4. 下属能力不够,有leader来带;自己能力不够,自己想办法去弥补。
    5. 公司失败了,永远是老板的责任,老板不会说公司失败了是因为招了一堆垃圾员工,因为招什么人的责任也是老板自己来背。这个原则向下同样适用于任何管理职位。
    6. 从来不会因为某个技术问题发愁,让人累的都是人的问题
    7. 很多时候明明已经对全部人交代了,但很多人还是要单独确认,同样的话总是要翻来覆去的说。推出一个新的流程,自己要先试试,然后写清操作规程,接着是普及和推广。然后运行的时候各种低级错误依旧层出不穷。
    展开全文
  • 研发管理流程(一)

    千次阅读 2019-08-19 15:30:55
    目前的研发管理流程,分为4部分: step1:是否跟进项目 step2:是否参加项目招投标 step3:是否签订合同 step4:确定项目验收及回款 Step1 描述:是否跟进项目,组建项目团队,一般是销售+方案+项目经理。 ...

    公司的一切流程都是为了提升交付质量,提高市场竞争力,形成核心竞争力。

    目前的研发管理流程,分为4部分:

    • step1:是否跟进项目
    • step2:是否参加项目招投标
    • step3:是否签订合同
    • step4:确定项目验收及回款

    Step1

    描述:是否跟进项目,组建项目团队,一般是销售+方案+项目经理。

    思路:判断客户想做这个事情的确定性,评估赢下项目的可能性和所需的预先投入,从而决定是否继续跟进;

    内容:

    1)商机预览

    2)我们为什么要参加?从商务层面和战略层面

    3)我们能否胜任?从解决方案分析、交付能力分析、竞争力分析、风险评估分析、下一步计划安排分析。

    参与决策人员:销售经理、项目部经理等

    对应项目管理知识点:

    • 销售或者需求分析工程师 需要出具商业价值分析PBA、干系人登记册、需求跟踪矩阵
    • 技术负责人需要编写初步的建设方案
    • PM要编写初步的项目预算

    Step2

    描述:是否参加项目招投标.

    思路:判断客户想做这个事情的确定性,评估赢下项目的可能性和所需的预先投入,从而决定是否继续跟进;

    内容:

    1)商机概览;

    2)我们为什么参与:战略层面分析、商务层面分析;

    3)我们能否胜任:从解决方案分析、交付能力分析、竞争力分析、风险评估分析、下一步计划安排分析。

    参与决策人员:销售经理、项目部经理、总经理、产品经理等

    对应项目管理知识点:

    • 需要通过步骤2,参与招投标,需要编写投标方案
    • 更清晰的客户需求列表
    • 更清晰的建设方案

     

     

    展开全文
  • 产品研发管理系统的实施应用.pdf产品研发管理系统的实施应用.pdfv产品研发管理系统的实施应用.pdf产品研发管理系统的实施应用.pdf
  • 20年研发管理经验谈(六)

    千次阅读 2019-06-10 15:12:53
    本文继20年研发管理经验谈(五) 如何进行产品研发业务外包?  进行产品研发业务外包的方式没有绝对的标准。行业分析师指出,理解其中的差异通常与一家公司管理层的成熟度有关,而不是与公司本身规模或者存在的历史...

    本文继 20年研发管理经验谈(五)

    如何进行产品研发业务外包?

      进行产品研发业务外包的方式没有绝对的标准。行业分析师指出,理解其中的差异通常与一家公司管理层的成熟度有关,而不是与公司本身规模或者存在的历史有关。最佳的方式是把产品线和研发分成两类:一类是构成该公司未来竞争力的核心要素,另一类是非核心要素,把非核心的部分外包。

      许多情况下,OEM公司倾向于将自己无力承担的工作外包出去,即使是系统中的关键部分。“许多厂商将软件开发外包给印度和其它地方的软件设计商,这并不是因为它们不是核心业务,而是因为这些厂商不具备这样的开发能力和团队。”市场咨询公司Pittiglio Rabin Todd & McGrath(PRTM)欧洲创新业务主管David Percival表示,“没有足够的人手导致了许多公司将软件开发这种核心的研发业务外包。”

      比较适宜的做法应是充分利用自己的内部资源来定义和制订产品规格,监督第三方合作伙伴开发,然后在内部进行测试和验证。Percival认为,这可能要求OEM厂商的开发队伍重新进行技能训练。

      另一个厂商经常犯的错误是将一些比较先进的开发工作外包。因为他们老产品的技术档案太糟糕和复杂,只有他们自己内部开发人员才能维护这些文档。“结果导致公司宝贵的研发资源和团队被禁锢起来,公司依赖外部伙伴来开发新的和令人激动的产品,而这些产品正是其竞争力的来源。”Percival说。

      比较适宜的做法是多花点时间进行正确地设计、调试和对当前设计建立文档,然后再外包,将内部资源集中用于新产品的研发上。Percival强调说:“在你将产品中独特元素外包的同时,你将利润也外包出去了,最后剩下的只有一个空壳。”

     

    产品开发流程的七要素

      引言:PACE在产品开发过程中的应用和扩展是一种实实在在的挑战,而那些成功运用PACE方法论和工具的企业也必将从这种挑战中得到显著的回报。

      产品开发流程可以分为七个相关要素,每一个要素都有其常见的不足之处。PACE提供了各种方法、技巧和手段,以克服每一个要素的不足之处。下文对这七个相关要素作了介绍,对一些常见的不足之处进行了总结,并针对每一个要素简单介绍了PACE的解决办法。  

      在以后的章节里,将进一步详述PACE的每一个要素。

    决策

      所有的公司都有一个新产品决策流程,尽管他们有可能并没有认识到这是一个有明确定义的流程。在决策流程薄弱的公司,因优柔寡断造成的延误很普遍。例如,如果某个实际流程是顺序性的,要求许多经理一一确认某产品设计概念的优劣,那么,起动就会延误。我们看到,许多良机的错失只是因为产品先驱们不知道如何运用这种不正规的决策流程。

      我们曾经帮助过的一家电脑公司有一个效率低下的决策流程,可以说它是我们所见过的许多流程当中的典型。在这家公司里,项目评审已沦为一系列面向不同听众的冗长的汇报。参加的人很多,提出的问题也很多,但这些汇报会并不是决策会议。评审并没有在开发流程的适当时机进行以促使决策,合适的信息也没有提供出来以推动决策。高层管理人员回避了评审,并且没有其他机制来推动适时决策。

      然而,并非所有明确定义的决策流程都是有效的。有些流程要么设计得很糟糕,要么实施不当。在这些情况下,一个正正规规的流程实际上对产品开发构成了管理障碍。花费大量时间,却收效甚微,这样的决策流程早已不能推进产品开发。

      在产品开发评审中,我们发现因决策流程不当会引发下列问题:

    ·由于高层管理人员不知道应该由谁来作出决策,或者需要什么样的一致意见,所以他无意识的延迟决策或修订决策。
    ·信息不够充分或细节不清楚导致决策质量低劣。
    ·没有及时解答疑问。
    ·未定义决策控制点,以至在适当的重要阶段又出现了评审工作。
    ·需要投入的资源过多,以至无法按期完成任何事情。
    ·授权审批和设定优先顺序的人没有明确批准给予产品开发项目的拨付资金。
    ·决策太迟——经常是在产品已经设计出来之后。
    ·没有用周期指导来证实项目进度。
    ·高层领导没有作出战略决策,却由开发人员在无奈中作出这种决策。

      在PACE流程中,新产品决策是通过阶段评审流程进行的,这种阶段评审需要在开发流程中具体定义的点上作出决策。一个产品开发项目必须在预定时间内达到明确定义的目标,才能获准进入下一阶段。

      产品审批委员会(Product Approval Committee, PAC)是指在一个部门或一个公司内负责主要新产品决策的高层领导小组。PAC有权在开发周期内的具体决策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。PAC负责通过产品开发活动实施公司的战略,因此,他们具有资源分配权,以推进新产品的开发。

      PAC一般通过阶段评审流程来作出决策和进行资源分配。没有这样一个流程,高层领导就难以有效地引导新产品的开发。然而,只有一个评审流程(或类似的一个流程,如把关流程或阶段开发流程)是不够的。定义不清、实施不当或与开发流程中的其他必要要素不协调,都可能使评审流程效率低下。

      阶段评审流程在产品开发中还扮演着另一个重要角色。通过它,PAC可以直接明了地授权项目小组分阶段地开发产品。项目小组为产品制定详细的建议,提交产品开发计划,并申请下一阶段所需的资源。如果PAC批准工作小组的各项建议,它会赋予项目小组以权力、责任以及实施小组计划的下一阶段所需要的资源。

    项目小组构成

      在评审中我们发现,尽管大多数公司有正规的项目小组,但多数并不成功。总的来说,由于这些项目小组的构成、角色和责任没有明确的定义,结果使沟通、协调和决策效率低下、纷繁混乱。

      有这么一家很典型的公司,不计其数的经理们只在他们有空的时候或是有什么特别原因使会议变得最优先的时候,他们才参加产品开发小组的会议。由于这种方法产生的效果差,所以公司曾尝试用不同的方法来改变这种状况。他们建立了专门的项目管理www.hi-blue.com部门,负责监督进度和任务的提交,以明确由谁去做什么以及事情做了没有。后来,每个部门都给每一个主要项目指定了自己部门的项目经理。但这些方法效果并不理想,只是增加了毫无价值的劳动,而这种劳动已经太多了。

      许多公司建立了项目小组的组织形式,但大多数效果不佳。针对这些不成功的案例,我们发现以下典型原因:

    ·如果项目小组和职能部门的责权不明确,将造成困惑。
    ·项目小组没有得到明确授权去实现目标,因而效率低下;在某些情况下,他们只被赋予了责任,却没有相应的权力和资源。
    ·缺乏并行工程,一些职能和技能无法和谐地融入到项目小组中去。
    ·项目领导工作效率低,这源于几个因素:项目领导人没有经验;对项目领导人角色不明确;培训不足;项目领导人更换频繁;或者项目小组的组织有缺陷。
    ·项目小组缺乏项目实施所需的人手和技能,因而无法实现目标;各种资源在项目小组间调来调去,缺乏明确的决定。
    ·由于没有明确定义项目小组和职能部门之间的协作方法,两者之间便有冲突和困扰。
    ·小组成员任务分配造成的困扰使整个小组效率低下:比如说,小组成员把自己看作职能部门的评估者或记录者,而非真正地帮助进行实时决策。

      项目小组构成是产品开发流程的一个关键要素。一个高效的项目小组能极大地增进沟通、协作和决策。在评审初期,我们就发现许多广为接受的项目小组模式效率低下,而低下的原因与上文所述颇为相似。我们开发了一个新的模式。这个模式既能发挥项目小组这种组织形式的最佳方面,又能克服上述缺陷。我们把它称之为项目小组构成中的核心小组模式(Core Team Approach)。

      核心小组是有权开发特定产品的一个小型跨部门项目小组。一个典型的核心小组有5—8名成员,有权力也有责任管理所有与开发该特定产品相关的任务。这些特定任务分配到核心小组的每个成员身上,每个成员都利用相应资源完成这些任务。小组成员们为指定给他们的工作确定方向,与职能部门打交道,并作为核心小组的一员参与集体决策。PAC则在开发工作的每一阶段通过阶段评审流程赋予核心小组责任和权力。每个核心小组都有一个指导和引导小组工作的领导人。该小组在执行每一开发阶段时遵守与PAC签定的有关重大项目目标以及可变动的范围的“合同”。

    开发活动的结构

      开发活动是开发新产品的实质性工作。在PACE中,结构化的开发流程明确了应做什么开发工作、相应的先后次序、其间的关联性以及用于开发项目的标准术语。在评审流程中,我们发现,开发活动的结构中往往存在三类普遍的缺陷:(1)没有任何明确的产品开发结构的公司;(2)有具体流程手册但并没得到遵循的公司;(3)有结构化的流程但并不能改进或加快开发进度的公司。

      对第一种情况来说,公司必须在产品开发流程中不断地“重新发明车轮”,即重新定义产品开发流程。每一个项目小组都定义其要遵循的流程,结果,每个项目小组即使在执行相同的或相似的任务时,开发流程也迥然不同。这种模式延长了开发周期,且整个公司的项目小组都易犯同样的错误。

      对第二种情况来说,流程被文档化了,但是并没有得到执行。典型的情况是,某个职员在程序手册里定义开发流程,然后把手册散发出去,天真地期待每个人都会遵守它,结果当然是他们并不遵守。多数情况下,他们不遵守反而好一点。项目小组又各自将自己的那一套流程搬了出来。

      对第三种情况来说,开发流程已得到明确和遵守,可惜这个流程天生就效率低下。令人吃惊的是,许多公司在规范流程时,只是简单地将他们现有的做法写成文件,哪怕这个流程效率低下,其结果自然是把问题制度化了。

      在评审开发流程时,我们发现普遍存在下列缺陷:

    ·无章可循的开发活动导致产品不断更新。
    ·由于对必须完成什么样的开发活动及何时完成有误解,因而造成项目计划不周及准备不足。
    ·缺乏通用术语以及由此引起的理解问题,导致开发工作不理想。
    ·产品开发定义过于详细,尤其是缺乏结构化的定义,使得开发效率不高。
    ·每一步都需要多个签字盖章的官僚流程延缓了开发工作。
    ·缺乏并行工程,因为它没有被设计到结构化开发流程里。
    ·缺乏开发活动的周期时间指导,导致项目进度不准确。
    ·由于没有将责任落实下来,导致未能不断地改进产品开发流程。

      在PACE方法中,核心小组用结构化开发流程开发产品,这将确保一致性,并避免小组创立各自的流程。基于一个通用的结构化流程,就可以使用通用的周期时间指南并为持续改进打下基础。

      按照PACE的方法,一个结构化开发流程包括几个等级。在阶段评审流程所提供的框架中,一般有15—20个主要步骤来定义一个公司的产品开发流程;每一步又分成10—30项任务,规定每一个步骤如何在公司里得以实施。这些任务又为每一个步骤定义出标准周期时间,因此可以根据这些基本步骤编制进度表、预估资源需求、制定计划及进行管理。

      每一项任务还可进一步细分成各种各样的开发活动。根据任务的性质,每一步骤的开发活动数量从几个到30或40个不等。总的来说,各步骤与任务永远适用于各种项目,而开发活动则因项目不同而不同。

     

    展开全文
  • 本人2000年就在华为印度所参与CMM的实施,后续帮助10多家企业实施CMMI体系,总结下来发现,一定要以项目为主线实施CMMI,通过项目主线将CMMI的各个过程域穿插在项目具体活动中,这样实施的直接好处是项目管理团队拿...

    如何快速响应市场的变化,如何推出更有竞争力的产品,如何在竞争中脱颖而出,是国内研发企业普遍面临的核心问题,为了解决这些问题,越来越多的企业开始重视创新与研发管理,加强研发过程的规范化,集成产品开发(IPD)、集成能力成熟度模型(CMMI)、敏捷开发(Scrum)是当前企业产品研发管理的最热门的3个体系,但是很多朋友并不真正了解这3套管理体系的适用范围和内涵,本文描述了它们之间的区别以及如何在企业研发管理过程中合理加以应用才能达到最优化的结果,使企业在市场竞争中保持不败之地并能脱颖而出。

    上篇请参考:如何理解IPD+CMMI+Scrum一体化研发管理解决方案之IPD篇

    http://blog.sina.com.cn/s/blog_81427a800102wqm5.html

    中篇请参考:如何理解IPD+CMMI+Scrum一体化研发管理解决方案之CMMI篇

    http://blog.sina.com.cn/s/blog_81427a800102wqm6.html

    下篇请参考:如何理解IPD+CMMI+Scrum一体化研发管理解决方案之Scrum篇

    http://blog.sina.com.cn/s/blog_81427a800102wqk7.html

    CMMI的历史、核心内容、实施难点和局限性、实施建议

    CMM/CMMI的历史

    信息时代,软件质量的重要性越来越为人们所认识。软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部立题专门研究软件项目做不好的原因,发现70%的项目是因为管理不善而引起,而并不是因为技术实力不够,进而得出一个结论:管理是影响软件研发项目全局的因素。1987年,美国卡内基.梅隆大学软件研究所(SEI)受美国国防部的委托,率先在软件行业提出了软件过程成熟度模型(CMM),随后在全世界推广实施,用于评价软件承包能力并帮助其改善软件质量的方法。

    CMM发布后,不但在单纯软件行业得到很好的实践,同时在系统工程领域、硬件领域、集成产品开发领域也有很大的借鉴价值,当年华为印度所推行CMM后,将软件CMM的方法嫁接到硬件项目开发管理中,形成了HW-CMM就是一个很好的例证。为此SEI推出CMM的升级版本CMMI,从而支撑更多领域的开发管理规范化。

    CMMI的核心思想

    CMMI,全称为“过程能力成熟度模型集成”,核心目的是用于衡量和改善组织过程能力的,虽然强调“人+技术+流程”三个方面共同决定开发项目的成败,而实际CMMI实施更多还是关注流程,强调过程规范性,最终达到保证开发交付质量的目的,CMMI的核心思想为如下2个方面:

    1、过程质量决定交付质量。CMMI将开发活动划分为22个过程域(PA),每一个过程域是关注研发项目中某个方面(PA),并且在CMMI标准中也定义和相应的工具方法,例如需求跟踪矩阵(RTM),强调组织只要严格按照规范化的过程去开发,开发最终交付的质量应该是可以保证的。

    2、组织能力需要持续改进。CMMI将组织的研发能力划分为5个等级,每个等级有详细的标准,建议组织根据自身能力、实际商业需要、组织资源多少灵活决定组织优化改进的目标。这一点本人深有感受,完全没有必要看别人已经过CMMI L5了,自己就着急,也要搞什么4级、5级,作为系统产品(涵盖软件、硬件、结构)的产品化公司,达到CMMI L3就完全够用了。如果招标书中严格要求承包商必须要达到什么CMMI的4级、5级水平,纯属误人子弟。

    CMMI的4类管理领域

    CMMI将开发活动划分为22个过程域(PA),同时这22个PA分别隶属4大管理领域,分别为:项目管理、流程管理、工程管理、支撑管理,而与产品开发组密切相关的主要是项目管理、工程管理、支撑管理三个领域:

    项目管理:本质没有脱离PMI标准的项目管理体系,例如项目策划、项目跟踪与控制、风险管理、供应协议管理这些内容在PMBOOK中都有详细的定义,所以可以理解为CMMI的项目管理是MiniPM,更加开发化的PM。

    流程管理:流程管理描述的也是非常通用化的流程优化与改进的方法,识别组织流程改进点,然后召集团队进行未来业务流程设计,全面推行前先试点,试点后修正,确保没有大的风险后,再全面推行,所以CMMI的流程管理没有脱离业界流程改进、流程优化的范畴,说实话没有什么神秘的,这些方法早在上个世纪80年代,在制造行业都已经普及了。

    工程管理:不同行业的工程技术方法存在比较大差异,虽然都叫软件编程,C语言与Java就有很大的差别,都叫可靠性设计,汽车行业与手机行业的差异也是显而易见的,所以CMMI针对工程管理只是定义最通用的方法,例如需求收集的方法就给推荐了一堆,什么访谈法、头脑风暴法、市场调研法、原型测试法、业务分析、Usecase法、逆向工程法、客户满意度调查法等,基本涵盖了人类可以想到的所有方法,而每种方法该如何做呢?哪个方法适合呢?CMMI没有告诉你,自己去修炼吧!所以针对工程管理,本人感觉CMMI定义的比较粗浅,只告诉做什么,但怎么做,几乎没有说明。

    支撑管理:个人认为支撑管理领域是CMMI 4个领域中定义最具有可操作性、最完备的部分,由此可以推测,估计当时CMMI定义小组,大部分成员是质量管理人员,尤其配置管理、度量和分析、质量保证定义的非常不错,能给实施CMMI的公司以非常具体的指导。

    CMMI的局限性

    从CMM/CMMI的出生就决定了CMMI作为研发管理体系的局限性,美国国防部为确保外部开发机构交付产品的质量,而资助SEI形成CMMI开发管理体系,所以CMMI的核心局限有2点:

    1)本身不谈如何赚钱的问题。作为美国国防部的外包方往往有充足的人员、资金、时间来从事产品研发;同时只要确保质量、按时交付,至于交付后产品怎么卖、怎么盈利不用关心,所以CMMI通篇规范几乎没有涉及竞争分析、财务分析、市场分析、上市推广;同时对产品的量产交付能力、量产采购供应风险也基本没有考虑,如果是产品化公司,单纯靠CMMI就很难确保市场成功,往往会进入为了流程而流程、为了量化而量化、为了质量而质量,这样的境地是非常危险的。

    2) 更多关注的是开发活动,没有将产品开发上升为涉及多个业务领域的系统工程。作为一个成功的产品往往涉及策划、实现、运营;及时在实现阶段也需要涉及市场调研、竞争分析、可制造性、可服务性、制造策略定义、服务策略定义,同时研发时,要充分考虑批量交付的可行性;CMMI针对研发项目团队的定义也更多局限在技术层次,如何让市场部门、采购部门、制造部门等相关领域的人员有效参与到产品开发并承担责任,CMMI没有明确的解决办法,没有设计一个贯穿整个产品生命周期的团队和角色存在,也没有横向交叉管理机构,而整个产品开发被分成一节一节的“封闭车厢”,这样往往导致局部最优,整体不优的结果。

    CMMI的实施难点

    首先:CMMI对象是一帮喜欢个性化,不愿被约束的人;CMMI主要是开发管理,同时需要开发人员配合收集提交相应的信息;开发人员普遍存在独立、内向、不善沟通、个人意识强,同时开发工作又难以量化等问题,CMMI实施往往被技术人员所抵制,很多公司最终就变成为应付交差,为了认证,造假一套资料,拿到证书后,原来怎么干,还继续怎么干,CMMI变成形式。

    其次,CMMI体系本身很散,需要丰富工程管理经验团队才能更好地把握实施内容。CMMI本身为了结构化,将研发相关活动划分为22个过程域,这样做的好处是便于专项学习,针对性改进。本人接触过国内一些企业CMMI实施的内容,就是按照CMMI的22个过程域分别对应定义22个管理规定,这是一帮绝对傻顾问、傻团队的自作聪明的作法,这样做认证评估很简单,一个对一个即可,但直接结果是项目管理团队不知道如何使用,作为项目管理团队,一般不管什么CMMI、IPD、ISO、什么过程域,他们就关心,该如何管理项目,如何按照项目主线来开展工作,而不是搞一堆过程文件,一看就烦。基于本人历史实施CMMI的经验,建议一定要首先定义项目运作主流程(阶段如何划分、涉及哪些角色、设置相应控制点、明确每个角色活动和职责),CMMI的22个过程都是为了支撑项目主流程的具体方法。

    CMMI的常见误区

    1)CMMI比较适合外包公司、软件企业,我们是做自主产品的,CMMI不适合我们。CMMI其实是规范化产品开发管理的标准方法,虽然起源在软件行业,但CMMI的规范、方法同样适用硬件、结构等领域的开发;实践证明CMMI非常适合产品开发中具体某个模块的开发管理,整个系统级产品的研发过程需要借鉴IPD的思路,但具体细节模块的开发就需要借鉴CMMI的方法,因为CMMI管理的更加精细和具体。

    2)CMMI很繁琐,需要提交大量的文档、填很多的表、收集海量的数据。CMMI本身是划分为5个等级,组织完全可以根据自身实际需要灵活决定朝哪个等级努力,CMMI本身没有明确要求需要提供哪些表格、需要写哪些文档、需要收集哪些量化数据,只是强调要知识沉淀、文档记录,至于实际需要写哪些文档,完全可以根据公司实际业务需要灵活定义,同时CMMI还强调裁减,可以基于公司流程,结合项目实际情况,灵活定义本项目的运作流程。关于数据收集,实践证明完全可以借助信息化手段快速、方便收集工作量、需求、进度、变更、文档等相关量化数据。

    CMMI的实施建议

    以项目为主线条实施CMMI相应过程域。CMMI目的是支撑研发项目的规范运作,22个过程域彼此独立,同时又密切关联;本人2000年就在华为印度所参与CMM的实施,后续帮助10多家企业实施CMMI体系,总结下来发现,一定要以项目为主线实施CMMI,通过项目主线将CMMI的各个过程域穿插在项目具体活动中,这样实施的直接好处是项目管理团队拿到CMMI体系后就知道如何操作了,也更清晰地展现CMMI对项目实际运作的指导价值,不能站在评估认证角度实施CMMI,一定要站在实际研发业务运作角度实施CMMI,这样的CMMI体系才会有生命力,才有广泛的群众基础。

    IPD与CMMI的差异

    IPD与CMMI起源和出发点的不同,决定了两者具有很大的区别。

    1) 管理层面不一样

        IPD是企业层面的一套产品开发管理的思想、模式和方法,本质上是一种产品经营管理的模式。CMMI是面向研发的,而且更多是面向软件、硬件、结构模块级开发的。

    2) 思想高度不一样

         两者目的的不同也导致了思想的不同。IPD是从投资、竞争、经营层次看待产品开发;CMMI主要倡导通过过程和活动来保证质量,更多是从过程、操作、实现方法层次出发。

    3)管理的范围不一样

         IPD对所有的产品开发活动进行管理,横向上涉及市场、设计、测试、试制、制造、采购、服务、销售、财务各功能部门在产品开发中的活动,纵向上涉及决策、管理、执行三个层面。而CMMI主要是面向研发部门的活动,如软件开发、系统集成、项目管理等。对于软硬件相结合的高科技产品而言,软件开发的工作量往往占整个开发工作量的50-60%,而硬件开发又可能占到15-20%,所以CMM可以管到50-60%的开发活动,而CMMI可以管到65-80%的开发活动。

    4) 关注重点不一样

         IPD不仅关注把事情做正确(do the things right),同时更关注做正确的事情(do the right things),所以IPD既强调执行的重要,也强调决策的重要。CMMI主要关注执行,即把事情做正确(do the things right),而且CMMI对如何执行好开发活动要求更规范、更细。

    IPD与CMMI的融合一体化

    作为研发高科技企业,不但要做正确的事情,同时还需要确保把事情做正确;IPD能有效帮助企业确保产品研发方向的正确性,强调市场驱动、投资回报,将市场、财务、竞争、技术有效融合为一体;CMMI强调规范化、精细化管理,落实为具体的计划、流程、制度、模板、控制方法,能帮助企业把事情做正确;所以企业需要构建IPD+CMMI融合一体化的研发管理体系。

    IPD管得“宽”(从市场管理到产品开发,再到产品生命周期管理)、定位高(公司级的决策与开发组织与架构、公司级产品开发流程等);而CMMI把流程分解为一个个关键过程域(KPA),相对离散地来定义流程的,在细节上力求更精更深。尽管IPD与CMMI有众多的不同,但就对具体流程和活动进行管理而言,两者所依据的原则、方法和实践是相通和一致的,所以我们可以形象地将IPD看作产品研发管理流程“十”字的“横”,将CMMI模型看作“十”字的“竖”,“IPD+CMMI”将是企业产品开发管理体系完美的“十”字组合,从而优化产品开发体系,规范产品开发流程。

    案例分享:华为技术IPD+CMMI一体化研发管理体系

    华为IPD-CMMI管理体系

    整体产品开发过程按照IPD来运作,从产品立项开始到量产发布结束,涵盖概念、计划、开发、验证、发布5个阶段,4个商业决策评审点,7个产品级技术评审点;TR2(技术评审2,总体方案+设计需求评审)后,产品划分为多个子系统、模块,每个子系统、模块进入相对独立的设计、实现、验证环节,这些工作就严格按照CMMI的规范要求进行;TR4(技术评审4,开发完成评审)后,CMMI过程结束,子系统、模块集成为整机,按照IPD的流程规范来执行;华为的产品开发过程可以概括为IPD-CMMI-IPD的过程。

    后记

    IPD确保方向的正确性,CMMI强调规范化、精细化管理,确保把事情做正确;在这个“快鱼吃慢鱼”的时代,如何加快开发与验证的速度?这就需要开发工作和测试工作能够并行展开,从而实现及时发现问题、及时修复、及时交付,实现降低质量成本,缩短开发周期,提升竞争优势的目的,这就需要借助敏捷开发的方法。

    ------完------  

    (作者: 董奎 (Tiger.dong),青铜器RDM产品经理、华成研发咨询联合创始人、青铜器软件联合创始人,1998~2004年就职华为技术,参与电信交换机、数据路由器等核心电信设备的设计与开发,IPD+CMMI+Scrum一体化研发管理体系的践行者,目前该体系已经被华为技术、科大讯飞、美的集团、长城汽车、中联重工、宇通客车、长城汽车、京信通信、联芯科技、华虹芯片、四维图新等500多家企业,110多家行业第一名公司所采用。

    ​新浪微博: @董奎Tiger  http://weibo.com/dongkui168)

    展开全文
  • 研发管理工具推荐

    千次阅读 2018-07-09 12:58:44
    我来介绍一下我所找到的,好用的敏捷工具:国内的「Leangoo(中文名:领歌)」Leangoo是一款基于看板的项目协作工具,Leangoo是由国内最权威的Scrum中文网精心打造,融入了先进的敏捷管理思想。我们可以使...
  • 在此,总结下本人在数年研发管理过程中的一些经验,供参考,先列一些关键点,后面会不断完善。 目标 保证高效率、高质量地完成项目的研发和上线工作,并保证软件在线上运行过程中的高性能和安全性。 保证项目进度...
  • 研发管理之规范管理

    千次阅读 2018-06-21 08:09:01
    成为研发管理人员已有小几年时间,记录总结一下管理经验。 规范管理 研发管理中,开发规范管理是很重要的一环。 提到规范,网上自然有很多人分享,但普遍内容太复杂,至少对中小团队来说太复杂。太复杂的规范,...
  • 全能项目经理训练营

    万人学习 2018-10-22 21:38:02
    项目管理就是一个大坑,什么都可以放进去! 项目经理就是这个坑的坑主,他需要具备周身刀,并且把把锋利。 本课程为你分享项目经理需要掌握的N多技能。
  • Git实战视频教程

    万人学习 2018-11-02 11:15:35
    Git作为实战型比较强的一门技术,光看书学习效果一般不是佳。Git视频培训课程通过深入浅出的内部机制解析、实际操作、动画演示、使用场景模拟等教学方式,让你提升Git技能,知其然知其所以然,大大缩短您的Git学习...
  • 带你玩转SVN

    万人学习 2019-06-26 11:58:52
    SVN是版本控制利器,团队协作工具之一。本课程主要面向开发人员,帮助初学者意识到版本控制的重要性,掌握SVN环境的搭建,以及SVN客户端工具的使用。
  • Linux Makefile工程实战视频教程

    万人学习 2018-10-25 11:48:38
    Makefile工程实战视频培训课程,该教程介绍Linux环境下开发软件编译Makefile的基础知识、项目构建、一步一步从零开始写一个模拟MP3项目的Makefile。
  • 项目管理工具是团队研发过程中不可缺少的工具,有助于团队协作,大大提高开发效率,这里对几个项目管理软件进行了对比。 1.TOPO 适用于重点关注任务、缺陷、文档及代码的研发团队。支持多项目数据汇总对比,完整的...
  • Jmeter性能测试从入门到精通-全程实战 全程实战,每个知识点通过实际项目演练讲解 理论实践结合,既会做,又知道为什么这样做 讲解时同其他工具做对比,加深理解,了解区别 分享技巧,用起来事半功倍 ...
  • Robot Framework 自动化测试框架

    万人学习 2019-11-29 15:16:52
    Robot Framework 自动化测试框架,包括接口测试、数据库测试、Web测试、App测试。
  • 团队项目管理工具:Maven3入门实战

    千人学习 2019-10-18 09:55:18
    Maven+SVN是目前团队项目开发,使用多的项目管理工具。 学习并掌握Maven与SVN,是JAVA开发人员必须的技能。
  • Python自动化测试之Selenium

    万人学习 2019-11-29 15:18:02
    本课程详细介绍了Selenium Python版本的自动化测试方法和实践,通过本课程的学习你将掌握如下内容:Selenium 测试环境搭建单元测试、生成测试报告、定位元素、WebDriver属性和方法、WebElement属性和方法、操作form...
  • 软件测试入门视频教程

    万人学习 2019-06-25 10:59:08
    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试...
  • 《QuickTest Professional》原书作者授课,书籍配套视频,QuickTest是测试领域的一门重要的专业技术课程,其属于测试领域中课程。课程讲授当前HP旗下主流自动化测试工具QuickTest Professional。
  • SDCC2015大会精彩演讲PPT集锦

    万人学习 2015-11-26 17:20:30
    SDCC2015中国软件开发者大会,由CSDN重磅打造,作为年度的技术盛会,邀请了近百名国内外业界领袖和知名技术讲师共论技术热点与佳实践。 本压缩包汇聚SDCC2015所有可公开的讲师演讲PPT,共计10份。...
1 2 3 4 5 ... 20
收藏数 242,932
精华内容 97,172
关键字:

研发管理