WEB项目经理手册排版Word下载.docx

1、 一般的web项目的周期为13月，而一般的软件开发的周期都在半年以上，象vista微软花费了五年的时间才开发出来。2、web项目要求上线快。 互联网公司推出的产品，讲究快字当头，谁先推出产品占领市场，谁就取得先机，所以web的项目往往要求上线快，对于比较大的项目通常我们会先把产品先launch上线，然后第二期第三期再来完善。 “快”应该是web开发和通常的软件开发的最大区别，web产品的维护是在服务器端，这就使得这种快成为可能，我们可以很容易地随时升级产品，而通常的软件由于是部署在用户的机器上，升级的频率和幅度没办法与web产品比拟。 也正由于这个“快”，使得web项目的需求变更成为了web项

2、目管理中最需解决的问题。 web项目经理手册分为若干主题，每个专题从项目管理的某个方面介绍项目经理在这方面要做的事情，专题会陆续推出。 本手册为本人在项目管理中的经验总结，所以手册的内容也会不断完善中。 本手册的原则：1、指导性强。2、实用性强。 我一直崇尚这么一句话：把问题复杂化是为了帮助我们更好地理解这个问题，而把问题简单化是为了让我们更好地执行。所以本手册把简单可行作为标准。一个再好的流程如果不简单可行，最终也没法在实际工作中推广起来。当然简单的含义不是要少做事情，而是所做的事情让执行的人觉得就该怎么做，不这么做，质量就没法保证，并且执行起来很自然。对阅读者的要求：1、本手册来源与本人平

3、时项目管理的经验，不同公司有不同的特点，项目本身也有差别，本手册虽然阐述的是具有普遍性的问题，但是遇到一些具体特殊问题，大家还是要以实际情况为准，本手册可以起到参考作用。web项目经理手册-版本控制流程 大家在项目过程中是否会经常发生以下问题：1、测试人员在测试阶段更新测试环境时，发现编译不通过，或者应用出现异常，无法进行测试。后来发现的根源是测试和开发共用一个分支。2、有一天某个人群发了一条邮件通知，“我们的项目代码已经发到主干，这段时间大家不要修改主干信息”，这样影响其他项目的正常发布。3、项目进行了比较长的时间，等最后发布，需要与主干进行合并的时候，出现大量的冲突，几乎没法处理。而且冲突

4、处理完后我们还需要重新再做测试，以保证我们的冲突处理没有问题，这样又会需要花费大量的时间。版本控制流程目标：1、保证各个环境（开发、测试、主干）的独立，避免相互影响。2、减少最终发布时合并主干出现冲突的概率。3、降低冲突处理的难度。原则：多个版本（开发版本，测试版本，发布版本）；多次合并。流程：1、项目开发编码前从当前主干建立一条开发分支，供项目开发人员使用；2、开发结束，提交测试的时候，从当前主干建立一条测试分支，将开发分支合并到测试分支上，供测试人员进行测试。这样开发人员对开发分支的修改不会影响测试环境；3、bug fix的时候我们定时将开发分支的修改合并到测试环境中。3、回归测试的时候，

5、从当前主干建议一条发布分支，将测试分支合并到该发布分支上，在发布分支上进行回归测试。4、发布前，将发布分支合并到当前主干。好处：1、多个版本相互独立，互不影响2、通过多次与主干的合并，这样发布时候和主干做最后一次合并的冲突会大大减少，并且在与主干多次合并过程中的冲突解决都在测试阶段中得到了测试。建议：如果项目的周期比较长，和主干进行合并的次数也应该加大，以降低处理冲突的难度。 web项目经理手册-开发时间估算 项目经理制定项目时间表的时候，需要估算每个任务所需的时间，其中开发任务中模块的分配和时间估算是其中最主要的部分。本篇专门就这部分作一个阐述。一、在分配模块和估算开发时间时，我们需要把握的

6、原则和目标：1、保证项目整体的进度。2、有助于确保开发编码的质量。3、有助于提高开发编码的速度。二、每个公司都拥有自己的技术框架，开发人员主要的工作通常投入在具体的商业逻辑上。通常每个模块所需的开发时间取决于以下三个因素：1、该模块的商业逻辑的复杂程度。2、开发人员的技术水平和对项目所在应用的熟悉程度（包括对框架和应用的熟悉程度）。3、该模块技术实现上是否有技术难点。这里我把技术难点定义为：在现有系统中还未实现的有一定技术难点的问题。对于这样的难题，开发者没有相关的代码可以参考，需要投入一些时间研究解决。三、模块分配和开发时间估算的步骤：1、作为项目经理划分好模块后，我会自己先估算一下每个模块

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

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

9、研究。这样会节省以后项目时间，降低技术风险。web项目经理手册-Code Review Code Review是保证项目中代码质量非常重要的一个环节，其主要工作是：1、发现代码中的bug；2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。1、代码中的bug主要会出现在下列两个地方：（1） 与商业逻辑无关的bug。 比如，系统中打开的流文件连接等没有及时关闭；或是存在thread safe问题，或是存在性能低下问题等，这类问题对有经验的开发人员是比较容易发现的。2、与商业逻辑相关的bug。这类bug是非常隐蔽的，如果有对产品不熟悉的人参与该产品的项目开发，容易出现这类的bug。为了

10、避免这类bug的出现，我们除了在Use Case和Test Case中详细描述以正确指导开发人员并在测试时能及时发现它之外，Code Review也是不可缺少的保证环节。 我们希望代码的审核者对产品非常熟悉。3、什么样的人承担代码审核者Code Reviewer？（1）、比较熟悉相关商业逻辑。（2）、有丰富的编程经验。两者缺一不可。4、代码Code Review的步骤，这些是我在平时工作中的经验总结，目前也是按照这个步骤在做。（1）、代码编写者和代码审核者坐在一起，由代码编写者按照UC依次讲解自己负责的代码和相关逻辑，从Web层-DAO层；（2）、代码审核者在此过程中可以随时提出自己的疑问，同

11、时积极发现隐藏的bug；对这些bug记录在案。（3）、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。 代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。（4）、代码审核者根据审核的结果编写“代码审核报告”，“审核报告”中记录发现的问题及修改建议，然后把“审核报告”发送给相关人员。（5）、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。（6）、代码编写者 bug fix完毕之后给出反馈。（7）、代码审核者把Code Review中发现的有价值的问题更新到代码审核规范的文档中，对于特别值得提醒的问题可群发ema

12、il给所有技术人员。5、责任： 代码编写者，代码审核者共同对代码的质量承担责任。这样才能保证Code Review不是走过场，其中代码编写者承担主要责任，代码审核者承担次要责任。6、Code Review必备的文档： “代码审核规范”文档：记录代码应该遵循的标准。代码审核者根据这些标准来Code Review代码，同时在Code Review过程中不断完善该文档。web项目经理手册需求变更管理 需求变更管理是web项目管理中最重要的一个环节，需求变更管理的有效性直接影响项目的成功与否。 对待变更的态度：1、变更是不可避免的。2、变更必须被管理。3、积极发现引起变更的因素，促使变更尽可能早的出现

13、，减低变更带来的风险。需求变更管理的目标：1、相关的干系人必须清楚地了解发生的变更。2、变更处于有效的管理中。3、尽量降低变更带来的风险。 通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。 需求变更流程：1、确定需求的基准线。通常我们会以User Case作为需求基准线，在User Case确认之后的任何需求改变，都需要走需求变更流程。没有走需求变更流程的需求将不被认可。2、首先项目经理接收到需求变更的要求。 需求变更的提出者可以是项目中的任何人包括产品经理、客服、开发人员、测试人员等。3、项目经理评估该需求变更。 项目经理可以召集相关人员讨论该需求变更的合理性、可行性

14、，实施的代价以及对项目的影响。项目经理作为项目的负责人，对项目的成功负有主要的责任。所以需求变更的决策者应该由项目经理承担。4、需求变更确认后由专人将需求变更记录下来（格式如下），通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括（客户方代表，需求分析师，测试人员，相关开发人员）。需求变更表的格式：序号 变更提出时间 变更描述 变更类型（是对原有需求的修改还是新增需求） 原因 变更提出者 开发人员 对进度的影响（工作量） 5、相关人员接收到确认的需求变更后，做以下事情。需求分析人员修改需求说明书和User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关