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

一、系统框架图

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

二、原型界面

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

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

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

三、验收文档

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

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

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

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

运营操作手册模板如下：

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

四、数据大屏

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

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

五、验收问题

1）谁来验收：

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

2）验收过程，及怎么验

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

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

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

4）验收后

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

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