理铭 的个人资料阿闷的共享空间照片日志列表更多 ![]() | 帮助 |
|
|
5月5日 与熊共舞节选1: ——摘自第1章 在克里福德之前,曾有这样一种观点:信念永远不能被放在伦理的灯下接受拷问;只要你愿意,你可以相信任何事。你甚至可以相信绝无可能的事,就像《爱丽丝漫游镜中世界》(Through the Looking Glass)里的白皇后那样。当爱丽丝认为“人不能相信不可能的事”时,这位皇后答道: “我猜你只是缺乏练习……像你这么大的时候,我每天都会用半小时去相信不可能的事。啊,有时我甚至可以在早餐前相信六件不可能的事。” 不过,对于软件项目管理者来说,“在早餐前相信六件不可能的事”似乎并不是一种难以企及的能力——我们总在相信着各种各样不可能的事,例如在极短的时间里、以极低的预算和极高的效率完成项目。 在做这件事时,我们与那位对自己的船充满信心的船主并无太大区别。无疑,作为软件项目的管理者,你肯定曾经做过这样的事。这也许是因为旁人的怂恿,例如你的老板会请求你在圣诞节前完成一个项目,却只给你三个人。当然,你会表示怀疑:这点时间够用吗? “那就是我选你来管理这个项目的原因。”老板信赖地对你说。 事情就这么定下来了:你接受这份工作,接受挑战,也准备接受荣誉……但你首先必须相信这个日程安排,那就是你要付出的代价。终于,你艰难地说:“我能行。”然后开始不断地巩固自己的信念。当然能行,不就是圣诞节吗?为什么不行?别的项目用的时间还要少呢,不是吗?没多久,你就已经充满信心了。也许时间会证明你的信心毫无根据,但至少现在,你非常肯定:你能够按时完成任务。 这时,你应该回想一下威廉·金顿·克里福德的质询。没错,那是你相信的,但你是否有权相信它?凭面前的证据,你是否有权相信那个日程安排? 只相信你有权相信的事,这就是风险管理。说到底,风险管理的核心就是克里福德的“信仰的伦理学”——尽管不确定性的存在使情况愈加复杂,但风险管理要求每个信念必须接受伦理的拷问。它将去除你工作(例如软件项目)中曾经充斥着的自欺欺人。除了“在早餐前相信六件不可能的事”之外,你还可以有另一种选择,一种更为明智的选择。 4月21日 工作分解和计划能力是项目经理的核心能力我们经常遇见这样的一些情况:在系统集成实际工作中,遇到过这样的项目经理,他们沟通能力很强,有亲和力,特别能够与客户保持很好的关系,但仔细分析,发现他们在项目执行中实际上没有细致的分解和计划,往往以客户关系为导向,以一些关键时间点为监控点,进行粗放的项目管理,经常还会以自己巧妙的沟通而自喜;也遇到过这样的项目经理,他们技术能力很强,有一定的计划和组织能力,但是他们的计划往往太侧重于技术方面,不能为客户理解,得不到客户的认可和支持,执行项目困难重重。 许许多多的项目管理培训,也总是告诉项目经理要具备这样那样的素质和能力,包括沟通能力,项目团队建设及人力资源管理能力,领导能力,等等,要求高而全,更多的项目经理在无所适从中选择了从自身优势出发,如行业知识不多或技术能力不强的,就更多地看重沟通能力,认为通过良好沟通就可以搞好项目,技术能力强的就更多地关注技术问题,以技术语言组织项目,不能站在客户角度或使用客户容易理解的语言进行沟通。 这些情况都存在一个问题,就是没有做好项目的计划。 计划的重要性 其实,在PMBOK中,对于项目计划过程及重要性描述的很清楚,只是许多人在工作中忽略了,没有按照项目管理的过程管理和组织项目,而是继续沿用自己的经验。 没有全面细致的计划,仅有里程碑式的粗略计划,不足以以此指导项目执行和控制,对项目的进度情况难以判断; 计划不细致,不全面,资源难以落实,成本不易控制,沟通也只能停留在表面问题上,更多的是发现问题时才知道沟通什么。往往会使项目经理疲于应付。 如何编制计划 在实际的项目管理过程中,可以按照下面的步骤编制项目计划。 首先明确项目的目标和要求。对目标和要求的理解及描述不能只站在自己一方,而要关注用户的立场,与用户的需求挂起钩来,才能很好地与用户沟通并达成一致。同时,要搞清楚完成项目目标给定了哪些条件。 第二步,根据项目的目标和要求,确定项目的工作范围及不在范围内的工作。工作范围的确定需要用到WBS,即工作分解结构,对于工作范围定义来说,分解到工作包即可。 第三步,根据工作范围定义,继续分解完成各工作包需要的活动,根据活动间的关系排出活动先后顺序,估计活动所需时间,确定活动需要的资源,即可作出项目时间进度计划。同时,也可编制出初步的资源计划; 第四步,有了进度计划和资源计划,根据完成项目活动所需资源情况,即可进行费用预算和分配,得到项目费用计划; 第五步,根据进度计划,资源计划以及费用计划,可以确定哪些资源满足,哪些资源需要通过采购而取得,哪些资源采购更合算,什么时候需要什么资源,从而得到项目采购计划。 第六步,需要考虑项目风险,项目的风险管理主要有风险识别,分析和应对,首要的是风险识别,风险识别实际上是对照项目的目标和工作范围,找出影响目标完成的可能因素,然后再分析这些因素发生的可能性及影响程度,最后,制定出应对计划。 第七步,编制质量计划和沟通计划; 第八步,将以上计划整合,平衡资源和其他因素,形成项目整体计划。 如何进行工作分解 遵循以上步骤,可以编制出项目整体计划,这个项目计划涉及到PMBOK所讲到的九大知识领域,可以说,这个计划够全面了。但是,这个计划是否能够细致而全面,有一个前提条件,就是工作分解能力。层次不清,分解不细,该想到的没想到,出来的计划可想而知。 第一,分解方式选择。可以按照产品结构分解,按照平面或空间位置分解,按照功能分解,按照实施过程分解,不同项目或不同的分解层次可以按照不同的分解方式进行分解。在按照实施过程分解时,往往是按照项目生命周期进行的,根据项目特点将项目分成若干个阶段,这时要注意不用与项目管理的五个管理过程组相混淆。 第二点,完备。所谓完备是指考虑到了每一个方面,没有遗漏。 第三点,相互独立,无重叠。是指所有同一层次的内容是独立的,可清楚区分的,不相互包含。 分解能力和计划能力是核心能力 当你具备很强的分解能力时,计划能力随之而提高,分解能力是基础,相对于计划能力,是核心中的核心。 有了分解能力作为基础,在处理其他项目问题,诸如资源,风险,沟通等时,你同样可以做到思路清晰,目标明确,有的放矢。 在项目之外,有很强的分解能力为基础,遇到任务或问题时,你总可以理出清晰的思路,从而找到解决。 所以,项目经理首先需要练好工作分解基本功,从而提高项目的计划能力。工作分解能力和计划能力得到提高后,你就具备了项目经理最核心的能力,绝大部分的项目工作就可以有效控制在你手中,感觉到许多工作都在按照你的思路进行着。随着经验的不断积累,你的领导能力,沟通能力,团队建设能力等得到提高,你就成为了令人钦佩的,合格的项目经理。 4月16日 如何评估个人的软件开发能力
从一个笑话看软件开发管理
1月16日 对于软件开发哲学的经验谈对于软件开发哲学的经验谈
"确认你已经理解问题, 由小型的有才干的团队来实现解决方案, 并且让你的客户告诉你如何改进它. 这就是全部; 其他的都是注解."(软件开发哲学,摘自<>) 做了这麽久的开发,看到这个开发哲学,真是很贴切,软件开发的几大要点概括的淋漓尽致.
"确认你已经理解问题" 即需求问题,宏观上为软件的商业目的,微观上为每个功能需求的理解与分析,根据我的开发经验,就是要获取需求并且正确的理解它,我们往往对需求的问题不能够达到全面的理解,大多数情况都是处在一知半解的状态,各种情况导致获取的需求并非真实有效,分析其原因主要有3点:
1.客户对需求也不能完全解释的清楚
2.业务逻辑确实很复杂,相关联系繁多,造成理解上会达到理解问题的限制(5~7个关联复杂性,超过就不易理解) 3.需求的获取,设计到实现的各个阶段出现了偏差,更严重的情况是无法追溯到原来提出的真实需求而造成的缺陷. 4.需求在软件开发过程中,客户实际情况已经变更,或是客户改变了原先的想法而造成的需求变更 解决这些矛盾的方法很多,主要在于需求开发的经验,设计开发的经验,团队的合做,有效全面及规范的需求记录与追踪,以及各阶段追溯到需求的评审等来保证我们对需求的理解. "由小型的有才干的团队来实现解决方案" 即团队合做与开发技能的问题. 高品质的团队一直是成功的软件开发的保证.否则软件开发很容易陷入绝境. 至于团队,以我的经验主要提出几点看法. 1.保证的团队稳定性
团队的核心成员要稳定,例如一个团队一定要确认哪几个是团队的核心,在软件的开发周期内一定要保证这些核心人员的稳定性,最好是不只是在一个项目周期,而是在组织面上也保证此团队核心成员的稳定性,这样才能够使得团队不断进步,积累经验,更重要的是合作的有效性,要知道一个人员更新频繁,或是刚刚组建的团队效率与合作性都是非常差的,需要很长时间的磨合与锻炼,但往往会导致软件开发的失败,因为在你为建立新团队的有效合作与开发过程的同时,软件的开发已经错误百出,种下了失败的种子,后面再想补救的代价就太高了.所以建立稳定的开发团队是软件开发的有效保证. 2.合理有效的团队发展规划.
1).明确有效的团队目标.
为团队设立一个明确有效的目标,让团队中的核心成员都能够一致的认同这个目标,并且将此目标与其自身的发展相互联系,给每个人前进的动力与希望.这也是团队稳定性的重要保证,没有一个一致目标和奋斗方向的团队,很难有凝聚力,也更不会成为一个高品质的团队.
2).团队成员合理的互补性.
我们要设定团队成员各方面能力的基准线,每个成员不能低于这基准,否则会影响团队的整体实力. 在此基准线上我们并不要求每个成员在各方面都优秀(这也是很难做到的),但一定会要求每个成员在某一个方面能力高于基准线,这样才能根据特殊能力来建立互补性的团队. 例如:开发团队管理者要达到分析,设计,编码,等工作能力的一个基准线, 在此之上他的管理能力一定是高于基准线之上,具备优秀管理能力的人.而不是让一个各方面平庸或是其他能力(如他的编码能力优秀)的人来充当管理者的角色. 这样让在各个方面的工作,都能够找到在此方面优秀的人来执行,以达到建立互补性的团队的目的.同时团队成员在此基础上又能够在各方面得到向他人学习提高的机会,以提高团队能力的基准线,达到团队发展的目的. 3).其他辅助性的策略与制度也不容忽视.
首先,团队内部要有一个公平,公正的氛围,每个人的能力,业绩与其获得的回报和在团队中的位置要相互一致,形成一个良好的团队发展环境. 第二,在保证核心成员稳定的同时,合理的团队流动性也是必要的,因为不能保证团队每个成员都能够达到团队的发展要求,所以将不适合的人员替换出去,再吸收新的成员,发展优秀的成员成为核心人员,以发展壮大团队,并形成良好的团队新陈代谢的模式. 第三,获得管理层对此团队的认同,鼓励团队的变革,鼓励创新,愿意承担相应的风险,也是关系到团队是否能够发展的一个非常重要的因素,这也要求团队要不断的获得成功,创造业绩,及良好的沟通来获得管理层的支持. "并且让你的客户告诉你如何改进它" 这里我的理解不仅仅是客户,而且也包括市场
开发好的软件,最重要的目的是达到客户的需要,以及市场的需要.让客户与市场来引导我们软件的开发方向是软件获得丰厚收益的重要保证,也是软件开发的重要目标.当然这也是建立在我们能够正确的理解客户的需求与市场的需求的基础之上的. "这就是全部; 其他的都是注解." 这里我的理解是软件开发要以上面所提到的需求,团队,客户与市场为主要关注点,而对于其他辅助性的方面,如过程改进,检查与监测等都是实现主要关注点的有效工具与过程,要分清主次,不要一味的盯在这些辅助性的工作方面,而忽视了软件开发成功的真正关键. 根据经验,如果软件开发时在还未理解需求,又没有良好的开发团队,客户与市场也模糊不清时,而相反却去注重文件表单规范,过程改进,ISO或CMMI等等相关的事务,这样试问就算这些做的再好,我们的软件开发能够成功吗.要分的清主次,合理应用其他辅助性事务,才是正道.
综上所述,我对软件开发的经验之总结, 软件开发需要以客户与市场为导向理解软件真正的需求,利用高品质优秀的团队进行开发,以达到获取最大商业利益的目的.
|
|
|