对待需求，始终保持一种中庸之道，既然听，也不要全听。如果全不听客户的意见，远离客户，会被市场所淘汰；如果全听客户的意见，搞出来四不像的产品。网上有一张很形象的图说明问题，如果iphoe听了所有客户意见，搞出来的产品应该是如下样子。

     以下谈一下个人经验，判断一个需求要不要做，主要从3个维度进行衡量，合理性、实现代价、确认需求责任主体。哪个需求要优先做，采用帕雷托法则（二八定律）用于根本原因分析，抓住20%需求，优先实现。

     极少部分管理者存在一种幻念，实现所有的需求，解决所有的问题，追求100％用户满意度，分不清楚主次矛盾。比如，对于不能复现的偶发性问题花费大把时间查找原因。又比如在那种无关紧要的简单问题上面花很多时间。

     在资源有限和项目周期刚性条件约束下，让工程师把时间聚焦在关键问题上是管理者的责任。

一、需求的合理性

    在需求合理上，你总会听到七嘴八舌的声音。我说合理，你说不合理；我说在合同之内，你说不在合同之内；我实现简单，你说很难实现；......。

    需求的合理性实质是利益相关者博弈的结果。举例说明，有一次我去内科去了解预约挂号需求，医生跟我讲要实现挂号不指定医生，直接挂到科室即可，患者实际来到科室再分配一个医生就诊。

    第一次博弈：我解释不建议按照原有的模式做，第一个原因，医保的要求挂号必须要指定医生；第二个原因：违反预约的初衷，预约的目的就提早规划好医疗资源，应该做好科室管理，适用这种新的管理模式。

    第二次博弈：小伙子，你不要讲那么多，旧系统能实现，新系统也应该能实现，我打开旧系统给你看，你就按这个思路实现即可。

    在用户认知当中换系统就是认为旧系统的延伸。而人性的弱点是不愿意改变，喜欢维持现状。人性的弱点不能被说服，一个人不在乎另一个人讲的多有道理，而是此时此刻对方是否能听的进去。

   上述对话，之所以用户听不进去，对我的专业性理解定位“冯师傅”，而不是“冯工程师”、“冯专家”。少数管理者在这件事情上表现为“猪一样的队友”。为什么我过去讲，用户就听明白，你们就不行，然后对工程师一顿pua，你看你表达是不是有问题？他不知道他此时的身份是“冯工程师”、“冯专家”，而不是“冯师傅”，对方能听得进去。

   第三次博弈：我说你们这个需求，先提交给门诊办，他们签字同意即可。我再提交需求给产品经理审批，再提交给开发工程师。

    如果按照旧的方式修改，还要有与产品理第四次博弈，与研发工程师第五次博弈。可能中间还要开几次会才能定下来。

二、合理需求的实现代价、责任主体

     有些需求确实很合理，但是实现代价很大，需要跟客户做好解释工作，探寻代替换的解决方案。

      需求合理，实现代价适中，还要确认责任主体。举例说明，有一次我去参加体检团检收费问题，经过一个小时的激烈讨论以后，大家一致认为合适的解决方案，在HIS系统增加一个虚拟的收费项目（1元）来解决问题。

      最后我向大家抛出了一个问题，这个问题最后谁来签字确认，是物价办还是财务科，还是其他人？现场顿时宁静片刻，某某某就开始说，要不然你找领导反馈一下？某某某又说你也要找你领导反馈一下，最后再定夺。

附codes简介