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

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

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

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

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

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

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

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

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

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