产品与技术：从相杀到相爱是一种怎样的体验？ ｜线上分享
为了加深EGO会员之间的相互了解，同时也为更多的技术人提供相互学习交流的机会，EGO开展了每周四21:00的线上分享活动。本文根据郭理靖 6月23日线上分享内容整理而成。
第十五期嘉宾：郭理靖
EGO会员，目前担任北京简网CTO，负责产品与技术部门。十二年互联网、六年云计算行业开发经验，曾任北京同仁堂国际CTO、京东云平台高级总监。
据说全球每天发生12万6423次需求变更，造成了1243万行代码废弃，影响了50万程序员的情绪，导致500个家庭的破裂。而每个IDC的机房里，有95%的代码都没有被执行，这些被遗弃的代码对拥在CPU怀里的同类发出怒恨的声音，被运维工程师称之为Codemourne。
产品经理就像女人一样，需求如同她的心情，每天都有新的变化。
————byBetaCat
最近五年多的工作中，我所管理的团队都包括产品与技术这两个角色，因此对这两个角色也有一些了解。同时我做过一些失败的产品，也做过一些相对还行的产品，对失败的经验进行一些总结，对一些做的好的方法进行提炼，希望对大家后面的工作能起到借鉴的意义。
产品与技术的思维方式
对于产品与技术的思维方式的区别，我们可以用简单的一句话来描述：产品是一个发现问题、定义问题的人，而技术是一个会利用不同手段解决问题的人。发现问题的人需要敏锐的观察力、旺盛的好奇心和卓越的猜测力，而解决问题的人需要扎实的知识、广阔的视野以及能灵活的利用各项工具。
当然，产品与技术的思维方式其实是有共性的，大家都有比较严谨的逻辑性思维。一般来说，技术的严谨性会稍微强一些，它经常能帮产品完善逻辑流程(功能流程图)。我下午画了一个表格，简单分析了产品和技术在不同角度的能力的差异：
5分制，指数并不绝对，只是我想描述一下差别。在发散性和用户的同理心上，技术和产品的差异是比较大的。当然这个表格不是要表达说产品比技术重要，相应的比较项也是比较偏向于产品经理的技术树的。这也是容易造成大家后面有分歧的原因。
对产品经理而言，人生的烦恼就是技术说这个实现不了、那个实现不了、只能改成那样了，嫌弃技术水平烂。
对技术人员而言，人生的烦恼就是产品原型太粗略，结果这里少一个逻辑，那里少一个文案，嫌弃产品考虑不周全。
对产品与技术而言，人生最大的烦恼就是运营说：我靠，你们做的东西不是我想要的，我们的需求其实是@￥%￥%@￥。
效率低下的深层次原因
我见到过很多团队和公司，聊天的时候，我发现没有几个CEO和Leader对自己的团队工作效率是特别满意的（资本家心态)。很多人都说，我们做的太慢了、功能更新的太慢了、迭代的太慢了，为什么一个简单的功能要整那么久呢？我们先来谈一个简单的案例，以下故事纯属虚拟，如有雷同，纯属巧合：
A公司是一家做电商类服务的，刚刚开始开发产品，CEO说我们的产品要简洁好用（老板说的都是对的），于是产品经理决定从用户注册登录入手。鉴于现在的用户都比较反感注册，我们就只用第三方授权登录来减轻用户注册的负担，这年头谁没有个微信、微博啊，我们就支持微信和微博的第三方登录就可以了。
哐当~~~产品上线，市场推广很给力，一下子拉了很多用户上来。但是用户反馈怎么没有QQ登录啊，这个得加上；怎么没有淘宝登录啊，这个得加上；怎么没有豆瓣登录啊，这个得加上。产品说：我们得增加更多第三方登录，技术一听，行吧，就用第三方组件把业界知名的第三方登录全加上了。上线了，登录页下面全是密密麻麻的第三方授权图标，产品说太多图标了，我们只展现第三方授权，其它的授权放到更多里面，于是又改了一版。
运营了一段时间，发现了下面几个严重的问题：
1. 用户有时候忘了自己到底是用哪个授权进来的，重新登录的时候选错了授权，发现自己的订单没有，暴怒，打客服电话狂投诉：你们技术怎么这么烂，把我的订单都搞没了。
2. 安卓版本App信息的到达率低，整体APP信息打开率比较低。
3. 辛辛苦苦获取的用户用过一次后就删除App，再也没法做召回了。
经产品和运营讨论研究决定，所有用户要绑定手机号码。新用户注册需要直接绑定，老用户引导绑定手机号码。技术一听好吧，绑定手机号码对业务有很多帮助，那得做。嗯，老版本的兼容器都保证。同一个用户，历史用过不同的第三方授权账号如何处理？给用户发送消息的时候，如果用户没有手机号码如何处理？于是很多关于用户的环节上，都加上了相应的逻辑判断，而且还要给运营和产品统计用户手机号码的绑定率。
于是好多逻辑的代码要加上，也多了很多test case, 整体的工作量就上来了。但是CEO就体会不到这些工作量，不就是加个手机号码嘛，怎么这个功能要搞这么久？不就是数据库里多搞个字段嘛？一个团队工作“效率低”（这只是表象，其实产品和技术都累的像狗一样，每天其实都不得闲，）会有很多种原因，我把我经历过的总结一下：
1. 持续性打补丁式的开发。补丁越来越多，代码越来越难读懂，业务逻辑越来越难理解，除了亲手写的人，没有人明白是怎么回事，维护起来也特别困难。
2. 持续性的无文档开发。所有资料图表都口口相传，在前期冲刺阶段，因为团队成员的相对默契，心有灵犀一点通，不用写详细的PRD、不用对API文档的返回值和错误做解释、不需要数据字典，这可能还行。但是对新加入的成员来说，学习成本就过高了，产品的原型是有，但是产品逻辑图非常粗糙，各种细节与方案需要技术脑补。
3. 前期利用了第三方的开发组件、服务和开源代码，在业务出现新变化和需求的时候，从技术的角度无法得到满足，用户诉求的功能迟迟无法实现。产品在设计一些新的需求的时候可能对这些第三方了解不多，导致需求做不了，而又或者对这些功能了解的太少，不知道如何利用这个第三方服务来加速产品功能。比如功能A虽然不是那么紧急，但是如果利用第三方的一个功能半天就能完成的话，这在ROI上讲是非常划算，也是值得做的。
4. 技术团队整体有短板。整体的技术栈链条其实是很长的，移动端、前端、API、负载均衡、防攻击、数据库、日志分析、数据报表等等，比如整个团队没有懂数据库的人才，出现数据库问题的时候就一筹莫展了。
5. 信息不够透明开放。有些事情在群里、QQ或邮件里说了就算了，信息并没有对全部人员开放。大家看到一个事情的前因后果，不知道事情的进展如何。这种情况经常发生，特别是在产品有一个小需求需要改动的时候，可能就并没有落在纸面上，而是碰到开发就口头说了。很多人会有这个思维惯性：以为自己开口说了，全世界人民都是应该知道这个事的。这个说法看上去很蠢，实际上你总会碰到这样的同学。
6. 产品设计其实缺乏前瞻性。对未来的需要没有考虑到位，导致后续改版成本居高不下。
7. 其实大家都没有搞清楚我们到底要做个什么样的东西、到底能不能产生价值，但是基于公司运行三大定律之“不能闲下来”的基本原则，那就先开搞再说了~
小步快跑有多难？
我们总说互联网节奏要求快，要小步快跑，快速进入市场、验证产品、收集反馈需求再迭代改进。在实操上，小步快跑难度其实远超我们的预期。在小步快跑的路上，不知道有多少团队死在体力不支上。下面谈几点我个人觉得要注意的地方：
1. 保持产品主干线逻辑大体不变。这个真的没啥好讲的，连这个都变了，代码那绝对是废了。
2. 产品迭代周期的良好把控。WEB前端以及后台的产品迭代周期是可以比较快的、风险相对可控，有了beta环境和回滚机制，基本上就问题不大。但是对移动端的产品来说，多久的一个更新周期是比较合理的呢？每个更新周期内应该做什么样的功能才会让用户有惊喜感，让用户觉得整个团队是在不断进步的呢？每一次的移动端的版本更新都会带来日活的小增长，但是太频繁的更新也会让用户觉得反感。而在之前iOS上架更新动不动就需要2周时间的情况下，如何把控安卓、iOS的进度特别是让iOS能有提前量，这些都是产品迭代特别需要注意的。
产品功能尽量分期迭代。产品着重细化当期的各种逻辑细节，但是让技术能够看到整个产品的全貌，而不是管中窥豹，知其然而不知其所以然。产品可以和技术一起规划一期、二期甚至三期的功能以及期望达到目标，迭代的过程真心可以采用MVP的思想。
3. 如何带着脚链跳舞。开发新功能的时候还需要填老功能的坑，技术要合理的分配时间，产品也要给技术留有一定的余量，很多项目的延期和矛盾的产生就是在于没有给开发留出一些时间余量地解决历史问题。技术对于产品的新功能需求，使用的第三方服务不支持想要的特性，也要多开脑洞想想如何搞（办法总比困难多），尽量避免说做不了、实现不了，要多提提有没有好的替代方案。
4. 新功能的ROI要衡量，产品要数据化运营。对于新的功能，我们还都是要做数据采集的埋点。对一些重大的功能，都需要做AB test. 数据化的采集在产品的中后期极其重点，前期真的可以靠产品的直觉出发，但是中后期还是要靠数据说话。有数据在手，产品也更能够容易证明自己的想法是对的。
产品对技术的方法要晓之以情、动之以理，毕竟技术还是冲锋陷阵战斗在第一线的人员，要做好关怀工作。而且对技术人员而言，做出来的东西，运营数据非常好看，那是最好的激励。
5. 性能与功能的权衡得失。比如在首页加更多的内容或者App启动多调用几个API，这必然会带来性能上的损失。其实在这一点上，经验不是很丰富的团队比较容易犯这样的错误。产品经理光顾着增加新的功能，技术也顾着功能的实现，于是导致用户的体验变差了，反而降低了留存，出现这样的问题有时候还很难被发现，如果团队在一开始的时候就对用户行为有详细的收集，对服务的质量有详细的记录，那就可能比较容易对问题进行定位。
天下武功，唯快不破，应用越快的响应对用户留存是一定有正向作用的。
6. 老版本兼容性问题。维护过API 1.0 、API 2.0 、API 3.0的同学说出来都是泪啊，（API是技术设计的产品）API这个种东西一旦放出去，就别想着有一天能够一次性的搞定。每一次API的强制升级都会经历腥风血雨，每当你正式关闭一个服务的API时，指不定又冒出来几个调用方说你的API影响到我的服务了。同时你永远不知道还有没有如幽灵般的App用户还在使用极其古老的版本。所以，版本管理要做在前面，产品设计时要尽量保证前后的一致性，避免动不动就来一个全部强制升级的事情。
反正我是比较讨厌那些一定要我升级App才能让我使用的App（12306除外，我很有耐心等待它的升级）。
如何形成正循环？
正循环的形成单单靠产品与技术这两个角色是不够的，这两个点只能构成直线，三个点才能构成稳定的三角形。想形成正循环，还得有运营的角色。
1. 需求宽进严出。相信我不管是在哪家公司，不管是在公司的哪个阶段，需求是永远做不完的。
2. 产品评审严格进行。在我看来其实这一块有点难度，有时候大家面对一个基本的产品原型，很难静下心来想产品的细节（也许细节太多了，想想就很烦），反正开了那么多场产品评审会，越严格、讨论越多的会，后面开发的效率越高，反之亦然。
3. 验收流程完善。技术提交测试，测试交付产品，产品验收交付运营进行内部体验。面向用户的产品，内部还是要深度消化过后才能上线上架
4. 工具、规范、分析做在前面。虽然有时候感觉会浪费时间，但是不去花时间思考更好地把事情做好的话，反而会造成更大的浪费。这世上有多少事输在谋定而后动，磨刀不误砍柴工这两句话上。
5. 良好而且充分的沟通。这也是最重要的一点。 结伙创业，一起共事就和搭伙过日子一样，话说互联网的大部分人和同事在一起的时间比和老婆在一起的时间还要长。技术与产品其实就像两口子，吵架的原因很多是因为：我那么爱你，你怎么还不能理解我的意思与痛苦呢？