项目尾声的反思
2012-09-11 00:23
302 查看
项目接近尾声了,在测试环节遇到一些问题,现在归纳如下:
1、页面和用户提示与设计文档不符合
产生这个原因是由于长期的产品开发思维限制了我对用户的交互模式。产品力求交互的友好性,可以实施的复杂但是用起来一定要顺心和明了,并且要充分考虑到用户的误操作,基本上每次的动作在关键点上都会有提示,例如,用户数据的删除,关键业务点的提示,异常类型的整合,这样的严格控制保证将用户误操作导致的系统错误降到最低。
但是对于物流平台来说,操作的快速和简单却是最重要考虑到问题。提示可以减少,甚至我们可以认为操作人员很专业(的确会专业些,会经过培训)而无需估计,这样能够提高操作人员单位时间完成的物流数量。比如作业单的生成,审核,完成,在扫描校验数据时,提示的出现往往显得累赘。
另外还要丢弃一些程序员的思维,充分考虑产品经理的需求文档,有些我们可能认为需要提示的地方,对于产品经理而言这些是完全可以规避和不需要考虑的。
2、系统单元测试不充分
最大的原因是没有全方位的考虑、理解系统与实现之间的关系,
1、业务流程不够清晰,甚至出现了按照自己想法来实现的怪圈,
2、系统逻辑边界点考虑不足
3、单元测试数据准备不够恰当
3、测试人员对业务不够熟悉
这点不能将责任推到测试身上,业务需要讲解给测试人员,他们只有充分理解了业务需求才能尽量做到对系统的 测试覆盖
4、自我管理欠缺:
1、项目没有一个明确的结束点,导致开发紧迫感不足
2、与产品经理有观点冲突,导致心态的叛逆和浮躁,其实完全没有必要,如果能先完成其观点再提出自己的观点,这样既能保证项目的有效性又能增加自己对别人的好感,这是最好的方式,而不是先摆到对立面去做,毕竟最后产品经理使用验收的,要是不合格吃亏的是自己。
3、测试没有一个明确的结束点这点自身原因很大,系统的漏洞较多,加之测试对业务也不是很了解,因此测试进行的不是很顺畅。应该在单元测试充分的情况下,首先给测试说明业务,期间出现的问题尽快响应和解决而不是一边做其它项目一边响应测试。
4、产品验收没有一个明确的开始时间,产品经理认为到了验收的时间,但是测试还没有完成,于是急切的看项目,这样做是将所有的事情都揉杂到了开发人员的身上,因为他们兼顾了开发其它系统,配合测试人员测试,同时又要面对产品经理的用户体验刁难,虽然可以应付,但是容易出现失误。应该规划好一个合理的时间点,采用串行和并行结合的方式,如果某个环节出现了问题在串行期间就可以解决到,如果一开始就并行那么一旦出现问题将会导致所有人的工作停滞。
5、产品经理对项目背景介绍没有,对系统操作流程没有说明项目背景应该有一个充分的说明,对于系统流程应该有一个图形的描述,同时再结合原型,这样能保证开发人员充分的理解系统,并考虑完整。
以上是对近期项目的一个总结,无论何时都应该有一颗警惕和敏感的心,快速响应彼此,居安思危才不会将自己逼到墙角。
1、页面和用户提示与设计文档不符合
产生这个原因是由于长期的产品开发思维限制了我对用户的交互模式。产品力求交互的友好性,可以实施的复杂但是用起来一定要顺心和明了,并且要充分考虑到用户的误操作,基本上每次的动作在关键点上都会有提示,例如,用户数据的删除,关键业务点的提示,异常类型的整合,这样的严格控制保证将用户误操作导致的系统错误降到最低。
但是对于物流平台来说,操作的快速和简单却是最重要考虑到问题。提示可以减少,甚至我们可以认为操作人员很专业(的确会专业些,会经过培训)而无需估计,这样能够提高操作人员单位时间完成的物流数量。比如作业单的生成,审核,完成,在扫描校验数据时,提示的出现往往显得累赘。
另外还要丢弃一些程序员的思维,充分考虑产品经理的需求文档,有些我们可能认为需要提示的地方,对于产品经理而言这些是完全可以规避和不需要考虑的。
2、系统单元测试不充分
最大的原因是没有全方位的考虑、理解系统与实现之间的关系,
1、业务流程不够清晰,甚至出现了按照自己想法来实现的怪圈,
2、系统逻辑边界点考虑不足
3、单元测试数据准备不够恰当
3、测试人员对业务不够熟悉
这点不能将责任推到测试身上,业务需要讲解给测试人员,他们只有充分理解了业务需求才能尽量做到对系统的 测试覆盖
4、自我管理欠缺:
1、项目没有一个明确的结束点,导致开发紧迫感不足
2、与产品经理有观点冲突,导致心态的叛逆和浮躁,其实完全没有必要,如果能先完成其观点再提出自己的观点,这样既能保证项目的有效性又能增加自己对别人的好感,这是最好的方式,而不是先摆到对立面去做,毕竟最后产品经理使用验收的,要是不合格吃亏的是自己。
3、测试没有一个明确的结束点这点自身原因很大,系统的漏洞较多,加之测试对业务也不是很了解,因此测试进行的不是很顺畅。应该在单元测试充分的情况下,首先给测试说明业务,期间出现的问题尽快响应和解决而不是一边做其它项目一边响应测试。
4、产品验收没有一个明确的开始时间,产品经理认为到了验收的时间,但是测试还没有完成,于是急切的看项目,这样做是将所有的事情都揉杂到了开发人员的身上,因为他们兼顾了开发其它系统,配合测试人员测试,同时又要面对产品经理的用户体验刁难,虽然可以应付,但是容易出现失误。应该规划好一个合理的时间点,采用串行和并行结合的方式,如果某个环节出现了问题在串行期间就可以解决到,如果一开始就并行那么一旦出现问题将会导致所有人的工作停滞。
5、产品经理对项目背景介绍没有,对系统操作流程没有说明项目背景应该有一个充分的说明,对于系统流程应该有一个图形的描述,同时再结合原型,这样能保证开发人员充分的理解系统,并考虑完整。
以上是对近期项目的一个总结,无论何时都应该有一颗警惕和敏感的心,快速响应彼此,居安思危才不会将自己逼到墙角。
相关文章推荐
- 项目中QNX的USB驱动开发的反思
- 死循环内存回收,sql语句效率,项目结尾阶段优化反思
- 囧囧的年终奖-反思做了一年的项目遇到的问题
- 一个想法照进现实-《IT连》创业项目:一个转折一个反思
- 项目反思
- 联想ERP项目实施案例分析(10):回到最初再反思IT价值
- 又到项目尾声时……
- 最近一个项目的反思
- 项目管理之感想与反思
- 项目终于接近尾声了
- 近期做项目的一些反思与总结
- 对面向接口编程、按分层建项目的反思和新的分层结构思路
- 121 项目 020 日志向 阅读 [编程能力的四种境界 ] 的反思
- 一个想法照进现实-《IT连》创业项目:一个转折一个反思
- 近二个月工作和项目的反思──执行力不足
- 项目反思
- 一个项目的反思与总结
- 项目管理之感想与反思
- 项目管理之感想与反思
- 项目终于接近尾声了