以原则为中心的产品经理二将正确的事推动

　　如果说产品经理的职责是将用户体验做到极致，不知有多少人会同意，反正我是不同意的。
　　以原则为中心的产品经理（一）：做什么大于怎么做出了后，我想了好久都找不到接下来的主题。有一段时间我想写从用户场景出发，脑图大纲都出好了，准备动笔之际，最近的一个项目却再次暴露了自己经验的不足项目没有按时上线。
　　方案出的倒是准时准点，但中途因为各种意外状况，比如人员请假，高优先级的需求插入等等，项目排期整整延后了半个月。方案没拖，听起来好像没我啥事，但这其实就是我在事前计划及事中跟进时缺乏经验的表现。
　　我的计划里没有缓冲、没有对平台近期紧急需求的预测，人员排期里没有并行而用的是瀑布式开发，需求优先级降低时我没有及时调动空闲资源。我有一万种方法可以让工期跟上进度，可我却傻傻的坐在原位感叹无能为力。
　　我费了多少心思在用户场景里啊，可是项目到现在都还没上线呢。要知道有些需求一旦延后，效果将大打折扣。
　　当然我并不是认为用户体验不重要，但确确实实，产品经理不是对用户负责的，他同时对用户、公司和实现负责。产品经理想的应该是如何将正确的事推动。
　　正确的事：
　　德鲁克老先生关于做正确的事情有一段经典论述：效率是以正确的方式做事，而效能则是做正确的事。效率和效能不应偏废，但这并不意味着效率和效能具有同样的重要性。我们当然希望同时提高效率和效能，但在效率与效能无法兼得时，我们首先应着眼于效能，然后再设法提高效率。
　　那现在的问题是，对产品来说，什么是正确的事，什么是有效能的事。
　　注重用户体验对产品来说是一件正确的事，但我们仔细想想，提高用户体验的目的是什么？？归根究底其实还是希望用户能够购买产品，只不过我们通过提升体验，从更长远的角度来提升盈利的机会。
　　如果一个产品用户体验优秀，但是商业模式不清晰以至于预期内都无法盈利，我会认为这是个失败的产品。但是我佩服他们以用户为导向的价值观。
　　答案在我心里越发清晰，产品所谓正确的事是平衡，是在努力考量过用户体验、商业盈利和技术实现后，找到一个最佳的可实行方案能将三者的价值都最大化。
　　剩下的就是，如何推动。
　　将事情推动：
　　推动是一件很难的事，能把事情推动直至推成并不是靠执行就能完成的。都说产品经理没有实权，是的，产品推动人靠的不是职务或者排期，靠的是影响力。
　　这里不得不说一句，产品经理是一个很辛苦的职位。虽说工作在于奖惩清晰、职责分明，但作为一个有影响力的产品，可能压根没有职责的区分。需求文档提交后，开发没有看没有重视，这是开发的问题，但更多的是产品经理的失职，你为什么没有想办法让他重视起这个需求，如果他不重视，是不是你的方案本身就没有传递出有意义的价值？
　　回想起自己在开发评审时的状态，我像一个战士一样回击每一个质疑，这不是推动事情时该有的心态和行为啊。我给自己定了个规矩，开发评审时，理性的评判每一个质疑，以寻求更好的解决方案为目标。其实再仔细想想，开会更多是一种形式，达成共识的大部分精力和机会应该是在会前完成的。早应该在开会之前，我们就需要面对面的和开发进行沟通取得共识。
　　推动还可以从文档下手，出方案是一回事，让开发明白是另外一回事。我们出的文档当然越简单越好，但更重要的是，符合开发的思维习惯。我曾经想用一个文档贯穿到设计、标注、后端和前端的所有过程，但发现技术和设计的思维是不同的，设计喜欢看列举好的页面，他们的思维是穷举。技术喜欢看归整好的页面，希望知道哪些页面可以复用，他们的思维是逻辑流程和归纳。产品经理是有义务为需求文档整理出更好的展现形式的，方便了开发，人家心情一好，工期不就赶上来了嘛。
　　我在一开始思考方案时，会屏蔽掉技术实现，完全从用户角度出发，实现的问题可以之后再和技术讨论，这样产品坚持自己观点时也是有用户场景作为支撑的。但其实再仔细想想，在构思方案时，是不是也能在不影响用户体验的基础上，想一些能方便开发实现的方案。比如关于接口的请求，在页面顺序设计上，我们可以尽可能减少接口请求的次数，而把返回的结果集中到一个页面。
　　不能否认有些开发对不懂技术的产品是存在赤裸裸的排斥的，这时我想借用下别人文章的描述（引用自：产品经理最重要的能力）：
　　工程师不理解需求，我们不论是画图、写文档、做原型还是直接表演给他们看，一定要弄到他们理解需求为止；合作伙伴不配合，我们不论是威逼还是利诱，拍桌子红脸还是跪在地下磕响头，一定要弄到他们配合为止；老板不支持，那我们就用最小的代价和完整的逻辑证明你的观点，说服他，没日没夜地说服他，厕所里堵住他说服他，电梯里拖住他说服他，满地打滚，以头抢地，把刀架在自己脖子上说服他；自己团队的同事解决不了的技术或者业务问题，不论是买书自学还是彻夜查资料还是找到其他行业大牛在他楼下跪一夜，一直到想办法找到解决方案为止。
　　推动的另一个难点在于和上级和老板的沟通，我们经常会抱怨老板总是突发奇想的插入新需求，但好的产品经理会在优先级上和老板达成共识（观点来自，戴雨森，好的产品经理糟糕的产品经理）。和老板有了共识，调动其它部门的资源也会更加容易。