在初次接触政务类产品的时候，项目经理直接扔出一堆下载的国家文件，告诉我可以先把需求功能写出来做好demo然后去见用户，去了解他们的看法。我起初是不解的，为什么不是先去和目标用户访谈，了解他们想要什么，再去做功能和功能确认？而要做这些即将重复返工的事？

      在这之前先来聊一聊我以前的B端行业经验，B端产品是为企业降本增效的，大部分用户已有使用这类软件的经验，功能产生绝大部分一定是先有较明确的用户需求，提出用户需求后，产品经理根据用户的需求进行产品的目标确定、需求的调研、需求的梳理，根据自己对行业痛点的理解，用户痛点的分析，去加入一小部分特色功能需求，把客户需求转化成具体的产品功能需求，这样既能够保证产品的行业通用型，还能帮助用户通过使用系统实现企业降本增效的目的。

     后来的经历打消了我的不解。经历过政务产品的小伙伴一定知道收集需求的过程有多艰难，在我经历过各种磨难后，我想复盘关于政务类产品需求产出的思考，如下。

     政务类信息化产品大部分是满足政策上指导的信息化要求，国家统建或者地方自建的。因此和我们接触的决策者虽然很清晰政策，但是可能对信息化功能怎么实现目标不太清楚，虽然使用过系统但几乎只关心数据的监督和展示，很难问出实际有效的的信息，如果要调研基层使用者用户需要领导发文或者提前通知，不然无法执行。因此前期只能通过成型的demo演示进行场景演练，决策者们才知道什么功能是他们需要或者是还存在问题需要优化的，确定demo后才会发文或通知基层配合调研。

    下面是我总结的政务类产品的特点，主要从用户类型、需求来源、需求类型三个角度来说。

    一、 用户类型

    用户分类两大类，一类是决策层用户、一类是使用层用户。决策层用户通常是领导或者监督者，使用层用户通常是窗口的操作人员，基层的工作者。

     二、需求来源

     1.政策文件，政务类产品的大部分需求来源于国家或地方发布的政策，根据政策建设或完善信息化系统，这里可以从国家政务网下载相关资料，例如：如果我是做医疗机构管理的信息化产品，我就会去政务网下载医疗机构管理相关的最新政策，根据最新政策的整理相关的政策需求。

     2.用户需求，通过用户访谈的方式获取，大部分用户刚开始往往没有具象化的需求，需要通过流程模拟的方式获取用户的意见和产品需求。

     三、需求类型

    1.决策层需求，报表需求为主，去了解决策层用户的工作就知道，除了通过统计了解当地的数据情况，他们每月、每季度、每年还需要上报的各种类型的报表，而他们汇总一个需要上报的报表通常需要找好几个系统相关的负责人，发文、沟通才能获取到想要的数据，系统多、搜集难、数据多源、统计难度大是他们最头痛的问题，如果能做好系统报表功能，对他们来说省了很大一部分精力。

    2.使用层需求，业务办理流程和系统交互为主，使用层是实际的高频系统业务信息操作人，基层的使用人日常工作其实已经比较繁重了，在他们看来新系统未来可能是沉重的工作负担，是比较排斥的，不一定会很配合，但是可以通过描述系统能给他们带来的好处，耐心相处，获取实际业务场景相关的需求。

     最后来说下政务类产品需求梳理的流程，主要流程为：政策文件解读-demo演示-决策层用户调研-使用层用户需求调研-需求输出-需求细化。

     一、政策文件解读

      知己知彼百战不殆，首次和决策层见面演示特别重要，决定了他们对你专业度的认可，对目标产品相关的政策进行分析解读，不仅可以分析大致的产品轮廓，还可以通过深入的了解减少和决策层用户的交流屏障。比如用户提起：医疗执业许可证的编码规则、医疗机构违规的监督和惩治方式等，我们完全不了解，这会给用户很差的印象，降低信任感。

     二、demo演示

      政策文件解读完成后大致对产品的形态有一个大概的轮廓，下一步是去验证自己的想法，根据行业产品和政策文件提到的要点整理一个功能表单和演示demo。在和决策者进行demo演示的时候注意要从用户的角度去拆分使用场景，挑重点去讲解需求切的哪些政策要点，怎么能实现更好的完成工作任务。演示完毕后决策者一定会有不同的意见或者想法可以交流，帮助我们完善功能需求表。

    三、使用层用户需求调研

     曾经有次前往领导沟通好的调研场所，刚刚到达，就被通知调研对象临时有公事离开最近都不在。所以建议对使用层用户的需求调研，需要提前沟通准备好访谈大纲，有条件的情况下尽量能够和一位决策层用户一同前往，保障访谈的过程正式性和顺利进行。

    同使用层的用户进行需求调研通常使用访谈的方式，时间不要超过1小时，按照使用者日常的业务处理流程演示demo,并进行反馈和记录，进一步的完善功能表。

    四、需求输出

     在获取完两大类用户的需求后，需要结合政策文件进行需求的整合，把符合政策的需求纳入、不符合政策的需求剔除，把合理化的需求纳入，把特色化的需求进行梳理，这里是一个需求整合过程，过程输出一份较为完成度较高的需求功能清单和业务流程图。这个时候可以开始进行产品需求输出，进入产品开发工作阶段了。

    五、需求细化

      政务类铺开覆盖的面积大，且产品的好坏可能会影响到决策者单位的公信力，遭到基层人员的投诉，因此会有试点区域对系统进行两个月到两年的定期的试点，在这个试点实施过程中会有很多试点地区、实施人员提出的相关实际场景或者特殊场景需求，比如：正常医疗机构补助发放是按照地区补助标准发放，但是部分机构因为在标准建立前已经进行进行补助发放，无法按照规定录入系统。这个期间我们就是不断的搜集实施现场需求，并且对产品需求进行细化和认真打磨。

     以上是我对政务类信息化产品的思考，希望后期能在行业上进行更深入的理解，各位同行共勉。

    End-