程序员的作用不应该是帮助产品经理梳理业务逻辑

程序员的作用应该是穷尽其软件开发和设计的技能，完成一个个能够提高效率、解放双手、让人们生活更便捷的工具和平台，而不是帮助产品经理梳理业务逻辑。然而，实际如此吗？恐怕诸多程序员都有话说，甚至是“有个马卖批不知道当讲不当讲？”。

君不见很多程序员，一方面得写代码，一方面还得给无偿辅佐产品经理这个小皇帝。给产品经理上业务课、帮助他们修改“比草稿还垃圾”的产品需求文档。通常来讲，只要是稍微复杂一点的项目，产品经理的初版需求文档只是提了一句话的需求，和百十字欠考虑的需求描述，和逻辑混乱无法串通的流程图。后面的内容都是拉着程序员进行需求评审——讨论——修改——再评审——重复此步骤，然后定稿，然后开始开发，开发途中再调整需求……。一切的一切，程序员在“抗大旗”，需求的调研，可行性讨论，历史兼容性，未来拓展性，界面设计的用户体验问题都是程序员要考虑的事情和"本职工作"，问题弄清楚了之后，还需要给产品经理讲懂。同时还需要承担项目开发中延期的风险，项目上线中失败的风险，项目上线后附带的风险。然后上线之后，上线成功的邮件通常是产品经理来发：“经过1个月的艰苦奋斗，我们的xx功能终于上线了，感谢相关技术人员的付出，谢谢”。无论你付出了多少工作，你都是相关技术人员，一笔带过。

我时常为大多数程序员感到悲哀，他们就像一位托孤大臣，辅佐小皇帝治理朝政。小皇帝啥都不会，啥都不懂，一切都是托孤大臣要操心的事情，但是还得给小皇帝下跪，把奏折写好递上去，请求他的旨意。等小皇帝长大了，江山还是他的，他能否念你的好可不一定，他没准还把你办了。

是什么造就了这样的境地？我时常想起这个问题，我觉得本质还是人的问题、门槛的问题、所处公司环境的问题。但是我感觉很复杂，三言两句又说不清楚，且每个公司的情况都不一样。但是有一个很明显的事实：“程序员有门槛，有衡量的标准，有可量化的标准；产品经理则不然”，什么人都能转行干产品经理，只要他具有一个本科学历。程序员则不然，通常我们招聘一个程序员，会要求他是计算机相关专业毕业，面试的时候我们会问很多专业问题，比如：编程语言特性问题，软件框架问题，算法问题，缓存问题，事务问题，并发问题，幂等问题，一致性问题，高可用问题……这些问题都是确切的专业问题，不容你忽悠，不容你满嘴跑火车，你会你就能回答好，不会就肯定无法随便瞎说，瞎说只会掉价。

程序员需要掌握相当多的专业知识，需要不断的学习和积累，要想掌握这么多知识，可不容易，门槛还是很高的。而产品经理呢？我认为产品经理的门槛也很高，我觉得最起码应该足够聪明、具有很好的逻辑性、具备一定的审美能力、至少具备某一个行业的业务知识、具备一定的交互设计能力、具备较好的文字能力等、大致懂一点技术就更好了。而实际上呢？很多产品经理都是“拖后腿的”，这一点我不用多说什么，垃圾的产品经理你们都碰到过。

我不是要贬低产品经理，我尊重每一个工种，实际上我也有同事和熟人在做产品经理，他们有的设计了瑜伽APP，有的设计了运动方面的APP，有的设计了财务方面的网站，也有在银行做产品经理的，他们都干的不错，设计的产品足够简单实用，界面美观，布局合理，操作便捷。我也不是说产品经理完全没有门槛，但现实是很多产品经理真的没水平。我痛恨那些“小皇帝型的产品经理”，啥都不懂，啥都不会，就是看了几本书背了一些入门概念，学会画点简单的axsure原型图，然后PRD文档就是垃圾草稿，原型图就是个图片流程都串不起来。跟他一起工作，你得背着他负重前行，疲惫不堪。

诸位猿人朋友们！程序员的作用不应该是帮助产品经理梳理业务逻辑啊！ 我们不应该浪费时间去做无意义的扯皮，不应该浪费时间去帮他忙梳理不成熟的想法和产品初稿。如果说一个产品需求能正式启动的时候，文档大概是90分，那么初稿我认为至少的达到70以上。也就是基本不用改太多，也不需要开发补充太多内容，也不需要开一遍又一遍的会议去讨论修改。

如果产品人员优秀一点，能够做好他的本质工作，需求明确，文档详尽，调研充分，逻辑清晰，设计合理，交互简单良好。我们看着这样的高水平文档，对我们来说也是有学习的价值。如果产品的想法也比较好，能超过我们技术人普遍的技术思维之上想事情，能让我们感受到技术之外的好想法，那么跟他们交流也能拓展我们的思维和眼界。

如果你所在的环境，产品经理很垃圾，我劝你离开。程序员的作用不应该是帮助产品经理梳理业务逻辑！。程序员的作用应该是，帮助优秀的产品经理实现他们卓越的想法，让人们看到技术的价值。而不是没日没夜的帮助垃圾产品经理梳理业务逻辑，教他写文档，明明我们已经都知道的事情，还要让他明白，然后再让他反过来告诉我们做什么。功劳也是他的，成果也是他的，你只是写了一些未来还需要翻来翻去的烂代码，你的收获是什么？成果是什么？花在他身上的时间值得吗？为什么不和更优秀的人合作呢？