项目管理之如何控制项目进度和质量

　　控制项目进度和质量首先在总体上要有一个合理清晰的流程，而且在整个管理过程当中，严格按照流程走。流程的每一步若是都控制好了，那么整个项目管理就不会出大问题。

　　下图是咱们全部项目应该严格遵照的流程。

　  流程-需求

　　需求是整个流程的入口。一般需求从客户那里来，而客户一般不是那么专业，客户发过来的需求可能很零散，甚至可能不合理，这时，项目经理须要对需求进行整理，而且屡次不断跟客户沟通，保证正确理解了需求。

　　一个项目的需求入口必须只能是一我的——项目经理。相信不少项目都遇到过这种状况，客户好像跟有的开发人员很熟悉，有时候客户会把需求告诉开发人员，开发人员就本身作了，结果项目经理不知道。这就会出很大的问题。因此，无论来自内部仍是外部的需求，全部的需求都只能通过项目经理。

　　流程-原型

　　原型用axure画，不论是web、desktop仍是APP，都用axure画。目前为止没有比axure更强大的原型工具。

　　在咱们的经验中，导出成网站的原型，能够做为需求管理很重要的一部分。因此，每一次需求的变动都应该首先体现到原型中，原型必定要一直维护下去。

　　画原型的一个最最重要的经验就是，要把全部的UI都体现出来。包括哪些呢？各类状态下的界面，全部的错误或者提示，也就是说凡是最终用户看得见的东西，所有要体如今原型中。

　　因为原型自己仍是需求管理系统的一部分，因此，原型页面上也能够放一些业务逻辑说明，特别是页面跳转等。还有一些隐藏的业务逻辑也能够在原型页面上写出来。

　　流程-UI设计

　　原型作好了以后，就可让UI团队开始基于原型作设计了。设计作好了就切图。设计团队的产出物为设计源文件、效果图和切图。放到SVN里面供开发人员使用。

　　流程-测试用例

　　原型作好了以后，测试团队就能够基于原型写测试用例了。若是没有测试团队，这一步也可省去。

　　流程-任务系统

　　这一步是很是关键的，其中最重要的工做就是功能评估。功能评估建议用Xmind软件来作，评估好了再录入到咱们的任务系统。参考：

　　若是项目经理不是项目所需技术领域的专家，那么在评估的时候，叫上技术团队领头人一块儿。可是一个好的项目经理，即便是本身不熟悉的技术领域，本身也应该有一个比较准确的评估。

　　任务评估时间还应该包含开发人员自测的时间。

　　当任务都评估好了，就能够录入到咱们的任务系统了。录入任务系统以后，就是作迭代计划。

　　在咱们的任务系统中，开发计划是经过迭代来作的。建议每一周提一个迭代，最多不超过2周一个迭代。开发人员只须要关心当前这一个迭代里面的全部任务，至于具体先完成哪一个任务，如无特殊要求，都应该让开发人员自行安排或者项目经理给一些建议。

　　每个迭代要求明确的开始和结束日期。一旦结束日期到，就应该把迭代里面未完成的任务移到下一个迭代。也就是说，迭代日期到，迭代的进度就是100%。对于有些只完成了一部分的任务，在咱们的任务系统中，要么你能够拆分任务把已完成的部分拆分出来，要么你也能够把整个任务移到下一个迭代。

　　开发人员完成功能开发以后，首先要通过全面的自测。一个聪明的开发人员应该在自测的时候解决绝大多数BUG。通过自测的产出物应该是具备很高质量的，特别是高质量的UI和UX。自测经过才能提交给测试团队，或者项目经理。作不到这一点的开发人员应该被淘汰。

　　自测完成以后，填写工时记录，将进度标记为100%，将任务状态标记为完成（不是关闭）。

　　流程-测试

　　若是没有测试团队，测试就应该由项目经理负责。

　　测试中报的BUG要提交到任务系统。测试人员提交BUG的时候不须要评估时间，而且也不须要指派。项目经理把全部未指派的BUG列出来，而后进行时间评估，而后再指派给某个开发人员。

　　BUG也是属于迭代的。若是不是那么紧急的BUG，能够暂时不安排到迭代里面，能够等到最后再去修复BUG。

　　流程-完成

　　测试团队测试经过，项目经理能够根据实际状况看是否须要再检查一遍。或者检查的力度到什么程度，这都由项目经理自行决定。检查经过，任务状态标记为关闭，任务完成。

　　问题 – 团队间等待

　　开发过程当中，可能各个技术团队之间的衔接会出现等待。好比客户端开发的开发人员，在作到某一个功能的时候，结果UI设计或者API尚未准备好，那么就只能等起。

　　这种衔接等待是没法避免的，咱们只能尽量下降等待的时间。咱们是这样解决的：

　　在咱们的任务系统中，咱们会加一个任务标签，叫“紧急任务”。注意这里是标签，不是优先级也不是任务类型。一旦出现这种等待，等待的人就给被等待的人建一个“紧急任务”。若是等待的人没有新建任务的权限，那么交给其团队负责人建立。咱们也建议你把这类任务同时放到一个任务分组里面，而且加个快速查询。

　　等待的过程当中，开发人员能够用假数据或者假UI来代替，等数据或UI准备好后再替换。

　　问题 – 需求变动

　　需求变动是任何开发团队都没法避免的问题。咱们要作的就是把需求变动对项目形成的影响尽量降到最低。

　　一般状况下，只有最紧急的需求才会放到当前的迭代，不然变动的需求都应该放到之后的迭代。若是放在当前的迭代，那么就须要把当前迭代中的部分任务移到下一个迭代。而且跟客户沟通好这个计划的改变。

　　需求变动时，必定要将需求更新到需求管理系统（原型和任务系统），无论变动的需求形成的工做量有多大。这一点是不少项目忽略的。举个例子，用户完成注册，原本系统送100金币，某天客户过来讲改为送200金币，结果程序员就花了几分钟时间将100改为200了事。过了几个月，新同事加入项目，看需求系统里仍是写的100，就去问项目经理，项目经理就说何时改为200了。因而这个需求管理系统就再没有人相信和使用了。因此这一点很是重要。

　　需求变动时，要按照本文开始的流程图一步一步走，由于是新的需求从流程入口进来了。

　　项目管理中常常还会遇到其余棘手的问题，扰乱项目计划，让项目管理失去了对进度和质量的控制。

　　本文转载自：http://www.spasvo.com/news/html/2016826135059.html