软件开发项目管理实施方案

项目管理实施方案作为一个项目管理者， 如何要成功的做好项目管理； 首先必须先要明白的是在特定的领 域中赋予这个角色所要实现的目标、 承担的职责、 以及项目管理者的具体工作内容是什么？从我个人的浅见和角度以及我们所从事的 IT 领域来分析回答以上三个问题。第一：目标作为一个项目的管理者， 必须要明确的知道自己的工作目标； 我个人认为项目管理者的 目标无非就是以下两点：1、就是清晰明确地了解项目利害关系者的需求和期望，努力做到满足项目利害关系者 的不同需求；项目利害关系者包括：项目团队成员和项目团队外成员（比如各部门的部门负责人和市场人员，客户等 ）。2、就是保证开发项目按需按时保质的完成。第二：职责作为项目的管理者， 首先要端正态度， 要明确知道自己的工作职责， 认识到这份工作职 责的本质。 项目管理者不是来管人的，而是来支持人的， 是来协调资源的， 是来营造一个适 合团队成员比较认同的工作环境和氛围的， 是来为一个共同的目标和大家一起战斗共同成长 的。可以大概概括成以下几点：1、建立有效的工作流程保证项目的顺利进行。2、制定详细周密的项目计划。3、跟踪，推动项目按计划进行。4、积极解决项目过程中出现的问题和冲突。5、调动开发团队的积极性，创造力，推动团队成员在项目过程中不断成长。6、项目风险识别、 风险评估、 风险解决和风险管理策略以及做好突发风险的应急预案。7、实现目标第三：项目管理者的具体工作内容最后一个是项目管理者的具体工作内容， 作为项目管理者必须清晰的知道自己的工作范 围和所要做的工作内容以及工作重心，分为以下六点：1、项目前期阶段对项目进行技术可行性分析、 技术评估、 成本评估以及风险评估。 与需求提出方的 代表进行需求讨论，明确项目的目标、价值；确定项目范围、功能及优先级。组建项目 团队，特别要搞清楚项目的 key person（ 对产品有决定权的人 ）。项目启动会议，相关的利害关系人员都必须参加。 该阶段完成后的成果：确认后的最终软件需求规格说明书文档。2、分析设计阶段根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解 （WBS）;资 源申请，项目涉及到的开发资源、测试资源、设计资源 （包括人员和软硬件资源 ）；数据 库设计；系统设计；文档 （包括Use Case Demo系统原型、Test Case等）；评审会议。该阶段完成后的成果：A、User Case係统用例）；B、DEMO（系统原型）；C系统设计文档（概要设计和详细设计）；D、数据库设计文档。最后对完成的成果，包括 User Case和设计文档等进行评审。3 、执行阶段 （ 开发和测试 ）准备开发环境、 测试环境；跟踪，推动项目按计划进行；以周报的形式通报项目的 进展情况。 对项目的阶段成果进行评估， 以确保该阶段完成的质量， 包括代码审核、 SQL 审核等。对需求变更进行控制管理； 对项目风险进行管理； 测试阶段BUG FIXED及改进、 收集反馈意见。4、发布阶段包括制定项目发布计划，用户培训，发布上线。5、上线后监控数据监控（日志、服务器状态），根据监控出现的问题，及时进行 BUG FIXED及改进 或做补丁升级。6、结束阶段产品交付，项目总结会。第四：基于以上三个问题所做的应对细则要做好项目管理，并能确实解决好以上三个问题， 实现目标、 履行职责、完成工作中的具体内容， 从我个人这几年的工作经验和面临的一些问题， 还有所积累的一些项目管理中的一些知识以及自己的观察和思考的角度看，应该要努力做好以下这几个方面的具体工作：1、项目开发时间的估算制定项目进度时间表的时候， 需要估算每个任务所需的时间， 其中开发任务中模块的分 配和时间估算是其中最主要的部分；在分配模块和估算开发时间时需要遵循的原则和目标：1、保证项目整体的进度。2、有助于确保开发编码的质量。3、有助于提高开发编码的速度。在公司现有的技术框架下， 开发人员主要的工作是投入在具体的商业逻辑上。 通常每个 模块所需的开发时间取决于以下三个因素：1、所负责模块的商业逻辑的复杂程度。2、开发人员的技术水平和对项目所在应用的熟悉程度（包括对框架和应用的熟悉程度 ）。3、该模块技术实现上是否有技术难点；这里所谓的技术难点定义是：在现有系统中还 未实现的、 开发人员自身也未没接触过的技术。 对于这样的难点， 开发者没有相关的代码可 以参考，自己也没有经验，所以需要投入一些时间研究解决。模块分配和开发时间估算的步骤：1、在划分好模块后，首先自己先估算一下每个模块所需要的开发时间。2、然后召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，让开 发人员从中挑选他们感兴趣的模块。 这样做可以提高开发人员的主动性和参与性。 在分配模 块的时候还需从以下几方面考虑，以确保开发的速度和质量：A、 相同类似的模块由同一人负责开发，比如用户管理的增删改由同一开发者负责。这样做的好处就是开发者对相关逻辑会更加熟悉， 同时接口的定义也会比较明确， 沟通 的成本比较低，同时功能实现的缺陷也相应的会降低。B、技术难度比较大的模块由技术水平比较高的人负责。C业务逻辑比较复杂的由对这块逻辑比较了解的人负责。3、模块分配完后，开发人员评估自己负责开发的模块所需要的时间。在此过程中最好 做到要和开发者比较详细的讨论每个模块的技术实现，以便使时间的估算更加准确。4、对开发人员估算的时间进行确认。在确认过程中作为项目管理者应参考以上提到的三个因素， 同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的， 将与技术人员探讨其中的缘由。 对于时间周期比较长的任务， 尽量将任务通过再细分的手段细化任务， 争取每个任务的最长时间不超过 3 天；时间周期越 长的任务，不确定性越高，风险也越高，越有可能成为项目的瓶颈，影响项目的进度。2、 Code ReviewCode Review 是保证项目中代码质量非常重要的一个环节，在这一环中我们公司做的非 常欠缺， 把关不严格； 这是导致每次测试后出现大量 bug 的主要原因， 这一环需要纳入绩效 考核中，实行责任追究制，实施重点监控。出现这样的薄弱环节，造成这样的原因，我想也 是有很多因素造成的； 比如开发人员对需求不是很明确， 以自己比较主观的因素去完成任务 的；还有对整个系统业务逻辑没有正确的清晰的认识的原因，以及对项目组成员培训不到位的原因等众多因素纠集在一起才产生的。如何做好这方面的工作？首先编码要有“编码规范”文档，Code Review 要有“代码审核规范” 文档：记录代码实现应该遵循的标准。 通过这两个文档来规范开发人员的代码实现， 代码编写者必须要严格按照规范来进行；代码审核者根据这些标准来Code Review代码，同时在 Code Review 过程中不断完善该文档。在做好这些前期工作的前提下，分以下几个步骤来实施：1、检查开发者的代码实现是否遵循了编码规范。2、从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。3、 代码编写者和代码审核者坐在一起，由代码编写者按照 Use Case依次讲解自己负责 的代码和相关逻辑，从 Web 层-到 Manage 层再到 Dao 层；4、 代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug;对这 些 bug 记录在案。5、代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要一 行一行静下心来看。同时代码又要全面的看，以确保代码整体上设计优良。6、代码审核者根据审核的结果编写“代码审核报告” ，“审核报告”中记录发现的问题 及修改建议，然后把“审核报告”发送给相关人员。7、代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方 可积极向代码审核者提出。8、代码编写者 bug fixed 完毕之后给出反馈。9、 代码审核者把Code Review中发现的有价值的问题更新到代码审核规范的文档中， 对于特别值得提醒的问题可群发 email 给所有技术人员。如果通过以上步骤，还因为是代码编写者的原因而出现严重的缺陷问题， 将通过绩效考核来加深代码编写者的印 象，并在周报会议上做通报批评。3、需求变更管理需求变更管理也是项目管理中最重要的一个环节， 对需求变更管理的有效性将直接影响 项目的成功与否。对待需求变更的态度：1、需求变更是不可避免的。2、需求变更要必须被管理。3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。 需求变更管理的目标：1、相关的干系人必须清楚地了解发生的变更。2、变更处于有效的管理中。3、尽量降低变更带来的风险。通过制定需求变更的流程， 确保项目中的需求变更有效地进行， 实现上述的目标。 需求 变更流程：1、确定需求的基准线。将以 User Case作为需求基准线，在 User Case确认之后的任何 需求改变，都需要走需求变更流程，这一环节我们基本没有，期间有时候使的工作很混乱， 也就是因为没有一个规范的变更流程而造成的； 如果建立了这么一个流程规范和机制， 需求 变更没有走这个流程的将不被认可。2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括 产品经理、市场人员、开发人员、测试人员等。3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该 需求变更的合理性、 可行性，实施的代价以及对项目的影响。 包括可能影响的项目范围，进度，费用，质量等计划。项目管理者作为项目的负责人，对项目的成功与否负有主要的责任。所以需求变更的决策者应该由项目管理者承担。4、需求变更确认后由专人将需求变更记录下来，通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的，他们必须知晓并认可此需求变更。包括（客户方，需求分析人员，测试人员，相关开发人员）。需求变更记录格式如下：序 号变更提出时间变更描述变更类型（是 对原有需求 的修改还是 新增需求）原因变更提出者开发人员对进度的 影响（工 作量）125、确定变更的负责人。承担需求变更的具体工作，比如基线控制，对需求变更的记录, 并通知相关人员。6、相关人员接收到确认的需求变更后，做以下事情。需求分析人员修改需求说明书和 User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部 分。7、按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现 的问题及时沟通和处理。8、需求冻结。项目越到后期，需求变更对项目的影响就越大，所以在一定时候要进入 需求冻结阶段，不再接收新需求或需求的变更。4、风险管理风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程，贯穿于整个项目过程中，风险管理包括风险识别、风险评估、风险解决以及风险管理策略。在项目的实施过程中需要不断地识别和应对风险，并加以有效的控制， 风险管理的好与坏直接影响项目的实施效果，从某种意义上讲，项目实施对于项目管理者就是识别、分析、 应对、控制风险的过程，使项目的约束性目标和质量目标朝有利的方向发展。项目不同于日常任务，它有明确的起止时间和目标，要在明确的范围、时间和成本约束下，达到相应的质量标准，并取得用户的满意。影响项目成败的因素涉及方方面面，并且风 险伴随着项目的始终，是客观存在的，作为一个项目管理者，应该具备良好的风险控制意识， 善于识别风险并分析风险的影响， 从中发现影响目标的风险点， 并施加影响或采取应对措施， 把风险的负面影响降到最低，并且风险控制应该贯穿项目始终。风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、 缺乏良好的团队协作等。 下面将详细描述一下这些问题以及出现这些 问题时的应对方案：1、目标以及需求不明确为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有形成正式的业务需求文档，在没有明确的需求范围的情况下，有时为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法， 技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。 所以，在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、 需求范围，充分考虑现有的时间和资源约束，将需求排定优先级， 对于关键的需求优先实现， 其他辅助性的根据过程中的具体情况进行滚动式计划， 并取 得业务部门的书面确认。 在此过程中要注重挖掘用户的隐性需求， 可以通过引导、 系统 原型等手段让用户在前期充分暴露自己的想法和需求。2、范围蔓延以及需求变更在有了明确的目标和需求范围的情况下， 需求的变更还是不可避免的， 业务部门在 看到具体系统的真实雏形之后， 源源不断地要求、 新想法随之产生， 如果不对此加以控 制，新的需求的加入通常会影响已实现的需求， 并且对项目进度和成本产生很大的影响。 项目管理者针对这种情况一定要采取严格的变更控制流程， 不能碍于面子， 否则最终的 结果往往是出力不讨好。 针对用户提出的新需求， 按照正式流程提出变更申请， 组织相 关团队成员进行分析及评估， 作为是否实施的依据， 变更控制负责人根据分析结果判断 是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际 情况下可以采取一些软措施缓解矛盾。需求变更风险：需求已经打上了基线，但此后仍然有变更发生，对项目造成影响。 如何减少此类风险的发生？前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。 找出项目中需求的决策者 （通常会是产品经理、相关职能主管、客户），所有的需求要经过他们的认可。 客户在项目过程中的全程参与有助于降低此类风险。 需求讨论、 需求确 认、 User Case 确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变 更时， 严格按照需求变更流程执行。 在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。3、代码质量或返工风险质量风险主要指开发代码的质量。 如何提高开发人员开发的质量？在制定项目计划 时，对开发时间的评估要尽可能的合适。 合理的开发时间对开发质量的影响也很大。 有 时开发人员为了赶进度在比较紧张的时间需要完成指定的任务， 可能就存在很大的开发 质量问题。 开发要有一套严格可行的代码规范，编码时严格遵守， 到现在为止，我们这 个方面做的不是很规范， 做的也很不足， 大家编写的代码随意性比较大， 代码编写者的 主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范， code review 时严格考核。 在编码前， 开发人员要对框架熟练掌握； 一份好的系统设计文档对 指导开发非常重要。返工是项目组最不愿意看到的， 既浪费人力、 物力和财力，又影响团队积极性。需 求不明确或范围没有有效控制都可能造成返工， 另外造成返工的原因是质量没有达到用 户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是 100%完成， 但一到最后系统交互测试或集成的时候就会发现一大堆问题， 不得不花费很大精力回头 排查、修改程序， 造成这种情况的主要原因是过程中质量保证没有做到位， 把大部分问 题留在了后面。 这就需要在项目实施过程中采取有效的措施来规避返工的风险， 通常的 做法有同行评审， 比如概要设计完成之后， 邀请其他项目组的技术专家进行技术评审以 发现架构设计问题； 管理评审， 通过组织级的质量审计看产品以及实施过程是否满足质 量要求； 代码走查， 在编码过程中加入至少一次的代码走查， 排查不符合规范或性能要 求的代码，走查通常能够发现 50%-70%的错误；每日构建，这是一种非常有效的方法， 可以避免把各部分的集成问题拖到最后， 并且能够及时发现相应的错误， 日构建一般在 项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。4、人员技能和资源的不足项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见， 一个 熟练的技术人员完成同样一个任务需要 3 天，但一个生手可能就需要 7-10 天。项目管理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训， 以保证项目的顺利实施。 如果对于项目中某些部分专 业性特别强或新技术，短期内又不能快速建立技能的情况，可以考虑将该块任务外包， 借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分 析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何减少此类风险的发生？在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风 险在后期或中期出现。项目所需人力资源无法按时到位，导致资源风险。如何减少此类风险的发生？这个就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。5、缺乏良好的团队协作软件项目实施属于知识型， 要发挥团队成员的创造力， 不同于制造业计件生产， 各 模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。 这是一个团队的软实力， 团队之间的协作好坏也将是个潜在 的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。项目风险管理的要点：1、 上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生 的风险不属于风险管理的范畴。这也将是考验一个项目管理者的经验和知识对能否管理好风险至关重要的内容。2、对不可预期的风险，项目管理者要有潜在的风险意识评估，做好一些可操作性的预 案准备。3、详细明确的项目计划、 以及项目执行过程中每个要点的质量保证是降低项目风险的 必要条件。4、风险报告是项目团队以及领导了解项目风险的一个有效手段。风险报告的格式:序号风险简介对项目的影响解决方案或对策5、团队管理团队就是一组个体为实现共同的目标而相互依赖、一起工作的共同体。团队工作顾名思义就是团队成员为实现这个共同的目标而付出的共同努力，项目团队的工作是否有效直接关系到项目的成败。团队管理是个渐进的过程。 世界上只有完美的团队， 没有完美的个人。好的高效的团队 不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化， 这需要大家共 同的努力。1、营造良好的工作环境和氛围。2、建设优秀或鲜明的团队文化。3、保持高效的沟通。6、项目会议组织会议是项目管理者日常工作中一项非常重要的工作任务， 项目过程中很多重要的决 定都是在会议中做出的，也有很多由于不成功的会议而对项目本身造成了不好的影响。首先看看不成功的会议常常表现为哪些形式：1、会议氛围不好，参与者发言不踊跃；2、会议讨论常常偏离主题；3、会议没有取得预期的结果；4、会议时间常常一拖再拖。 这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的， 很多人都对这样的会议都有抵触情绪， 对此也是深恶痛绝。 以下是组织会议时应该注意的问 题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：1、会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有 可能取得成功，这是会议成功的充分条件。2、会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要 希望会议的参与者和你一样， 对会议有着如此的期待， 对大多数参与者而言， 在会议中他只 是一个发表想法的人，他不用对会议的成功承担责任。3、以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。 组织会议的十一条最佳实践：1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。2、提前发出会议议程，以便会议参与者知道他们来做什么。3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确 保必要人物都在的情况下一次会议参与者越少效果越好。4、提前预约参与者的时间，以确保他们能按时到场。5、会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在 开场时说：A、再一次强调会议的目标，我们来做什么。B、 强调会议的主题与基调。 比如：本次会议是一个需求确认会， 而非需求讨论会， 主要是讨论做还是不做以及告知大家我们要做什么， 而不要把太多的精力放在讨论 如何做上面。C说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人 的讲 话，等别人说完你再说等等。6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围 是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成 果之一。8、 会议要有结论。我们常在会议上听到有人说： 大家讨论了这么半天，结论呢？ 。 没有结论的会议是没有意义的。9、 会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。10、会议后的 action 执行情况的反馈很重要。 反馈是对会议参与者的尊重， 同时也告知 了会议的效果。 否则会让大家感觉到这是一个可无可无的会议， 大家以后参与的积极性 也会降低。很多会议往往都不注意这一点。11、按时结束的会议会受到所有人的欢迎。7、版本控制版本控制也是项目管理者的一个重要工作内容之一， 一个项目或产品的完成不可能是一 步到位的， 在项目完成的后期可能会有多个不同的版本的发布 （开发版本， 测试版本， 发布 版本等）。需要做好版本的管理和控制。8、项目总结在项目完成后，总结整个完成项目的过程和经历，为下一次的项目启动提供参考经验， 完善不足，避免在类似的项目中出现可能存在的相同的错误发生。