本文主要是介绍历时4小时的原型评审会,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
前言
本次评审的项目属于政务类管理系统。具体业务肯定就不能透露了,按照正常流程执行话,我预计评审时间在1.5h。这次却达到了惊人的4小时,本篇文章简单陈诉一下个人主观上总结的问题,同时也希望自己的总结能够给位同学的思考及帮助。
问题总结与分析
-
产品原型问题:为了提高操作数据录入效率,操作极其复杂,某些功能开发都难以理解。
对于一个TOG管理系统,在满足需求的同时,产品界面统一简洁、操作方便 是非常重要的,因为公职人员群体年龄基本都是35+的偏多,所以在产品的设计上一定要考虑操作简单以及又容错性。我一个开发对于有些操作逻辑都很难理解,对于客户来说我相信就更难了。对于开发来说太复杂的逻辑也不利于后续的迭代。在传递这么复杂的操作上也花费了大量时间。 -
跨专业的讨论:业务过于介入到研发层面的讨论。
业务介入到技术层面的讨论,导致双方理解不到对方的意思,这样的沟通导致浪费大量的时间。当然从另一个角度来说跨专业的讨论也可能产生一些新的idea,打破固有的思维局限。 -
前期的需求分析,数据调研不充分:没有需求文档,缺乏数据调研工作
我们公司的开发流程是没有严格的需求分析流程的,需求是有业务反馈给产品,反馈给产品大多时候还是口头传递,没有需求文档输出。
因此在评审的时候,这个需求到底是谁提的,产品和业务还在拉扯。
有些数据应该有第三方在维护的,比如街道信息等,这些数据谁提供,能不能提供,是我们自己维护还是三方提供接口,这些前置工作没有提前做的。
建议
做To G的项目时,需求分析做得不够深入时,第一个版本,不要把细节做得太深入复杂。尽量常规功能常规做,多考虑产品易用性,减少用户误操作概率。调研工作提前开展,需求文档化。
欢迎各位大佬提留言评论
这篇关于历时4小时的原型评审会的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!