思考“产品与技术都要互相尊重对方的专业性”
有头驴，它的任务就是一天到晚的推磨，这一天主人要求它把一麻袋黄豆磨成豆面，
它磨了半天，终于在中午前磨完了。本以为中午能休息一下，但这时坏消息传来，主人
不打算用豆面做吃的了，想改为用小麦磨面做面条。这时驴的午觉时间泡汤了，马上又
要开始磨小麦了。
看完这个故事，让我想起《澡堂老板家的男人们》中的大儿媳妇，她在片中有一句经
典的不能再经典的话来形象她一天到晚在家里不辞辛劳的劳作：“我就像是一头上了磨的
瞎驴”。的确，看了上面的那个故事再对比一下这句话，真是太贴切了。我想大家此时也
会很感慨的。
当需求（方）发生变动，甚至是天翻地覆的变化时，就意味着我们要修改甚至推倒重
来已有的设计架构方案了。而这无疑是很痛苦的。即使我们使用了不少“手段”（比如：
模式，架构等等）来响应需求的变化，但遇到了需求发生根本变化（需求分析出现重大
人为失误）时，同样会显得那么被动或无用。
如同我在之前一篇文中所说的，越早投入编码，代码死的越快。而越来提出需求，
需求变更的也会越快。这需求的变更一方面是市场的变化，一方面是人为因素。前者我
们无法准确预知，而后者却可以通过一些方法部分加以控制。比如专业的咨询分析，科
学的汇总，充分的调研论证，而这都是对人自身能力，行业背景，工作经验的考量。现
在公司招的人五花八门，经常是专业不专业都招进来，然后通过短期培训就上岗了。如
果这些人之前就有相关行业的工作背景那还好说，如果是新手，并且恰恰是新手来给你
提需求，要求你这样那样的话，那就真把我们当手他们的“练手工具”了。
当然，公司内部可能还有专门的部门主管来有效的规避这种情况的发生，当然如果
你能直接找出这些新手工作上的瑕疵起不更好，起码你就不会那么被动的在他错误的思
想指引下设计编码了。所以这里我会赞同下面文中所说的观点，即“技术也要插手产品”：
如文中所说，这是需要公司有一个比较开明的“激励和体制”，让这些有产品业务
感兴趣的开发者也能参与到产品的需求分析设计中来，而不是在编码时才想到他们。
同时当开发者知道他们的开发出来的东西会提供给什么样的客户，以及客户对他们
产品的看法时，开发者也会第一时间了解到，而不是技术支持和服务部门打电话来告之
他们（要知道信息在传递过程中会有噪声的），虽然这会添加开发者的工作负担，但事
情是有两面的，这里面的好处相信大家也能体会的到。
说到这里就要提到一个非常重要的人物，就是"产品经理"，他是一个要在公司内部
上上下下，左右逢园的角色，特别是在有技术主管（或经理）的公司，往往他不会有直
接管理的手下，而他的那些资源不管是人力，财力，行政还是市场，技术支持等都是要
努力争取申请才能获得，所以他要在各部门之间水平协调沟通，从而最终形成合力，把
产品做出来，推出去。这里要求要本身要有行业背景，了解市场，熟悉技术（可做为参
考），更重要的就是： 善于沟通。
其中在那篇文章的后半部分就讨论了如果处理产品与技术之间关系的问题。当然这
里我更倾向于将文中“产品”理解为“需求提供方”，也就是提需求的人。其时还是那
句话，产品和技术之间要相互理解，团结合作，最终把产品做好，赢得更多的口碑，挣
更多的钱。而互相理解的前提就是要对别人的工作先要理解，甚至插手（这里不是为了
显摆或干涉，而是真诚的参与）。
原文链接:http://www.cnblogs.com/daizhj/archive/2009/06/05/1496663.html
作者: daizhj,代震军,LaoD
Tags: 产品经理,产品,技术,沟通
网址: http://daizhj.cnblogs.com/
