产品经理的完美主义

一、追求完美应该是每个产品经理的标准

     只有心里有完美主义这个标杆，自己做产品设计的时候才不会轻易放低对自己和对方案的要求与标准，才会在有限的时间有限的资源内给出能力范围内的最优方案。既能在设计方案时考虑到用户使用场景、边界条件、多种状态、逻辑分支、交互流程、多系统关联影响等；也能在沟通推进项目时，降低沟通成本，不轻易妥协设计方案；也能在需求方案执行后，不随意改方案，干扰其他合作人员的工作；也能在项目上线后，遇到反馈时，不是立马紧急改方案，而是先确认并定位是否真的有问题需要紧急修复再做决定。

     要想做到以上这些，就得在问题出现前产品经理已经预先想到了并在方案里规避了。而预先想到这些，并尽量想全面，无疑要求产品经理对自身和对产品都有着极高的要求，不是得过且过者，不是糊弄型，而是思考全面型，负责型。完美主义大概可以简略概括这个标准。

     由于职能范围与权限不同，设计、技术、运营、测试同学可能了解的需求、业务背景、产品愿景与产品同学不对等，这样在沟通方案的时候，产品同学要为大家解释需求和方案，有时候还要面对犀利的质疑。而如果产品经理自己对这一切都没思考透彻，那何来娓娓道来的解释，据理力争的底气？

二、非完美主义带来的潜在问题

     早前在各处看到过以下聊天：From PM“这版方案（新版本基础架构）先这样做呗，大不了用户反馈了再改，不是可以试错嘛？！” From UI“移动端也像Web那样简单设计就好了呗？何必单独设计？” From RD“以前咱们都是那样做的，现在这样做跟以前不一样，这样没以前简单” FromQA “这个不改，下版本再改，我们只测功能，现在只改崩溃，适配跟体验都是小问题”From QA “业务执行崩溃不太好发现，比较稳妥的是在外网个别渠道先更新，有问题快速迭代，等待版本稳定后再全线更新”。当沟通推进项目的时候你若遇到这样的回答会如何做？

     基础架构啊，那可是基础架构！！！基础架构哪能这么随意改？信息架构不明确，展示深度是否合适，都会影响用户使用。而这类交互问题普通用户是发现不了的，他大多会感觉不好用，不好用就不用了呗，反正竞品做的还不错，谁又会反馈呢？那个时候怎么改？而且最为一个专业的PM，基础架构本是产品设计者对目标用户的表达体现，有引导作用，我们更应该在发布前已经反复论证过方案的可行性，而不是依靠发布后用户反馈来修改，不是吗？不然产品经理的价值何以体现？

    《精益创业》里面提倡科学试错、快速迭代。请别忽略了“科学”二字。试错可以，但别随意，也就是说有些错可以试，而有些不能试。在做一个增量需求的时候，我们对需求的把握对方案的设计大多是带有尝试性的，这时候可以快速将方案落实走向用户和市场，根据用户的反馈，迅速调整。而不是在做存量需求的时候，遇到举棋不定的需求方案时不去论证，不去做竞品分析，不去做围绕目标用户又适合自身产品的设计，不内测尽全力修复了bug就随意把方案抛向市场，交给用户去使用，期待用户的反馈。

     当一款产品有Web版、PC客户端、安卓端、IOS端、浏览器轻应用、微信公众号轻应用等的时候，产品设计就需要做差异化设计，依据平台自身的属性做针对性设计。Web大屏可以做的设计，在移动端很多就不适用，移动端屏小，而且使用场景也不同。安卓与iOS系统不同，硬件设备也不同，例如协调安卓已有的返回键，可以在做功能和交互设计的时候不在APP中设置返回按钮，这一点陌陌在安卓端与ios端就做的灰常好。而不能为了统一而统一，片面理解了简洁，简洁不是简单。

三、积极正能量影响各合作人员完美主义起来

     理解RD时间紧工作量大，产品经理定要在设计方案的时候想全面，别在开发途中或者开发完了改大需求，作为一个写过代码的程序员，这样真的挺坑兄弟们的。但是偶也不认同，在接到需求的时候，技术方案与之前的不同就拒绝落实需求或者要求改方案。项目的一生总会遇到无法提前规避的各种各样新的旧的问题，而且往往新需求新方案就会用到新技术来解决。这个时候，回避问题不能解决任何问题，迎难而上才有可能解决当下的问题，也可能同时解决了其他已现问题，并突破技术难点，为以后做出更优的东西打下基础。

     测试作为质保部门，责任重大，产品上线前需要测试部门全线测试，对方案的实现程度、业务的流畅程度、并发的处理、边界的处理等都要一一细致的检测。如果没检测出来上线了，上线后发现严重的Bug可能造成紧急修复，不严重的下版本修复。但移动端发版不像网页那样容易，往往紧急修复版本也需要几天时间才能到达用户手上；而遗留bug好多也会静静的待在bug列表里待解决。如果这样的问题遗留多了，产品看似做了很多功能，体量也足够大，但是内里实际是虚的，是千疮百孔的，是不健壮的。

     因此产品经理，在跟各部门同事沟通需求、推进项目的时候，还是要跟大家解释清楚的，要用力的。因为当下看似很小的问题，时间紧可以忽略的问题，日后都可能造成隐患。而产品经理要能去提早做出各样的风险控制。

     跟设计同学争取页面和交互，是因为视觉跟交互作为表现层是产品设计实现的表层，也是用户最先接触到的产品部分，如果这部分都过不了他的关，那我们背后做多少设计他都不会理解，因为没有深度参与，也就没有留存。

     跟技术争取方案落实，是因为这是用户使用产品时会切实体验到的，如果产品稳定性和流畅性不够，体验差，也很难留存，不然花很多钱推广却留不住用户，岂不是浪费？

     请测试前置参与了解需求，方便其提早准备测试用例，做精细测试，及早全面测出问题并修复，再发版，别总给下个版本遗留bug。每个产品Bug系统上若有几千到万的Buglists，至今遗留的未解决的问题，就是现在或未来产品面临的发展瓶颈。每一版新需求开发周期都要拿出来一部分时间修复已有bug，或者新需求导致原本没有的bug，而造成周期时间不够。多半是因为起初产品方案设计的标准不够高，方案不够全面，开发按此方案执行，测试没测出来，技术没改，为此时遗留隐患；或者大家都得过且过，当然遗留问题。等到某个时间点，问题大到不得不管，就不是大家不想改，而是代码耦合度太高，无法解耦，牵一发而动全身，这就是一款产品面临的发展瓶颈。就算以后升级版本做全新移动端，如果基于此版来做，用户量激增，这个瓶颈不解决，还会出现更棘手的问题。招更多的人来维护一个本就臃肿不堪的产品是无底洞；招更多人来重构产品也费时费力，不是每个司都有那么多人力物力和最宝贵的时间来支持这样的工作。灰常稀饭的APP网易云音乐，至少在我看来就是一个提早规避了这些问题，稳定发展，可调整可扩展的好产品。

四、努力做一个恰到好处、审时度势的完美主义产品经理

     以上都是产品经理在做好自身工作的同时，也要去兼顾的，而且是同等重要的。做产品经理时间久了，感触最深的就是发现需求和给出需求方案是相对容易的，而这仅仅是开始，最难的是需求方案的真正落实。多少方案在上线时已与解决方案相离倍远，更别说上线后的推广运营等等一系列工作。好产品是基础，不然神一样的运营累屎鸟也无法把它运营好。在做好这些需求落实后续工作时，沟通是至关重要的，哪一环都不能出偏差。所以，能在一个大公司有标准流程辅助推进、控制风险是好的；能在一个小公司有相似流程来助力是幸运的；无论在大公司、小公司，有一群有同样意识又有能力的人来合作是最最幸运的。所有的问题，归根到最后，都是人的问题。如果每个人都有一颗完美主义的心，也有这样的能力，环环相扣，全面负责，那很多问题是可以避免的。

     我还在这条看得见方向的路上欢快的奔跑着，期待自己做一个有意识有能力靠谱的产品经理。既能仰望星空，又能脚踏实地。