项目管理总结2020
2021-02-20 13:55:00 11 举报AI智能生成
项目管理知识全览，含全部过程域的经验总结
作者其他创作
大纲/内容
角色转换
程序员转管理三大误区
误区 1:凡事恨不得事必躬亲
做程序员时，我的工作是高度可控的，我可以把每天的工作安排得井井有条。但在做项 目管理之后，我发现自己的产出全部依赖别人的工作，于是我会经常性地陷入一种抓狂的状 态，着起急来，甚至会忍不住冲上去，替别人做好人家本该做好的事情
对于团队长期的发展而言，这种行为的效率是最低的
如何影响他人去做好一件事呢
让人知道要做(Awareness)
单方面的工作交待和告知，停留在 浅层次的信息传达上，只是让人知道要做，但并不足以让人产生动力，去促成有效的行动
有动力做(Desire)
在把工作授权给别人时，对于动力(Desire)的关注尤为重要。讲清楚 为什么要做，为什么要现在做，获取理解及认同，激发团队的动力是项目经理成功授权工作 的关键
有能力做 (Ability)
项目成功关键路径上的核心能力缺失，是你作为项目管 理人员，要当作最高优先级的风险管理的事项
从外部引入相应的人才，是最直接有效的方式
除此之外，你还可以去积极争取短期借调、 内部转岗等
从长期来看，你还需要有意识地发现和投资那些团队中最有潜力的人，给他们 安排相应的工作辅导，开展有针对性的培训等，帮助项目组成员发展相应能力，让事情真正 落地
误区 2:追在别人屁股后面做监工
初转项目管理，经常会有种“赶鸭子上架”的无奈。通常情况下，我会在心里设 定一个目标，然后费尽心力地把大家往一处赶，但往往我赶得越是卖力，鸭子们就越是跑得 到处都是。
其实，项目经理最该做的，不是每天逐个人逐条事项的监督，而是要明确目标，建立机制， 并让这个机制运转起来，最终在项目组形成一种良性的秩序
比如，项目经理要带大家一起开启动会，清晰愿景目标，定义阶段里程碑和完成标准，接着 制定分段执行的计划，把事情的所有环节从头到尾捋顺了
项目经理要建立上下游协同的流 程规则，明确各个角色在整个过程中的职责，获得大家的认同和共识
项目经理还要建立站 会、周会等制度和模版，让进展和风险通过这些良好设计的信息渠道汇聚，借助规则和工具 来达到监控的目的
项目管理并非要让你成为监工，要始终依靠流程和规则来约束大家的行为
当成熟的秩序在团 队中形成之后，从日常琐事中解放出来的项目经理，就可以集中精力去做愿景驱动、激励团 队等更高层面的工作，真正做到变“赶”为“引”
误区 3:拿着锤子，看哪里都是钉子
案例分享
我曾经见过一位新官上任的项目经理，可能是因为终于得到施展的空间了，一上来就左突右 攻，恨不得把十八般武艺全都套上去，结果激起了许多不必要的麻烦
开站会也好，电子看 板也罢，本来都是好工具，但是如果引入过程不当或时机不对，会让团队产生抵触心理，最 终拿不到好的效果
看到项目中的问题，哪里都很想修理一下，这种心情我非常能理解
但是，你要知道的是， 每个项目的现有执行方式，都有它本身的背景和成因，不管现有方法是否先进，都是更加适 应本土环境的
回到刚刚说到的那位新官上任的项目经理，在我和他对照着以上这五个问题分析完之后，他 终于明白了问题到底在哪儿
在他的项目中，时间绝对是第一要素，拖延一天交付都是直接损失
在这样的情景下，团队对变更的容忍度很低，最头疼的就是客户的需求变更又很频 繁......实际上，变更的背后是对客户需求管理的失控，大家对这个痛点的改进要求非常迫 切，项目发起人也很是头疼
之前他看哪儿都是问题，眉毛胡子一把抓，现在经过梳理之后，他意识到自己应该找准变更 这个切入口，让大家看到切实的效果，其他的改进一步一步来
说干就干!他和发起人沟通 了自己改善变更的思路和方法，很快就得到了认可，而通过这些有效的改进，团队对他的信 任也与日俱增了
不要急于实践，你可以试着问自己几个问题：
在你的项目组中，时间、成本、质量、范围这几个因素，到底哪个更重要?哪些是允许 有一定调整空间的?
各个角色目前的痛点在哪儿?哪些是最先需要解决的?这些问题背后潜在的原因是什么？
团队对于这个痛点的改进是否有真实需要?需求的迫切程度如何?
你的老板或项目发起人对于项目管理以及你本人的定位是怎样的?关于这些问题与可能 的改进，你是否与其沟通过并达成了一致?
如果你打算引入新方法或工具，更适合用怎样的路径进行，是自上而下地全面推广，还 是自下而上地一步步优化呢?最有可能从哪个问题切入?
总结
从程序员走向项目管理，是从“左手习惯”到“右手习惯”的转变
其中，思维模式和行为习惯的转变，远比学会使用那些工具方法要有挑战得多
从管好自己的事，到管好别人的事，你需要有意识地避免 3 个误区
第 1 个误区是凡事都要亲力亲为
遇到事情时，你不要自己直接去做，而是要想办法驱动 他人去做好事情
在授权工作时，有三个层次，从让人知道要做，到让人有动力做，再到有 能力做
你需要讲清楚为什么要做，为什么要现在做，获取理解及认同，激发团队的动力， 同时为每个任务选择能力匹配的授权对象
第 2 个误区是追着别人做监工
做项目管理，不是要你变成监工，而是要你带领团队明确 目标，建立机制，并让这个机制运转起来，要始终依靠流程和规则来约束大家的行为
第 3 个误区是拿着锤子看哪里都是钉子
每个项目的现有执行方式，都有它本身的背景和 成因，你要与项目中的重要干系人加强沟通，理解前因后果，从项目和团队当前的真实痛点 出发，找到真正解决问题的方法和步骤
十大领域五大过程组
1、项目管理的历史
甘特图
美国一位名叫亨利·甘特的机械工程师
一张标明计划 与实际完成情况的图表
关键路径法（CPM）
美国的路易斯维化工厂
他们把检修流程精细分解后，竟然发现，只 要缩短最长路线上工序的工期，就能够缩短整个检修的时间
这就是至今项目管理工作者还 在应用的“关键路径法”，简称 CPM
“阿波罗”登月计划
让项目管理方法从此风靡全球
三大项目管理的研究体系
项目管理逐步标准化，国际上逐渐形成了三大项目管理的研究体系
欧洲的国际项目管理协会(IPMA)
美国项目管理协会(PMI)
英国的 PRINCE2 体系
2、什么是项目管理
精辟总结
项目管理就是变理想为现实，化抽象为具体的一门科学和艺术。
《项目管理知识体系指南》
项目是为创造独特的产品、服务或成果而进行的临时性工作
项目管理就是将各种知识、技能、工具与技术应用于项目活动，以满足项目的要求
指责定位
保目标，助决策，提效能，促协作
3、项目管理的十大知识领域
整合管理
如何实现整体最优？
范围管理
做什么？
时间管理
给多长时间？
成本管理
花多大代价？
质量管理
达到什么要求
人力资源管理
有多少资源？
沟通管理
如何沟通？
干系人管理
如何管理干系人？
风险管理
如何应对风险？
采购管理
有多少还要买？
应用案例
案例介绍
你的部门最近有大量新员工入职，同时业务发展涉及越来越多的跨部门合作，领导希 望你组织一场跨部门的篮球竞技活动，让大家以最快的速度熟悉起来
项目管理
干系人管理
分析干系方
在这个活动中，哪些人会是你的干系人?
项目发起人对活动的预 期效果是什么?
比如说增进团队的协作，提升凝聚力等
这个项目是否存在更多的潜在干系方，可以助力到活动的成功举办呢?
比如，经 过一番了解，你发现 HR 部门最近刚刚成立了团建组，很愿意为活动提供赞助，那么，这 时你需要思考，如何拿到这笔赞助?
HR 总监对于活动的诉求又是什么?
如何管理干系人
如何更好地管理干系人的期望和影响?
活动过程 中的各类决定，都需要谁来拍板?
干系人要以什么样的方式参与?
范围管理
分析完各方干系人的诉求，就可以进一步来划定项目交付的范围了
主要任务
搞清楚到底要做到哪些事，才能更好地达成各方的期望
比如，这次篮球赛的预期目标具体是什么?
是更关注活动的参与度和投入度？
部门之间的合 作交流？
还是活动的对外影响力?
你要确保围绕着预期目标来设计相应的活动方案，然后再 进一步确定活动前、活动中、活动后分别要完成的具体工作
进度管理
你要规划好阶段性步骤，同时明确每个里程碑的目标成果和时间安排
比如，活动的总工期是一个月，那么你可以分为四个阶段来进行:
第一阶段，启动项目并确认概要方案设计;
第二阶段，规划并落实人力和各项资源的投入;
第三阶段，确定具体的活动流程和详细分工，完成活动前的各项准备工作;
第四阶段，做好活动当天现场的统筹和运作。
成本管理
你要思考一下，活动预算有多少?资金什么时候到位?如何使用?
你要去关注整个预算中成 本最高的开销是什么
比如是一笔价格不菲的教练费
然后，你要判断这笔投入可能带来的 收益，也就是说钱是否用到了刀刃上?
总之，你要从全局视角去思考，如何更有效地管理项 目的各项投入，以达到更加匹配目标的预期效果。
质量管理
从这个角度来说，你需要先确定这次活动圆满成功的标准是什么？
现场参与人数
参与者满意度
管理者的满意度
对外传播效果
然后，以终为始，思考一下，你需要引入哪 些必要的流程和方法，以保障活动效果的达成。
资源管理
你要知道，公司内有哪些核心资源是可以使用的?
宣传渠道
设计人员
经费支持
另外，公司内部有哪些人可以作为支援活动的志愿者呢?公司可以提供活动所需的哪些 物品?
采购管理
确定了可以使用的公司资源以后，你要接着思考，还有哪些是需要外部采购?有哪些工作需 要外部人员支持?
如果经费受限，是否可以通过交换资源的方式，来获取更多的外部支持?
沟通管理
活动策划团队、执行团队分别通过什么方式来进行项目沟通?
与发起人和赞助方的沟通方式和频率是怎样的?
你如何保持团队内外项目信息的高效 传递，使用什么方式来同步进展?
风险管理
你要弄清楚哪些风险可能会妨碍这次篮球赛的成功举办
天气因素
场地因素
交通管制
赞助方经费紧张
物料供应延期
公司内外政策变化导致活动被喊停
业务压力大导致 兼职志愿者流失
整合管理
如何统筹全局，达到最优效果
4、项目管理的五大过程
PDCA循环
最早来自于质量管理领域
意思是做任何事情，都要 经过规划(Plan)、执行(Do)、检查 (Check) 和行动 (Act) 这四个步骤，又称戴明环
这四个步骤提供了一个简易的思考和做事框架
PMI 遵循 PDCA 的法则，将所有的项 目管理活动分成了五大过程组
注意
这个循环并不是运行 一次就结束了，而是周而复始、螺旋上升的
别看它很简单，实际上，越是简单的东西，就 越是普适!
五大过程组
1. 启动过程组(千里之行，始于足下)
启动过程组意味着正式开始一个项目，或者是开始一个项目中的新阶段，包括识别干系人和 制定项目章程两个子过程
启动过程组是最容易被忽略的过程组之一，越是持有结果导向的人，就越容易马上直奔主题去做，根本不管什么项目章程
我们在启动一个新项目或新阶段时，首先要建立项 目章程，并且通过启动会去公开确认
启动会
正式宣告一个新项目或新阶段的开始，公开确认项目章程，包括明晰各方干系人的期望和诉求，设定愿景目标和重要里程碑，确定责任分工和沟通机制等
涉及跨部门
项目经理要积极创造一个场合，邀请更高 的管理层出面，讲清楚项目的背景、目标和重要性
除此之外，启动会也是项目管理人员获 得公开授权的有效方式，可以让你之后的推进工作更容易开展
2. 规划过程组(运筹帷幄，决胜千里)
如果说启动是要明确目标，那么，规划就是要把愿景目标转化为可落地的行动方案和工作路线
你需要根据预期目标，明确项目范围，确定项目的里程碑阶段目标，为项目的执行做好各项准备
对于复杂项目
规划通常是一个渐进明晰的过程，近期的规划往往是最具体的，需 要拆分到具体版本和工作项
而远期的规划则相对比较模糊。随着收集和掌 握的信息逐渐增多，规划也要进一步动态细化，不断更新
3、执行过程组(言出必行，行之必果)
这个阶段重在整合资源，推进项目落地，完成项 目管理计划中确定的工作以实现项目目标
如果在启动和规划环节做好了，到了执行环节，项目经理反而会轻松一些
此时的工作更侧重于确保项目一直在正确的轨道上，确保各个环节按照规划进行，并且能够真正 做到位
4、监控过程组(审时度势，沉着应变)
执行并不意味着在任何情况下都要一成不变
当外界环境或内部要求发生变化时，项目管理 者也要审时度势，沉着应变，适时地调整各方，以更好地实现目标
怎么做到这一点
需要定期对项目的进展、范围、质量等进行跟踪和监控
识别目前的进 度与计划之间的偏差，从而快速准确地采取办法进行纠正和调整
5、收尾过程组(慎终如始，则无败事)
在这个阶段，你要交付项目成果，组织团队的回顾复盘，归档所有文档等组织过程资 产，正式结束一个项目或阶段
项目复盘
“复盘!复盘!复盘!”不管项目成功与 否，“趁热”复盘都是极为重要的一步
验尸会
不仅仅复盘正常结束的项目，对于那些中途被叫停的非正常“死 亡”项目也应立即复盘
这样的复盘通 常会带给我们很多有价值的信息和启示
5、互联网项目管理的职责定位
保目标、助决策、提 效能、促协作
保目标、助决策是要打通从战略到执行的闭环，提效能、促协作则是打通上下游 协同的闭环
从互联网业务情境来看
项目与项目之间的边界相互交叠在一起
产品需求就如同海浪一样，一波未平，一波又起，大浪中夹杂着小浪
除非产品下线，否则“造浪机”在整个产品的生命周期 中根本就不会停息
实际情况
对于大多数互联网产品而言，研发期和运营期是交织在一起的
并非像传统软件那 样，有个清晰的项目交付目标和时间周期
从项目管理的方法层面看
经典方法仍然是通用和普适的，只是你需要基于你的场景，找到对应颗粒度下的 PDCA 闭环管理方法
保目标、助决策
在从战略到执行的过程中，项目管理的两项职能是保目标和助决策，这形成了一个围绕目标驱动的闭环
把关键战役进行规划分解
首先，你要围绕组织绩效目标，定位出核心的 3~5 件要事， 即关键战役，把关键战役进行规划分解，拆到可交付可验收的里程碑，最后落地到版本 / 迭代的工作安排中
清晰而系统的反馈机制和平台
把执行中的进展状态、变更、风险等集中 呈现，以帮助管理者更好地进行优化和调整
比如，结合产出进度来调整业务策略，通过里 程碑状态信息来调整目标和规划的节奏，根据人力投入的分布，来优化整体的资源配置
提效能、促协作
提效能和促协作，本质上都是工作在上下游跨角色协同的这条线 上，链条越长，协同就越是复杂
提效能是要去关注和消灭团队中的低价值工作所引发的效能痛点
eg
假如测试 环境的部署耗时很长，这已经成为了整个团队的瓶颈，那你就要想办法通过技术的手段 实现自动化，从而为整条链条提速
促协作则是着眼于使用各种项目管理方法和工具，让高价值工作者可以更好地合作
eg
比 如，建立清晰有效的信息渠道和沟通机制，积极推动各角色达成共识等，实现全局价值 的最大化
项目管理知识地图.png
项目启动
识别项目中的四类干系人
在一个新项目刚刚启动时，干系人分析，可以说是最容易被漏掉的一个重要环节
干系人分析
指对项目干系人进行分析和归类，有针对性地规划管理其核心诉求和期望， 让干系人可以更好地参与项目，对项目产生积极影响，从而更好地保障项目目标的成功达 成
干系人分析的目的？
作为项目管理人员，你需要通 过积极的干系人管理，尽可能把反对的力量变成支持的力量，同时发掘和调动中间力量
该怎么做到这一点？
1、深入了解项目的现状
2、了解各方干系人对项目的期望和诉求
项目干系人分析目的.png
干系人分析表.png
干系人分类
按照在项目上的权力和利益相关度对干系人进行划分，可以把项目干系人分成四类
干系人的四象限分类图.png
高利益 - 高权力
项目发起人-Sponsor
项目发起人会定 义组织对项目的需求，为项目提供资金支持，并进行人员配备
了解项目的真正诉求至关重要
发起人所掌握的项目背景信息量肯定比你要大，所以，对发起人做一轮全面而深 入的了解，是非常有必要的
与项目发起人沟通问题列表.png
为了管理好之后的沟通，你还需要约定好你们之间的沟通频率和方式，以便在项目进 行的过程中做好实时同步
可以是每周用邮件同步项目的进展及风险问题
建立核心微信群实时交流
每个月至少进行一次深入面谈
或者，你们只是简单地达成约定:在你 需要支持的时候，随时发起，当日问题当日解决
高利益 - 低权力
这是与项目结果结果直接相关，但是对决策影响不大的一类人，广大的项目组成员就属于这个象限的典型代表
通过三类问题了解了解项目的规划和实施过程
高利益-低权利问题列表.png
这些痛点和渴望，会成为你在团队中促发改变的 有力抓手，帮助你找准突破点，集中发力
管理这类干系人的核心，就是要做到项目事项的随时告知，及时通报项目的进展和困难。
低利益 - 高权力
职能经理
在矩阵式组织结构中，职能经理是资源池的所有者，他们所管辖的团队通常覆盖多个项目或 项目群，这也使得他们与单个项目的利益相关度通常比较低，介入程度往往也很有限
但是，因为他们对资源的把控力很强，如果管理不好这类干系人，你的项目资源就很容易受到 影响
应用案例
案例背景
我曾经就碰到过这样的情况。有段时间，团队一再跟我抱怨，这个项目中的设计资源成了最 大的瓶颈，于是我决定去拜访一下那位传说中性格乖张、超难合作的设计经理
见面后的前半个小时，他一直在跟我抱怨:“项目进度压得太紧，我的很多设计师都累病 了;产品和开发对设计师们太不友好了，产品没有经验，连需求都说不清楚;开发实现得还 原度太低，问题一箩筐......”
我没有反驳他，而是把他的话一条条地记录了下来。半个小时之后，我给他看我记的内容， 耐心地跟他一一确认，他想要表达的是不是我所记录的意思。看到我认真的笔记，他的态度 明显缓和了。
经过一番梳理，我发现，他之所以排斥这个项目，是因为他觉得在这个项目中，设计师没有 太多发挥的空间。于是，我问他:“咱们设计团队今年最想做的事是什么?这个项目怎样才 能更好地支持你和你的团队呢?”这个问题瞬间打开了他的话匣子，他兴致高昂地跟我描绘 了他的期望。这次交流，让我们找到了更多深度契合的合作点。
随着合作的深入，这位经理从一个抵制者慢慢变成了项目的坚定支持者。他调动了资深的设计师来支持这个项目，并且主动发起了 Logo 和界面主风格改版的创意评选活动，把项目的设计品质提升了一大截，这给项目组带来了非常正向的影响
案例启发
要想让干系人的态度发生转变，最重要的就是弄清楚他抵制的原因
强烈的态度背后，一定反映了干系人对现状的某种认知
比如，这位设计经理抱怨的“这个项目没有太 多设计师可以发挥的空间”，这种认知未必是事实，但你一定不要急于反驳，而是不带评判 地去了解他的内心想法，通过积极聆听去建立信任
只有真正地理解了对方的逻辑，才有可能进一步对其施加影响
细化分类
根据对项目的认知态度，我们还可以把“低利益 - 高权力”的干系人再细分成以下 3 类，进行差异化管理
对项目的认知态度.png
反对者(红色部分)
反对者是最难处理的一类，就像刚刚案例中展示的那样，管理这 类人的重点在于建立信任，化解敌意
如果你实在无法争取他们的支持，至少要让他们 保持中立，以免对其他成员造成负面影响
支持者(绿色部分)
支持者是项目获得成功非常需要依赖的力量
管理这类人的重点 是，首先你要明确地知道，他们各自对项目不同的期望和诉求，然后有意识地创造更多 的空间和机会，让他们能够深度参与到这个项目的决策或创意环节
这样可以增强他们 的主人翁意识，也会给整个项目组带来最大的收益
中立者(灰色部分)
对待这类人，总体原则就是，在条件合适时，进一步将其转化为 支持力量。但如果你精力有限，可以先不管
深入了解干系人问题列表.png
低利益 - 低权力
外围支持人员
我们通常会把一些复杂度低而且非核心的工作，转交给外围支持人员，比如，设计外包、技术外包人员等
在不影响项目的前提下，你可以花最小的力气对他们进行监督
比如，你可 以跟他们提前约定好，每天或者每周进展汇报的格式和内容，确保他们的工作职责和任务明 确，进展符合预期就可以了
项目规划
排除计划中的“延期地雷”
在项目管理中，计划是贯穿始终的重要课题，是各个角色协同工作的基准
程序员做项目管理的优势
对项目中涉及到的架构设计、技术难点等问题， 有着非常深刻的理解，因此，你对技术类风险会有更高的把控力
需要学习的地方
从全局的视角出发，去推进项目整体目标的落地，优化各个角色 的协同过程
作为项目经理，你要利用一切可以利用的资源、尽自己最大的努力达成项目目 标，而计划是你可以借助的重要工具
项目计划
计划是“市场需求或发起人的期望”和“团队生产力”之间平衡的结果
从本质上 来讲，计划是用来对焦的!做计划，是个集体对焦的过程
常见雷区
案例背景
程序员朋友小勤，她升任项目负责人之后，在工作中突然多了很多困惑，尤其是在做 计划时，她遇到了很多问题。现在，我就带你来看看她在做计划时遇到的典型问题
五大雷区
雷区 1:不够具体
小勤的第一版计划是这样的:
网课 2.0 升级项目计划于 9 月 18 日提测，10 月 1 日正式上线。
WBS 工作分解(Work Breakdown Structure)
计划是一种集体对焦的方式。好的计划，不仅要 给出时间节点，还要给出依据和来源，这样才能更有效地对焦
作为一个描述思路的规划和设计工具，WBS 可以清晰地表示各项目工作之间的相互联系， 帮助团队更高效地管理项目
WBS 是项目管理领域非常重要的方法
创建 WBS 的过程，也就是把项目工作按阶段可交 付成果分解成较小的、更易于管理的组成部分的过程
简单来讲
WBS 就是“把大象放进冰箱”的过程，在做计划的时候，我们要把“大象”，也就是我们要做的这件事情真正拆解开，明确要分成多少块工作内容，涉及哪些角色和哪些环节的工作项，你需要将工作项拆解到 3 个工作日以内，每项任务都对应到个
在跟小勤沟通好 WBS 之后，她很认真地做了改进，以下是她修改后的第二版计划:
WBS任务计划分解.png
从这份计划中，我们可以看到，小勤对开发任务进行了详细地拆解，每个人的工作都很明确
做计划的方式的转变，背后其实是思维方式的根本转变
小勤在做程序员的时候，她的目标 就是完成开发任务。但当她的职责扩大之后，她本能地将设定目标默认为完成一堆开发任 务，她还没有意识到，作为项目负责人，自己还需要做些什么
雷区 2:不够全面
项目管理是运用当前一切可用的资源，去完成整个项目目标
这份计划最大的问题是只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节
这样的计划，无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标以及如何 完成
识别依赖并画出关键路径
这一步意味着我们开始 从目标的角度对资源进行统筹思考
关键路径是决定项目工期的进度活动序列
它是项目中最长的路径，关键路径的工期决定了 整个项目的工期。所以，任何关键路径上的延迟都将直接影响项目的预期完成时间
明确了这一点之后，小勤又进一步调整了计划，我们来看看小勤做的第三版计划
WBS任务改进计划.png
小勤已经把工作流中的先后依赖关系识别出来了，这样一来，关键路径也 明确了，这份计划总算有个模样了
在核心部分计划出炉以后，我们还要对项目涉及到的其他合作环节，进行全面地 规划和安排，为各个阶段设定合理的里程碑节点
小勤再一次改进了她的计划，把其他合作环节也明确地标注出来了
项目整体里程碑计划.png
Visio可视化任务计划表.png
雷区 3:不够准确
当计划在执行中出问题的时候，总是会产生很多纠纷，大多是因为大家对一 些节点的定义理解不一致，比如什么叫提测，什么叫里程碑完成
定义完成标准
对小勤来讲，这时迫切要做的，就是让节点的定义形成共同的标准
完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标(特定 水平的 Bug 数量 / 性能指标等)
进度计划中的任何重要时间节点，都应该有一组完成标 准。越早定义完成标准，计划按照期望完成的概率就越大
以最关键的几个常见时间节点，完成标准
需求 / 设计确认
执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经 准备好要编写产品代码了
值得一提的是，有些团队还会对需求稿或设计稿做一定的要 求，比如把未处理的反馈意见数小于多少作为标准
功能完成 / 提测
所有定义的功能都已经完成(比如冒烟测试通过率高于 90%)，团队 已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪
一些质量 基础比较好的团队，也可以把 CI 自动回归用例集通过率、静态代码检查分数、单元测试 覆盖率等，作为更加细节具体的完成标准
里程碑完成
质量已经达到适当水平(如不存在 P0 及 P1 优先级的 Bug)，可以上线发 布，或者可以开始下一个里程碑
事先定义完成标准，就好比提前约法三章，会让计划有更准确的指向作用
雷区 4:没有共识
小勤做计划还有个毛病，就是进度计划的文档只在她自己的电脑里， 在执行计划的过程中，她只和几个开发口头说过，从来没有以任何公开的方式发布过，甚至都没有发邮件、公告等与全员同步信息，更别说开专门的规划会了
做计划本身并不是最难的，真正难的是什么?对焦!没有达成共识的计划，是不具备任何效力的
达成共识并公开透明
事实上，PM 在召开规划会之前，排期的内容已经准备得差不多了
在全员规划会上，除了 对齐信息之外，更重要的是当面达成共识，这其实也是仪式感和承诺的象征，对计划后续的 有效执行，是至关重要的
对于一些小项目，即便没有全员规划会，强烈建议你至少要在确认计划之后，向所有项 目组成员，包括项目的所有干系人，发送计划邮件，正式周知，这可以尽早地发现共识的偏 差
雷区 5:不够即时
在整个项目周期中，由于随时会可能出现变更，加上对估算的不断细化，做计划永远是个反 复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整
及时调整变更
重要的是，每一次进行调 整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需 要谁参与决策
需要注意的是
与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中 对应功能小组的成员(该功能模块涉及的策划、设计、开发、测试)及其他相关干系方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员
项目计划的特点及举措.png
项目执行
实际场景
不知道你是否经历过这样的场景:你的团队历经一个多月没日没夜的奋斗，终于在圣诞节采 购季来临前，完成了“黑五购物节”活动的所有功能，全部测试完毕，马上就要上线了。结 果，产品负责人试用之后，皱着眉头说:“这......不是我想要的!” 你说，还有比这更悲惨的吗?
实际上，这种现象并不少见，有些产品经理还美其名曰“允许试错”。可是，最后做完了才发现不是自己想要的，早干吗去了呢?
潜在原因
1、在互联网环境下，要弄清楚开发什么产 品，准确把握并实现用户需求，对产品人员的要求其实非常高
对于互联网产品而言，从最初的一个想法，到确定规模化的增长模式，通常要经历很多轮的螺旋式迭代，不断调整
2、需求和设计根本没有经过严格的把关，就匆忙投入开发
同时，在传统的研发中间过程中，很难看到串连起来的功能效果，产品经理必须等到 快上线了，才能看到和真实体验到可完整运行的产品。但是这个时候，再想大幅度修改产 品，代价已经非常高了。
打造品质，要从头开始“闭环”
在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发 的整个过程中，建立起真正闭环反馈的产品验证机制
什么才是真正的闭环
开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节
闭环验证方法
方案评审(OARP 决策机制)
需求评审、交互评审、视觉评审都是非常基本的闭环验证方法
典型的开环系统
有些项目是从来不做需求评审和设计评审的，产品人员找某位开发单方面讨论一下，需求就 算定下来了，可以直接往下走了
要想执行中不走样，你就必须把方案评审做到位
评审的精髓不在开会，而在于背后的决策机制
只有决策机制清晰，职责分工明确，方案评审才会有好的闭环效果
OARP决策机制
OARP 是 Owner、Approver、Reviewer、Participant 的缩写，分别对应四个关键角色
负责人(Owner)
负责给出方案，组织各方讨论并推进做出最终的决定
批准者 (Approver)
最终批准者
审核者(Reviewer)
负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复
参与者 (Participant)
其他提供意见的人。参与者会收到文档的相关信息，可以对相 关问题做出反馈
ORAP方案评审流程图.png
OARP 是一套决策机制，你需要为项 目中每一类方案的评审，确定明确的角色和职责，让各角色应享有的权利、应履行的职责， 都得到规则上的保障，这样才能更好地确保方案质量，把后期的返工降到最低
项目中常见文档所对应的 OARP 角色汇总.png
Bug Bash(Bug 大扫除)
Bug Bash，也叫 Bug 大扫除，最初来自微软，是指在项目开发里程碑的末期(比如 Beta 版发布前)，划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起 来给项目找 Bug，目的是从各个维度衡量和体验产品
Bug Bash变种
除了应用于测试阶段，Bug Bash 还 是进行产品闭环验证的一个非常有效的方法。通常，在版本的需求稿和交互稿完成之后，我 会专门安排一段时间，组织团队成员一起，集中精力给需求稿和设计稿找问题
通过这些 Bug Bash 活动，我们把产品验证环节大大地提前了, 不仅达到了更好的体验效果，还有效地保障了上线质量
那么，想要组织一场 Bug Bash 活动，该从哪些方面入手呢?
时间
测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间 段开展
需求设计类的 Bug Bash，一般会放在需求稿或设计稿完成后举行。这个活动需 要一到两个小时的时间，你一定要提前排除所有干扰
地点
你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力 做这一件事
同时，作战室可以提供一些零食和饮料，让活动更有氛围
参与者
除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群， 都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角
现场安排
你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况
需要注意的是，营造互动的氛围非常关键，如果因为空间受 限，参与者做不到在同一个地点进行，你至少也要在通信群中实时更新排名情况的变化
活动结束
在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组
最后，在对 Bug 进行去重后，还要分类定级，确定哪些 Bug 是必须修的，哪些 Bug 是改了会更好的
另外，千万不要忘记公示结果，明确修复计划
冒烟用例评审
当程序员说完成了某个模块的开发工作时，项目管理人员怎么知道 100% 完成了呢?
其实，项目经理最怕听到的一个词，就是“差不多”
差不多写完了
差不多测好了
差不多可以发布了
而冒烟测试用例，可以说是开发和测试之间最基础的合约
要想避免掉进“差不多”的陷阱，在进入开发环节后，你需要安 排专门的测试用例评审，让开发和测试对标准的冒烟用例集达成约定，这个约定就会成为进 入测试的准入标准
开发发起提测以后，测试人员就会依照这个标准用例集进行冒烟，并记录冒烟测试通过率， 如果通过率不达标，就打回修正并再次提测
如果在完全没有基础的团队中推行这个做法，可以先从测试人员记录冒烟测试通过率开始
接着，你要收集相关数据，和你的团队在回顾会上一起看看冒烟用例失败所导致的后期 返工成本，讨论出一种更好的确保质量的做法
你可以选择从一个合适的起点开始，比如 80%，然后再一步步地逼近更好 的提测质量
总结：
在项目执行过程中，有效降低偏差、避免返工的三种闭环验 证方法，包括方案评审、Bug Bash(Bug 大扫除)，以及冒烟测试用例评审
需要注意的是
并不需要在每一个 版本中把这些方法全都用上。你可以结合自己的项目情况，有步骤地开展优化，在核心的输 出环节，设置合适的断点和关口，这样就能更好地把控全局了
项目监控
进展“巧”汇报，学会用数据说话
应用案例
我们在做计划的时候，明明已经想得非常周全了，可是，真正开工之 后才发现，很多事情并没有那么简单
我曾经就经历过这样一个项目。某个课程系统要对其购物车功能进行扩展改造，最初评估 时，研发认为功能并不复杂，三天就够了。但是，开工之后却发现，这个“坑”改动起来牵 涉面太大，老的订单系统盘根错节，不好下手，现在看来至少也得两个礼拜才能完成
可问题是，这个任务正好在关键路径上，如果它延期了，所有都得跟着延。更重要的是，老 板特意交待过，这次上线关系到年底最重要的 KPI，一定不能延期......万分紧急之下，如果 你是项目经理，你该怎么办?
首先，必须要冷静!泰山崩于前而色不变，这是作为一个项目经理必须要修炼的心态。在项 目的监控过程中，你会遇到各种各样的情况，甚至是突发的紧急状况，这个时候，有效的沟 通汇报是必不可少的。
项目汇报
紧急汇报:直面问题有章法
承认自己遇到了问题需要帮助，其实是件非常困难的事情
毕竟，很多人都有“特别想要把 事情做好，让老板有个好印象”的心态
但是，作为项目管理人员，当事情已经超出了你的 可控范围时，你首先要做的，就是第一时间直面问题，如实地呈现和反馈遇到的困难
对于整个项目而言，你的真实和坦诚反而是最重要的
紧急问题汇报方法
紧急报告
紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告
比如遇到 高风险延期、线上重大问题、或者重要客户投诉等
目的是向全组或者主要干系人通报项目 的重要变化，以及时协调应对工作，或者第一时间寻求外部支援
由于事发突然，紧急报告一般不需要拘泥于具体的形式，关键在于言简意赅地传递信息，并组织后续的跟进动作
紧急报告会包含 5 个基本元素
1. 事件描述
2. 影响后果
3. 跟进分析
4. 响应措施:包含负责人及时间表
5. 所需支持
结合实际案例，以上面购物车改造项目为例，看下那位项目经理写的紧急报告
1. 事件描述
购物车改造功能高延期风险;
2. 影响后果
由于此功能在项目的关键路径上，很有可能会造成项目整体延期两周;
3. 跟进分析
本期购物车改造功能，有部分调整涉及到底层订单系统，里面有大量遗留代 码，已经很久没有人维护了
之前对此风险的评估不够充分，改动风险很高，可能会影响全站订单系统的稳定性，具体影响仍需要详细分析;
4. 响应措施:包含负责人及时间表
主程全力以赴做好技术评估，本周内给出详细任务评估时间表;
与此同时， 产品人员介入，调研规避老系统又能满足需求的可行性，本周内给出调研结论;
5. 所需支持
熟悉老系统的资深技术人员，以及红牛一箱。
提交这份报告的作用和效果
发起人第一时间就会关注到，项目组正面临着非常棘手的问题，以 及可能造成的影响和后果
同时，他也了解到，团队正在试图解决这个问题，目前的解决方 案是什么，还需要什么样的支持和帮助
当然，如果你能够第一时间跟发起人当面沟通，效果会更好
总结
总之，执行过程中突发的紧急情况，非常考验项目经理的专业素养
首先，你必须要直面问 题，在紧急时刻勇于站出来承担责任，不仅不会让老板对你的印象减分，还能让决策者在第 一时间选择更好的应对方式
另外，你要尽可能简洁地描述清楚可能的影响和后果，目前的 建议方案和所需支持，最大程度地争取各个相关环节的协同配合，共同应对问题
常规汇报:项目周报回答的三个问题
项目周报
切忌任务流水账式的罗列，没突出重点，项目的整体进展状态到底如何?风 险可控吗?目标达成有没有问题?
项目周报是向项目团队和干系人沟通项目状态的常用手段，你需要用简要的方式呈 现项目全貌，客观地展示项目问题，推进问题解决
项目周报.png
项目周报模板.png
在这份项目周报模版中，最必不可少的就是整体项目状态评估、风险列表、项目概况及计划 变更情况
好的周报，应该让大家对项目现状的三个问题形成统一、清晰的整体认知
这份 整体认知，可以让平时扎在细节工作中的人，从全局视角来了解和看待整体，从而更好地完 成自己的工作
需要注意的是
一份周报的阅读时间不应超过 5 分钟
因此，在写到进展和问题时，切 忌事无巨细，只写要点就够了
周报不是为了表现工作量，更不是为了刷存在感，只说重点 就够了
数据汇报:善用“透明”的力量
实际案例
拿线上事故的改进措施 为例，每次都说要建立完善的保障体系，可是经常一个月过去了，也没什么进展
于是，我 就把事故数据拉出来，根据原因定位，分门别类地做成直观的数据图表
后来，我发现，只 要我坚持在项目组大群里发上三天，表格上的数据就会悄无声息地发生变化，改进项清零的 速度也加快好多
常见的项目仪表盘
倒计时图
倒计时图是个非常醒目的标志，可以帮助大家建立清晰的时间意识
发布倒计时和工作燃尽图.png
工作任务的状态 分布和剩余工作量分布
剩余工作量和工作状态分布.png
可以清晰地展现出每位成员的工作排布情况，帮你快速发现和定位 执行过程人员工作量的瓶颈
燃尽图(Burn Down Chart)
这是敏捷开发方式中用于表示任务 完成趋势的工作图表，横轴表示时间，纵轴表示工作量
如果你在做好规划之后，把任务和 工作量录入 JIRA，设定好迭代的预期完成时间，就可以自动生成这样的图表
这种图表可以直观地进行过程预测和风险预警
其中，灰色线是计划完成情况的基线，红色 线代表实际完成情况
在进展顺利的情况下，红色实际线会紧贴着灰色计划线，一路往下， 直到“燃烧殆尽”
每天开站会时，更新完任务状态之后，团队可以一起看下燃尽图的变 化。如果红色线连续多天居高不下，一直停留在灰色线上方，这就说明进展持续低于预期， 你就要多加关注了，具体分析到底是哪个环节拖了后腿，然后有针对性地发起改善
实际问题
某项目前期拖沓，需求稿、设计稿经常给得很晚，开发承受着很大的压 力，只好拼命加班
解决方案
为了促发改变，我尝试客观记录了策划、 设计、开发、测试等各个环节的时长分布，以及可能带来的后期风险。这份数据在项目汇报 中展示以后，引发了管理层的高度关注，在下一个版本中，问题很快就得到了改善
经验总结
项目进展汇报是项目经理面向所有干系人、非常重要的一个沟通和发声的平台，运 用得好的话，可以成为项目经理有力的杠杆力量
有效运用这个杠杆的秘诀就是:想要改善 什么，你就去透明什么，越直观越好!
项目收尾
项目复盘会
项目团队有意识地向过去的行为经验学习的过程
在项目或里程碑完结之后，项目经理会组织召集项目成员，一起回顾一下，在项目的整个历程中，团队做对了哪些事，做错了哪些事，再来一次，如何做得更好，借此把项目行进过程中产生的集体智慧沉淀下来
但是，现实情况经常是，项目一个接一个地做，忙上线、忙变更、忙返工，哪有时间坐下来 复盘?又有多少复盘会，是为了复盘而复盘，逐渐地流于形式，成为了可有可无的摆设?除 此之外，还有很多复盘会，成为了追责者的工具，除了锻炼出花样百出的各种甩锅技能之 外，留下的只有“一地鸡毛”
如何做好项目复盘
复盘会的基调设定
在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要
如何设定开放的基调呢
首先，我们自己要先进入反思区
在复盘会之前，我跟这个部门的负责人，就部门中反复出现的各种问题，进行过多次深度沟通
一开始，这位负责人觉得团队里到处都是问题。但当我们把问题一层层地剖开来看时，我们发现了很多问题背后的深层原因
在会议刚开场，就要展示出自己的开放与坦诚，给复盘会奠定基调
这次复盘不是来挑问题的，而是为了找到问题的根源并改进的
在那次复盘会上，这位负责人特意讲了 自己这一年来的深刻反思，这就带动大家敞开心扉，直面问题
那次会上，大家自发地找到了在各个环节有效避免无用功能的方法
会议结束以后，这个部门还发起了一项“整风运动”
增强用户意识的讲座
用户调研方法的培训
激励与考核制度的挂钩
复盘会的会前准备
除了设定基调，你还需要充分的会前准备
在复盘会之前，你要去梳理整个版本的历程，包 括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等， 这些是客观数据的总结
同时，你还可以提前收集这个版本期间，团队满意度的问卷调查， 为复盘会引入更多主观的输入
除此之外，视频也是非常好的回顾材料
复盘会的基调设定，以及会前的准备工作，在开会之前，就很大程度地决定了复盘会 的效果，你一定要特别留意
复盘会的简易流程
1. 现场回顾总结项目 / 里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需 求变更情况、质量报告等项目历程记录
2. 与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环 节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达
3. 在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论
4. 对大家总结出的好和不好的点，进行集体投票
5. 由项目经理整理投票结果，对于做得好的环节，总结经验;对于做得不好的环节，当场讨论出改进方案
复盘会简易流程图.png
复盘会投票结果.png
这个项目是第一次引入项目经理。在这次复盘会上，项目经理的工作得到了一致的认可，包 括 Bug Bash 的引入、WBS 工作分解、进度控制等措施，帮助团队快速地完成了从混乱到 有序的转变
再来看看待改进项，投票最多的一项是，后台研发与各端的沟通瓶颈，那么很 显然，这就是你在下个版本一定要去解决掉的问题
经过分析之后，我们发现，由于工期紧张，在后端接口没有成熟的情况下，前端、客户端必 须同时开发，如此快节奏迭代之下，频繁的后台接口变动，牵一发而动全身，这让后台技术 成为了整个项目的瓶颈
为了改善这个问题，我们成立了专门的 Triage 小组(判别小 组)，由各端的主程组成，每天固定 15 分钟时间，参与者线上同时连线，对每个端提出的 接口变动需求，进行统一判断，并作出决策，确保接口变更信息第一时间的同步
无法促发行动的复盘，说得再好都是空谈
一开始开复盘会，大家会期待，解决的问题越 多越好，但焦点增多之后，哪个都是蜻蜓点水地过一遍，哪个都没改彻底
下次再开会的时候，大家发现之前反馈的问题依然还在，那谁还有动力继续提问题呢?
改进措施一定要落地，重点行动不要太多，一个就够了!
如果每次复盘聚焦于改进项中的 Top 1，确保改进措施真正落地，长期坚持下去，就会促进持续的能力提升
同时， 复盘的次数也不要太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的
打造团队持续改进能力
项目复盘不只是一次会议，它更应该成为团队持续改进的推动力
那么，怎样才能让 一次成功的复盘发展成为复盘文化，激发团队自主地持续精进呢?
实际上，想要让团队进入自发改进的正向循环，你需要更好地激发团队的主人翁意识，让团 队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人。
“研发代表大会”复盘会
当时，我们把部门中所有 资深的程序员召集在一起，让他们给平台越来越严重的技术债问题出谋划策
这次复盘我采 用了“批奏章”的玩法，各位代表把自己的意见写在纸上，然后围成一个圈，依次传递给左 边的同学，每个人把手上的“奏章”批阅完成后，继续往左传。这样一圈转下来，+1 数最 多的那份“奏章”，就会被选出成为年度力荐
最后，这份“奏章”得到了最多的关注和资源，这项建议迅速得到了落实
同时，这样的复 盘方式，也让更多的研发同学享受到了“批奏章”的愉悦感，一旦他们发现，自己选出 的“奏章”会得到采纳和落地，那么这个“研发代表大会”也就可以真正地自行运转起来， 更多人愿意主动参与进来，通过这个平台，发表自己的见解，为整体能力的提升贡献一份力量
越是困难时期，越是塑造团队能力的大好机会
在团队遇到重大困难时，你也可以及 时组织一场复盘会，深度关注和调整个人的状态
我就曾经试过让每个人画出自己进入这个 项目组以后的状态变化曲线，跟大家分享自己的“高光时刻”和“至暗时刻”
在业务低落期，这样的复盘会会成为一个重要的转折点，让团队的力量得到深度聚合
这些对人的关注，都会让复盘会超越问题解决的层面，在推进事的同时，促使团队自发地推 进问题的解决，并把经验内化下来，从而不断提升团队的持续精进能力
总结
当人们在说复盘时，往往会把焦点放在复盘会本身。 但我却认为，决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节
复盘会前，复盘基调的设定是否开放，复盘会前的各项准备是否充分，对于复盘会的效果非 常关键
组织一个复盘会本身并不难，难的是在复盘会后，持续跟进这些反思，落地为切实 的改进措施，让团队真正看到效果，从而打开团队持续改进的正向循环
认真地做好一次复盘，每次复盘后聚焦一个改进点。再提醒你一句:聚焦点 别太多，一个就够了!
需求变更
需求变更一直都是一个热门话题，特别是在奉行唯快不破的互联网公司，需求变更可以说是 程序员的头号噩梦，也是“996”的直接元凶
阿里有句非常有名的口号，叫作拥抱变化。既然需求变更无法被消灭，那么我们就要通过学 习，掌握更好地应对需求变更的方法
常见的需求变更流程
需求变更流程.png
首先要发起变更申请，由变更委员会来综合评估，评估的内容包括变更范围、风险、对现有计划的影响程度等，以此来判断是否接受变更
变更委员会一般是由产品 leader、技术 leader、测试 leader 及项目经理组成，如果接受变更，那么就需要判断项目计划是否需要 进行相应的调整，最后公告处理结果
锦囊妙计
锦囊 1:达成最小共识，变更是有代价的
实际案例
我刚到 A 团队的时候，交互妹子就可怜兮兮地拉着我说:“2 个月过去了，我们的第一个 版本还在打磨，80% 的交互稿都已经改得大不一样了，越是临近上线越是不断地改。如果 去跟策划们争辩，对方就甩过来一句‘老大要加的’，你说怎么办呢?”这个“老大”也就 是 A 业务的负责人。他是产品经理出身，又是完美主义加说一不二的性格。于是，产品策 划在团队中就有着绝对的话语权。
在耐心地观察了一番之后，我终于等到了时机。在版本结束的复盘会之前，我跟负责人建议 说:“你看，我们项目组是全新的团队，成立两个多月了，这么长时间运行下来，还是有不 少问题的。我们需要一次深度复盘，这次复盘非常重要，你一定要来参加!”
复盘会的当天，大家匿名写纸条，分别列出各个环节做得好与不好的地方，贴到白板上。看 着满墙花花绿绿的便签，写满了各个角色对需求变更的各种吐槽，这位负责人沉默了好久。
接着，我把事先准备好的表格拿出来，表格中记录着历次变更给团队带来的各项成本增加及 引发的返工
需求变更成本计划表.png
在复盘会接近尾声的时候，业务负责人当场发话:“从今天开始，团队里的需求变更要严格 控制，从我自己做起!”在这之后，产品策划的随意变更行为显然收敛了很多
复盘举措
我也趁势在 下一次的全员会上，跟所有团队成员约法三章，把复盘会上的共识，细化成了具体流程:
1. 所有需求及所有变更必须建单，无单需求开发有权不接
2. 需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计 划，并告知全员
3. 对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道
变更源头
就是把关需求的质量，避免需求问题流到下游
建议你在一些大版本的需求设计稿完成时，发动团队的力量去做一轮全面的 需求检查，让各个角色早期深度地参与到项目中，这对防治需求变更非常有效
总结
要想改变现状，首先就是找到合适的时机，树立对变更的最小共识
之所以说最小共识，是指这个共识不需要一步到位，如果在你的环境中确实比较困 难，可以只是前进很小的一步，比如你可以从所有变更都需要记录，并公告周知开始
达成这个最小共识，是要让团队开始慢慢认识到，需求变更是有代价的。不过，毕竟产品仍 然在探索期，变更总是在所难免的
我们追求的是达成项目目标，而不是零变更
锦囊 2:源头治理，一次把事情做对
问题
上线时间都是定死的，即便认真做了评审，发现了方案的很多问题，一 改再改，最后压缩的还是开发时间。其实，要想真正把关需求的质量，还是得从源头开始治理
案例
我来跟你分享一个几年前，我在某事业群启动中台建设项目的真实案例。这个事业 群当时已经有三四年的历史了，伴随着多条业务线的高速发展，公共平台的架构频频遭遇掣 肘。这个事业群的老大几经思索，下定决心花大力气快速进行整治。情急之下，他找到我， 让我来负责这个超级复杂的项目
在四个月内，我们重整了这个平台积累了四年的整个业务和技术架构。当时时间非常紧 张，，四五条业务线的产品和设计人员都会参与其中。作为新的中台架构，如果在后续执行 中发生变更，往往会产生灾难性的影响。怎么办呢?
我急中生智:“小黑屋集中开发呀!”不同的是，这次被关进小黑屋的，不再是苦哈哈的程 序员，而是产品和设计人员。他们以前哪经历过这个啊?纷纷念叨着:“What?项目还没 怎么着，先把产品和设计的 deadline 定了?!”于是，我找来那位老大站台，召集全员， 开了次隆重的启动会。会议的第二天，十几位产品和设计人员就搬进来了
为了减少后期的变更，尽可能一次把事情做对，我们在小黑屋搞起了“上墙文化”，产品和 设计的 Deadline 排期图、产品模块设计图、页面逻辑跳转图......还有各种设计草图，全都被搬上了墙
没过几天，这里居然成为了程序员午饭后驻足观赏的胜地。见到如此盛况，我们开始给他们 准备各色小标签，让他们在游览的同时随时发表各种评论。大家的参与热情空前高涨，很多 需求和设计的漏洞就在这里被提前发现、及时讨论并修改掉了，有效地保障了早期需求和设 计的质量
其实，这个项目中每条业务线都有自己的策划，如果采用传统方式，这些需求各自成稿，再 加上不同业务线的策划之间、策划和设计之间、设计和开发之间的沟通成本，不知道什么时 候才能真正确认，也不知道会埋下多少变更的“坑”
总结
从变更的源头开始治理，从源头开 始公开透明，一次把事情最对，实际上是最有效率的方式
小黑屋 + Deadline 的实践效果 奇佳，在一些上线时间有严格要求的复杂项目上，你绝对可以考虑下
锦囊 3:快试错，不可抗力巧应对
问题
来自产品经理的变更就不在话下了。不过，现实情况是，很多变更来自大老板或大客户，这些不可抗力，我们又该如何应对呢?
方案
不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求
为了隔离老板的需求对整个团队进度的干扰，我们在常规团队之外，组建了一个老板需 求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽!同时， 对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说 话
当这一系列机制运转顺畅之后，我们慢慢发现，老板在提需求时，不会每次都火急火燎了
很多同学把这类来自老板的变更视为不可抗力，实际上，这背后还是有一定的改进空间的。 你可以从建立快速有效的响应机制开始，同时多去总结和剖析这些需求背后的原因，毕竟老 板要的是效果，那你就得用数据说话，更好地应对这些需求变更
总结
建议你从达成最小共识开始入手，让团队意识到变 更是有代价的
然后，再往前一步，从源头开始深入，集中保障需求质量，争取第一次就把 事情做对
另外，关于来自老板或客户的需求变更，你要快试错，巧妙应对
风险管理
项目风险
有什么影响
项目风险是一种不确定的事件或条件，一旦发生，就会对至少一个项目目标造成影响
比如范围、进度、成本、质量等
项目风险也可能对组织或组织的目标造成影响
比如 财务、声誉等
该怎么平衡
如果风险给项 目造成的威胁在可以承受的范围内，并且与可能得到的收获是相平衡的，那么这个风险就是 可以接受的
要想在充满不确定性的大环境下取得成功，组织应该致力于在整个项目期间，积极而又持续 地开展风险管理
风险管理
系统化风险识别
风险识别主体
风险识别的主体，应该包含项目中的团队成员在内的各方干系人，而不只是项目经理
组织中的每个层级，都必须有意识地积极识别，并有效管理风险
系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终
风险过程输出
风险登记册
包括已识别的风险清单，以及潜在应对 措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序
其中，风险概率是指每个具体风险发生的可能性，风险影响则是风险对于项目目标(进度、 成本、范围、质量)的潜在影响
风险概率和影响的评估
风险对主要项目目标的影响表.png
此表是《项目管理知识体系指南》中给出的，风险对项目目标影响程度的评估量表
其中， 造成成本增加大于 40%、进度拖延大于 20% 的风险，就属于最高影响程度级别的风险
可以通过访谈或会议的形式来进行
参与人员包括熟悉相应风险类 别的人员，以及项目外部的经验丰富人员
风险登记册的示例.png
冰山下的风险
项目执行过程中，最大的风险，不是那些显而易见的、冰山上的风险，那些冰山下看不见的风 险，往往才是最要命的
通常，项目组中最坏的情况是，大家对项目里的风险避而不谈
避谈风险的原因
缺乏风险的沟通渠道
提出来也没有用
老板会认为自己没能力管好当前的项目
如何识别冰山下的风险
当寻常的渠道不管用的时候，就要看项目经理的信息网络了
项目经理一定不能脱离团队
如果没有群众基础，只是坐等着别人给你上报风险，那你的工作就远远没有做到位
一个优秀的项目经理
必须是一个优秀的“情报人员”
上至最高的项目发起人及组织的各 层决策者，下至项目最边缘的人群，比如外包、实习生、短期借调支持人员等，你都要跟他们建立广泛且深入的联系
你识别出的风险越多，项目的风险就越低
风险应对措施
你需要为识别出的每个风险，制定相应的风险应对措施
风险应急预案
对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案
一旦风险和危机来临，应急预案就可 以有效地降低风险的损失和危机带来的灾难
“双十一”之前的故障演练应急预案
需要针对每一种可能发生的线上突发状况， 提前确定好处理步骤、责任人、预计时长，甚至是每一步的指令或脚本，以免在出现突发问 题时，手忙脚乱导致出错
故障演练计划
在项目排期时，你要确保有相应的故障演练计划，并且做好充分的准备
也许有些风 险预案永远也用不上，但是这并不是说它们是多余的
在风险降临的危机关头，它们的价值 就会凸显出来
周期性风险审查
在项目执行期间，已识别的风险会不断地变化，新的风险也会产生。你需要在每周的项目状 态同步会议上，对风险进行再评估，并通过周期性的风险审查，来识别新的风险
树立正确的风险观
1. 治未病，建立系统性保健机制
所谓的“治未病”，就是说要未病先防，事后不如事中控制，事中不如事前控制
“春江水暖鸭先知”，关于执行中的风险，群众永远是最有发言权的。如果这个系统是健康的，一定是可以自行去呈现和反馈风险的
建立系统性保障机制的关键
你要致力于持续改善人与人之间的互动品质，提升项目团队的健康度
系统性保健方法
1、经常做匿名的问卷收集或访谈
做调查问卷，是项目经理了解团队的重要方式之一
在每个重要版本结束时，你都可以用调查问卷的形式，收集大家的意见，其中有两个典型的问题：
对这个版本研发过程的综合评分(包括迭代方式、工作量、工作压力、团队配合、时间 管理等各个方面)，这反映了过程满意度
对这个版本功能设计的满意度，即产品认可度
你要坚持在多个版本中反复使用，积累数据
这样一来，你就可以通过各个版本的数据变 化，看到团队状态的起伏和健康度的走势
当团队对产品的发展方向产生疑虑或不认可，抑 或是对过程中的管理方式或协作状态不满的时候，你要允许团队各抒己见，充分沟通表达
事先预防永远胜过事后纠正，如果你有意识地在团队中构建这样的常规反馈渠道，系统性风 险提示和保健的作用就会逐渐发挥出来
2、定期做一场坦诚布公的复盘会
2. 积极管理致命风险
常见的致命风险
公司高层对于项目的态度和预期
项目目标与组织战略目标的一致性
项目所依赖的重要资源方的合作关系
竞争对手及行业市场状况的变化
政策变化
监管风险
如何管理致命风险
第 1 步:挖掘出这些致命风险，把它们变为可见的、可谈的
很多管理者非常关心执行 中的风险，却对于这类致命风险讳莫如深，只留在自己脑子里，这样反而是最危险的
致命风险的挖掘，通常会让我们对项目背景的理解更加透彻，并对那些影响到项目生死 存亡的关键要事，有更加清晰的认知和规划部署
第 2 步:正视风险，不存侥幸心理
你要和发起人一起想办法，发动核心团队，合力去 制定应对策略
第 3 步:在项目的核心团队中，周期性地梳理和同步风险状态
总结
加速构建核心能力，不断拓宽“护城河”， 才是最根本的应对之道
质量管理
实际现象
说到质量，很多人会说:“工期太紧了，能按期提测就不错了，Bug 多一点也正常。质量 好不好?不好说。如何提升?不知道，QA 会保证的呀。”
一般大部分程序员，对自己的代码质量要求还是很高的，但是，一旦遇到赶工压力，尤 其是在 deadline 之前，就很可能会把完成度很低的代码交出去，心想“反正有人给我检 查，到时候再说吧”。但是，这些代码就好比是一台“行走的 Bug 制造机”，后患无穷
访谈调研
我曾经在一个技术债特别严重的部门中，面向各级程序员做过一轮抽样的访谈调研
调研结果
程序员们只有 27.2% 的时间在做真正产生价值的编码工作
但是，他们有 20.7%的时间，是在做需求质量和代码质量问题所引发的 Bug 修复、返工和紧急上线工作
质量成本
一类是事前防止失败的一致性成本
一类是事后处理失败的非一致性成本
包括内部 Bug 引发的返工成本，以及外部 Bug 导致的用户侧成本
事后检查处理的代价其实是最高的
预防高于检查
质量是规划、设计、建造出来的，不是检查出来的。预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多
一次性把事情做对的成本是最低的。而一次性把事情做对就意味着，我们要有 意识地提升预防类工作的占比，从根本上降低内部 Bug 率和外部 Bug 率。在这个质量改进 的过程中，程序员是绝对的关键力量，而非测试人员
规划质量管理活动
质量规划，明确标准
规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程
需要注意
在业务生命周期的不同阶段，质量标准应该是动态变化的
比如，业务初创 期追求的是最小化 MVP 模型的快速迭代，在这个阶段，质量往往不会是最关键的因素
但 是，当规模扩张到一定程度之后，对于质量的要求就非常高了
不同的项目对质量的要求也相差甚远，无法一概而论
因此，只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义
质量保障活动
各个阶段的质量保障手段的列表图.png
需要特别关注研发过程中的质量保障手段，制定适当的编码规范、提交规范和分支 规范，同时设计代码准入标准，确保代码 Review、单元测试、接口验证和 UI 验证等手段 与你的项目质量要求相匹配
质量分析，追根溯源
质量分析
是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并 制定相应的预防措施和解决方案
案例分析
我曾经给一个底层核心模块的技术团队做项目管理，但我经常听到上层模块抱怨它的质量， 有时候甚至在关键流程上都有问题，团队内外都对其质量失去了信心。
从数据上看，这个模块的线上 Bug 量占项目总 Bug 量的 17%，给上层其他模块和运维都 带来了不少麻烦。随着越来越多的外部应用陆续接入，如果这个问题得不到有效解决，内部 矛盾很可能就会升级为外部矛盾，不容忽视。
经过深入分析，我对频发的质量问题有了以下认识:
1. 团队扩张得很快，在相当长的时间内，测试人员的配比都非常低，8 个开发对应 0.5 个 测试。测试基本上只是给开发打工，只能保证最最基本的功能，其他更深度的测试类型 根本无所涉猎;
2. 团队没有从用户的视角来检验产品，上层模块的应用场景、运维的应用场景与测试的视 角相差较大，测试效果很难保障;
3. 约有五分之一的线上 Bug，是来自社区，用户侧出现问题以后才去社区找，再把这个补 丁合进来，没有主动应对。
同时，我也做了用户调研，最终的结果显示，用户对底层核心模块的期望更多的是稳定，至 于新功能，用户普遍表示暂时没有需要。因此，盲目增加复杂功能其实并不明智，保持产品 简单可靠才是王道。
改进措施
1. 新功能适当放慢
在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占 比与优先级。当时我们定义的是不超过 70%，在一定时期内，核心功能不再做大的变 动。
2.回顾总结
将线上 Bug 分析作为周会的一项固定内容，集体讨论出整体层面上的改进措 施，并跟进实施到位。
3. 查漏补缺
对已有的测试用例进行全面梳理，与相关的开发、测试、运维一起集体 review，花大力气补充测试代码(增加异常、并发、稳定性测试等)。考虑到这是一项 长期工作，要确保将其分解到各个迭代中，分批实施。
4. 走到前面
紧密跟进社区 Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对 措施，主动引入必要的补丁。
5. 以终为始
新功能需求确定后，测试用例同步设计并进行 review，然后开放冒烟测试标 准，让开发人员在明确“什么是完成”的前提下，进行开发。
在坚持了两个月之后，整体的质量状况好了很多。总体来说，质量分析最重要的是要追根溯 源，找到问题症结
实践方法
每月坚持开线上 Bug 分析会
你可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落
持续进行内部 Bug 分类
从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug 分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗 留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数 据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要 先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效
建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势
对齐千行代码 Bug 率、Bug 数 / 需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性 的原因分析
质量控制，层层卡点
质量控制
如果说质量分析的要点重在追根溯源，那么质量控制，就是将一些明确下来的质量规范和做 法，真正落地到各个环节
从需求到发布的整个过程中 的质量活动概览.png
质量控制及卡点行为
是要结合项目的质量要求和团队的质量成熟度，一层一层地加强质量把关和收口
即便是在同个项目的不同应用中，也会因为线上要求的不同， 而对质量卡点有不同的侧重
通过质量卡点的在线工具化，才能做到真正有效的质量保障
比如，某些团队在特定阶段，会按照静态代码扫描问题的级别来分级计算缺陷值，提交测试 申请时，如果系统检测到缺陷值有升高，就不能够成功提交
总结
项目经理在质量管理过程中的工作，你可以从三个方面入手
质量规划，明确项目的质量标准
质量分析，追根溯源，找到质量差距的根本症结
质量控 制，在需求到发布的过程中，设置层层卡点来控制质量
要想一次把事情做对，你首先得明确什么是对，然后要分析差距，找到相应的质量保障方 法，并不断迭代。这三个方面是个螺旋式循环上升的过程，你需要不断地根据质量分析的结 果，设置合适的质量卡点，直到达到规划中的质量标准
高效会议
“断舍离”，只开最有必要的会，会而有议，议而有决，决而有行
会议不在多， 而在于精，每个会议都要真正开出效果来
项目中的重要会议
“断舍离”是一种思维习惯，也就是说，你要有意识地选择，最适合项目现阶段状况的会议
项目中的重要会议.png
启动会
意义
启动会好比是誓师大会，用来快速地聚拢兵力，集中力量干大事!
目的
清晰目标，明确授权
要做到这一点，你需要分三步走，分别是 why、 what 和 how
第一步why
只有充分理解了项目背景、目的和意义，才 能更好地唤起团队的参与热情
项目的启动会，我们特意邀请到大老板亲自上阵跟大家讲述项目背景。他从公司战略赛 道的选择性聚焦，讲到自己对这个事业的追求，话语中所传达出的重视、关注和热爱，是让 这个 why 真正打动人的核心要素
第二步what
描绘蓝图，设定清晰的愿景
包括项目的三年目标、五年规划，越清晰越 好，为的是让团队看到未来的样子
第三步how
也就是明确团队之间的责任分工以及合作公约
对于一些新组建的团队来说，也可以加入一些破冰的环节，让大家打破边界，尽快建立新的 协作模式
你还可以留一些时间给重要的角色代表发言，大家的热情相互感染，会让士气空 前高涨。这时，启动会的效果就达成了
内容
1. 项目背景
2. 项目目标
3. 项目范围
4. 里程碑计划
5. 主要风险
6. 组织架构
7. 责任分工
8. 流程机制
9. 沟通方式
沟通方式指的是，会议的时间安排、频率及参与人员
10.支持工具
支持工具一般是指项目组统一 使用的任务管理、文档管理、代码管理的工具
只有在新项目或新阶段准备启动，涉及到方向、目标、人员、职责的调整的 时候，才需要开启动会来进行公开的澄清和授权
每日站会
开好站会的关键，是要还政于民。站会满足的是团队的自组织需要，而不是 leader 的监控需求
作为项目管理人员，你要引导团队不断建立和完善自己的规则，并在运行顺畅之后，把站会 还给大家，让大家自己决定站会要怎么开
实际案例
早期我带过一个团队，经过反复尝试，大家决定把站会的时间放在午饭前的 11:30 开始。 这样一来，团队成员可以有相对完整、不被打扰的整个上午的工作时间。另外，吃饭的动力 也会让大家集体加速，从而保障站会的高效。如果有一些争议性的话题没有解决，午饭时也 可以继续讨论
自我管理站会
真正自我管理的站会，除了团队成员自己决定站会时间之外，连主持人都是成员轮流来当的
为了让每个主持人都能把站会开好，有效把握会议节奏，经过长期的实践，我逐渐 摸索出来一套“三张牌”式站会法
“三张牌”式站会法
1、站会开始时，主持人将红、黄、绿三张牌分别发给所有的与会人员。在整个站会的过程中， 任何人都可以随时举牌来行使自己的权利
2、举“红牌”:表示叫停谈话，避免过度的讨论和无结果的时间浪费，提高站会效率
3、举“黄牌”:表示打断讨论，进行提问，向发言者了解协同及依赖的信息
4、举“绿牌”:这是一个 token 牌，代表每个人的发言权。每次只有1个人发言，按顺序来，将此牌归还给主持人表示同步完毕
5、当所有的“绿牌”都已归到主持人手中，而且没有更多疑问的时候，站会就可以结束了
这样简单的游戏规则，既可以帮助主持人有效地把握节奏，同时还把会议控制的权力和责任 交给了与会的每一个人，任何人都可以对过度的讨论随时喊停，从而让站会在“有用”的同 时又能保持“高效”
项目周会
通常情况下，对于 10 人以内的小团队来说，如果已经有了每日站会，就不太需要再另外设 置周会了
但是，当项目组的规模继续扩大，分成了若干的工作小组之后，你就需要利用项目周会，周 期性地对项目的各个角色、各条线的进展和风险做全面的检查了
目的
是解决整体计划层面、跨团队协同配合的问题
包括产品、运营、市场、 研发等环节
由于项目周会是面向各个角色负责人，甚至面向全员的全局性会议，所以，项 目周会就天然地成为了一个最能直接把控整体脉搏的地方
内容
除了常规的各角色进度和风险同步之外，你还需要根据项目组每个时期的 整体阶段性重点，来设置相应的环节，让大家清晰地感受到项目组明确的导向，也就是什么 是当前最重要的
比如，业务初创期，我们每周会一起关注业务数据的实时变化，针对有问题的部分，各个角 色及时联动调整策略
对于一些技术保障类的业务，则会每周重点关注客户反馈的工单数据 和服务保障 SLA 的变化
对于 ToB 类业务，会重点关注付费率、续费和丢单情况的最新变 化，从而及时找到问题，快速联动解决
保障会议品质的关键
不要盯着会议的数量，而是要追求会议的品质
三个基本要素
1. 明确会议边界
每个会议都有特定的主题和目的，并有明确的参会人员范围，这个就叫会议的边界
会议边界
“为什么要开这个会?会议的边界是什么?哪 些议题适合在会上讨论?”
对于那些与主题不相干的议题，你要坚决舍弃
两个确保
确保各部分的进展信息在会前统一提交，会议当场只说重要问题、风险及需要支持的地方
确保会议当场严格围绕主题开展，对偏离主题的讨论，及时叫停!
参会人员
相关问题的主要决策人，对这个问 题有责任的相关人员、负责执行决议的人员是必须参与的
发送会议邀请时，你要明确哪些 是必须参与的人员，并抄送那些可以选择参加的人员
2. 建立会议规则
“会议小恶魔”
我们曾经做过一个“会议小恶魔”的游戏，就是让每个人想尽办法地破坏会议，借此去体会 开好一个会，需要哪些要素。结果我们发现，像迟到、拖堂、开小会、看手机等行为，问题 虽然不大，但是频繁发生的话，就会大大地影响会议品质
特别是对于一些周期性的常规会议，约定好会议规则是非常有必要的
主持人要引导大家建 立会议规则，对于迟到、请假、拖堂、跑题等行为建立公约，并成为规则的守护者
会议规则
我身边有些做得好的项目周会，光是会议规则就已经迭代过五六个版本，从迟到红包、拖堂 红包开始，到轮流担任“规则守护大使”的角色，最后发展成由主持人判定违反会议规则 者，即自动成为下次会议的主持人......不得不说，这一招真的很管用。规则上的推陈出新， 在活跃了氛围的同时，还共同构建出了高效的会议品质，最终是对每个人的时间负责
3. 做好会后跟进
要想真正做到决而有行，最终靠的是有效的会后跟进，真正把决策落到实处
会议主持人要及时汇总讨论的结果，并形成会议结论
对于无法当场确认的问题，一定也要 进行记录，并明确跟进人和完成时间
会后所有跟进事项，直接进任务系统，确保跟进到底
同时，要在会议纪要的邮件中明文呈现，下次会议统一回顾
应用案例
把项目管理方法引入团队的三要素
首先是“天时”，也就是合适的时机
时机或早或晚，都会让引入变化的阻力成倍放大。早 了，大家还没意识到问题;晚了，他们又找到了可以将就的办法，逐渐形成了惯性，并视为 理所当然。那到底什么时候才合适呢?
实际案例
小云在半年前刚刚升任项目经理，他跟进的第二个项目，就遇到了麻烦。眼看着距离版 本发布的日期只剩两天了，任务系统上还显示着有好几项关键任务并没有完成，之前明 明说是这两天就可以弄好的。结果到现在，讨论了一个小时，最后才敲定先用加缓存的 方案处理。可这么下来，再加上测试，两天肯定搞不定，要把这个版本做完，恐怕是无 望了。
在整个团队中，似乎只有小云一个人在意，目标是不是可以达成。老实说，在做项目经 理的半年里，他经常感觉自己脑门上写着“监工”两个大字，非常着急，可又觉得无处 使力，只能一个一个去催。那么，这个困境到底要怎么破呢?
一个念头瞬间击中了他:“对了，开每日站会啊!”小云一个鲤鱼打挺，从床上蹦了下 来，连忙打开电脑，却马上又陷入了沉思。
以现在的形势来看，跟团队提出要每天开会?小云都可以想象到大家的反应:“开什么玩笑?活儿都干不完，为啥每天开会?安静写会儿代码不行吗?”
是啊，现在缺的就是这个“为啥”，也就是 why，可总不能跟大家说为了方便自己跟进问题吧，那样大家会买账才怪!小云心想，这次我得讲究“策略”。
重点
很多同学都觉得，自己的项目组中有着这样那样的问题，而且，问题简直太多了。于是呢， 自己一看到问题就想去改变，就想去整治，就觉得这是一个机会
实际上，问题并不等同于 时机，只有把问题和痛点关联起来，才能形成一个好的时机
那么，怎么关联呢?我们接着来看故事进展
分支主题
高峰是这个部门的技术总监，当初就是他把小云提拔到项目经理的位置上的。
在每周一次的周会上，高峰和小云的问题特别得多，不知不觉两个小时就过去了。直到预定的会议室到期，他们被撵了出来，状态还没有同步完。
会后，小云叫住了高峰，直接跟他谈起了自己对目前境况的担忧:“现在我们每周开一 次同步会，总感觉信息滞后得很。如果我们的同步频率再高一点，就能够提早发现问 题，现在也不至于大费周章了。”
高峰没有直接回应，对于小云的建议也不置可否。在他看来，信息同步的问题虽然有， 但整体其实还好。
小云猜到了高峰的心思，进一步说:“如果只是开发的问题，倒还好办，可是一旦涉及 到其他角色、其他模块的支持，事儿就难办了。我们喊了很久要加强测试，加强运维， 可也只是喊喊，喊完之后就没了下文。现在，我们产品的基本功能已经成型，质量和运维才是重中之重啊。”。“没错!”高峰坚定地说。可见，小云的话一下子戳中了高峰 的痛点。
问题：如何抓住痛点，有什么方法？
1. 访谈法，也就是直接问
“你认为项目组当前最大的风险和问题是什么?从你的角度出发，最迫切需要解决 的是什么?”
2. 观察法
实际上，与其看别人怎么说，不如看他怎么做
很多时候，人们会说这个很重要，但是一两 个星期过去了，他也没有投入任何精力，那么这就是个“伪痛点”
去观察那些花他时间和精力最多、他反复强调却又没很好解决的问题，那些才是他 真正的痛点
3. 同理心和倾听
只有你用心倾听，设身处地去理解他人，你才能够准确地感知到他最大的痛点
需要注意的 是，抓痛点的过程，并不是一蹴而就的，你需要多观察、多了解，通过非正式的聊天，了解 他们对潜在变化的态度，找到合适的契合点
总结
在变革的早期，最重要的就是寻找到早期支持者。围绕着你想要引入的变化，击中 几个重要干系人的痛点之后，这个时机就到了
由早期支持者形成的变革核心团队，就会成 为你在推动变化过程中的重要支撑力量
小云心想，终于等到机会了。于是，他把各个角色一起每天开站会的想法，一股脑儿地全告诉了高峰，双方顿时一拍即合
高峰觉得，这的确是个好办法。考虑到人数众多，他们又一起商议了很久，觉得还是有 必要分两组来开站会
高峰说:要不我们一开始还是两天开一次，两个组错开进行吧?小云知道高峰在顾虑什么，连忙回说:刚开始的确需要慎重些
然后是“地利”，学会因地制宜
结合团队的实际情况，为团队定制适合的解决方案，而不是照搬理论或所谓的“最佳实践”
在这个故事中，小云与高峰决定分成两组开站会，每两天轮一次。实践中，你首先要去理解 每个团队现有做法背后的历史原因和必要性，结合每个项目团队的现状，做好本地化的场景 适配，这样才能获得好的效果。
因地制宜的适应性调整，并不是向环境妥协，而是创造一个最小阻力的落地方法，先快速地 跑起来，让团队感受到变化带来的闭环成效!
案例继续
与高峰统一战线之后，小云信心大增。于是，他立刻找来了几个测试，想聊聊看测试这 边怎么分组好。几个人坐定后，小云说道:“现在大家都坐得很近，但是团队之间的沟 通似乎并不是那么顺畅，我跟高峰商量着，想要引入每日站会。”一句话还没说完，测 试巴泰插话说:“我觉得现在的沟通挺顺畅的啊，有什么问题?”
高峰见状，赶紧出来打了个圆场，说:“咱们现在的沟通方式是有事就喊上两嗓子，快 是快，可是很多事情喊过之后，经常就没下文了。”
小云接着说:“是啊，就比方说，开发改个 Bug 没改好，测试等着去测，只好去问开 发，开发说正在修，但几天过去了还没动静。再一看，开发已经忘了这茬儿，做其他的 去了。这种情况，我想测试肯定碰到过，但我猜，巴泰你也不好意思一次次地去问 吧。”
其他两个测试点头应和，说确实是有这个麻烦。
小云继续说:“可是，如果我们每天开站会，花 15 分钟互相同步下进展，问题很容易就 解决了。测试不需要再去找开发催进度了，因为每天开站会的时候，开发自己就会讲进 展。如果测试需要开发重新安排开发顺序，也容易多了。”看到巴泰若有所思地点着 头，小云就知道，测试这边已经 ok 了。
接着小云又找到运维同学，把站会的好处说了一遍，有了高峰和巴泰的支持，进行得还 算顺利。
然后是“人和”，采用不同的策略进行有效沟通
研究表明
企业变革失败的最常见因素就是人的阻力
面对变革，每个人都有与生俱来的情 绪反应。这个情绪，是自动触发的，跟变革的大小无关
大到企业战略转型，小到仅仅是改 变一个会议的方式，只要是引入变化，就会触发情绪反应，人们总是需要一个接受的过程
那么，如何在引入变化的过程中，最大程度地创造出“人和”的局面，让大家更容易接受 呢?
解法就是多聆听彼此，充分理解，找到共同的出发点
现实中，很可能你觉得是对的事情，不同人去看，会产生完全不同的看法
在沟通时，你要 因人而异，针对不同的人，采用不同的策略
那么，如何选用合适的沟通策略?
先判断立场
立场，是指人们在认识和处理问题时所站的位置。立场不同，看问题的视角就不同
在具体操作时，你可以把变化涉及到的干系人，按照角色和层级做个初始划分，思考下不同区域的人，会怎么看待这个变化带给他的影响
你要做的就是，找出更多的积极因素
比如，通过开站会，测试可以更及时地获知和影响开 发的进程，这对于测试来说，就是一个积极因素
同时，对于变化所带来的消极因素，你要 提前引入相应的工具或方法来规避或改善
除此之外，就算是立场一致的两个人，也会因为基本假设和价值观的不同，对同一件事有不 同的解读，从而呈现出截然不同的态度
所以，在大范围公布并引入变化之前，与关键角色进行一对一的沟通，是更稳妥的做法。
案例继续
这天，又是一次例行周会。同步完状态之后，近两个小时已经过去了，屋里闷热得很， 大家都有些焦躁，有人凑在一块儿开小会，有人低头玩手机。
小云感叹道:“现在我们每次周会的时间好长啊，一转眼，两个小时就没了。”大家早 已经开会开得有些生厌，经小云这么一说，纷纷吐起了槽。
小云示意高峰来说两句，于是，高峰就把早就讨论好的分组开站会的想法，讲了出来。
小云接着补充说:“我们现在有 15 个人，开一次周会要花费所有人 30 个小时的时间 (2 小时 *15=30 小时)。可如果按照刚才高峰的提议，每个人每周开两次站会，也就 花 30 分钟，能给每个人节省一个半小时的时间!”
大家显然心有所动，有人笑着问道:“那以后的周会是不是也不要开了?”
小云说:“以后每周五前，我会收集下大家的议题，如果有需要全员讨论的，我就另行 组织周会，没有的话，那就默认不开啦!”看大家的一脸高兴劲儿，小云就知道，这时 已经大功告成了。
总结
总体来说，在引入变化的过程中，面向全员的正式公开沟通，一般会放在最后
因为这时， 关键问题和主要影响已经处理好了，路障也都清理干净了，变化自然就是水到渠成的了
总结
1、新手项目经理在引入变化的过程中，最关键 的三个因素
天时
首先，你要选择合适的时机
地利
然后，找到因地制宜的解决方案
人和
最后因人而异，采用不同的策略进行有效沟通
2、如何把项目管理方法引入团队
最难的其实不是那些招数，而是 招数背后的你的发心
之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么
只有解决了大家的问题，这个变化才能 最终被所有人打心底里接纳
3、信任是基础
所有这一切的发生，必须建立在信任的基础上
这个信任不仅仅是对你能力的信任，更重要 的是，你是否能够站在对方的角度设身处地地思考问题
当你是在真心为他着想，为他解决 问题的时候，对方自然会愿意接受你所带来的变化
敏捷应用实践
为什么引入敏捷?
敏捷的特点，就是小即是美(Small is beautiful)。这个小而美，体现在人、事、时间三 个方面:
1. 人:拆分成小规模(5~7 人)、跨职能的小团队;
2. 事:拆分成一系列小而具体的交付物，按优先级排序，增量交付;
3. 时间:拆分成固定大小的短迭代(1~4 周)，在每个迭代结束后，对可工作的产出进行 演示。
总体来说，就是用小团队在小块时间，做出小块的东西来，并且周期性地集成组装
痛点一:发布时间不可控(快速的增量交付)
考虑到项目的实际背景，我们把迭代周期定为一个月。我们每个月都会跟内部客户一起做 Sprint 计划及 Review 演示。这种做法，给我们带来了哪些改进呢?
提早集成与测试
这让问题得以及时暴露，带来了更快的反馈及应对;
及时规避风险
意外仍然会有，但大多数情况下，我们可以在 Sprint 内部消化掉，避免更大的影响
快速响应变化
在 Sprint 1 演示会后，我们收到了新客户提的紧急需求，立即做了相应 的调整。如果按照之前的模式，这个时候，可能很多事情我们都只做了一半，想调头没 那么容易。短周期让我们可以灵活调整方向，每个 Sprint 都是潜在可交付的产品
另外，在 Sprint 3 之后，我们临时安排了一个小的 Sprint，用来快速地将“潜在可交 付”变为“真正可交付”
我们发现，在每个周期内，能够真正把事情做完，跟我们的最终 用户一起分享阶段性成果，对团队来说，也是非常好的激励
这时，发布周期的问题已经基本解决了，我们的交付灵活性高了很多，客户也更满意了。那 么，我们是否可以号称是个 Scrum 团队了呢?
痛点二:摆脱“接力综合征”(从对抗走向协作)
经过仔细地观察和总结，我发现，团队各个角色之间的协作方式仍然存在着一些问题，我把 这叫作“接力综合征”。虽然交付周期变成了每月一次，但大家却仍然在按照过去的方式工 作。具体表现有以下两点:
1. 宁愿选择等待
每个人都等着上一环节的人把东西弄好送到自己面前来，才能开始工作
比如，我经常听到 这样的说法:“需求文档还没理清楚，急啥?”“接口设计文档还没确认，怎么做啊?”这 种情况，在传统的项目管理中是很正常的
但是，这些空耗的时间，并不能给产品带来直接 的价值。
2. 角色间泾渭分明
每个人都觉得，只要把自己份内的事做完就行了
比如，开发把工作做完了，也不管做得效 果咋样，心想:“反正要丢给测试，我先撤了，测出问题再说。”测试测出来 Bug，心 想:“等开发全部修完，我再接着测，反正我都测完了。”
在这种情况下，各角色之间是有一定的对抗的
项目中的任何一件小事都有可能造成冲突
最终大家都耗在那儿，每个人更在意的是“这是你的问题，不是我的问题”，却没有把焦点 放在达成整体目标上
在传统的项目管理中，项目经理的很大一部分工作就是要厘清各方责任，界定权利与义务， 疏通对抗情绪，并解决随之而来的突发问题
但在敏捷的情境中，更加快速的交付压力，使 得这种等待和界限变得越来越不可接受，我们不得不改变思路
敏捷的打法，就好比是打橄榄球，所有队员都时刻关注着场上的比分
虽然彼此之间有分 工，但作为一个 team，进球才是最关键的。敏捷也是一样。我们从敏捷思想中得到启发， 开始进行一系列的改进。
首先，开发和测试把位置搬到了一起，并且设定了共同的 Sprint 目标和完成标准。
开发做完了工作以后，如果发现测试进度被卡，就会跟着一起着急，一起想办法解决问题，因为这影响到了整体的进度。
其次，从“你完成 - 我开始”，到我们一起完成
在敏捷团队中，开发干得热火朝天的时候，测试也没闲着，测试代码与开发代码几乎是同时 在写的
往往代码刚“出炉”就测上了，而且只有在测试结束并确认没有 Bug 的时候，开 发的工作才算结束
我们使用故事点燃尽图，来衡量整体进度的偏差，并且团队会约定好，只有一个功能点完全 测试通过，燃尽图才能往下走。这个燃尽图成了团队的计分牌，每个人都关注着同一个目 标。
同时，我们还发明了里程碑燃尽图，用来衡量每个迭代对于整体进度的贡献，以及多个迭代 之间累积需求总量的变化，相当于一个赛季的累积记分牌。我给你分享一份燃尽图型项目进 度模版，你可以点击网盘获取，提取码是 pmx8。
这些措施打破了角色之间相互切分和推诿的局面，共同的目标让我们变成了一个价值共同 体。毕竟，只有协作，才能达成目标
痛点三:需求理解不一致 (面对面澄清及估算)
至此，团队的力量得到了很好的凝聚
在复盘会上，大家畅所欲言，共同讨论了下一个待改 进项，那就是是需求理解。这应该是技术类项目的一个共性问题
当时，我们团队没有专职的策划，开发人员在理解需求时，经常会感到非常困难
我们打开 敏捷宝箱，找到了一条重要的价值观“个体与交互 > 过程与工具”
相比于更多、更长的 需求文档，我们决定采用更多的面对面交流来解决这个问题!
于是，我们把迭代计划会分成了两个部分:
1. 产品负责人向团队和用户代表，面对面地讲解收集来的各方需求，最终明确需求的优先 级及验证条件，也就是说，在迭代结束的 Demo 演示会上，我们要给用户呈现什么。
2. 团队估算。我们采用敏捷估算扑克的形式，由团队成员共同给出估算结果，最后综合得 出这个迭代要交付哪些内容。
团队估算的过程，其实是个双向互动的环节，可以帮助团队和产品负责人共同加深对条目的 理解。同时，产品负责人也会根据大家的反馈，及时修改条目，完善条目。
具体估算时，为了避免干扰估算结果，当所有成员选择好代表自己估算值的纸牌后，大家同 时亮牌。同时亮牌的好处是，不会有人跟风出牌，每个人的估算都是经过独立思考得出的， 这也是扑克估算的精华所在。
如果估算值差距明显，代表大家对该条目的工作量没有获得共识，团队需要对该条目的评估 结果进行讨论，由最大值和最小值的牌主，分别说明自己的估算理由，并重新讨论，确定最 终的评估结果。
经过实践检验，这样面对面的需求沟通及评估，至少带来了以下三方面的好处
1. 需求探索更深入。
在计划会上，团队会直面一线用户，需求可以得到面对面的交流和澄清
另外，团队估算其 实也是一个团队共同探索需求的过程。因为只有到真正考虑要花多少成本去做的时候，才会 有各种各样的问题暴露出来。这个方法对于在早期进一步挖掘需求细节，特别有帮助。
2. 估算结果更加全面、细致。
在传统的项目管理中，我们也做估算
比如，WBS 分配好了任务，然后每个人估算自己 的。因为每个人都只对自己的那部分任务比较熟悉，估算时往往会有欠考虑，而团队估算， 就很好地补足了这一点。
每一个故事都会由全员出牌，各方从自己的角度出发想问题，可以互相补充。比如，在估算 时，测试的成本也会被考虑进去。对于测试成本高的功能点，开发会主动想办法加强单元测试等白盒测试手段，这样一来，估算结果自然更细致、全面。
3. 找到了更优的整体解决方案。
由于各方共同参与估算，前端、中间层、后端、测试的思路可以在一起交流碰撞，这样就非 常利于找到最优的解决方案。
我们团队的这一系列敏捷尝试，始终都是围绕着项目中切实的痛点展开的
从最开始缩短发 布周期、经常交付可工作的软件，到应对“接力综合征”，提升团队的整体目标感和协作效 率，再到探索更加有效的需求理解及团队估算方式，在增进团队交流的同时，又保障了需求 质量。
敏捷实践的应用，为我们带来了诸多好处:
1. 提升客户体验
更低的延误率
阶段性可见的产出
更快的反馈、适应与调整
2. 提升管理者体验
团队自主运行，管理更轻松
变“赶”为“引”，为共同目标奋斗
3. 提升团队体验
更高的生产力
更强的责任感、主人翁意识
向上沟通
向上沟通的三个误区
误区一:所有问题，都自己扛!
迈过自己内心的那道坎，主动大胆地发起沟通，是做好向上沟通的第一步
不管通过什么途径，我们必须时刻从大局出发，让这些项目关键信息，及时 有效地流动，保障及时有效的决策
你不需要所有问题，都自己扛
误区二:只知道吐槽，不知道争取
尽自己的努力帮团队解决问题，脏活累活都自己来
把“夹心饼”变成“连接器”，成为高层干系人与团队之间紧密联系的纽带
当需要高层重视和支持的事件发生时，该出手时就得出手，引发高层关注， 把团队最一手的相关动态信息及时传递给他，争取高层必要的支持，而不是跟着团队一起吐 槽
误区三:抓不住重点，给不出方案
“团队现在加班很严重”“团队任务不及时更新”“某某工作不主动、总是迟到”......如果 你只是这样反映问题，只是说这里不好、那里不好，却没有告诉他，为什么要关注这个问题 的话，你的意见不仅不会得到重视，甚至还会产生反效果。
你要 反映的问题，与高层干系人的核心关注点是否相匹配，这是能否引起其关注并进一步行动的 关键所在
在向高层干系人提问题的同时，一定要给他一个明确的“点”，让他知道，为什么要关注这个问题
抓住重点，高效沟通
找到“核心关注点”
用数据和事实来作“论点”
给出一个小小的“行动点”
跨部门沟通
应对跨部门沟通的方法
约法三章，先说清楚
第一步:建立君子协定
在合作前，你要跟对方建立合约，明确合作目标、合作事项、双方各自的需求和责任、时间 进度要求、风险及责任人
建立合约时，要由双方负责人进行邮件确认，公开做出正式的承诺
注意
在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得 到公开确认
否则，这些问题如果不明不白的话，就会给后续工作带来极大的隐患
第二步:建立机制
实际现象
眼看着要到联调的 Deadline 了，对方的任务还没完成。我问了对方之后，才知道，说好的功能接口不能准时交付了。他们给出了很多原因，比如，工 作比想象得复杂，还有人员休产假、离职等等
建立机制
合作建立之后，需要建立常规的沟通机制来持续推动
比如，项目信息开放共享，每周在固定的时间开碰头会，双方相关人员交流工作进展及风险情况
更进一步的话，你还可以借助 标准的任务管理和文档管理工具，对项目任务和文档做到统一的流程化管理，在过程中确保 及时地跟进检查
流程自检
常规机制及工具搭建好之后，在运行过程中，你还需要经常自检，确认下流程上是否有疏忽的地方
比如，是否存在“三不管”地带?每个依赖任务的职责是否明确，责任是否具体到 个人?
如果你发现了模糊地带的存在，要及时明确需要共同协作的内容是什么，该由哪个部门、哪 个人负责，做到权责分明和分工合理，避免后期出现相互推诿、扯皮的情况
第三步:解决问题
实际问题
通过周期检查，我们可以及时发现问题。但是，如果事先约定好了，并做了周期检查，对方 负责的事情还是出问题了，该怎么办呢?
有同学会说:“找他们领导!”在跨部门沟通中，打出领导牌，的确会起到一定的作用。但 是，这张牌属于“王炸”，不到特别时刻，不要随便拿出来用
在找领导之前，建议你先自己摸清楚状况，尽快启动风险应对机制，确定问题处理方案，比 如改变方案、调整时间、增加资源、减少范围等
另外，你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影 响及调整方案
同时，你还要明确的是，今后要采取哪些预防措施，以避免问题的再次发生
什么时候该找领导呢
实际情况
两边的领导已经达成了正式的约定，但是，不是每个牵涉进去的 协作方都会立马配合
原因很多
比如，这个部门的 KPI 早就定义好了，目前上面的领导虽然认可了合作方 案，但是没改 KPI，原来的目标依然有效
对于这部分新增的工作，他们要额外投人去做。 因此，他们非常担心，虽然增加了工作量，但产出却不受领导的重视
解决措施
类似这种会影响合作落地的根本机制问题，你就需要引入双方的领导，来一起研究解决方案
比如，在双方的绩效考核指标中，加入跨部门利益的指标，来强化这种目标和利益的捆 绑，让双方真正把劲往一处使
总结
1、首先，在项目合作开始时，要努力争取合 作部门上级领导的支持，达成明确公开的“君子协议”，建立稳定的合作预期
2、然后，你要 建立周期检查机制和标准化的流程，而不是想起来才问一句
3、最后，对于执行过程中的问 题，及时跟进解决，对于涉及合作机制类的问题，要及时请双方领导介入进来
打开边界，一起想办法
尽管不是自己人，咱还是要把对方当成自己人看待， 好，就一起好;出了问题，大家就一起扛
案例分析
X 项目是一个非常典型的跨部门、跨职能的大型项目集，项目组人员接近两百个，涉及到的 跨职能小组就有 12 个
由于技术复杂性，各模块之间的依赖和耦合很强，再加上各业务模 块都有自己的目标和优先级，跨部门沟通的成本很高
在这样的背景下，每个业务模块都反馈说:“跨部门协调这个事，太难了。”一个很小的改 进，可能就需要交互、前端、中间层、后端、各模块的测试都参与其中。即使只是组织一个 会议，要想把人叫齐，都颇费周折
这种跨部门的协作，已经融入到每一天的工作中了。这时，“约法三章”的沟通方式，显然 已经不适合我们了。那怎么办呢?
解决措施
首先，要建立统一、清晰的节奏感。
你需要结合不同业务模块的功能、相互之间的依赖关系，来为各个业务模块设计统一的交付 节奏，也就是根据项目中的关键依赖，把交付时间错开排布
比如，在 X 项目中，我们在每个月固定设置了四个发布窗口，分别是 5 号、10 号、15 号 和 20 号。接着，根据这 12 个模块的先后依赖关系，我们把它们安排在不同的窗口进行发 布
在此之前，这些模块的发布时间都是自行定义的，现在，每月有了统一的规划和交付节奏， 协同复杂度降低了很多，因为彼此之间有了稳定的交付预期和协同基准
注意
需要注意的是，节奏的设定没有固定模式可循，你需要在自己的情境中，尝试总结规律，并 把它们固化下来
有一个指示性的指标，就是重新设定节奏之后，如果跨部门协调的问题明 显变少了，那么，当前这个节奏就是更合适的
其次，想要打开边界，你还需要主动往前一步。
对于这个项目集里的 12 个子业务模块来说，每个模块既可能是底层服务的用户，同时又是 上层服务的依赖方，彼此互为上下游。在这样的情况下，如果没有彼此的通力合作，那就谁 也做不好
曾经，我见过两个部门的负责人来来回回地在邮件里争吵，据理力争地互怼。后来，因为实 在无法直接沟通了，他们就跟我说:“给我们加个项目经理吧。”
在了解了需求之后，我发现，每个模块的日子都不好过，要么是被需求的反复弄得焦头烂 额，一肚子怨气，说:“明明之前都约定好了，需求还是说变就变。我辛辛苦苦做出来了， 说不用就不用，全白搭了。”要么是被频繁的依赖问题折磨得陷入“水深火热”的境地，纷 纷吐槽:“底层服务又出问题，害我挨用户一顿臭骂。整天出问题，真是拿我们当小白 鼠。”
不管是哪一方，每个人都盯着别人的问题，同时捂住自己的问题。像这样的情况，就算是再 放 10 个项目经理，估计都很难从整体上改善局面。那么，该怎么办呢?
在和项目集的高层领导一起深入地剖析了现状之后，我们都认为，“头痛医头，脚痛医 脚”的方式，并不是我们想要寻求的解决方案
于是，我们在 Leader 层发起了一次跨部门的交流讨论，取名为“上有老，下有小”，意思 是，在这个项目集生态里，各个模块是层层嵌套在一起的，每个模块都在持续建设中，还远 未成熟。上面，有人要调用我的服务;下面，我要依赖另外一个服务提供底层能力。每个模 块都是“上有老，下有小”，如果我们想要获得整体改善，该怎么做?
我们收集了大家的改进建议，并进行了统一整理，形成了我们所定义的“担当力模型”(如 下图所示)。这个模型总共分为四层，它们分别描述了我们在遇到跨部门沟通的问题时的四 种不同心态和行为。
担当力模型
担当力模型.png
第一层:放弃
这背后的心态是:“见怪不怪，反正我已经绝望了。”抱着这种心态， 于是，你就什么都没做
第二层;责怪
这背后的心理是:“你怎么搞的，每次都这样?”这样想着，你依然 是，什么都没做
第三层:完成任务
这背后的心态是:“真是不省心，下次我得特意盯着你点!”抱着 这种完成任务的心态，你会针对问题做全面的排查，增强对应的监控
第四层:担当
这一层的表现是:“出问题不可怕，但我们绝对不能再犯同一个错误。”你会把错误当作完善的机会，帮助用户方和依赖方共同成长
我们把真正的担当解释为“上敬老，下爱小”
什么意思呢?上敬老，是说对于用户方，你 要去主动深挖用户方的需求及业务背景，走在用户前面
下爱小，是指对于依赖方，你要全 面监控、必要容错、并帮助它不断改进
总结
通过这次的深入讨论，我们认识到，只有各个模块都往前走一步，才能够引发系统的改善
与其去责怪对方，不如跟他一起找到合作共赢的方式，最终让所有人获益
这四层担当力模 型，本质上是心态上的差异，而每次主动往前一步，最终必将体现到工作的长期效果上，从 而形成持久化差异
怎么区分什么时候该使用哪种方式
看双方之间的依赖关系和合作性质
如果更多是单方面依赖、单方面受益，且是 一次性的合作，第一种方式会更加适合
如果是互相依赖，而且是长期合作的共生关系，那 么，你就不能只考虑短期利益了
跨部门协作难的根源
在于边界所引发的“分别心”，也就是你是你，我是我
如果执着于你我之间的“界限”，必然会导致各种摩擦
也正因为这样，在跨部门合作 时，你需要付出更多的努力，在保障项目推进的同时，用心经营、维护良好的合作关系
总结
共同目标、利益捆绑、流程约束是基础，除此之外，你还需要更加开放的心态，去找到更多 合作共赢的方式，共同做大事业
向下沟通
如何在团队中让自己拥有更大的 Power
项目经理无权无势，别人不听你的怎么办?
如果你想靠自己的力 量，让别人真心信服，并没有捷径可走。你只能从自身做起，在一点一滴的行动中，从头构 建非职权领导力
非职权领导力的六力模型
“六力”分别是执行力、 信息力、感知力、透明力、影响力和整合力
这六力是层层递进的关系，代表了非职权领导 力发展之路上的六个层次
执行力
执行力是非职权领导力的根基，俗称“靠谱”，这是项目经理的立身之本
我们判断一个人 是否靠谱，往往是在说这个人是否具有两个特征
主动担责
有始有终
主动担责
管好自己的一亩三分地，并非就是执行力好。
案例
比如，我见过很多策划，在写好策划案之后就甩手不管了。但是，我曾遇到过这样一位策 划，他不仅把自己的本职工作做得很出色，还会帮忙给所有策划制作一张总进度表，即时同 步信息，汇报进展。
如果中间过程出现了问题，比如开发跟测试发生了冲突，他也会主动想办法协调解决，推进 项目落地
一段时间后，他被 Leader 点名表扬，很快从几个同级中脱颖而出，得到了晋升。我问 他:“你为啥做这么多事?”他笑笑说:“也没啥，我就是很想看到整个产品都做得很好， 不能忍受有些环节出了问题没人管，没人上，那就我上呗。”
所以，你看，执行力的第一层，并没有什么神奇的，你首先需要跳出自己的小圈圈，主动承 担更大的责任，而不是眼睁睁地看着项目出现问题，放手不管
有始有终
言必信，行必果。交给你的任何事情，都有始有终。当很多人都只是在完成任务时，如果你 懂得闭环的重要性，势必会事半功倍!
案例分享
当时，我在团队中发起了一项“零 Bug”的改进活动，后来因为一些原因没有坚持做下去
她在了解了情况之后，很严厉地跟我说:“作为一个项目经理，你发起的任何一件事都 要有‘Close’的动作
你既然跟团队讲过要做这件事，现在不做了，就算自认为原因再合 理，都需要给大家一个交待，而不是不声不响地就停止了
闭环理论
一个有始有终的闭环，意味着你要对自己的每一个行为负责，清楚地了解为什么 做，目标是什么，做完之后效果是怎样的，还有什么问题，以后要做哪些改进。如果中途有变化，也要及时跟相关方明确说明调整或取消的原因是什么
总结
想要做一个“靠谱”的人
第一，跨出自己的边界，主动担责;
第二，言必信，行必果，做事情有始有终
一屋不扫，何以扫天下?执行力可以说是你能够影响他人，继而具备非职权领导力的根本。
信息力
在大数据时代，谁掌握着数据和信息，谁就拥有更强大的力量和权力
在大数据时代，谁掌握着数据和信息，谁就拥有更强大的力量和权力。由于自身的职责和信 息渠道的便利，项目管理人员会很容易成为团队中拥有最大信息量的人。大到全局的战略、 项目的初衷和发展方向、决策的起因和前后变迁，小到每个团队每天在干什么，都尽在项目 管理人员的掌控之中。因此，项目经理就好比是项目信息的交换中心
案例分享
我曾遇到过一个项目经理，他就拥有这种神通广大的信息力。不只是项目组里，甚至是公司 里上上下下发生的事情，他都能第一时间获悉。所以，遇到拿不定主意的事情时，我经常向 他打听消息。
有一次，我忍不住问他:“你到底是怎么做到的?”他说:“没什么神秘的，我这个就是好 奇心强，而且比较热心。我对别人很感兴趣，就会经常跟大家多聊几句，不管聊的东西有没 有用，我都记得清清楚楚。而且，我还特别喜欢帮助别人。比如，我觉得某个机会适合某 某，我就会推荐他去试试看。久而久之，大家就会主动给我提供信息，让我帮忙出谋划策， 所以我就成了最有信息力的人啦!”
信息力可不只是掌握简单的八卦，而是要让流动的信息汇聚起来
作为初学者，你可 以通过信息互通机制和平台来帮助自己做到这一点。比如，周会、站会、周报、邮件列表、通讯群，甚至是各类数据平台，都可以成为信息力的承载
除此之外，能够让非正式信息自动流向你，就属于内功的范畴了
在与人交往与合作时，好 奇、关心、真诚、友善......这些特质都会帮助你构建起信任基础
连接多了，覆盖面广了， 自然会形成规模效应和网络效应，这时就会产生信息力的红利了
感知力
感知力建立在信息力的基础之上，不同的是，感知力是对“冰山下”隐性信息的敏锐度。这种对系统敏锐的感知判断，俗称“闻味道”
据说，马云就是个“闻味道”的高手。如果他出差一个月不在公司，那么，他回公司之后做 的第一件事，就是把十层楼的办公区都跑一遍，然后找副总们开会，精准地说出公司存在的 问题，观察之细密往往让人佩服至极
感知力是日积月累的功力，但也并不是什么深奥的功夫，你也可以做得到，重点就是平常在 开会时，你要多练习、多观察
案例分享
举个例子，某业务负责人请我给他的管理层做一次共创会，请大家根据总体规划，各个角色 共同定义下半年各自的工作重点。拿到这个需求之后，我先跟几个管理者开了一次沟通会。
会后，我找到这位负责人，跟他同步了我对管理团队的观察，并且提出了我的共创方 案:“在这次共创之前，我们必须先有个复盘环节，否则，以咱们团队现在的这种合作状 态，根本没法很好地共创。咱们得提前准备，我需要你的大力配合。”
他很快就认可了我的方案，并且惊讶地问我:“你是怎么做到在这么的短时间内捕捉到这么 多复杂的背景信息的?”
你可能也很好奇，事实上，这就是感知力在现实场景中的运用。要想培养感知力，你需要经 历三个层次。
体会到这些之后，你会发现，如果不事先处理好这些强烈的感受，这些人是根本没有办法在 一起很好地进行共创的
于是，在共创开始前，我安排了一个之前提到过的复盘环节，就是让每个成员画出自己从项 目启动以来的状态、经历，并把其中的“高光时刻”和“至暗时刻”分享给大家。
当天，这位负责人第一个发言，跟大家分享了开创新业务以来自己的坎坷经历。他的开放和 坦诚让大家一下子轻松了许多
接着，轮到产品，她提到了刚上线就被苹果推荐的成就和喜悦，同时又分享了最近“两头受 夹板气”的惨痛经历。开发同学则拿出自己的画，说自己自始至终都是“压力山大”，从来 都没轻松过......就这样，大家开始一点点地敞开了心扉。
那些平时看不到的真实一面，被集体看见和理解之后，团队内部淤积的压力也终于得到了释 放。于是，大家开始聚焦在共创下一步真正有效的解决方案。
培养感知力的三个层次
第一层:现象层。这一层观察的焦点，是在“冰山上”的行为
比如，你观察到开发和产品 在会上吵起来了，这时，你注意到的是行为，还不是真正的感知
第二层:意图层。这一层观察的焦点，是在“冰山下”行为背后的真正意图。具体要怎么做 呢?最简单的是，多问几个为什么
比如，他们为什么会吵起来，各自想要达成什么目标。
仔细思考之后，你会发现，原来技术已经对于产品的频繁变更忍无可忍了，技术 Leader 有 很大的压力，想要为受苦受难的开发们出头;而产品的意图也很直接，他们的想法是:“业 务 KPI 在那儿摆着，咱能不能别那么磨叽?快速推进不行吗?”观察到这一层，你就很接 近冲突的根源了
第三层:感受层。你要试着从这些现象和意图中，去感受每个人的状态和需要
你会发现， 开发的核心感受显然是愤怒;产品直接承担着业务指标带来的高压，老大的想法又一直在 变，技术的不配合让他们受到双面夹击，早已是苦不堪言，核心感受是苦涩
总结
总之，要想培养感知力，就要在日常的观察之中下功夫。从关注行为，到关注行为背后的意 图，再到关注意图背后个体的核心感受和深层需要，最后着眼于团队中的气场和互动品质。
这样一来，你就能找到“四两拨千斤”的杠杆点，从“救火式”的应对问题，变成“治未 病”的先知先觉，从而在团队中积累起自己的独特影响力
透明力
我在上一讲中提到过，信息力和感知力是对环境的观察、观察、再观察。你需要注意的是， 这些观察的结果只有透明出来，才能发挥效用
你要想办法把你看到的问题可视化，让决策 者和团队都能看到这些问题。这就是我经常说到的透明的力量
怎么运用透明的力量呢
案例分享
我在一个团队中经常听到这样的声音:“搞什么需求评审、交互评审?要做什么先说好，然 后就别再来烦我了。让我安静地写会儿代码，不行吗?”
于是，这些评审会能不开就不开。结果，在 Deadline 之前，需求稿、设计稿和技术方案的 问题不断爆发，要熬上好几个通宵，才能保证版本的正常发布。但是到了下一个版本，情况 依然如此，循环往复。
经过仔细了解，我发现，如果在早期投入精力的话，这些导致发布延期的大多数问题都是可 以有效避免的，发布的风险也会大大降低。
实际上，定位问题并不难，但是要想解决这个问题就很难了。因为这个团队三四年来一直都 是这样，他们早就已经习惯这种模式了。
问题解决思路
想要引发改变，不是仅凭一人之力就可以做得到 的。要打破这个恶性循环，就一定得让大家真正地看见问题，并且从心底里达成共识
透明化呈现的方法
分析−思考−看见
前者走脑，是指借助数据、事实、逻辑分析等，调动头脑的智慧，创造共识
目睹−感受−看见
后者走 心，是指运用图片、视频、故事等形象化的元素，调动情绪的力量，创造共鸣
项目问题该如何解决
在一次版本总结回顾时，我给大家讲了一个“熊猫大侠”的故事。这位“熊猫大侠”是一个 苦兮兮的程序员，他有着熊猫一样的黑眼圈，他的黑眼圈是怎么来的呢?
我以这个问题为切入点，以故事的形式带领大家回顾了整个版本进行过程中的一幕幕场景， 从上个版本结束时的“累觉不爱”，需求评审会上的睡意朦胧，讲到提测前对设计方案的争 执不下，最后到上线前的“兵荒马乱”
“熊猫大侠”的故事，使团队成员深度地看到了项 目的现状，并产生了共鸣
接着，我晒出了各种过程数据，包括需求变更率、需求和设计问题发生的阶段及成本、各阶 段等待时间、研发负荷度等，邀请团队一起来想办法解开 Deadline 的“魔咒”
看见这些事实和数据之后，大家才真正地意识到早期那些看似无聊的评审工作的重要性。除 此之外，团队还进一步定义了各角色的协作规则，以达到更合理的节奏
最后，在团队的共同努力下，我们进一步建立了基于过程数据的效能改进机制，各角色的协 同状况得到了持续的改善
想要改善什么，就把什么透明化!在走脑的同时又要走心，让团队的所有人都 看见问题，调动起集体的关注力和改变的动力
这样的话，这种透明的力量就会自然地推动 变化的发生
影响力
项目经理无权无势，行走江湖，靠的是大家肯买你的账。能让他人买账的这种影响力，对个 体来说，就是说服力;对群体来说，就是感染力
人们通常认为，要想提升影响力，一定要能讲，会讲
但很有意思的是，影响力的真正秘诀 却在于“听”，而不是“讲”
案例分享
我们在听马丁·路德·金的演讲时，往往会觉得非常震撼。这是因为，真正能够征 服人心的演讲都具有强大的说服力和感染力，而这些都是建立在对听众的深度理解的基础之 上的
因为理解，所以才能创造共鸣。如果演讲者自己激情澎湃，但听众并不受用，那根本 就无法产生真正的影响力
我曾经跟一位产品总监合作，他本人聪明又强势，属于公认的特别难搞的类型。有一次，他 主动跟我说:“别人跟我讲话，我向来只听两句就忍不住想打断，但是你说的话，我几乎全 都听完了。”
他之所以会这样说，并不是因为我的表达能力比别人强、我的逻辑更清晰、我的话更有道 理，而是因为在他讲话的时候，我做到了真正的听
跟其他人相比，我更懂他的逻辑，我明 白他是出于什么样的考虑，才会那么说、那么做的
我给他提的每一条建议都是建立在我对 他的理解之上的，所以才能被他听进去
不听，是一切沟通问题的根源
要想增强你的影响力，你需要先培养“听”的能力
如何培养“听”的能力
你可以找一位项目中的成员，请他聊一聊，在最近的工作中，他有 没有什么高兴或者烦恼的事
在听他说话的时候，你一定不要打断他，也不需要特意去想自 己该怎么回应
你只要简单地把注意力放在对方身上，清空你的思绪，打开你的所有感官，留心去体会对方 的状态和需求就可以了
试着保持至少五分钟的专注，并在结束后记录自己的体会
同时，我鼓励你跟对方分享一下，在刚刚的对话中，你留意到了什么
另外，你也可以跟他 沟通下，有没有什么事情是你可以帮他一起做的
实际上，在真正有说服力的对话中，恰恰并不存在什么“一定要去说服”的想法，这又是一 个有意思的悖论
实际上，只有当你真诚地抱着想要了解和倾听对方的愿望，放下对自己的想法的执着时，你 才能留意到对方真正的需要
这样自然的交流分享，反而更容易产生碰撞，引发共振
如果你能够在你的每次工作对话中有意识地坚持运用这个小练习，半年之后，你的影响力就 能够得到很大的提升
整合力
在一个业务团队中，除了总负责人之外，项目经理往往是唯一站在全局层面的人
毕竟，其 他人都各有各的职责分工
在这样的定位之下，项目经理一定要成为一个“多面手”
因此，优秀的全局整合能力非常关键
简单来说，整合力就是把互相分离的部分连接在一起，使它们发挥出整体作用的力量
一群 优秀的人结合在一起，也并不一定能成为一个优秀的团队，不一定能真的做成一个业务
作为项目经理，整合力就意味着你要去主动发现项目组中的各类风险和问题，综合运用各种 能力，跨部门、跨角色地整合资源，以实现全链条的共同目标
定义
凡是能促进业务良性运作的，凡是能促进团队健康发 展的，都是整合管理的范畴
案例分享
举个例子，我身边有个项目曾经遭遇到了发展上的瓶颈，军心溃散，士气低落，这时，我就 变身成了教练，借助教练技术，给业务负责人及核心团队“照镜子”，帮助他们看到限制他 们的模式到底是什么，促发团队进行深度思考和交流，共同梳理出当前局面之下最好的思路 和打法，从而帮助团队更好地走出困境。
所谓的整合力，就是不受限于你自己的角色、从头到尾把事做成的能力。这种 整合力来源于你对项目环境的观察和感知，最后要落地到全局层面的行动中去
总结
如何让自己在团队中拥有更大的影响力呢
“六力模型”为你提供了一个知行合一的框架
在“六力模型”中，执行力是从现在的“行”开始，想要影响别人，就要先做好自己，走出 自己的小圈圈，去承担更大的职责，并且把你在日常执行中遇到的每一个问题，都视为一个 开启新循环的机会
信息力和感知力是指你要不断拓展自己对环境的准确认知和把握，观察、观察、再观察，从 复杂的系统中找到一个恰当的发力点，通过把它有效地透明出来，让集体共同看见，从而获 取新的共识，也就是新知
最后，你还需要通过影响力和整合力去践行这个新知，反向影响和改造环境，最终推进新知 的有效落地
实践中的“六力模型”
前面提到的刚刚升任项目经理的小勤，她认为“六力模型”对她帮助 很大。之前，她发现产品的问题不是在于研发环节，而是在于销售和研发环节的脱节，可是 她很难改变这个现状，她担心直接指出问题的话会得罪别人
在把研发过程梳理清楚之后，她开始着手收集相关的数据，并且做了大量的调研和分析，摸 清问题对整体的影响(信息力)，然后去感知项目中各个角色的声音和诉求，这让她找到了最迫切想要改变的力量(感知力)。接着，她想办法把问题透明给销售主管及各部门的负责 人，引发了更大的关注(透明力)。除此之外，她还主动找各方讨论可能的应对方案，促成 变化的发生(影响力)。最终，她推动这件事被列为部门下个阶段的重点改进目标之一(整 合力)
现在，这个销售环节的漏洞早已被堵上了，销售和研发之间的衔接流程更加规范化、透明 化，甚至还因此增加了相应的考核项。
小勤用自己的实践给我们展示了“六力模型”的魔力。这个知行合一的闭环，是从“行”开 始，到让团队获得“新知”，再落地到“行”的转变过程。很显然，这个过程让小勤在团队 中积攒了更大的影响力!
0 条评论
下一页
