项目管理实战20讲
雷蓓蓓
网易杭研项目管理部总监，《网易一千零一夜》核心作者
立即订阅
3862 人已学习
课程目录
已更新 21 讲 / 共 20 讲
0/2登录后，你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 为什么说项目管理是每个人的底层能力？
免费
常识篇 (3讲)
01 | 角色转换：程序员做项目管理的三大误区
02 | 十大领域五大过程组（上）：程序员必须要了解的项目管理常识
03 | 十大领域五大过程组（下）：程序员必须要了解的项目管理常识
硬技能篇 (12讲)
04 | 启动：识别项目中的四类干系人
05 | 规划：排除计划中的“延期地雷”
06 | 执行：打造品质，要从头开始“闭环”
07 | 监控：进展“巧”汇报，学会用数据说话
08 | 收尾：项目复盘，小团队也要持续改进
09 | 需求变更：化解程序员的“头号噩梦”
10 | 风险管理：如何系统化应对风险？
11 | 质量管理：一次把事情做对！
12 | 高效会议：项目中要开好哪些会？
13 | 故事案例（上）：新手上路，如何引入变化？
14 | 故事案例（下）：小步快跑，小而美的敏捷
15 | 工具方法串讲：手把手教你高效管理
免费
软实力篇 (4讲)
16 | 向上沟通：你必须要注意的三个误区
17 | 跨部门沟通：怎么让不归你管的人积极配合你？
18 | 向下沟通（上）：无权无势，他们不听你的怎么办？
19 | 向下沟通（下）：无权无势，他们不听你的怎么办？
特别放送 (1讲)
特别加餐 ：“学习”到“实战”的距离，到底有多远？
项目管理实战20讲
登录|注册
06 | 执行：打造品质，要从头开始“闭环”
雷蓓蓓 2019-11-09
你好，我是雷蓓蓓。今天我要跟你分享的主题是：打造品质，要从头开始“闭环”。
不知道你是否经历过这样的场景：你的团队历经一个多月没日没夜的奋斗，终于在圣诞节采购季来临前，完成了“黑五购物节”活动的所有功能，全部测试完毕，马上就要上线了。结果，产品负责人试用之后，皱着眉头说：“这……不是我想要的！” 你说，还有比这更悲惨的吗？
实际上，这种现象并不少见，有些产品经理还美其名曰“允许试错”。可是，最后做完了才发现不是自己想要的，早干吗去了呢？！
之所以会出现这种情况，有很多潜在的原因。比如，在互联网环境下，要弄清楚开发什么产品，准确把握并实现用户需求，对产品人员的要求其实非常高。对于互联网产品而言，从最初的一个想法，到确定规模化的增长模式，通常要经历很多轮的螺旋式迭代，不断调整。
除了这个原因之外，更为常见的情况是，需求和设计根本没有经过严格的把关，就匆忙投入开发；同时，在传统的研发中间过程中，很难看到串连起来的功能效果，产品经理必须等到快上线了，才能看到和真实体验到可完整运行的产品。但是这个时候，再想大幅度修改产品，代价已经非常高了。
很多时候，我们确实没有办法一步到位，但合理试错，减少不必要的浪费，仍然是可以做到的。在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《项目管理实战20讲》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(23)
有心猴最坑的就是工期倒推,产品的东西你可以评审,评审不合格就改,可是占用的都是开发的时间,最终结果是产品文档改的合格了,工期到了,是开发没有完成.作者回复: 谢谢你的留言，这个问题很典型，我在09中有专门讲解我们的做法，希望给你些参考。
2019-11-11 3 11- maks我作为一个程序员，有一次接到需求之后。
按照流程需求分析，然后编写需求实施方案经邮件通知。
结果在开发完成，技术测试后。到业务测试环节，业务人员却说：“这不是我要的效果” 。
最可笑的是我们在核对需求都时候，却发现我从项目经理那拿到的是一个旧版本的需求书。
然后当我发现所谓的新版需求书根本连需求都没描述清楚，是几个系统的需求混合在一起（如果一开始是这一版我绝不会接受）。
连夜赶工按照当前需求所述考虑已开发的特性和系统可行性得出的实施方案（现在想来，我应该先让业务核实我的实施方案，不然又做无用功）。
实现之后立刻让业务人员核查一点一点确认，最后终于按时上线。
（现在回想我应该在事前在仔细沟通，至少一个电话确认，而非两份文档石沉大海，了无音讯）作者回复: 反向验证，从我做起，嗯！
2019-11-09 3 
看山灬1 产品说：这个功能很简单，就和xxx一样。（简单你来写啊）
2 上面这还不是最恶心的，最恶心是是你问他xxx的逻辑是什么的时候，他只能大体说出来，细节都不知道，细节得自己看代码。（你连细节都不知道，怎么说和xxx一样，谁给你的勇气）
3 产品说：这个是业务提的，拉个群你问问，技术的东西我不懂。（如果我没记错，产品是根据业务需求进行抽象延伸实现产品化的过程，难道你这个产品是看了《人人都是产品经理》就来了？再说了，我只想听到清晰的表达，不需要你懂技术）
4 业务说：这属于技术问题，我不懂。（1+1=2我觉得不属于技术范围，属于义务教育或者脑科医生的范围。）
5 业务说：怎么又出问题了，还会不会有问题？（会，肯定会，原来75个bug，修复完这个应该会变成90个bug）
6 业务在验收上线之后说：我还以为是xxx呢，变成xxx需要多久？（我手里还有你的验收单呢，刚验收完就不认账啦）
5 产品和业务一起说：因为时间很紧，咱们倒排期，大家有什么困难都提一下，保证项目顺利上线。（没别的困难，就是时间太紧，要不您老再多给点时间）
6 产品和业务一起说：你们（指开发）说我们该干什么，我们看你们这么累，想帮你们，但又不知道怎么帮，技术的东西我们也不懂。（少挖坑，谢谢）
9 开发说：差不多写完了（差不多是多少，85%还是99%？最后的1%不会卡住吧）
10 开发说：写完了，提测吧，出了问题我再改。（你也太不负责了吧，还会出问题叫写完了？）
11 欢迎补充。。。作者回复: 段子会火
2019-11-16 2
enjoylearning我们的设计稿都是产品一个人敲定，设计人员直接受产品经理管理。现在开需求会甚至都没有原型只有需求描述就开搞了，而且口头禅是 这个需求很简单，研发叫苦不迭作者回复: 你这种情况我也遇到过！可以看下第9讲，需求变更应对，我会详细展开，关键在于产生共识。
2019-11-09 2
未未的未来坑很多，例如按照研发流程经过了立项评审，包括对需求和设计可行性的评审，领导也有参与，最后项目上线，没有达到客户预期。并不反对流程，但是在执行流程的过程中有些流于形式了，并未引起所有人员的重视，感觉公司有要求，就走走过场。
最后，除了问题，都得挨批，研发还得返工，这中间的帐就是没算没明白，总认为流程耽误时间，回头一看，欠的帐总是要还的，只是时间未到而已。2019-11-09 2
杨家二少爷期待蓓蓓姐做一场直播作者回复: 蓓蓓姐正在超级马力通宵备课状态……
现在，做好课程是第一位。直播会有的，让子弹飞一会～2019-11-09 2
Ios王子最后说的冒烟测试没看明白是什么作者回复: 一般是指针对最基本的功能或最主要的业务流程进行的测试，用作提测验收条件。
2019-11-20 1
海罗沃德在敏捷開發團隊如何落實這些閉環？每個sprint時間都很短，沒有多餘時間進行這樣的閉環測試作者回复: 拆分成小迭代之后，你可能未必在每个迭代都这么做一遍，根据整体的里程碑规划，可以在封版测试的时候，设置相应的环节来做闭环测试
2019-11-11 1
qpm假设对方都清楚地沟通是团队协作的一个大问题，给各个岗位设定一定的反馈机制非常重要。我们这里测试负责给研发开发反馈，在策划方面却缺少了，导致阅读文档理解成本很高，经常遇到“一句话需求”。现在也是让我觉得头疼，引进流程，改变是一件不容易的事。作者回复: 想要在团队中引入变化，你可以看下第13篇，新手上路，如何引入变化，有详细拆解的步骤。
2019-12-02
发条方案评审是目前团队会做的，但是基本流于形式，根本的问题是不少人在策划阶段根本不会用心去看产品的策划案，许多关键问题被漏掉了；bug bash也许是个好的激励机制，但是目前团队感觉推不起来呀~~感觉需要项目管理人员去推。作者回复: 觉得这方法好，如何引入变化到团队，这也是一门学问。实际上，你并不需要有非常大影响力，或是专职项目经理才能去做这件事。
不管是引入bugbash，还是复盘会，其实都一样，我在第13讲中会具体讲怎么做。2019-11-20
Jxin来自产品的“很简单，和xxx老逻辑一样”。类比本身是好事。但当你的项目，又老又烂，而开发又嫩又懒时，这就是个噩梦。老项目功能可读性低，又不存在什么灵活扩展的空间。所以老逻辑想要兼容新的业务元往往需要投入高成本的阅读理解和适当的代码重构。而年轻的程序员由于缺少一定的业务背景和经验，阅读理解容易产生偏差，重构手法也不娴熟，还懒得一一验证当前功能所有case的准确性。于是往往就容易导致兼容出bug的现象，结果不仅新的业务元无法使用，老的业务还受到破坏，很可能最终就是这个迭代延期（并没有很好管理代码版本，迭代里多个需求的代码提交都是耦合的，没有提交的原子性，导致如果临近发版出问题，迭代里的需求难以再拆分，只能整个延期）。作者回复: 你这句话很典型的，又老又烂vs又嫩又懒，真是滋生技术债的天然土壤。
2019-11-12
马拉马拉整个方案评审有必要从头到尾跟着吗 现在手里项目多了 方案评审很多参加不了 导致很多方案只知道结果 不知道内容 做出来才发现有问题 这个怎么平衡作者回复: 不知道你在这个评审中的角色是什么，OARP重要的为不同的方案明晰角色和责任，如果你是reviewer，就必须提供意见，不能全程参与的话，也要相应指定好替代者
2019-11-11
xavier一句话概括就是设法降低沟通成本，消除信息不对称。2019-11-11
支离书为啥我感觉这节说的是监控阶段的内容呢？2019-11-11
Cy23尤其是改外包项目的时候，坑多的无法想象2019-11-11
穷查理周末下午，阳光明媚，怀孕五个多月的老婆在旁边床上睡觉，睡的很安详。看了一眼老婆熟睡的胖胖的脸，能给她带来这份安详，我感觉很欣慰。
盯着电脑思考了这个问题一个多小时。想了写，写了又删，删了又想，想到了项目中的很多坑，以及迈过一个个坑痛苦的过程，同时也想到了大领导跟我说的一句话（他说：因为我们不专业），
不知道为何，想到他这句话心里突然酸了一下，后来决定不细说这些坑了。说一点此刻的心情吧，O(∩_∩)O哈哈~
其实对于项目管理，我自己也是懵懵懂懂的开始，两年多摸摸索索的前行。有过很多迷茫、焦虑，也带着小伙伴们取得过一些小小成绩，也在跌跌撞撞的探索过程中最终决定选择项目管理作为自己今后的职业发展方向，同时也意味着开启探寻和学习项目管理专业化和系统性之路。到目前为止，我感觉蓓蓓老师的课程带给我的就是这份专业性和系统化。
希望自己以后能以更加专业的水平到更规范的平台从事这项工作，也希望身边的妻儿睡得更加安详。作者回复: 被你的文字感动到……你一定会成为专业的项目经理，因为你遇到的每个坑，都带着一份礼物，哈哈，祝福你！
2019-11-10
Hunter Liu任何功能必须让产品在各个环节多参与，多看效果，多与开发沟通，多让设计看Demo，因为每个人分工不同，思维方式不一样，产品人员是产品思维，设计人员注重细节和整体美感，开发人员是工程思维，当你思维方式不同，做出的东西可能就会有偏差，如果都弄好再看，是很难达成各方都满意的效果，为了避免后续大量返工，各种怨言，还是前期多参与多互动的好，不然，以我的经验，日程肯定是延期了，各方还都觉得输出了无用功，非常影响情绪和士气，大家都是满满的疲惫感和负能量。作者回复: 对的，早期多方视角的参与最重要
2019-11-10
程序员人生网上曾有过这么个段子，产品经理提给开发一个需求，app的皮肤要根据用户手机壳的颜色改变而改变，不知道这个公司有没有需求评审这个环节2019-11-09- 程序员人生很多公司的前期评审更多地只是一个形式，并没有起到很好的效果。所以到后期问题都暴露出来，然后大家都在加班……2019-11-09
like_junbug bash还没尝试过。2019-11-09
收起评论