ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

IPD产品开发流程裁剪指南:按项目驱动分类,落地阶段评审与归档

IPD产品开发流程裁剪指南:按项目驱动分类,落地阶段评审与归档 简介面向产品研发与项目管理人员的IPD产品开发流程标准宣贯PPT系统梳理产品从概念、规划、设计验证到生产销售的全生命周期。资源围绕市场驱动、技术驱动、提高竞争力三类项目展开对比剖析各自特点与适用场景并逐阶段说明概念阶段的市场/技术调查分析、规划阶段结构化技术方案与关键技术识别、设计及验证阶段原型机制作与中试、小批试生产等关键任务以及各阶段成果文件如项目概念任务书、规划任务书、设计验证报告等。附件包含立项、概念、规划、设计验证等阶段的详细工作流程图、操作指引与对应表单规范可作为企业导入IPD体系、梳理研发流程或内部培训的实用参考。压缩包内含1个PPT文件大小约359KB内容精炼、结构清晰便于直接用于宣贯学习。该资源已有160人学习下载适合需要系统理解IPD核心框架与落地要点的产品经理、项目经理及研发管理人员。1. IPD产品开发流程先按驱动分类再谈裁剪否则标准流程只会变成过场IPD产品开发流程是那种下载下来容易、真正用起来很容易翻车的资料。乍看是一套从概念到销售的端到端流程图可它真正的核心不在那张总图而在你的项目属于哪种驱动。这份宣贯PPT把项目拆成市场驱动、技术驱动、提高竞争力三类每一类的阶段取舍完全不同市场驱动要完整走立项、概念、规划、设计验证技术驱动可以直接跳概念阶段提高竞争力的项目在概念阶段只做部分工作。对研发项目经理、被要求把研发流程建起来的技术负责人来说这份材料的直接价值是你不需要重新发明流程只需要按它给出的阶段评审点和文件配套搭出属于自己的那一套。适合具体做硬件、嵌入式、系统集成项目的人以及正在被流程文档折磨、想给团队定规矩但不知道第一步干什么的人。2. 项目驱动分类是流程裁剪的总开关市场/技术/竞争力三类项目差在哪2.1 市场驱动的项目十二项不清决定了必须完整走完所有阶段市场驱动的项目在PPT里给了一个很扎心的画像十二项特征全是不清目标用户群模糊、项目全新、竞争环境不清、目标产品不清、技术可行性和制造可行性不清、投资组合风险回报不清、政策法规不清、适用的标准不清、可制造性不清、客户服务和技术支持方案不清、可获得资源不清、项目费用不清。做项目的人看到这份清单应该会有共鸣这种项目就是典型的从零开始连从哪问起都不知道。这类项目最忌讳的是跳过概念阶段直接冲规划因为目标产品和技术路线都还没收敛写出来的结构化技术方案大概率是拍脑袋拍出来的。因此市场驱动的项目必须走完整流程立项、概念、规划、设计及验证、生产销售。全流程的意义不是流程繁琐而是每经过一道评审就砍掉一批不确定性。概念阶段做的市场调查和技术调查本质上是在把十二个不清逐项变成清晰。概念阶段内部有一套完整动作调查、分析归纳、验证、综合。调查要同时覆盖现在和潜在两种情况市场侧看目标用户、用户群、需要的产品种类、市场容量、可接受价格区间、竞争环境、政策法规技术侧看项目应完成的功能、市场现有产品、市场期望的产品概念、适用的国标行标。分析归纳阶段产出《项目市场分析报告》和《项目技术分析报告》在验证基础上综合成《初步项目技术规格》《项目概念性方案》《市场业务规划和计划书》《技术业务规划和计划书》《项目风险分析和评估报告》最终形成市场可行性分析报告和技术可行性分析报告交决策层做项目可行性决策。这里有一个很多人忽略的关键点可行性分析报告是集成文件。技术可行性分析报告内部集成了技术调查报告、技术分析报告、初步技术规格、概念性方案、技术业务规划和计划市场可行性分析报告同理。归档时只归档集成件即可过程文件不需要进档案。很多团队把流程跑重就是没意识到大部分文件是在逐层汇总决策层真正看的其实就是一份可行性分析报告加财务的风险分析。概念阶段的产物在下一阶段如何被使用也决定了它的写法。《初步项目技术规格》是规划阶段制定最终《项目技术规格》的依据《项目概念性方案》是结构化技术方案的上游输入市场和技术业务规划则直接影响资源配置和费用计划。写概念阶段文件时心里没有这张和下一步的接续关系图写出来就是一堆漂在纸面上的报告。2.2 技术驱动与提高竞争力项目跳概念阶段的前提条件不是技术厉害技术驱动的项目特点与市场驱动几乎反过来目标用户群清晰、项目清晰、竞争环境清晰、目标产品清晰、技术可行性清晰、制造可行性清晰、投资组合明确、风险回报清楚、政策和标准清晰、客户服务和技术支持方案清晰、资源清晰唯一待落实的是费用计划。这种项目的流程只走三条立项、规划、设计及验证概念阶段整个砍掉。原因是调研分析工作在立项前就基本完成了或者项目本身就是基于成熟技术栈的升级迭代再走一遍市场调查纯属浪费时间。但砍概念阶段有个容易被误用的前提技术驱动不等于技术很牛。技术驱动的判断标准是对项目本身的认知已经清晰而不是我们掌握了很厉害的技术。如果团队只是觉得我们技术强所以不用做需求分析然后硬套技术驱动流程那就是把流程分类当挡箭牌了。我见过不止一个项目立项时拍板说技术驱动做完规划才发现目标用户群根本没定义清楚又回头补概念阶段的调研全程白跑。提高竞争力的项目介于两者之间目标用户群清晰、竞争环境清晰但目标产品有待清晰可获得的资源有待落实费用计划有待落实。流程上只做部分概念阶段工作然后进规划、设计及验证。所谓部分概念阶段工作通常是只做技术侧的分析和规格确认省略大范围市场调查因为目标用户和竞争格局已经明确再把预算花在市场调研上是纯浪费。这里再提醒一句裁剪流程不等于裁剪评审记录。即便是技术驱动项目跳过概念阶段规划阶段的两次评审一次都不能省设计验证阶段的原型机和中试测试都要按全套标准跑。裁剪的是重复的调研动作不是质量门槛。2.3 一张表对照三类项目的流程取舍把三类项目的差异压成一张表做项目立项时可以直接拿来判断流程怎么裁判断项市场驱动技术驱动提高竞争力目标用户群模糊清晰清晰目标产品不清清晰有待清晰技术可行性不清清晰清晰制造可行性不清清晰清晰费用计划不清有待落实有待落实概念阶段完整执行不执行部分执行规划阶段执行执行执行设计及验证阶段执行执行执行归档重点可行性分析报告结构化技术方案技术规格加方案这张表的实际用法是拿来当裁剪清单。每次新项目立项时拿十二项特征逐条打勾落在哪一类就按哪一类走不要拍脑袋决定也不要用我们上个项目就是这么跑的来当理由。项目驱动的分类本质是评估团队对项目的认知程度认知越清晰能裁剪的阶段越多。实践中这张表还可以当流程健康检查工具每半年复盘一次把已交付项目的实际路径和这张表对一遍看有没有隐性跳过评审的情况有就补流程没有就继续用。3. 从立项到中试的完整链路每个评审点该卡什么文件、由谁决策3.1 立项阶段项目建议书的流转与决策门立项阶段是流程入口也是最容易做成走个过场的一段。流程本身很清晰项目建议人或部门提出合理化建议填写《项目建议书》送到研究所研究所登记、整理并给出初步意见送网络厂领导决策。决策不通过直接终结决策通过由研究所负责组建项目组、启动相应设计阶段工作。这个环节的关键参数有两个项目建议书给谁看以及研究所的初步意见到底评什么。实践中研究所初步意见主要评三件事项目方向与现有产品线是否吻合、技术可行性是否具备基本条件、资源投入是否可承受。这三条不满足就没必要往决策层送。立项通过的产物是研究所下达《项目概念任务书》或《项目规划任务书》计划部下达《项目总体工作计划》。怎么选任务书依据就是项目驱动分类市场驱动项目下达概念任务书因为还要做完整的用户、市场、竞争环境摸底技术驱动或提高竞争力项目如果立项前已经理清目标产品和技术路线可以直接下达规划任务书。任务书选错后面所有动作都会跟着错。配套文件在这一步就要建立起来《项目建议书》《项目建议书填写规范》《组建项目组通知》《项目概念任务书》《项目规划任务书》以及各自的编写规范。很多团队做研发流程时忽略编写规范这件事结果同一个阶段不同项目写出来的文档格式五花八门评审人根本看不下去。标准流程的落地一半靠流程本身一半靠文档规范统一。3.2 概念阶段调查、分析、验证、综合的四步收敛法概念阶段是IPD里信息密度最高的阶段也是新手最难拿捏的阶段。它的核心逻辑是从一片模糊中一点点逼近结论把十二项不清压缩成一个可执行的技术规格。概念阶段的起点是项目组接收概念任务书依据《项目总体工作计划》制定《项目组概念阶段工作计划》再下达到各功能领域形成《项目分解工作计划》。这里注意有两级计划项目组一级是对总体计划的责任分解功能领域一级是对项目组计划的再分解。两级计划都是过程文件不归档但它们的存在决定了项目组内各成员单位有没有被真正调动起来。调查环节分市场调查和技术调查两条线。市场调查覆盖目标用户、用户群、产品种类、市场容量、价格预期、竞争环境、政策法规导向技术调查覆盖项目功能、市场现有产品情况、市场期望的产品概念、适用的国标行标。有四条硬指标值得记住市场容量、价格预期、竞争环境、适用标准。这四个数不清楚后面所有假设都是空中楼阁。分析归纳在调查基础上形成两份报告《项目市场分析报告》要回答现有市场情况、潜在情况、产品定位、市场策略与规划、市场份额预估、市场支持策略、存在的问题及解决办法《项目技术分析报告》要回答需求分析、需求规格与项目概念、应用到的技术、现有技术资源的满足程度、技术障碍及解决办法。验证与综合接着收口先验证两份报告里的关键结论再综合成《初步项目技术规格》《项目概念性方案》《市场业务规划和计划书》《技术业务规划和计划书》由财务做《风险分析和评估报告》。到这里市场可行性分析报告和技术可行性分析报告就成型了决策层据此做概念阶段决策评审。归档习惯值得直接抄可行性分析报告只归档集成件项目组计划和分解计划不归档。原因很朴素归档的目的是让后续阶段和审计有据可查过程文件无人会看归档只会让文控系统变成垃圾场。3.3 规划阶段结构化技术方案与关键技术清单的双评审规划阶段的输入是《项目规划任务书》和调整后的《项目总体工作计划》。执行时项目组先制定《项目规划阶段工作计划》再下达各功能领域《项目分解工作计划》。这一段的工作量比概念阶段轻但决策权重更高因为技术路线在这里彻底定型。规划阶段要完成三件事系统分析、完善、确认《项目技术规格》制定《项目结构化技术方案》确定《项目关键技术明细及解决方案》。技术规格从概念阶段的初步版本升格为最终版本这是后面设计阶段的唯一依据。所谓确认是让设计、中试、市场、品质各功能领域对规格达成一致这份文档一旦定稿设计评审、测试方案、采购选型都会以它为准规格里任何一个模糊的词都会在设计验证阶段变成一次返工。规划阶段有两次评审性质和顺序不能搞反。第一次是技术评审对象是结构化技术方案和关键技术清单解决的是这个方案能不能成立第二次是决策评审对象是设计验证工作计划、资源配置和费用计划解决的是值不值得投入资源做下去。技术评审不过设计验证计划做得再漂亮也不用谈决策评审不过技术方案再好也要终结。评审顺序是这套流程里最容易翻车的地方。很多团队把技术评审和决策评审合并成一场会技术专家觉得方案没问题就默认项目会继续结果费用超预算被决策层砍掉技术白做反过来只谈钱不谈技术风险项目进了设计阶段才发现关键技术根本没验证过。实际项目里我会把两次评审分开至少两天逼两个问题各自有明确回答谁也不能糊弄过去。3.4 设计及验证阶段方案评审、原型机、中试、小批试生产四道门设计及验证阶段是IPD里最复杂的一段参与角色一下子扩编了。设计启动前网络厂技术委员会要扩建项目组纳入设计、品质、采购、生产、中试、市场部、系统工程部同时下达《项目设计任务书》和调整后的总体工作计划。设计部门出技术方案采购出采购计划中试和生产出部门计划质量计划视项目而定多线并行是这一阶段的底色。设计实现的产出是一整套可供生产的文件原理图、PCB文件、总装图、接线图、零件图、产品BOM单、项目程序、使用说明书同步完成FAE报告和关键元器件检验项目及方法要求。这里最值得注意的一句话是FAE、质量计划、测试准备、物料采购同时展开。很多团队的设计阶段只有研发一个人忙等原型机出来采购还没备料测试没准备白白浪费几周。方案及计划评审由技术委员会执行评审维度四个计划是否一致协调系统、具体技术方案是否符合结构化技术方案、方案是否合理科学最优、关键技术应用是否正确、标准化应用是否正确。评审通过后进入原型机制作。原型机测试由开发部测试组承担中试、品质协助测试通过后完成设计文件准备提交原型机设计评审。原型机评审通过后才轮到中试也就是系统测试。中试以中试、品质为主开发部辅助生产部、市场部、系统工程部参与测试内容和原型机测试相同。这里有一条非常重要的规则中试不通过直接返回设计连中试评审都不必开。这个规则的价值在于拦截——原型机测试可能是在理想参数下通过的中试是用接近生产的条件再压一遍不通过说明产品还没到量产条件。中试通过后申请中试评审侧重性能、功能、工程化的满足程度。再往后是设计确认评审、小批试生产、生产评审、发布新产品信息和取证申请最后进入生产销售。设计确认通过后设计文件转化为生产所需文件以品质、生产为主研究所协助系列生产文件以生产文件为标准。小批试生产评审通过后由文控接收项目最后文件并归档生产和市场反馈的《生产信息反馈表》《市场信息反馈表》明确无须归档它们的价值是驱动下一轮产品改善而不是进档案室。4. IPD落地避坑与常见问题排查评审流于形式和归档过重的五个现场4.1 现象决策评审会开成了进度通报会现象概念阶段决策评审会开了两个小时汇报的全是我们做了市场调查、写了分析报告、完成了方案设计最后决策人问了一句你们觉得行不行没人能给出量化结论。原因评审前没有按该阶段应有输出项是否齐全、结论是否明确来核对。汇报人把评审当工作汇报决策人把评审当知情会。解决把评审关注点从做了什么转为是否满足进入下一阶段的条件。概念阶段决策评审只回答三个问题市场可行性结论是什么、技术可行性结论是什么、风险分析和财务评估后的结论是什么。三个问题都明确写进《项目概念阶段决策评审报告》才算通过。我在内部推流程时会指定人在评审前把报告里这三个问题圈出来会上只讲结论讲不清就不过。4.2 现象文件归档把所有过程文件都收进档案库现象文控人员收到项目组移交的几十份文件连《项目组工作计划》《项目分解工作计划》都归档进系统文件柜塞满后来要查的人根本不知道去哪翻。原因对过程文件不归档的规则理解不到位总觉得多留一份没坏处。解决严格按照集成文件原则归档。市场可行性分析报告是市场调查报告、市场分析报告、市场业务规划和计划书的集成件归档只收集成件技术可行性分析报告同理。项目组计划和分解计划是过程文件明确不归档。操作上项目启动时就让文控团队拉一张档案包清单把要归档的文件名列死项目做完照着清单收清单外的不收。4.3 现象所有项目共用一个全流程模板现象公司统一上线了IPD流程模板三类项目都走同一套立项加概念加规划加设计验证的流程结果小项目被各种调查报告拖了两个月市场驱动的项目又觉得决策太快没摸清需求。原因立项时没有做驱动分类或者做了分类但流程模板里没有分类分支照旧全流程走。解决立项评审用十二项特征做驱动分类结论写进项目建议书。只有目标用户、项目、竞争环境、目标产品、技术可行性等大部分特征清晰的项目才有资格裁剪概念阶段。分类表贴在评审会议室每次立项先过一遍再谈计划从小处养习惯。4.4 现象中试阶段大量返工进度整体失控现象原型机测试通过了里程碑计划上写着进入中试结果中试第一周就发现性能不达标、装配干涉、可靠性测试过不了只能退回设计改版整个项目延期一个半月。原因原型机测试的门槛定得太松很多边界条件没覆盖团队为了赶进度带着已知缺陷进中试。解决把原型机测试报告当作进入中试的硬前置条件测试项没有全绿不允许发出《项目中试通知单》。具体做法是给测试组一张检查表把高低温、振动、EMC、长期老化这些系统级项目提前列进去原型机阶段就按这个表跑而不是等中试才压。宁可原型机阶段多花两周不要中试返工一个月。4.5 现象技术委员会评审时各小组只审自己那一块现象评审会开了设计组说电路没问题品质组说按现有标准能过市场组没提意见生产组不说话结果量产时工艺装配出大问题。原因技术委员会各小组职责没有在评审前对齐没有指定谁是本次评审的牵头评审组评审结论没有汇总责任人。解决按评审类型定牵头组职责落到委员会名单里。决策评审和设计确认由技术组承担管理、组织和协调职责市场可行性由市场组评审技术评审、原型机评审由设计组牵头中试评审由品质组牵头生产评审由生产组牵头。每次评审通知写明牵头组和参与组评审报告由牵头组汇总结论这个改动几乎零成本评审效果立竿见影。5. 把通用流程变成自己的门禁表用一张表管住阶段进出和归档这套PPT里最有迁移价值的东西是每阶段工作流程、工作指引及说明、对应文件、文件规范四栏结构。我做项目流程落地时会把它转成一张授权评审门禁表挂在共享文档里项目从立项到量产全程按这张表走。阶段进入条件输出归档文件评审牵头组评审产出立项合理化建议经研究所初审项目建议书、组建项目组通知研究所及决策层决策通过或终结概念概念任务书加总体工作计划市场可行性报告、技术可行性报告、风险分析、决策评审报告技术组、市场组是否进入规划规划规划任务书加调整后的总计划技术规格、结构化技术方案、关键技术明细、决策评审报告设计组是否进入设计验证设计验证设计任务书原理图、PCB、BOM、原型机测试报告、中试评审报告设计组牵头品质组做中试评审是否进入小批试生产生产销售生产评审通过试生产总结报告、新产品信息发布、取证申请生产组发布与量产门禁表里的输出归档文件列直接对应PPT里只需要集成文件归档的规则。我会把归档文件单列一列和过程文件分开标注项目结束时文控按表收研发按表交不再有到底要不要归档的口头争论。这张表不需要软件系统在线表格就能跑通。每个阶段评审前项目经理把对应行的文件清单拉出来逐项核对有没有交付评审通过才能往下一行挪。这个习惯逼着项目往前走的每一步都留痕也逼着每个人在评审前把该交的东西交齐。一个进阶用法门禁表要跟费用里程碑挂在一起。规划阶段的决策评审除了技术结论还必须同步确认一条费用基线设计验证阶段的原型机和中试各挂一笔款项。这样财务介入项目的时间点自然有了依据不用每次只听PM口头说项目没钱了。提示团队规模不大时评审牵头组可以和阶段负责人合并不必单独设岗但牵头责任必须写进评审通知否则又会回到各审各的。从第一次牵头搭研发流程到现在我最深的感受是流程落地最大的敌人不是流程太复杂而是没人把它当一套可执行的决策门禁。从那以后我每次给团队导入IPD流程都会强制自己先做驱动分类、再定阶段门禁、最后定归档清单把这张表跑通了再考虑上不上工具系统。希望帮到你。本文还有配套的精品资源点击获取
返回列表