当然，这得感谢产品团队的同学们，抽象代码是个很辛苦的工作，结合11月艰苦看PMP的心得，总结几个经验教训

1、多简单的需求也是需求，就算是一眼就能搞懂的，也不要想当然，必须和干系人求证，确认。

2、乐观的估算周期内没搞定，委屈是不对的，“早知道多报些时间”的心态也是不对的，要记得估算，或者告诉干系人，不出意外两周搞定，如果遇到技术问题那最多耽搁一周。要不要装B的说我给您一个三点估算结果，但信息更丰富显然是诚意满满的。

3、系统reviewer，发现理解歧义不要立马着急，质疑干系人“当时为什么不提出来，现在又要改了”，这个很不专业，会徒增矛盾，如果当时多问个为什么，问题就不会出现了，专业的做法是把讨论聚焦在“仔细探讨下这个需求的逻辑，看看有没有漏洞”、“这个需求是加到这个项目中，延迟项目交付时间；还是放到下一个后续项目中？哪个更适合我们的目标？”，用职业化的、专业的思维来评估项目范围、评估变更请求、和各交付成果的优先级，不要用”又害得我们白做“、”早说不就省事了”这种从个人角度来判断得失。

4、项目系统，再小的项目也要用系统，别觉得依靠Excel、Word、图片和邮件可以搞定，项目无论大小，规范地使用工具，不然一定会落下什么重要的没有做。