转载自：http://blog.csdn.net/luohuacanyue/article/details/12903189
这篇文章里说的内容，其实都是老生常谈，但是里面有一点我觉得非常有道理，在做完一个项目之后，我通常想的是，这个项目中有哪些不足，而不是——“怎样把这个项目做的更好”，两者看上去没什么区别，其实有很大区别，因为出发点不同。
凡事都应该是目标导向，你所做的一切，都应该是为了实现你的目标。
下面是正文：
前言
最近一直在想自己在项目中的一些得失，在每一个项目结束都要问自己一下：这个项目中自己获得哪些成长，下次是不是可以做到更好。长期的项目过程往往会让人陷入一种思维的定式：好像每个项目的工作都一样，这样很容易进入一种比较消极的状态，会忘记自己曾经给自己设置的目标。以前看过这样一个问题：什么才算得上有效经验？有些人做了三年其实只有一年的经验，因为后面基本上是前面的copy。这也是为什么有人说一个人的成长在于前面三五年，后面很有可能会遇到天花板。当遇到天花板的时候能不能突破是一个关键。下面讲一个整个项目中需要做什么。我会在介绍整个流程的同时插入自己的一些想法和思考。更重要的是思考，思考是人的精髓所在。
项目流程
1. 需求阶段
这是项目的最初的阶段，这个阶段主要需要明确这个项目要做什么？目标是什么？一般来讲这个过程是产品经理去做，这个阶段的酝酿时间往往比较长。因为一个项目最开始可能只是一个idea，对于整个目标可能他自己也没想好，甚至是不可行的，需要进行一段时间的沟通和厘清才会逐渐形成一个真正的需求。另外对于产品经理而言是以业务结果为导向，可能会提出一些从技术角度不合实际的想法。这个时候就需要项目经理和产品经理进行沟通，一个是明确具体要做什么，另外一个是可行性（引入成本收益原则，就是完成这样一件事情的成本是多少？收益是多少？是不是值得？就应了那句话：一切皆平衡）。当这两个目标达成一致才可能往后面去做。如果兴冲冲的往前走，往往会适得其反。所谓“磨刀不误砍柴工”。
2. 概要设计文档
明确整个需求后开始要做的就是启动项目。确定项目经理、架构师、开发人员、测试人员、前端等各种资源都需要到位。架构师需要产出概要设计文档（可能比较多的项目这个文档是由项目经理产出），并对整个项目的时间有一个评估，确定整个项目的重要时间节点。整个项目流程中几个重要的节点的时间都需要敲定，并对其规模需要比较仔细的评估。另外整个项目风险在哪里，都需要做到尽量的枚举，以往的项目经验在这个过程中就会起到非常重要的作用。
3. 详细设计文档
在概要设计后需要对这个整个项目进行分解，这时候可能并不是架构师来设计，很有可能是每个开发工程师进行分模块设计，数据库表结构、接口、缓存等一系列和此项目相关的东西，然后在做一个合并，这种方式对于开发来讲会有比较多的成长。如果整个设计过程只是项目经理或者架构师参与，而开发工程师只是参与编码工作，这样的一个流程对于开发工程师的成长而言就会非常有限。
项目文档的详细程度会根据整个项目的规模来判断，大项目和小项目在流程上会有一些差异，小项目可能就不需要繁文缛节的项目流程和文档，这样可以加快整个项目的进程。大项目整个流程和文档是不可或缺和非常重要的。如果说小项目可以靠个人进行保证，那么大的项目更多的依赖于流程和管理。所以项目的流程并非一层不变，完全可以根据项目的规模在实际应用中采取灵活变通的方式。在大的流程框架下做一些优化和变通对于实际应用中是非常有好处的。引用中国那句很有名的话：“不管黑猫白猫，抓到老鼠就是好猫”。可能有些公司会非常强调流程的重要性，我觉得整个流程不能太死板，对于互联网行业来讲，最重要的是应对变化和把握时机。流程是为了保证产品的质量，而不要为了流程而流程。
4. 编码阶段
这个阶段没什么异议，开发工程师按照设计文档中进行coding。如果是开发工程师在这个阶段会有比较多的感触。在项目管理中会有比较多的形式对开发进度进行保证，比如 说每天的晨会制、周报制。各种汇报机制各有不同，也各有优劣，比如说晨会制每天都可以监控到整个项目的进度，周报制的好处是给予开发一个比较大的发挥空间，但是对于项目管理而言会产生一些风险。
一个任务应该分成多细。也就是说一个任务分配下去多长时间合理。这个曾经我们也一起讨论过这个问题。有的说1天，2天，也有的说3天5天等等。对于我而言是不太喜欢把一个任务分解到一天，这样心里会感觉到非常的不爽，受到了严格的束缚。我比较赞同这样一种分法：可以把一个星期的任务分配下去，然后由开发工程师再将这一个星期的任务进行分解，一个层面上来讲开发工程师有一定的自由分配能力，他可以在这个过程中获得成长。另外就是给予开发工程师一定的空间，而不是完全把时间交给了项目经理。
5. 测试阶段
测试阶段对于开发来讲是比较轻松的，主要的工作重心转移到了测试人员身上。这个阶段的重要性不言而喻，因为测试阶段是对于项目质量保证的比较后面的一道关卡，也是可能发现问题最多的一个阶段。测试的质量很大程度上会影响整个项目的质量。QA在前期对于整个需求已经有一个很清晰的了解，根据需求文档和设计文档产出测试用例。很多的测试会陷入开发的思维，采取开发的思维方式去测。这种方式往往会出现漏测甚至测错的情况。QA应该是尽量独立于开发，QA应该完全按照其本身的专业特征进行，这样才能保证在测试阶段尽量多的暴露问题。
这里再说说开发自测的问题。一般来讲开发工程师开发完成后都会进行一些自测工作，但是不管多仔细，或多或少都会产生一些遗漏。比较好的方式是可以根据测试的TC进行自测，因为开发很有可能会陷入自己的思维定式，在自测的过程中会很难覆盖到所有的点。这里也遵循了一个项目原则：问题越往前暴露项目风险越小。
6. 发布阶段（交付）
这是项目的最后阶段，这个项目能不能正常上线，仰仗于前面的工作，是对前面工作的一个检验。PM在前面准备发布计划。确定整个项目发布上的一些工作。
项目管理
对于PM而言核心的目标就是按质按时的保证项目上线。在上面6个阶段中其他人员可能某一两个阶段介入（严格意义来一个项目对于每个人都需要全程介入，实际项目中可能会有一些差异）。但是对于PM而言需要全程的跟进整个项目，对于整个项目要了然于胸。在项目的前期PM需要协调各方资源，比如说确定开发人员、测试人员等和项目有关的各方人员，推动整个项目的进行。
在项目阶段可能会有不同的管理工具或者管理方法，比如说定期的例会，项目阶段性报告（上面也有所提及）。这都是在项目中间阶段让整个项目处于可控状态。这些往往需要在实际过程中不断总结。
在项目的过程中可能会遇到形形色色的问题或者风险，这些问题在每个项目都或多或少的都会出现，稍微枚举一下：
1. 资源不到位，开发资源不够或者测试资源不够等等都会影响整个项目的进行。
2. 项目时间评估不准，这个也比较容易出现，如何保证在任务阶段评估出一个准确的时间？
3. 需求变更，项目过程中需求变更是一件非常常见的事情，这时候如何处理好需求和项目进度，如何平衡好这两者之前在关系。
4. 外部资源协调，如果是一个跨部门甚至是跨公司的项目，PM如何保证项目的进行。一般来讲外部资源极有可能影响整个项目的进度。这时候又如何去做？
5. 开发进度延期，实际开发中如何保证开发的进度。开发的时间和最初整个任务评估时间有些出入，这时候又需要怎么做？
6. 编码质量的保证，除了保证时间外，如何保证整个项目的质量。除了靠QA保证外，开发本身又如何保证代码的质量？
7. 发布问题，一个项目发布后完全没有问题的概率还是比较小的，所以如何保证发布后的善后工作。
8. 人员变更问题，项目中有人离职或被调离等。
个人问题总结
不管是何种角色在整个项目中都是非常重要的。每个角色除了站在自己的岗位上把自己的工作做好之外是否可以做更多的延伸。这个举一个例子，比如说你目前是一个开发工程师，后面的发展路径是项目经理，这个过程中你要怎么积累？我想一定不是简简单单的把自己的模块开发完成后就OK了。一定可以往外学到更多的东西。目标只有一个：离自己的目标更近一些。
来源：https://www.cnblogs.com/arthur3/p/3410039.html