发布新日志

  • 软件项目管理之范围潜变

    2012-06-08 18:24:39

    软件项目的是不是能按时完成提交,是否做且只做成功完成项目需求所需的全部,其实很大一部分因素是取决于项目范围管理的是否成功。范围潜变又叫范围蔓延,未得到控制的变更通常称为项目范围潜变,也叫范围蔓延。范围潜变包括范围的增加和减少;范围的减少可能导致客户的不满意,范围的增加导致时间,费用和资源的投入增加。

    怎么防止范围的潜变:
    1. 跟客户在一开始就定义好范围。
    2. 在项目团队中明确需求范围变更流程,CCB 成员等。
    3. 客户提出的任何需求范围变更都要经过CCB的批准,走变更流程,确保变更被纳入管理。
    4. 还要有专员负责范围的管理。

  • 软件项目管理之范围管理

    2012-05-29 18:12:40

    软件项目管理之范围管理

    软件项目不可避免的一个问题就是项目范围的不断更新。大部分项目没法在一开始的时候就把项目的范围定义得非常清楚,或者说定好之后就不再更改的。项目范围的更改既然是软件项目中不可避免的事情, 那么管理好项目范围就成为软件项目管理中比较重要的一方面,即要让客户明明白白我们的范围也要让项目中的开发,测试,BA 等等在范围的理解上一致.
    项目范围文档:
    a) 项目经理自己或是项目经理指定一个专员维护一个文档专门记录项目范围,包括项目中的每个UC 或是Tickets 是在哪个阶段做,这个项目分几个阶段, 每个UC(Tickets) 都由哪几个开发人员,那几个测试人员来负责,哪几个成员负责Review 等。
    b) 此文档还记录这个项目中有哪些是原来打算做,现在不做了的功能范围,或是所有人都已达成共识,作为Know Issue 再后期阶段做或是以后项目做或是在维护阶段做的范围。
    c) 此文档还记录着一些UC (Tickets) 相关的一些备注,比如说对于这个UC 我们跟客户沟通过,结论是什么等等信息。
    d) 此文档还记录着开发的完成情况,比如说让开发填一个状态一旦他们完成所有的Coding,UT and IT 工作。
    e) 项目经理和 whole Team 随时可以查看这个文档,来确认自己理解的范围是不是跟整个项目的范围一致。

    项目范围的变更:
    a) 一旦客户提出范围变更包括增加或是减少功能,首先将新增加的功能记录在项目范围文档中,且指定某个或多个专员对其进行分析。
    b) 新增加功能的范围对当前已经做好功能有没有影响,新功能有几个solutions, 每个solutions 需要多少effort 去coding, UT,IT ST 和写文档时间包括更新测试计划,测试cases, 设计文档,详细设计文档等时间.
    c) 分析对于现有Schedule 有哪些影响,哪些资源来做这个新增加的功能比较合适。
    d) 如果新功能加到现在项目中,那么新的timeline 是什么, 有没有新的dependency , 给客户的target date 又是哪天。
    e) 更新完schedule 之后,自己内部whole team review , 有comments就改,确保内部达成一致意见之后发给客户确定。
    f) 如果客户没有意见,一切好办;如果客户有疑问,就需要解释为什么我们更新的schedule 是这样的。
    g) 等最终确认新增加的功能加在当前的项目中时,要相应的更新WBS,FP, cost 等等相关文档。
    h) 确认了的信息一定要通知到项目中的所有相关人员,确保所有相关人员在范围理解上的一致。

    当然在项目的后期阶段不建议变更项目范围,即使要变也一定要告诉客户,这样做都有哪些风险一条一条的列出来给客户看。

  • 软件项目管理之原则

    2012-05-23 18:41:56

    1.Result:软件项目管理是以结果为导向的。
    2.Focus:每周一列出这一周的重点要处理的事情;每天早上列出所有当天必须要做的事情,然后一件一件的解决,一件一件的处理。
    3.whole picture:做为了一个领导者,要有全局观,从整个Team 去考虑问题,从整个部门去考虑,甚至是公司的战略去考虑问题。
    4.Advantage:利用Team 中每个人的优势,多想办法引导他们到优势上,尽量忽略他们的劣势。
    5.Trust:对Team要信任,相信他们能做好;做得不够好时要提出来,让他们做得更好; 碰到积极性比较差一点要Track 的更紧。
    6.Positive thinking:给客户提供的Solution 不止一个,况且说明每个solution 的优势和劣势;做为一个管理者,任何时候都不要说消极的话,要积极主动的想办法去解决问题。
  • 软件项目管理之高效的每日状态会议

    2012-05-12 22:27:15

    软件项目管理之高效的每日状态会议:

    1.事先跟同学学们澄清每日状态会议都要讨论的内容(可以随meeting agenda 一起发出去):项目信息更新,每个人昨天做了什么,今天做了什么,遇到什么问题,需要什么帮助,有什么风险等。
    2.开会时间基本上控制在15分到25分钟,如果是遇到一些麻烦或是重大问题,一两钟解决不了的,那这个话题就另开会议来解决。
    3.事先约定:不许带手机,水杯,笔,笔记本之类的进去,只有要记会议纪要的同学才允许带笔记本和笔。
    4.为了防止某些同学开小差,建议把重要的项目信息一开始就先分享。
    5.当其中的以个同学发言时,项目经理可以问些问题,比如说在测试阶段可以问问,质量如何,发现多少BUGs,需要哪位开发或是BA 的支持,有没有Show stop issues,是否需要开发马上解决,跑了多少CASES,完成%,还能不能在原来定的项目计划内完成测试等等。
    6.也可以让同学们轮流主持会议,来提高他们的Ownership .
    7.到一天快要下班的时候, 项目经理可以跟踪一下,同学们今天要做的事情都做得如何啦,有没有遇到困难等等。
  • 主管不能用的三种人

    2012-04-24 18:25:51

    主管不能用的人有三种,笨,慢,懒,但事实上真正不能用的是懒人。

     

    笨:只是比别人反应慢一点,能通过自身的努力去严格要求自己,比别人付出更多的汗水是能用的,况且这种人能明白自己想要的是什么,知道自己的优势很劣势,还是挺不错的一种人;另一种的笨就是不肯花心思在工作上,不具备研究精神,不想把工作做好,带着一种什么都无所谓的消极态度,这种人是不能用的,这种人不是真正的笨,是聪明过头。

     

    慢:做事拖拉与慢工出细活这是两个不同的方向; 慢工出细活是追求精益求精,同一件事情比别人想得更好,更广,更深,自然要比别人花更多的时间和精力; 这里要说的慢就是做事拖拉,主管交代的任务不能按时完成不说,完成的部分也与原来期望的结果相差甚远,这种人也是要考虑考虑的。

     

    懒:这种人就是多一事不如少一事,甚至不做事,交代的事情是用最低的标准来完成,甚至达不到标准,要的是减轻自己的工作量,减轻自己的付出;你想让他/她积极主动那是妄想,其实笨和慢归根结底还是懒惹的祸,懒的人也是主管的需要考虑的。

     

    笨,慢,懒的人,在面试的时候是很难看出来的,在试用期也很难看出来,只有等待时间印证。

Open Toolbar