惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog RSS Feed
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Google Online Security Blog
Google Online Security Blog
Hugging Face - Blog
Hugging Face - Blog
博客园 - Franky
Last Week in AI
Last Week in AI
MongoDB | Blog
MongoDB | Blog
T
Tailwind CSS Blog
云风的 BLOG
云风的 BLOG
Vercel News
Vercel News
博客园 - 三生石上(FineUI控件)
腾讯CDC
The GitHub Blog
The GitHub Blog
V
Visual Studio Blog
N
News | PayPal Newsroom
M
MIT News - Artificial intelligence
C
CERT Recently Published Vulnerability Notes
Apple Machine Learning Research
Apple Machine Learning Research
雷峰网
雷峰网
A
Arctic Wolf
The Cloudflare Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
C
Cyber Attacks, Cyber Crime and Cyber Security
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
AI
AI
S
Security @ Cisco Blogs
aimingoo的专栏
aimingoo的专栏
Cloudbric
Cloudbric
爱范儿
爱范儿
罗磊的独立博客
Y
Y Combinator Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Attack and Defense Labs
Attack and Defense Labs
Webroot Blog
Webroot Blog
T
Threatpost
T
Threat Research - Cisco Blogs
Cisco Talos Blog
Cisco Talos Blog
Recorded Future
Recorded Future
Security Latest
Security Latest
P
Proofpoint News Feed
www.infosecurity-magazine.com
www.infosecurity-magazine.com
I
Intezer
H
Heimdal Security Blog
Blog — PlanetScale
Blog — PlanetScale
S
Securelist
Forbes - Security
Forbes - Security
Application and Cybersecurity Blog
Application and Cybersecurity Blog
WordPress大学
WordPress大学
Engineering at Meta
Engineering at Meta
H
Hackread – Cybersecurity News, Data Breaches, AI and More

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
CMMI 1.3级认证下,包含了哪些管理体系?
老李与技术 · 2023-04-17 · via 人人都是产品经理

在日常业务中,项目团队有时需要借助一定指标体系来衡量或推动整体管理进程,其中,CMMI,即能力成熟度模型集成,就是这样的一套用于评估和提升组织能力与绩效的体系实践。那么,CMMI 1.3级认证下,包含了哪些管理体系?这些体系可以被如何应用于产品项目管理中?

一、CMMI是什么?

cmmi(Capability Maturity Model Integration,能力成熟度模型集成)是一套用于评估和提升组织能力和绩效的全球最佳实践。

cmmi最初是为美国国防部开发的,用于评估其软件承包商的质量和能力,后来扩展到了任何行业的任何组织,帮助它们理解自己当前的能力和绩效水平,并提供优化业务结果的指南。cmmi包括五个组成部分:模型、采用指南、系统和工具、培训和认证、评估方法。当它们一起使用时,它们提供了一个清晰而有效的路径来实现你的业务目标。

CMMI V2.0 版本是一个全球公认的软件、产品和系统开发优良实践过程改进模型,能够帮助组织提升绩效。CMMI V1.3 已于 2020 年 9 月 30 日停用。从 2020 年 10 月 1 日开始,仅接受 CMMI V2.0 评估。

CMMI2.0 版本产品套件包括成熟度模型、使用指南、系统与支持工具、培训、认证和评估方法。与前期版本一样,CMMI2.0 版本使用五个级别代表提高能力成熟度以改进业务绩效的途径。

新的 CMMI V2.0 模型具有四个类,12 个能力域和 25 个实践域。新的 CMMI 类别有四个,分别是 doing(对应1.3的工程类)、managing(对应1.3的项目管理类)、enabling(对应1.3的支持类)和 improving(对应1.3的过程管理类)。它们是相关域的分组,这些域在组织或项目的已定义活动中定义了改进性能的实践。

二、CMMI 1.3级认证下包含哪些管理体系?

cmmi3级认证表示组织已经实现了定义的过程,即过程已经被标准化、文档化、管理化,并且在整个组织内保持一致。cmmi3级认证下包含以下管理体系:

  1. 过程管理体系:包括组织级过程定义(OPD)、组织级过程焦点(OPF)和组织培训管理(OT);
  2. 项目管理体系:包括项目计划(PP)、项目监督与控制(PMC)、供应商协议管理(SAM)、集成项目管理(IPM)和风险管理(RSKM);
  3. 工程管理体系:包括需求开发(RD)、需求管理(REQM)、技术解决方案(TS)、产品集成(PI)、验证(VER)和确认(VAL);
  4. 支持管理体系:包括配置管理(CM)、过程和产品质量保证(PPQA)、测量与分析(MA)和决策分析与解决(DAR)。

1. 过程管理体系

1)组织过程定义(OPD)

组织过程定义(OPD)就是对软件过程进行定义,建立组织级别的通用过程资产库,以便于以后开发过程中,根据资产库的积累对标准组织级别的过程进行裁剪,适合具体项目情况。

实施方案:

  1. 建立一个过程资产库,即一个存放组织所有过程相关资产(如文档、模板、工具等)的集中位置,并确保其可访问性和安全性。
  2. 定义组织标准过程,即根据组织的业务目标和特点,定义一套适用于组织内各个项目或部门的标准过程,并遵循相应的规范和原则。
  3. 建立过程度量体系,即根据组织标准过程的特点和要求,确定需要度量和控制的过程属性(如效率、效果、成熟度等),并定义相应的度量方法和指标。

2)组织级过程焦点(OPF)

组织级过程焦点(Organizational Process Focus,OPF)是确定组织需要改进的过程领域和优先级的过程,包括建立过程管理委员会、收集和分析过程数据、制定过程改进计划等。

实施方案:

  1. 建立一个过程管理委员会,包括组织高层领导、过程改进专家、相关方代表等。
  2. 收集和分析过程数据,即使用适当的方法(如问卷、访谈、观察等)收集组织当前的过程状况和绩效,并使用适当的工具(如图表、表格、公式等)分析过程数据。
  3. 制定过程改进计划,即根据过程数据分析结果,确定组织需要改进的过程领域和优先级,并制定相应的改进目标、策略、资源等。

3)组织培训管理(OT)

组织培训管理(Organizational Training,OT)是提供组织成员所需技能和知识的过程,包括识别培训需求、制定培训计划、执行培训活动、评估培训效果等。

实施方案:

  1. 建立一个组织培训团队,包括培训经理、培训师、评估师等。
  2. 识别培训需求,即使用适当的方法(如问卷、访谈、测试等)识别组织成员在技能和知识方面的现状和差距,并确定培训的目标和对象。
  3. 制定培训计划,即确定培训的内容、方法、工具、资源、时间、地点等,并制定培训预算和评估标准。
  4. 执行培训活动,即按照培训计划,使用适当的方法(如讲座、演示、模拟、案例等)向组织成员提供所需的技能和知识,并监督和记录培训过程。
  5. 评估培训效果,即使用适当的方法(如测试、问卷、观察等)评估组织成员在技能和知识方面的提升情况,并根据评估结果进行反馈和改进。

2. 项目管理体系

1)项目计划(PP)

项目计划(Project Planning,PP)是建立和维护项目计划的过程,包括定义项目活动、估算资源需求和成本、建立进度和预算、识别项目风险并制定风险缓解计划等。

实施方案:

  1. 建立一个跨职能的项目计划团队,包括项目经理、客户代表、供应商代表等。
  2. 根据项目范围和目标,定义项目活动,并将其分解为可管理的任务。
  3. 根据任务之间的依赖关系,建立一个逻辑网络图,并确定关键路径。
  4. 根据任务的复杂度和难度,估算所需的资源(人员、设备、材料等)和成本。
  5. 根据资源可用性和约束条件,建立一个合理的进度计划,并确定里程碑和交付物。
  6. 根据进度计划,建立一个详细的预算,并考虑预留金和变更控制。
  7. 根据项目特点和环境因素,识别潜在性项目风险,并评估其可能性和影响。
  8. 根据风险评估结果,制定风险缓解计划,并分配责任人和资源。
  9. 将项目计划与相关方沟通并获得批准,确保计划的可行性和一致性。
  10. 定期审查和更新项目计划,根据实际情况和变更请求进行调整,并记录变更历史。

2)项目监督与控制(PMC)

项目监督与控制(Project Monitoring and Control,PMC)是监督项目执行情况,并采取必要的纠正措施的过程,包括收集和分析项目数据、比较实际与计划的偏差、识别问题和风险、实施变更控制、报告项目状态和绩效等。

实施方案:

  1. 建立一个有效的项目监控和控制系统,包括定义数据收集方法、频率、格式、责任人等。
  2. 定期收集和分析项目数据,包括范围、进度、成本、质量、风险等指标。
  3. 比较实际与计划的偏差,并确定其原因和影响。
  4. 识别问题和风险,并采取相应的纠正或预防措施。
  5. 实施变更控制过程,包括记录、评估、批准、通知、执行、验证等步骤。
  6. 报告项目状态和绩效,包括使用图表、表格、仪表盘等可视化工具,向相关方提供及时、准确、完整的信息。

3)供应商协议管理(SAM)

供应商协议管理(Supplier Agreement Management,SAM)是管理与供应商之间的协议的过程,包括选择供应商、建立协议条款和条件、监督供应商绩效、处理协议问题等。

实施方案:

  1. 建立一个供应商协议管理团队,包括采购经理、合同经理、质量经理等。
  2. 根据项目需要,确定外包范围和标准,并编制采购计划,并确定潜在的供应商。
  3. 选择供应商,即根据供应商的资质、信誉、报价、交付能力等因素,进行评估和比较,并确定最佳的供应商。
  4. 建立协议条款和条件,即与供应商协商并确定协议的目标、范围、责任、交付物、验收标准、付款方式、变更控制、争议解决等内容,并签署正式的协议文件。
  5. 监督供应商绩效,即定期收集和分析供应商的进度、成本、质量等数据,并与协议要求进行比较,评估供应商的满意度和风险。
  6. 处理协议问题,即及时识别和沟通协议中出现的问题,并采取相应的纠正或预防措施,如变更请求、索赔、终止等。

4)集成项目管理(IPM)

集成项目管理(Integrated Project Management,IPM)是从组织的标准过程集中裁剪得到集成的已定义过程,并以此为依据建立并管理项目以及相关干系人的参与。

实施方案:

  1. 了解组织的标准过程集:在实施IPM之前,需要了解组织的标准过程集,以便从中裁剪得到集成的已定义过程。
  2. 建立项目已定义的过程:通过裁剪组织的标准过程集,建立项目已定义的过程。这一步需要考虑项目的具体需求和特点。
  3. 管理项目:使用项目已定义的过程来管理项目。这包括使用项目计划、影响项目的其他计划以及项目已定义的过程来管理项目。
  4. 建立团队:建立旨在达成项目各项目标的团队。这包括确定团队成员、分配角色和职责以及建立团队沟通机制等。
  5. 协调相关干系人:在项目期间,需要协调相关干系人,使他们关注的事项得以识别、考虑并在适当的时候得到处理。
  6. 使用组织级过程资产并为其做贡献:使用组织级过程资产来支持项目管理,并为组织级过程资产做出贡献。

5)风险管理(RSKM)

风险管理是管理项目风险的过程,包括识别风险、分析风险、规划风险应对策略、实施风险应对策略、监控风险等。需要与其他过程域(如项目计划、项目监督与控制等)协同工作,以确保项目能够有效地应对风险。

实施方案:

  1. 建立一个风险管理团队,包括项目经理、风险经理、相关方代表等。
  2. 识别风险,即使用适当的技术(如头脑风暴、检查表、假设分析、风险分解结构等)识别项目中可能发生的不确定事件或条件,并记录在风险登记册中。
  3. 分析风险,即对每个风险进行定性或定量分析,评估其可能性和影响,并确定其优先级。
  4. 规划风险应对策略,即根据风险的性质和优先级,制定相应的应对策略(如规避、转移、减轻、接受等),并分配责任人和资源。
  5. 实施风险应对策略,即按照规划好的策略,对风险进行应对或控制,以降低风险的负面影响或增加风险的正面影响。
  6. 监控风险,即定期收集和分析风险数据,评估风险状态和趋势,并根据实际情况更新风险登记册和应对策略。

3. 工程管理体系

1)需求开发(RD)

需求开发是开发客户需求的过程,包括识别需求来源、定义需求属性、建立需求层次结构、分配需求优先级等。

实施方案:

  1. 建立一个需求开发团队,包括业务分析师、系统分析师、客户代表等。
  2. 识别需求来源,即确定影响需求的各种因素(如客户、用户、法规、竞争对手等),并获取相关信息。
  3. 定义需求属性,即为每个需求定义其标识符、名称、描述、类型(功能或非功能)、来源、状态等属性。
  4. 建立需求层次结构,即将需求按照不同的抽象层次(如业务需求、用户需求、系统需求等)进行分类和分解,并建立父子关系。
  5. 分配需求优先级,即根据需求的重要性和紧迫性,为每个需求分配一个优先级(如高、中、低等),并考虑需求之间的依赖关系。

2)需求管理(REQM)

需求管理是管理需求的过程,包括获取客户需求、分析需求可行性和一致性、建立需求基线、跟踪需求变更等。

实施方案:

  1. 建立一个跨职能的需求管理团队,包括客户代表、业务分析师、系统分析师等。
  2. 使用适当的技术(如访谈、问卷、观察等)获取客户需求,并记录在需求规格说明书中。
  3. 分析需求的可行性(是否能够实现)、一致性(是否有矛盾或冲突)、完整性(是否覆盖了所有方面)、可验证性(是否能够验证)等属性,并解决需求问题。
  4. 建立需求基线,即经过相关方批准的需求集合,并将其作为后续开发和测试的依据。
  5. 跟踪需求变更,即记录、评估、批准、通知、执行、验证等步骤,并更新需求基线。

① 需求验证

需求验证是验证客户需求是否正确和完整的过程,包括评审需求文档、执行需求测试、获取客户反馈等。

实施方案:

  1. 建立一个需求验证团队,包括业务分析师、系统分析师、测试工程师、客户代表等。
  2. 评审需求文档,即使用适当的技术(如检查单、同行评审等)检查需求文档是否符合规范和要求,并发现需求文档中的错误或问题,并进行修改或补充。
  3. 执行需求测试,即使用适当的方法(如原型、模拟、场景等)测试需求是否能够满足客户的期望和目标,并检查需求是否可行、一致、完整、可验证等。
  4. 获取客户反馈,即向客户展示需求文档和测试结果,并征求客户的意见和建议,并根据客户的反馈进行调整或确认。

3)技术解决方案(TS)

技术解决方案是设计和开发系统的过程,包括选择设计方法、定义系统架构、设计系统组件、实现系统功能等。

实施方案:

  1. 建立一个技术解决方案团队,包括系统工程师、软件工程师、硬件工程师等。
  2. 选择设计方法,即根据项目特点和需求,确定使用何种设计方法(如面向对象、结构化、模块化等),并遵循相应的设计原则和规范。
  3. 定义系统架构,即确定系统的整体结构和组织方式,并定义系统的主要功能模块和接口。
  4. 设计系统组件,即对每个功能模块进行详细的设计,包括定义输入、输出、处理、存储等,并使用适当的工具(如流程图、数据字典、类图等)进行描述和说明。
  5. 实现系统功能,即根据设计文档,编写相应的代码或配置相应的硬件,以实现系统的功能,并进行单元测试和集成测试,以检查代码或硬件是否符合设计要求。

4)产品集成(PI)

产品集成是将系统各个部分组装在一起并验证其正确性的过程,包括建立集成环境、执行集成测试、获取客户验收等。

实施方案:

  1. 建立一个产品集成团队,包括系统工程师、测试工程师、客户代表等。
  2. 建立集成环境,即准备好集成所需的硬件、软件、网络等资源,并确保其正常运行和兼容性。
  3. 执行集成测试,即按照预先制定的集成测试计划和用例,将系统各个部分逐步组装在一起,并进行功能测试、性能测试、安全测试等,以检查系统是否符合需求和规范。
  4. 获取客户验收,即向客户展示集成后的系统,并征求客户的意见和建议,并根据客户的反馈进行调整或确认。

5)验证(VER)

验证是确认系统是否满足用户需求和预期效果的过程,包括制定验证计划、执行验证活动、报告验证结果等。

实施方案:

  1. 建立一个验证团队,包括测试工程师、用户代表、质量经理等。
  2. 制定验证计划,即确定验证的目标、范围、方法、标准、资源等,并编制验证用例和验收标准。
  3. 执行验证活动,即使用适当的方法(如用户测试、场景测试、操作测试等)验证系统是否能够满足用户需求和预期效果,并记录验证数据和问题。
  4. 报告验证结果,即分析验证数据和问题,并确定验证的结论和建议,并使用适当的工具(如图表、表格、仪表盘等)向相关方报告验证结果。

6)确认(VAL)

确认是确认系统是否符合合同或协议要求的过程,包括制定确认计划、执行确认活动、报告确认结果等。

实施方案:

  1. 建立一个确认团队,包括测试工程师、客户代表、合同经理等。
  2. 制定确认计划,即确定确认的目标、范围、方法、标准、资源等,并编制确认用例和验收标准。
  3. 执行确认活动,即使用适当的方法(如合规性测试、审计测试、验收测试等)确认系统是否符合合同或协议要求,并记录确认数据和问题。
  4. 报告确认结果,即分析确认数据和问题,并确定确认的结论和建议,并使用适当的工具(如图表、表格、仪表盘等)向相关方报告确认结果。

4. 支持体系

1)配置管理(CM)

配置管理是管理项目或产品的配置项(如文档、代码、硬件等)的过程,包括识别配置项、建立配置基线、控制配置变更、审计配置状态等。

实施方案:

  1. 建立一个配置管理团队,包括配置经理、配置管理员、配置审核员等。
  2. 识别配置项,即确定项目或产品中需要被管理的配置项,并为每个配置项定义其标识符、名称、版本等属性。
  3. 建立配置基线,即经过相关方批准的配置项集合,并将其作为后续开发和测试的依据。
  4. 控制配置变更,即记录、评估、批准、通知、执行、验证等步骤,并更新配置基线。
  5. -审计配状态,即定期检查配置项是否符合配置基线,并报告审计结果和问题。

2)过程和产品质量保证(PPQA)

过程和产品质量保证是提供对过程和产品质量的保证的过程,包括建立质量标准和度量体系、执行质量审核和检查、报告质量结果和问题等。

实施方案:

  1. 建立一个过程和产品质量保证团队,包括质量经理、质量审核员、质量检查员等。
  2. 建立质量标准和度量体系,即根据客户需求和组织目标,确定过程和产品需要满足的质量标准(如规范、要求等),并定义相应的质量度量方法和指标(如缺陷率、合格率等)。
  3. 执行质量审核和检查,即使用适当的方法(如检查单、同行评审等)审核过程是否符合质量标准,并使用适当的方法(如抽样、测试等)检查产品是否符合质量标准,并记录审核和检查数据和问题报告质量结果和

问题,即分析审核和检查数据和问题,并确定质量的结论和建议,并使用适当的工具(如图表、表格、仪表盘等)向相关方报告质量结果和问题。

3)度量和分析(MA)

度量和分析是收集、分析和使用项目或过程数据的过程,包括确定度量目标和指标、建立度量计划、收集和存储度量数据、分析度量数据、使用度量结果等。

实施方案:

  1. 建立一个度量和分析团队,包括度量经理、数据分析师、统计专家等。
  2. 确定度量目标和指标,即根据项目或过程的目标和需求,确定需要度量的属性(如进度、成本、质量等),并定义相应的度量方法和指标(如工期偏差、成本偏差、缺陷密度等)。
  3. 建立度量计划,即确定度量的内容、方法、工具、资源、时间、地点等,并制定度量预算和评估标准。
  4. 收集和存储度量数据,即使用适当的方法(如抽样、测量、记录等)收集项目或过程的数据,并使用适当的工具(如数据库、电子表格等)存储和管理数据。
  5. 分析度量数据,即使用适当的方法(如图表、表格、公式等)分析数据,并识别数据中的模式、趋势、异常等,并确定其原因和影响。
  6. 使用度量结果,即根据分析结果,提出改进建议或决策依据,并向相关方报告或展示度量结果。

4)决策分析和解决方案(DAR)

决策分析和解决方案是分析并解决项目或过程中出现的问题或决策的过程,包括识别问题或决策、定义评估标准、生成可选方案、评估可选方案、选择最佳方案等。

实施方案:

  1. 建立一个决策分析和解决方案团队,包括项目经理、问题解决专家、相关方代表等。
  2. 识别问题或决策,即确定项目或过程中需要解决的问题或需要做出的决策,并定义其背景和目标。
  3. 定义评估标准,即确定用于评估可选方案的标准(如成本、时间、质量等),并为每个标准赋予一个权重。
  4. 生成可选方案,即根据问题或决策的特点,生成若干个可能的解决方案或决策选项,并描述其优缺点。
  5. 评估可选方案,即根据评估标准,对每个可选方案进行定性或定量分析,并计算其得分或排名。
  6. 选择最佳方案,即根据评估结果,选择得分最高或排名最前的方案作为最佳方案,并向相关方报告或展示选择过程和结果。

本文由作者 @老李与技术 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。