理铭 的个人资料阿闷的共享空间照片日志列表更多 工具 帮助

日志


5月5日

与熊共舞

节选1
逃避风险就等于举旗投降。在过去,如果恰好遇到一个看来全无风险的项目,你也许会把它看作一次愉快的享受,或许还会感谢你的幸运星给了你这样一个轻松的项目。我们也曾有过这样的反应——多么愚蠢的反应。没有真正意义上的风险,项目注定是失败的:全无风险的同时,它们也几乎全无收益,所以这类项目至今仍然没有付诸实施。给自己节省一点时间和精力,去做那些真正有价值的事情吧。

——摘自第1
节选2

在克里福德之前,曾有这样一种观点:信念永远不能被放在伦理的灯下接受拷问;只要你愿意,你可以相信任何事。你甚至可以相信绝无可能的事,就像《爱丽丝漫游镜中世界》(Through the Looking Glass)里的白皇后那样。当爱丽丝认为“人不能相信不可能的事”时,这位皇后答道:

“我猜你只是缺乏练习……像你这么大的时候,我每天都会用半小时去相信不可能的事。啊,有时我甚至可以在早餐前相信六件不可能的事。”

不过,对于软件项目管理者来说,“在早餐前相信六件不可能的事”似乎并不是一种难以企及的能力——我们总在相信着各种各样不可能的事,例如在极短的时间里、以极低的预算和极高的效率完成项目。

在做这件事时,我们与那位对自己的船充满信心的船主并无太大区别。无疑,作为软件项目的管理者,你肯定曾经做过这样的事。这也许是因为旁人的怂恿,例如你的老板会请求你在圣诞节前完成一个项目,却只给你三个人。当然,你会表示怀疑:这点时间够用吗?

“那就是我选来管理这个项目的原因。”老板信赖地对你说。

事情就这么定下来了:你接受这份工作,接受挑战,也准备接受荣誉……但你首先必须相信这个日程安排,那就是你要付出的代价。终于,你艰难地说:“我能行。”然后开始不断地巩固自己的信念。当然能行,不就是圣诞节吗?为什么不行?别的项目用的时间还要少呢,不是吗?没多久,你就已经充满信心了。也许时间会证明你的信心毫无根据,但至少现在,你非常肯定:你能够按时完成任务。

这时,你应该回想一下威廉·金顿·克里福德的质询。没错,那是你相信的,但你是否有权相信它?凭面前的证据,你是否有权相信那个日程安排?

只相信你有权相信的事,这就是风险管理。说到底,风险管理的核心就是克里福德的“信仰的伦理学”——尽管不确定性的存在使情况愈加复杂,但风险管理要求每个信念必须接受伦理的拷问。它将去除你工作(例如软件项目)中曾经充斥着的自欺欺人。除了“在早餐前相信六件不可能的事”之外,你还可以有另一种选择,一种更为明智的选择。

4月21日

工作分解和计划能力是项目经理的核心能力

我们经常遇见这样的一些情况:在系统集成实际工作中,遇到过这样的项目经理,他们沟通能力很强,有亲和力,特别能够与客户保持很好的关系,但仔细分析,发现他们在项目执行中实际上没有细致的分解和计划,往往以客户关系为导向,以一些关键时间点为监控点,进行粗放的项目管理,经常还会以自己巧妙的沟通而自喜;也遇到过这样的项目经理,他们技术能力很强,有一定的计划和组织能力,但是他们的计划往往太侧重于技术方面,不能为客户理解,得不到客户的认可和支持,执行项目困难重重。

许许多多的项目管理培训,也总是告诉项目经理要具备这样那样的素质和能力,包括沟通能力,项目团队建设及人力资源管理能力,领导能力,等等,要求高而全,更多的项目经理在无所适从中选择了从自身优势出发,如行业知识不多或技术能力不强的,就更多地看重沟通能力,认为通过良好沟通就可以搞好项目,技术能力强的就更多地关注技术问题,以技术语言组织项目,不能站在客户角度或使用客户容易理解的语言进行沟通。

这些情况都存在一个问题,就是没有做好项目的计划。

计划的重要性

其实,在PMBOK中,对于项目计划过程及重要性描述的很清楚,只是许多人在工作中忽略了,没有按照项目管理的过程管理和组织项目,而是继续沿用自己的经验。

没有全面细致的计划,仅有里程碑式的粗略计划,不足以以此指导项目执行和控制,对项目的进度情况难以判断;

计划不细致,不全面,资源难以落实,成本不易控制,沟通也只能停留在表面问题上,更多的是发现问题时才知道沟通什么。往往会使项目经理疲于应付。

如何编制计划

在实际的项目管理过程中,可以按照下面的步骤编制项目计划。

首先明确项目的目标和要求。对目标和要求的理解及描述不能只站在自己一方,而要关注用户的立场,与用户的需求挂起钩来,才能很好地与用户沟通并达成一致。同时,要搞清楚完成项目目标给定了哪些条件。

第二步,根据项目的目标和要求,确定项目的工作范围及不在范围内的工作。工作范围的确定需要用到WBS,即工作分解结构,对于工作范围定义来说,分解到工作包即可。

第三步,根据工作范围定义,继续分解完成各工作包需要的活动,根据活动间的关系排出活动先后顺序,估计活动所需时间,确定活动需要的资源,即可作出项目时间进度计划。同时,也可编制出初步的资源计划;

第四步,有了进度计划和资源计划,根据完成项目活动所需资源情况,即可进行费用预算和分配,得到项目费用计划;

第五步,根据进度计划,资源计划以及费用计划,可以确定哪些资源满足,哪些资源需要通过采购而取得,哪些资源采购更合算,什么时候需要什么资源,从而得到项目采购计划。

第六步,需要考虑项目风险,项目的风险管理主要有风险识别,分析和应对,首要的是风险识别,风险识别实际上是对照项目的目标和工作范围,找出影响目标完成的可能因素,然后再分析这些因素发生的可能性及影响程度,最后,制定出应对计划。

第七步,编制质量计划和沟通计划;

第八步,将以上计划整合,平衡资源和其他因素,形成项目整体计划。

如何进行工作分解

遵循以上步骤,可以编制出项目整体计划,这个项目计划涉及到PMBOK所讲到的九大知识领域,可以说,这个计划够全面了。但是,这个计划是否能够细致而全面,有一个前提条件,就是工作分解能力。层次不清,分解不细,该想到的没想到,出来的计划可想而知。

 有效的工作分解应该注意以下三点:

第一,分解方式选择。可以按照产品结构分解,按照平面或空间位置分解,按照功能分解,按照实施过程分解,不同项目或不同的分解层次可以按照不同的分解方式进行分解。在按照实施过程分解时,往往是按照项目生命周期进行的,根据项目特点将项目分成若干个阶段,这时要注意不用与项目管理的五个管理过程组相混淆。

第二点,完备。所谓完备是指考虑到了每一个方面,没有遗漏。

第三点,相互独立,无重叠。是指所有同一层次的内容是独立的,可清楚区分的,不相互包含。

 做到以上几点,工作分解就会层次清晰,细致全面。为了更好地掌握工作分解要点,推荐大家看看《麦肯锡方法》,对于提高工作分解能力有巨大的帮助。

分解能力和计划能力是核心能力

当你具备很强的分解能力时,计划能力随之而提高,分解能力是基础,相对于计划能力,是核心中的核心。

有了分解能力作为基础,在处理其他项目问题,诸如资源,风险,沟通等时,你同样可以做到思路清晰,目标明确,有的放矢。

在项目之外,有很强的分解能力为基础,遇到任务或问题时,你总可以理出清晰的思路,从而找到解决。

所以,项目经理首先需要练好工作分解基本功,从而提高项目的计划能力。工作分解能力和计划能力得到提高后,你就具备了项目经理最核心的能力,绝大部分的项目工作就可以有效控制在你手中,感觉到许多工作都在按照你的思路进行着。随着经验的不断积累,你的领导能力,沟通能力,团队建设能力等得到提高,你就成为了令人钦佩的,合格的项目经理。

4月16日

如何评估个人的软件开发能力

[转]如何评估个人的软件开发能力 〔by sleeper317)

从基本的来看,应涉及到以下几点:

1. 读程序的能力

     很多的软件开发工作不一定会从头开始,这就需要开发人员有良好的阅读程序的能力,能在尽可能短的时间里了解软件整体的架构,理解该软件初始的开发思想,能迅速并有效地参与到项目开发中去。

2. 编码能力

     这点会涉及到开发人员对所用语言的熟练程度,和该开发人员的编程风格。是否拥有良好的编程习惯,能遵循通用的编程规范,并作好注释,对该开发人员所开发代码的易读性和易维护性有很大的影响。

3. 调试和测试能力

     现代的软件行业中,代码的调试和测试时间并不比编码时间短,甚至会超出,当然,很多的调试和测试工作并不都是编码人员完成,但测试工作是很多软件开发人员的必经之路。

4. 软件的维护

     似乎维护谈不上需要什么能力,因为这时更多需要的是开发人员的耐心。记得曾经看过这样的话(大意):你的程序就是你的孩子,在你产生了他们之后,还需要你的呵护才能成长和成熟^^

     前面讨论的都是实际动手能力,是一个软件开发人员的基本功。而评估一个开发人员的软件开发能力,除了评估他的编程能力外,还应考虑到其他的一些很重要的能力,如

1. 需求分析的能力

     一个项目,最初就需要做需求分析,了解该项目的目的,对系统的需求,对功能的要求,并对其进行分析,作好项目规划和说明

2. 建立软件框架的能力

     建立一个良好的软件框架是这个项目成功的一个保证,需要考虑整个软件的一致性和完整性

3. 贯穿项目始终的管理控制能力

     在项目开发过程中,不可避免会出现新需求的加入,目标的修正,或者人员的变动等问题,对此进行有效的管理控制是对开发人员的更高要求

从一个笑话看软件开发管理

[转]从一个笑话看软件开发管理

1. 程序员写出自认为没有Bug的代码。
2. 软件测试,发现了20个Bug。
3. 程序员修改了10个Bug,并告诉测试组另外10个不是Bug。
4. 测试组发现其中5个改动根本无法工作,同时又发现了15个新Bug。
5. 重复3次步骤3和步骤4。
6. 鉴于市场方面的压力,为了配合当初制定的过分乐观的发布时间表,产品终于上市了。
7. 用户发现了137个新Bug。
8. 已经领了项目奖金的程序员不知跑到哪里去了。
9. 新组建的项目组修正了差不多全部137个Bug,但又发现了456个新Bug。
10. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。
11. 公司被竞争对手恶意收购。收购时,软件的最终版本包含783个Bug。
12. 新CEO走马上任。公司雇了一名新程序员重写该软件。
13. 程序员写出自认为没有Bug的代码。

  要我说,如果真有这样的公司,不倒闭对不起人民。

 这个笑话从程序员开始,到程序员结束,从头到尾都在说程序员的不是。但是我要说的是,这完全是管理者的失败,从整个过程中,看不到任何管理工作。这种管理者不但无知无能,还很无耻——将自己的失败责任推给程序员。

 1、程序员凭什么证明他的代码没有BUG?有Test case吗?有Code review吗?这个环节管理缺失。

 2、测试发现BUG有进行BUG管理吗?有跟踪吗?这个环节管理缺失。

 3、凭什么证明程序员已经把那10个BUG修改好了?另10个又为什么不是BUG?BUG的评价标准难道是程序员说了算?这个环节管理缺失。

 4、5个不能工作的BUG修改问题有没有追究责任?增加新BUG是修改过程中不可避免的事情,但是如果有有效的单元测试机制,可以大大减少这种情况。这个环节管理缺失。

 5、迭代是正常的,但是问题处理于发散而不是收敛发展,可见没有有效的管理调控。这个环节管理缺失。

 6、过于乐观的时间表和不可能达到的最后期限,都表现出管理者的无知和无能。而在这样的情况下强行推出产品,那就是无知者无畏了。

 7、这是对用户的不负责任,管理者要负最大的责任。

 8、这样的情况还能发项目奖金,只能说管理者不是一般的愚蠢。

 9、管理工作没有任何的改进,问题仍然处于发散迭代状态。管理工作依然没有到位。

 10、拖欠测试部门工资体现出管理者对质量管理工作的忽视以及对人力资源管理方面一无所知。

 11、送被收购者两个字:活该。送收购者两个字:瞎眼。

 12、可见新管理者与原管理者半斤八两,都没有认识到问题的根本所在。不过也只有这样的管理者才会作出收购这种公司的决策。

 13、历史的重演是必然的。

 一个正常的企业或是项目,其运作必须应该是循环向上进行的。而保障这种运行的工作就是管理。而管理工作的主要内容就是控制,包括控制循环的节奏——不能太快也不能太慢,控制发展的方向——只能向上不能向下,控制运作的稳定——不能大起大落或时聚时散等。

 而这一切,在这个例子中都看不到。

 在这个笑话的例子中,一切都是以开发工作在驱动,这首先就是一个方向性错误,产品是为用户服务的,当然应该是以用户和市场作为驱动,并且结合自身的能力最终 确定工作的重点。这一错误折射出管理者对被管理的内容很不了解,只好任由比较了解的程序员摆布——事实上他们除了技术,并不会了解更多。

 一个管理者如果对自己所管理的内容不了解,他就不可能管理得好。

 这是一件毫无疑问的事,可是国内的软件业似乎总是不相信这一点。中国软件业中流毒最深的谎言之一就是:

 管理者只要懂管理就可以,不需要懂技术。
其实这不过是那些无知无能无耻的管理者为了骗钱而编出来的,相信这句话的人必将付出金钱的代价。

 其次是质量管理。基本的质量管理常识告诉我们,每次循环结束前,最重的工作就是总结改进。只有这样才能保证循环运作是向上发展,而不是失去控制地向下发展。 也只有有效的质量管理,才能保证迭代过程是收敛发展,并最终达到目标。但在这个例子中,这个部分显然是缺失的——其中虽然有测试部门,但是他们的作用仅仅 是质量管理中的质量检测环节,管理部分还是缺失的。

 然后是人力资源管理。软件开发是一项劳动密集型的工作,虽然这是脑力劳动,但同样意味着人在因素在其中占有决定性的地位。而例子中未改完BUG的程 序员拿到项目奖金,而同样辛苦工作的测试人员却被拖欠薪资,除了表现出管理者对他们的工作内容的不了解,以及对质量管理工作的不重视以外,还表现出管理者 完全不会管人,这是一种谋杀团队的行为——谋杀一个团队远比建设要容易得多。

 最后,这个失败的管理者把他的经历编成这个笑话,让大家看到他被程序员们害得多惨,把程序员妖魔化为一群骗子。但只要稍懂管理的人简单分析一下就可以看出来,只不过是这个人的无知和无能造成了他现在的结果,而把责任推给别人的行为更是表现出他的无耻。

 作为身居高位的管理者,如果连应该承担的责任都要推卸,他们还能胜任什么事情呢。

1月16日

对于软件开发哲学的经验谈

对于软件开发哲学的经验谈
       "确认你已经理解问题, 由小型的有才干的团队来实现解决方案, 并且让你的客户告诉你如何改进它. 这就是全部; 其他的都是注解."(软件开发哲学,摘自<>)
      做了这麽久的开发,看到这个开发哲学,真是很贴切,软件开发的几大要点概括的淋漓尽致.
 
     "确认你已经理解问题" 即需求问题,宏观上为软件的商业目的,微观上为每个功能需求的理解与分析,根据我的开发经验,就是要获取需求并且正确的理解它,我们往往对需求的问题不能够达到全面的理解,大多数情况都是处在一知半解的状态,各种情况导致获取的需求并非真实有效,分析其原因主要有3点:
    1.客户对需求也不能完全解释的清楚
    2.业务逻辑确实很复杂,相关联系繁多,造成理解上会达到理解问题的限制(5~7个关联复杂性,超过就不易理解)
    3.需求的获取,设计到实现的各个阶段出现了偏差,更严重的情况是无法追溯到原来提出的真实需求而造成的缺陷.
    4.需求在软件开发过程中,客户实际情况已经变更,或是客户改变了原先的想法而造成的需求变更
    解决这些矛盾的方法很多,主要在于需求开发的经验,设计开发的经验,团队的合做,有效全面及规范的需求记录与追踪,以及各阶段追溯到需求的评审等来保证我们对需求的理解.

    "由小型的有才干的团队来实现解决方案" 即团队合做与开发技能的问题.
     高品质的团队一直是成功的软件开发的保证.否则软件开发很容易陷入绝境.
    至于团队,以我的经验主要提出几点看法.
   1.保证的团队稳定性
   团队的核心成员要稳定,例如一个团队一定要确认哪几个是团队的核心,在软件的开发周期内一定要保证这些核心人员的稳定性,最好是不只是在一个项目周期,而是在组织面上也保证此团队核心成员的稳定性,这样才能够使得团队不断进步,积累经验,更重要的是合作的有效性,要知道一个人员更新频繁,或是刚刚组建的团队效率与合作性都是非常差的,需要很长时间的磨合与锻炼,但往往会导致软件开发的失败,因为在你为建立新团队的有效合作与开发过程的同时,软件的开发已经错误百出,种下了失败的种子,后面再想补救的代价就太高了.所以建立稳定的开发团队是软件开发的有效保证.
    2.合理有效的团队发展规划.
     1).明确有效的团队目标.
      为团队设立一个明确有效的目标,让团队中的核心成员都能够一致的认同这个目标,并且将此目标与其自身的发展相互联系,给每个人前进的动力与希望.这也是团队稳定性的重要保证,没有一个一致目标和奋斗方向的团队,很难有凝聚力,也更不会成为一个高品质的团队.
     2).团队成员合理的互补性.
        我们要设定团队成员各方面能力的基准线,每个成员不能低于这基准,否则会影响团队的整体实力.
在此基准线上我们并不要求每个成员在各方面都优秀(这也是很难做到的),但一定会要求每个成员在某一个方面能力高于基准线,这样才能根据特殊能力来建立互补性的团队.
        例如:开发团队管理者要达到分析,设计,编码,等工作能力的一个基准线, 在此之上他的管理能力一定是高于基准线之上,具备优秀管理能力的人.而不是让一个各方面平庸或是其他能力(如他的编码能力优秀)的人来充当管理者的角色. 这样让在各个方面的工作,都能够找到在此方面优秀的人来执行,以达到建立互补性的团队的目的.同时团队成员在此基础上又能够在各方面得到向他人学习提高的机会,以提高团队能力的基准线,达到团队发展的目的.
      3).其他辅助性的策略与制度也不容忽视.
      首先,团队内部要有一个公平,公正的氛围,每个人的能力,业绩与其获得的回报和在团队中的位置要相互一致,形成一个良好的团队发展环境.
      第二,在保证核心成员稳定的同时,合理的团队流动性也是必要的,因为不能保证团队每个成员都能够达到团队的发展要求,所以将不适合的人员替换出去,再吸收新的成员,发展优秀的成员成为核心人员,以发展壮大团队,并形成良好的团队新陈代谢的模式.
      第三,获得管理层对此团队的认同,鼓励团队的变革,鼓励创新,愿意承担相应的风险,也是关系到团队是否能够发展的一个非常重要的因素,这也要求团队要不断的获得成功,创造业绩,及良好的沟通来获得管理层的支持.
 
       "并且让你的客户告诉你如何改进它" 这里我的理解不仅仅是客户,而且也包括市场
       开发好的软件,最重要的目的是达到客户的需要,以及市场的需要.让客户与市场来引导我们软件的开发方向是软件获得丰厚收益的重要保证,也是软件开发的重要目标.当然这也是建立在我们能够正确的理解客户的需求与市场的需求的基础之上的.
 
        "这就是全部; 其他的都是注解."  这里我的理解是软件开发要以上面所提到的需求,团队,客户与市场为主要关注点,而对于其他辅助性的方面,如过程改进,检查与监测等都是实现主要关注点的有效工具与过程,要分清主次,不要一味的盯在这些辅助性的工作方面,而忽视了软件开发成功的真正关键. 根据经验,如果软件开发时在还未理解需求,又没有良好的开发团队,客户与市场也模糊不清时,而相反却去注重文件表单规范,过程改进,ISO或CMMI等等相关的事务,这样试问就算这些做的再好,我们的软件开发能够成功吗.要分的清主次,合理应用其他辅助性事务,才是正道.
        综上所述,我对软件开发的经验之总结, 软件开发需要以客户与市场为导向理解软件真正的需求,利用高品质优秀的团队进行开发,以达到获取最大商业利益的目的.