初次接手To G项目，我真是太天真了（下）
接着上篇文章，我们继续说To G项目的产品设计要点。
一、产品设计要点
1. 接口文档更新保存
这个看起来是个基本操作，但由于To G项目的特殊性，以及接口人的频繁变动，这个基本要点却会成为将来需求开发，功能逻辑梳理的重要来源。
所以接口文档，对接文档，需求文档都需要进行及时更新和保存，必要时要进行双方盖章确认，从而保障后续工作的进行。
2. 考虑弱网环境与基础浏览器设计
在现如今的互联网开发过程中，我们会习惯性的在网络通畅环境，并使用谷歌浏览器进行测试开发调试，但在To G项目中，这种习惯恰恰会带来后期更多的兼容问题。
由于To G项目的特点，他们有多个层级使用者：基层工作人员，部门领导等等；对于这些使用者来说，他们所处的网络环境并不够好，硬件也不够完善，使用的浏览器甚至是研发同事最讨厌的IE浏览器。
曾经在一次测试过程中，由于开发人员修改了一个Js文件，导致业务方无法登录，无法校验后续的流程，研发同事的电脑却一直无法重现，重重排除后终于发现是由于浏览器的版本没有升级造成的……
研发同事很无奈的说：他们可以升级一下浏览器不？
我只能回复：倒不是他们不想，是他们的电脑硬件不允许。
所以在开发过程中，必须要考虑到这类的弱网环境和基础浏览器的设计，先做好兼容，从而避免返工。
3. 不激进采用互联网式思维与设计
相信每位产品经理会经常关注市面上最新的设计风格，以及高效便捷的操作体验。
但是在To G项目中，激进的使用这类设计容易让你碰一鼻子灰：
- 一方面G端业务方并非不能接受这类设计，但层层上报的机制会让这类设计不断修改，最终反而变得不伦不类；
- 另一方面这类设计和G端产品的调性并不相符——政务类/政府类的软件在产品设计上依旧需要带有一定的稳健感，而不是纯粹互联网化。
二、沟通方式要点
接下来，我要说说与To G项目业务方沟通的几个要点，这也是这段时间工作给我带来的启发
1. 了解原因
To G项目不像普通的业务产品，其中涉及的业务流程可能同时跨越好几个部门，每一个部门的流程都不能轻易修改；在进行需求沟通时，必须往下深挖，具体在哪个环节出现了问题，以最小的方式完成最大的效益，否则就有可能牵一发动全身，整个流程乱套。
2. 明确信息概念
在To G项目中，经常会出现相似的词语，但代表的信息却完全不同。
例如在之前的一次数据统计表设计过程中，我就由于对“直接下级”和“所有下级”的概念没有明确，差点将所有字段的统计逻辑进行全盘推翻，所以明确每一个具体的信息概念非常重要。
3. 平等交流
也许有些人会觉得和政府部门合作，心理上就矮了一截，但是在我看来，用专业能力说服他们采用我们的方案，才是更有效的工作方式。
三、总结
回想起这半年的To G工作，和To B /To C项目在工作方式上，沟通方法上有很多的不同，这样的经历也是十分难得，感触良多，与大家共勉！
#相关阅读#
初次接手To G项目，我真是太天真了（上）
初次接手To G项目，我真是太天真了（中）
本文作者 @DHAllison 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
