项目管理实战20讲
雷蓓蓓
网易杭研项目管理部总监,《网易一千零一夜》核心作者
立即订阅
4023 人已学习
课程目录
已完结 23 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词 | 为什么说项目管理是每个人的底层能力?
免费
常识篇 (3讲)
01 | 角色转换:程序员做项目管理的三大误区
02 | 十大领域五大过程组(上):程序员必须要了解的项目管理常识
03 | 十大领域五大过程组(下):程序员必须要了解的项目管理常识
硬技能篇 (12讲)
04 | 启动:识别项目中的四类干系人
05 | 规划:排除计划中的“延期地雷”
06 | 执行:打造品质,要从头开始“闭环”
07 | 监控:进展“巧”汇报,学会用数据说话
08 | 收尾:项目复盘,小团队也要持续改进
09 | 需求变更:化解程序员的“头号噩梦”
10 | 风险管理:如何系统化应对风险?
11 | 质量管理:一次把事情做对!
12 | 高效会议:项目中要开好哪些会?
13 | 故事案例(上):新手上路,如何引入变化?
14 | 故事案例(下):小步快跑,小而美的敏捷
15 | 工具方法串讲:手把手教你高效管理
免费
特别加餐 (1讲)
特别加餐 :“学习”到“实战”的距离,到底有多远?
软实力篇 (5讲)
16 | 向上沟通:你必须要注意的三个误区
17 | 跨部门沟通:怎么让不归你管的人积极配合你?
18 | 向下沟通(上):无权无势,他们不听你的怎么办?
19 | 向下沟通(下):无权无势,他们不听你的怎么办?
20 | 进阶之路:项目经理预备战之PMP认证攻略
结束语 (1讲)
结束语 | 如果我可以,你也一定行!
项目管理实战20讲
登录|注册

11 | 质量管理:一次把事情做对!

雷蓓蓓 2019-11-21
你好,我是雷蓓蓓,今天我们来聊一聊质量管理。
说到质量,很多人会说:“工期太紧了,能按期提测就不错了,Bug 多一点也正常。质量好不好?不好说。如何提升?不知道,QA 会保证的呀。”
我见过的大部分程序员,对自己的代码质量要求还是很高的。但是,一旦遇到赶工压力,尤其是在 deadline 之前,就很可能会把完成度很低的代码交出去,心想“反正有人给我检查,到时候再说吧”。但是,这些代码就好比是一台“行走的 Bug 制造机”,后患无穷。
我曾经在一个技术债特别严重的部门中,面向各级程序员做过一轮抽样的访谈调研。调研的结果是,程序员们只有 27.2% 的时间在做真正产生价值的编码工作。但是,他们有 20.7% 的时间,是在做需求质量和代码质量问题所引发的 Bug 修复、返工和紧急上线工作。
质量成本分为两类:一类是事前防止失败的一致性成本;一类是事后处理失败的非一致性成本,包括内部 Bug 引发的返工成本,以及外部 Bug 导致的用户侧成本。
近些年来,越来越多的公司在严格控制测试人员的比例,鼓励开发人员通过各类技术手段从上游保障质量,就是因为越发地认识到:事后检查处理的代价其实是最高的
实际上,质量是规划、设计、建造出来的,不是检查出来的。预防高于检查,预防错误的成本通常比在检查中发现并纠正错误的成本低得多
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《项目管理实战20讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 哥本
    质量控制从时间维度分为
    事前 做好质量保证计划。
    事中 时时监控节点,防止偏差。
    事后 总结归纳 分析根因,持续改进。
    感觉也是一个小的项目计划
    2019-11-21
    2
  • leslie
    谈谈个人的现实感受吧:其实处理这种技术债应当是两类手段,其实也是两类人的处理方式。
        第一类:定期处理-做事情极度有魄力的CTO,定期会对现状做个总结然后还债,这个可能就像我们用花呗或者信用卡定期主动还款一样。
        第二类:知道一堆问题,可是就是觉得太杂、知道问题、记录下来、大不了这个爆了我还有其它的,总体上最后做到核心不出问题就行,其实这种CTO自己都不知道现有的有些项目哪天会爆了。
         一次性做好是不可能的:前几天刚和极客时间的老师在专栏中聊过类似的问题;有技术债不可怕,怕的是决策者不能确定技术债的风险且适当的时候定期还债,最终导致某些债务引发部分爆仓。
        以上是个人的一点切身体会和薄见:期待老师下节课的分享。

    作者回复: 谢谢,帮你总结下:

    技术债不可怕,定期主动还债,规避爆仓风险!

    2019-11-21
    2
    2
  • qpm
    质量管理在一个正在运行的项目里很重要。我2016~2018年所在的老项目(2011年)就曾经面临质量危机,它是公司收益非常大的项目,危机是不得不解决的。
    危机原因:技术债务堆积数年,开发已经陷入举步维艰的地步,大部分的技术同学一周都得忙两天时间修复线上bug。
    危机解决方法:小步快跑地重构崩坏的代码,对于不方便修改的代码,直接开发一套新的兼容代码,旧的代码让其尘封起来。
    解决关键:所有的小步快跑都要寻找反馈来证明有效;相信工具和自动化;
    项目的是周更新的,迭代速度很快,有利于项目的改动快速得到反馈,甚至说每一个人的努力都可能在下一周得到回应。我那时在团队里以上线晚上的加班时间为自己的反馈,假如超过12点而原因是研发进度问题,则优先解决最重要的研发瓶颈问题。17年花了半年时间不断地重构,重构获得更多的时间后,又可以进行新一轮更难、持续时间更长的重构,团队重新进入良心的循环,最终技术债务逐渐基本还清,17年下半年版本质量重新稳定了。
    后来我补充思考了一些关于防止项目质量重新陷入崩坏的问题。
    1、在技术团队中强调代码的不仅仅是正确与否,有优劣之分,由于项目是快速迭代的,所以代码的可读性和稳定性优先于代码的性能问题。保证每个技术同学都知道这个原则,敢于对违反这个原则的代码自行进行重构(还得培训相关重构知识)。
    2、在技术团队中,补充规范和文档、注释,把之前重构出来的成果以肉眼可见的形式留存下来,要求是一个实习生按照文档操作不会踩到坑。

    现在该项目已经又继续稳定运行了两年多,最重要的成就感莫过于自己留下的框架和规范还有用地指导着新同学去继续这个支持这个项目。

    现在新的项目依然有很多质量的问题需要处理,但是要处理的维度更高了,新项目的问题不仅仅是代码质量问题,而是更多是团队问题,这是我19年下半年最大的挑战。希望两年后回望也有我今日回望17年的成就感吧。

    作者回复: 佩服你的魄力和坚持,棒棒哒

    2019-12-10
    1
  • Cy23
    树立责任感,出来混迟早要还的,回头还债的时间远超发现问题及时修改的时间,因为你要把代码重新复读理解一遍。原来人多还可以安排固定的人做测试,现在设计、开发、测试、修复全都一个人。我只能干活的时候多加小心,尽量考虑全面减少bug出现率。
    2019-11-21
    1
  • quietwater
    质量管理最高境界还是治未病,需求质量决定了质量的上线,需求评审固然重要,但最有效的还是开发测试需求对需求的理解达成一致,包括验收条件。这样大家都心里有数,提高了效率。

    作者回复: 没错

    2019-12-15
  • panqing
    质量卡点的部分不是很具体哦,有没有什么参考资料可以分享?
    2019-12-02
  • maks
    质量把控是一件反复交互的过程,前期代价最小,但是也是最为困难的,对于这一点
    我只能说, "我尽量......"
    其实相比于一次性把事情做对,我更倾向于 与问题的及时反馈与及时处理,
    因此一般我都是解了需求中的 当前系统的现状, 业务要就效果, 怎么达成效果 三点之后
    我就会去做, 我有个习惯 当我做程序员的时候我总是避免编码解决问题,
    如果能避免,那么就证明是需求评审和运维人员的环节出了问题.
    对于质量问题,我只能是完善测试,反向验证,方案评审等手段尽量给每个环节
    来个双保险,(其实是因为甩锅的时候甩的快 !!!∑(゚Д゚ノ)ノ )
    2019-11-29
  • 赖赖猫
    感谢老师的分享。如下2个问题请教一下:1.提测前的质量门禁和上线质量标准是PMO制定后与相关部门沟通达成一致后执行,还是PMO推进相关开发及测试部门/产品部门来完成并上级review拍板?这个问题主要问相关质量标准的制定和推广是怎样进行的?2.针对产线问题的根源分析和改进措施如何做到闭环及改进效果评估?质量提高需要一个过程,有些改进需要技术不能内部立项跟进。如果按月review发现改进方案还未见到明显成效并且review下来还是类似的问题和类似的解决方案,是否参与人会感觉到review是浪费时间,这种情况下您怎样处理的?谢谢

    作者回复: 第一个问题,不清楚你所在组织的具体架构,质量标准制定要结合业务不同阶段的需要来定义,PMO可以起到推进作用,需要产品和开发测试协同来做。

    第二个问题,我在复盘会也特意讲过,线上bug分析算是对线上问题的复盘,复盘最重要的就是改进措施落到实处,否则一再的开自然觉得无意义。

    这样的情况下,问题重点不在开会,而是你要持续去推进bug原因分类,用数据去加快技术部立项等改进措施的有效落地,这个更为重要。

    2019-11-22
  • furyboo
    要做到“一次性把事情做对”还需要一个前提,就是项目的干系人(包括产品、设计、开发、测试等)能够统一对产品需要、目标、质量等有比较一致的理解和认知。
    在我之前的一个团队中,有些项目业务逻辑会比较复杂,在产品需求沟通或者评审时,大家很少会有疑问或者问题,会后就根据各自的理解开始开发或者设计测试用例了,等功能做出来的时候,经常会发现有很大的偏差。
    后来我们采取了一个方案:每次产品讲完需求后,随机让几个参会成员讲解对需要的理解,这样避免了部分成员在开会的时候划水提高大家的参与度,也可以及时发现大家都需要理解的偏差。
    请问一下,大家有没有什么好的办法尽量减小团队成员对需求等理解或者认知偏差呢

    作者回复: 面对面的交流最有效,你用的复述讲解就是很好的方法,另外可以总结看看,经常理解不一致的地方,是否有必要建立一些共同的语境认知。

    除此之外,我们试过在一个团队中,讲完一个需求,就通过扑克牌来做简易的工作量估算,从大家给出的评估差异,就可以把理解上的差异提早暴露出来。

    2019-11-21
  • 天天向上
    质量分析没怎么看懂?很多时候分析开发及测试都认为花了时间但没结果
    2019-11-21
收起评论
10
返回
顶部