诚信平台邮件分类项目总结

这个项目是做产品工作以来完成的第二个项目，同时担任了项目经理。

从14年12月开始，到15年6月上线，共计7个月。

先做总结如下：

【产品设计相关】

1：对于类别的确定：

 我的方案的找来TOP 100 的邮件数据，通过数据归类，同时参考谷歌的方案——得到了最终的分类类别。（这是工程师的思维）

CY的方案是从用户的实际使用场景出发——得出应该设立的几种分类（这是产品的思维，但是容易落入主观的陷阱中，比如设立的各个分类中邮件种类数量不均）

2：对于分类标签的数字化表示，在整个项目的运行过程中有3处需要用到。

（1）人工训练标记

（2）Smail与分类引擎数据传输

（3）分类引擎结果返回

在项目推进的过程中，这三处几乎可以说都使用了独立的标号系统，这样就会造成一种混乱，发生问题时也容易混淆。其实下次再遇到类似的情况，应该从一开始就统一确定下来。全流程使用统一的标号标准。

3：新功能上线时，如果因为技术原因，不能覆盖到全部用户，要懂得合理的取舍，必要时可以放弃。需要评估放弃或舍弃时产生的影响大小。

POP用户无法执行分类，最终处理方式为：邮件全部收取下来，不对POP用户进行分类。这样做损失了POP用户的使用体验，但是避免的丢信问题（这是更大的危机）。

4：需求文档版本变更时，需要写明变更内容（在邮件正文中）。

5：每一个功能的开通/关闭，都要要求开发人员在后端记录日志。有数据可以查询。

6：当涉及到内测/AB测试/灰度测试的时候（部分人开通，部分人未开通）能够进行逻辑隔离，就不要进行物理隔离。（逻辑隔离风险小，灵活性高，物理隔离风险大，灵活性差）

7：每一个改动/功能/阶段性目标上线后，要及时观测相应的指标/变化量是否正常。

【项目管理相关】

1：项目评审时，需要考虑到核心业务指标（收入/活跃度/用户体验——数据化），并将项目目标与之产生直接或间接的联系。

2：答辩PPT中如果有流程图，用透明背景。

3：效果评估指标和评定标准要一开始就确定下来，并贯彻始终。并且发邮件给所有人，解释清楚是什么和为什么。

在这个项目中，用到了好几个指标，一开始是各类别的分类准确率，和分类邮件覆盖率，后来又加入了重要邮件准确率和次要邮件准确率。最后重要邮件和次要邮件准确率由由用户移动率替代，比较混乱，前后用了很多不同的标准，没有办法从始至终的评价效果。

4：要多使用SVN来进行代码管理和文档管理。不要都保存在本地。

5：重要的/经常会查阅的wiki/文档说明要及时保留。

比如LW的各个fid的定义文档。

6：在定制项目计划/进度的时候，要考虑到各个子里程碑之间互相的依存关系，A事件的启动是否依赖B事件的完成。

7：对每一个执行细节都要了解清楚，通过开会/当面进行沟通。

在完成4轮内测后就认为可以开始发送邀请信执行用户内测了。但是这中间还需要若干工作，当时并不了解，包括：LM把程序安装包给SHB，SHB安装后，ZH更新Smail规则后，前端才可以上线。在考虑进度安排时，并没有给这些工作预留时间。导致了一定的延期。

8：对进度时间的安排，要留有余量。

对内测用户发送邀请信的时候，由于公司线上系统故障，导致发送邀请信延期。

但这个时候，如果push一下合作方，说不定他们可以给出其他解决方案。但是如果不进一步推进的话，由于惰性等原因，对方并不会主动提出帮忙解决。（LW最后手动操作发送了所有邀请信）。

9：每个新功能对用户发布前要自己先进行测试，无误后才可以提出上线要求。

10：当项目因为某些原因（自身团队或者合作团队）需要延期较长一段时间时，需要及时主动向汇报人（如XJP/super）发邮件，并确认问题的重要性，影响范围和解决方案，遇到的 难点等。

11：当开发说，由于XX等原因（内存共享什么的）机器无法准备好的时候，需要坚持再要求一下，进一步多问几个问什么，不要被对方完全牵制住。

SJ说由于占用机器内存的原因，希望再单独调用服务器进行部署，于是还需要等待新服务器到位。最后证明，并没有占用太多内存。

12：邮件列表list单独整理一份放在本地，每次发邮件的时候保证无人被遗漏。