开发工程师的产品素养
星爷的九品芝麻官里，有这样一段很经典的台词：“贪官奸，清官要更奸！要不然，怎么斗得过贪官！”
以这段台词开篇，绝没有想要挑拨产品与开发内斗的意思，只是想表明一个观点：“优秀的工程师有时要比产品经理更了解产品的流程和细节！”开发工程师如果是两耳不闻窗外事，一心埋头写功能，很难在互联网公司有好的发展。只有既懂产品，又懂开发的人，才能更出色的完成自己的工作！接下来我们就聊聊工程师应该有的一些产品常识。
抄袭并不可耻，但姿势要对！
我们工作中经常会遇到这样的场景，产品经理给工程师描述一个有些复杂的需求，工程师还不是很理解，产品经理就掏出手机，打开一个第三方的应用说：“我要的功能就是这样啦...”
这并没有什么问题，模仿成熟的功能并在此基础上进行改进，是很好的起步方式。但是抄袭的时候要想明白，抄来这个功能是不是真正满足了你们用户的需求？这个功能为什么做成现在这个样子？如果只是单纯的照搬别人的功能，不做任何思考，就不知道这么做是为什么，迭代的时候也就不知道该如何改进了。
我经常用上图来回答一个常见的产品问题：“为什么同样的功能，在别的APP上反响很好，而我们做了就完全没人用呢？”
这张图想表达的是：企业家杂志的封面人物，西装都穿的笔挺笔挺的，非常有气质，为什么我们一穿西装，哪怕是定做的，也无法达到这样的效果？这都是背后这一排排的夹子的功劳呀！只看到别人表面上的光鲜，看不到别人背后付出的思考和努力，是永远做不出同样的效果的！
差的抄袭是不假思索的把产品经理自己喜欢的功能或者是公司希望用户使用的功能，一股脑的塞给用户。用户不买帐还一脸委屈的说：“我把我能想到的都给你们了， 为什么你们还不喜欢呢！”这样的产品经理常常被自己的努力感动，却很少打动用户...
而好的抄袭应该是在深入分析自己产品解决的问题、使用的场景和用户特点的基础上，不断关注有哪些新的功能可以更好的为用户创造价值。当年微信在强关系高频次即时通讯工具的基础上，引入类Path的朋友圈玩法，既满足了发布者表达（炫耀）的需求，又满足了朋友之间相互了解近况（窥视）的需求，从而做到了野蛮生长， 成为了目前的流量巨兽，吞噬了手机超过一半的电量和流量！反观Path，因为没有足够高频的功能来支撑它培养用户进行社交的习惯，最终慢慢被人遗忘...
很荣幸有机会和几个腾讯的产品经理深入交流过他们“解构”一款竞争对手产品的过程。首先，他们会从“界面-交互-功能、用户需求-使用场景-心里诉求、核心策略-关键数据-迭代过程”等角度一层层对竞品进行拆解分析，然后重新设计这款产品，再将重新设计的产品与竞品进行对比，看看那些地方相同，那些地方不同，不同的地方是新方案更好还是原方案更优再择优选取，最终才能做到青出于蓝的效果，这才是正确的抄袭姿势嘛！
曾经有个产品团队“解构”我做过的一款应用，把我们所有的功能和页面全部重新制作了成了一个带完整交互原型文件，做的比我们自己的原型质量还高（我们是一步步做到最终的形态的，所以原型文件很零散），我直接就跪了...
好的产品迭代策略，应该是在保持系统可用的基础上，持续改进和迭代
移动互联网产品开发是一件风险非常高的事情，没有一个人能够仅仅凭借自己的天赋就做出完全符合用户需求的产品，只有通过将产品投放到市场上，从用户的行为和反馈中收集信息，然后不断的改进和迭代，才能以最小的成本找到正确的方向！一群人关在小黑屋里闭门造车，上线之后就风靡世界的时代，早已经一去不复返了！
上图中造汽车的例子，本质上要解决的问题是“帮助用户通过更省力的方式达到目的地”。
第一种迭代策略是构想好最终目标，然后一个组件一个组件的叠加（造完轮子造底盘，造完地盘造顶棚，然后装车门，但是发动机装进去之前，永远不能动...），直到汽车被造出来之前，没人知道那东西有什么用！也许等汽车造出来之后，会因为太过超前无法被大众接受，而更加有可能的是，汽车还没造出来，大家却因为迟迟看不到希望，已经早早放弃了。
第二种迭代方式则不然，过程中的每一个版本都是可以解决用户的问题，每一次迭代都是对前一代产品的升级（用滑板变滑动摩擦力为滚动摩擦力，加入方向控制系统的滑板车降低了学习门槛，增加轮胎直径的自行车提高了速度，引入发动机的摩托车更加省力，将人包裹在内的汽车大幅提高了舒适度和安全性！），用户的需求在一次次的迭代中被更好的满足，团队也能够在用户的使用行为和反馈中，不断的获得改进和迭代的灵感，从而更容易取得最后的成功。
第一次看到这张图的时候，就深深的认同第二种迭代的策略！产品经理在做产品规划的时候，往往需要进入一个理想的状态，暂时忽略的所有的限制（技术、资金、用户量、运营能力等），设想出产品达到最佳状态的时候该是什么样子，这是一个很自然的过程，也是产品经理该具备的基本的能力。但是当真正落地执行的时候，一定要从理想状态走出来，保证过程中的每一个版本都可用，每一次迭代都是从一种可用的形态进入另一种可用的形态，这才是最好的改进和迭代的方式。
忽略使用场景去解决用户需求，大多是隔靴搔痒
普通的产品经理通常是从需求出发，结合用户的特点去设计功能满足用户的需求，而往往会忽略用户使用功能的场景。这样设计出来的功能往往是差强人意，很难给用户惊喜！
微信摇一摇识别歌曲这个功能，刚开发出来的时候，我记得是以卡片的形式给出歌曲的名字和演唱者，点击卡片进入歌曲的详情页并开始播放。这样的功能设计确实解决了用户想知道当前环境里听到的歌曲是什么的需求，但是，还能不能做的更好？
最近一次使用这个功能，当歌曲被成功识别后，直接进入了歌曲详情页，然后将歌词快速滚动到环境中歌曲播放到的位置，再同步滚动！！！中文歌看着歌词就能跟着唱两句，英文歌还能看到英文歌词对应的中文翻译，方便的了解唱的到底是什么！！！我瞬间就被这个功能击穿了，太牛逼了，这才是优秀的产品经理嘛！
这就是充分的考虑了用户在使用这个功能时候的场景（这首歌挺好听的嘛，叫什么？谁唱的？是快唱完了，还是刚开始？这首外文歌唱的是什么？），才达到了给用户惊喜，甚至击穿用户的效果！
没有配套推广和运营计划的新需求，基本没戏！
普通的产品经理最喜欢设计出一个功能，就催着开发加班加点的做出来上线，然后祈祷美好的事情自然而然的发生...美好的事情哪儿那么容易发生呀！
产品、推广、运营，三者的关系是相辅相成的，产品解决的问题越高频刚需（操作系统、微信等），推广和运营就越轻松；如果产品的研发门槛较低频次又不是那么高（打车、外卖等），那就需要在推广和运营上发力来培养用户习惯，建立门槛。
哪怕是做个以传播为目的的功能，也要根据它的传播能力计算出需要的启动流量，杜蕾斯的营销创意再好，没有几百万的粉丝，也很难做到每条创意都在朋友圈大量传播，更别说脸萌、足记、冰桶挑战了，他们在启动的时候一定都是配合非常全面的推广和运营策略（从哪些人群启动，需要多少启动用户量，配套哪些媒体的报道和推荐，出现快速扩散的趋势之后，要不要在配套的刷个榜单等），才能做到刷爆朋友圈的！
要相信数据分析，但是不能迷信！
数据分析在产品改进和迭代的过程中是非常重要的，它能让我们更好的看到产品各项功能的使用情况，更好的进行决策，而不是全靠拍脑袋来做决定。
但数据有时候并不是那么的客观准确的，记得在某本讲产品的书上，看到了这样一句话：“数据分析得到的结论就像穿着比基尼的美女，露出来的地方确实很性感，但是遮住的地方才是关键所在！”我非常认同这个观点，数据分析只能体现出部分情况，想了解全部的情况，用户调研是必不可少的。
我们基于微信服务号做的一款产品，从数据统计平台看到提交注册信息页面的流失率高达70%以上，当时看到这个数据的时候吓坏了，认为是提交注册信息页面做得过于复杂，导致用户不愿意注册从而造成了大量的流失。所以就开始大刀阔斧的删减提交注册信息页面需要填写的内容（去掉了名片上传、延长了短信验证码的有效期等），从接近十个字段删减到只需要填写四个字段，然后继续观察统计平台注册页面的用户流失数据，却没有任何好转，这流失率每天得损失多少注册用户呀！直到后来我们邀请了几个新用户来测试产品，在旁边观察他们的操作，才发现真正出问题的原因是我们注册完成页面没有和后续的功能打通，变成了一个孤立的页面，而微信想关闭当前的页面需要向前返回一次，才会出现关闭按钮，这就导致一大批成功注册的用户，为了关闭当前页面，只好返回到提交注册信息页面在关闭，从而被统计成了注册提交页面流失的用户！虽然是虚惊一场，但是这个案例告诉我们，数据分析一定要结合产品场景和用户行为，才能得到正确的结论。
产品应该是一切可以解决问题的方法，而不是一定要开发APP或者WEB
前段时间被黑的很惨的那句“我有一个绝妙的创意和一个靠谱的团队，就差一个写代码的了！”，充分暴露了说这话的人完全就是个缺乏技术常识的外行，他缺的一定不是一个写代码的人，而是一整套技术体系！
同时这句话也暴露出了另外一个问题，就是很多的产品经理过分的依赖开发，认为只有通过开发APP或者WEB才能检验自己的想法是否可行，这也是不对的。
当有一个想法的时候，首先应该做的是寻找一切可以利用方案去测试自己想法的可行性。比如传统企业想做电商，那就先去天猫开个店，看看自己线上的推广运营能力能不能把销售量做上来，而不是先开发个漏洞百出的电商网站，陷入各种技术的泥潭！等真的在天猫把销量做起来了之后，再考虑为了减少被天猫分去的利润，慢慢建设自己的电商网站，然后通过在非自有渠道的商品包装中投放自有渠道的代金券来进行转化，成功率要高的多。
我们之前帮一家酒店集团做官方APP的时候，做了一个入住用户评论的功能，在收集了一些入住的评论之后，产品经理就来找我说能不能做个评论的智能语义分析系统，从用户的评论中分析出哪些是正面的评价，哪些是负面的评价，哪些是针对基础设施的评价，哪些是针对服务的评价等，再将这些分类后的评论信息推送给酒店的经营者。
需求确实是好需求，但是我反问了产品经理一个问题：“你们每天能收集到多少条评论？”
产品经理：“少的时候几十条，多的时候一百多吧。”
我：“去招个实习生人工分类吧，又快又好，比我们短时间那开发出来的语义分析系统靠谱的多，而且还能出去吹这是通过生物智能识别技术实现的！等每天的评论数过千了，我们再来做语义分析系统吧，现在就开发不是在用大炮打蚊子嘛！”
在网上看到的一个例子，一家酒店前台向单个入住的客人推荐他们的超级大床房（2.4米宽的床），客人听了之后都很有兴趣愿意尝试一下，整体的入住反馈都很好。这家酒店是怎么做到的呢？他们只是把没卖出去的标准间里的两张1.2米的床，拼成了一张2.4米的大床，然后换上2.4米的床上用品...太智慧了！如果这家酒店一定要走标准的流程，真的去采购2.4米的大床，最后如果客人的反馈良好还行，如果反馈不好，那这些2.4米的大床不全白买了嘛！
所以说，产品应该是一切可以解决问题的方法，先用现有的资源尽可能的去测试方法的可行性，而不是过早的投入昂贵的研发资源！研发资源应该是在方法确认有效之后，提供更好的体验和更高的效率。
不知不觉又啰嗦了这么多，这篇是之前《产品经理的技术素养》的后续，这样我以后出去分享的时候，工程师为主就讲《开发工程师的产品素养》，产品经理为主就讲《产品经理的技术素养》，这样我这个既不怎么写代码，又不怎么做原型的水货，就很难被打脸了，哈哈哈！
作者：LeapRuby开发者，系统架构师，鹰漠旅行CTO，产品经理，连续创业者...
