不会写代码的产品不是好产品，懂代码的产品才能走得远

不会写代码的产品不是好产品，不会写代码的产品不是好产品，不会写代码的产品不是好产品——三遍完毕。

很多产品经理都认为，产品经理不一定要会写代码，只要大概了解一下程序设计就可以了。于是我带着这个问题从我的产品经理生涯开始就一直探索。经过一段时间，总结出来以下几点思考：

1. 沟通——产品经理与程序员产生矛盾的根本原因是什么？难道是程序员就是不愿意配合吗？亦或者是程序员天生就脑子木很难沟通。我个人认为一旦产生问题，不要把责任都往别人身上丢，就如产品经理的产品做不好不考虑自己的设计问题却要怪用户奇葩是一个道理。假设产品经理真的懂技术，能看清某些看似简单实则很难实现，某些看似复杂实则很脑残的技术的话，与程序员的沟通成本就会大大降低，更不会产生产品经理觉得程序员木，程序员觉得产品经理智障，大家相互you can you up的情况 。记住产品经理永远都是一个项目的主导，如果自己协调不好关系，那么整个项目就会自上而下的产生越来越大的时间成本，沟通成本和人力成本。

2. 设计——很少有产品能在一上架就大卖的，都是需要一段时间的积累。如果设计出现问题，在新团队中会产生争执，在老团队中会出现产品上架后各种奇奇怪怪的问题。因为新团队磨合程度不够，不能心照不宣的避开一些问题，而老团队磨合的程度虽然高，但是程序员会自行判断设计出一套东西出来，最后的结果就是产品失败，导致加班，改bug等一系列的头疼问题。这一切产生的原因归咎于产品经理对技术的把控能力不到位，假设从程序设计之初就考虑到各种可能出现的技术问题，第一步先考虑产品逻辑是否正确，第二步以一个程序架构师的角度考虑程序逻辑是否正确，那么产品经理就不会再抱怨——为什么程序实现出来以后总是跟我的设计的不一样呢？（ps：当然有部分问题是连自己真正需求什么都搞不清楚人）

3. 项目管理——在这个高速发展的时代，互联网公司的竞争中，谁赢得了时间就赢得了市场。在小型互联网公司中，产品经理往往担任了一部分项目经理的角色。不管产品经理对项目成本管理，项目风险管理等理论知识运用的多好，亦或者对敏捷开发、瀑布开发把控得多牛逼。只要不懂技术，那些各种理论都是空谈，技术的启动和实现整个项目的基础，连这个基础都不懂还谈什么项目管理。因为一个项目从一开始的时间评估就是错误的，产品经理没有能力以技术角度去跟领导谈时间周期和项目技术实现方案，仅仅是依靠对市场的分析和用户的分析得出来的项目是进行不下去的。这也是导致项目延期的最直接原因。很多时候项目延期了失信于用户，亦或者为了赶工期而草草了事，最终只会造成用户的流失。

最后总结一下，一个项目出现问题，不应该去怪做具体事情的兄弟们。而是应该站在一个管理者的角度去思考问题：

• 项目设计是否合理，做具体事情的同事是否能在有限时间内保质保量的完成任务，如果不能，是否有更好的途径是实现它；
• 中层管理者是否有能力能在一线同事出现难解决的问题时第一时间帮其解决问题，而不是一味的责怪和推责任。

在一个项目中，产品经理是对产品最直接的负责人，对产品负责就是对自己负责，从现在开始，在业余时间撸一撸代码吧，一个懂代码的产品经理才能走得高走得远。