无论是身为运营，还是身为产品经理，在工作中要善于总结，这样才能使得个人技能和自身能力快速提升。
接手公司运营后台的产品工作快1年时间了，忙忙碌碌一整年，踩过许多的坑，我希望把这些经验总结分享给大家。
做b端业务和平台业务不久，主要由于从客户端及c端跳转过来，刚开始也有一些不习惯，但其实对产品经理的能力和要求都是共通的，这些经验也算是抛砖引玉，供大家讨论指导。
先简单介绍一下业务背景：
公司主要业务为资讯和广告，属于b端，但有c端的一些特性；产品形态多样，导致需求多样；产品不太设计审批流程、支付流程，主要为数据的读、写、用；功能主要对内使用，部分功能对客户开放；主要使用方为运营、产品、审核人员，需求方也多为这三个部分。下面就开始正文：
一、需求方、使用方及业务上游、下游的需清晰
其实，对内的平台产品（以下就以这个名字称呼）承担着一个产品系统中“交通枢纽”的作用。
有时候系统的设定是反人类的，但是平台的操作人员又是感性的、直接的。
在这个时候，平台需要作出一定的权衡和适应，既能满足人、又能满足机器。这就要求我们对需求要有明确、完整的理解：有的时候，需求方和使用方往往不是同一方。
比如说系统产品要做一个配置，没有这个配置，系统无法升级迭代，但是使用这个配置的人往往是运营，运营根据实际情况来考虑是否需要配置。
这个时候就需要拉个会，把利益方叫在一起达成初步的共识。有的时候，数据存储需要和业务上下游交互，那么就需要和上下游一起商定存储细节。
二、对业务的了解程度，决定了平台设计的合理度
这一条其实是一个相对抽象的总结，但其实你越了解业务，对自身工作越有好处。
系统产品提了一个需求：需要一个配置，这个配置是用来控制某个模块中的某个部分功能是否对用户开放，那么就需要在操作系统上做一个可配置的页面，根据人员的操作，对系统进行可配置化管理。
这样说起来像是一个不需要动脑的需求，但实际上你其实全方位多角度的考虑这个配置的情况，比如：（括号中为思考树的枝叶，可以不看）
配置生效的位置，比如说配置项分别是作用于系统哪个部分，会对哪些数据造成影响。配置储存的要求（是否对配置有时间要求？若有，存储在哪里可以满足；若无，是否设定缓存时间的阈值）。配置要求，比如说在无配置的情况下，系统是否有默认值（如果有，平台无需定义，如果无，则平台是否需要配置默认值）？使用方是谁，在页面上有权限方面的控制（配置修改是否需要审批）。其他：对什么指标有提升，涉及到的部门有哪些，需求的合理性是否已经被认可（以防止需求做完之后，需要再次返工，或者撤销需求）。这样看起来是不是很繁杂？你可能会问，一个小功能至于么，给他们做了就得了。
其实不然，因为平台是系统和用户的连接点，系统的修改（无论开发侧还是运营侧）很可能直接影响了用户的使用效果、体验，最后体现到数据上。
有时候需求方（由于没有你有经验、看的广）可能根本不了解这个配置对业务会有什么影响，这也是做这个需求的风险点，需要告知需求方再做定夺。
三、数据库的设计很重要
虽然说产品经理不需要“特别”懂技术，但作为运营平台的产品，数据库的基本知识需要具备一些，以下是我在未系统学习过mysql的情况下，仅通过工作学习到的一些常用经验了解数据存储的基本知识，比如说不只是有mysql这种数据库；了解不同数据库的存取逻辑。
自己会查数据库、导数据，如果不会写语句，就用界面操作的傻瓜也没问题，可以应付日常工作所需。有时候帮运营定位问题、导数据，可以给开发争取更多的时间完成项目，利人利己。做需求的时候，可以尝试给定义表结构、数据情况（当然，也需要充分和开发沟通业务，讨论设计是否合理、可扩展性如何对数据库表的写入方、使用方了如指掌，这样一旦出bug了可以迅速定位问题给其他部门提需求的时候，可以替着自己设计的数据表去，不需要再交给开发和开发沟通：）（自豪）
四、在做需求的时候，尽可能地为自己争取主动权
其实对于公司、用户、业务来说，对内平台就是一个工具、操作手段，许多设计都受制于业务，主要是业务上游的规则。这个上游，狭义来说指的是业务流程中的上游。
多掌握一些信息，比如上游系统的设计理由、局限，了解上游业务的设计模式，从而“配合”其设计进行自己的产品设计。
广义来说，上游可能是来自客户、客户端产品、系统、业务……
一切需要使用平台的人，掌握多方的需求动因，才能让你在设计平台时，可能会给你的工作带来一些更高效的因子，给出更符合需求目的作品。
本文由
swiiiiii原创发布于人人都是产品经理。未经许可，禁止转载。题图来自Unsplash，基于CC0协议