版权声明：如有转载请求，请注明出处：http://blog.csdn.net/yzhz  杨争  

        web项目指基于web的开发项目，由于web开发的一些特点，使得web开发的项目管理与以往的软件开发项目管理有很大的不同，具体表现在
1、web项目周期短。
        一般的web项目的周期为1～3月，而一般的软件开发的周期都在半年以上，象vista微软花费了五年的时间才开发出来。
2、web项目要求上线快。
        互联网公司推出的产品，讲究快字当头，谁先推出产品占领市场，谁就取得先机，所以web的项目往往要求上线快，对于比较大的项目通常我们会先把产品先launch上线，然后第二期第三期再来完善。
      “快”应该是web开发和通常的软件开发的最大区别，web产品的维护是在服务器端，这就使得这种快成为可能，我们可以很容易地随时升级产品，而通常的软件由于是部署在用户的机器上，升级的频率和幅度没办法与web产品比拟。
        也正由于这个“快”，使得web项目的需求变更成为了web项目管理中最需解决的问题。
 
        web项目经理手册分为若干主题，每个专题从项目管理的某个方面介绍项目经理在这方面要做的事情，专题会陆续推出。
       本手册为本人在项目管理中的经验总结，所以手册的内容也会不断完善中。

       本手册的原则：
1、指导性强。
2、实用性强。
        我一直崇尚这么一句话：把问题复杂化是为了帮助我们更好地理解这个问题，而把问题简单化是为了让我们更好地执行。所以本手册把简单可行作为标准。一个再好的流程如果不简单可行，最终也没法在实际工作中推广起来。当然简单的含义不是要少做事情，而是所做的事情让执行的人觉得就该怎么做，不这么做，质量就没法保证，并且执行起来很自然。

对阅读者的要求：
1、本手册来源与本人平时项目管理的经验，不同公司有不同的特点，项目本身也有差别，本手册虽然阐述的是具有普遍性的问题，但是遇到一些具体特殊问题，大家还是要以实际情况为准，本手册可以起到参考作用。

web项目经理手册-版本控制流程

        大家在项目过程中是否会经常发生以下问题：
1、测试人员在测试阶段更新测试环境时，发现编译不通过，或者应用出现异常，无法进行测试。后来发现的根源是测试和开发共用一个分支。
2、有一天某个人群发了一条邮件通知，“我们的项目代码已经发到主干，这段时间大家不要修改主干信息”，这样影响其他项目的正常发布。
3、项目进行了比较长的时间，等最后发布，需要与主干进行合并的时候，出现大量的冲突，几乎没法处理。而且冲突处理完后我们还需要重新再做测试，以保证我们的冲突处理没有问题，这样又会需要花费大量的时间。

 版本控制流程目标：
1、保证各个环境(开发、测试、主干)的独立，避免相互影响。
2、减少最终发布时合并主干出现冲突的概率。
3、降低冲突处理的难度。

原则：
多个版本（开发版本，测试版本，发布版本）；多次合并。

流程：
1、项目开发编码前从当前主干建立一条开发分支，供项目开发人员使用；
2、开发结束，提交测试的时候，从当前主干建立一条测试分支，将开发分支合并到测试分支上，供测试人员进行测试。这样开发人员对开发分支的修改不会影响测试环境；
3、bug fix的时候我们定时将开发分支的修改合并到测试环境中。
3、回归测试的时候，从当前主干建议一条发布分支，将测试分支合并到该发布分支上，在发布分支上进行回归测试。
4、发布前，将发布分支合并到当前主干。

好处：
1、多个版本相互独立，互不影响
2、通过多次与主干的合并，这样发布时候和主干做最后一次合并的冲突会大大减少，并且在与主干多次合并过程中的冲突解决都在测试阶段中得到了测试。

建议：
如果项目的周期比较长，和主干进行合并的次数也应该加大，以降低处理冲突的难度。

 

web项目经理手册-开发时间估算

 

        项目经理制定项目时间表的时候，需要估算每个任务所需的时间，其中开发任务中模块的分配和时间估算是其中最主要的部分。本篇专门就这部分作一个阐述。

一、在分配模块和估算开发时间时，我们需要把握的原则和目标：
1、保证项目整体的进度。
2、有助于确保开发编码的质量。
3、有助于提高开发编码的速度。

二、每个公司都拥有自己的技术框架，开发人员主要的工作通常投入在具体的商业逻辑上。
通常每个模块所需的开发时间取决于以下三个因素：
1、该模块的商业逻辑的复杂程度。
2、开发人员的技术水平和对项目所在应用的熟悉程度（包括对框架和应用的熟悉程度）。
3、该模块技术实现上是否有技术难点。这里我把技术难点定义为：在现有系统中还未实现的有一定技术难点的问题。对于这样的难题，开发者没有相关的代码可以参考，需要投入一些时间研究解决。

三、模块分配和开发时间估算的步骤：
1、作为项目经理划分好模块后，我会自己先估算一下每个模块所需要的开发时间。

2、召集所有开发人员，讨论模块分配和开发时间估算。
      项目经理将划分好的模块，让开发人员从中挑选他们感兴趣的模块。这样做可以提高开发人员的主动性和参与性。
      项目经理在分配模块的时候还需从以下几方面考虑，以确保开发的速度和质量。
 (1)相同类似的模块由同一人负责开发，比如文章的增删改由同一开发者负责。这样做的好处就是开发者对相关逻辑会更加熟悉，同时接口的定义也会比较明确，沟通的成本比较低。
 (2)技术难度比较大的模块由技术水平比较高的人负责。
 (3)业务逻辑比较复杂的由对这块逻辑比较了解的人负责。

 3、模块分配完后，开发人员评估自己负责开发的模块所需要的时间。在此过程中我们会比较详细的讨论每个模块的技术实现，以便使时间的估算更加准确。
 
 4、项目经理对开发人员估算的时间进行确认。
        在确认过程中作为项目经理我会参考以上提到的三个因素，同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的，我会和技术人员探讨其中的缘由。
        对于时间周期比较长的任务，我通常会再细分一下，争取每个任务的最长时间不超过3天。时间周期越长的任务，不确定性越高，风险也越高，越有可能成为项目的瓶颈。
 
 
建议：
1、项目总结的时候，对项目中的一些数据做好统计比如单位UC所花的开发时间、测试时间等，这些数据统计可以作为以后开发的参考。
2、对技术难点，在项目开始前做好技术准备，提前安排人员研究。这样会节省以后项目时间，降低技术风险。

 

web项目经理手册-Code Review

 

     Code Review是保证项目中代码质量非常重要的一个环节，其主要工作是：
1、发现代码中的bug；
2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。

1、代码中的bug主要会出现在下列两个地方：
(1) 与商业逻辑无关的bug。
        比如，系统中打开的流／文件／连接等没有及时关闭；或是存在thread safe问题，或是存在性能低下问题等，这类问题对有经验的开发人员是比较容易发现的。

2、与商业逻辑相关的bug。
        这类bug是非常隐蔽的，如果有对产品不熟悉的人参与该产品的项目开发，容易出现这类的bug。为了避免这类bug的出现，我们除了在Use Case和Test Case中详细描述以正确指导开发人员并在测试时能及时发现它之外，Code Review也是不可缺少的保证环节。
        我们希望代码的审核者对产品非常熟悉。

3、什么样的人承担代码审核者Code Reviewer？
(1)、比较熟悉相关商业逻辑。
(2)、有丰富的编程经验。
两者缺一不可。

4、代码Code Review的步骤，这些是我在平时工作中的经验总结，目前也是按照这个步骤在做。
(1)、代码编写者和代码审核者坐在一起，由代码编写者按照UC依次讲解自己负责的代码和相关逻辑，从Web层->DAO层；
(2)、代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug；对这些bug记录在案。
(3)、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。
        代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。

(4)、代码审核者根据审核的结果编写“代码审核报告”，“审核报告”中记录发现的问题及修改建议，然后把“审核报告”发送给相关人员。

(5)、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。

(6)、代码编写者 bug fix完毕之后给出反馈。

(7)、代码审核者把Code Review中发现的有价值的问题更新到"代码审核规范"的文档中，对于特别值得提醒的问题可群发email给所有技术人员。

5、责任：
        代码编写者，代码审核者共同对代码的质量承担责任。这样才能保证Code Review不是走过场，其中代码编写者承担主要责任，代码审核者承担次要责任。

6、Code Review必备的文档：
      “代码审核规范”文档：记录代码应该遵循的标准。代码审核者根据这些标准来Code Review代码，同时在Code Review过程中不断完善该文档。

web项目经理手册－需求变更管理

 

  需求变更管理是web项目管理中最重要的一个环节，需求变更管理的有效性直接影响项目的成功与否。

  对待变更的态度：
1、变更是不可避免的。
2、变更必须被管理。
3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。

需求变更管理的目标：
1、相关的干系人必须清楚地了解发生的变更。
2、变更处于有效的管理中。
3、尽量降低变更带来的风险。

  通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。

  需求变更流程：
1、确定需求的基准线。
 通常我们会以User Case作为需求基准线，在User Case确认之后的任何需求改变，都需要走需求变更流程。没有走需求变更流程的需求将不被认可。

2、首先项目经理接收到需求变更的要求。
  需求变更的提出者可以是项目中的任何人包括产品经理、客服、开发人员、测试人员等。
 
3、项目经理评估该需求变更。
  项目经理可以召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。
 项目经理作为项目的负责人，对项目的成功负有主要的责任。所以需求变更的决策者应该由项目经理承担。
 
4、需求变更确认后由专人将需求变更记录下来(格式如下)，通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括（客户方代表，需求分析师，测试人员，相关开发人员）。
需求变更表的格式：

序号

变更提出时间

变更描述

变更类型(是对原有需求的修改还是新增需求)

原因

变更提出者

开发人员

对进度的影响（工作量）

5、相关人员接收到确认的需求变更后，做以下事情。
需求分析人员修改需求说明书和User Case的相关内容。
测试人员修改测试用例的相关内容。
开发人员修改代码中的相关部分。

6、需求冻结
 项目越到后期，需求变更对项目的影响就越大，所以在一定时候我们会进入需求冻结阶段，不再接收需求的变更。

 

web项目经理手册-项目经理的工作内容

 

一、项目经理的目标
1、满足项目利害关系者的不同需求。
清晰明确地了解每一个项目利害关系者的需求和期望,投其所好。
项目利害关系者包括：项目团队成员和项目团队外成员(比如各部门的部门经理，客服等)。
2、保证开发项目按时保质的完成。

二、项目经理的职责
1、建立有效的流程保证项目的顺利进行。
2、制定详细周密的项目计划。
3、跟踪，推动项目按计划进行。
4、积极解决项目过程中出现的问题和冲突。
5、调动开发团队的积极性，创造力，推动团队成员在项目过程中不断成长。

三、项目经理的具体工作

1、项目前期阶段
  . 技术可行性分析，对项目进行技术评估、成本评估以及风险评估。
 . 与需求方代表进行需求讨论，明确项目的目标、价值；确定项目范围、功能及优先级。
  . 组建项目团队，特别要搞清楚项目的key person(对产品有决定权的人)。
  . 项目启动会议。

    通常项目成员包括以下人员：项目经理、架构师、技术经理、产品经理、开发工程师、DBA、测试工程师、需求分析工程师、UI、文案、SQA、SCM。
   
阶段输出物：确认后的最终需求文档
       
2、分析设计阶段
. 制定项目进度计划，工作任务分解(WBS)。
. 资源申请-项目涉及到的开发资源、测试资源、设计资源。
. 数据库设计。
. 系统设计。
. 文档(包括UC、Demo、TC等)评审会议

阶段输出物：
(1) User Case
(2) DEMO
(3) 系统设计文档
(4) 数据库设计文档
(5) User Case等文档评审
 
3、执行阶段(开发、测试)
. 准备开发环境、测试环境。
. 跟踪，推动项目按计划进行。
. 通报项目的进展情况，通常以周报的形式。
. 对项目的阶段成果进行评估，以确保该阶段完成的质量，包括代码审核、SQL审核等。
. 对需求变更进行控制管理。
. 对项目风险进行管理。
. 测试阶段客户验收、收集反馈意见。

4、发布阶段
. 制定项目发布计划。
. 用户培训。
. 发布上线。

5、上线后监控
. 数据监控(日志、服务器状态)。
. BUG FIX及改进。

5、结束阶段
. 项目总结会。
. 产品交付。

 

web项目经理手册-项目经理需要铭记在心的话

 

1、项目经理不是来管人的，而是来支持人的。
        解析：不光是项目经理，任何经理的职位都是如此。但现实中很多人并不是那么做，这也是为什么他们没能把项目做成功的原因。作为项目经理首先要端正态度，认识到这份工作职责的本质。

2、好的开始是成功的一半。
        解析：一个好项目的失败，往往是由于前期的准备不足、计划不周密。所以在项目初期要舍得花时间做前期的需求收集、讨论、技术准备等工作。尽管前期的工作看起来并没有直接产生效益，但这块工作做好了，后面的工作往往会事半功倍。否则前期准备不足，很可能导致项目出现各种各样的问题（比如大量的需求变更等）。

3、什么样的项目最可能成功？答案是：项目越小成功的可能性越大。
       解析：项目经理和相关人员要仔细评估项目中feature的成本/价值比，尽可能缩小产品的规模。
      有时候项目经理可能改变不了整个项目规模，但是项目经理可以采用各种手段来“缩小”项目，比如分期进行、迭代开发等。
 
4、任何对项目的改善无关的工作都是浪费时间。
       解析：在项目过程中项目经理不要做表面工作，或者对项目本身无意义的工作。比如无休止的会议；要求编写详细而最终没有用处的文档。
 
5、使用者的参与是项目成功的重要保证。
      解析：使用者可以是：产品经理、需求方代表、或者客户。
      在项目的各个阶段，项目经理要积极要求使用者参与到项目过程中。通过这种与使用者不断的沟通、反馈，使得最终做出来的产品是客户真正想要的。

6、不要认为把任务交给团队成员，期间你可以不闻不问，到了完成的时间他自然会把任务交上来。这种想法是非常错误。
       解析：这样做无疑会增加项目的风险，很容易出现该完成的任务没有按时完成，有些延误，这样项目后续的工作都会收到牵制。
      正确的做法是：当把任务安排下去后，你要定期和成员沟通完成的情况，询问是否需要支持，这样我们才能保证任务能按时保质的完成。

7、沟通要诀：项目过程中与相关人员沟通时，不要总认为对方的出发点都是从项目利益考虑，他/她一定先考虑个人利益或部门利益，所以项目经理要做的是：如何把对方的个人利益(部门利益)引导到和项目利益一致。

8、“加班”是一个危险的信号，表明一定是某个地方出现了问题，要找出进度落后的原因。

9、项目开始前，项目经理一定要找出项目的决策者是谁，谁对项目的产品有最终的发言权。

10、我们交付的不是程序，而是产品和服务。 

 

web项目经理手册-风险管理

 

         风险管理是web项目中项目经理最重要的工作之一。风险管理是一个持续的过程，贯穿于整个项目过程中，风险管理包括风险识别、风险估计、风险解决以及风险管理策略。
   
        在实际web项目中，项目风险主要表现为以下情况。了解这些有助于项目经理在项目初期就识别出这些风险，并采取措施避免或者减少它们的发生。

一、web项目风险列表：
1：需求变更风险：需求已经打上了基线，但此后仍然有变更发生，对项目造成影响。
       如何减少此类风险的发生？
(1) 前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。
(2) 需求文档中要有demo。对于web项目，图片比文字更能说明问题。
(3) 找出项目中需求的决策者(通常会是产品经理、相关职能主管、客服)，所有的需求要经过他们的认可。
(4) 客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、User Case确认、测试阶段的客户验收等环节，都要要求客户参与。
(5) 发生需求变更时，严格按照需求变更流程执行。

2、技术风险：开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。
     如何减少此类风险的发生？
     在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，可以要求需求方变更需求。

3、质量风险：对于web项目而言，质量风险主要指开发代码的质量。
       如何提高开发人员开发的质量？
(1)、制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响很大。开发时间评估可参考【web项目经理手册-开发时间估算】。
(2)、有一套严格可行的代码规范，编码时严格遵守，code review时严格考核。
(3)、在编码前，开发人员要对框架熟练掌握。
(4)、一份好的系统设计文档对指导开发非常重要。

4、资源风险：项目所需人力资源无法按时到位，导致资源风险。
如何减少此类风险的发生？
这个就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。

二、项目风险管理的要点：
1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生的风险不属于风险管理的范畴。这也说明项目经理的经验和知识对能否管理好风险至关重要。
2、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的必要条件。
3、风险报告是项目团队以及领导了解项目风险的一个有效手段。
风险报告的格式通常是：

序号

风险简介

对项目的影响

解决方案（对策）

web项目经理手册-跨部门合作项目

 

       web项目中有很多项目涉及到跨部门、跨公司的合作。这类项目往往比其他项目更有挑战。对于项目经理如何做好这些项目呢？
       首先让我们看看这类项目都有哪些共同的特点。
1、合作双方工作在不同地方，对项目沟通造成一定影响。
2、合作双方隶属于不同的公司或者部门，双方的项目开发流程可能完全不同，在项目执行过程中需要考虑到这个因素。
2、合作项目需要双方共同完成，如果一方的工作进度出现延误，那么整个项目的进度都会收到影响。

      本人根据平时这类项目的实施经验，总结一下这类项目要想成功，需要把握的原则。
1、合作双方的领导层必须都非常重视这个项目。剃头挑子一头热的项目成功的可能性不会高。
只有这样，项目的优先级才有保证，这样在以后项目过程中一些资源（包括人力、硬件、时间投入）更有保证，配合起来也会更加顺畅。

2、合作双方确定好各自的接口人。双方的沟通都通过接口人进行，这样可以降低成本，提高沟通的效率。
接口人可以分为两类：一类是商业上的接口人，一类是技术上的接口人。

3、完备的文档(接口文档、数据库文档)必不可少。
web项目双方的合作在技术方面通常采用API接口方式交互。所以项目前期详细准确的接口说明文档非常重要，双方开发人员之后的开发都是严格按照接口进行。
同时接口的相对稳定也是非常重要的，所以需要前期设计的时候认真全面地考虑接口规范。
 
4、便利的沟通工具。
 对于跨地区的合作，便利的沟通工具是非常重要的。当然工具最好是免费，比如使用IM。从沟通方式的效果来看，我觉得面对面的沟通>电话沟通>EMAIL(or IM)。

5、接口变更的及时通知。
这一点很重要，接口变更应该有流程来保证，特别是对于这种成员分散在不同地方的团队尤为重要。
 
6、前期技术方案的沟通。
前期技术方案的讨论以及接口的定义，最好能当面沟通，这样效果最好。所以前期最好去一趟对方公司商谈这些要点。

7、各自开发环境的可访问问题。解决双方开发环境的相互调用问题。
合作双方联调的时候通常需要访问对方的接口。由于双方都在各自环境进行开发，所以需要解决这种问题。
最好的情况是：可以访问对方的环境(外网)。
最大的风险是：没有可以联调的环境，等到发布到正式环境上再测试，这时候时间上就有点晚了，可能会遇到一些之前预想不到的问题。所以联调的时间越提前,问题就能越快暴露出来，整个项目的风险就越小。
联调环境的稳定也非常重要。有一次我们发现我们的功能有问题，代码跟踪调试，结果发现原来对方的环境有问题，浪费了我们很多时间。

8、由于项目的各个点是互相依赖的，所以在一些关键点上要能按时提交，否则会影响对方的进度。
在项目计划中要详细定义各个重要的里程碑，并严格控制执行。

9、项目进度报告。
定时相互通告项目进度，重点关注项目风险。

10、熟悉对方项目开发的流程。
不同公司项目的流程、角色分工不一定相同。只有熟悉了对方项目的流程，在与对方沟通时候才能做正确的事情。所谓知己知彼，才能百战百胜。
千万不要自己闷头开发，完全不顾对方的做事方式，然后自己想当然他们应该和我们一样。

 

 web项目经理手册-你会沟通吗？

 

序号	项目干系人	其对项目的主要期望	在本项目中的利益程度 (H, M, L)	对项目的影响程度 (H, M, L)	与其沟通的策略
1
2
3
4
5