产品和技术天生是一对冤家。因为当你的产品团队给技术施加压力足够大，或者技术这边特别希望干涉产品团队的时候，这两者的关系就会变得比较剑拔弩张，但是两者平时又处于互助共存的状态。本文将带大家了解产品和技术的那种理不清的关系，以及如何更好地处理来提高团队整体的工作效率。
技术与产品关系的方法论
技术和产品是什么样的关系？首先肯定是合作关系。产品作为一个设计师，拿出原型图，与技术进行功能需求的细节沟通，然后技术把它进行实现。另一方面，产品和技术，一个是消费者，一个生产者，这就存在一个对立的关系。这在大部分公司都会遇到，两者之间有时候在需求上会取得一个平衡。还有一种是暧昧关系，产品和技术表现为亦敌亦友，比如市场活动、广告这些小的需求，产品有时候会帮技术去承担一部分，这个时候产品和技术是相互掩护、相互帮助，关系比较暧昧。
本次，我准备给大家讲一些产品和技术的方法论。在这些方法论最后，我会抛出自己的观点，技术跟产品到底保持怎样的共同协助的关系才会相对健康一些。
1．关系方法论之一：技术应该理解产品方向
我觉得技术要做几件事情，第一就是技术应该理解产品方向。为什么技术需要理解产品方向？因为产品方向对员工的士气非常重要。下面拿执行力最强的一个组织单元军队来举例，在你的印象中，军队的高层领导命令部下要去攻打某个地方，他的部下就往前冲吗？不是的，真实情况是高层领导在命令下达的同时，会告诉他的部下，我们打那个地方的目标是什么，向哪个方向防御，向哪个方向进攻，向哪个方向做准备，有可能会经过哪些地方，可能会撤到哪儿。这些指令不光是高级将领去指导部下作战的一些备用方案，其实更多是告诉他一个目标，让他们了解拿下这个地方之后要怎么做。这就是为什么在打仗之前，要做一个全体动员。同样，对于产品，就要求他在项目启动前，告诉技术这个项目的发展方向和做这件事情的意义，从目标层次上达成一致。
如果产品不告诉员工方向的时候，他会觉得这个事情根本就看不出来意义在哪儿，你没有跟我做任何沟通。技术理解产品方向，首先在士气上就特别重要。
第二，在代码的架构设计上，技术需要和产品协商好功能是否有全面实现的必要性，数据库、接口和架构是不是要快速迭代并做好功能预留，后续是否涉及重构。这里建议技术直接问产品，你下一步到底想把这个功能做成什么样子，是一个大众化的，还是只是一个试点小众的，你的入口有没有可能扩展到外面，导致自己服务的压力上升很多，还是说你这个产品可能会跟别的产品捆绑在一起，我的接口是不是要做一些预留，你可能会用到几家的服务，还是说一家就可以了，像这些问题都非常重要，如果不去问的话，下一个迭代中，大家就会累死。
第三个好处是说技术储备。其实很多时候产品不敢匆忙上线，是因为我知道我的技术可能现在这个阶段做不了。我知道你们承受不了再上一个数量级的服务，我知道你们的搜索技术还没做好，你们的技术储备还没做好。这个时候产品永远不敢上，但是技术如果不理解产品方向的话，他们也会说产品还没提需求，我为什么要做它，我有更多的时间，可以去做点现在的新功能或者功能优化，而不是投入更多到项目的发展上去。
2．关系方法论之二：技术应该理解产品细节
技术部门经理的一些责任，就是去跟产品沟通方向，去给自己的技术往前去规划一个路线，这个非常重要。
方向理解完了之后，第二个就是产品细节。其实好的产品跟技术的一些交互，应该用一个完整的文档把这个细节写得很清晰，我知道有些创业公司，尤其是在早期的创业公司，细节并没有那么细。但是作为技术，在一些小的细节上需要很好的把控，原因有以下三点：第一个是架构的选择，再一个是产品的质量，第三个就是产品的bug。从技术层面上进行维护有几种好处：首先是按模块去划分，在产品线呆得比较久，所以对业务的熟悉程度很可能在产品之上。其次，因为好多办法是互用的，所以技术可能会比产品更清晰或者更容易找到哪个地方是两边都会用到的，然后提醒产品自动更新是有问题的，从而在逻辑方面对产品会有帮助。
说完了前面两点，我们技术一定要去关注产品，直接去挑战产品的一些思路、设计，包括为什么要这么做。这个时候就特别容易剑拔弩张，有时候产品会觉得我是产品经理，还是你是产品经理；这个产品需求，我为什么要跟你解释这么清楚。在这种情况下，如何避免两方交火，就要求双方相互要做一些理解，其中一部分，就是技术要理解产品的一些困难。
3．关系方法论之三：技术应该理解产品困难和鞭策产品进步
产品和技术最不一样的地方在于产品有很大的主观性，技术没必要非得让产品找出一个理由证明这个需求是一定要做的，在这个方面，技术要容忍产品的一些主观性。即便有些公司可能会做一些AB测试，但是AB测试的时间成本也不低。还有很多功能，真的是很难做评估的，就算从数字上做了试验，你也很难看到有任何变化。
除了主观性之外，还有一个是试错性，就是产品有时候自己也不知道我主观想象的功能到底好不好，你真的要去挑战他，他也没有办法辩护，所以他们很可能真的是需要一些情况去试错。
然后又回到我们技术应该有的责任感上来。我觉得技术要鞭策产品进步。可能在有些公司，产品经理内部团队之间会去进行一种相互的批评和建议，通过团队之间去成长。但是有些公司的产品，首先是每个按功能划分，每个的领域是不一样的，所以其实他们之间的成长性和挑战性没有那么大，如果产品本身不是很自省的话，他们的进步会弱些。这个时候，技术可以在这方面进行一些补充。
我们要认识到产品哪些方面是可以去挑战的。第一就是主观性产品容易加入太多，他们会不断地加这种试错，但是资源有限，也存在用户成本和机会成本。在这种情况下，技术一定要告诉产品，需求实现是一个平衡，不能无限地主观，不能无限地试错。
还有一点就是，粗糙的设计会影响产品质量，这一点一定要跟产品经理讲清楚。因为粗糙的产品设计会严重影响代码的质量。第一个是可能出现复杂的状态机，多处调用，你可能每添加一个状态，它将呈现指数级的增长，测试也难，代码会出bug。第二个就是会引入Hack代码，出现不能理解的地方，当未来进行改版，后面的技术将看不懂代码。还有就是会有不必要的服务器压力。
4．关系方法论之四：技术应该监控产品问题
技术一般会对产品效果进行监控，因为技术跟一线用户贴得很紧，他们会在运营群里面，去看后台的用户反馈，结合自己的运营和用户体验，给出产品方向调整的建议。所以技术基本上全员都会参与产品的一些需求讨论，这是非常值得鼓励的。
产品分为方向、战略、具体功能，最后才到UE。对于2B的公司来说，UE不是产品的主要部分，主要部分是做一个能够承载业务的产品。2B行业的产品思维严谨，他可能不需要关注太多的交互和取舍，只要把逻辑做好，然后该有的功能都具备就可以了。
在技术帮助产品层面，有几个方向可以考虑。第一是收集一些数据，在唱吧，每个技术都会去想他自己做的这一块有哪一部分的统计数据需要收集，就算产品没有说这些需求，技术也要考虑哪个地方需要做统计，理清里面的各种数据，把它收集起来，同时去找一些干扰项去做对比。
在招聘技术人员的时候，我们希望起码有 1/3 或者一半的技术人员有产品意识，包括他的一些架构思维。对于比较小的互联网公司，我们希望看到大家每个人都是以一种创业的心态来做事，其实公司氛围可能跟老板的创业基因有关。对于技术自身的管理问题，第一是你要选对老板，第二是作为中层或者公司创始人之一，你要去跟老板说清楚员工激励的重要性，包括所属领域有多大，老板愿意多大程度上发挥他们的创新性，老板对自己的信心和对员工的信心有多大。还有就是事情完成时的成就感，会有多少人受益，获得多大的认可。
技术与产品关系的处理策略
1．关系策略论之一：建立技术和产品之间的信任
技术和产品相互之间要PK，怎么办？要怎么去培养一个产品经理，让他能够发挥出自己的能力？怎样不让那种很弱的产品经理拖累大家。这里有几个策略：第一，你要让产品经理去试错，产品完成后，我们看产品经理出来的应用情况去打分，并按照重要性去评估风险。如果你不愿意为这个功能背书，你就放弃这个机会；如果你愿意，你就赌这一次，最后产品上进行 3～6 次迭代，我们来看这个产品经理的能力如何。
技术也是一样，产品想试错是可以。我们就来赌，我们按照你的技术方案走，最后看你的评价能力怎样。最后的理想结果是构建每一个产品经理、每一个技术人员他自己对产品的理解，慢慢树立他在团队中的威信。所以，我是觉得一开始不要打压产品经理特别狠，要给他们一个机会，让他们用事实说话，去建立自己的一个威信。
这其实牵涉一个OKR的问题，就是结果导向。产品要告诉技术大概的实现目标，我们去衡量你这个结果大概达到什么程度，所以不会把中间的一些小的数据拿出来去衡量产品，更多是看产品的迭代之后会是怎样的一个情况。这是我的方法论，如何去评价产品，可能在大部分公司，产品经理跟技术之间没有这么融洽的话，还是产品团队内部会去做一些评价，产品A去评价产品B，产品B评价产品C，相互之间互评。这种情况比较适合技术和产品衔接特别紧密的团队。
有产品观的技术是什么样的？技术必须满足至少三点。第一是大局观。技术不光要关注自己的技术领域是否实现了，他还要知道公司想往什么方向发展，产品往哪个方向发展。
其次是有逻辑性。逻辑性在于发现产品的bug，就是我知道哪个地方是有问题的，包括产品怎么做，甚至产品设计的一些不好的地方之类的，他都能够去了解。像测试为开发的质量负责一样，开发也会为产品的质量负一部分责任，这个相互去支撑，其实能够使这个产品的成功率变得更高。
主动就更不用说了，一个有大局观的人，他必须要主动。最后一个加分项是审美，就是你自己对这个产品本身有没有感知。技术追求代码架构的干净、完整和扩展，他在产品上会有同样的产品观，他希望产品的一个功能跟别人不要咬合得那么紧，他希望产品在买点上、在未来是有扩展性的，这种技术提出来的产品建议往往非常好。
2．关系策略论之二：打造具有产品观的技术团队
需求方在招聘中需要注意哪些点呢？首先，工资的定位一定要适中，不能过低，这是肯定的。当公司把工资开到百分之七八十的时候，可以淘汰掉一部分只追求钱的工程师。那些真正对这个产品感兴趣，希望推动做事的工程师，他们会愿意牺牲一点点的个人利益，去加入公司，但是进来的工资会稍微卡得低一点点，不会开到最高。
其次是技术对产品的理解。我面试的时候，一般会去问他当前产品研发中遇到的一些问题，你觉得现在公司做得怎么样，你觉得问题会出现在哪些方面。其实我最开始的目的是想知道，作为一个技术，他认为他为产品做得不太好的地方负多大的责任，这会增加他的责任感。这种认识的清晰度有助于他后面去做设计，去做架构，甚至整个对公司的贡献，所以我直接会问他对产品的理解。
另外，你们也可以去问他有没有主动去做的一些事情，比如有没有在功能之外准备一些备选，哪怕做一些工具也好，这种事情是特别难能可贵的。
再一个就是责任的判断，当问题出现的时候，你去问他这个责任到底是技术的，还是产品的，或者是哪个层次出现的。这个时候既体现了他的一种责任感，也体现了他的一种逻辑性，就是你怎么判断这个功能责任的归属。比如产品和技术经常遇到的bug复现问题，理想的状态是，技术会跟测试一起想办法寻找里面可能让它复现的地方，即便是那种不可复现的bug也不能扔在那儿，一定要有责任感。
然后就是冲突的解决。技术经常碰到产品老改需求，有时会设置封版期，比如半个月不让改需求了，不过也可能会出现这种情况：如果那个需求不改的话，会影响产品上线的效果，这个时候，该加的需求还得添加，项目需要延期还得延期。
技术团队和产品在产品观上如果获得很好的融合，技术会关注产品的发展，愿意主动沟通和做事，毕竟大家的责任感和价值观是一致的。
3．关系策略论之三：建立健康的工作流程和反馈机制
我们每个公司都有很多内部的会和外部的会，不一定是针对一个议题的，也可能是一个简单的、小规模的碰头会。比如产品内部会有一些产品需求讨论会、功能审核会、竞品分析会以及运营策略会。技术那边可能会对业务需求进行分解，进行概要设计、代码审核、上线审核这些环节。
两个部门中间这一块是产品加技术。每个公司的情况不太一样，可能大部分都会有一些需求讨论会，有的也会有需求宣讲会，需求宣讲会后，需求还是可以讨论的。那么，后续会进行一个需求答疑会。从开会频次上看，需求讨论会和产品分析会可能会少一点，因为需求讨论会是讨论需求到底要不要上，产品会跟技术一起参加讨论。产品分析会是产品做得好不好，上线之后会有技术来参与一起听。
这里的产品分析会很重要，它是一个衔接和一个反馈。为什么我们的技术愿意去思考这些产品的功能，最终帮助产品去做完善，因为一定要通过最后这个产品分析会来完成一个闭环。你光有需求讨论会，需求讨论完了，开发功能确定以后，后面的实现效果没有人关注，技术的主观能动性一定会降低很多，所以必须要有产品的分析会，把技术拉上，产品告诉技术这个功能做到什么程度了，这时不光技术能帮忙一起想有哪些能做的，而且可以帮助产品一起去排除潜在的问题。这不是说问题是技术实现不好导致的，更重要的是让技术知道我们看重技术的主观能动性，而且技术能看到这个产品方向的未来，他们也能准备下一个版本要不要去做优化，并提前做一些准备，所以这一点非常重要。如果没有这一点的话，强烈建议你们把它加上，但是前提是要保护好产品，不要让产品下线。
还有一些技术反馈产品需求的通道，一般公司会设置需求池，可以查看谁提出了什么观点、描述、时间，这就要求产品要周期性地对这些需求进行盘点，说明这个需求为什么不上线或者我们可以上线，什么时候上线，上线之后会是什么样子。建立需求池的好处是建立产品和技术双方正式的沟通渠道，技术可以跟产品进行意见反馈；另外一方面，对产品也是一个自我训练，同时技术会感觉受到重视。这个需求池做完了之后，我们产品如果不需要迭代的话，会直接变到我们的技术需求层里去，技术会找最近一个版本直接修改。
另外一个产品反馈技术需求的通道，就是技术委员会。通过设置页面，专门去让所有的部门提需求，技术委员会定期在里面说明哪些需求要做，哪些需求不做，现在做是为了什么，哪些功能未来是可以做的，并给出一个大概实现的时间点。技术委员会的作用一方面是为未来的技术发展寻找方向，然后去隔离一部分要做的资源，去做一部分的招聘。另外一方面是培养技术的一些自发意识，让你知道哪些项目是可以做的，甚至当团队做完一个项目，出现空档期的时候，技术委员会拎出些项目来做，让大家的工作更饱满。
反馈机制还有两个渠道，刚刚提到的产品总结会是一个，就是产品把产品思路交给技术，然后那些对产品感兴趣的技术能够评价产品。同时技术传授技术基础的通道是技术公开课。很多技术讲座会分成两个部分，前一部分会讲大面上大家都在做的技术实现方法，然后针对自有产品的特点，不光告诉产品哪些功能是技术做不了的，还会告诉产品哪些功能是我们技术能做到的。
技术与产品的结晶
这块内容是技术和产品部门领导非常关注的主题，就是技术和产品如何达到最大程度的工作配合，以及以往有哪些成功经验可以分享。
1．技术与产品的人员配比
之前统计的技术和产品比较健康的比例应该是在1:1和3:1之间，3:1稍微有点难，2:1可能会是比较正常的公司。但如果你这个公司特别依赖产品，比如说做社交的公司，产品经理可能有一部分的需求就直接被忽略了，他可能每个星期有一半的产品过了，一半没过，这种情况下技术与产品的人员配比可能会变成1:2，这是比较正常的。这个配比有助于技术和产品团队去决定你们公司技术和产品应该招聘多少人。
理论值一般是技术团队按照经验值去找产品询问，今年要上线哪些新品，需要产品大致评估工作量。一个典型的产品团队应该有多大，会决定一个技术团队有多大。
2．技术与产品的交流方式
技术和产品的交流方式，基本上包括Wiki、邮件、文档库和协作平台。有些可能就是直接到Wiki上面去提需求了。有些是Wiki上或者文档里面，用文档去提需求，然后再发一个邮件做提醒。有些公司可能前卫一点，做协作平台，会有一个类似于Give Help之类的应用去更新。
（本文节选自CTO训练营作品《CTO说》）作者：黄全能
文章来源网络，如有侵权请联系小编
喜欢的可以加Q群162542073一起讨论，交流
扫一扫
1970
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
