开发为什么要了解产品

                                          开发为什么要了解产品

    最近在思考一个问题，为什么开发人员需要有产品思维？

    不知道是不是所有的开发人员，就本人接触的开发人员而言，大部分都以能够对产品人员的需求提出挑战为荣，本人也不例外。似乎是下意识的觉得，完全按照产品的说明书来开发，没有任何自己的见解，那不成机器了吗，那怎么行，所以不行！我见过各种各样开发要了解业务、了解需求、了解产品（特指产品设计技能）的理由，比如减少不必要的需求，比如帮助产品人员完善产品、减少需求改动，或者了解产品能让我们更好的去开发产品，这些都是充分的需要开发了解产品的理由，但总觉得还不够，会有一些疑惑，产品是一个专业的岗位，相比开发人员而言，岗位上的产品人员，在产品这个专业技能上无疑比开发人员更为专业也更专注，显然开发人员不能教产品人员怎么去设计产品，充其量只能是建议者的角色，这个角色跟测试或者用户相比应该并不具备优势，那为什么我们要在这个看起来不在我们职责范围，不是我们擅长的领地投入宝贵的精力呢？为什么不能是这样，我们在产品实现的领域做到更专业，尽快的实现产品人员的意图，开发出产品，我们可以开发很多的工具，就像建筑行业设计的各种起重机、挖机等等工具，我们能不能定位为那样一个实现者的角色？让专业的人做专业的事，为什么不这样呢？

    心里有疑问，但还是不甘心的，内心似乎不希望真的是这样，似乎开发人员的内心深处会有一丝的产品情节。

    带着这疑问，开始寻找答案。

    首先映入脑海的是之前接触到的一个观点，不同级别或者领域之间的人进行沟通时，需要彼此熟悉对方的“语言”（泛指，领域内的术语也可以理解为语言）。不同的人进行沟通时，需要一种共同掌握的语言，如果缺少这种语言，就需要一个懂两种语言的人做翻译。部门经理作为一个例子是这样一种角色，他为普通员工与公司高层之间搭建一座沟通的桥梁，普通员工关注工作的具体执行，高层关注战略，两者看问题的角度，描述问题的方式，解决问题的办法全都不一样，而部门经理正好在中间做协调，将公司战略以员工能懂的方式进行讲解，将员工的看法以高层的视角描述。部门经理需要会两种语言，可能两种语言都不那么精，但必须能有效沟通。产品人员与开发人员之间的沟通也存在同样的情况，产品需求描述与程序代码开发之间的鸿沟极大，产品需求中基本上不会出现代码相关的语言，技术领域也没有产品相关的词语，两者之前想要有效沟通，必须要互相学会对方的语言，可以是产品人员多走一步，学一些程序设计方面的知识（这方面开发转岗的产品会有优势），也可以是开发多走一步，学会产品领域的语言，比较而言，开发学会产品语言难度小一点，而且动力也大一点，一般而言，开发人员总是不太满足于做一个机械式的听令者的角色，这也涉及到一个开发人员为什么要具有产品思维的另外一个理由，能以自己的理解去影响产品，而不只是作为一个工具被使用，具有更大的成就感和自我实现的满足感。

    再有一点，开发人员必须了解产品的理由是，一个软件产品的技术架构，受到产品现状及未来发展趋势的约束，只适应现状或只适应未来的架构都是不合理的，因此需要架构者了解产品的现状及发展，根据实际情况作出抉择，这是一个非常重大的选择，可能会影响到产品的成败。当然这部分产品及市场的知识可以由产品了解之后向架构人员传输，而且这个层面来说，只对架构师有要求，普通开发人员并不影响，但每一个开发人员都一颗架构师的心，为了职业的发展，应该早做准备，学习产品知识，你不是在浪费时间。

    再者，就普通开发人员来说，一个普通开发人员负责某一个功能或者某一个模块非常普遍，功能或者模块的技术架构和业务架构需要开发人员自己负责，深入了解行业，具有产品思维的开发人员，更有可能设置出正确的模型或者说框架，正确的模型更稳定而且便于理解，易于维护和扩展，或者通俗点说“耐折腾”，从而使得功能模块的质量更高。

    产品人员定义一个产品时，不可能事无巨细全部面面俱到，而这些没有说明的大部分是产品领域约定俗成的一些事物，如果开发人员也在这个领域拥有足够的知识和历练，那么这些被忽略的部分更可能被正确理解，否则则导致偏差而降低效率降低质量。

    最后，虽然开发人员具有产品思维很重要，但一定不能反客为主，直接将自己当做产品人员，擅自作出产品决策。产品是一个专业领域，程序开发是另外一个专业领域，两个领域要做到专业都需要大量的时间和精力，是不太现实的，非常人所能为。了解自己学习产品思维的目的，了解自己所擅长的，了解自己应该做什么和不应该做什么，跟学习产品思维一样关键。

   以上为个人对开发人员为什么要具有产品 思维的一些理解，欢迎拍砖。