CNFM升降级总结

一、分析设计阶段

1、被“CNFM支持子账号”这个名头束缚了思想，没有充分意识到“CNFM升降级”在整个项目中对WS影响的严重程度。这一点，不仅之前的QA同学疏忽了，我自己也有不可推卸的责任。事实证明，在后续的开发和测试过程中，该处的处理成本要远远大过于“支持子账号”的处理成本。

根本原因：对整个系统的熟悉程度不够，还不能够在一定的项目背景下，充分的分析和预测系统真正可能收到的影响和应该做出的调整。

2、项目组的其他成员介入太晚，导致从开发阶段开始，WS线除我之外的几乎所有开发同学，对整个项目的改动点从宏观上根本没有一个清晰的认识。甚至还不清楚自己所作的改动究竟会影响到哪里，以及应该怎样去改。前期的QA同学对项目也没有一个充分的认识。当然，这点在客观上来说，也跟资源的实际情况有关，貌似WS这边的资源安排也确实不怎么给力。

3、对卖家线的后续开发进度做了比较详细的计划，但是对Escrow和买家线的关注不多。当然这个也跟当时对整个项目的理解有关（还没有充分意识到整个项目的影响范围），同时客观上也跟Escrow和买家线的资源介入有关，当时两边都没有投人进来，跟谈不上充分的评估了。

二、开发阶段

1、卖家线在开发初期还是基本按照计划来走的。为了留有充分的自测时间，在前期我甚至留了充分的buffer给每位开发人员，目的是希望大家能够在完成功能开发本身之后，抽出相应的时间进行充分的自测。但事实证明，这点在当时执行的还是有点问题，现在看来，我领的这个小团队，新人貌似还不能完全按计划胜任开发任务，会出现延误现象。老人也故意卡时间完成任务，没有真正有效的利用当初希望预留出来的一段时间。以后对于这种情况，可能需要提前制定一些对策。交叉review和交叉自测可以是一种方法，但是如何有效的执行，还是值得商榷的。

2、都某些不是很熟悉的功能点，过于相信当时的开发人员。比如图片银行容量的变化这个点。当时只是尽量去找到当初做这个功能的人，咨询在哪里使用，影响范围是什么这些。其实任何一位开发人员（包括我自己）也不可能在写完一段代码之后，一段时间之后，还能清楚的记得代码所塑造的业务逻辑和可能影响的范围。这个时候，找到相应的开发时必要的，但是了解了基本背景之后，适当的阅读代码，并且充分grep才是解决问题的最安全方法（至少目前没有发现什么更安全的手段），机器毕竟比人犯错的几率小很多。

3、各条线的开发资源投入时间不等也是一个非常严重的问题。卖家线整个项目受影响最为严重的产品线（也是WS方的主导方）是WS方3条线中最早投入这个项目的一条线。起初重资源、时间的评估上，一直认为卖家线是WS这边最大的瓶颈，总觉得其他两条线再怎么折腾也有足够的buffer可用。但实际上，其他两条线都有自己的问题。资源紧张是共同的问题，但对于买家线，本身自己还没有梳理清楚供级会员的子账号前台逻辑，这不得不说是个不小的问题。对于Escrow来说，开发人员过于自信，轻视了整个项目的影响范围，或者说也不是很清楚整个项目的影响范围。比较杯具的是，我也比较相信两边的开发同学，认为他们有能力并且真正理解了项目的内容。而事实上，我确实有必要在那个时候统一叫上几条线的开发和测试，大家在一起过一遍整个项目的改动点，让各条线的开发和测试充分意识到，项目可能带来的风险点。

三、测试阶段

1、测试前期在系统环境搭建上着实浪费了不少时间。让QA同学弄清楚用分支搭建测试环境和用tar包搭建测试环境没有本质的区别还真不是一件容易的事情。在这个阶段，还因为这个问题跟某位愚昧开发吵得面红耳赤（当时比较生气的是作为一名开发人员，居然不知道两个有什么区别，还理直气壮的认为就应该用tar包搭建环境，也不知道tar搭建环境到底会带来多大的合并分支的时间开销）。别人的问题不多说了，自己的问题是自己没有充分意识到这个问题可能给QA同学带来的困扰。毕竟人家不是干开发的，所以并不会理所当然的知道二方库的release顺序（事实上某些开发也搞不清楚）。这种情况下，其实我应该和所有不理解这个方式的人说清楚，我们为什么放着模式最简单的tar不用，非要用分支。并且让相关各线的人员给QA同学列出相应的二方库顺序非常重要，否则QA同学也不知道应该用什么样的顺序，用了错误的顺序环境搭建的有问题了，也不知道到底啥情况，只能找开发再去搞环境。这个过程就造成了环境搭建的耗时、低效。

2、开发和测试投入时间不连续。这个问题体现的最明显的就是买家线。当时开发完成之后，过了相当一段时间之后，才有相关的QA同学介入测试。当时出现问题了，开发已经无法完全想起当时的情景，QA除了抱怨测试进度的delay，似乎也没有什么方略可以应对了。同时因为开发此时已经投入另外的项目，测试同学在遇到问题时，不能及时找到相应的开发获得帮助也是个问题。当时买家线因为环境搭建问题居然整整耽误了一天的测试工时。但是那边的开发除了质疑我为什么不用tar包搭建环境之外，根本没有提供任何有用的帮助给QA同学，那是我只能牺牲自己的时间来帮QA搭建Escrow环境。这样不仅耽误的买家线的测试进度，也耽误了卖家线的测试进度。

3、测试期间，卖家线抽走了两名其他的开发。主管的意思是他们可以暂时抽出去做别的项目，有问题是也可以再回来fix bug。因为他认为测试期间已经不应该有太多的问题了。但实际上，指望被抽出去的资源再回来处理问题，是非常不可靠的。因为他们已经被其他项目或需求占用，主客观上，都很难及时抽身fix他们搞出来的bug。为了不耽误项目进度，我能做的就只有整日忙碌于测试环境的搭建和各种奇怪的bug fix。加之那段时间故障猖獗，居然照成连续3天没有时间修复bug。当时我最大的问题就是没有充分意识到这个问题的严重性，并主动提出这个问题给主管和项目大的PM，不然这个问题可能通过协调其他资源能够更好的得到缓解。自己也不用搞得焦头烂额了。

4、QA同学的水平也确实是个问题。这个不是针对某个个人，但客观的说，测试阶段确实浪费了我不少的时间在帮助QA重复搭建环境上。面对这种情况，下次再有类似场景的时候，可以考虑抽出一定的时间，写写帮助文档之类的，做些一劳永逸的事情，可能才是磨刀不误砍柴工根本解决方案。

四、发布阶段

1、发布计划制定，当时过于相信Escrow某开发，造成发布计划评审时，才由opps指出Escrow通过vip方式调用RMI的配置项错误。如果当时没有发现，后果会很严重。事实上，到后面，发生在这位开发同学身上的问题还层出不穷。在这里我不想一一列举了，但是这个问题却始终有点困扰我。对于这种情况，我作为WS方的PM，同时兼任卖家线的主力开发，是否需要样样细节过问，事必躬亲。如果是，我哪里有那么多的时间和精力。如果不是，我又能通过什么方式更好的规避这类事情发生呢？

2、发布前一周，进入大联调，细心的汪汪还是发现了一个之前遗漏的ME中价格问题。这个问题，当时我处理的非常不理智。事实上，老姚作为这块的原创作者和最为熟悉的人，以及WS这边的PLA，我最该首先请教的就是他。但我还是做了一个自以为比较负责任的决定，就是从根本上改掉价格的费率不对的问题。这个问题耗费了我大量的时间，因为越做越发现，需要考虑的点其实不仅仅是修改个数据那么简单。DB和存储都必须考虑周全。于是在最后非常宝贵的时间里，我不仅花费了将近两个晚上的通宵时间来实现这个功能，同时也严重影响了QA同学整体的测试进度。在后续自己的精神状态不是很好的情况下，如果不是汪汪及时提醒自己找老姚review这部分代码，还真不知道这么仓促写出来的上千行代码会给QA同学造成多大的负担，以及在预发布或者发布中，抽不抽风。这点必须注意，自己作为PM，在项目的这个阶段，必须学会评估风险！

3、预发布过程中，也问题不小。最为严重的一个问题，就是之前测试好的用户降级之后的产品下架逻辑突然不好使了。这个问题一直折腾我们到了半夜。最郁闷的是，预发布环境timer需要回滚，我们没有第二次线上测试的机会。于是带着这个问题，是否需要在继续深究，我自己也有些摇摆不定了。但是最后关头，还是聪妈严肃要求一定要搞清楚这个问题，不然到第二天正式发布就来不及处理了。于是在预发布当晚，我们几乎采用了各种手段，终于找到了问题。在几乎度过了一个不眠之夜之后，查出来的问题，竟然是因为消息发送方发给我的数据类型变了！我晕倒。这个问题为甚么测试的时候没暴露？因为测试的时候她还没改。又是一个典型没有按照流程走的案例，杯具楽。

4、预发布当天，还有生产环境没有建表的情况，更不用说sql review了，我汗啊。就连sql review都是当天那么紧张的发布环境下临时做的。

5、正式发布当天，又出现了没有提前做数据订正的问题。这个情况，最大的问题，不是忘记了做数据订正，而是当时记得了，但是开发人员因为不熟悉某些表的含义，而错误的进行了线上查询，认为不需要进行数据订正，而实际上他遗漏了9W多条数据。后果还是很严重的。

总结

项目总算发布上线了，带着些许遗憾，带着某些风险，当然还是带着一丝我们努力付出之后看到的收获的喜悦的。零零散散的写了好多，算是做个祭奠。回头想想，其实还是对那些在这个过程中帮助我一起成长的人心怀感激的。

谢谢汪汪在最后关头临危受命，帮我分担了好多工作，并为整个WS这边的项目质量保驾护航。

谢谢刚哥神经半夜，大老远的从家来跑来公司陪我排查问题，真讲究！

谢谢聪妈严谨的态度，不息通宵达旦的帮我review代码，陪我一起分析、调试，让我看到什么才是工程师应该具有的品格。

谢谢彬哥关键时候，跟我一起合作，一句“江湖救急”真的有种为朋友两肋插刀的感觉。

谢谢那些曾经让我觉得很不爽的甚至鄙视的人，是你们让我知道了，很多事情还是需要自己认真考虑的，完全的相信别人还是靠不住的。

最后也得谢谢亲爱的GF在这顿时间的理解。这段时间，确实疏忽了你好多。希望后续你的项目也能顺利上线，同时也不要太辛苦了。。。。。。

最后，希望这次经历能够带给我更多成长，在下一的项目管理中做的更好吧。