一次糟糕的开发体验

这一版开发已经接近尾声了，不过这真是一次糟糕的开发体验。开发累死，产品催死，测试抱怨........有必要好好反思一下问题到底出在哪里？以后应该怎么杜绝类似问题。

产品

我不知道怎么定义一个好的产品，每次听到人人都是产品经理这句话的时候，我的直观理解就是产品经理这个门槛越来越低了。

• 好的产品绝对不是人人都能做到的，但我觉得你至少要懂那么一点技术吧！不要让人觉得很白痴，不要老是认为我的需求就是这样的，你就应该这么样。你是不是更多的时候要想想这个需求是否合理，这个需求是否是一个真正的需求。
• 现在确实很少有创新的产品了，但你就算是照抄别人的功能也没有关系，你要搞清楚别人产品背后的原理吧！总要把别人的产品和自己的产品比较一下吧！不要老是说谁谁谁就是这样的，我们也要这样的，我们也要这样的。
• 一个合格的产品是不是在自己的脑子里就应该有自己产品的模型了，而不是我也不知道长什么样子，也不用心去打磨自己的功能，只是一味的累加。
• 需求应该是越详细越好，版本之间的变化和差异应该描述的越清晰越好，不应该是两三句话，还要开发变开发边帮你理需求，很多时候开发一问，产品自己都没有想到，临时给了一个方案。转过身就忘了。

开发（我）

这一次我觉得自己应该负主要责任，很多东西是我自己没有做好。

• 没有仔细看需求文档，只是觉得自己和产品碰过之后，自己理解的就应该差不多了，很多时候产品反馈给我们的信息和产品文档里面的信息是不完全一致的。开发必须以产品文档为准，这就是凭证，每一次改动都要求产品同步文档。
• 没有仔细看交互，可能每一个人的交互形式不一样，但一定要仔细看交互，不懂的地方一定要多问，一定要多提出自己的疑问，不然你就可能漏掉一些东西，这也为你后来的苦逼埋下伏笔。
• 对于估工期太随意，认为这只是一个形式，deadline在那里，你所有的估时都说为了迎合deadline。这真是一个错误的观点，我们应该明白估计工时应该是建立你在需求充分了解，对整个项目通盘考虑，列出每一个改动点，然后估计出来的时间。这个时间没有必要迎合deadline。
• 前期规划很重要，不要上来就干，干到半路干不下去了，才觉得这不合理那不合理，痛苦的修改，代码质量也没有保证。开干之前在自己的脑子里对整个项目有一个全局的概念，知道它会影响那些地方，最好是有个checklist，然后每一个难点都想想自己是否有解决方案，然后再着手去干。
• 跨项目的沟通很重要，这个沟通最好是前期就做好，而不是后期想一个加一个，也不是前期就自己定义好，不通知别人，后期就直接告诉别人用这个。这个时候会有很多问题，第一你不知道别人的实现，你自己定义的并不一定是合理的，第二你一个人的思考不一定是充分，很多时候可能会导致你漏掉很多东西。因此前期充分的讨论和约定是特别重要的，避免不必要的返工。

这些都是这次深切的体会，以后一定要记着。