关闭

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

1273人阅读 评论(0) 收藏 举报
分类:

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

  下图是我们所有项目应该严格遵守的流程。



   流程-需求

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

  一个项目的需求入口必须只能是一个人——项目经理。相信很多项目都遇到过这种情况,客户好像跟有的开发人员很熟悉,有时候客户会把需求告诉开发人员,开发人员就自己做了,结果项目经理不知道。这就会出很大的问题。所以,不管来自内部还是外部的需求,所有的需求都只能经过项目经理

  流程-原型

  原型用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

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:43157次
    • 积分:818
    • 等级:
    • 排名:千里之外
    • 原创:28篇
    • 转载:66篇
    • 译文:0篇
    • 评论:1条
    最新评论