前段时间做了一款算法产品，当时还写了一篇文章《做一款带算法的产品》。目前产品基本落地，做算法产品的疲惫程度比普通产品要高。
趁着做产品的记忆还在，写篇算法产品的经验总结，以免将来忘记。
alpha测试--测试模型的建立
Beta公测：优和约束条件和算法公式
沟通、沟通--足够的耐心
延期--预留更多的工期时间
alpha测试--测试模型建立
产品做好了，需要做测试；算法做好了，也需要做测试。
做算法测试的人，最好是最熟悉算法的人，能快速辨别算法的谬误。
算法产品的测试模型，会远远高于普通产品，为此我们需要单独建设一个测试模型记录系统。
记录的工具有很多，我这里以表格为例吧，主要统计以下数据:测试编号、用户类型、角色卡姓名、数据库记录的事件id、涉及算法模块、bug描述、修正方向、记录时间、修改结果、备注。
根据做好的测试模型，进入测试模式。
编写测试角色
算法运算
人工运算结果（更据流程图、算法文档、算法公式计算）
对比结果
记录测试行为
有个测试经验，一般都先做单一影响因素测算，看看此单一因素的运算情况。等所有单一影响因素全部正确后，再做多项影响因素复合测算，此处的多项是逐渐增加的。
Beta公测：优化约束条件和算法公式
Alpha测算后，我们进入beta测算，找到大量的客户做真实运算。
一般来说在alpha测算时，测算人员应该就会感受到部分算法需要优化了。但是beta测算，一定会迫使算法工程师进行算法优化，因为我们会发现算法会有很多没考虑到的地方。
进行的行为有以下几种：
第一、找到异常的算法结果
第二、清洗异常算法--统一归类
第三、优化算法约束条件
第四、算法公式修改（可能不需要）
基本上可以断定，出现异常算法结果是一定，这里的主要原因是算法包含的用户情况不够。
找到异常算法后，我们会清洗异常算法，统一归类，归类后进入alpha测试流程。只要能归类，基本都能找到优化方向。
修正异常算法，可能是以下几种情况：算法触发机制出错、算法约束条件不够、算法约束条件逻辑冲突等，针对性的修正就可以了。
最后一个，有时候可能真的算法公式用错了，需要修改。
沟通、沟通--足够的耐心
一般来说做算法的是算法工程师或者产品经理，写算法的那个人是后台程序工程师。只要存在沟通，就会存在理解偏差，很简单的一件小事都会这样，更何况是有点复杂的算法。
我做的算法产品是外包的，沟通更是通过qq，相对而言出偏差的可能性会更大。
比如，我描述算法修正的情况，我自己以为已经描述清楚了，程序工程师也说听懂了，但是修改后，会发现没有，很大可能就是理解出现偏差了。
如果是外包，我建议及时电话语音沟通，这样的偏差性会比文字低很多。
如果出现僵持的情况，不妨冷静会，回头再重新核对修改。
其实这里到没有什么奥秘，只要有足够的耐心就够了。
延期--预留更多的工期时间
上面的一套走下来，你会发现真实完工时间比预期的完工时间大概多很多。
所以，如果你做的是包含算法的产品，建议不妨在已经延期的预期时间上，再加上一点延期时间。
