一个项目的完整的生命周期大致可以分为：启动阶段、计划阶段、实施阶段、控制阶段、收尾阶段。对于每个阶段的合理管理、把控得当，有时可以加快项目的进度，提升项目的品质，否则可能会导致项目的延期或中断。
1、启动阶段
启动阶段，也即是项目的立项阶段，这个阶段要明确当前项目究竟是为了解决什么问题而存在？它的终极目标是什么？它的服务对象是谁？做的原因是什么？时间要求有哪些？
能带来哪些收益？具体有哪些商业利润？
要明确项目立项的支撑点，并整理记录下来。
就个人之前的工作经验中得出，要明确上述的内容，不是一次会议一次沟通就能有结果的。
（1）在任何情况下，一定要把在会议沟通中的任何需求和任何想法记录清楚，形成一份清晰的纪要文档，每次沟通一定要有讨论结果和解决方案。
注意：一定要有解决方案，问题谁都容易发现，关键是一个大致的合理的解决方案。
（2）作为项目乙方，想要项目能在计划的之内顺利完成交付，一定要注意不要过于在意需求方的口头要求，很多时候需求方只是临时起意，突发奇想，不能盲目的答应，对于合理的需求要多加考虑结果，
最好是能当场确定需求的大体流程（可以通过画草图、流程图的方式），再确认是否能开发等，一定一定要记录在册，邮件通知需求方确认，并抄送告知项目关联的每个人，尤其是双方的领导人员和项目重要人员。
2、计划阶段
计划阶段是项目实施前最重要的一个阶段，这个阶段是对项目的一个具体的计划过程，如：项目的技术选型、代码规范、项目组成员培训、项目需求边界的确认、项目内容的分解、需求评审、技术评审、任务排期、开发周期的初步确立、测试方式、进度计划、沟通计划等；
其中一定要规范化：需求文档(需求细节和原型)、技术文档(包含架构、api等技术细节)、排期文档、上线和回滚文档。
在这个阶段，有几个重点：
####（1）需求边界的确立，整理需求文档。
任何时候，任何阶段都会有很多需求，要根据项目的整体性和立项的原始需求弄清楚哪些需求是不必要的，明确需求的范围；
(2) 对项目需求进行优先级排序
功能开发时，一定有优先级顺序，工期越紧越要搞清楚优先级顺序。
在开发时，结合个人过往的工作经验主要是遵循：业务级第一，功能级第二，统计级第三，页面（显示，UI）级最后的原则。
项目的使用是满足业务的，业务能跑通，项目才是正确的，其次是让使用人员用的开心，就属于功能级的事情，减少使用人员的使用次数就是好的功能，越简单越好，最后才是用户可能无感的东西做优化。
注意：项目中肯定会遇到多个项目需求同时要处理的情况，此时，唯一的评估要求就是，哪个功能不做你损失最大？哪个功能做了，对公司贡献最大？
(3) 对于项目需求变更的处理方案
需求一定是经常变更的，毕竟没有人能一次把所有问题和需求都想清楚，需求变更的事情，大多不是业务层面的，大多是功能层面和使用层面的事情，这类需求变更，成文件形式记录，通报给技术总监和相关技术人员。
业务层面变更就要组织相关领导开会确认，之后把变更后的内容告知所有技术人员。
需求变更一般是由实际使用方提出，包括商务，业务，运营等
如何避免需求的变更就两个解决方案，一是：在需求确立时多搞清楚情况；二是：需求管理 —— 任何需求都要文档形式记录，每次需求的结果都一定一定要邮件形式告知每一个相关人员，跟需求变更人员确认变更(这样可以让他们在提变更时想清楚再提)。
最后在接到需求变更时，要搞清楚优先级，这个需求到底是需要现在就去改，现在就做，要评估清楚。
(4)项目的开发安排
个人比较排斥分功能点开发。
大项目的开发，大部分是几十个功能一起开发，开发时，尽量一个功能模块由一个人（组/团队）来做，这时候，一定要经常开会讨论，把各功能模块之间的关联关系说明白，写明白，画明白。
不然开发时一定会出现，做出来的东西在功能时的不适用（要么是接口对不上，要么就是Bug多），甚至可能会出现底层架构设计上的错误。
以前看过一个关于项目管理的帖子中说过，技术在开发功能时，如果是一个功能比较多的项目，一定要按照严格意义上的功能模块进行分配；
到底什么事严格意义上的功能模块，个人的理解，大概就是一个功能，由某个工程师开发时，他要知道这个功能中包含的东西，就算不是他做的接口，也必须知道里面的业务逻辑。
这样，在开发的时候，他可以把整个功能模块的业务全部理清楚，交付给测试后的Bug就会相对比较少，如果出现问题，一个人就可以解决Bug（我相信一定有人遇到过一个Bug找不到是哪个技术负责的修改的情况）
3、实施阶段
实施阶段主要是指项目的具体实施，主体内容的执行过程，期间要明确前一项内容中的任务分配和优先级，对拆分的任务做合理的排期工作，抽离出难点和重点，最重要的是抓大放小。
同时要考虑到开发过程中的需求变更，做好开发内容的信息记录。
其中有以下几个重点：
(1)开发任务的跟进检查，合理把控具体的开发时间，大概2-3天或最迟1周做一次，进度check。
(2)开发中的人员安排，在项目开发中或多或少会遇到人员的变更，如新员工的入职参与、老员工可能性的离职等，做好人员稳定性的观察，并同时合理安排预备人员（如在实施过程中安排2人以上去了解核心开发进度或任务，可以只有一个人主控某个模块的开发，但另一个人必须了解其中的整个过程）
(3)某项任务延期的处理方式，具体的项目任务过程中不可避免的会遇到一些难点或痛点，此时有可能会因为遇到超出具体的实施人员无法解决的问题，从而导致当前模块的进度延期，此时应当做好合理沟通，记录问题点，要么找有经验的同事指导解决或者发动团队一起进行头脑风暴一起完善当前项目任务。
4、控制阶段
此阶段即过程控制阶段，要确保项目能够朝着计划的目标稳步的前进，要及时发现项目中的偏差，并采取纠正措施，保证项目的准时完成。
项目状态有：需求排队、需求评审、技术评审、排期中、开发中、测试中、上线中、已上线、暂停或废弃，每一个状态下会有对应的项目列表，了解每个阶段的状态信息，和研发一起推动项目状态的不断变更。
(1)做好具体任务的信息记录、版本控制、范围变更。
(2)已完成内容的评审，项目管理人员必须每周抽出至少一次到两次的时间去查看项目中已实际完成的内容，并对完成内容的质量做好内容评估，对于不符合要求的内容定点去跟进并指导，严格控制好项目的质量。
(3)完善每个状态的状态报告，和具体的风险应对(对于开发主要是时间延期，上一项中也提到了大概的处理方案)。
(5)项目测试跟进，查漏补缺。
其实在项目实施阶段就会有测试，但是站在实施的角度去测试是不够完善的，这里的测试是一定要站在用户角度，需求方的角度，把自己完全变成小白。
注意：测试一定要写测试用例，一定要懂项目的业务需要和这个功能的使用场景，测试时尽量能做到角色扮演（把自己当成用户）。
5、收尾阶段
项目的收尾应当说是非常重要的，这一阶段要对项目做整体的验收，整理完整的项目文档、使用手册、有时还要做好项目各模块功能的演示demo，同时也要整理出整个项目过程中遇到的难题、重点和解决方案，吸取经验和教训。
