项目管理实战 20 讲
2022-10-20 20:23:59 2 举报AI智能生成
程序员项目管理实战 20 讲
作者其他创作
大纲/内容
迈过自己内心的那道坎，主动大胆地发起沟通，是做好向上沟通的第一步
不管通过什么途径，我们必须时刻从大局出发，让这些项目关键信息，及时有效地流动，保障及时有效的决策
不需要所有问题，都自己扛
误区一：所有问题，都自己扛
误区：尽自己的努力帮团队解决问题，脏活累活都自己来
把“夹心饼”变成“连接器”，成为高层干系人与团队之间紧密联系的纽带
当需要高层重视和支持的事件发生时，该出手时就得出手，引发高层关注，把团队最一手的相关动态信息及时传递给他，争取高层必要的支持，而不是跟着团队一起吐槽
误区二：只知道吐槽，不知道争取
只是说这里不好、那里不好，却没有告诉他，为什么要关注这个问题的话，你的意见不仅不会得到重视，甚至还会产生反效果
要反映的问题，与高层干系人的核心关注点是否相匹配，这是能否引起其关注并进一步行动的关键所在
在向高层干系人提问题的同时，一定要给他一个明确的“点”，让他知道，为什么要关注这个问题
针对提出的问题，列举可能的解决方案，这一点非常重要
给出前进一小步的解决方案，给领导，也给自己，一个小小的行动暗示
找到“核心关注点”
用数据和事实来作“论点”
给出一个小小的“行动点”
抓住重点，高效沟通，要记住三点
误区三：抓不住重点，给不出方案
向上沟通
在合作前，你要跟对方建立合约，明确合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人。建立合约时，要由双方负责人进行邮件确认，公开做出正式的承诺。
需要注意的是，在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得到公开确认。否则，这些问题如果不明不白的话，就会给后续工作带来极大的隐患。
为什么很多公司级的战略合作，都会举办一个签字仪式呢？其实，这就是因为承诺越公开，越正式，日后对双方的约束效力就越大。
第一步：建立君子协定
合作建立之后，需要建立常规的沟通机制来持续推动。比如，项目信息开放共享，每周在固定的时间开碰头会，双方相关人员交流工作进展及风险情况。更进一步的话，你还可以借助标准的任务管理和文档管理工具，对项目任务和文档做到统一的流程化管理，在过程中确保及时地跟进检查。
如果你发现了模糊地带的存在，要及时明确需要共同协作的内容是什么，该由哪个部门、哪个人负责，做到权责分明和分工合理，避免后期出现相互推诿、扯皮的情况。
第二步：建立机制
在找领导之前，建议你先自己摸清楚状况，尽快启动风险应对机制，确定问题处理方案，比如改变方案、调整时间、增加资源、减少范围等。
你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影响及调整方案。同时，你还要明确的是，今后要采取哪些预防措施，以避免问题的再次发生。
第三步：解决问题
约法三章，先说清楚
重新设定节奏之后，如果跨部门协调的问题明显变少，那么当前这个节奏就是更合适的
首先，要建立统一、清晰的节奏感
其次，想要打开边界，你还需要主动往前一步
如果更多是单方面依赖、单方面受益，且是一次性的合作，第一种方式会更加适合
如果是互相依赖，而且是长期合作的共生关系，那么就不能只考虑短期利益了
总结
打开边界，一起想办法
跨部门沟通
执行力、信息力、感知力、透明力、影响力和整合力
非职权领导力六力模型
主动担责
一个有始有终的闭环，意味着你要对自己的每一个行为负责，清楚地了解为什么做，目标是什么，做完之后效果是怎样的，还有什么问题，以后要做哪些改进；如果中途有变化，也要及时跟相关方明确说明调整或取消的原因是什么
有始有终
想要做一个“靠谱”的人：第一，跨出自己的边界，主动担责；第二，言必信，行必果，做事情有始有终
执行力
在大数据时代，谁掌握着数据和信息，谁就拥有更强大的力量和权力
要让流动的信息汇聚起来，可以通过信息互通机制和平台来做到这一点
周会、站会、周报、邮件列表、通讯群，甚至各类数据平台，都可以成为信息力的承载
让非正式信息自动流向你
信息力
感知力是对“冰山下”隐性信息的敏锐度
第一层：现象层；这一层观察的焦点，是在“冰山上”的行为
第二层：意图层；这一层观察的焦点，是在“冰山下”行为背后的真正意图；最简单的是，多问几个为什么
第三层：感受层；你要试着从这些现象和意图中，去感受每个人的状态和需要
要想培养感知力，就要在日常观察之中下功夫；从关注行为，到关注行为背后的意图，再到关注意图背后个体的核心感受和深层需要，最后着眼于团队中的气场和互动品质
感知力
向下沟通（上）
想要引发改变，不是仅凭一人之力就可以做得到的；要打破这个恶性循环，就一定得让大家真正地看见问题，并且从心底里达成共识
两个透明化呈现的方法：一个是“分析−思考−看见”，一个是“目睹−感受−看见“
想要改善什么，就把什么透明化；在走脑的同时又要走心，让团队的所有人都看见问题，调动起集体的关注力和改变的动力
透明力
影响力的真正秘诀却在于“听”，而不是“讲”
提的每一条建议都是建立在对他的理解之上的，所以才能被听进去
不听，是一切沟通问题的根源
自然的交流分享，反而更容易产生碰撞，引发共振
影响力
优秀的全局整合能力非常关键
一群优秀的人合在一起，也不一定能成为一个优秀的团队，不一定能真的做成一个业务
凡是能促进业务良性运作的，凡是能促进团队健康发展的，都是整合管理的范畴
整合力
实践中的“六力模型”
向下沟通（下）
让考级最大程度地帮助自己提升专业技能，才是最重要的
PMP 认证的普及为我们创造了项目管理专业的共同语境
PMP 的认证过程也是我们学习并掌握一门项目管理的国际标准语言的过程，就好比是学会了另一门英语
决定你是否被录取的，还是你的实战经验和实战水平；再进一步去看的话，还有建立在实战经验之上的、你对专业方法论的掌握和应用水平
学习中最怕的就是本末倒置
在具备一定的实战经验之后再去系统化地学习这门课程
为什么要考 PMP
确保至少完整地经历过两到三个项目周期
避开工作高峰期，选择自己相对空闲的季度
并不一定需要有明确的项目经理岗位，只要有相应的项目经验，并且达到足够的时长积累，就可以报名了
第一步：确定考试的目标时间
英文申请全年都可以提交，没有时间限制，但是有 5～7 天的审核时间，审核成功后，账户有一年的有效期
如果英文申请没有通过，是不能完成中文报名的
第二步：完成中英文报名
报名考生需要具备 PMI 授权的培训机构所颁发的 35PDU 培训证书
通读
要真正把培训老师当作你的资源，遇到问题多思考、抓住时机多提问，在弄懂方法原理的同时，更要去主动思考，你如何将这个学习引入自己的工作
精读
多总结学习和做题过程中遇到的问题，回顾书上的常见考点，反复加深理解
对于那些重点、难点，你要刻意去背诵下来
在考试之前，你要对熟练掌握各个知识点，并达到融会贯通的效果
从死记硬背到真正理解，需要时间和阅历
记忆
《PMBOK 指南》三步学习法
第三步：课程学习和备考
如何有效备考 PMP
一旦涉及到职业选择，最关键的一点就是，尽可能不要让自己被很多外在的因素所左右
留些空间给自己，先想好，如果没有 Leader 的影响和要求，自己的决定到底会是什么
变被动为主动，为自己的职业道路负起责任
性格内向或外向并不是影响转型的决定性因素
看这项工作是否能够激发你更大的热情
程序员研究的是“一堆代码在一起，如何运行会更好”，那么项目经理研究的就是“一群人在一起共同做一件事，如何运作会更好”
需要对人有敏感度，并且要发自内心地认为研究人比研究代码更加有趣
在拥有热情的前提下，经验背景的差异都是可以用时间弥补的
项目管理进阶之路
实战永远是我们不变的基调
进阶之路
软实力篇
自己对困难的定义，对问题的定义，对理想环境的定义……这些定义决定了你的体验，以及你下一步的行动
要想前进，你就必须先破除“魔”障；别让你的定义，限制了你的可能性
破除“魔”障
每次一小步
就是多看几遍，多听几遍，把那种事情已然成真的喜悦和满足感，刻录在心里
试着和自己的经验相关联，在大脑中想象自己已经做到这些的样子，越清晰越好
先找找“感觉”
通过行动，反复加深神经系统中的凹痕，直到新的行为，巩固成为新的模式
“足”量的刻意练习
大师创造的“四步学习法”
加餐 ：“学习”到“实战”的距离，到底有多远
别人给的内容再好，都不如你自己跑到丛林深处，靠自己的力量采来的一个野果香甜
你能在这条路上走多远，不取决于你的起点，也不取决于你当前所处的位置，而是取决于你是否对此有持续的热情和足够的专注，来支撑你真正地付诸行动
结束语
具备项目管理能力的程序员，拥有更多的竞争优势
项目管理是新一代“进化型”程序员的重要底层能力
为什么要学习项目管理
对“机”的把握是一种非常稀缺且不可替代的能力
如何有效地学习项目管理
在一个组织中，具备项目管理能力的人是越多越好
开篇词
想办法影响他人去把事情做好，要难得多
成功施加影响的三个层次，分别是让人知道要做（Awareness）、有动力做（Desire）和有能力做（Ability）
单方面的工作交待和告知，停留在浅层次的信息传达上，只是让人知道要做，但并不足以让人产生动力，去促成有效的行动
讲清楚为什么要做，为什么要现在做，获取理解及认同，激发团队的动力是项目经理成功授权工作的关键
从外部引入相应的人才，是最直接有效的方式。除此之外，你还可以去积极争取短期借调、内部转岗等。从长期来看，你还需要有意识地发现和投资那些团队中最有潜力的人，给他们安排相应的工作辅导，开展有针对性的培训等，帮助项目组成员发展相应能力，让事情真正落地。
项目成功关键路径上的核心能力缺失，是作为项目管理人员，要当作最高优先级的风险管理的事项
误区 1：凡事恨不得事必躬亲
项目经理要带大家一起开启动会，清晰愿景目标，定义阶段里程碑和完成标准，接着制定分段执行的计划，把事情的所有环节从头到尾捋顺了；项目经理要建立上下游协同的流程规则，明确各个角色在整个过程中的职责，获得大家的认同和共识：项目经理还要建立站会、周会等制度和模版，让进展和风险通过这些良好设计的信息渠道汇聚，借助规则和工具来达到监控的目的。
要明确目标，建立机制，并让这个机制运转起来，最终在项目组形成一种良性的秩序
当成熟的秩序在团队中形成之后，从日常琐事中解放出来的项目经理，就可以集中精力去做愿景驱动、激励团队等更高层面的工作，真正做到变“赶〞为"引。
项目管理并非要让你成为监工，要始终依靠流程和规则来约束大家的行为
误区 2：追在别人屁股后面做监工
在你的项目组中，时间、成本、质量、范围这几个因素，到底哪个更重要？哪些是允许有一定调整空间的？
各个角色目前的痛点在哪儿？哪些是最先需要解决的？这些问题背后潜在的原因是什么？
团队对于这个痛点的改进是否有真实需要？需求的迫切程度如何？
你的老板或项目发起人对于项目管理以及你本人的定位是怎样的？关于这些问题与可能的改进，你是否与其沟通过并达成了一致？
如果你打算引入新方法或工具，更适合用怎样的路径进行，是自上而下地全面推广，还是自下而上地一步步优化呢？最有可能从哪个问题切入？
从项目和团队当前的真实痛点出发，找到真正解决问题的方法和步骤
误区 3：拿着锤子，看哪里都是钉子
角色转换
1917 年，发明了著名的甘特图
1957 年，发明了关键路径法（CPM）
90 年代后，项目管理逐步标准化
项目管理的历史
项目管理就是变理想为现实，化抽象为具体的一门科学和艺术
项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内，完成项目的各项工作，对组织资源进行计划、引导和控制。
什么是项目管理
分析那些是活动组织者的干系人？
项目发起人对活动的预期效果是什么？
是否存在更多潜在的干系方，可以助力活动的成功？
如何更好地管理干系人的期望和影响？
活动过程中的各类决定，都需要谁来拍版？
干系人要以什么样的方式参与？
干系人管理：如何管理干系人
确保围绕着预期目标来设计相应的活动方案
范围管理的过程中主要是搞清楚到底要做到那些事情，达到各方的期望值
范围管理：做什么
要规划好阶段性步骤，同时明确每个里程碑的目标成果和时间安排
第一阶段，启动项目并确认概要方案设计
第二阶段，规划并落实人力和各项资源的投入
第三阶段，确定具体的活动流程和详细分工，完成活动前的各项准备工作
第四阶段，做好活动当天现场的统筹和运作
进度管理：花多少时间？
从全局视角去思考，如何更有效地管理项目的各项投入，以达到更加匹配目标的预期效果
成本管理：花多大代价？
以终为始，从结果出发，思考引入那些流程可以有效保证活动效果
质量管理：达到什么要求？
公司内有哪些核心资源是可以使用的？
资源管理：有多少资源？
哪些是需要外部采购？
有哪些工作需要外部人员支持？
如果经费受限，是否可以通过交换资源的方式，来获取更多的外部支持？
采购管理：有多少东西需要购买？
从这个角度出发，需要考虑的是，活动策划团队、执行团队分别通过什么方式来进行项目沟通？
与发起人和赞助方的沟通方式和频率是怎样的？
你如何保持团队内外项目信息的高效传递，使用什么方式来同步进展？
沟通管理：如何管理沟通？
需要提前做好系统性的风险识别，分等级制定应对策略
风险管理：如何应对风险？
整合管理是要告诉你，作为这个活动的大内总管，你该如何去统筹全局，整合并协调各个环节利益冲突和工作安排
在不断变化的情境下，根据活动的目标"裁剪”出合适的过程、方法和工具，进行有效管理，从而达到全局的最优效果
整合管理：如何实现整体最优
项目管理的十大知识领域
保目标，助决策，提效能，促协作
十大领域五大过程组（上）
意味着正式开始一个项目，或者是开始一个项目中的新阶段，包括识别干系人和制定项目章程两个子过程
正式宣告一个新项目或新阶段的开始，公开确认项目章程，包括明晰各方干系人的期望和诉求，设定愿景目标和重要里程碑，确定责任分工和沟通机制等
启动过程组是最容易被忽略的过程组之一，越是持有结果导向的人，就越容易马上直奔主题去做，根本不管什么项目章程
启动过程组
规划就是要把愿景目标转化为可落地的行动方案和工作路线
需要根据预期目标，明确项目范围，确定项目的里程碑阶段目标，为项目的执行做好各项准备
规划过程组
确保项目一直在正确的轨道上，确保各个环节按照规划进行，并且能够真正做到位
规划做好之后，就是考验执行力的时候了。这个阶段重在整合资源，推进项目落地，完成项目管理计划中确定的工作以实现项目目标
执行过程组
对项目的进展、范围、质量等进行跟踪和监控，识别目前的进度与计划之间的偏差，从而快速准确地采取办法进行纠正和调整
执行并不意味着在任何情况下都要一成不变。当外界环境或内部要求发生变化时，项目管理者也要审时度势，沉着应变，适时地调整各方，以更地实现目标
监控过程组
不管项目成功与否，“趁热”复盘都是极为重要的一步
复盘通常会带给我们很多有价值的信息和启示，比如哪些致命风险需要在一开始就被很好地管理和应对，再来一次的话，我们该怎么做
收尾过程组
项目管理的五大过程组
项目管理有着天然的无边界属性，这也就意味着，放眼全局你能看到的地方，你什么都得操心、什么活都得干。所以，要搞清楚这件事，其实是很难的。别的角色都有自己的输出、自己的作品和固定的职责，但是好的项目经理却是融于无形的，整体项目团队的产出就是项目经理的作品
业务最顶层的战略意图，需要一层层地进行拆解。首先，你要围绕组织绩效目标，定位出核心的3～5 件要事，即关键战役，再把关键战役进行规划分解，拆到可交付可验收的里程碑，最后落地到版本/迭代的工作安排中
你还要通过清晰而系统的反馈机制和平台，把执行中的进展状态、变更、风险等集中呈现，以帮助管理者更好地进行优化和调整。比如，结合产出进度来调整业务策略，通过里程碑状态信息来调整目标和规划的节奏，根据人力投入的分布，来优化整体的资源配置
提效能是要去关注和消灭团队中的低价值工作所引发的效能痛点
促协作则是着眼于使用各种项目管理方法和工具，让高价值工作者可以更好地合作
保目标、助决策是要打通从战略到执行的闭环，提效能、促协作则是打通上下游协同的闭环
互联网项目管理的职责定位
十大领域五大过程组（下）
常识篇
为了管理好之后的沟通，你还需要约定好你们之间的沟通频率和方式，以便在项目进行的过程中做好实时同步
项目发起人会定义组织对项目的需求，为项目提供资金支持，并进行人员配备。一般来说，项目发起人天然会成为你强有力的支持者，需要重点管理
了解发起人对项目的真正诉求，对项目的成功至关重要。有很多项目经理只知道保质保量地完成项目是最重要的，却从来没问过发起人，这个项目真正要的是什么。
询问项目发起人流程
“高利益 - 高权力”代表：项目发起人
职能经理是资源池的所有者，他们所管辖的团队通常覆盖多个项目或项目群，这也使得他们与单个项目的利益相关度通常比较低，介入程度往往也很有限。但是，因为他们对资源的把控力很强，如果管理不好这类干系人，你的项目资源就很容易受到影响。
强烈的态度背后，一定反映了干系人对现状的某种认知，这种认知未必是事实，但你一定不要急于反驳，而是不带评判地去了解他的内心想法，通过积极聆听去建立信任。只有真正地理解了对方的逻辑，才有可能进一步对其施加影响。
反对者是最难处理的一类，管理这类人的重点在于建立信任，化解敌意。如果你实在无法争取他们的支持，至少要让他们保持中立，以免对其他成员造成负面影响。
反对者
支持者是项目获得成功非常需要依赖的力量。管理这类人的重点是，首先你要明确地知道，他们各自对项目不同的期望和诉求，然后有意识地创造更多的空间和机会，让他们能够深度参与到这个项目的决策或创意环节。这样可以增强他们的主人翁意识，也会给整个项目组带来最大的收益。
支持者
对待这类人，总体原则就是，在条件合适时，进一步将其转化为支持力量。但如果你精力有限，可以先不管。
中立者
“低利益 - 高权力”代表：职能经理
管理这类干系人的核心，就是要做到项目事项的随时告知，及时通报项目的进展和困难
这些问题可以帮你了解项目的规划和实施过程，找出那些没有做到位的地方，弄清楚项目组成员当前最希望通过项目管理看到的变化。这些痛点和渴望，会成为你在团队中促发改变的有力抓手，帮助你找准突破点，集中发力。
“高利益 - 低权力”代表：项目组成员
每天或者每周进展汇报的格式和内容，确保他们的工作职责和任务明确，进展符合预期就可以了
“低利益 - 低权力”代表：外围支持人员
启动
计划是贯穿始终的重要课题，是各个角色协同工作的基准
程序员在做项目管理的时候，会有个特别明显的优势，就是对项目中涉及到的架构设计、技术难点等问题，有着非常深刻的理解，因此，你对技术类风险会有更高的把控力。
利用一切可以利用的资源、尽自己最大的努力达成项目目标，而计划是你可以借助的重要工具
从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程
为啥一定要做计划
好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦
WBS 工作分解（Work Breakdown Structure），这是我们做计划的第一个标准动作
WBS 是项目管理领域非常重要的方法。创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。
简单来说，在做计划的时候，我们要把项目，也就是我们要做的这件事情真正拆解开，明确要分成多少块工作内容，涉及哪些角色和哪些环节的工作项，你需要将工作项拆解到 3 个工作日以内，每项任务都对应到个人。
做计划的方式的转变，背后其实是思维方式的根本转变
雷区 1：不够具体
只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。这样的计划，无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标以及如何完成
关键路径是决定项目工期的进度活动序列。它是项目中最长的路径，关键路径的工期决定了整个项目的工期。所以，任何关键路径上的延迟都将直接影响项目的预期完成时间。
识别依赖并画出关键路径，这一步意味着我们开始从目标的角度对资源进行统筹思考
雷区 2：不够全面
做计划的第三个标准动作就是定义完成标准
完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标（特定水平的 Bug 数量/ 性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。越早定义完成标准，计划按照期望完成的概率就越大。
执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
需求 / 设计确认
所有定义的功能都己经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把 CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
功能完成 / 提测
质量已经达到适当水平（如不存在PO 及P1 优先级的 Bug)，可以上线发布，或者可以开始下一个里程碑。
里程碑完成
越早定义完成标准，计划按照期望完成的概率就越大
雷区 3：不够准确
没有达成共识的计划，是不具备任何效力的
达成共识并公开透明，就是做计划的第四个标准动作
雷区 4：没有共识
每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策
及时调整变更，就是做计划的第五个标准动作
雷区 5：不够即时
扫雷游戏
WBS 工作分解，识别依赖及各环节关键路径，定义完成标准，达成共识并公开透明，即时调整变更
做计划的 5 个标准动作
规划
很多时候，我们确实没有办法一步到位，但合理试错，减少不必要的浪费，仍然是可以做到的。在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。
开环与闭环之间的关键差异，在于有没有反馈环节，以及系统是否会根据反馈自动调节
闭环
要想执行中不走样，就必须把方案评审做到位
评审的精髓不在会，而在于背后的决策机制
负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；
批准者 (Approver)：最终批准者；
申核者(Reviewer)：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；
参与者 (Participant)：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。
OARP 是 Owner、Approver、Reviewer、Participant 的缩写
方案评审（OARP 决策机制）
1. 时间：测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间段开展；需求设计类的 Bug Bash，一般会放在需求稿或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰；
2. 地点：你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围；
3. 参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角；
4. 现场安排：你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一个地点进行，你至少也要在通信群中实时更新排名情况的变化。
5.活动结束：在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。最后，在对 Bug 进行去重后，还要分类定级，确定哪些 Bug 是必须修的，哪些Bug 是改了会更好的。另外，千万不要忘记公示结果，明确修复计划。
Bug Bash（Bug 大扫除）
先从测试人员记录冒烟测试通过率开始
冒烟用例评审
执行
事件描述
影响后果
跟进分析
响应措施
所需支持
紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告
总之，执行过程中突发的紧急情况，非常考验项目经理的专业素养。首先，你必须要直面问题，在紧急时刻勇于站出来承担责任，不仅不会让老板对你的印象减分，还能让决策者在第一时间选择更好的应对方式。另外，你要尽可能简洁地描述清楚可能的影响和后果，目前的建议方案和所需支持，最大程度地争取各个相关环节的协同配合，共同应对问题。
紧急汇报：直面问题有章法
最必不可少的就是整体项目状态评估、风险列表、项目概况及计划变更情况
实际上，项目周报是向项目团队和干系人沟通项目状态的常用手段，你需要用简要的方式呈现项目全貌，客观地展示项目问题，推进问题解决。我给你分享一份周报模板，你可以根据自己项目组的需要，选择合适的内容模块。
在这份项目周报模版中，最必不可少的就是整体项目状态评估、风险列表、项目概况及计划变更情况。好的周报，应该让大家对项目现状的三个问题形成统一、清晰的整体认知。这份整体认知，可以让平时扎在细节工作中的人，从全局视角来了解和看待整体，从而更好地完成自己的工作。
切忌事无巨细，只写要点就够了
常规汇报：项目周报回答的三个问题
燃尽图（Burn Down Chart）可以直观地进行过程预测和风险预警
我给你介绍几种常见的项目仪表盘，这些图表，你都可以快速地在 JIRA 中绘制出来。其中，倒计时图是个非常醒目的标志，可以帮助大家建立清晰的时间意识，而工作任务的状态分布和剩余工作量分布，可以清晰地展现出每位成员的工作排布情况，帮你快速发现和定位执行过程人员工作量的瓶颈。
JIRA 上有丰富的插件去获取各类图表和数据
数据汇报：善用“透明”的力量
监控
复盘是对思维的训练
项目复盘会是项目团队有意识地向过去的行为经验学习的过程
通过复盘，当类似的局面再次出现在你面前的时候，你就能够快速地预测接下来的动态和走向，并且更好地应对。而项目复盘会，可以说是项目团队有意识地向过去的行为经验学习的过程。在项目或里程碑完结之后，项目经理会组织召集项目成员，一起回顾一下，在项目的整个历程中，团队做对了哪些事，做错了哪些事，再来一次，如何做得更好，借此把项目行进过程中产生的集体智慧沉淀下来。
复盘
在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要
首先，我们自己要先进入反思区
奠定基调：复盘不是来挑问题的，而是为了找到问题的根源并改进的
如何设定开放的基调
复盘会的基调设定
包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等
梳理整个版本的历程
复盘会的基调设定，以及会前的准备工作，在开会之前，就很大程度地决定了复盘会的效果
复盘会的会前准备
现场回顾总结项目 / 里程碑的整体概况
与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点
在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论
对大家总结出的好和不好的点，进行集体投票
由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案
流程
无法促发行动的复盘，说得再好都是空谈
改进措施一定要落地，重点行动不要太多，一个就够了
复盘的次数也不要太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的
复盘会的简易流程
想要让团队进入自发改进的正向循环，你需要更好地激发团队的主人翁意识，让团队成为复盘的主角，而不是你
最重要的是，你不仅要关注事，还要关注人
越是困难时期，越是塑造团队能力的大好机会
越是困难时期，越是塑造团队能力的大好机会。在团队遇到重大困难时，你也可以及时组织一场复盘会，深度关注和调整个人的状态。我就曾经试过让每个人画出自己进入这个项目组以后的状态变化曲线，跟大家分享自己的“高光时刻〞和“至暗时刻〞。在业务低落期，这样的复盘会会成为一个重要的转折点，让团队的力量得到深度聚合。
打造团队持续改进能力
决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节
认真地做好一次复盘，每次复盘后聚焦一个改进点
聚焦点别太多，一个就够了
收尾
要想改变现状，首先就是找到合适的时机，树立对变更的最小共识
需求变更是有代价的
我们追求的是达成项目目标，而不是零变更
1. 所有需求及所有变更必须建单，无单需求开发有权不接；2. 需求变更必须经过变更委员会评估成本，变更成本较大的，要提交项目经理更新时间计划，并告知全员；3. 对于确认通过的变更，产品人员要发送邮件，让全项目组人员都知道。
首先，就是把关需求的质量，避免需求问题流到下游。Bug Bash， 就是一个好方法，建议你在一些大版本的需求设计稿完成时，发动团队的力量去做一轮全面的需求检查，让各个角色早期深度地参与到项目中，这对防治需求变更非常有效。
锦囊 1：达成最小共识，变更是有代价的
从变更的源头开始治理，从源头开始公开透明，一次把事情最对，实际上是最有效率的方式
这个项目中每条业务线都有自己的策划，如果采用传统方式，这些需求各自成稿，再加上不同业务线的策划之间、策划和设计之间、设计和开发之间的沟通成本，不知道什么时候才能真正确认，也不知道会埋下多少变更的\"坑〞。
锦囊 2：源头治理，一次把事情做对
不要直接顶回去，要去剖析、把握和满足老板或客户的真正诉求
在常规团队之外，组建了一个老板需求响应小分队，由团队轮流值班，协同提高响应速度，让老板可以试得快，试得爽
对于那些我们并不太认同的老板需求，就快速尝试，先小范围灰度发布，再用对比数据说话
锦囊 3：快试错，不可抗力巧应对
需求变更
项目风险是一种不确定的事件或条件，一且发生，就会对至少一个项目目标造成影响，比如范围、进度、成本、质量等，项目风险也可能对组织或组织的目标造成影响，比如财务、声誉等。
风险识别的主体，应该包含项目中的团队成员在内的各方干系人，而不只是项目经理。组织中的每个层级，都必须有意识地积极识别，并有效管理风险。系统化的风险识别，是一个反复进行的过程，应该从构思阶段开始，贯穿项目规划和执行的始终。
识别风险过程的主要输出，就是初始的风险登记册，包括已识别的风险清单，以及潜在应对措施清单。对于已识别的每个风险，都要评估其概率和影响，并进行优先排序
系统化风险识别
没有人反馈风险，不代表没有风险
需要的是一颗真诚交流的心，去关注项目中的每个角色、每个成员的需求，理解他们的困难，愿意为他们提供发展的机会，帮助他们去获得更大的成功
先去观察一下，在吃饭的时候，你的团队分成了哪些群体
你识别出的风险越多，项目的风险就越低
冰山下的风险
对于发生概率很高的严重风险，一定要提前准备风险应对方案和危机应急预案。一旦风险和危机来临，应急预案就可以有效地降低风险的损失和危机带来的灾难。
在项目排期时，你要确保有相应的故障演练计划，并且做好充分的准备。也许有些风险预案永远也用不上，但是这并不是说它们是多余的。在风险降临的危机关头，它们的价值就会凸显出来。
在项目执行期间，已识别的风险会不断地变化，新的风险也会产生。你需要在每周的项目状态同步会议上，对风险进行再评估，并通过周期性的风险审查，来识别新的风险。
风险应对措施
事后不如事中控制，事中不如事前控制
对这个版本研发过程的综合评分（包括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面），这反映了过程满意度；
对这个版本功能设计的满意度，即产品认可度。
关于执行中的风险，群众永远是最有发言权的。如果这个系统是健康的，一定是可以自行去呈现和反馈风险的。而建立系统性保障机制的关键就在于，你要致力于持续改善人与人之间的互动品质，提升项目团队的健康度。
经常做匿名问卷收集或访谈，定期做一场坦诚布公的复盘会，都是系统性保健的好方法
做调查问卷，是项目经理了解团队的重要方式之一
你要坚持在多个版本中反复使用，积累数据。这样一来，你就可以通过各个版本的数据变化，看到团队状态的起伏和健康度的走势。当团队对产品的发展方向产生疑虑或不认可，抑或是对过程中的管理方式或协作状态不满的时候，你要允许团队各抒己见，充分沟通表达。事先预防永远胜过事后纠正，如果你有意识地在团队中构建这样的常规反馈渠道，系统性风险提示和保健的作用就会逐渐发挥出来。
治未病，建立系统性保健机制
项目经理不是只要管理好常规执行风险就可以了，真正会导致项目失败的致命风险，往往在项目一开始就埋下了。比如，公司高层对于项目的态度和预期、项目目标与组织战略目标的一致性、项目所依赖的重要资源方的合作关系、竞争对手及行业市场状况的变化、政策变化、监管风险等。
第 1 步：挖掘出这些致命风险，把它们变为可见的、可谈的
第 2 步：正视风险，不存侥幸心理
第 3 步：在项目的核心团队中，周期性地梳理和同步风险状态
积极管理致命风险
加速构建核心能力，不断拓宽“护城河”，才是最根本的应对之道
树立正确的风险观
风险是一种不确定的事件或条件，用辩证的眼光看，风险的另外一面就是“机〞。互联网领域的产品创新，大多是一场跳进未知的冒险，这给传统的风险观带来了极大的冲击。在项目管理的过程中，步步为营的风险管理之外，积极把握不确定性带来的机会，提升系统的反脆弱能力，达到最优的效果，是项目经理需要持续修炼的功课。
风险管理
质量成本分为两类：一类是事前防止失败的一致性成本；一类是事后处理失败的非一致性成本，包括内部 Bug 引发的返工成本，以及外部 Bug 导致的用户侧成本
事后检查处理的代价其实是最高的
预防高于检查，预防错误的成本通常比在检查中发现并纠正错误的成本低得多
一次性把事情做对的成本是最低的。而一次性把事情做对就意味着，我们要有意识地提升预防类工作的占比，从根本上降低内部 Bug 率和外部 Bug 率。在这个质量改进的过程中，程序员是绝对的关键力量，而非测试人员。
概述
规划质量，是识别项目及产品的质量要求和标准，并确定用哪些保障方法、改进措施来达到这些标准的过程
项目经理的视角始终聚焦在项目的整体目标上。在项目经理看来，质量作为目标的一部分，达到要求是最重要的，不需要追求质量的无止境提升。因为，质量终究也是有代价的，是否够用则取决于项目目标和要求。
在业务生命周期的不同阶段，质量标准应该是动态变化的
只能结合具体项目和具体阶段的质量诉求，对质量的标准进行合理定义
质量规划，明确标准
质量分析，是指识别项目运行期间，整体质量上遇到的问题和制约因素，分析根本原因，并制定相应的预防措施和解决方案。
新功能适当放慢：在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占比与优先级。当时我们定义的是不超过 70%，在一定时期内，核心功能不再做大的变动
回顾总结：将线上 Bug 分析作为周会的一项固定内容，集体讨论出整体层面上的改进措饰并立即实施到位
查漏补缺：对已有的测试用例进行全面梳理，与相关的开发、测试、运维一起集体review，花大力气补充测试代码（增加异常、并发、稳定性测试等）。考虑到这是一项长期工作，要确保将其分解到各个迭代中，分批实施。
走到前面：紧密跟进社区 Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对措施，主动引入必要的补丁。
以终为始：新功能需求确定后，测试用例同步设计并进行 review，然后开放冒烟测试标准，让开发人员在明确”什么是完成”的前提下，进行开发。
改进措施
1. 每月坚持开线上 Bug 分析会。你可以召集产品、研发、测试，一起对过去一个月的线上问题，进行深入的根因分析，制定策略并推进落实。
2. 持续进行内部 Bug 分类。从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效。
3. 建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势，对齐干行代码 Bug 率、Bug数/需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性的原因分析。
质量分析方法
质量分析，追根溯源
，质量控制及卡点行为，是要结合项目的质量要求和团队的质量成熟度，一层一层地加强质量把关和收口。即便是在同个项目的不同应用中，也会因为线上要求的不同，而对质量卡点有不同的侧重。通过质量卡点的在线工具化，才能做到真正有效的质量保障。比如，某些团队在特定阶段，会按照静态代码扫描问题的级别来分级计算缺陷值，提交测试申请时，如果系统检测到缺陷值有升高，就不能够成功提交。
质量控制，层层卡点
质量管理
“断舍离”，只开最有必要的会，会而有议，议而有决，决而有行
会议不在多，而在于精，每个会议都要真正开出效果来
要有意识地选择，最适合项目现阶段状况的会议
项目中的重要会议
启动会的目的是清晰目标，明确授权
分三步走，分别是 why、what 和 how
那个项目的启动会，可以邀请到大老板亲自上阵跟大家讲述项目背景。他从公司战略赛道的选择性聚焦，讲到自己对这个事业的追求，话语中所传达出的重视、关注和热爱，是让这个 why 真正打动人的核心要素。
why，只有充分理解了项目背景、目的和意义，才能更好地唤起团队的参与热情
what，描绘蓝图，设定清晰的愿景，包括项目的三年目标、五年规划，越清晰越好，为的是让团队看到未来的样子
对于一些新组建的团队来说，也可以加入一些破冰的环节，让大家打破边界，尽快建立新的协作模式。你还可以留一些时间给重要的角色代表发言，大家的热情相互感染，会让士气空前高涨。这时，启动会的效果就达成了。
how，明确团队之间的责任分工以及合作公约
只有在新项目或新阶段准备启动，涉及到方向、目标、人员、职责的调整的时候，才需要开启动会来进行公开的澄清和授权
启动会
开好站会的关键，是要还政于民；站会满足的是团队的自组织需要，而不是 leader 的监控需求
作为项目管理人员，你要引导团队不断建立和完善自己的规则，并在运行顺畅之后，把站会还给大家，让大家自己决定站会要怎么开。
真正自我管理的站会，除了团队成员自己决定站会时间之外，连主持人都是成员轮流来当的
举“红牌〞：表示叫停谈话，避免过度的讨论和无结果的时间浪费，提高站会效率；
举“黄牌〞：表示打断讨论，进行提问，向发言者了解协同及依赖的信息；
举\"绿牌〞：这是一个 token 牌，代表每个人的发言权。每次只有1 个人发言，按顺序来，将此牌归还给主持人表示同步完毕。
这样简单的游戏规则，既可以帮助主持人有效地把握节奏，同时还把会议控制的权力和责任交给了与会的每一个人，任何人都可以对过度的讨论随时喊停，从而让站会在“有用”的同时又能保持\"高效〞。
“三张牌”式站会法
每日站会
项目周会的目的，是解决整体计划层面、跨团队协同配合的问题，包括产品、运营、市场、研发等环节。由于项目周会是面向各个角色负责人，甚至面向全员的全局性会议，所以，工目周会就天然地成为了一个最能直接把控整体脉搏的地方。
根据项目组每个时期的整体阶段性重点，来设置相应的环节，让大家清晰地感受到项目组明确的导向，也就是什么是当前最重要的
项目周会
不要盯着会议的数量，而是要追求会议的品质
每个会议都有特定的主题和目的，并有明确的参会人员范围，这个就叫会议的边界
会议当场只说重要问题、风险及需要支持的地方
确保会议当场严格围绕主题开展，对偏离主题的讨论，及时叫停
项目经理要做好两个确保
相关问题的主要决策人，对这个问题有责任的相关人员、负责执行决议的人员是必须参与的
明确会议边界
建立会议规则
会后所有跟进事项，直接进任务系统，确保跟进到底
做好会后跟进
保障会议品质的关键
坚持只开最有必要的会，开真正高效且产生决议的会
高效会议
首先是“天时”，也就是合适的时机
问题并不等同于时机，只有把问题和痛点关联起来，才能形成一个好的时机
之所以不能产生改进动力，只能说明，你还没有抓准痛点
判断是否是痛点的标志，就是看这个问题，如果不解决，对方是否会很苦恼、很痛苦
访谈法，也就是直接问
去观察那些花他时间和精力最多、他反复强调却又没很好解决的问题，那些才是他真正的痛点
观察法
在变革的早期，最重要的就是寻找到早期支持者；围绕着你想要引入的变化，击中几个重要干系人的痛点之后，这个时机就到了
同理心和倾听
要想促发别人的行动，你必须换位思考，去体会和抓住他的痛点
结合每个项目团队的现状，做好本地化的场景适配
创造一个最小阻力的落地方法，先快速地跑起来，让团队感受到变化带来的闭环成效
引入变化的第二点“地利”，也就是说，你要学会因地制宜
多聆听彼此，充分理解，找到共同的出发点
在沟通时，要因人而异，针对不同的人，采用不同的策略
引入变化的第三个关键点了，也就是“人和”
先判断立场；立场，是指人们在认识和处理问题时所站的位置；立场不同，看问题的视角就不同
把变化涉及到的干系人，按照角色和层级做个初始划分，思考下不同区域的人，会怎么看待这个变化带给他的影响
找出更多的积极因素
在大范围公布并引入变化之前，与关键角色进行一对一的沟通，是更稳妥的做法
如何选用合适的沟通策略
在引入变化的过程中，面向全员的正式公开沟通，一般会放在最后
首先，你要选择合适的时机，然后，找到因地制宜的解决方案，最后因人而异，采用不同的策略进行有效沟通
之所以要引入变化，不是因为你觉得这个方法好，解决了你的问题，而是要看团队需要的是什么，干系人的痛点是什么
能够站在对方的角度设身处地地思考问题
故事案例：新手上路，如何引入变化
最初引入敏捷，原因很简单，就是想要发布周期更短
1. 人：拆分成小规模（5~7人）、跨职能的小团队；2. 事：拆分成一系列小而具体的交付物，按优先级排序，增量交付；3. 时间：拆分成固定大小的短迭代（1～4 周），在每个迭代结束后，对可工作的产出进行演示。
为什么引入敏捷
提早集成与测试。这让问题得以及时暴露，带来了更快的反馈及应对；
及时规避风险。意外仍然会有，但大多数情况下，我们可以在 Sprint 内部消化掉，避免更大的影响；
快速响应变化。在 Sprint 1 演示会后，我们收到了新客户提的紧急需求，立即做了相应的调整。如果按照之前的模式，这个时候，可能很多事情我们都只做了一半，想调头没那么容易。短周期让我们可以灵活调整方向，每个 Sprint 都是潜在可交付的产品。
痛点一：发布时间不可控（快速的增量交付）
每个人都等着上一环节的人把东西弄好送到自己面前来，才能开始工作。这些空耗的时间，并不能给产品带来直接的价值。
宁愿选择等待
在传统的项目管理中，项目经理的很大一部分工作就是要厘清各方责任，界定权利与义务，疏通对抗情绪，并解决随之而来的突发问题。但在敏捷的情境中，更加快速的交付压力，使得这种等待和界限变得越来越不可接受，我们不得不改变思路。
角色间泾渭分明
敏捷的打法，就好比是打橄榄球，所有队员都时刻关注着场上的比分
开发做完了工作以后，如果发现测试进度被卡，就会跟着一起着急，一起想办法解决问题，因为这影响到了整体的进度。
开发和测试把位置搬到了一起，并且设定了共同的 Sprint 目标和完成标准
在敏捷团队中，开发干得热火朝天的时候，测试也没闲着，测试代码与开发代码几乎是同时在写的。往往代码刚”出炉” 就测上了，而且只有在测试结束并确认没有 Bug 的时候，开发的工作才算结束。
从“你完成 - 我开始”，到我们一起完成
只有协作，才能达成目标
痛点二：摆脱“接力综合征”（从对抗走向协作）
1. 产品负责人向团队和用户代表，面对面地讲解收集来的各方需求，最终明确需求的优先级及验证条件，也就是说，在迭代结束的 Demo 演示会上，我们要给用户呈现什么。2. 团队估算。我们采用敏捷估算扑克的形式，由团队成员共同给出估算结果，最后综合得出这个迭代要交付哪些内容.
团队估算的过程，其实是个双向互动的环节，可以帮助团队和产品负责人共同加深对条目的理解。同时，产品负责人也会根据大家的反馈，及时修改条目，完善条目。
个体与交互 > 过程与工具
在计划会上，团队会直面一线用户，需求可以得到面对面的交流和澄清。另外，团队估算其实也是一个团队共同探索需求的过程。因为只有到真正考虑要花多少成本去做的时候，才会有各种各样的问题暴露出来。这个方法对于在早期进一步挖掘需求细节，特别有帮助。
需求探索更深入
每一个故事都会由全员出牌，各方从自己的角度出发想问题，可以互相补充。
估算结果更加全面、细致
我们团队的这一系列敏捷尝试，始终都是围绕着项目中切实的痛点展开的。从最开始缩短发布周期、经常交付可工作的软件，到应对“接力综合征〞，提升团队的整体目标感和协作效率，再到探索更加有效的需求理解及团队估算方式，在增进团队交流的同时，又保障了需求质量。
找到了更优的整体解决方案
三方面的好处
团队的这一系列敏捷尝试，始终都是围绕着项目中切实的痛点展开的
痛点三：需求理解不一致 （面对面澄清及估算）
更低的延误率
阶段性可见的产出
更快的反馈、适应与调整
提升客户体验
团队自主运行，管理更轻松
变“赶”为”引，为共同目标奋斗
提升管理者体验
更高的生产力
更强的责任感、主人翁意识
提升团队体验
敏捷实践的应用带来的好处
三项最重要的敏捷精神，那就是：快速可靠交付，用户价值驱动，持续自发改进
故事案例：小步快跑，小而美的敏捷
Step 1：选择并创建甘特图
Step 2：按照 WBS 工作分解，增 / 删任务
Step 3：拆解子任务（升 / 降级）
Step 4：配置任务属性（如资源名称、持续时间等）
Step 5：设置任务依赖关系
Visio：WBS 及甘特图
Step 1：选择并创建日程表
Step 2：选择日程表形状，绘制时间线
Step 3：设定里程碑时间
Step 4：设定时间间隔
Step 5：增加今日标记
Visio：里程碑规划
任务管理平台
为每个阶段设置清晰的完成标准
Tower：在线多人协同
研发的流程和标准管理是所有团队都会碰到的痛点，团队越大，越是如此
在流程中设置质量卡点
网易 Overmind：在流程中设置质量卡点
一页纸看到项目全局，更好地进行整合管理，轻松搞定各种干系人汇报
清晰明了地体现了项目管理的五个核心要素（目标、任务、负责人、时间线及成本）
12 个步骤：确定项目名称及目标、明确责任人、绘制项目矩阵、划分子目标、拆解主要任务、关联任务与子目标、设置目标日期、完成任务排期、分配任务到个人、设置定性任务、成本预算与监控、概述与风险预测
把最有用、最有价值的东西，用最快捷、最简单的方式呈现出来，这就是透明
一页纸项目管理：全局视图及干系人汇报
工具方法串讲
硬技能篇
项目管理实战20讲
0 条评论
回复 删除
下一页
