产品经理如何炼成（一）- 需求理解
近期我们邀请到物流行业的资深产品经理兼项目经理Sam，他给大家做一个产品经理系列的讲解。本期涉及的内容为产品经理的根基：需求理解。
“产品经理没说要做这个"，“产品经理就是这么说的”，"原型上没写”，“原型上就是这样的”，当测试遇上了开发，很多时候办公室会有这样的声音。
产品经理自然而然的被推到了风口浪尖，产品设计的好，皆大欢喜，产品设计的有问题，一切矛头都指向了产品经理。
更有甚者，前一段时间爆出了开发人员不满产品经理要求的根据手机壳改变手机背景颜色的设计而与之大打出手的著名事件。
为什么会这样，产品经理真的是在用生命去设计自己的产品吗？今天我们就来谈谈作为产品经理如何在工作中应对各种各样的客户需求和各种没法做做不了的开发，真正做到产品原型设计和实现能够尽可能的一致。
从产品设计的角度来分析，可以把产品分类成不同的干系人影响：
- 客户的需求
- 用户的声音
- 同行的批判和竞品
- 内部领导的挑战
- 开发的“刁难”
- 其他各方的声音
今天首先从外部客户和用户的角度去分析一下产品人应该如何应对外部环境的挑战，从中寻找自己的机遇。
第一步，了解客户需求知道客户真正想要的是什么
或许大家会呵呵一笑，鄙视也油然而生，这个谁不知道，还用你说吗。
看似简单的一句话其实却暗藏着很深的学问。从一则流传很久的心灵鸡汤的故事来看这个问题：
几乎同时入职的小李和小王，一开始进入公司的角色都是文员，干一些琐碎的小事，但是之后的发展却大相径庭。
小王用了短短一年就从给人端茶倒水的角色变成了公司某个部门的负责人，而小李还是重复着入职以来的琐碎小事。始终无法获取老板重用的小李终于安耐不住自己的傲气找到老板。
老板呵呵一笑，说：你打电话询问一下下周过来的客户周几到，这件事情办好我自然会给你满意答复。
小李心想这不是小事一桩，于是电话给客户询问了相关事宜。
在给老板答复他们周三到之后，老板笑而不语的叫来了小王。在两人短暂的等待后，小王的汇报如下：
- 对方三个人是由总经理亲自带队周三下午3点的航班
- 我和他们沟通好了会派车去接待，酒店也按照咱们的接待标准订好
- 考虑到航班时间，我也安排了晚宴，若您如果没时间可以安排徐总。
听完这个故事，小李应该能找到为什么小王会升职，自己却一直原地踏步的原因了。
或许有朋友吐槽这个故事编的逻辑太差，语气生硬。Anyway，我们今天讨论的重点不是故事的好坏，而是对于需求的理解。
作为一名出色的产品经理，我们需要考虑的客户需求：
不仅仅是客户的需要，还要考虑需求的原因，诉求引起的问题。了解的情况越多、掌握的信息越全面，越有利于如何把诉求整理清晰。
需求调研可以采用访谈、问卷、会议等多种形式，这些都可以作为需求了解的手段进行需求收集。
了解需求不仅仅是客户说出的东西，还需要有举一反三的思维。
再举个栗子：
老板让你去倒一杯水。
是头也不回直接前往茶水间吗？这样提供的水是老板想要的吗，是否还要思考一下老板需要的是热水还是冷水，老板有杯子吗，他是要蓄水吗？等等。
因此，了解需求不但要知其然更要知其所以然，充分和深入的理解才能在设计的时候充分考虑到是否满足需求。
一知半解的结果就可能是客户的需求实现了表面意思，但是用起来复杂或者开发实现难度加倍，客户的需求也许只要变通改变方式就能事倍功半的解决。
同时，不明确的需求也会存在返工或设计调整的尴尬局面，这也导致开发对产品经理的信任度降低。
另外，深刻了解客户的需求，需求的原因也会更好的帮助产品经理来设计系统框架。我曾经碰到一个典型的案例：
客户用习惯性叫法“驾驶员”的称谓让统计所有注册人员的信息，但是产品经理惯性思维的按照客户叫法仅仅统计了注册时有驾照的人员信息，却忽略了驾驶员可能没有在系统填写驾照内容，其他人员也会填写驾照内容的场景，导致开发在统计时工作量加倍还不准确。
其实，简单的明确客户需求，这个就是统计系统注册人员的信息，并不用过滤任何条件。通过这个简单的例子，也是想和大家分享，了解客户真正需求的重要性，千万不能“想当然”的主观判断。
第二步，在条件允许的情况下跟随客户观察他们的工作
从中进一步的了解工作流程，为产品流程设计打下基础。
这种方式适合行业了解不深，可以相对快速的接触体验客户工作方式，这也是接触用户的好机会，了解用户的期望。
当然，对于时间或是条件的限制，现场可能不会有“实习”的机会，于是在访谈、会议这种了解需求的场景下去梳理工作流程就变得至关重要了。
在此期间可以尽可能多的要求关键用户参与，需求的提供者不能只是客户的上层管理者，用户的参与也是至关重要的。同时获取客户的需求和用户的期望也是产品经理需要考量的。
对于需求方面，今天先谈到这里，后续我们会针对系统设计方面在进行探讨。
了解更多的职位数据信息，敬请关注微信公众号：乐伯职位分析 或者