解惑

解己之惑,解人之惑

标签:项目

项目又变了

今天下午接到的消息,项目要推迟了,原因是部门的产品的revenue远低于预期,sales说产品质量太差,很难卖,作为开发人员,我们确实也感觉到产品的质量并不是很好,性能存在较大问题,所以开发部门也没有很大的底气反驳这个说法,在我们之前,他们原来都没有做什么像样的性能测试,后来的性能测试的压力也远远小于实际客户的压力,而我们要做的产品,压力是目前最大客户的2倍以上,我们在做我们自己的性能测试的时候已经发现了很多性能问题。

调整的结果是我们的产品推迟(毕竟在沙地上盖房子不会有什么好结果),但是我们去做什么还不太确定,大原则是帮助他们提高他们的产品质量(他们现在深陷火坑,一堆的bug等待他们去解决,没有额外的资源去做产品的提升,而且可能面临裁员),但是怎么合作是个大问题,具体做那些东西也很难讲,真正核心的东西肯定不会给我们做,老板估计也不敢给我们做,但是做其它不痛不痒的东西我们也没有什么成就感,纯粹的变成帮忙扑火了,如果他们自己不能把大问题解决好,我们最后也不会有什么好结果,唉。

使用Checklist提升项目的质量

Checklist这个词是我在做一个日本的外包项目时学到的,问题源于我们最初提交的代码质量非常的差,很多基本的内容编码人员都没有去处理,例如缩进,注释,日志处理,异常处理等,而且由于我们使用的是他们提供的框架,框架本身也有一些要求,到了后来,我们根据以前常见的问题罗列了一个list,而另外抽调了几个人专门根据这个列表进行检查,就演变为checklist,而且这个列表是不断更新的,发现新的共通的错误就加进去,如果有原来的检查项在经过一段时间后几乎就没有再出现过就从列表中删除以减少检查人员不必要的工作。最重要的是这个经验后来被推广到其它的项目组,以及项目的各个阶段,例如需求分析有需求分析的checklist,设计有设计的checklist,即使是测试组也有自己的checklist,因为有些刚刚开始做测试的人对于基本的测试原理并不熟悉,例如边界测试,极大值极小值测试,异常系测试,对于经常被新人忽略的的测试类似就会有一个这样的list,而且每个系统会有一些自己特有的需要特别关注或者以前比较容易出问题的地方,也可以列到这个list里面。这样在整个软件周期中我们可以避免很多常见的问题,大大提升软件的整体质量。

上线成功

经过24个小时的奋战,项目成功的上线了,虽然还有些问题,但是不是什么非常严重的问题。本来我是两班倒的,但是中间只有不到6个小时的时间,如果扣除中间坐车的时间也就没有多长时间了,就没有回去,连续奋战。还好结果比较好,我也就比预订的时间提前回家了。
上线成功是最好的消息,因为这样我就可以安心的回家了,可是一个Team的其它人还要再继续辛苦一个星期,因为还要继续Support一个星期以防在出现问题的时候可以及时解决,有的人还要上夜班。
今天晚上就回家了,希望结婚的事情能够比较顺利

项目上线

项目明天正式上线,周六周日两天都要加班,今天晚上十点的飞机票也作废了(由于是四折以下的特价票,不能退也不能改签,只能退燃油附加和机场建设费),老婆也不想一个人走,在等公交车的时候决定不走了。
这次项目上线非常的重要,是公司自己开发的第一个重大版本(原来都是外包的),也是中国这边的研发中心的第一个重大版本,而且到目前为止的进度和结果都非常的不错,按照公司方面的报告,完成了预期的127%,呵呵,但是在Stage环境中的发布并不顺利,问题多多,希望经过那个锤炼以后,这次的正式上线顺利一些(Stage和正式上线都是美国的Team执行的,而不是我们的开发团队)。
由于事情重大,所以虽然我一个月以前就请好假了也不得不推迟,希望一切顺利,我能够星期天晚上或者星期一回家准备结婚的事情。

© 2024 解惑

本主题由Anders Noren提供向上 ↑