一个人缘不错的女学生跳槽到某公司做产品经理。最近这个鬼妹经常跟我吐槽说，“公司技术部的每个开发人员都不是很牛逼，需求重复很多次还是会理解错，或者简单的回复一句‘可以’tdoit”。即使我对新产品需求有1000万个idea，开发人员也是束手无策，能力差。想想等等。”面对这一系列喋喋不休的吐槽，小编不知该如何回答才能解忧，于是将这个问题发到了朋友圈，结果各种大神的评论都曝光了……这文章发朋友圈不到一个小时，就有十多个评论，其中有CTO、高级架构、研发人员、初学程序员、产品经理……但是看完这些评论，小编慌了……决斗?刀?锋利的刀……我们来看看曾经是程序员出身的锤子科技前产品经理刘飞是怎么思考这个问题的：记得之前参加过一个团建活动，它是个真正的CS，我们产品经理很少，程序员却有几十个。所以你大概可以想象当时的场景……不是刺激的战斗，而是残酷的团战，一个被BB打成狗的产品经理子弹（咦，这不是狗吗？）急于变聪明，大喊：“我有ttencodebefore！”我是我自己的一员！』其他被施暴的程序员面面相觑，表示很感动，但还是拒绝了他的请求，继续在地上打了半个小时。......我在哈尔滨工业大学读书。我学习了六年的计算机和编写代码。毕业后，我做产品。所谓程序员和产品经理之间的调侃，主要是因为双方之间经常会发生冲突，而冲突明显是因为双方既是需求提供者又是需求实施者。矛盾的种类也很简单，就是大家常说的那几种。我一边写代码一边做产品，但其实我还是没有一个很好的通用规则可以解决所有的矛盾。但是当了产品总监之后，我的理解就完全不一样了。产品工作和研发工作都在我的管理范围之内，所以我看事情的角度完全不同。作为以前的程序员，总觉得改提供的需求很烦人，需求不合理，deadline也不合理。在做产品经理的时候，我也觉得程序员总是推卸责任，没有及时完成，或者做的不够好。其实，从整体工作协调的角度来看，问题在所难免。关键是如何预防和解决。...以下是一些基于个人经验的实证建议：对于开发人员：1.准备更改需求许多顽固的程序员会认为更改需求是一种错误。改变需求？为什么不早点考虑？改变需求？你知道我的工作量有多大吗？改变需求？然后我退出了。其实在互联网产品领域，需求的变化肯定是家常便饭。我没做过统计，但是我接触过的成立一年的公司几乎都有大改版，也就是所有的代码都重写了。这对于研发团队来说自然是痛苦的，但却是无法避免的。对互联网的需求经常变化。一方面，大环境随时都在变化。去年还在刷微博，今年已经是朋友圈了。另一方面，获取需求的渠道也多种多样。产品经理可能会有新的发现，新的判断，不一定都是以前想通的。当然，如果需求是老板从《易经》得到感悟，从云卷云舒花花花得到灵感，让你赶紧帮他改，那就没意义了。由于变更需求经常出现，因此需要做好变更需求的准备。有以下几种方法：1.1提高代码的可重用性、可扩展性等将一些产品中很可能会用到的各种控件和功能模块做成可重用性高的代码，增加类似功能的使用时会有很大的好处，或者当现有的类似功能被修改时。可扩展性是指各种接口、数据库、底层结构不应该写死，而是尽可能以可扩展的方式编写。比如现在有五个类别，不要写成五个，而是写n个类别，目前是五个。嗯，这是常识，只是有些程序员比较随意，写代码没有远见。其他代码特性，如果有助于减少产品变更和优化成本，也应该多加注意。1.2根据产品规划做好充分准备。每个功能的实现方式有很多种。如何选择，不仅要根据当前的成本，还要对未来的产品进行统筹规划。目前可能可以完成功能A，有1、2、3选项，选项1成本最小。但是A、B、C、D的很多功能都是未来完成的，方案3更有利于最小化整体成本。然后选择选项3提前计划。多和产品组沟通，了解未来的产品会是什么样子，哪些功能是必须的，哪些功能可能会用到，要有长远的眼光。1.3合理预留修改时间首先，不要把研发时间当成完成时间。研发功能只是一部分，测试、修复bug、处理突发情况的时间一定要预留。有两种情况需要预留更多的修剪时间。一是研发团队对功能没有把握。可能是一个全新的功能，也可能是一个比较难的功能。可能BUG较多，功能实现不佳，多预留时间。另一个是产品团队也对该功能表示怀疑。比如在提供需求的时候说这个功能有可能要调整，或者说这个功能本身信心不够，需要多花点时间去调整。2.了解需求，防止返工研发团队通常缺乏对需求的了解，尤其是外包团队。听过太多的外包团队花了几十万，开发出来的结果却特别不理想，用不上。合同又签了，钱也得还，就算是丢了老婆丢了军。一些技术团队和产品团队坐在同一个办公室，他们经常缺乏沟通。技术团队不知道现在的功能是给谁用的，提供什么功能，满足用户的价值是什么。这些都不是很深的理论，不需要深入研究。你只需要通过产品经理去了解，就可以省去一些坑，也不会轻易返工。比如有些产品页面可以提前缓存，也可以每次都刷新，但要看用户平时是在WiFi环境下使用还是在移动数据上使用，这个产品经理一清二楚。产品经理不会想到实现层面在功能细节上那么具体，所以研发团队需要了解刚才说的需求，做出一些判断。另外，如果在开发之前就意识到做出来的功能会和产品经理想象的不一样，一定要及时提出来。不要等到开发完成。成本对任何人来说都太高了。3、善于与数据、理论、通俗解释进行交流。程序员最忌讳的应该是“这个做不到，你又不懂”或者“这个太难了，我懒得跟你解释”。产品经理听了肯定会觉得自己在推卸责任。正确的做法是：用通俗易懂的客观事实来解释。嗯，这个弹窗做不到。为什么现在做不到？因为代码实现可能需要三个月。为什么这么久？这是因为需要在底层驱动程序级别调用一些东西。为什么叫底层驱动的东西呢？因为Android系统原有的框架和协议就是这样设置的。如果你想看协议，我可以帮你找到。就这样一步步解释，把所有的原因都解释清楚，不要不耐烦，只要产品经理讲道理，他都会理解你的。如果他听懂了你的解释，也会帮助他找到另一个可以接受的解决方案。哦，原来如此，这种弹窗的形式太复杂了。然后让我们跳转到普通页面。这样问题就解决了。对于产品：产品经理在不断迭代和不断变化的需求的风险中得到程序员的认可是最重要的。我认为最重要的是“合理”。不要说“我无所谓，反正我必须完成”或“老板就这么决定了，我没办法”之类的狗屁话。1.对产品功能有规划就提供给研发，对自己的产品没有一个大概的规划，是产品经理的大忌，也是出问题的主要原因。一年后，当产品成熟时，会为用户解决什么样的问题？产品在未来六个月内会是什么样子？产品在三个月内主要提供哪些功能？本月有哪些具体的产品计划？这些都必须仔细考虑和计划。当然，长期的产品规划在很多情况下（市场变化、团队更替、产品转向）用处不大，但规划时间越短，对研发团队越有帮助。正常情况下，三个月内估计出产品的功能是完全可以的，除非老板和产品经理都不知道这个产品应该用什么做。把这些方案想清楚并传达给研发团队，让他们在当前代码中为未来的功能留出空间，是避免代码重写的最好方法。2.提供的要求必须足够具体。这就需要产品经理做两件事：第一，把产品需求文档写得特别具体。具体来说，并不是说要按照大公司的珠三角来完成。而是不要缺少东西。对于需求文档，页面逻辑，页面布局，功能逻辑，每个功能的使用细节都必须存在。不只是画交互图就叫需求文档。你给了R&D5页，R&D还在工作，我来问你，好像少了一页。你完成了一个，做了一段时间研发，发现少了一个……***10个零碎的页面拼凑起来，发现不好用，推倒重来再次。如果R&D经常问你在某个地方做什么，你要反省是不是需求文档写的不够好。其次，解释每个要求背后的原因。这在上面已经表达过了，程序员明白了需求背后的原因，就会选择更合理的方案来完成。不要提“不要担心为什么”，而是告诉他为什么不管他问为什么这个功能是这样做的。3、熟悉基本的研发背景和研发能力“产品经理需要懂技术吗？”是我被问到的关于产品经理的TOP5问题。我对这个问题的回答是：根据需求了解基础知识，不需要了解实现细节。知其然不知其底，就是说产品经理应该知道一些最基础的理论。比如你是Android操作系统，你需要知道Android原生提供了哪些控件，这样你在设计解决方案的时候就可以尽可能多地使用它们。在代码实现上，调用一个控件可能只需要几行代码，但是自己重写一个功能接口可能是几千行代码。比如手机网页上的产品，需要知道哪些交互在H5上比较容易实现，哪些交互非常有效。如果在iOS上根据动画效果需要H5，开发成本可能成倍增加。点播就是对产品经理来说，不买《iOS 入门指南》、《安卓开发手册》、《H5 设计实例》来学习。除了装饰书架外，它没有其他意义。因为自己开发的指南和手册都是实现细节，对于你理解Android的基本控件或者H5的常用交互完全没用；同时，不同的产品具有不同的特性和代码特性。你只需要了解你负责的产品的技术背景就足够了。有的同学居然决定从C语言入手，简直尴尬。以上就是刘飞的一些了解。希望对大家有所帮助。
