zoukankan      html  css  js  c++  java
  • 如何控制项目进度和质量

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

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

    流程-需求

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

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

    流程-原型

    原型用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了。于是这个需求管理系统就再没有人相信和使用了。所以这一点非常重要。

    需求变更时,要按照本文开始的流程图一步一步走,因为是新的需求从流程入口进来了。

    项目管理中经常还会遇到其他棘手的问题,扰乱项目计划,让项目管理失去了对进度和质量的控制。欢迎大家提出讨论。

  • 相关阅读:
    leetcode--Populating Next Right Pointers in Each Node II
    leetcode—Populating Next Right Pointers in Each Node
    Pascal's Triangle II
    leetcode—pascal triangle
    leetcode—triangle
    October 23rd, 2017 Week 43rd Monday
    October 22nd, 2017 Week 43rd Sunday
    October 21st 2017 Week 42nd Saturday
    October 20th 2017 Week 42nd Friday
    October 19th 2017 Week 42nd Thursday
  • 原文地址:https://www.cnblogs.com/leotsai/p/how-to-do-project-progress-and-quality-control.html
Copyright © 2011-2022 走看看