当前位置: 首页 > article >正文

谈谈芯片设计企业中的产品项目管理

        项目/产品管理,是人人都懂,但人人都不是很懂的概念,今天我来拆解一下,把两者区分开来讲,最后再合起来,看两者的配合。

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 
    └── 销售

对于质量部,项目管理的定位,可能根据公司的重点会有所不同。我认为项目主要还是集中在研发。整体的管理更偏重产品管理。而质量更多是定义和确定规则,检查结果,起到辅助作用,更多的质量问题,要落在产品和项目的流程中去。


http://www.kler.cn/a/534741.html

相关文章:

  • Verilog基础(一):基础元素
  • 蓝桥杯备赛题目练习(一)
  • langchain教程-5.DocumentLoader/多种文档加载器
  • AI大模型:DeepSeek
  • 苹果再度砍掉AR眼镜项目?AR真的是伪风口吗?
  • [ Spring ] Spring Boot Mybatis++ 2025
  • 【漫画机器学习】083.安斯库姆四重奏(Anscombe‘s quartet)
  • 链式结构二叉树(递归暴力美学)
  • C06S01-Docker架设
  • 前端知识速记:重绘和回流
  • 自然世界的数字原理
  • 文件上传到腾讯云存储、签名及设置过期时间
  • 算法日记13:SC41树状数组(区间修改)
  • C语言程序设计P7【结构体和共用体】——定义和使用结构体、使用结构体数组、结构体指针、链表、共用体、枚举类型
  • c语言对应汇编写法(以中微单片机举例)
  • java时间相关类
  • 微信小程序~电器维修系统小程序
  • 【redis】数据类型之list
  • 深入解析色度二次采样 —— 4:4:4、4:2:2 和 4:2:0 的技术分析
  • API接口开发分享一些在实际开发中获取京东商品价格信息的方法
  • 【LeetCode】day15 142.环形链表II
  • 微服务知识——微服务拆分规范
  • 全能型免费内网穿透工具,全面支持macOS、Windows、Linux及Docker系统
  • 深入了解 MySQL:从基础到高级特性
  • 【实用技能】如何使用 DHTMLX JavaScript 组件加速初创企业发展?
  • 获取阿里云nacos注册接口状态