无线产品运营之：小议产品经理基本功

From: http://luzheng.blog.techweb.com.cn/archives/88.html

 

产品经理，作为一个衔接公司战略到具体实现的重要位置，通常要求具有多方面的素质。但是拥有全面素质的产品经理是可遇不可求的，我们不妨学习一下KPI管理的一些思路，将其核心价值提炼出来，归纳出最核心的一些基本素质。

在我看来，成为一个合格的产品经理，必须要重视三个方面的能力：

1，文档的规范能力；
2，项目管理能力；
3，跨部门沟通协作能力。

第一，文档规范能力。

要说文档写作，是产品经理的家常便饭，如果连这个都做不好，难免说不过去。但是文档，却偏偏是最好上手，最难精通的，浓缩着产品经理对于项目的理解与规划，一份具有前瞻性、逻辑性、延续性的文档，写出来实属不易。

文档写作，是一门大学没教过，注重积累的工作。要展开去说，怕是写几篇文章也说不完。我的朋友龙拓互动的狒狒同学可以说是一个文档方面的专家，大家可以从我的博客友链中摸索过去，细致了解。而我在这里，只提几个重点。

首先，是产品目的。通常很多写文档的人虽然开头会有这个部分，却常常省略或者应付了事。其实一个产品的目的，是最好的定位工具，也是在文档整体写作中，永远牢记于心的东西。是创新性突破，还是延续性增强，又或是配合整体战略需要对其他产品线予以补充？没有目的性的航船，走不出一个好方向。

然后，是产品的整体设计，也就是通常所说的sitemap，big picture。整体设计我认为又有三个重点：1，外展，套用物理学原理，将本文档设计作为一个点来看，确定它和其他文档的相互隶属关联性，以及相关产品线的互相影响性。一个变量引入，必然会对全局产生蝴蝶效应，除了应尽量遵循既有体系的产品设计原则，也需要在适当突破时，做明确约束说明，以利于相关产品线相应调整。2，是内扩，将本文档从一个点放大成为一个面甚至一个体，必然会发现本文档涉及的产品，有多个主干旁支：理清并标注明确。这样有助于你避免以后具体需求撰写的层级失误，并且能更好的把握体系内各节点的关联性与协同性。3，我们还要引进时间维度，将本文档的产品规划定义在产品发展的一个具体里程点上。这样，一个产品全局设计清晰，其未来的推进与衍生，就更为立体的展现在我们面前。

再后，是产品的具体设计。具体设计讲究的是层级分明。特别是在产品纵深非常多的时候，良好的结构是可读性的关键。为了量化产品的具体设计，我通常建议产品人员在具体设计需求的时候，进行简单的数据表结构设计。通过表结构设计，能够更好锻炼逻辑思维，同时也是对自身产品需求的一种反向检验。当你发现根据自己的需求而制定的数据表凌乱庞杂，很多需求频繁的跨表操作，那么从新审视一下需求就非常有必要了。

再再后，是业务流程与页面流程，分别是抽象化和具象化的业务进程描述。细谈又会很多，简单说，重点是清晰与细致。一个良好的流程设计，对产品文档的理解是非常重要的，是否通过流程设计图就能反馈出你的文档全貌，是检验流程设计好坏的重要标准。

最后一个要提的，是性能要求。性能要求虽然落笔简单，但是却是一个产品规模和运营成本的重要考量。支持用户量的多少，并发请求的响应速度等等，不可不慎重对待。

通过以上的简单描述其实可以发现，我在文档写作中很关注技术环节的内容。在很多公司，数据表设计、性能要求，都是拆到研发体系去进行的。但即使如此，这部分的内容仍然最好能在文档中体现，因为这是产品实现的程度和未来扩展性的关键。放弃掉对数据表和性能的要求，意味着文档需求再完善，也只能保证此阶段产品的实现。而一旦配合的研发人员并不是一个勤于思考的人，或者是即使勤于思考但是开发时间压力很大的研发同学，很可能意味着产品下一阶段升级、扩展的力不从心乃至需要推倒从来。相信每个产品经理，工作时间长了，总会有机会面临给这样的产品擦屁股的经历，为了自己或者其他接手人能够顺利的将产品演进下去，不再擦屁股，请做好技术环节的控制工作。不懂，可以问，可以与研发人员一起交流讨论，向其强调产品的纵深，学习并逐步培养自己的技术具体实现环节的敏感度。

产品文档，必须对产品编码、数据库搭建、服务器配置和运维需要，做到良好的预规范和限制，并为未来的测试工作，提供必要而细致的支持。而这种文档操作方式，也是下两个基本功实现的前提。
第二，项目管理能力

项目管理能力，是产品人员应该具备的一个素质。因为通常很少有公司会专门有流程管理人员，通常需要产品或者研发人员兼任。产品人员兼任的好处在于，因为了解产品内部的优先级，可以有效的对项目调整做出正确的判断，而研发人员担任流程管理，通常不敢砍掉任何功能，只好采用一些不完善的方式暂时替代性实现某功能，或者直接项目延期。如果产品不介入，哪些功能被稀泥和上了不知道，未来可能出现非常致命的问题。因此，即使所在公司是研发主导项目管理环节，产品人员也切不可甩手不理会，放弃了一个重要能力培养的机会。至少，旁听并思考项目进展合理性，是必要的。

项目管理的关键点很多，足可以开一个专门的培训课程讲上一个礼拜。这里也只挑两个重点。

1，是时间点的细化。对项目的进程管理，必须要将产品需求细致拆分，将每个小功能模块的工时算清楚。这个时候就体现出产品文档结构清晰的好处了，可以很快的理清楚小功能点的具体实现难度，并且理顺优先级和先后关系，实现项目的最优实现路线。

时间点明确后，可以进一步配合测试人员约定好代码测试和黑盒白盒测试的时间点。至少在黑盒测试阶段，产品人员应该积极参与。

2，是处理项目的突发事件。在中国公司里面，项目突发事件发生几率是很大的。比如临时某环节人员被抽调其他项目，以高层为首提出临时的需求变更，为配合市场战略而不得不提前的deadline等等。这个时候，单纯抓狂是没有用处的，对项目各流程的弹性是否留足，以对未来开发测试时间周期可能事件的预判；以及是否在产品规划时期，就已经考虑到非常状态下的功能模块取舍，都是项目进展稳定性的关键。非必要时刻，造成全项目组加班加点日夜鏖战是相当罪过的。当然，某些公司的领导，刻意制造这种必须加班的项目日程，冠以锻炼队伍、强化凝聚力的大标语的情况，超出项目调配的范畴之外。除此之外，一些正常的项目突发事件，如何理顺，不仅仅是项目实现的问题，更是让整个项目组成员不至于疲于奔命的关键，也是塑造自身领导力和被团队信赖的关键。

第三，跨部门协调沟通能力。

其实通过前面两点的叙述，就已经看到了大量的跨部门协调与沟通工作。因此，如果产品人员前两点较为用功，这第三点是一个顺理成章的事情，无需特别说明。

在我过往的工作经历中，很多时候产品团队会把相邻部门人员的满意度，作为一个产品经理的考核目标，并且比重不低。这其实就是在提醒产品经理，作为一个衔接职位，一不是最初战略的发起者而是贯彻者，二不是最终的实现者而是协调者，其实对于自身而言，一个产品项目能否顺利进行，很多时候已经超出了自身能力的控制范围。这个时候，如何学会调动相邻部门的积极性，让其中的同事认可你、配合你，乃至于相互督促互相提高，是最终目标实现的重要潜在条件。

人际关系管理，是一个更庞大的话题，今天也同样不可能展开了。就多说一句，想要其他人支持你满意你，最重要的是学会利他，学会站在对方的立场思考问题，将心比心，而不仅仅是就事论事。

限于篇幅，今天谈的内容只能浅尝辄止，抛出一些观点。希望到访的同行朋友也能够多提宝贵意见：有自己认为更应该成为产品人员的核心能力的能力，欢迎加以说明；或者就我提到的核心能力觉得我理解的有偏差的地方，也欢迎提出指正。大家共同交流以提高发展，才是最终目的。