政务项目的产品规划，通常需要结合项目的里程碑一起定制，按照时间来交付，在项目周期内，在什么阶段需要做哪些？本文总结了政务G端产品的建设指南，希望对你了解相关流程有所帮助。

一、背景

本指南，基于数字政府建设的要求和趋势，从多个角度阐述数字政府建设的行业经验和方式方法，包含涵义篇、体系篇、建设篇、经验篇等内容，供各位想从事了解或者已经从事政务行业的人士参考。

本篇为经验篇的其中一个章节，错误或不完善的地方，还请指正。

项目风云变幻，一个好的产品规划，是项目能够获得主动性的关键，也是产品能够平稳落地、符合逾期的核心。

政务项目的产品规划，通常结合项目的里程碑一起定制，也就是在规定的项目周期里，各阶段计划实现哪些内容。

二、产品规划

1. 需求管理

政府行业的需求，具有一定的不确定性和浅显性，分析需求时，一定要主动思考，不能以“客户提出的就是对的”这种心态管理需求。

需求的来源，除了上述提到的需求调研之外，还包括项目内部团队成员提出、老板提出、竞品分析等。通过以上多种渠道收集来的需求，需要进一步的分析整理，整理要点如下：

需求的准确性。并不是所有的客户需求都会直接传递给产品经理或需求分析师，因此，产品经理或需求分析师在收到“二手”需求时要第一时间确认原始需求，尽量要到客户原话并加以理解分析，如果第一时间不能完全确认需求，尽量约客户进行二次需求确认，避免出现理解不一致返工的情况。

需求的有效性。我们经常会陷入一个“自我认同”的心境中，即接到需求的第一时间，就认为需求是真实需求，甚至在客户现场就光速答应客户会实现提出的需求。谈论需求时，首要明确需求是否是真实需求，如果是伪需求，进一步看看是否属于因客户表达方式问题而忽略的隐藏需求，试图挖掘背后真实的意图；如果识别为真实需求，判断技术上能否实现、实现的难易程度以及是否超出合同范围等。

需求的价值性。并不是所有的有效需求都要满足实现，受限于资源、时间等因素的影响，需要考虑需求的实现价值。企业经营产品，核心是盈利，本质是减少成本，特别是政府项目，成本控制是很重要的一环。

因此，产品设计或者完善的过程中，需要考虑需求的定制性，即需求是否具备一定的通用性。如果需求具有一定的通用性且对客户有价值，那是必须要实现的；反之，如果需求定制性很强，除非是客户有强制性要求或者爽快花钱，那么就要考虑如何把定制性的内容尽量地抽离甚至拒绝，或者协商加入后面的项目规划中。

需求的紧急性。项目是循序渐进的，客户是急不可耐的，需求是可以排的。划分需求优先级，也是产品规划中比较重要的一个事项。P0级别的需求，一般指客户强烈提出、涉及功能交付节点、严重影响客户体验、影响主流程的程序BUG等类型需求。其他类型的需求，结合项目计划、团队资源、客户反馈等因素依次排列。

整理好的需求，放入需求池中管理。关于需求池的呈现载体，最常见的就是Excel在线文档，其次就是项目管理工具，如TAPD、禅道、Teambition等。

当然，工具不是最重要的，重要的是池子需要记录哪些信息。需求池的信息分基本信息和状态信息，基本信息包含需求名称、需求描述、需求类型、需求模块、需求来源、需求优先级、提出人、提出时间，备注，状态信息包含需求状态、解决时间、解决版本、负责人。必要时，可以定期对需求池进行统计分析，为客户回复和后面的产品迭代提供依据和参考。

要重视需求池的日常管理，特别是在政府项目中。一方面，需求池的日常维护可以体现我们的工作量，另一方面，当需求的分析出现偏差的时候，可以通过需求池溯源。

2. 需求设计

需求设计，即产品设计，输出原型和需求文档。

产品设计工作开展之前，要对拟设计的需求充分论证分析。

一是转化需求为功能。需求是要听懂用户讲什么，功能是要讲明功能做什么。

举个例子， 假设用户的需求是从广州到上海，那么，就要摸清用户具体想要什么（功能）。

首先，摸清用户的真实目的，比如去上海的原因、时间，如用户是想去旅游，那么就可以事先查查上海的天气情况，天气不合适时需要调整用户的预期，更换需求（比如换个目的地）或者调整功能（比如换个时间）；其次，摸清用户的信息，比如住址（判断路程）、前往人数（判断规模）、年龄分布（判断人群）、预算（判断支出）、期望搭乘的工具（判断出行）、天数（判断攻略）等内容；最后，根据已有的信息和分析结论，输出产品方案。本例子的用户方案为：

（1）用户期望及基本信息

广州白云区住户，首次出发上海家庭游，两个大人一个老人和一个6岁小孩，预算较高，期望轻松舒适出行，三天两夜。

（2）出发前准备

确认出发时间。原定于2024年1月10日出发，但由于当天整体气温较低，最低气温接近零下，因此延迟一天出发，1月11日出发，11日至13日皆为晴天，最高温度均超过10°，适应出行。

确认交通工具。预算充足，老人无身体明显不适，住所靠近白云机场，因此选择飞机作为广州到上海的交通工具。由于距离机场较近，因此选择10:00~10:30出发并且有餐食的飞机，飞行途中解决午餐。因为浦东机场地方较大，家庭出行不方便，因此落地考虑虹桥国际机场。

确认行程框架。抵达上海机场的时间预计是中午时间，行程时间为下午+晚上，考虑舟车劳顿，因此住宿和晚餐安排在南京路步行街附近，第一天游玩步行街、外滩、黄浦江和东方明珠。考虑到有小孩，第二天安排游玩上海迪士尼乐园，一早出发，游玩至下午或者晚上回到市区吃晚饭，考虑到一家出行携带行李不方便，因此住宿地不变。考虑到老人对古代建筑风格感兴趣，因此第三天安排游玩城隍庙、豫园、孙中山故居纪念馆和田子坊，上午在住宿地自由休息，下午出发并解决晚饭，住宿地不变。第四天上午飞机返程。结合上述框架，提前预定酒店和购买门票，酒店最好是预定家庭套房或者民宿。此外，长距离出行主要交通工具为打商务车，预算特别充足时可以考虑包车，短距离出行主要搭乘地铁（提前下载大都会app）。

确认携带物品。证件：身份证在多个地方都会用到，因此可以备一个卡包，统一由一个人保管；衣物：早晚温差大，因此除了需要贴身保暖的衣物之外，也可以带一些方便穿戴的大衣等；电器：充电器、充电宝、耳机等；洗漱：一次性用品、身体乳、面膜、护肤品等；药物：肠胃药、感冒药等；其他：保温杯、纸巾、湿巾、少量现金等。

（3）旅行途中

乘机。提前预约打车并提前1个半小时到达广州白云机场。到达机场后办理值机，因为行李较多较大，因此需要去所属航空公司的人工柜台办理托运。另外，手机、电脑、充电宝等含有电池的电子产品，要随身携带，不能办理托运，并且建议放置在方便拿出来检查的地方。安检时提前准备好身份证，安检后到达登机口等待登机即可。此外，老人和小孩若是首次搭乘飞机，可能会对飞机起飞或降落时高空压力产生的耳鸣感到不适，可以提前告知并采取方式（如打哈欠）调节。

到达。根据指示前往行李转盘拿取行李，前往打车出口准备打车前往酒店办理入住。

游玩。简单歇息后，开启上海游玩之旅。根据出发前制定的行程计划，按计划游玩，每个计划都会有具体的游玩方案，由于本次例子主要叙述广州到达上海的方案，因此游玩方案在此不再详细叙述。

（4）方案总结

做旅游攻略和做产品设计的思维和方法是想通的，基于已有的调研信息，梳理框架、流程、角色等内容，论证和分析需求可实现性和逻辑细节，最后输出产品方案（旅游攻略），完成原型设计（家庭游玩）。

设计之前“多想一步”，是最可靠的方式和选择。

此外，做旅游攻略时，通常会参考已有的成熟攻略，常见的查攻略app比如马蜂窝、小红书、抖音等，采用关键词（地名+时间+辅助词+攻略）的方式搜索相关攻略，比如上海三天两夜亲子游攻略。

产品设计同理，可以参考市面上的成熟产品，即竞品分析。不过，由于政务产品具有非常明显的定制性和一定的非公开性，所以大多数非面向公众的政务产品不会在互联网中公开，参考也会有一定的局限性。当然，参考也不是仅限于政务方向的产品，毕竟产品之间具备通性，可以借鉴设计的思路，理解产品设计背后的思维和逻辑。最重要的，借鉴产品时，切忌唯功能论，忽略核心需求，忽视功能是否符合用户的价值以及是否满足当前产品的发展阶段。

3. 需求交付

实施交付前，需要规划一个版本。

规划版本，一是明确本次版本的目的，即为什么在当前的时间点使用资源实施交付；二是明确本次版本的范围，即本次版本具体需要用资源实现哪些内容，有何影响？三是明确本次版本的时间周期和重要性，即在什么时间范围内需要完成本次版本以及该版本对于里程碑的重要性。

版本规划中，应该包含如下内容：

版本号。主要由主版本号、次版本号、修订版本号组成，分别代表版本的更新范围，如修订版本号主要是用于问题修复或者功能优化时，次版本号主要是用于小功能的新增，主版本号主要是用于大功能的新增或者原有功能的重构等。另外，部分版本号还包含版本所处的阶段，如测试阶段、预发布阶段等。

需求清单。也称为功能清单，罗列本次版本的所有功能点，包括但不限于功能模块、功能描述、功能类型、优先级、负责人等信息。此外，为了提高清单的阅读性，部分项目会要求在功能清单中加入需求背景（需求价值）的说明，以便于统一各方对于需求的理解。

需求评审。通常分为需求内部评审和需求交付评审，内部评审主要是产品团队之间的内部评审，由本次版本负责人讲解需求，评审人员关注需求的合理性、逻辑性、完整性以及设计细节，最终给出评审结果，不通过时需要二次内审；需求交付评审主要是交付团队之间的外部评审，由项目经理主持，版本负责人主讲，在会议中讲述本次会议的背景、目的、主要内容（清单）、设计方案、版本风险、版本周期等，确认每个模块对应的负责人以及预计完成时间。此外，需求评审开始前要做好准备工作，如预约会议室、通知相关人、发送相关资料、和研发确认技术实现性；会议中要注意控场，尽量避免会议中讨论过多且发散的设计细节，可以留会后单独讨论完善，及时记录待办事项和问题；会后做好会议纪要，做好需求交接工作。

研发跟进。正式进入研发阶段，测试团队同步进行测试用例的编写工作。研发开始前，针对复杂、大型的需求，技术团队需要输出设计方案，并且邀约相关人员进行需求反讲，这是为了保障需求理解的一致性，避免实际研发出现偏差。研发过程中，产品团队不仅需要关注研发和测试老师提出的需求问题，还需要关注研发测试的依赖项以及风险点，定期了解和评估研发进度，及时和各团队同步需求变更项，尽量避免口头传达，记录好每次的改动，包含但不限于变更的范围、变更的原因、变更源头等。

功能测试。正式进入测试阶段，测试团队按照评审通过后的测试用例开始测试工作。在此过程中，测试团队提出缺陷，研发团队及时关注缺陷并修复，产品团队关注需求疑问项以及着手准备下一个版本的规划。同样的，若出现需求变更，也应及时记录并且知会相关人员。测试通过后，测试团队输出测试报告，产品团队同步功能验证。

预发布上线。上线前，组织召开发布评审会议，同步本次的版本部署内容以及检查各方的版本验收工作和交付材料是否到位，确认本次版本的上线时间以及支撑工作。评审通过后，提交发版流程，根据既定的部署时间执行发版，相关人员随时待命。部署成功，开始执行验证工作，并邮件或者其他途径同步上线结果。部署失败，需要执行版本回滚，回归验证。另外，政务项目中，上线前需要进行安全测评，比如漏洞扫描、渗透测试等，出示安全测评报告（无中高危问题）。

生产上线。和预发布上线类似，上线前需要召开发布评审会议，评审通过后方可执行发版。和预发布不同的是，生产环境的验证工作要尤为谨慎，特别是涉及数据的增删改查，要有相应的恢复方案，否则不轻易调整生产环境的数据。

以上过程，除了项目经理之外，产品经理是最重要的推动人，一定要有非常强烈的主动性，主动协调好所有相关事项，这个是政务项目成功的一个重要因素。

标准的流程是保障质量的一种手段。当然，标准并非一成不变，没有最好的标准，只有最合适的方法。因此，实际的需求交付过程中，根据版本的大小、范围、紧急性等特性动态调整，以质量和效率为核心，协同向最终目标出发，通力完成版本的上线。