数十万互联网从业者的共同关注！
数十万互联网从业者的共同关注！
小早说：特别感谢12.31早读课广州线下沙龙三位特邀嘉宾，Leap、大卫、李龙的精彩分享，分享结束后小伙伴们都觉得收获满满，心情大好！
本文是第一位特邀嘉宾Leap的分享精华（感谢Leap把分享内容整理成文）。作为一个从技术转产品、做过CEO的CTO，Leap把压箱底的货都给小伙伴们分享了，从技术常识到跟程序员沟通的技巧，这么干的货很少见了，果断收藏！
作者：Leap。作者授权早读课发表，转载请联系作者。
微信号：谱曰(ID:puyue365)。
编辑：Verna。
欢迎投稿到早读课，投稿邮箱：[email protected]
经常有产品经理问我：产品经理到底需不需要懂技术？
我：你觉得呢？
他：需要吧？
我：产品经理对需求负责，你觉得自己有懂技术的需求吗？
他：有啊，懂技术后能让需求更符合实际情况，更好的根开发沟通，更好的评估开发需要的时间，还能在功能和性能之间找到平衡点...
我：那还不赶快去学！
他：你能教教我么？
我：原来你在这等着我...
于是，就有了这篇文章：产品经理的技术素养。
当下ToC的创业项目，要么是守着iOS和Android平台做APP，要么是守着微信平台做HTML5的应用，所以就讲讲这两个领域的开发常识吧。
一、APP 开发常识
1. APP能稳定运行是对客户端开发的最低要求，没的商量！
任何的客户端闪退和卡死都是客户端开发的错，也许他们会说这是因为服务器返回结果的格式不对呀，或是返回的数据里面有脏数据呀，或是网络异常导致的呀......但是我要告诉你们，这都不是客户端闪退或卡死的理由！返回格式不对，友好的提示下就好了呀，脏数据过滤掉呀，网路异常就超时结束请求，提示用户网路有问题就好了呀，闪退或卡死就是客户端没处理好！
理论上，哪怕是服务端所在的机房炸了，客户端也应该是除了不能读取新的数据，其他功能都可以正常运行，这才是优秀的APP该有的素质（你们自己关闭网络，然后用微信感受下）！
2. 所有的闪退都要收集回来并解决！
再完善的测试，也无法做到将所有的情况都考虑到，特别是在复杂变的手机端。所以对于APP影响最大的闪退，一定要借助第三方平台对所有闪退的异常进行完整收集！这里的完整是指系统平台（iOS&Android），应用版本，程序的报错描述，引发闪退的相关数据等，这些信息可以帮助开发快速的定位出错的位置，减少开发说我这里重现不了，没办法解决的情况，对于解决闪退非常有帮助。
推荐两个用户量比较多的闪退监控平台，方便你们选择吧：
1. Fabric(twitter维护)
2. BugTags(国内团队维护)
3. 热修复技术：线上严重故障的救命稻草！
这个技术主要是解决应用上线之后，在主干流程上发现严重BUG，例如闪退或者数据加载出错等问题。以前遇到的这样的问题，就只能紧急修复并发版，一面安排运营安抚用户，另一面祈祷各大市场赶快帮忙通过审核，相当的狼狈。现在有了热修复技术，可以通过在应用启动的时候，从网上下载一段代码到本地，替换掉本地有问题的代码，从而达到无需发版就能修复严重BUG的效果，有效的保证产品的稳定性。
推荐几个常用的热修复解决方案：
1. iOS平台下阿Bang同学的JSPatch相当的靠谱，微信都在用。
2. Android平台下阿里维护的AndFix也是个不错的选择。
4. Andriod的兼容与适配
Android开发最繁琐地方，莫过于适配各种屏幕尺寸和兼容各种厂商修改过的系统了。建议上线前优先适配主流机型，上线后重点适配你应用的用户使用最多的机型，并结合前面提到的闪退收集和热修复技术，保证应用的稳定性。
5. iOS的内测分发与审核
iOS应用做有一定规模的内测分发是一件挺麻烦的事情，如果你用的是99美元的开发者账户，就只能通过一个个的添加测试用户手机的UDID，才能进行呢测。更好的办法是申请一个299美元的企业开发者账号，使用这个账号的证书打包的应用可以自由分发，再结合一些分发平台（fir.im或者蒲公英等），可以非常方便进行千人规模的内测，获得更多的用户反馈。
但是，申请企业开发者账号是需要提供企业的邓白氏编码才能申请，然而由于国内很多第三方苹果市场对企业开发者账号的滥用（所谓的免越狱安装应用，就是靠使用企业开发者账号打包实现的），导致苹果对大陆地区企业账号审核的越来越严格，一度淘宝上一个企业开发者账号都炒到了10W＋，所以有一定规模内测需求的项目，初期就开始申请企业开发者账号吧，因为一般需要一两个月才能搞定。
6. 客户端和服务端都可以做的功能，大多数情况下建议在服务端实现
项目推进的过程中，经常会遇到有些功能客户端也可以做，服务端也可以做的情况，这种情况下，大多数时候建议在服务端实现，这样有两个好处：
1. 核心逻辑只在服务端实现一次，不用在两个客户端平台都开发一遍，节省开发时间。
2. 如果有BUG，可以在服务端即时修改，而不需要重新发版。
举个例子，查看附近的人列表里，每条记录都有个距离的数值，这个距离在客户端计算也行，在服务端计算也行，但是在服务端计算并将结果直接返回给客户端可以保证数据的一致性，一方面减少由于客户端选用的GIS库不同，导致iOS算出来是1.81km，Andorid算出来是1.82km的诡异情况；另一方面如果计算出错，只要在服务器调整距离的算法，客户端自动就可以正确显示了。
二、微信&HTML5 开发常识
1. 微信授权登录
微信提供的应用授权登录作为目前最流行的第三方登录方式，基本已经成为应用的标配了，而相应的微信服务号提供的Web授权登录，也已经成为微信HTML5应用获取用户信息的利器，但是这里有一个坑，就是默认情况下，应用授权登录的返回的用户唯一标识（即OpenID）与Web授权登录返回的OpenID不一致，哪怕是同样的应用名称也是如此。解决办法是将你的服务号绑定到微信开放平台下，这样两种授权的返回信息中，会多一个统一的UnionID字断，用做用户的唯一标识。但是UnionID不能用于发送消息模版的需求，所以最终每个微信授权的用户，需要同时保存OpenID和UnionID，才能顺利的完成打通和后续的业务处理。
另外微信的授权登录有两个模式，基础授权和高级授权。前者的好处是用户无感知，但是只返回OpenID和UnionID；后者需要额外跳转一次页面进行授权，但是能拿到包括昵称、性别、城市等在内的完整的用户信息。这里有一个优化的技巧是当用户登录的时候，先使用基础授权登录的方式获取用用户的OpenID和UnionID，然后在你的用户信息中查询，如果该用户存在，则直接完成登录；如果该用户不存在，再跳转到高级授权登录，获取完整的用户信息并保存，这样这个用户再下次登录的时候，就不需要使用高级授权登录了，直接通过基础授权即可无跳转的完成登录。
2. 防欺诈提示
经常会在各种微信里的Web页面中，看到上方这个红色的防欺诈提示，包括一些知名平台的服务号也是如此。其实这个提示是可以去掉的，只要你的服务号通过了支付功能的审核，将页面的域名设置到业务域名的位置，就可以去掉这个提示了，如下图所示：
3. 运营商劫持
现在的运营商劫持，已经流氓到令人发指的地步了，左图底部的banner广告，有图中间的弹窗通知，已经严重影响到了用户的体验。目前对于运营商劫持，最好的解决办法是使用HTTPS协议的部署你的Web服务，这样信息在传输过程中是加密的，运营商就很难再进行劫持和嵌入广告了。
4. 网络出错
最后再分享个疑难杂症，在微信里打开Web页面的时候，偶尔会遇到这样一种情况，就是页面无法打开，微信提示网络出错，点击重新加载多次依然如此，吓得产品经理以为系统挂了！但是让开发去查，开发却说服务器根本连你这个请求的没收到，跟系统没关系！一边用户反馈打不开，一边开发说跟他们没关系，产品经理卡在中间，真是日了X了！
这种情况呢，绝大多数是因为微信内置的浏览器缓存了一个错误的DNS解析结果，导致请求无法发送到服务器，从而一直无法打开。解决的办法也很简单，切换下网络（4G就切到WIFI，反义亦然），重新解析下域名，就可以正常访问了。
通用常识
1. 一些文本推送的长度限制
一条短信最多70个字，如果内容超长，虽然会被智能手机合并成一条信息展示给用户，但是运营商计算是按照70个字一条进行拆分的，所以处于成本的考虑，还是将短信的文案控制在70个字以内吧。
主要的应用推送服务（包括苹果和Android的第三方推送服务），用来承载内容的空间一般也就是256个字节（utf-8编码下，一个汉字占三个字节），超过的话会发送失败。如果遇到有些推送能收到，有些推送收不到的情况，很可能就是文案超长了，可以检查下。
微信服务号推送的客服信息不能超过2048个字节，并且用户与服务号之间48小时内要有互动，否则会发送失败。
2. 使用云服务
别再用Excel管理项目了！别再自己找机房买服务器了！别再自己搞文件存储了！别再自己开发统计分析系统了！现在有大量的优质的云服务，可以大幅的提高创业团队的效率，果断用起来吧！
推荐一些不错云服务给你们：
项目管理：TeamBition、Tower；
云主机：阿里云、Ucloud；
消息推送：极光推送、个推；
短信：创蓝、螺丝帽；
云存储&CDN：七牛、又拍；
即时通讯：融云、环信；
代码托管：Coding、Bitbucket；
统计分析：友盟、腾讯分析；
3. 关于开发外包
如果实在招聘不到合适的开发人员，项目原型的开发可以找你信得过的朋友来做并付费。别老想着找人免费帮你做，适当的付费能大幅提高朋友的开发效率，从有空写写变成努力完成，绝对是双赢的！
如果找外包公司开发的话，找个你信得过的朋友做顾问，审核数据库的设计和核心代码，尽可能的避免项目发展过程中因为系统设计不当，导致需要推翻重来的风险。
另外，项目原型是用来快速验证想法的，不要过于追求细节，关注核心业务的功能即可，快速上线去检验你的商业模式才是关键。
4. 关于代码重构
产品经理经常听到开发要求对现有代码进行重构，这里的重构一方面是改进赶进度时写的低质量代码，另一方面是把一些通用的功能和模块进行抽象，方便后续开发。
建议每个月至少给开发留2个工作日进行代码重构吧。
一、最好掌握的技能
科学上网：网络世界哪么大，要常出去看看，毕竟Copy to China还是主流的创新模式...
数据库查询：项目初期运营系统还没有那么完善的时候，如果你会查询数据库，能大幅的提升数据分析的效率！
微调HTML/CSS：不需要会做复杂的前端布局，但是如果你可以对Web页面的样式进行微调，更容易做出最满意的效果，输出你自己的品味；
二、至少了解的概念
下面这些概念，如果你能了解他们的优势与不足，那么在与开发沟通和产品决策的时候，会有很大的帮助（例如之前提到的HTTPS能够解决运营商劫持的问题）：
一、如何提需求
差的方式
产品：我们需要做一个刷脸付款的功能，用户通过刷脸完成支付。
开发：人脸识别可靠性差，特征容易改变或者相同，在全球范围内都是难点，用来做支付太不安全了！
好的方式
产品：我们为了提高用户的荣耀感增加一个营销的口碑传播点，想做一个刷脸支付的功能，你们看看安全性方面有没有什么好的方案？这个功能使用的流程是......（过程描述略之）
开发：人脸识别可靠性差，最好加入一个二次确认的过程，例如微信上发条确认信息，用户确认一下，其它应该没什么问题。
抓到要点没？没有的话，看看我的总结吧：
1. 先讲需求背后的诉求，再讲需求的要点；
2. 提出需求要点中技术上的不确定部分，征询开发意见；
3. 最后再补充细节，并允许开发对细节进行合理的调整。
二、如何协商开发进度？
差的方式
产品：这个需求开发完成需要多少时间？
开发：一周
产品：要这么久？这个需求不是很复杂呀？
开发：这个需要XXXX...（一堆产品可能听不懂的术语）
产品：不用这么麻烦吧！
开发：你行你来做啊！
产品：好吧，那就一周吧...
好的方式
产品：这个需求开发完成需要多少时间？
开发：一周
产品：要这么久？那我们一起把这个需求拆分一下，拆分成几个一到两天内可以完成并测试的小需求吧。
开发：这个需求可以拆分成ABCD四个任务，A任务需要1天，B任务需要1天，C任务应该要2天，D任务需要1天。
产品：好的，就这么定了，我重新把这几个需求写到任务系统上。
抓到要点没？没有的话，继续看总结吧：
1. 尊重技术的评估，不要想当然；
2. 如果一个需求的开发时间超出了你的预期，就对需求进行拆分，每个需求的开发时间控制在两天以内，这样的好处是可以快速的了解到开发的进展，不断确认产出的结果是否是产品所需要的，避免一周后，发现开发和产品对需求的理解有很大的偏差而导致的延期。另外，如果真的是个非常简单的需求，开发根本无法进行分解，他自然会缩减时间的。
PS：别把开发进度逼的太紧，可能会影响系统质量..
三、如何报BUG？
差的方式
为什么我的账号不能登录呀？
好的方式
为什么我的账号不能登录呀？提示帐号密码错误！我测试的帐号是：cc123 密码是：123456，用的是苹果手机，安装的最新的版本！
刚刚测试的，相关信息我都写在TeamBition（Bug跟踪系统）上了，尽快处理下，这个BUG的优先级最高！
抓到要点没？没有的话，最后再帮你们的总结一次：
1. 提供稳定复现的流程和错误信息(最好有截图)；
2. 提供支持复现BUG的完整数据(相关帐号密码、测试的输入等)；
3. 提供准确的应用信息(应用版本、测试环境/正式环境 等)和平台信息(iOS、Android等)；
4. 明确BUG的紧急程度；
5. 将BUG录入到追踪系统，以防被忽略；
四、开发延期怎么办
开发没有按照约定的时间完成工作...
工期一天天的延期，你很焦虑...
怎么办？怎么？怎么办？
接受现实吧，轻度的Delay是难以避免的宿命！如果开发每次都特别准时的交工，那你们的开发一定在保留实力，并没有拼尽全力…
如果你每天上午到公司的时候，看见他们已经在对着你昨晚反馈的BUG冥思苦想了；每天晚上你离开的时候，他们还围在一起讨论解决方案...那么他们已经尽力了，但毕竟人力有穷尽，轻度的Delay代表他们对产品尽早完工的渴望和你一样强烈，对产品尽快上线和你一样的期待，才会让自己这么的辛苦的加班。
此时你能做的是，把优先级低的BUG整理好后，在每天的沟通会议上一起提交给他们，而不是一次次的打断他们；你还能做的是把当前节点里不太重要但是又比较复杂的功能，放进下一个节点，让他们能够专注在重点的功能。
但是，如果你的开发团队面对一天天Delay泰然自若，继续该迟到迟到，该早退早退...如果你不断的询问要延期到什么时候，但是并没有人能给出准确的答复！是时候找CEO和技术负责人一起好好的讨论下了，一个项目组人不多心还不齐，这项目不干也罢了。一个项目想要成事，一定是和一群能够前途相托，甚至性命相托人在一起，才有可能！
所以，产品经理对技术该了解到什么程度？
举个打车的例子吧：
产品经理相当于一个乘客，知道要去哪儿，开发团队就相当于是司机。产品经理可以不会开车，不会踩是离合器不会挂挡，但是如果他知道：1. 哪条路最短？2. 哪条路虽然绕一点但是最顺畅？3. 如果出现特殊情况，两条道路都不能走了，步行是否可行，需要多久？就可以省钱省时间！
说了这么多，再送给你们一段我很喜欢的话吧：
From 邱岳：
对产品负责，最直接的表现就是「让正确的事情相继发生」！
如果在这个过程中需要懂技术，就去学技术，需要懂交互，就去学交互，需要懂画图，就去学画图，需要懂演讲，就去学演讲，需要懂什么，就去学什么…
团队中，谁都可以说这不是我的职责范围，只有产品经理不行，受不了这个委屈，就别干产品经理。
最后，送给你们一个个有趣的视频，《产品经理的日常》from「不上班TV」：
作者简介：Leap，重度Ruby用户、系统架构师、当过CEO的CTO、产品经理、连续创业者。
