浅谈企业中产品与技术合作的管理
By 韩嫕@央视网
摘要：本文旨在讨论企业中产品和技术工种之间的合作和协调管理，作为企业发展产品的灵魂，技术和产品经常站在相反的两个对立面，无论管理者偏向哪一方，事情的发展往往都不顺利，合适的管理模式将有效提升双方的动能，增强企业在市场中的竞争力。
前言
产品与技术，互联网生态中天生的冤家，互联网文化里天天都能听到关于产品汪和程序猿之间的种种故事。由于双方立场的不同，这两个“种族”从出生的那刻开始就已经相互烙上了死磕的烙印。一个新产品的诞生最离不开的就是这两个“种族”，虽然有些时候这两个角色可能集合在一个人身上，但大多数时候特别是在有一定规模的企业中，为了给企业追求最大化利益，领导者一定会从根本上对这两个角色进行分离。
在这个过程中双方有的成了欢喜冤家，有的甚至天天拍案而起像一对“仇人”。产品经理最怕遇到古怪的技术工程师，而工程师则最怕遇到天天变更需求的产品经理。
但也正是由于产品技术密不可分的关系，在大多数中大型互联网企业中，产品和技术部门在管理体系上往往是统一的，被称为企业的“PT线”，更是互联网企业的生命线，由统一的高层进行管理。协调平衡产品和技术的位置，处理两个部门之间的关系，就成为了互联网企业高层管理人员必须掌握的管理艺术。下面我将就自己的一些经验，浅谈在企业中如何做好产品经理和技术工程师之间的管理。
有些人看到这里可能会说少了运营这个环节，由于篇幅所限，本文中我并没有把运营这个角色混淆进来，希望在以后的篇幅中再进行讨论。
一、选择合适的产品经理实现团队的成就感
对于产品经理的定义非常多种，我个人更愿意形象的把它定义为产品大管家。关于产品经理的地位，在业界一直存在争议，到底互联网公司的核心竞争力取决于核心技术还是核心产品？很难说的清楚。虽然我一直是说自己是技术出身，但我仍然推崇产品经理在整个产业的贡献和地位。不去纠结产品和技术谁更重要，作为管理者，应该关注的是当我们去选择产品经理的时候应该注重哪些特点，产品经理又该具备什么技能？ 下面我将浅谈几点个人的理解。
首先，产品经理应该足够的熟悉和了解用户，这里的用户从老板到团队内部的各种岗位角色再到真正的使用者，产品经理需要使用最通用的表达形式让所有的干系人都理解自己的设计初衷和用意。产品经理除了要保持自己出淤泥而不染的想法外，还要充分聆听所有用户的需求，在其中找到最佳的平衡并让使用流程变得简单。
其次，一个合格的产品经理应该有一定的技术功底，当然产品经理不需要去做技术要做的事情，也不一定非得是自己做过大规模的coding，但是技术工种严密的逻辑性思维能力会让产品经理和工程师的交流变得简单。特别是当攻城狮种族对苛刻的需求提出质疑的时候，一个具备技术功底的产品经理可以清晰地描述出自己设计的意图，流程要怎么做，设计原理是如何，甚至亲自上手将核心逻辑算法展示出来。试想一下无论多磨孤傲的攻城狮在这个时候都会对眼前的产品经理顶礼膜拜。而后的所有事情，程序猿种族就会规规矩矩的按照需求去执行了。
最后，我认为产品经理要会借助外力并且能够做好沟通交流。大部分的产品经理经常面临多头受气的情况。技术、运营、领导、市场各个层面都会对产品经理提出特别要求。产品经理也经常面临无所适从的情况，在这时候就要合理的借助外力来进行压力传导和转移。一个成功的产品经理因素离不开有效借助外力搞好自己的人际和人脉，有时候一顿酒、一场球会把之前的针锋相对变成平和的茶话会。
作为团队的管理者，在一定的程度上要给予产品经理更多的信任和权利，并且树立产品经理在整个过程中的权威性，在资源配置和权利义务上都向这个岗位倾斜。另外就是要在团队组织中明确各自的分工、制定合理的流程，鼓励团队由产品经理带着开晨会、需求分析会等，无论运行还是开发过程中，需要定义清楚每个阶段（日、周、月、季度）的交付物，让所有岗位在工作中都得以释放和表现。
二、帮助产品经理合理评估需求及配套资源，减少技术开发做无用功
管理者经常面临需要协调产品和技术之间最大的矛盾莫过于需求的不合理或者经常地变更导致开发过程中不停地打乱进程。有时候需求是从市场反馈来的、有时候需求可能是管理者拍脑袋想出来的、有时候可能是经营部门为了配合市场需求“过渡”设计出来的。理想状态下一个优秀的产品经理就会通过他对市场的理解核对需求的掌控进行重新整合，并向技术部门输出合理的需求文档，技术部门按照需求进行开发，按照时间交付上线，但大多数时候并不一定如此。一方面是由于产品经理能力的参差，一方面也是由于产品经理所处位置的眼界限制，产品经理交给技术的需求常常层次不明，优先级混乱，甚至超出技术开发所能提供的资源能力。
正如大多数人坚持的那样，技术工种的相较于其他岗位是一个偏科学形的岗位，需要通过时间、资源配置和勤奋的努力使用代码或者算法去实现一个个看起来很美的功能。目前大部分的互联网产品都是通过非单机的形式表现，也就是说在技术内部也需要分成多个工作岗位配合才能完成一个相对复杂的功能。每个功能的实现都需要通过非常严密的逻辑设计和容错优化实现，多个功能交杂在一起的时候环环相扣的逻辑在面临调整和修改的时候非常复杂，即便是再成熟的程序员也会非常排斥频繁的需求变更。
此时，管理者就应该站在应有的高度和战略的角度，帮助产品经理根据效果、资源配置情况科学的评估产品需求，对所有需求进行分级、分层，合理规划技术资源配比和实现步骤实现时间，这样才能让产品“说的出”，技术“做得到”。合理的需求需要有几个构成因素，需求是真实存在的，可以解决真正的痛点；需求是合乎情理、符合逻辑的；在完成这个需求的时候周边的资源是可以配合的，包括人力资源、技术资源、基础储备资源等；最后完成需求的时间是合理的，时间节点不能太离谱，要按照实际可行的方式执行。严格把握以上几点，产品经理就可以消除80%不合理的要求。在管理者的角色上需要阶段性帮着产品经理在决策中回顾这些步骤，特别是在关键的版本更新中，一个需求的把握可能关系到整个产品的未来走势以及市场状况。
同时作为管理者，还应该尽量创造产品与技术通畅的合作空间，把需求应对关系转变为共同创造关系。比如产品经理交付给开发需求的时候并不需要非常细致和完整，但是要突出需求的重点。在整个开发过程中给工程师留出充分的展现自己空间，通过设计开发过程中对于工程化的取舍实现对于产品的贡献。明确了重要的目标，对于如何实现产品经理提出的需求，工程师就可以利用自己的聪明才智进行变通和实施。产品能看到自己设计的功能得以实现，技术能将自己的智慧融于其中，我们便有机会见到和谐相处、荣辱与共的相处模式。
三、 创造工程师文化，让技术人员更加“靠谱”
在互联网企业中，由于工程师这个角色的专业性，他们的一言一行在企业中成为无可替代的角色，但工程师特色的线性思考模式很难产生网状辐射从而形成群体文化，一方面很难让工程师产生认同感和工作主动性，另一方面会让产品经理觉得工程师不好沟通。从领导者的角度，创造良好的工程师文化氛围，建构工程师梯队，是调节产品和技术间矛盾，充分增强工程师的创造力和提升企业动能的利器。
1、提倡小步快跑的迭代模式，构建敏捷化开发体系
在这里我们更多提到的是迭代式开发方式，也就是将整个开发过程分成若干个交付迭代周期，每个迭代周期大约在1-6周左右。相较于传统的瀑布流方式，虽然迭代式的开发对于系统的完整性并不一定能在最短的周期内完成一个目标，但这样的模式可有效地满足不断变化的需求。敏捷的迭代方式重点强调在每一个迭代周期内都可交付一个可用、可部署的系统，并通过短期市场反馈和用户体验反馈提升产品的适应性和产品质量。在互联网环境下，快速、精准、高质量的微创新将给企业带来好处。
2、引入自动化能力提升工作效率
随着用户规模的不断增大，工程师要处理的问题就越来越复杂，我们经常会听到有人反馈我们的程序出现了问题，要求工程师进行修复，然而在没有自动化监控的情况下解决BUG无异于大海捞针。通过自动化监控工具记录的日志，我们可以了解到哪里错、怎么错的从而得出为什么会犯错。
自动化的价值就是用脚本替代人的劳动量，目前市场上主要自动化环节包括测试环节、运营监控环节以及数据采集分析环节。构建自动化体系是企业发展到一定规模后必要的投资。
3、代码review文化有效提高工程师之间的交流渠道和工程水平
维持一个高质量的代码库会有效提升整个工程师团队的工作效率。随着产品的不断迭代，整齐的代码库将更便于团队在扩展中的适应性，并且不容易引入错误。代码审核是有效降低错误的必要过程，在代码审核过程中团队的成员相互接触对方的代码，在相互交流、相互评审中可以促进团队成员互相学习共同成长。
代码评审中不区分工程师的等级，没有经历过评审的代码不应该进入程序的主分支。这是代码审核中最常见的两种原则，越大型的程序越需要经历完整的代码评审过程，这样在产品未来发展中才能平稳发展。
4、建立内部知识共享
术业有专攻，在技术领域更是如此。但是在开放的互联网领域，虽然有众多专家，但各家都还会有各自的见解。在团队中保持共享的代码可以带来多种好处，首先可以有效避免团队相关垂直领域人才流失造成的风险，在每一个功能、没一个模块都共享的情况下，鼓励团队多多了解别人的领域并相互学习除了提升团队整体水平外也可以提升企业抗击人才流动的风险；其次共享要鼓励跨界，鼓励项目中或者跨项目的员工参与到知识共享中，有助于保持员工对工作保持趣味性，提高学习积极性；最后知识共享可以创造工程师的成就感，工程师非常重视自己在GIT或者开源社区的贡献率，然而并不是所有人和所有项目都适合开源共享。构建企业内部的共享体系并给内部工程师合适的展示平台可以让工程师获得自我认同。在内部交流中更可以让员工充分展现自己的魅力和知识，促进相互间的了解。
5、建立学习体系
工程师行业被誉为在以摩尔定律方式发展的行业，其中最重要的就是技术发展的快速更新。我们经常看到在社区里面会出现大量的新型语言和新型词汇，这就意味着工程师不能“啃老”，持续学习和寻找挑战是在这个行业发展的根源。通过建立培训和交流文化让工程师充分掌握成长和成功做的必要技能。
技术人员的水平和“靠谱”程度，直接关系到产品经理设计的功能是否能被表现出来，工程师与产品团队以“创造力”为核心达成水乳交融，才是双方和谐共处的基础。
四、通过项目经理的介入减少产品经理与工程师之间的直接冲突
我接触的企业领导中有两种极端情况，一种是技术至上的模式，也就是说任何事情都以技术先导完全凭借技术部门对事情的评估进行需求合理化判断，站在工程师的立场这样的领导非常平易近人，工作环境和气氛也会很轻松，但通常这样的企业会发展缓慢，久而久之无论是团队核心人员还是新进入的员工都会对这样的气氛感厌倦；另一类是完全不听从技术部门的评估，一意孤行的领导，只看重产品“说”能力，不关注技术“做”的可能性，一旦技术没做到，就认为是技术团队出了问题。这样反作用力也会很明显，技术团队整日就处在应付和疲于奔命的状态中。
一个科学的管理者，既不能只依赖技术，也不能只依赖产品，更科学的方式，是引入一个第三方角色对双方的资源和工作效能做更科学的评估、督促和融合，这就是项目经理。
项目经理这个角色其实在所有的项目中都存在，在产品设计及开发初期阶段经常由其他的岗位兼任这个角色的负责人，产品经理或者技术开发人员都有可能兼任这个岗位角色，或者一个项目初始的创始者。随着产品的逐步成熟企业规模的不断变大，所有的角色都将面临重新精炼和垂直定义，这时候我们会发现除了原来的产品经理和技术开发人员外，更多的角色将被加入，比如UI、交互、测试、用研、运营、数据分析、市场渠道等等，但是我想说在产品研发和迭代过程中可以有效协调产品和技术之间的角色应该是项目经理。
项目经理特别是工程类项目经理一般来说都是从技术工种“转业”的，这个岗位的人员需要掌握信息系统相关的知识体系，具备信息系统知识、熟悉项目管理方法、掌握项目管理工具、了解业务流程和相关规范，在全球有PMP体系，在国内也有信息系统项目管理考核体系。
项目经理将产品经理和技术管理的一部分职责整合，在项目执行过程中可以屏蔽所有主观因素，将所有精力都放在时间、质量、资源三个核心要素来平衡产品与技术之间会产生的矛盾点。项目经理需要站在技术的角度帮助产品部门出谋划策，又需要站在产品的角度说服技术部门通过最优化的解决方式解决产品提出的需求，并督促事情按照既定的时间和资源投入完成目标，实现企业利益的最大化。
五、构建相互信任、相互理解、相互尊重的团队气氛
产品经理也好，技术团队也好，要和谐共处，说到底还是人与人的交往，而这其中相互尊重、相互信任、相互理解是和谐共处的基本因素。建立产品和技术和谐的沟通合作环境更是如此。
首先，相互信任是一切的基石。如果合作双方不能信任对方，整个团队中就回惧怕冲突，缺乏真正对事不对人的争执，造成一团和气的假象。在实际执行中就会出现问题，并首先逃避责任。信任文化源于充分的了解，创造合作沟通的机会加强团队成员间的交流，加深团队成员间的彼此了解，以增强团队成员间的信任，从而深化成员间的合作。
有了双方的信任，我们就可以探索第二步相互之间的理解。俗话说“屁股决定脑袋”，我们在什么岗位上就会从自身岗位的立场考虑问题。在需求过程中让技术和产品人员都充分参与到头脑风暴和分析讨论中，让双方可以更好地理解对方的立场和需求，在合适的小功能点上尝试让技术人员充当产品经理角色，完成产品设计并自己开发；让产品人员配合开发人员进行流程设计可以让双方更好地了解对方的工作。
理解的基础上，才能实现相互尊重。尊重并不是仅仅是形成良好企业环境的前提，更是企业激发员工创造力的源泉，工作中互相尊重主要体现在以下几个方面：对他人的认可，理解和赞赏他人，倾听关注他人的需求，欣赏他人，以请求而非命令的口吻寻求帮助。技术和产品团队虽然是常规对立的岗位，但如果能够充分的尊重对方的想法和意见，双方的交流可激发出更多的创意和想法，可以成为员工创造力萌发的催化剂和孵化器。
六、总结
企业中面临产品和技术之间的问题是管理者经常要面临的难题，大多数时候我们都需要见招拆招，本文也仅仅是本人在团队管理过程中的一些见解，希望可以给需要的人一些建议，也非常希望有更多的朋友参与到这个话题的讨论中，相互协助相互成长。