精心整理管理目标1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。

2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。

3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。

执行概述1、2、3、跟踪设计/开发/测试/回归/4、/跨部门协调等几个方面。

5、6、风险识别、风险控制以及风险的预案。

项目管理1、需求阶段2根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。

设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。

该阶段交付成果需要进行评审。

3、执行阶段(开发和测试)准备开发环境、测试环境。

跟踪，推动项目按计划进行。

项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。

按里程碑对阶段成果进行评估，以确保该阶段完成的质量。

代码审核，包括CS审核、SQL审核、WEB审核等。

对需求变更进行控制管理。

测试阶段BUG响应及改进、收集反馈意见。

对项目风险进行管理。

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

5、试运行阶段数据监控(日志、服务器状态)定情况执行补丁升级。

6、收尾阶段产品交付，项目总结会。

常见问题1、开发时间的估算算，通常单个模块开发时间取决于以下因素：12(包括对框架和应用的熟悉程度)。

3开发者没有相关的代码可以参考，自己也没有经验，1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。

2、召集所有开发人员，讨论模块的分配和开发时间估算。

将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。

分配模块的时为确保开发的速度和质量，基本原则如下：A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。

这样开发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。

B、技术难度较大的模块由技术水平比较高的人负责。

C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。

3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。

在此过程中应与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。

4、对开发人员估算的时间进行确认。

在确认过程中作为，项目管理者将预估时间和开发人员估算时间进行比较。

那些差异较大的，与人员探讨其中的缘由。

对于时间周期比较长的任务，将任务拆分为更小的子任务，每个任务的完成时间为8-24工时，消除时间周期较长的任务，避免不确定性影响项目的进度。

2、CodeReviewCodeReview是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工；关于CodeReview执行，首先应有编码规范和代码审查规范。

代码审核者根据这些标准来CodeReviewCodeReview一般可按以下步骤实施：1、2、3、bug，对这些bug记录在案。

4、Bug。

同5、6、7、中发现的有价值的问题更新到"代码审核规范"的文档中，对于特别给所有技术人员。

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

对待需求变更的正确态度：1、需求变更是不可避免的。

2、需求变更要必须被管理。

3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。

需求变更管理的目标：1、相关的干系人必须清楚地了解发生的变更。

2、变更处于有效的管理中。

3、尽量降低变更带来的风险。

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

需求变更流程：1、确定需求的基准线。

将以UserCase作为需求基准线，在UserCase确认之后的任何需求改变，都需要走需求变更流程。

2、项目管理者接收到需求变更的要求。

需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。

3、项目管理者评估该需求变更。

针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。

项目管理者对项目的成功与否负有主要的责任。

需求变更的决策应由项目管理者做出。

45、确定员。

6的相关内7及时沟通和处理。

84、风险管理1人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。

在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。

在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。

2、项目目标扩大以及需求变更在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。

项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。

针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。

前期的需求讨论要详细、充分。

需求文档中需求的范围要明确、功能描述要清楚。

找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户)，所有的需求要经过他们的认可。

客户在项目过程中的全程参与有助于降低此类风险。

需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。

在发生需求变更时，严格按照需求变更流程执行。

在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。

3、代码质量风险质量风险主要指开发代码的质量。

合理的开发时间对开发质量的影响很大。

系统设计文档对指导开发非常重要。

43天，但一个新手可能就需要7-10天。

项目管理者应该在前的技能培训，以保证项目的顺利实施。

开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。

在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。

如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。

这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。

5、缺乏良好的团队协作软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。

这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。

6、项目会议组织会议是项目执行过程中一项非常重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，不成功的会议会对项目本身造成了不好的影响。

不成功的会议通常表现为如下形式：1、会议氛围不好，参与者发言不踊跃；2、会议讨论常常偏离主题；3、会议没有取得预期的结果；4、会议时间常常一拖再拖。

都对这样的会议都有抵触情绪，也可看作1得成功，这是会议成功的充分条件。

2议的参与者和你一样，对会议有着如此的期待，312345说：A、再一次强调会议的目标，我们来做什么。

B、强调会议的主题与基调。

比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。

C、说明一下会议的规则。

如要发言，请举手；不要有小圈子讨论；不要打断别人的讲话，等别人说完你再说等等。

6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。

一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。

比如多提一些开放式的问题。

7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。

8、会议要有结论。

我们常在会议上听到有人说："大家讨论了这么半天，结论呢？"。

没有结论的会议是没有意义的。

9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。

10、会议后的action执行情况的反馈很重要。

反馈是对会议参与者的尊重，同时也告知了会议的效果。

否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。

很多会议往往都不注意这一点。

11、按时结束的会议会受到所有人的欢迎。

？·。