对于后端来说，一个项目究竟应该怎么做
引子
作为一个程序员，平时的工作是与项目来挂钩的，但是有的时候会发现有些项目做得风生水起，有的则做得浑身难受，那么一个项目究竟应该怎么做？
一个后端接到项目的主要流程
- 需求咨询
- 需求评审
- 项目估期
- 技术评审
- 跟上游约定 api
- 开发
- 联调测试
- 产品验收
- 上线
- 整理必要的文档
需求咨询
这个阶段是后端最初接触某项目的初始阶段，此时产品会给出最初的需求文档（线框图此时可能没有），甚至是人肉来咨询后端做最初的评估，已确定某些需求的可能性。
讨论结束后产品会根据讨论得到的结果回去开脑洞，项目可能夭折或者继续进行。
需求评审
产品经过他们自己的讨论设计，给出需求文档线框图（此时设计稿一般没有），召集前后端等项目成员进行需求评审。此时后端同学需要根据需求的合理性、项目的开发周期进行讨论（砍需求）。
砍需求的目的不是为了砍需求而砍需求，需要根据手上已有系统的功能以及新需求做出综合考虑，尽量在相对简单的情况下实现产品的需求。
简单的说就是难的我也能做，但是要花时间，砍需求的目的就在于在项目的 deadline 内能够完成这个项目。实在不行这个需求放在二期，太多的所谓二期需求就没有二期的项目了（可见有时候产品的需求...）
注意，产品会接受开发砍需求，但是开发请对确认后的需求认真估期，保证 deadline。否则又砍需求时间到了又做不完，呵呵。
项目估期
根据需求评审得到的需求，后端会先做初步的技术调研，需求拆分，在评审结束的1~2天内给出估期。
估期时需要注意，估期很难一次性估准，一个开发对于大于一周以上的估期就可以认为是凭感觉瞎估了，这里有个估期的经验：将需求拆细后拆到开发级别的力度建立对应的 task，对于每个 task 来做估期，当发现一个 task 的时间大于5后（单位为天），则需要拆分子 task，估期时采用斐波那契数列的评估方式: 1 2 3 5 8 13 21，对应于1天 2天 半周 1周 1.5周 2周 3周，可以上下加减0.5。然后根据子任务的时间合估计主任务的时间。
需要注意的是，估期时需要估计前后端联调时间，上线时间，资源申请时间，幺蛾子时间。幺蛾子时间为处理非此项目事件所花费的时间，这个跟开发本身所处的环境有关，可以在总估期的基础上乘以 1.2 ~ 1.5。
技术评审
复杂事情需要技术评审，尤其是自己做的事情心里也没有底气，需要其他开发一起讨论的时候。技术评审是保证复杂事情可以顺利完成，减少后期返工可能性的一个重要环节。
技术评审开发本身自己需要给出评审文档，包括项目背景，技术选型，主要的技术约束，自己想到的设计实现。
跟上游约定 api
一般一个项目会由多个部门并行开发，例如 数据、后端、前端、客户端，并行的过程中如果某个端开发比较慢，会导致卡另一个端的开发进度，所以需要开发前跟自己的上游约定 api，并给出文档，各个端遵循接口文档进行开发。
开发
根据技术评审后（简单的事情没有评审，自己心里有数）得到的方案以及之前建立的任务进行开发。
开发过程中需要仔细研究设计稿的细节，有任何存疑问的点去找产品确认，确认后的需求记录在某个文档上。开发前几分钟的几句话，会大大降低返工的可能性。
记录后@产品画押，开发和产品的记性都很差，画押非常必要。后期甩锅有用。
开发时注意把某些流程繁琐的事情放在前面做，例如申请某些资源可能需要其他部门同学支持，有额外等候时间。
开发过程中遇到难点及时向其他开发求助，不要憋着。
如果可能遇到延期风险，请及时通知产品，deadline 请尽量遵循（这句话的意思很明显）。
联调测试
前后端开发完后做整体的联调测试，在扔个产品测试前，请自己测过自己开发的 feature。否则气死产品事小，被产品打死事大。
产品验收
迎接可能的返工。
上线
上线注意各种细节，例如数据库变更，是否需要热缓存，灰度或者预发布后是否需要 cms 添加某些基础数据等等。
上线前请提供回滚方案。
整理必要的文档
文档记录下各种链接（需求文档、技术评审、 api），主要的实现，需求的变更即可。
正常情况下，上完线就结束了，也没有人会做这一步，但是如果后端做掉这一步的话，之后维护起来就会节省很多看代码思考逻辑的时间。
后记
请尊重项目的 deadline。