这个总结,好几次想写,每次新建了文档之后,就不知道从何写起。可能东西太多了,也可能是自己懒惰了。但是今天决定动笔了。
刚刚毕业的时候,做过的项目都会写总结,不论大小。但是这一年来,项目的总结越来越少了,不是因为没时间写,可能随着工作的深入,觉得有必要写总结的项目没有多少了,自己慢慢变成一个熟练工,但是我觉得这不是啥好兆头。这个项目,确实非常有必要落笔写一下。之前参与过大型项目,但是作为PM来主导一个项目还没有过,也算是程序员生涯中一次难忘的经历吧。
问题:这次项目内容是啥?
项目整体涉及到物流服务的三个业务,次日必达、预约配送、新版保障速递。次日必达能够从字面上就能理解,是一个时效产品,商家给消费者承诺第二天送达的服务,如果没有送达,就赔钱。预约配送,最简单的解释是消费者在下单的时候,能够选择物流公司配送的日期和时间段。之前的保障速递是作为一种配送方式来体现,现在含义变了,新版是一个时效产品,用户订购这个服务后,把快递公司的时效数据披露在商品详情和交易下单页面。刚刚开始老板和我聊的时候,是一个业务场景,后来是又加了一个,这个时候我自己心里就没底了,因为单独做一个服务就可能需要一个半月时间。后来在过程中又考虑把保障速度改版的事情加入进来。这个时候我彻底凌乱了。东西实在太多了。而且中间涉及到一个P0系统一个P1系统的改造。稍有不慎,直接就是大问题。吃不了兜着走的那种。总结来看,在原有系统基础上,修改一个服务,添加两个服务。
问题:项目的时间计划是怎么样的?
技术方案评审是4月27日,这个方案用了两天的时间搞出来的。本来打算模块划分好,让每个开发出自己部分的技术方案,但是时间太紧了,只能全部搞掉了。然后开始定的发布时间是5月23日,中间开发写代码的时间只有8到10天,测试时间只有7-10天左右。后来由于实在搞不定,就延期到5月27日。发布用了一天加半个晚上,发布那一天,对于每个同事来都是一个挑战,那天的工作负荷以及压力,是我不想再体会的。整体历时一个多月,正好是五月份,可以说是黑山五月。
问题:项目的挑战性在哪里?
首先谈一下我自己的挑战点,之前自己的技术关注点主要在数据方面,看技术东东也停留在数据部分,对于物流服务的系统不是很熟悉,之前的服务是怎么做的也不是很了解。而这次大部分的东西是在原来的架构体系下做改造,这时候就需要我在短时间内快速了解之前的系统架构是怎么样的。另外项目包含三个服务,彻底搞清楚需求,是很耗时的。这些挑战大部分来自我自己。剩下的就是团队的了。物流宝技术的组织架构刚刚调整,参与这个项目的成员,没有几个对于原有的系统了解,这时候对于原有系统的影响点以及风险点评估可能就没有那么到位。另外开发的同学,刚开始确定的一个同学中间表明要离职,这时候我彻底郁闷了。正在我犯愁的时候,一个测试同学转开发,正好目前空着,加入了项目组,解决了我的燃眉之急。总结来看,时间紧,任务多,项目组成员以及我自己对于原有系统熟悉度不够。
问题:项目参与人员情况如何,外部合作团队有多少?
内部服务相关五个系统,还有结算部分,外部合作有六个团队。旺旺群里加了有七十多个人,实际上还更多,后面说实话我懒的加人到旺旺群里了,全是电话聊了。开发累计有七八个,因为有些同学不是全职的,测试后面投入了七个同学,三个PD。外部合作的团队情况就不多介绍了。这次外部合作都很给力,非常感谢大家对于项目的认可和配合,容忍了我们对于时间点的要求。
问题:项目的风险在哪里以及如何规避的?
首先是时间点的保证,这一个是最大的头疼点,但是没办法。中间在讨论需求的时候,很多次和PD争论起来,但是这体现在项目的前半段,后面就淡定很多了,有需求变更就变更吧,哥不做了,谁说也不行。中间的风险点很多一一列举有三十多条。如何规避的呢?总体是能找人评估的直接找人,需要看代码解决的就快速看代码,需要测试增加用例场景的就增加用例。沟通上面,能电话的不旺旺,能当面沟通的不打电话。
问题:上线后有没有问题,灰度和beta等过程中有没有问题?
目前灰度部分,有两个地方,在服务订购的地方,前期做了白名单,用来限制用户的订购行为。再就是服务在交易端的展示,又做了一层白名单。这两个白名单来服务于业务试运营阶段。还有针对新增的两个服务,做了降级开关,在有重大问题的时候,果断关掉这个开关。关于beta,是在应用发布的时候先单台发布,观察一段时间,发现问题了没有?发现了,有一个系统在调用用户中心的时候,代码有问题,每次都会调用,这个上线后有什么后果,后果是用户中心增加20亿左右的调用量。后来回滚,修复了一下午,晚上通宵发布的这个应用。还好两点多就发布完了。上线后有一个js问题,由于开发同学和前端协作部分,引用的js文件没有修改时间戳,这样需要用户强制刷新浏览器才能得以解决,还好紧急发布掉了。后面再就是几个文案的小问题,27号发布完成,28号一天基本上都在发布模板文件,中间还有一次紧急发布。
问题:项目做完后,项目的成员成长性在哪里?
这一点是我一直比较关注的,商业类的项目,对于业务人员来说可能是一个产品的诞生,但是对于技术人员的成长在哪里呢?在我看来,项目成员都是有提升的,最差了解了系统,成长多或者成长少,这里我就没法评估了,毕竟感受是大家的。对于我自己,可以说对于写代码的能力没有提升过少,虽然杂七杂八的需求点代码是我写的,但是说实话没有多少提升。但是对于沟通协作,确实有了更多的了解,在外部协作的时候,可能有时候需要多站在对方的角度考虑问题。基于理解的基础上,很多问题就可能不是问题。再就是cover大型项目,这一次是一个证明。
规避掉了一些敏感部分,其余的贴出来。分享给各位。。。