项目尾声的反思
来源:互联网 发布:ubuntu怎么运行py文件 编辑:程序博客网 时间:2024/06/02 07:47
项目接近尾声了,在测试环节遇到一些问题,现在归纳如下:
1、页面和用户提示与设计文档不符合
产生这个原因是由于长期的产品开发思维限制了我对用户的交互模式。产品力求交互的友好性,可以实施的复杂但是用起来一定要顺心和明了,并且要充分考虑到用户的误操作,基本上每次的动作在关键点上都会有提示,例如,用户数据的删除,关键业务点的提示,异常类型的整合,这样的严格控制保证将用户误操作导致的系统错误降到最低。
但是对于物流平台来说,操作的快速和简单却是最重要考虑到问题。提示可以减少,甚至我们可以认为操作人员很专业(的确会专业些,会经过培训)而无需估计,这样能够提高操作人员单位时间完成的物流数量。比如作业单的生成,审核,完成,在扫描校验数据时,提示的出现往往显得累赘。
另外还要丢弃一些程序员的思维,充分考虑产品经理的需求文档,有些我们可能认为需要提示的地方,对于产品经理而言这些是完全可以规避和不需要考虑的。
2、系统单元测试不充分
最大的原因是没有全方位的考虑、理解系统与实现之间的关系,
1、业务流程不够清晰,甚至出现了按照自己想法来实现的怪圈,
2、系统逻辑边界点考虑不足
3、单元测试数据准备不够恰当
3、测试人员对业务不够熟悉
这点不能将责任推到测试身上,业务需要讲解给测试人员,他们只有充分理解了业务需求才能尽量做到对系统的 测试覆盖
4、自我管理欠缺:
1、项目没有一个明确的结束点,导致开发紧迫感不足
2、与产品经理有观点冲突,导致心态的叛逆和浮躁,其实完全没有必要,如果能先完成其观点再提出自己的观点,这样既能保证项目的有效性又能增加自己对别人的好感,这是最好的方式,而不是先摆到对立面去做,毕竟最后产品经理使用验收的,要是不合格吃亏的是自己。
3、测试没有一个明确的结束点这点自身原因很大,系统的漏洞较多,加之测试对业务也不是很了解,因此测试进行的不是很顺畅。应该在单元测试充分的情况下,首先给测试说明业务,期间出现的问题尽快响应和解决而不是一边做其它项目一边响应测试。
4、产品验收没有一个明确的开始时间,产品经理认为到了验收的时间,但是测试还没有完成,于是急切的看项目,这样做是将所有的事情都揉杂到了开发人员的身上,因为他们兼顾了开发其它系统,配合测试人员测试,同时又要面对产品经理的用户体验刁难,虽然可以应付,但是容易出现失误。应该规划好一个合理的时间点,采用串行和并行结合的方式,如果某个环节出现了问题在串行期间就可以解决到,如果一开始就并行那么一旦出现问题将会导致所有人的工作停滞。
5、产品经理对项目背景介绍没有,对系统操作流程没有说明项目背景应该有一个充分的说明,对于系统流程应该有一个图形的描述,同时再结合原型,这样能保证开发人员充分的理解系统,并考虑完整。
以上是对近期项目的一个总结,无论何时都应该有一颗警惕和敏感的心,快速响应彼此,居安思危才不会将自己逼到墙角。
- 项目尾声的反思
- 中级项目进入尾声
- 项目组的ST终于快接近尾声了
- 最近一个项目的反思
- 最近一个项目的反思
- 最近一个项目的反思
- 关于尊严项目的反思
- 最近一个项目的反思
- 尾声-怪盗基德的逃离
- 一周简报(项目尾声)
- 哇、项目接近尾声了。
- 第三个项目接近尾声
- 项目终于接近尾声了
- 尾声
- 尾声!
- 反思项目
- 项目反思
- 项目反思
- 函数调用 堆栈 转载
- 在路上
- 《推荐系统实践》读书笔记——推荐系统十戒
- c常用函数实现
- PostGIS介绍
- 项目尾声的反思
- 青春划过指尖
- memmove,memcpy 函数的分别实现
- javap生成的字节码的意思
- Android 内存监测工具 DDMS --> Heap
- oracle mysql sqlserver 查看当前所有数据库及数据库基本操作命令
- LDD3读书笔记(第7章 中断处理)
- 推荐一款JavaEE项目原型设计工具
- jquery处理xml数据