历时4小时的原型评审会

2024-01-09 18:40:27

前言

本次评审的项目属于政务类管理系统。具体业务肯定就不能透露了,按照正常流程执行话,我预计评审时间在1.5h。这次却达到了惊人的4小时,本篇文章简单陈诉一下个人主观上总结的问题,同时也希望自己的总结能够给位同学的思考及帮助。

问题总结与分析

  • 产品原型问题:为了提高操作数据录入效率,操作极其复杂,某些功能开发都难以理解。
    对于一个TOG管理系统,在满足需求的同时,产品界面统一简洁、操作方便 是非常重要的,因为公职人员群体年龄基本都是35+的偏多,所以在产品的设计上一定要考虑操作简单以及又容错性。我一个开发对于有些操作逻辑都很难理解,对于客户来说我相信就更难了。对于开发来说太复杂的逻辑也不利于后续的迭代。在传递这么复杂的操作上也花费了大量时间。

  • 跨专业的讨论:业务过于介入到研发层面的讨论。
    业务介入到技术层面的讨论,导致双方理解不到对方的意思,这样的沟通导致浪费大量的时间。当然从另一个角度来说跨专业的讨论也可能产生一些新的idea,打破固有的思维局限。

  • 前期的需求分析,数据调研不充分:没有需求文档,缺乏数据调研工作
    我们公司的开发流程是没有严格的需求分析流程的,需求是有业务反馈给产品,反馈给产品大多时候还是口头传递,没有需求文档输出。
    因此在评审的时候,这个需求到底是谁提的,产品和业务还在拉扯。
    有些数据应该有第三方在维护的,比如街道信息等,这些数据谁提供,能不能提供,是我们自己维护还是三方提供接口,这些前置工作没有提前做的。

建议

做To G的项目时,需求分析做得不够深入时,第一个版本,不要把细节做得太深入复杂。尽量常规功能常规做,多考虑产品易用性,减少用户误操作概率。调研工作提前开展,需求文档化。

欢迎各位大佬提留言评论

文章来源:https://blog.csdn.net/weixin_39439156/article/details/135475525
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。