Auction网上拍卖项目纪实--Day 26-32

前情回顾:Auction网上拍卖项目纪实—Day 20-25,前台的卖品预展功能在最后时间点成功上线了,可是这才是一个开端,这六天迎接的挑战是用户身份认证,交付定金,退定金等功能模块在10月27日Day33的正式上线。

Day26-32,功能还在推进可是大家士气低落,效率也越来越低,测试小妹加入后虽然保障了功能的最终质量却因为不断地催促无形中给所有开发人员造成巨大压力与反抗情绪。总监一直跟卖品叫价的相关功能所以基本一直在往前推进,为后面的工作铺路。

之前的工作中,我在梳理定金支付(网上支付与线下支付可以结合使用)与审核流程相关功能的时候要求很多工作大返工,B君、C君已经按照要求的流程重做了一次。经过这次教训,觉得有些必要的时间还是不能省,开发人员在产品设计不充分的时候依靠前期根本未细化的数据库设计上开发是没有保障的,因为准备不充分令重要的业务流程在没有跟任何人沟通的情况下就开始开发绝对是小作坊的做法。苦在公司在项目决策经验不丰富的情况下并没有设置一个项目经理的角色,不过在掌握了足够的资源与获得团队信任后,在潜移默化中项目管理与节奏控制的工作都慢慢向我集中可以提前处理了,缓解了这部分的窘迫。

在快速迭代中,由下至上的开发方式很不合理,从业务出发由上至下会是代价最小的处理方式。

Day26的卖品预展功能上线后,马上准备下个时间节点的上线功能开发,心里大致对所有拍卖会的相关流程走过一遍后,召集财务,市场,产品经过各渠道沟通与确认流程、需求点与信息,在没人反对的情况下拍定所有将后续上线的流程。还是有些不放心退款申请与退款审核流程,于是再三口述笔录后让A君来处理退款审核的功能,B君处理退款申请的处理流程,C君因为别的项目又被借走。所有关键功能开发启动后安排测试小妹先按照原型页面与流程做测试用例,测试环节可以让产品经理A与B都参与测试。

Day27-30上线功能的团队开发与测试在各种bug中度过。在其他人的开发过程中,我抽空先帮助总监解决了线上拍卖功能Web服务多节点部署的障碍,因为多个用户拍卖叫价的过程分布到多服务节点中处理会存在一个卖品最高叫价数据不同步的问题(这部分的技术会在以后单篇文章记录)。因为很多涉及用户的金额操作的业务复杂,对于数据事务的同步有特殊的技术需求,为了不影响到大家的工作,在其他人没有意识到时,先解决了这个技术点,然后在审核完成的功能没有问题后统一处理(这部分的技术也会在以后单篇文章记录)。

另外一个项目的各种事情要紧急处理用到一下午,Day29后几天,下班后脑袋里都已经都是浆糊。

Day32晚上,最后为A君、B君分别走查代码填补了一些逻辑漏洞并在需要处加上了事务的处理,知道所有的业务流程在测试环境走测试用例全部通过。但是之前的很多代码一直质量不高,反复更改,不负责任地提交测试的情况时有发生,不过最后几天在其他人的无差别陪坐模式与我擦屁股擦的勤的各种动力与压力下最终大家的工作终于告一段落。



本作品采用知识共享署名 4.0 国际许可协议进行许可,欢迎转载内容并请注明出处
《Auction网上拍卖项目纪实--Day 26-32》 http://io97.com/2014/10/26/10015.html