2019-11-11最坑的就是工期倒推,产品的东西你可以评审,评审不合格就改,可是占用的都是开发的时间,最终结果是产品文档改的合格了,工期到了,是开发没有完成.作者回复: 谢谢你的留言，这个问题很典型，我在09中有专门讲解我们的做法，希望给你些参考。
3 15
2019-11-161 产品说：这个功能很简单，就和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 欢迎补充。。。展开作者回复: 段子会火
4 7
2019-12-20蓓蓓姐，问个私人问题，作为一个女孩子，你每天作息怎么安排，能做好网易项目经理工作，还能写书，备课，你怎样激励自己的。非常感谢🙏作者回复: 先说作息，实际上，人的作息弹性之大，超过了你的想象，挤一挤总会发现，还能继续加！！专栏期间，大体就是每天改稿到凌晨下班，醒来就是录音，周末全部把娃支走，都别理我的节奏。
再说自我激励，我见过很多非常优秀的人，努力的程度也超过我很多，所以我也会经常产生这样的感慨，无法想象他是怎么做到的？他是怎么坚持下来的？
后来我发现，其实这些人背后，内心往往都有一个自己还不够好的声音，随时随地拿着个小鞭子对自己，不管别人怎么认可，他自己还觉得不够完美，没办法他只能往前做更多，哈哈哈
所以，千万不要羡慕这些人，每个人有自己发光的方式和节奏，找到你的那个独一无二的热情最重要，这样一来，并不需要什么意志力来坚持，我只是乐此不疲罢了！ 1 6- 2019-11-09我作为一个程序员，有一次接到需求之后。
按照流程需求分析，然后编写需求实施方案经邮件通知。
结果在开发完成，技术测试后。到业务测试环节，业务人员却说：“这不是我要的效果” 。
最可笑的是我们在核对需求都时候，却发现我从项目经理那拿到的是一个旧版本的需求书。
然后当我发现所谓的新版需求书根本连需求都没描述清楚，是几个系统的需求混合在一起（如果一开始是这一版我绝不会接受）。
连夜赶工按照当前需求所述考虑已开发的特性和系统可行性得出的实施方案（现在想来，我应该先让业务核实我的实施方案，不然又做无用功）。
实现之后立刻让业务人员核查一点一点确认，最后终于按时上线。
（现在回想我应该在事前在仔细沟通，至少一个电话确认，而非两份文档石沉大海，了无音讯）展开作者回复: 反向验证，从我做起，嗯！
3 
2019-11-09期待蓓蓓姐做一场直播作者回复: 蓓蓓姐正在超级马力通宵备课状态……
现在，做好课程是第一位。直播会有的，让子弹飞一会～ 3
2019-11-09我们的设计稿都是产品一个人敲定，设计人员直接受产品经理管理。现在开需求会甚至都没有原型只有需求描述就开搞了，而且口头禅是 这个需求很简单，研发叫苦不迭作者回复: 你这种情况我也遇到过！可以看下第9讲，需求变更应对，我会详细展开，关键在于产生共识。
2
2019-11-09坑很多，例如按照研发流程经过了立项评审，包括对需求和设计可行性的评审，领导也有参与，最后项目上线，没有达到客户预期。并不反对流程，但是在执行流程的过程中有些流于形式了，并未引起所有人员的重视，感觉公司有要求，就走走过场。
最后，除了问题，都得挨批，研发还得返工，这中间的帐就是没算没明白，总认为流程耽误时间，回头一看，欠的帐总是要还的，只是时间未到而已。 2
2019-12-23本讲中的OARP让我想起了项目管理里的RACI矩阵，RACI是沟通管理的一种可视化工具和模型，OARP更强调了在流程中明确角色职责。其实，流程和速度总是相爱相杀，没有人愿意被流程束缚，每个人都认为对方知道自己该干什么，但实际上“应该思维”害死人！一个优秀的项目经理能够让流程闭环，在各个节点有响应和反馈，发动群众“搞运动”（bug bash） 1
2019-11-20最后说的冒烟测试没看明白是什么作者回复: 一般是指针对最基本的功能或最主要的业务流程进行的测试，用作提测验收条件。
1
2019-11-11在敏捷開發團隊如何落實這些閉環？每個sprint時間都很短，沒有多餘時間進行這樣的閉環測試作者回复: 拆分成小迭代之后，你可能未必在每个迭代都这么做一遍，根据整体的里程碑规划，可以在封版测试的时候，设置相应的环节来做闭环测试
1
2020-01-19请教老师，请问项目开展的正确顺序是什么？
从用户角度看，一般先有RFQ还是RFP呢？
2019-12-23想请教下，bug bash这种活动是每个环节都要进行的吗？然后假如需求评审第一次bug很多，修复之后是否需要第二次对于需求的bug bash？假如问题还有，是否需要第三次？我的疑问就是bug bash需要做到什么精细度？贵司关于这一块的标准化是什么样的？请老师解惑，谢谢
2019-12-17OARP中审核者（Reviewer）应该指定项目中的什么人呢？如果每次都选择开发的leader，那leader不是应该会很忙吗。如果选择项目组其他组员，又担心组员的能力不够不能从整体考虑设计。作者回复: 这个是人员后备的问题，不是机制本身解决的，机制只是告诉你，需要有这个角色。问题有的话，之前也会有，如此更多暴露之后，相信可以更快地引发重视。
2019-12-02假设对方都清楚地沟通是团队协作的一个大问题，给各个岗位设定一定的反馈机制非常重要。我们这里测试负责给研发开发反馈，在策划方面却缺少了，导致阅读文档理解成本很高，经常遇到“一句话需求”。现在也是让我觉得头疼，引进流程，改变是一件不容易的事。作者回复: 想要在团队中引入变化，你可以看下第13篇，新手上路，如何引入变化，有详细拆解的步骤。
2019-11-20方案评审是目前团队会做的，但是基本流于形式，根本的问题是不少人在策划阶段根本不会用心去看产品的策划案，许多关键问题被漏掉了；bug bash也许是个好的激励机制，但是目前团队感觉推不起来呀~~感觉需要项目管理人员去推。作者回复: 觉得这方法好，如何引入变化到团队，这也是一门学问。实际上，你并不需要有非常大影响力，或是专职项目经理才能去做这件事。
不管是引入bugbash，还是复盘会，其实都一样，我在第13讲中会具体讲怎么做。
2019-11-12来自产品的“很简单，和xxx老逻辑一样”。类比本身是好事。但当你的项目，又老又烂，而开发又嫩又懒时，这就是个噩梦。老项目功能可读性低，又不存在什么灵活扩展的空间。所以老逻辑想要兼容新的业务元往往需要投入高成本的阅读理解和适当的代码重构。而年轻的程序员由于缺少一定的业务背景和经验，阅读理解容易产生偏差，重构手法也不娴熟，还懒得一一验证当前功能所有case的准确性。于是往往就容易导致兼容出bug的现象，结果不仅新的业务元无法使用，老的业务还受到破坏，很可能最终就是这个迭代延期（并没有很好管理代码版本，迭代里多个需求的代码提交都是耦合的，没有提交的原子性，导致如果临近发版出问题，迭代里的需求难以再拆分，只能整个延期）。作者回复: 你这句话很典型的，又老又烂vs又嫩又懒，真是滋生技术债的天然土壤。
2019-11-11整个方案评审有必要从头到尾跟着吗 现在手里项目多了 方案评审很多参加不了 导致很多方案只知道结果 不知道内容 做出来才发现有问题 这个怎么平衡作者回复: 不知道你在这个评审中的角色是什么，OARP重要的为不同的方案明晰角色和责任，如果你是reviewer，就必须提供意见，不能全程参与的话，也要相应指定好替代者
2019-11-11一句话概括就是设法降低沟通成本，消除信息不对称。
2019-11-11为啥我感觉这节说的是监控阶段的内容呢？
2019-11-11尤其是改外包项目的时候，坑多的无法想象