CTO训练营黄全能：产品与技术谱写的协奏曲

唱吧技术总监黄全能在由51CTO高招主办的“CTO训练营第五课管理的艺术”做了主题为“产品与技术的协奏曲”的分享。其内容主要介绍产品与技术之间的关系，以及如何解决二者之间的对立问题。

讲师简介

  

黄全能，唱吧技术总监，2005年从清华大学毕业后加入爱立信，五年后加入一个美国硅谷云计算公司担任商业智能组负责人，2012年加入唱吧服务至今，现在是唱吧线上研发部门的技术负责人。再唱吧技术团队从0到1的过程中，他以小而精的团队管理理念，运用精英化、非预期性奖金的管理方法，是技术团队以强大的内聚力而著称。

技术与产品之间是合作的关系。产品作为设计，技术去构建。但是产品和技术，一个是消费者，一个生产者，二者本身就是一个对立的关系。所以当生产出来了东西，消费跟不上，产品会觉得技术能力不够大；当技术做出来东西，不好卖，不好用，技术会觉得产品设计的不好。这种对立现象经常会出现，产品设计的一些方案，技术上不好实现，产品会觉得技术能力太差，而技术说设计得本来就不合理。两者中间有时候在需求上会取一个平衡。但是当遇到运营、市场活动的时候，产品和技术是互帮互助的关系。

黄全能认为产品与技术之间实现共同协助，有以下几点：

技术需要理解产品方向

有些公司的产品，真的把技术当成一个外包团队，类似施工团队，产品指哪里，技术就要做哪里，但其实产品方向对员工的士气才是重要。产品与技术之间不做任何沟通，不告诉技术方向的时候，技术根本看不出来产品的意义在哪儿。

其次，代码的架构上。产品的方向是什么，可能其自身也没有想好，在这个茫然的阶段，技术根本就不知道下面的数据库、接口、架构怎么去搭比较好。

***是技术储备。很多时候产品不敢匆忙上线，是因为知道技术可能现在这个阶段还未完成，技术储备还没做好。但是技术如果不理解产品方向的话，也会说产品还没提需求，可以去做点儿小优化，而不是投入到更多前面的发展当中去。

技术很大的一部分职责是和产品沟通方向，给自己的技术规划路线。技术的学习需要方向，所以了解产品方向非常重要。

技术应该理解产品细节

除了要理解方向，还应有一个文档把产品与技术间的交互完整的记录下来，也叫产品细节。作为技术，在一些小的细节上真的需要很好的把控，原因其实就在以下三点。

***个是架构的选择。因为方向定下来了，虽然细节对架构面的影响会小一点，但是实际上也有可能会影响一些动画的处理，包括一些图层的展示。如果不关注细节，就不会猜到产品会往哪个方向改。包括API接口其实也一样的，有些API，细节其实会影响到跟服务器的交互，服务器又会影响到怎么存储，缓存之类的东西，都可能能处理掉。

第二个是产品的质量。IOS、安卓很多地方要交互，有时候遇到不一致，包括测试也是安卓的测安卓，IOS测IOS，如果没有做加大测试的话，有的就会出现不一致。产品经理可能从大的功能去着手，可能在一些小的交互上或者体系上并没有看到问题，这样就会出现一些产品质量的小问题。技术如果不能理解细节的话，就没有办法帮产品打掩护，很有可能就蹦出一些小的、没有处理过的问题，比如该弹出的错误提示就没有弹出来，等等。

第三个是产品的bug。如果一开始不去理解产品细节的话，这个问题会经常出现，产品本身做得很复杂，产品经理对整个产品全局不是很熟悉的情况下，基本上会出现三种情况。***就是功能丢失，下个版本把上一个版本换了种做法，但是丢了一小块儿功能，没做全，要么就是页面不一致，改了样式去展现。还有一些逻辑矛盾的地方，比如封号后用户还可以从别的地方把评论发出来，像这种产品的bug需要有人去维护。

技术应该理解产品困难

技术一定要去关注产品，要知道产品怎么想的，当技术觉得跟产品想法不一致或者产品对技术会造成困难，甚至对非技术的业务造成困难的时候，要及时地指出这些东西。唱吧的技术会直接挑战产品的一些思路、设计，需求，包括为什么要这么做。虽然此时特别容易剑拔弩张，如何避免交火，其实是相互要做一些理解。其中一部分的理解就是技术要理解产品的一些困难。

产品和技术最不一样的地方在于产品有很大的主观性。不是所有产品都可以数字化驱动的；有些产品的判断无法进行AB测试。所以意识上要理解产品的某些猜测，并减少无根据的挑衅。除了主观性之外，另外就是一个试错性，产品有时候自己也不知道主观想象的东西到底好不好，应该允许产品的某种试错性，并给出试错周期。技术上给予配合，尽可能提供灵活的方案；一些想法可能早期有意义，但会迅速过时。

技术应该鞭策产品进步

在有些公司，产品是产品经理内部团队之间去进行一种交流成果。技术要认识到产品哪些方面是可以去进行挑战的。主观性产品容易加入太多；产品会不断地加这种试错，浪费试错成本；粗糙的设计会影响产品质量。试错的成本其实试很大的，一个是用户成本，如果方案不好，导致用户流失，还有一个是机会成本，迭代时做别的事情，该涌进来的用户没有涌进来，该挽留的用户也没挽留住。然后是研发成本，大量的开发成本、维护成本都是很重要的，不能***地主观，不能***地试错。至于粗糙的设计会影响产品质量，这点一定要跟产品经理讲清楚。很多产品觉得产品稍微粗糙一点没有太多用户在意，但其实产品设计的粗糙不禁影响架构，各种奇怪的状态、各种hack展示、各种不必要的服务器压力，而且会影响代码风格。

技术应该监控产品问题

产品经理往往是孤独的，这时候同一模块的技术开发和测试，才是产品经理的同盟军。

技术应该主动收集数据、添加统计、预埋日志。

建立技术与产品之间的信任

给双方以机会，建立适合自己公司团队实力的权力平衡。可以有这样的两个体系：产品经理的威信评价体系和技术伙伴的能力评价体系，分别针对产品与技术之间的情况进行打分。其实产品经理很难做KPI，因为产品经理的综合评价很难量化的那么清晰，更多是看产品的迭代之后会是一个什么样的情况.

打造具有产品观的技术团队

如果想建立有产品观的技术的话，技术至少必须满足三点。大局观，为产品未来的可能做好准备；逻辑性，发现产品的bug，敢于质疑产品的方向；主动性，主动预留的一些功能，为产品填坑。还有一个加分项，美感，好的技术对美感有天然的评价和认识。好的技术追求代码架构的干净、完整以及扩展，同样在产品上有自己的观点。

建立健康的工作流程

 

给产品以足够的空间，建立合适的防火墙，但必须让产品传达其意图，为技术解惑。

建立技术与产品的反馈机制

本文转载自网络，原文链接：http://x.51cto.com
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！