《大产品，小团队——携程敏捷技术与管理转型实战》读后感

Posted 2021-03-12 mandou-diu

作为曾经携程的一员，看到一起奋斗过的小伙伴们宣传此书立刻就买了，非常开心拿到了作者团队的亲笔签名版。读完颇为感慨与惭愧，有种虽然身在此山中，竟不识庐山真面目的感受。当时身处携程俩大核心业务之一，却只知一味地吐槽糟糕的流程和无止尽的加班，即没有推动改进的勇气与执行力，也不知背地里整个公司为优化流程，提倡创新所作出的努力，以及已经取得的成果。

诚如书名《大产品，小团队——携程敏捷技术与管理转型实战》，此书着重于在敏捷开发与管理转型期碰到的问题与解决方案，所以建议小伙伴们在学过了ACP，或者敏捷项目管理理论知识之后的再看此书，会对自己的敏捷项目管理起到更上一层楼的认识。

下面摘抄一些对我个人而言有所启发的观点与敏捷项目管理方法。

No.1 理念篇

1. 敏捷的含义并不单纯是实现快速研发，而是快速达成业务目标。

2. PO需要设计用于业务关键指标分析的辅助数据，并对其收集和监控。

3. Story point是一个相对独立的功能点，它能使不同技术水平和工作速度的人在估算结果上保持一致。

4. 我们想改变世界，却发现周围的一切坚硬如铁。:)

5. 如果你无法衡量它，你就无法管理它。

6. 互联网产品的一个重要特点是快，对用户的需求变化需要快速响应，对产品上线后的效果需要快速验证，版本需要快速迭代。

No.2 团队篇

1. 为提高大家的主动性，看板也由之前的电子看板调整为了实体看板，每个人各自去拖动自己的任务条，不再由SM去更新进度。

2. 改良版经典三问，昨天的目标是否完成？今天准备做什么？目标没有完成碰到的障碍是什么？——有助于聚焦于项目整体的风险和状态。

3. 如果团队里还是不时地有人抱怨会议太多，每天都开会都没有时间做事情了，这个时候我们一定要停下来，审视下团队，我们是否明白每个会议的目的。

4. 一个敏捷团队是需要

1）要有交付能力

2）要“高内聚，低耦合”，对其他团队的依赖是少量的或者简单的

3）7+-2是比较合适的范围团队成员数

5. 测试前置也可称为测试左移，其中涉及的工作大致可分为PRD静态测试、服务契约测试、代码静态扫描、单元测试、服务接口测试、开发自测、测试准入检查、入测质量数据统计等。测试前置需要计入工作量，否则即使全员有质量意识但在高强度的工作下也可能有心无力。

6. 学习的721理论

1）70%来自于工作中的经验积累（工作方法+经验技巧）

2）20%来自于人际交往、沟通交流

3）10%来自于培训课堂

7. 团队刺激学习新知识、考核的办法：

1）竞赛

2）积分制——定期对积分排名靠前的员工进行奖励，或者要求累积到一定分数时才有资格晋级或者得到A级考评等。例如“十分感谢”大奖评选（每人有10分，可以送个想要感谢的人任意分数，并注明感谢的话，以1分为最小单位，鼓励尽量把10分送完，不能送给自己），此方法可以用于“孙悟空”类的同事，是否一定要让他作出改变，可以酌情考虑。如果得分尚可，说明对团队的正面影响多于负面影响；如果得分太低，则要考虑谈话了。

8. 只承诺当前优先级最高的事情。

9. 建立统一的沟通方式：微信群、邮件组等。

10. Scrum Master不需要管理太多细节，他需要相信团队是可以解决和克服这些困难的，要专注在对项目整体影响最大的点上。

11. Scrum是用一种可持续的稳定的节奏来降低以往频繁出现在最后一秒临时救火的不可控场面。

12. Scrum Master不要为团队做太多的决定，把问题交给团队，相信团队才是最好的问题解决者。

13. 价值观不是挂在墙上的口号，我们说的价值观是对一系列办公室工作内容的看法。

14. 做事不能光考虑可见的具体目标，更要有那种现在根本无法清晰描述的长远目标，不管怎么说先定下来，往这个方向尝试。

No.3 技术篇

1. 关于技术篇，主要聚焦于CI/CD，虽然我不是专业的DevOps，但是可以看出来携程的运维们为了团队更高效的集成代码，持续闪电交付做出非常多的尝试，也成绩斐然。其中让我印象最深刻的对Jira的定制化，相信大多数的公司都在用Jira，我一度自诩能把Jira灵活运用，生成各种数据报表。然而携程却是将它用到了极致！比如"对物理白板拍照，然后在Jira中上传照片"，就可以根据白板上的变更信息，自动识别并更新系统中对应的任务状态。其次是，将Jira同工程信息打通，统一研发全过程的各类操作入口，发布、回滚只需在Jira中按一个Button就可完成。Seriously？这真的是我用的那个Jira么？！真想体验一下这么高科技的Jira呢！看来对程序猿来说，没有什么不可以，只有你想不到！

2. 他们的思路是，核心用户是一线研发团队，要把用户在项目管理系统中的操作成本降到最低，做到尽量简单、易用、用完就走。不能为了给老板做各种维度的报表，就要求一线人员在系统中填写各种分类字段，这其实是一种本末倒置的行为，牺牲了研发人员创造直接业务价值的时间，比如写代码。（感觉这一点没有强大的技术支持实现起来还有点困难呢......）

No.4 产品篇

1. 如果需要跨公司合作，对方不合作，有时上级领导未必不清楚，这种情况下再没法向上反馈了。只能是从商业合作的角度出发，大家从产品中各取所需，各自获得各自相应的利益。

由于此书是多人合作，每个章节又都是以第一人称的视角在叙述，所以有时候难免会不清楚当下到底是站在哪个角色的角度在分享，章节与章节之间有时会有一些内容上的重复与不连贯，但还是非常感谢携程技术中心的多位小伙伴将自己的经验无私分享出来！