谈谈芯片设计企业中的产品项目管理
项目/产品管理,是人人都懂,但人人都不是很懂的概念,今天我来拆解一下,把两者区分开来讲,最后再合起来,看两者的配合。
1:项目管理误区
对于项目管理,容易走两个极端。一个是完全排斥,一个是把它神化。
一个极端是:老板认为项目管理人员很多都是业务的外行(初创公司,因为某些不愉快的经历,可能碰到了半吊子的项目管理人员),让外行领导内行,容易造成专业内行人员的反感,导致项目运转不畅,在某些阶段,不如不管。
另一个极端:认为产品的质量问题,项目的延期问题,目标不清晰的问题,等……,都是没有好的项目管理导致,项目管理在他看来就是银弹(因为在大公司呆习惯了,看过一些成熟公司的项目管理)。没有项目管理,一定无法产出好的产品,混乱在所难免。
大家容易走这两个极端,或者说无法找到平衡点,这是在创业公司和缺少真正的行业经验的企业常犯的错误。
因此,在什么时机,如何适当的引入项目管理,是个很难把所握的问题,也可能企业稀里糊涂,运气很好的渡过了(我认为,高技术领域的企业很难),也可能在还没有得到答案前,企业就夭折了。
那原因是什么呢?我认为是没有理解项目管理的本质。
那项目管理的本质是什么呢?
项目管理,是以规则的确定性来降低结果的不确定性。确保项目保质保量按时完成。
2:产品管理界线
另外一个问题,容易把产品管理和项目管理给混淆了。搞不清楚产品管理和项目管理的界线,什么时候需要产品经理,什么时候需要项目经理。
这其实是很简单的问题,但是,对于没有管理经验的初创公司,可能照抄了一些作业,但实际上并没有真正理解背后的原理。
实际上产品管理和项目管理有很大的不同,
目标:
产品管理——确保产品全生命周期成功(市场价值实现)
项目管理——确保项目按时按质完成(执行效率)
时间:
产品管理——长期(3-5年产品路线图)
项目管理——短期(6-24个月项目周期)
关注:
产品管理——市场需求、技术趋势、竞争力、ROI
项目管理——资源协调、进度控制、风险应对
决策权:
产品管理——战略优先级与产品定义
项目管理——执行路径与任务分解
交付:
产品管理——可盈利、可迭代的产品
项目管理——符合需求、按时交付的阶段性成果
产品管理,确保产品在全生命周期取得市场价值,能为公司取得成功。
3:企业需要管什么
综上所述,我们再回头来看看,企业哪些事情需要管?
- 市场——找到产品真实的市场方向。这是企业生存的基础,找到客户。
- 需求——获得产品最准确/真实的需求。这是产品质量的本质,知道客户要的是什么。
- 研发流程结构化,决策制度化——让研发过程风险可控。这是个工程问题,要有能力交货。
- 积累成功经验,不依赖英雄——让企业持续发展的流程深淀。这是企业生命力的问题,是否可以经得起大风大浪。
我们从上面可以看得出,实际上,管理可以贯穿到企业的方方面面和各个阶段,它的目的是很明确的,抓的都是生存问题,而结合产品管理+项目管理,就是管了企业的命脉。
但要注意,我们这里指的项目,不是指的那种周而复始的重复型工作,确定是面对一个有特定目标,临时性,一次性的活动,我们称之为项目。每个项目都有自已的独特性,往往不同团队会采用不同的过程。
所以,要说项目管理,更多是指的是研发过程的管理,以及企业持续发展,需要的流程管理。
那么,我们先来看看项目管理。
4:项目管理要管什么
上面讲到了,我们需要管的东西,那具体如何管呢?人员是如何配合的呢?
不管做什么事,一件事情要达成,有三个关键要素:
时间:
能否在指定时间内完成。任何产品都是有市场周期的,一旦错过某个时间点,可能就一文不值了。
要能达成,首先是要做好计划,控制计划的实际执行(时间),控制好变更,如果项目由多个子项目组成,需要做好项目集的管理,对于任何风险,要尽早识别,尽早应对。
质量:
产品如果达不到一定的质量,可能也会失败,所以,一定要达成某个质量标准。
成本(效率):
如果不计成本去完成一件事情,那可能是赔本买卖,或者说资金无法支撑,那也是不行的,所以,还需要达与一定的效率,需要控制成本。
流程化是根本,对于可以固定的过程,通过流程化让它执行高效。
根据三个要素,我们可以拆解出如下的管理点:
4.1:时间——计划管理
在获取任务后,第一要务就是制定计划,计划要做到什么程度?
我们假设任务已经拆解到具体人员,任务的拆解,有很强的专业性,一般需要技术管理人员来完成。
然后,计划需要确定大的里程碑,这样,可以把大任务拆成阶段的任务,方便把控风险。
任务分配到人,分配时间,同时也就确定了人力和时间资源。
任务需要建立依赖关系,这样可以控制风险。
所有任务都按流程来进行驱动,而流程可以自行定义,比如:
简单流程——开始,进行中,已结束。
需求分析的流程——需求调研,需求分析,设计,……
复杂的流程——完成按需要进行自定义。
注意:流程是可以回退的,通过流程可以更好的把控任务的完成状态,跟进进度。
4.2:时间——执行时间管理
根据计划和实际执行录入的情况,提供执行情况的跟踪,主要是查看任务逾期的情况。
根据实际的执行情况,对执行排期进行微调。如果需要变更时间计划,或者变更产品需求,需要进行 变更管理。
4.3:时间——变更管理
变更这里指的是排期,也可以指的是产品的需求。但不管是哪个,变更需要是主动的,而非被动完成。变更的管理需要有一定流程,但也不要太繁琐。
变更的规则,可以自行定义,比如:在TR3之后,所有变动都会触发变更,这个可以视需求来定义。
4.4:时间——项目集管理
如果项目由多个子项目组成,要达成合理的时度,需要站在项目集的高度,协调相互关联和依赖的项目。
一般需要提供一个全景图,将所有相关的子项目聚合到一起。比如:一款FPGA系列芯片的研发,可能包括硬件开发,软件开发,验证测试,生产测试(上板)这几个子项目需要有好的配合,才能保证整体项目完成。
可能还需要定义一些全景的指标,来衡量项目集的完成度。然后根据实际情况,放置到PMO的工作台上进行管控。
4.5:时间——风险管理
初期需要定义风险(界定),过程中需要有能力识别风险(有工具),产生风险后需要分析风险,并制定相应的计划,最后达成控制风险的目的。一旦形成风险经验库,也可以给到后续项目做参考。
风险的界定,可能是一个计算字段,也可能是人为填写。需要提前定义好。
4.6:质量——质量管理
确定规范,放到流程中把关。
对质量进行分析,提供看板,进行预警。
提供实时的数据展示,驱动项目高质量交付。
质量在一个很大的产品里,不方便单独拿出来,最好还是放到子项目中反关。只是相关质量指标的定义,公司需要有一个单独的组织来评审确认,做到有公信力,并且科学。
4.7:效率——流程管理
按业务流程来建立组织架构,因此可以获得规范的流程。流程需要持续的PDCA(Plan Do Check Act)。
上面的每一个任务,我们都可以认为是一个小的流程,而不同任务又建立起一个大的流程。
有了上面的这些管理,还需要有一根绳把它们都串起来,那就是整体的管理,可以理解为程序中的编排,调度。以它定义开始和结束。注意,这不仅仅是项目集的管理。
4.8:整体管理
建立项目任务书,确定大的项目目标,预定义交付物要求。
定义项目的关键度量指标,通过多种视图对进度进行监控。
出现问题了,组织集成的变更组织和流程进行决策。
所以,这里还有一个不可少的决策评审。后面会单独讲决策评审。
好了,项目管理就讲这么多了。
但是,据统计,不少项目的失败并不是因为项目管理过程,而是因为需求不正确导致。所以,合理的需求管理,实际上是非常重要的事情,它指引我们做正确的事情,然后才是正确的做事。这样,我们就过渡到产品管理了。
5:产品管理要管什么
IPD中讲到的,端到端 ,也就是建立一个拉通的跨部门团队,来解决部门墙,信息孤岛的问题。其实,最重要需要拉通的就是客户需求收集,分析,分发,实现,验证的过程。
正如上面讲到的,产品管理是面向市场,面向客户的,最重要的就是需求的管理。
5.1:需求收集
需要有一个好的通道的手段来收集客户的需求。
当然,也包括内部的需求。对于FPGA芯片,不管是硬件还是软件,基础还是一些行业的需求,可以理解为内部需求,如果没有经验,这个需要花大力气做一次初始化,不要把基础的问题放到迭代阶段去做,那样,会让客户伤心。
3.2:需求分析
收集到的需求需要结构化,明确的对需求进行解释,过滤,分类,排序。
解释:就是需要将需求讲得很清楚,有必要的话,开评审会进行澄清,了解需求的真实价值。
过滤:不符合价值的需求,需要打回补充,或者终止需求。
分类:我们会交需求进行分类,短期,紧急,长期,以便下一步进行分发。
排序:需求是有优先级的,可以按照公司战略和其它因素来划分,将公司有限的资源投入到最重要的事情上。
3.3:需求分发
需求一般有三种类型:紧急,短期,中长期。不同类型增的流程是不同的,需要按照不同方式给到研发团队。
这里实际上就是通过规则来减少不确定性。因为三种分发的流程完全不同,如果走相同的流程,一定会有效率问题。
3.4:需求实现
需求的实现,这里就是要和项目管理进行对接了。并且,相关需求的状态,也需要及时的互通。需求要做到理解到位,不遗漏,不曲解。需要将MRD变成PRD,而PRD可以按 IR,SR,AR进行分解。
注意,信息的同步非常重要,需要随时了解需求的实现状况和实现结点。
3.5:需求验证
端到端验证需求,做到价值闭环。并且需求最终还需要上线后客户进行评估。
需求上线,并不是终点,需要持续跟进客户和市场的反馈。
管理一定不是一帆风顺的,一定会碰到很多争论,争吵,最害怕的是问题不暴露,不解决。所以,当发生问题时,一定要有好的决策管理。这时,领导层可能会出场了。
6:如何决策?
好的决策机制,是企业最终能否管理好的关键。那如何做到合理的决策呢?即要科学又要做平衡。其实呢,在IPD中有明确的决策评审点,大多数情况是会涉及的。
Charter评审:是项目启动前的商业论证,确认项目可行性和资源。
CDCP:Concept Decision Checkpoint,即概念决策评审,决定是否进入下一阶段。
PDCP:Plan Decision Checkpoint,计划决策评审,确认详细计划。
EDCP:Engineering Design Checkpoint,工程设计评审,确认详细的技术方案。
ADCP:Availability Decision Checkpoint,可获得性评审,确认是否可以量产,正式交付客户。
EOXDCP:End-of-Life Decision Checkpoint,生命周期终止评审,产品是否下线的评审。
当然,这些评审并不是全部,也不是都是必须,可以根据项目的实际情况进行增减。
评审是有一些标准的要素的,需要提前定义好,这也往往是企业的重要资产。
6.1:评审要素
主要是参与的角色代表(注意,一定是角色,而不是具体的某个人)。
评审的工作项,这是和实际工作相关的评审点,需要一早进行裁剪。当然,这可以在过程中迭代和优化。
6.2:评审结论
最终的结论是如何形成的?
可以记录大家的评论意见。
可以按百分比或者绝对人数,或者关键票来决定评审的结论,这可以灵活定义,但一定需要提前约定好。
个人以为,上面讲的几大内容,可以解释一个研发企业的主要管理要素。
做好了这几点,项目也不一定能成功,但至少不会在不合理的地方摔倒,可以大大加大成功的概率,甚至,可以助力团队及时找到核心问题,然后推动公司的HR,财务,采购去解决相关的问题,使得企业走向成功。注意:HR 需要帮助找人,采购需要帮助找外力,财务需要帮助找钱。
当然,还有一些细节的管理并没有提及,比如:交付物管理,评审管理,工时管理等……
最后,项目管理在哪里?产品管理在哪里?谁来管他们?
有一个比较简单的架构,可以随便给一下:
CEO ├── **产品管理部**(CPO) │ ├── 行业产品线(通信/工业/汽车电子) │ ├── 技术战略组(制程/IP核/生态规划) │ └── 市场分析组(竞品/客户需求) | └── 质量管理 │ ├── **研发中心**(CTO) │ ├── **硬件部** │ │ │ ├── **软件工程部** │ │ │ ├── **验证与测试部** │ │ │ └── **PMO(项目管理办公室)** │ ├── 硬件项目经理(负责流片交付) │ ├── 软件项目经理(负责工具链发布) │ └── 集成项目经理(跨模块协同) │ └── **生产运营部**(COO) | ├── 生产测试 | ├── 工程管理 | └── 供应链 | └── IT支持 | └── **市场部**(COO) ├── AE ├── FAE └── 销售
对于质量部,项目管理的定位,可能根据公司的重点会有所不同。我认为项目主要还是集中在研发。整体的管理更偏重产品管理。而质量更多是定义和确定规则,检查结果,起到辅助作用,更多的质量问题,要落在产品和项目的流程中去。