软件项目经常遇到的一些问题可能包括：项目时间紧，项目组成员经常加班；项目需求经常变化；在项目进行过程中，部分项目团队成员可能会离开或转到其他项目团队；项目重复建设问题严重，每个项目都需要从框架上重新开发，现有项目成果难以重用等等。我认为通过更好的规划和管理，可以在一定程度上提高项目的成功率或质量，降低开发成本，缩短开发时间。 　　

　　我理解项目管理有两种主要的分工方法。一是一般项目管理体系，即PMP提到的5个项目管理过程组、10个知识领域、49个项目管理过程；二是根据项目生命周期不同阶段具体业务领域的管理。本文主要总结了项目生命周期各阶段的管理。 　　

　　软件生命周期的一般过程：可行性分析、需求、设计、开发、测试、实现、维护和总结。 　　

　　一、可行性分析 　　

　　一般项目通过对外招标获得。对于一些公司来说，投标的时候，项目之间肯定是有选择的。如果在特殊时期有可能活下来，只要不是成本太高，项目就尽量承接。 　　

　　但是承接一般项当前最好先进行经济、技术等方面的可行性分析，而且这个可行性分析最好有管理人员、市场人员、技术人员参加，因为市场人员一般不太懂技术，只有大家一起分析讨论，才能得出比较可行的结果。可行性分析的结果一方面可以作为是否承接项目的依据，另一方面也可以作为承接项目或与客户谈判的依据。比如经过分析，项目的工作量很大，如果按照投标额开发可能会亏钱，那么我们可以和用户商量以后是否会有二期项目；另外，如果用户要求的时间比较紧，但是经过分析很难按照招标时间完成，我们也可以在正式签约的时候和用户讨论是否可以延长系统的交付时间。当然，这些与用户的讨论一般都需要公司高层领导的协调，有时候单靠项目组是无法达到预期效果的。 　　

　　另外，在这个阶段，最好对项目的成本和资源进行估算。 　　

　　二、需求 　　

　　实际需求要细分为需求调查、需求分析、需求确认、需求管理等。 　　

我建议每个项目无论多大也无论项目时间要求多紧急一定要有一个比较详细的需求文档。

在需求确定之后再对项目成本进行估算。同时对需要的资源及相关里程碑进行说明。

三、设计

大部分中小型项目会因为时间和人力的问题加上需求变更比较频繁，所以有时很难书写一个比较详细的设计文档。但是如果没有设计文档一是为后期维护可能会带来一些问题，尤其是当原来开发人员或主力开发人员离职或调离到其他项目组时；另外没有经过详细设计的项目可能也会存在一些风险。

因此建议不必为了文档而文档，除了项目验收的要求外，建议设计文档根据项目特点有选择地包括以下一些内容的说明：

系统的关键配置说明【如数据库服务器，应用服务器等等，如有必要可另加附件进行说明】。

对于中小型项目如果不是用户要求有时不必在设计文档中对所有数据库表及字段都进行说明，可以只说明比较重要的一些数据库表及字段以及相关数据库的关联关系就可。因为在用数据库建模软件进行数据库设计的时候可以对每个表及每个字段加注释进行说明，在使用开发工具进行开发的时候自然可以看到每个数据库表或字段的说明。而且一般中小型项目在开发的过程中可能需要经常性地修改数据库表的设计，如果还有文档描述数据库的设计那么每次修改时除了修改数据库之外还要维护设计文档的一致性，如果项目忙忘记了修改就会导致文档和数据库的不一致，有时这种不一致的文档可能还不如没有，因为它可能会误导其他人员的理解。

另外也可以通过开发过程的规范来减少设计文档的内容。这个将在下面的开发环节进行详细的说明。

四、开发

整个项目有一个合理的框架是很重要的。框架具体包括哪些内容在此很难解释清楚，但是我想最起码整个框架应该把项目所采用的各种技术【如java中的Hibernate、Struts、Spring的结合】比较合理地组织起来，并为具体模块的开发提供一些工具类等，同时整个框架应该具有较好的可扩展性、可维护性和较好的性能。框架最好由项目组中技术最强的人【在此称他为技术负责人】进行搭建及维护。

另外对于整个项目有一个统一的命名规范【类和方法按什么方式命名，所有文档都加上时间作者等】并进行遵守是很必要的，这样一个人开发的代码其他人很容易就能够读懂。

在整个项目进行全面开发前最好先向项目组全体成员讲解需求及项目框架的机制、使用方式及注意事项，再说明相关规范。然后每一个开发人员按照理解开发一个简单的功能。然后大家在一起【或者由技术负责人】看一下每个人对于框架的使用是否合理，规范理解的是否有误，编码习惯是否需要改正等等。在讨论并达成共识后再进行具体功能的开发。另外在具体的开发过程中尽量在关键算法处加一些注释进行说明。建议定期进行一些代码走查的工作。尽量由技术负责人负责这份工作，当然也可以进行互相检查等。代码走查的好处很多，如何发现一些不好的编码习惯；提高整个系统代码的可读性；发现一些bug；借鉴别人好的编码思路或技术等。

五、测试

首先开发人员一定要养成单元测试的习惯。对自己开发模块的功能进行单元测试过之后再提交测试组进行结合测试、系统测试甚至性能测试。单元测试很重要，在进行单元测试的时候如果条件允许可以使用一些代码覆盖率工具帮助分析测试用例的覆盖程度。另外，一般项目可能是整体开发完之后才进行性能测试，可是这时测试出性能问题了却因为临近上线或试运行时期，不一定有充足的时间进行修改，另外也可能因为整个项目已经都使用了某种影响性能的技术或方法，要想改变要付出很大的代价。所以建议如果条件允许可以在开发的过程中【甚至搭建项目框架时】使用一些轻量级的开源性能测试工具由开发人员对可能影响性能的功能进行测试。

对于测试部门的测试人员要尽早地参与到项目中来，建议在需求阶段就介入。早介入的好处一是可以对需求理解得比较深入，知道原始需求是怎么来的，中间经过哪些变化，这样会比在开发结束后一次性地讲解能够更好地把握需求，更好地书写测试用例及测试计划。

项目组设计人员一定要把一些关键测试点、数据及功能的关联关系对测试人员说清楚。测试过程中有一个bug管理系统并对bug进行跟踪是很必要的，最好是在项目结束后能对产生的所有bug进行一下分类。然后通过分析得出一些规律。通过在以后的项目中采取一些措施进行项目质量的提高。

六、实施

对于涉及多个子系统的长期开发项目，在系统设计和开发过程中要优化处理关联性强的系统，同时有一个【或几个】系统成熟了就试运行或上线，不必等所有系统都好了再上线。一是因为时间长了开发人员可能调离至其它岗位，维护代价会增大；二是子系统用户可能会改变而导致需求变更；三是时间长了用户对系统需求会有陌生感，也可能会产生新的需求；四是时间长会打消用户对使用系统的积极性；五是较早地让用户看到系统也可以减轻因双方理解偏差而导致的系统需求变更的影响。

七、维护

争取把用户提过的所有修改都进行记录，并争取所有修改都请用户签字【不一定提一个修改就签字一次，可以统一记录然后定期把一段时间内的修改进行签字确认】，如果做不到所有修改都签字也尽量做到对于重大修改请用户签字。签字的好处很多：让用户看到项目组所做的工作；如果修改的内容比较多可以通过双方高层领导的沟通再进行系统二期或三期的开发；有了签字有时用户对需求变更会相对少一些等等。

另外对于所有修改除了签字留档外争取定期把所有修改的内容再整理到需求文档中，保持需求文档与正式环境功能的一致性。这个工作很有必要，可能带来以下一些好处：方便测试人员在回归测试时理解系统功能；如果维护人员的调离其他接手人员比较方便理解系统功能等。

八、总结

建议每个项目结束后都召开一个项目总结会。项目总结会建议与项目相关的所有人都参加。由项目经理进行主要总结，但每个参与人员最好也都进行总结。可以从管理和技术两大方面对项目中的每个阶段的成功与失败进行总结，目的是总结经验教训，提高每个人的项目经验，提高项目组的成熟度，使以后的项目更加成功。在此要强调一下，一般项目总结时大家都喜欢只说成功的，而很少提到失败的或所走的一些弯路，而往往对这些失败的总结更能使大家收获更多，当然这也要看组织的文化，我建议如果可能尽量鼓励大家多总结一些失败的经验教训。

项目结束后如果有时间最好是把项目中的一些有重用价值的文档放到公司的组织过程资产库中。

如果项目的框架比较合理也可以剔除项目中的业务相关功能的代码，整理出项目框架并加以简要说明文档供本项目组其他项目或其他项目组使用。

九、项目经理职责分析

对于中小型规模的项目，项目经理可能既要充当管理人员的角色又要充当开发甚至实施人员的角色，基本上软件项目生命期的每个阶段都要参与。

但是我觉得以下一些工作项目经理一定要重视：

总之项目经理要对项目的成败负责，要对项目成员的发展负责，要对客户负责，还要对公司负责，所以项目经理一定要有责任心、要有全局观。

近期热文：

• 一张图知道项目经理每天每周每旬每月的日常工作
  
• 项目管理就是多想一步，多走一步
  
• 一图掌握项目管理的核心工具WBS工作分解结构，PM必备技能！
  
• 项目管理体系指南PMBOK第七版框架解读
  
• PMBOK第7版整体架构全面详解--带你快速掌握第七版全貌
  
• 什么决定了项目经理的高度?
• 拿到项目之后项目经理每个阶段都应该做什么？用什么工具和方法？核心关键是什么？
• 优秀项目经理必备的实用演讲技巧
• 优秀的项目经理是如何做述职汇报？附模板下载【可乐洞察】
• IT项目经理每天每周都在干什么？附简要周报模板
• 掌握管理全景图，让你知道作为管理者到底管什么？理什么？
• 项目经理能力提升模型详解
• 优秀项目经理和PMO管理的六脉神剑
• 月薪60K以上的PMO岗位要求都是什么样的？
• PMO和项目经理应该掌握的项目研发效能度量指标大全
• 一图掌握项目管理各阶段必备工具方法大全
• 项目管理的最重要的一环需求管理该如何做？
• 项目管理面试难题问答及经验参考