浅谈G端项目产品设计的相关问题(下)

0 评论 1448 浏览 2 收藏 8 分钟

上次我们谈到G端项目中的一些常见的问题,这次来谈谈关于G端输出的内容、原型、文档、大屏及项目终验的问题。本次以公共服务类的项目-中小企业融资平台这个为例,作为产品人员参与了项目需求调研及项目的验收全过程。调研完后我们根据立项文档安排了后面的版本计划,以下是我的一些经验心得:   

一、系统框架图

以下是PPT标书中关于系统框架中常见的内容,从事过售前的产品同事应该比较熟悉,这些都有实现和部署,有空或有必要可单独针对某个模块详细描述。

二、原型界面

1)这是中小企业融资平台官网(融资模块)-的原型设计稿,一般是以线框图为主,不建议做交互,主要是做交互比较浪费时间,必要性不大。但是如果有交互需求或者关联到后端模块时通过文字描述即可。

2)这是中小融的APP版本1.0的原型设计稿。

在输出原型时还是建议使用Axure,给政府方查阅,他们可能不懂IT方面和知识,沟通成本相对有点大,所以输出的内容尽量简单明了,语言描述上不用IT上的专业述语。以下这个业务扭转图把能业务逻辑以及每种情况注释的很清楚,客户看了也挺满意。

三、验收文档

G端项目涉及的文档相对比较多,就单产品负责撰写的文档就不少,比如需求调研方案、需求调研报告、详细设计说明书、系统需求规格说明书、运营操作手册。

这些文档所有的格式一般是由甲方提供模版。其实这些文档主要是出于形式,里面写的内容差不多就行,他们基本不会详细看。

先给大家看看需求调研的文档模板:

其他的文档有些是需要和技术合作写完,比如详细设计说明书,涉及到代码和数据库。下面看看需求规则说明书的模板:

运营操作手册模板如下:

记住运营操作手册需要按角色撰写,尽量简单通俗易懂,主要描述流程和说明。不要写的和需示文档一样复杂。

四、数据大屏

作为服务型的G端项目,基本会存在大屏数据的诉求,大屏的设计思路,首先大屏定位是主要给谁看的,目的是什么,需要解决什么问题。比如有些大屏是给领导设计的,就是做年末汇报。有些则是给特定人员,比如项目管理人员需要通过数据查看内部的问题。

其次大屏设计时要考虑页面要视觉效果要好。否则你内容设计再好可能会被否决。先有好看的外壳然后才看里面的内容这是G端的特殊之处。以下是数据大屏的模板初稿,生产环境的视觉效果会更好。

五、验收问题

1)谁来验收:

G端政府项目一般分为初验和终验,上次说的验收主要是业务相关人员验收。这次的验收主要谈初验和终验,这时候是甲方派遣第三方公司来负责。

2)验收过程,及怎么验

别以为初验和终验人员他们也是专业人员,其实他们多是不懂业务需求的小年轻,验收时只能依葫芦画瓢,立项文档怎么描述就怎么验,所以我在前面提到在产品设计时一定要考虑立项文档上的内容,不然验收时迟早要回炉再造,这样就浪费时间和精力。

功能清单其实都有对应的成本(具体成本这边不便透露),产品设计时也可以了解一下成本,如果一个功能成本太小,没有必要花费太多精力。

验收时一般会咨询产品详细的功能位置和目录,包括如何操作,有些前端看不到的功能可能还需要研发提供代码截图。最后他们记录的问题最好主动过目一下,当然他们一般也会和你核心。因为他们最终要汇总到甲方那,所以在汇总前有错误的地方你可以再和验收人员据理力争,因为有些可能是他不太清楚业务和功能,在描述上可能有误差,比如小的问题写成大的,不存在的问题写成有问题。

4)验收后

验收后一般多用文档记录下来,和产品确认后就反馈给甲方,如果主流程没问题,有些小问题的话,可以再做个迭代版本优化。如果是主流程有问题那问题比较大,甲方公司可能会发布对外公函,意思就是警告和督的作用,主要是给我们最上级领导查看。情况严重甚至扣除部分项目费用。

验收通过后会进入答辨流程,这个一般在线下完成,有第三方主持人,另外甲方邀请的一些技术专家对该系统的评审和建议,其实也不用担心,只是走流程而已,如果你对他们的提问有矛盾,为挽回我们利益的目的下可以进行回复。不过不要进行反驳,最好是作深入一步的补充。答辩完后根据专家提的一些问题进行整改,完成最后盖章,交付完成后等着回款吧!

作者:平心而论,公众号:书海智慧之窗

本文由 @平心而论 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!