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

推荐订阅源

Stack Overflow Blog
Stack Overflow Blog
博客园 - Franky
MyScale Blog
MyScale Blog
Jina AI
Jina AI
B
Blog
Microsoft Security Blog
Microsoft Security Blog
T
Troy Hunt's Blog
博客园_首页
T
Threatpost
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
L
Lohrmann on Cybersecurity
GbyAI
GbyAI
T
Tenable Blog
B
Blog RSS Feed
S
Securelist
T
Threat Research - Cisco Blogs
P
Privacy International News Feed
P
Proofpoint News Feed
T
The Exploit Database - CXSecurity.com
H
Hackread – Cybersecurity News, Data Breaches, AI and More
量子位
博客园 - 三生石上(FineUI控件)
大猫的无限游戏
大猫的无限游戏
雷峰网
雷峰网
C
CXSECURITY Database RSS Feed - CXSecurity.com
罗磊的独立博客
AWS News Blog
AWS News Blog
V
V2EX
宝玉的分享
宝玉的分享
J
Java Code Geeks
小众软件
小众软件
Spread Privacy
Spread Privacy
腾讯CDC
Google Online Security Blog
Google Online Security Blog
月光博客
月光博客
V
Visual Studio Blog
The Hacker News
The Hacker News
C
CERT Recently Published Vulnerability Notes
Project Zero
Project Zero
Know Your Adversary
Know Your Adversary
T
The Blog of Author Tim Ferriss
Last Week in AI
Last Week in AI
Apple Machine Learning Research
Apple Machine Learning Research
NISL@THU
NISL@THU
C
Check Point Blog
Webroot Blog
Webroot Blog
D
DataBreaches.Net
Cloudbric
Cloudbric
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
IT之家
IT之家

人人都是产品经理

为什么你的产品找不到差异化?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混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
不要“宠坏”客户:谈项目范围管理
Smile · 2022-09-08 · via 人人都是产品经理

成为一个靠谱产品经理,必然要做好项目范围管理,这既是对项目团队的负责,也是对客户的负责。为什么这么说,范围管理又有哪些方法路径?一起跟着这篇文章来了解吧,希望对你有帮助。

在一位产品经理的工作生涯中,只服务于一款产品并不常见。反而在大多数时候,很多产品或服务是以项目的形式进行交付的。这就要求我们在工作过程中熟练掌握项目管理的方式方法,并将项目管理理论与产品经理工作实际结合起来。

下面我将从项目伊始的范围管理开始,带你领略互联网行业的项目管理,希望籍此你也能掌握一定的方法论并运用到往后的工作中去。记住,只要你想完成你手头的项目,无论你和客户的关系多么亲密,不要“宠坏”他们。

一、什么是项目范围

在日常工作生活中,评判一个人是否靠谱,有两个很重要的评判因素“边界感”和“分寸感”。做人做事没有边界感,从小的方面看容易冒犯他人,让自己显得粗鲁莽撞;从大的方面看也容易越俎代庖,干出不合规矩的事情。而缺乏分寸感,就会对事情的轻重缓急拿捏不清,重要的事情不做,反而在无关紧要的小事上钻牛角尖。

项目的范围,其实就是项目的“边界”和“分寸”。项目范围定义了哪些工作应该包含在项目内,哪些不应包含在项目内。做好项目范围管理,就是确保做且只做必要的事情,这些事是成功完成项目所不可或缺的。简言之,能用6个包子填报肚子,就绝不吃第7个。

项目的范围可以从两个层面进行拆分理解:用户需求和项目工作。用户需求,就是用户要求产品所必备的功能及特性;项目工作,就是为使产品能满足要求,所必须完成的工作。举个例子,把你自己当作“产品”,把追女孩儿当作一个项目来操盘。

你心目中的白月光对理想男友的要求是年少多金、风趣幽默、颀长健硕、博闻强识……而你为使自己尽可能靠近此标准,就开始健身、看书、交际、搞钱,最终你成功抱得女神归,这就是一个成功的项目。而如果你一不小心逼自己成为亿万富翁,远远超出女神的要求并导致对方自惭形秽而更加疏远你,那恭喜你找到了更优秀的自己,但很显然操盘了一个“失败”的项目。

控制客户预期,把握好用户需求,将其梳理为具体的功能要点和参数特性,最终落实为项目团队具体的行动。这就是项目范围管理的本质。

二、范围管理的意义何在

现代社会的各类组织,小到部门、小组,大到集团、工会,都是由“人”组成的有机体,都在积极的吸收外界能量,消化为自身成长的养分。因此,花最少的钱干最优的事,一直是一个组织做事的底层逻辑。

项目范围定义不清,往往是导致项目失败的首要原因。在启动一个项目时,如果不能对项目要做的事情定义清晰,就是为日后项目交付时的推诿扯皮埋下伏笔。项目的范围管理是制定项目计划,做好进度把控的关键基础。一个项目没有做好范围管理,只会导致摊子越铺越大,最终无以为继,虎头蛇尾。

权责不清是大家在工作中最怕碰到的。这不仅仅是谁多做谁少做的问题,更会涉及到工作环节的衔接和工作成果的交接,进而影响项目的整体进度。

打个比方,小A是终端嵌入式开发,小B是后台开发,两个人都觉得制定接口协议是对方应该主导的事情,都没对这件事上心,最终导致临近交付时才发现终端没有与后台联调,影响交付进度。

而如果做好了项目范围管理,就能够确定项目的具体工作任务,有助于清楚的责任划分和任务分派。像小A和小B的这种事情就不会再发生了。

对于项目发起方和项目经理而言,成本一直是敏感且重要的话题。一个项目在立项之初,就需要清晰准确的估算出所需投入的成本、所需协调引入的资源,以及所需的时间。

估算成本不是拍脑袋,需要准确识别设备设施、人员配备、工作工时等,这些都和项目的具体工作息息相关。比方说研发一款智能手表,需要使用示波器等仪器测试硬件PCBA,如果在事先不明确这部分工作,就容易漏掉这些仪器,进而导致固定投入估算不清。

总的来说,不对项目范围进行清晰的定义,就无法明确项目的工作具体范围和具体内容,就无法提高成本、时间和资源估算的准确性。

工作中我们常常遇到下图所示的情况,客户要求三个月做一幢豪宅,给了能做几间平房的钱,我们用一年的时间反复推倒重建,最后交付了一个公厕。如果你读到这里能够会心一笑,那证明你已经是有过几年项目经验的PM了,有一定经验,但不多。

这个读来令人捧腹的例子,向我们深刻揭示了约束项目范围的三大要素:进度、成本、质量:

  • 要求三个月完成,最终拖延一年。这是进度;
  • 给了几间平房的钱,实际因为反复重修,超出预算,最终只交付了一间房。这是成本;
  • 要求豪宅,最终公厕。这是质量

做项目不是做慈善,哪怕你为了梦想参与到项目里来,也不能罔顾客观实际。想要兼顾快捷、低廉、优质,那这个项目是不可能成功的。如果有客户向你提出这等非分之想,不妨把这张图发给他。

三、范围管理的方法路径

项目范围管理的方法论就三个字——“做减法”。我们做且只做能成功完成项目所需的全部工作。围绕这个核心理念,我们将项目范围管理拆分成六个步骤。

  1. 规划范围管理:指导团队如何管理项目范围,需制定项目范围管理计划
  2. 收集需求:挖掘真实需求,建立需求与可交付成果及项目目标间的对应关系
  3. 定义范围:制定详细的项目范围说明书,明确验收标准
  4. 创建WBS(工作分解结构):明确范围基准,分解工作内容,关联唯一责任人
  5. 确认范围:明确工作结果是否可以接受,完成验收
  6. 控制范围:管理实际的范围变更。这一过程贯穿项目始终

要怎么控制好客户预期,如何把握客户的真实需求,这些需求如何落地为具体可执行的工作?带着这三个疑问,我们往下看。

1. 规划范围管理

在初创型企业或者传统家族式企业,做项目很多时候都是“一言堂”,老板说做那就做,老板说加那就加。可惜如马斯克或者乔布斯那样的天才产品经理极度少见,你的老板极大概率并非这样的天才。很多时候,这种一言堂会把整个项目带进沟里。

规划范围管理这个步骤,更像是为项目,甚至是为企业制定标准。这一过程的输出,也就是“项目范围计划”,不仅是项目工作开展的指导文件的一部分,更能成为企业经验的一部分,变成组织过程资产。

一般来说,规划范围管理这一步需要进行如下活动:

1)制定详细的范围说明书

这一步骤在很多时候和项目可行性分析、搭建需求池、建立项目章程等步骤合在了一起。只要能详细清晰的表达出项目范围,不用拘泥于形式。

2)确认从详细的范围说明书内创建WBS(工作分解结构)的流程方法

一般而言,每个公司有其通用的一套规则,项目上沿用即可。若要建立一套全新的流程,则项目经理或产品经理应对产品研发的整个流程有着非常清晰的认知,知道哪个阶段应该做什么、需要哪些前置输入,需要哪些产出。

3)确认批准和维护WBS的流程方法

WBS建立好后应如何评审,谁来参与评审,这些都要提前定义清楚。此外,应确认由哪个岗位来维护WBS,大点的团队一般会专门设立项目管理工程师这个岗位,简称“项管”,来对WBS的整体排期和进度进行追踪,小点的团队就只能产品经理或项目经理兼任这个角色。

4)确认对已完成的项目可交付物进行正式确认和接受的流程方法

项目的阶段性产出如何进行验收,谁来验收,验收的标准是什么?千人千面,适合就好。

5)明确如何对详细的项目范围说明书申请变更

一般范围说明书定义清楚后不会再改动,若的确需要变更,那一般都是非常重大的改动。需明确在发生哪些突发情况时,才允许对项目范围说明书进行变更,这一过程需要严格谨慎。

四、收集需求并挖掘真实需求

不可否认的一点是,无论对谁来说,收集需求并挖掘出真实需求都是一件很难的事情。

  • 首先,你的客户有着与你不同的专业背景,你们很可能并非同一行业。假设你们在为一家医院打造业务平台,你用计算机专业的思维,去理解一些医疗行业从业者的诉求,往往鸡同鸭讲,互相get不到点;
  • 其次,基于每个人逻辑思维与表达能力的不同,语言的表达有其固有的损耗。客户想的是100,传达给你的是60,你转达给开发的是40,开发能理解并做出来的不到20,这是很常见的态势;
  • 最后,某个人在某一时刻的想法,往往只是灵光乍现,并非真实需求。客户本质上是一群人,且你的甲方和最终用户往往属于两个不同群体。但凡是群体,就不会有完全统一的声音。如果在收集需求时只考虑某个人的声音,就必然会造成需求图谱的失真。

收集需求的核心原则,为“具体化”、“书面化”、“可测量”。需求的模糊程度越低,执行时产生偏差的可能性就越低;需求描述的越具体,验收时发生扯皮的情况就越少。一千个人眼中有一千个哈姆雷特,为尽可能的减少分歧,在需求收集阶段就要尽可能做到明确、具体,可测量,并记录在文档内归档。

1. 收集需求和梳理需求

  • 访谈:和客户直接交谈,来获取信息。信息失真小,但效率较低;
  • 问卷调查:书面问卷,受众填写。信息失真大,效率较高
  • 会议研讨:把行业专家和项目相关方都聚集到一起,大家坐下来对产品需求进行集中讨论与建议,了解大家对所提议产品、服务或成果的期望和态度。信息失真小,效率高,对组织能力有一定要求;
  • 群体创新:头脑风暴,再用思维导图等形式将大家的想法做分类梳理。一般适用于创新类或演示类的项目;
  • 群体决策:在已搜集到的需求基础上,通过一致同意原则或相对多数原则来决定具体执行哪些需求;
  • 标杆对照:抄竞品;

收集需求的下一步就是梳理需求,需要建立需求与项目可交付成果以及项目目标间的对应关系。可以借用OKR的概念对这个动作进行解释。O即Objectives,核心目标;KR即Key Results,关键成果。在需求收集这个环节,项目目标就是我们的O,可交付成果即为KR,需求即为完成可交付成果所必须的步骤。需要确保所有的需求点,最终都是为达成项目目标而做的,与项目目标无关的需求要果断排除。

值得注意的是,并不是所有与项目目标关联的需求都需要项目组去满足,且需求是否被批准最终是由项目发起人决定的。在一个项目里,项目经理只是一个被授权调用资源的“打工仔”,项目发起人才是“幕后Boss”。

2. 输出需求跟踪矩阵

在很多互联网企业,产品经理往往会搭建一个需求池,服务的是一个长生命周期的产品。这个需求池和项目的需求跟踪矩阵有一定相似之处,可以对照理解。在项目需求跟踪矩阵中:

  • 首先需要明确项目的成本中心和项目背景、目标;
  • 其次以可交付成果为标杆进行需求的细化拆解;
  • 最终对需求进行详细描述,说明预期效果,阐明可交付成果、对应责任人等

五、创建工作分解结构

收集、梳理需求并关联项目目标,是回答了“做什么事情”,“为什么要做这些事”,高屋建瓴的为项目成员指明了前进方向。但是我们既要仰望星空,也要脚踏实地,需要把项目目标拆解成每个成员具体该干的事情,才能把愿望落地,让项目接地气。回答好“怎么做这些事情”,是创建工作分解结构(WBS,Work Breakdown Structure)的核心所在。

1. 工作分解的意义

首先必须要说明的是,不是所有项目都必须按照项目范围管理的条条框框来执行,也不是只有严格遵循范围管理的方法论,项目才能成功。日常工作中,我们不能陷入教条主义。对于重难点问题攻关型项目,或者开创前人未有之道路的创新型项目,就不存在工作分解这一说了。大家都在摸着石头过河,谁也指导不了谁。这就带来工作分解这一步能正常执行的前提:必须得有一个人对项目的整个过程有着非常清醒的认知,有过相关经验,知道在什么时间点应该干什么事情。项目经理就起着这样的作用。

正如大家都喜欢“跟我上”而非“给我上”的领导,正确执行工作分解能带来如下好处:

  • 可以建立完整的项目保证体系,便于执行和实现项目目标;
  • 通过工作分解结构,项目相关人员对项目一目了然,明白各自所处的位置、所要做的事情和所需承担的责任。方便后续进行费用、进度、绩效的跟踪;
  • 能够明确项目各方面的界限,便于责任划分和落实;
  • 为项目沟通提供依据,可用于与项目干系人沟通项目状态,提高项目团队整体沟通效率;

2. 工作分解的方法

不同组织创建工作分解结构的方法不同,有两个常见的分解工作的维度:

  • 基于项目的生命周期的各阶段。如一个企业信息管理系统的交付类项目,往往按照需求调研——分析设计——程序设计——软件测试——产品验收交付的流程来进行,需要针对各阶段的主要工作进行拆解,如分析设计阶段,可拆解为数据库设计、系统接口设计、业务功能设计等;
  • 基于可交付成果。同样以企业信息管理系统为例,可以简化为OA系统、人事系统、营销系统、设备管理系统等多个版块,需要对各板块进行拆解。如人事系统版块可以拆解为职工管理、培训管理、党政管理等

在对大型项目进行工作分解时,除了具体的工作内容和责任人,还可能包含以下特定内容:

  • 编码标识。特定的序号,用于划分层级、进行区分;
  • 假设条件和制约因素。即执行此项工作的前提,及可能影响工作进度的因素;
  • 进度里程碑。完成此项工作的标志;
  • 所需资源。一般指软硬件外部环境,仪器设备等;
  • 成本估算。一般包含人力成本和直接材料成本等;
  • 质量要求
  • 验收标准

在工作分解结构里,往往会人为设置一些管理控制点,叫“控制账户”。可以理解为项目节点,在这个节点上需要对范围、成本、进度进行整合分析,并与预期效果进行比对,以明确项目进度和绩效。

在实际工作中,若有专门的项目管理工程师参与统筹,是可以尽量细致的对工作进行拆分的,在设定的项目节点也可以对项目进度及时复盘。若是人员配备不足,也可酌情减少拆解的力度。

我们在这里谈到什么是项目范围,管理好项目范围的意义何在,做好范围管理的基本路径等,核心内容就是确立了范围管理的方法论——“做减法”。谈到面对客户时,我们要合理控制客户预期,无论你和他们关系多么亲密,不能“宠坏”他们。

规划范围管理是常常被人忽视,却又极为重要的步骤,这往往决定了这个项目组的做事基调。靠谱的项目团队,一定会“把丑话说在前头”,并在往后的工作中严格执行。

正如“慈母多败儿”,做好项目范围管理既是对项目团队的负责,也是对客户的负责。成为一个靠谱的项目经理或产品经理,从控制好你的项目范围开始。

本文由 @Smile 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash ,基于 CC0 协议

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