??xml version="1.0" encoding="utf-8" standalone="yes"?> q䆾文档主要l出了一些常用的 TWiki 文章~辑Ҏ(gu)。TWiki 是一个广泛用的开?wiki
pȝQ通常被企业和l织用户用来׃n知识{。更多介l请看它的官方站点:http://twiki.org
?/p>
q只是作者的一份编E笔讎ͼ其实与网上早期版本的 TWiki 文档中文译有些重复Q需要更多内容请查看参考文章和链接?/p>
目录 1. 基本语法 1. 基本语法 [1.1 话题] Wiki 的精就是用词条描述世界Q所?TWiki 也是q样Q它内部对内容的理是用一个一?WikiWord
来分cȝ。WikiWord 是像前面这U两个单词构成的q接在一L(fng)词组Q里面大写交错?/p>
TWiki 的话题(topicQ推荐用 WikiWord 来徏立,如果用户输入的新话题不是一?
WikiWordQ那么徏立新话题的按钮就不会被激zR但?TWiki 允许用户使用?WikiWord 建立词条Q需要手动勾选上允许使用?
WikiWord 建立话题?/p>
[1.2 标题和段落] 1.2.1 标题 ---+!! 目录 1.2.2 D落 区别?<verbatim></verbatim>
中间的代码以完全原始方式昄Q?lt;pre></pre> 中某?HTML 标签依然起作用?/p>
[1.3 字体和分隔线] 1.3.1 字体 1.3.2 分割U?br />
TWiki 的分割线是在行首输入q箋的多于三个的减号"-"Q例?br />
---- [1.4 列表] 1.4.1 无序号列?br />
无序号列表的格式是: 1.4.2 带序号列?br />
带序号列表的格式是: 注意:q里后面的小数点可要可不要,可以一直?1"~号Q也可用"1,2,3"递增~号Q效果无区别?/p>
[1.5 表格] 表格的徏立是用竖U?|"分隔Q比如: [1.6 链接] 1.6.1 词条链接 1.6.2 外部链接 1.6.3 面内锚?br />
在页面内可以定义锚点Q这样可以用链接在面内蟩来蟩厅R定义锚点的Ҏ(gu)是在行首使用 #WikiWordQ例如: 1.6.4 囄和附仉?br />
如果引用在同一面的附件或者图片(其实一般图片也是附ӞQ链接的格式为:%ATTACHURL%/filename.extesionQ比
如:%ATTACHURL%/about.pdfQ引用在不同面的链接,需要在文g名前面加上该面主题的名字,比如Q?PUBURL%/%WEB%
/MyWikiTopic/about.pdf [1.7 图标] TWiki 预定义了很多图标Q直接在文中可以用,比如帮助的小 i 图标是:%H%Qupdate 的图标是Q?U%Qnew
的图标是Q?N%。合理用这些图标能增强文章的可L?/p>
2. 面~辑技?/p>
[1] 建立话题时合理分U,有规律地规划父话题和子话题关pR?br />
[2] 处理重复话题时?%INCLUDE{"XXX"}% 来包含已有的话题Q比如我已经有了 PersonalComputer 话题Q在建立
PC 话题时候,应该直接在面中?%INCLUDE{"PersonalComputer"}% 来避免冗余?br />
[3] 使用%TOC%自动创徏目录Q当~辑一比较长的文章时Q徏议用标题标记徏立分U标题,最后?%TOC% 在上方徏立一个可索引目录?/p>
[4] 合理使用字体和图标增加可L?br />
[5] 合理使用 HTML 代码来加强页面排版功能。TWiki 可以直接支持 HTML 代码Qؓ了格式的l一Q一般不直接使用
HTML。但有些面排版q于复杂Q?HTML 可以直接辑ֈ要求?br />
[6] 使用注释的技巧:TWiki 没有?footnote
插g时候是不支持注释链接的Q但是可以通过一些技巧来实现。我们可以先在注释或者引用列表前建立一个锚点: ---+ Footnotes 3. 参考文章和链接 [1] 早期版本 TWiki 语法格式的中文翻? http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules WBSh4个主要用途: WBS是一个描q思\的规划和设计工具。它帮助目l理和项目团队确定和有效地管理项目的工作?nbsp; 防止遗漏目的可交付成果?nbsp; 工作包可以分配给另一位项目经理进行计划和执行?nbsp; 创徏WBS是指复杂的目分解Zpd明确定义的项目工作ƈ作ؓ随后计划zd的指导文档。创建WBS的方法主要有以下几种Q? 使用指导斚w。一些像国国防?DOD)的组l,提供MIL-STD之类的指导方针用于创建项目的WBS?nbsp; 创徏WBS旉要满以下几点基本要求: 某项d应该在WBS中的一个地方且只应该在WBS中的一个地方出现?nbsp; WBS可以由树形的层次l构图或者行首羃q的表格表示? 在实际应用中Q表格Ş式的WBS应用比较普遍Q特别是在项目管理Y件中? 4QWBS的分解方? WBS的分解可以采用多U方式进行,包括Q? 按品的物理l构分解?nbsp; 创徏WBS的过E非帔R要,因ؓ在项目分解过E中Q项目经理、项目成员和所有参与项目的职能l理都必考虑该项目的所有方面。制定WBS的过E是Q? 得到范围说明?ScopeStatement)或工作说明书(StatementofWokQ承包子目??nbsp; 每个d的状态和完成情况是可以量化的?nbsp; 对WBS需要徏立WBS词典(WBSDictionary)来描q各个工作部分。WBS词典通常包括工作包描Q述、进度日期、成本预和人员分配{信息。对于每个工作包Q应可能地包括有关工作包的必要的、尽量多的信息? 当WBS与OBSl合使用Ӟ要徏立̎目编?Code ofAccount)。̎目编码是用于惟一定目工作分解l构每一个单元的~码pȝ。成本和资源被分配到q一~码l构中? 7QWBS的实늻? 最多?0个层ơ,多于20层是q度的。对于一些较?yu)的?Q?层一般就_了?
1.1 话题
1.2 标题和段?br />
1.3 字体
1.4 列表
1.4.1 无序号列?br />
1.4.2 带序号列?br />
1.5 表格
1.6 链接
1.6.1 词条链接
1.6.2 外部链接
1.6.3 面内锚?br />
1.6.4 囄和附仉?br />
1.7
图标
2. 面~辑技?br />
3. 参考文章和链接
TWiki 中可以用分U标题,分标题的语法如下:
---+
---++
卛_行首三个"-"和一?+"代表一U标题,三个"-"和两?+"代表二标题Q以此类推。当用户使用规范的标题记号徏立好话题之后Q可以很方便C
?%TOC%"标记建立一个标题目录。如果用户不x个标题被包含Q只需要在标记标记后加上两个感叹号"!!"Q比如:
%TOC%
q样目录q个标题׃会包含在自动建立的目录里?/p>
TWiki 的段落分隔和 LaTeX 有点儿类|D落之间需要空一行。如果想输入不被 TWiki
格式化的原始文字Q比如源E序{)Q需要用标签这些段落包hQ主要有以下两种标签Q?br />
<verbatim></verbatim>
<pre></pre>
TWiki 使用字体的方式比较像 HTML 的标{,是在字W串两头加上某些标记。比如:
*Bold Font* _体
_Italic Font_ 斜体
__Bold Italic__ _斜?br />
=Fixed Font= {宽字符
==Bold Fixed Font== {宽_体字符
最最需要注意的一Ҏ(gu)Q这些标?*_="必须内侧与文字相q,外侧为空|标记之间也不得有I格?/p>
*
*
即三个空格加"*"所q一层,六个I格?*"~进W二层,以此cL?/p>
1.
1.
即三个空格加"1"所q一层,六个I格?1"~进W二层,以此cL。注意,q里?1"代表用阿拉伯数字~号列表Q其它编h式有"A"?a"大小?
字母标号Q?I"?i"大小写罗马字母编受?/p>
|T1|T2|T3|
|A1|A2|A3|
徏立了一个两行三列的列表。单元格内部的左叛_齐是利用和竖U的距离实现的?/p>
如果是规范的多词 WikiWord 话题Q可以用双Ҏ(gu)L(fng)接括hQ例如:[[my wiki topic]]׃直接引用
MyWikiTopic
词条Q如果是非规范话题,或者引用说明和引用话题不一P需要用引用与说明分开的格式,例如Q[[MyWikiTopic][my WIKI
topic]]?/p>
外部链接可以直接使用cM与词条链接的方式来引用,例如Q[[
http://blog.solrex.org][Solrex 的博客]] ?/p>
#FootNote Footnote is....
定义了一个到该段的锚炏V引用锚点和词条链接的方式也cMQ例如:[[#FootNote][to
footnote]]。如果引用别的页面的锚点Q只需要在锚点前面加上该页面的话题名,例如Q[[MyWikiTopic#FootNote][to
another footnote]]?/p>
#FootNote
1 aaa
1 bbb
当文中内定w要注释时Q?HTML ?TWiki
链接一起加一个上脚标Qaaa<sup>[[[#FootNote][1]]]</sup>Q这?aaa
的右上角可以出C个方括号Q里面是带到脚注链接的脚注编?"1"?/p>
http://www.stlchina.org/twiki/bin/view.pl/TWiki/TextFormattingRules
[2] TWiki 官方语法文档Q?/p>
]]>
WBS是一个清晰地表示各项目工作之间的怺联系的结构设计工兗?nbsp;
WBS是一个展现项目全貌,详细说明为完成项目所必须完成的各工作的计划工具?nbsp;
WBS定义了里E碑事gQ可以向高理层和客户报告目完成情况Q作为项目状늚报告工具?nbsp;
WBS
是面向项目可交付成果的成l的目元素Q这些元素定义和l织该项目的ȝ工作范围Q未在WBS中包括的工作׃属于该项目的范围。WBS每下降一层就代表
寚w目工作更加详l的定义和描q。项目可交付成果之所以应在项目范围定义过E中q一步被分解为WBSQ是因ؓ较好的工作分解可以:
帮助目l理x目目标和澄清职责?nbsp;
建立可视化的目可交付成果,以便估算工作量和分配工作?nbsp;
帮助改进旉、成本和资源估计的准度?nbsp;
帮助目团队的徏立和获得目人员的承诺?nbsp;
为W效测量和目控制定义一个基准?nbsp;
辅助沟通清晰的工作责Q?nbsp;
为其他项目计划的制定建立框架?nbsp;
帮助分析目的最初风险?nbsp;
WBS的最低层ơ的目可交付成果称为工作包(WorkPackage)Q具有以下特点:
工作包可以通过子项目的方式q一步分解ؓ子项目的WBS?nbsp;
工作包可以在制定目q度计划Ӟq一步分解ؓzd?nbsp;
工作包可以由惟一的一个部门或承包商负责。用于在l织之外分包ӞUCؓ委托?CommitmentPackage)?nbsp;
工作包的定义应考虑80时法则(80-HourRule)或两周法?Two Week Rule)Q即M工作包的完成旉应当不超q?0时。在每个80时或少?0时l束Ӟ只报告该工作包是否完成。通过q种定期查的Ҏ(gu)Q可以控刉目的变化?nbsp;
1. 创徏WBS的方?
cLҎ(gu)。参考类似项目的WBS创徏新项目的WBS?nbsp;
自上而下的方法。从目的目标开始,逐分解目工作Q直到参与者满意地认ؓ目工作已经充分地得到定义。该Ҏ(gu)׃可以项目工作定义在适当的细节水qI对于目工期、成本和资源需求的估计可以比较准确?nbsp;
自下而上的方法。从详细的Q务开始,识别和认可的项目Q务逐归类C一层次Q直到达到项目的目标。这U方法存在的主要风险是可能不?完全地识别出所有Q务或者识别出的Q务过于粗略或q于琐碎?nbsp;
2Q创建WBS的基本要?
WBS中某Q务的内容是其下所有WBS的d?nbsp;
一个WBS只能由一个h责QQ即使许多h都可能在其上工作Q也只能׃个h负责Q其他h只能是参与者?nbsp;
WBS必须与实际工作中的执行方式一致?nbsp;
应让目团队成员U极参与创徏WBSQ以保WBS的一致性?nbsp;
每个WBSw必须文档化,以确保准理解已包括和未包括的工作范围?nbsp;
WBS必须在根据范围说明书正常地维护项目工作内容的同时Q也能适应无法避免的变更?nbsp;
3QWBS的表C方?
按品或目的功能分解?nbsp;
按照实施q程分解?nbsp;
按照目的地域分布分解?nbsp;
按照目的各个目标分解?nbsp;
按部门分解?nbsp;
按职能分解?nbsp;
5Q创建WBS的过E?
召集有关人员Q集体讨论所有主要项目工作,定目工作分解的方式?nbsp;
分解目工作。如果有现成的模板,应该量利用?nbsp;
dWBS的层ơ结构图。WBS较高层次上的一些工作可以定义ؓ子项目或子生命周期阶Dc?nbsp;
主要项目可交付成果l分为更的、易于管理的l分或工作包。工作包必须详细到可以对该工作包q行估算(成本和历?、安排进度、做出预 、分配负责h员或l织单位?nbsp;
验证上述分解的正性。如果发现较低层ơ的Ҏ(gu)有必要,则修改组成成分?nbsp;
如果有必要,建立一个编L(fng)l?nbsp;
随着其他计划zd的进行,不断地对WBS更新或修正,直到覆盖所有工作?nbsp;
验W(xu)BS是否定义完全、项目的所有Q务是否都被完全分解可以参考以下标准:
明确定义了每个Q务的开始和l束?nbsp;
每个d都有一个可交付成果?nbsp;
工期易于估算且在可接受期限内?nbsp;
Ҏ(gu)估算成本?nbsp;
各项d是独立的?nbsp;
6QWBS的?
]]>
旉的要素──完成的时间要“?#8221;?
成本的要素──完成的成本要“便宜”?
效果的要素──完成后的表现?#8220;?#8221;?
q三个彼此互斥的要素Q就像等边三角Ş的三边一P~Z一边,或Q何一Ҏ(gu)其它两边短,我们׃能再U其为等边三角Ş?
在我的经验中Q如果在q三个要素中只要做到一,q种专案好做Q百分之八、九(ji)十以上的目l理大概都可以愉快胜仅R如果在三个要素中要做到两项Q就不是一
般的目l理能胜ȝ了。在比率上,我认把以上三个要素中的Q何两做到的目l理Q大概不会超q百分之五十。真正能够把目中三个主要需求都做到?
高手Q在一百位目l理中,最多不到十个?
有h听我q么说也怼不服气,认ؓ我在q里p耸听Qؕ吓唬人。他们不了解我的本意。我的本意只有两点:W一Q项目成功的要素Q彼此之间是g熊掌的关
pR第二,要兼儡隑ֺQ是照几何C升而不是按术U数上升。这样一个三角难题,要我们怎么去解军_Q我认ؓ应该从两斚wȝ手?
什么是好、快、便?/strong>
W一Q我如果是个目l理Q一定要问:什么是“?#8221;Q什么是“?#8221;Q什么是“便宜”Q?
“?#8221;字咱们中国h用来真是千变万化Q神奇不巌Ӏ有时用来作副词Q这颜色“?#8221;漂亮。有时用来做动词Q那个家伙很“?#8221;Ԍ可不是什么恭l之词?#8220;?#8221;?
用得恰当Q又变成了另外意思的代名词了。别人问Q?#8220;q个奛_子怎么P”你说Q?#8220;她很好?#8221;a下之意,是不很漂亮。别人问Q?#8220;q个人怎么P”你回{:
“他很好?#8221;a下之意,是他不太能qӀ同Ӟ某一个h认ؓ好的Q另外一个ƈ不认为好Q这是我们日常生zM帔R到的问题?
在项目管理中Q好是好,不好是不好Q这没有什么主观或客观的差异,也没有什么明C或暗示的问题存在。要谈到目理?#8220;?#8221;的定义,W一个条件就是要
看它是不是有用?#8220;有用”?#8220;能用”是两回事。很?#8220;能用?#8221;东西不一?#8220;有用”Q这牉|到客观h(hun)值的问题。有一天,我在台北的街上看C个年Mh开了一
部d国制的跑车,车尾上还有一块压风板。我心想Q在台北q种交通堵塞、寸步难行的情况下,开q种跑R真是龙游水Q英雄无用武之地。这部跑车算不算是部?
车呢Q当然算。但在台北街头这U客观环境之下,它还不是部好车?当然不算?
我从前有一只瑞士制的名表,是属于那U很c很多仿制品的那U。因动,它才会上弦,不动它,隔一阵就停了。我后来不胜其烦Q换了一只日本制的石pQ?
价钱只有那只瑞士表的几十分之一Q不但不用上弦,q且有两个时_能让我不用花脑筋可以同时知道台湑֒国加州的时间。早上六点它会把我闹醒,打球、洗
澡也懒得把它脱掉Qƈ且是夜光的。你说这两个表那个比较好Q我可以很坦白地告诉你,因ؓ后者比较有用,后者比较好。因此,在项目管理上Q关?#8220;?#8221;的定
义,?#8220;有用”而非“能用”?
“?#8221;的第二个条gQ要看它是不是能辑ֈ原先要达到的目的。如果说目的是代步,汽R比脚tR好;如果说目的是q动Q脚tR却比汽R好。在日常生活中,有h
叫你MҎ(gu)Q结果你C桔子回来。苹果和桔子虽然不是一P但也许还勉强可以淯厅R在目理上,如果要的是苹果,交货的时候却变成了桔子,q就不能
是一个成功的目。ؓ了避免这U错误,目l理必须在项目设计时把项目结果的规格先弄清楚。口说无凭,要的东西都要写下来。交货的时候,如果我交l你?
是规g写明的东西,那我ql你一?#8220;?#8221;东西?
不管目的成果是什么,也许是一套Y件系l,或一部新的机器,或一条新修的铁\……凡是好的东西Q一定是Ҏ(gu)用的东西。当录像机刚出来的时候,懂得怎么?
它去录电(sh)视节目,真是一门大学问。在我的朋友中,大多Ch都不会用Q尤其是太太们,十有?ji)h不会用它。不会用、不敢用之h中,很多q都拥有博士学位哩。ؓ
什么?因ؓ它设计得太复杂,太不Ҏ(gu)用了。后来有两个工程师,惛_一个办法,h个电(sh)视台把每个节目都用一个不同的数字来代替,到时候Q何h只要把他惛_
节目的代可q录像控制器中,节目旉一刎ͼ录像开始,q样一来,Zh会用录像机。从目理“?#8221;的定义来看,单、好用的东西Q就?#8220;?#8221;的东ѝ?
一个项目的产品Q除了有用和好用之外Q还要具有可塑性和可扩展的Ҏ(gu)。前者表C它的功能,在必要时可以加以改变。后者表C在旉上,它不但可以持久ƈ能扩
展。美国的公\是艾豪威尔L时的hQ在设计上,考虑到必要时可供喷射战斗v落。扩充性比可塑性更重要。如果说一套计机实用软g的设计,在开
发完成上U不久,׃能满_怸务上的新需要的话,设计q套pȝ的项目还够格UCؓ一个好专案吗?当然Q未来的需要也怸是目前能预料的,Z不可预测?
来而牺牲现在的需要当然不对,但无论如何,一个好的项目,它所设计的品必d有容易修攏V可以扩充,q且不会马上失效的弹性。缺乏这U弹性的产品Q就
不是一个好的品。一个生产没有弹性品的目Q就不能是一个好的专案?
但是一般所谓好的项目,I竟指的是什么呢Q换句话_怎么知道q个目是成功的目或失败的目呢?你只要问Q项目的l果能否使公司的收入增加Q项目的l果能否使公司的支出减少Q项目的l果能否使公司的服务加强Q能辑ֈq三个目的,是好的目?br />
接着Q让我们来谈谈什么是“?#8221;Q在我们日常的生zMQ?#8220;?#8221;?#8220;?#8221;一P往往是主观的而非客观的。有时它又是凭感觉而非凭理性的。小时候写作文Q常?
Ƣ用“光阴似箭”来破题。遇到做自己不喜Ƣ做的事情,老喜Ƣ用“度日如年”来Ş宏V在目理上,旉是绝对的Q而非凭感觉的——能在半q内完工Q就是比
在九(ji)个月内完工要快三个月。但q个目能在半年内完工就快吗?谁说的?我们搞项目管理的人常讲一个笑话:如果你问你的老板他希望什么时候要q个目?
工,他一定会回答_昨天。因此,目l理最Ҏ(gu)犯的一个错误,是在完工日期的预测上,Z讨好上司的要求而尽量乐观。同Ӟ老是用历史的数据或别人的
l验来媄响自q预测Q殊不知每个目的客观条件和外在环境都不一栗项目经理在作完工预时Q千万要记得一个教训:你的老板或客户不会记得你告诉他多?
可以完工Q因为再快他们都会嫌慢,但如果你告诉他们该完工的时候完不了工,那你的麻烦可大了。所以在预估Ӟ胆子攑ְ点,旉N些。还有一Ҏ(gu)重要Q?
板们当然不喜Ƣ听坏消息,但更不喜Ƣ听Zh意外的坏消息Q因此当完工的预如果出问题的时候,l不能隐瞒,着头皮也要让老板知道?
要达到预期完工的要求Q项目经理一定要懂得怎么把一个规模大、时间长的项目,分成不同的阶D|完成。在每个阶段中,又要Ҏ(gu)每阶D不同的重点分别来作完工
预测。工E分得越l,预测的准性就高。这道理很普通,但做h却很困难Q因为需要很周详的计划和分析。计划和分析要花脑筋Q可不是每个人都能做到的?
说了半天Q快字诀只有一点,如果一切按照计划,q就合乎快的原则Q否则就是不快。该完工时完工就是快Q否则就是慢?
至于什么是“便宜”Q我以ؓ省钱不是目理中最重要的目的。一个项目该花多钱Q是应该早就出来的。一般来_如果实际的花费和预估的花费差别在
30Q左叻I应该是能接受的范_过30Q,表示预算做得不彻底。在目理里,最N估的不是完工的时_而是目的预。项目经理在q方面遭受的?
力,比什么都大,因此Q在做预的时候,必须面对现实Q既不能故意灌水Q也不能故意q䆾乐观。一个聪明的ȝQ要重视的是产品的h(hun)|而非只是重视价钱?
不懂得在价g动脑{,只懂得在价钱上打盘的项目经理,前途不乐观。但是h(hun)值有两种Q有形的价值和无Ş的h(hun)倹{在目理中,无Ş价值是致命伤。坦
白地_如果一个项目没有有形h(hun)值当后台Q其存在的h(hun)值就很有限。在我刚才提
到那三个目的目的中Q增加收入和减少支出属于有Ş价|增强服务属于无Ş价倹{有形h(hun)值高的项目,是“便宜”的项目。否则,是不便宜的目?
学会取舍分析
目l理了解目理三角关系的定义之后,臛_寚w目追求的目标不会太迷p。但q不能担保从此就天下太^。Q何项目经理都x他的目得又快、又好、又便宜。但事实上,不是每个目都能辑ֈq个境界。有时候,也ƈ非一定要辑ֈq个境界不可?
一位有l验的项目经理,一定要懂得怎么?#8220;取舍分析”。换a之,懂得“弃R保帅”的重要性。如果我们用我提到过?#8220;快、好、便?#8221;来作标准Q有的时候三者可以只取其一Q或者只取其二,q就是我们所谓的“取舍分析”?
现在Q让我D几个例子来说明一下,我在q方面的看法?
一般来_凡是属于研究发展的项目,其是有兌品方面的研究发展Q钱和时间都很有Ҏ(gu),但对目产品的品质却没有MҎ(gu)。换句话_快、好、便宜的q?
个三角ŞQ?#8220;?#8221;的那Ҏ(gu)什么都重要。反q来_一般重工业机械或房屋徏{等有关目Q?#8220;?#8221;却是最重要的因素,因ؓ只有在项目结束交货后Q才能收ƾ来l?
l以后的目?
再看有关刉环保控制机器的发展目Q由于它的订价和效果已经按法律的规定而不能再有太多弹性,但在交货的时间上Q快不快q不是那么重要。相反地Q所有的咨询目Q在旉和h(hun)׃没什么弹性,但在成品的品质方面,好不好就大有融通的余地?
有些目是没有什?#8220;弃R保帅”那套的。一?ji)六○年代初期,国受苏联发史泼尼克号人造卫星的刺激Q肯D_ȝ下命令要?960q代l束前把人送上?
球,q安全地带回来。这个庞大的专案Q在旉上要快,必须赶在苏联之前完成Q要好,l不能出CQ何差错;q且在预上有限Ӟ因ؓ预算来自老百姓交的税Q?
l国会通过才行。结果,国果真抢先把hc送上月球Qƈq_地带回来。在历史上可以和q个目媲美的,大概只有造原子弹的曼哈顿目了?
我提?#8220;弃R保帅”的观念,q不是要国内的项目经理们攑ּ理想Q不q求目三角关系的完。我只是一点:当这个三角难题无解的时候,要懂得顾全大局Q?
两害相权取其轅R很多时候,׃外在和内在的压力Q?#8220;取舍分析”是免不了的。要做好取舍分析Q项目经理至要懂得六g事:
W一Q要很清楚地了解目冲突的基本原因?
W二Q重新确认项目的目的?
W三Q了解项目现处的环境及目前状c?
W四Q寻求可行的其它Ҏ(gu)?
W五Q选择最佳的其它Ҏ(gu)?
W六Q重新策划项目计划?
目的目的,不外乎增加公司收入、节省公司支出和提升公司服务水准三者。项目的成功与否Q取决于目完成是否又快又好又便宜。这个三角关p虽焉解,但ƈ非无解。运用之妙,存乎一心。我在此文中谈到的一些技巧,有点像野人献曝,希望有些参考h(hun)倹{?br />
]]>
当我们的办公室内堆满了杂乱无章的文gӞ恐怕无法知道对于我们真正有用的文g在哪里,当我们的软g相目中收集了各种需求、意见、问题时Q我? 也很难从中估出整个目的规模、工作量以及成本。因此,在估之前我们首先要对众多信息进行整理、归cd析,从而得C个条理清晰的目计划Q在q个? 划提供的框架内,才可能开始正的估算。精心的规划是Q何一个Y件开发项目成功与否的关键Q有了规划就有如成竹在胸Q之后无论风云变q,都有应对入流的方 法。当然只有正的规划Q才能给软g开发指引正的方向?/p>
软g目规划的重Ҏ(gu)对h员角艌ӀQ务进度、经贏V设备资源、工作成果等{做出合适的安排Q制定出一些计?包括高层的和l节?Q大家按照计划行事Q最l顺利地辑ֈ预定的目标。blog.mypm.net
1.1、规划的W一步:定软g范围
定软g范围Q就是确定目标Y件的数据和控制、功能、性能、约束、接口以及可靠性。这工作和需求分析是很类似的Q如果之前已l达成需求分析规 U,那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析,关于定软g范围的方法方面,我们可以采用许多需求分析技?? 需求诱?Q从客户那里得到一个具体的软g范围。当然如果是一ơ全新的软g边界探烦Q就应当考虑软g本n可行性问题,包括团队是否具备在技术、胦务、时 间、资源上游可靠的保障QY件本w在市场上是否有可靠的竞争优?Q等{?/p>
获得软g范围Q最直接最可靠的来源就是用户对软g的需求描q。例如,在开发一个C/S架构的铁路供甉|数据上报pȝ中,客户向我们提供了以下的目标Y仉求描qͼ
在供늫总部每天l束前要审核下属节点操作?30~40?的供?sh)安全数据报表,要求每个节点必须在下?Q?0~6Q?0之间上传数据。? 部系l通过自动分析Q整理出整个区内的安全Ş势报表,q自动反馈到每个节点。各个节点之间通过调制解调器拨?MODEM)用内部电(sh)话线相连Q每个节点电(sh) 脑主机配备一个MODEM。上传数据ؓ制式报表Z制式信息外,pȝ自动附加操作员姓名、上报时间、上报节点名U。信息一旦上传,节点端就不可以对已提? 信息q行修改、删除,只能阅读、查询。节炚w数据互相隔离Q只有总部才具备对各个节点数据的管理权限,但是对于归档数据(一旦审核完毕的数据Q就q行? ?总部不具备删改的权限。系l设|数据库理员,独立于审核权限,其职责是对历史数据的清理l护。项目经理圈?/p>
通过上面的描qͼ我们通过提炼和简化,得到软g的一下功能:
?节点数据录入、查询、上?/p>
?总部数据汇怅R查询、反?/p>
?总部与节点的互联
?总部数据库存?/p>
?节点数据的本地存储项目管理者联盟文?/p> 在本例中QY件的性能是潜在的。客戯然没有明提出,但是׃数据本n的重要性,要求pȝ在数据上传、反馈、存储过E中安全可靠。客戯求 用MODEMq行拨号q接Q那么鉴于MODEMq接q程中可能会出现Q由于拨h开而道D的数据丢失,在节Ҏ(gu)地存放一份数据副本是有必要的。由于系l? 要求每天上传数据Q总部数据库应当是7X24时不间断服务的Q再加上目前总部只有该系l运行接受数据Q务,各节Ҏ(gu)据量q不大,那么在徏议用户选择服务 器时Q应当考虑性能E_可靠Q但q不一定要购买大容量磁盘阵列和高性能双CPUL。由于每天上传数据接q下班时_那么总部汇L据应当是自动q行的, 一旦分析发现重大问题,可以通过与外部网l的讄Q向值班人员发送手息、E-MAIL或其他警C。由于不同h员对于上报数据的权限不同Q对于系l用? 实行分理。不同别的用户Q具有对数据的不同管理权力,从而保证在软g使用q程中不发生混ؕ?br /> 那么现在一个较为清晰的软g模型已经构造完毕,接下来我们需要进入计划的W二步:定工作所需资源?
1.2、规划的W二步:定工作所需资源
软g工作所需资源包括Q工作环?软硬件环境、办公室环境)、可复用软g资源(构g、中间g)、h力资?包括不同各种角色的h员:分析师、设 计师、测试师、程序员、项目经?#8230;…)。这三种资源的组成比例,可以看作一个金字塔的模式,最上面是h力资源、其ơ是可复用Y件资源、最下面是工作环境? 最上面的是l成比例最的Q最下面的是l成比例最大的部分?/p>
?人力资源
一个项目到底需要多种职务的h员构成、多数量的人员总量Q再能成为最有创造力的团队呢?q恐怕是最让项目经理头疼的事情了。Q何一个Y件工 E,都必d定软g的工作量之后Q才能清楚地知道I竟需要多h力才能以最成本和最高效率完成Q务。在q之前,不能盲目地进行h力扩充,而且l对不能 Zl公司抬高门面,盲目招收高学历?/p>
?可复用Y件资?/p>
q是一个容易在计划阶段被忽视的重要资源Q很多hLq入~码阶段才发现可复用资源的h(hun)值和存在。经q长期的目U篏或是购买Q公司的软g资源 库中或许已经U篏了大量的可复用资源,但在当前d中,只能选择有h(hun)值的资源。根据不同的应用、时间、来源,可复用Y件资源被分ؓ以下几种Q?/p>
可直接用的构gQ已有的Q能够从W三方厂商获得或已经在以前的目中开发过的Y件。这些构件已l经q验证及认且可以直接用在当前的目中?/p>
h完全l验的构Ӟ已有的ؓ以前cM于当前要开发的目建立的规U、设计、代码、或试数据。当前Y仉目组的成员在q些构g所代表的应用领域中h丰富的经验。因此,对于q类构gq行所需的修改其风险相对较小?/p>
h部分l验的构Ӟ已有的ؓ以前与当前要开发的目相关的项目徏立的规约、设计、代码、或试数据Q但需做实质上的修攏V当前Y仉目组的成员在q些构g所代表的应用领域中仅有有限的经验,因此Q对于这cL件进行所需的修改会有相当程度的风险?/p>
新构Ӟ软g目lؓ满当前目的特定需要而必M门开发的软g构g。training.mypm.net
在采用构件的时候,应当以低成本、低风险Z用前提。如果Q何一个漂亮的构g的应用,可能会带来潜在出错的风险或者必ȝq复杂修Ҏ(gu)者效率低 下时Q我们都应当毫不犹U地把它抛弃。我们只采用那些能够满目的需要且可直接用的构gQ或者具有完全经验的构gQ或者经q稍微修改便可用的构g?/p>
?环境资源
“工欲善其事,必先利其?#8221;Q要得到高效的开发过E,必d工作人员提供良好的Yg环境Q包括开发工兗开发设备、工作环境、管理制度。一般管理h员都会购买可以满需要的软g开发工具和gq_Q但是工作环境和理制度往往被忽视?/p>
站在Zg的角度看Q向工作人员提供更轻松自在、安静舒适的办公环境的公司员工往往比整天在狭小隔间中工作的公司员工Q生更高的工作效率。而那 些拥有灵zMh性化的管理制度的公司Q比整天加班的公司更能留住高技术的人才。所以如何在有限资金中,规划一个合理的环境是很重要的事情?/p>
到此为止Q估前的项目计划已l完成,我们已经形成一个工E开发框架。这是一个有界限的框Ӟ虽然q不够精,但以进行估的工作?
2、估的对象
目前为止Q一个较为准的软g目估算的定义是Q在l定公差范围内,对于姚开发的软g规模的预,以及对开发Y件所需的工作量、成本和日历事g的预。这个概忉|Z一个事实,即估是一U大U的估计Q是误差限定在一定范围内的估计?/p>
估算主要包括以下几个重要内容Q项目管理者联?/p>
?规模估算
软g估算首先要将整个工程的规模估出来,才能q行下面的其他估。规模,是一个工E可量化的结果,是用具体数字来体现项目的描述。规模估的信息来源是清晰、有界限的用户需求?/p>
?工作量估?/p>
q是对开发Y件所需的工作时间的估算Q它和进度估一起决定了开发团队的规模和构建。通常以h时、h天、h月、hq的单位来衡量,q些不同单位之间可以q行合理的{换。blog.mypm.net
?q度估算
q度旉目自始至l之间的一个时间段。进度以不同阶段的里E碑作ؓ标志。进度估是针对以阶Dؓ单位的估,而不是对每一个细Q务都加以估算Q对d的适当分解很重要,分解得越l反而会不准。因ZQ何一个Y件工E,在各个方面都有与生俱来的不确定性?/p>
?成本估算
包括人力、物质、有形的、无形的支出成本估算Q其中以人力成本Z要部分。比较容易被忽视的学习成本、Y件培训成本、h员变动风险成本、开发g期成本等Q一些潜在成本消耗。{自项目管理者联?/p>
3、估的{略
在Y件估的众多Ҏ(gu)中,存在着“自顶向下”?#8220;自底向上”两种不同的策略,两种{略的出发点不同Q适应于不同的场合使用。项目管理培?/p>
3.1、自向下的{略
q是一U站在客L(fng)角度来看问题的策略。它L以客L(fng)要求为最高目标,M估算l果都必ȝ合这个目标。其工作Ҏ(gu)是,由项目经理ؓȝ一个核心小l根据客L(fng)要求Q确定一个时间期限,然后Ҏ(gu)q个期限Q将d分解Q将开发工作进行对号入座,以获得一个估结果?
当然׃q完全是从客戯求出发的{略Q而由于Y件工E是一个综合项目,几乎没有哪个目能完全保质保量按照预定工期完工,那么q样一个策略就 ~少了许多客观性。但是由于这样完成的估算比较Ҏ(gu)被客戗甚臌目l理所接受Q在许多公司我们看到q样一个ƈ不科学的{略仍然被坚定地执行着?/p>
3.2、自底向上的{略
与自向下的{略完全相反Q自底向上的{略是一U从技术、h性的角度出发看问题的{略。在q样一个策略指引下Q将目充分讨论得到一个合理的? 务分解。在每个Q务的难易E度Q每个Q务依照项目成员的特点、兴特长进行分配,q要求进行估。最后将估算加v来就是项目的估算倹{?/p>
昄自底向上的这U策略具有较为客观的特点Q但是它的缺点就是这样一来项目工期就和客L(fng)要求不一致了。而且׃其带来的不确定性,许多目l理也不会采用这U方法?/p>
4、估的Ҏ(gu)
昄估算是徏立在客观实际上,Ҏ(gu)来尽可能合理的一U预。那么估本w的不确定性,军_了它不可能是癑ֈ之百准确无误的。在目刚开始时Qh 们对产品需求、技术、市场预期、h员素质等因素的了解还q远不够Q在q种情况下h们很难作出准的估计。但是依据某U方法进行估计显然比瞎猜好得多?/p>
估算Ҏ(gu)有很多,大致分ؓZ分解的技术和Zl验模型两大cR基于分解的技术的Ҏ(gu)包括功能点估法、LOC估算法、MARK II{?Zl验模型的方法包括IBM模型、普特南模型、COCOMO模型{?/p>
4.1、FP功能点估法
功能点估法是一U在需求分析阶D基于系l功能的一U规模估计方法。通过研究初始应用需求来定各种输入、输出、计和数据库需求的数量和特 性。这U方法的计算公式是:功能?信息处理规模x技术复杂度。信息处理规模包括各U输入、输出、查询、内部逻辑文g数、外部接口文件数{等;技术复杂度 包括性能复杂度、配|项目复杂度、数据通信复杂度、分布式处理复杂度、在U更新复杂度{等?/p>
4.2、LOC估算?/p>
q是一U从技术的角度来估的Ҏ(gu)ȝQ其中又包含许多Ҏ(gu)。这cL法以代码(LOC)作ؓ软g工作量的估算单位Q在早期的系l开发中较ؓq泛 使用。基于LOC的估,又有点也有缺炏V优点在于方便计、容易监控、能反映E序员的思维能力;~点在于代码行数的含p不清,不能正确反映一工作的? 易程度以及代码的效率。因此在传统的LOCҎ(gu)q行了许多改q。其中不断被使用Q且不断演化的方法包括以下:www.mypm.net
PERT功能点估法QPERT对各个项目活动的完成旉按三U不同情况估计:一个品的期望规模Q一个最低可能估计,一个最高可能估计。用q三个估计用来得C个品期望规模和标准偏差的Pert l计估计QPert 估计可得C码行的期望值和标准偏差SD?/p>
cL估算法:cL法适合评估一些与历史目在应用领域、环境和复杂度的怼的项目,通过新项目与历史目的比较得到规模估计。类比法估计l果? _度取决于历史目数据的完整性和准确度,因此Q用好类比法的前提条件之一是组l徏立v较好的项目后评h(hun)与分析机Ӟ对历史项目的数据分析是可信赖的。项目管理者联?/p>
Delphi估算法:Delphi法是一U专家评估技术,在没有历史数据的情况下,q种方式适用于评定过M来Q新技术与特定E序之间的差别。对于需要预和深度分析的领域,依赖于专家的技术指|可以获得较ؓ客观的估。通过专家们的互相讨论Q还可以博取众长?/p>
pȝ分解Q将pȝ分成若干个易于用LOC估算的部分,其各个估算l果累加是LOC的总规模。其中关键是建立起SBS(pȝ分解l构)Q它描述? pȝ的不同组件。SBSq被使用在其他重要的地方Q如pȝ设计、系l分析等。在q行分解的时候,可以采用自由讨论的Ş式,可以获得更合理的SBS构成?
4.3、IBM模型估算?/p>
该模型是Watson和Felix?977q发布的Q是ZIBM联合pȝ分布负责?0个项目的ȝ而得到的模型。该模型是一个静态模型,而参考数据只?0多个目Q因此有很大的局限性。项目经理圈?/p>
4.4、COCOMO估算?/p>
Boehm在其l典著作“软g工程l济?#8221;(software engineering conomics)中,介绍了一UY件估模型的层次体系Q?UCؓCOCOMO(构造性成本模型,COnstructive COst MOdel)Q它代表了Y件估的一个综合经验模型?/p>
COCOMO 模型是适用于三U类型的软g目Q?1)l织模式——较?yu)的、简单的软g目Q有良好应用l验的小型项目组Q针对一l不是很严格的需求开展工?如,Z 个热传输pȝ开发的热分析程?;(2)半分L式——一个中{的软g目(在规模和复杂性上)Q具有不同经验水q的目l必L严格的及不严格的需? (如,一个事务处理系l,对于l端g和数据库软g有确定需?;(3)嵌入模式——必d一l严格的g、Y件及操作U束下开发的软g目(如,飞机? 航空控制pȝ)。项目管理培?/p>
4.5、Y件方E式估算?/p>
软g方程式是一个多变量模型Q它假设在Y件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000 多个当代的Y仉目中攉的生产率数据中导出的公式。初期的方程式较为复杂,通过QPutnam 和Myers的努力又提出一l简化的方程式。当然这U方法也是基于长期的参考数据的U篏而得到的?/p>
4.6、WBS估算?/p>
q是一U基于WBS(工作d分解)的方法,卛_把项目Q务进行合理的l分Q分到可以确认的E度Q如某种材料Q某U设备,某一zd单元{。然后估每个WBS要素的费用。采用这一Ҏ(gu)的前提条件或先决步骤是:
寚w目需求作Z个完整的限定。blog.mypm.net
制定完成d所必需的逻辑步骤?/p>
~制WBS表?/p>
目需求的完整限定应包括工作报告书、规g以及总进度表。工作报告书是指实施目所需的各工作的叙述性说明,它应认必须辑ֈ的目标。如? 有资金等限制Q该信息也应包括在内。规g是对工时、设备以及材料标L(fng)Ҏ(gu)。它应该能ə目人员和用户了解工时、设备以及材料估L(fng)依据。总进度表应明 项目实施的主要阶段和分界点Q其中应包括长期定货、原型试验、设计评审会议以及其他Q何关键的决策炏V如果可能,用来指导成本估算的总进度表应含有项? 开始和l束的日历时间?/p>
除了以上介绍的几U方法外Q还有一些其他的Ҏ(gu)Q类比估、推估、Standard-component估算法、普特南估算法等。当然不? 的方法适用于不同的具体环境Q有些方法虽然很好但q不一定适合当前的Q务。只有量体裁衣,具体问题具体分析Q才能得到尽量合理的估算?/p>
5、估的戒律
CQ应该满于事物的本性所能容许的_度,当只能近g真理Ӟ不要d求绝对的准确?? ——亚里斯多d
对于M一个项目经理,都知道要慎重估算Q但是我们仍然会看到人力资源的浪费和财力资源的匮乏,在许多项目中存在。对于宝늚资源Q我们不是用得太多,是Ҏ(gu)不够用。因此,有以下前人ȝ出来的一些经验以供借鉴。项目经理圈?/p>
不要q求完美Q就像没有h能预出未来Q如果还没有完成Q就不要企图完美的结果。更何况估算的太_Q反而会失去灉|机动的空间?/p>
不要为满预而估:如果q个目的预根本不能完?00%的Q务,那么׃要让你的团队委曲求全。正地反映客观现状Q不仅可以争取应得的权利Q而且是完成Q务的前提?/p>
不要随意削减估算l果Q有很多老板喜欢把项目经理递交的估,不假思烦地砍掉一部分。这是一U不负责ȝ做法Q如果要削减一定要有理由。项目管理培?/p>
客观C,不贪多不偷减Q就像老板不能随便削减你的估算一P你也同样不能在估的时候,贪多或是偷减。贪多必然导致会费Q偷减必然导致不뀂这两个l果恐怕都不是一个合格的目l理的作为?/p>
客观利用q去的经验:对于以往估算的经验,当然是宝늚财富Q但是如果胦富用错了地方׃变成垃圾。在使用l验Ӟ要注意现在和参考经验之间的差异。不要忘讎ͼ随着旉的推U,计算机领域技术的更新Q许多观念都在发生着改变?/p>
不要以客L(fng)标作Z的l果Q客h上帝QY件公怸定要力实现客户的需求。但我们要实现的是合理的目标Q况且不能ؓ了完成目标而去堆积数字Q这样岂不是因果倒置了?/p>
不要隐匿不确定的成本QY件开发中存在潜在风险Q是很正常的事情。现在风险就会带来潜在的成本Q如Q突然一位程序员职Q导致工作进度\落后。我们不可能估算CQ何一U可能发生的情况Q但有责L可能出现的一些关键环节列出来?/p>
我国软g从业人员?0多万人,?000多家软g企业中有60%?0Z下的企业,1000Z上的企业?0余家QY件出口额不到印度 ?0%。在印度的优U软g企业如Wipro、Infosys、Tata中,软g开发项目的按时完成率高?5%以上Q可以说是项目管理能力促q了印度? 件企业承揽外包业务和规模化的发展。据l计Q目前我国Y件企业项目的按时完成率^均ؓ20%左右。可见,我国软g企业在项目管理能力方面与印度软g企业? 比还存在很大差距。项目管理者联?/p>
一、面向利益相兌的目{划
软g目{划的目的主要在于明晰定义项目的价值和目目标Q它是Y仉目正式启动的基础是明项目需求的基础Q也是控刉目范围的基础。据l? 计,过50%的Y仉目都遭受q不充分的需求管理的问题Q^均有25%的Y仉目需求会发生变化。对有缺L(fng)需求、设计、代码进行返工的p占整个项? 费用?0%?0%。项目策划的要点包含以下四个斚w。training.mypm.net
1.识别和定义项目的利益相关者www.mypm.net
C目理的核心理忉|目必须让其利益相关者满意,要理解和定义目的h(hun)|q而在此基上定义项目的目标Q必M识别目的利益相兌入 手。然而,实践表明Q识别清楚Y仉目的利益相关者ƈ不是一件容易的事。有时一个项目进行了很长旉Q但目l未必知道项目的真正客户是谁Q最常犯的错? 是仅项目成果的使用者作为客戗例如,?sh)子政务pȝ的真正用h该机关的决策层,而不是具体负责这个电(sh)子政务项目的某个部门。如果需求仅仅来自负责这? 目的某个部门,那么即ɘq个pȝ建好了,也极有可能没有真正达到目的。但是由于各U原因,决策层h员往往没有_的精力来兛_qg事,q时如果目l不 L方设法解册个问题的话,那么Q这个项目从一开始就埋下?#8220;陷入泥潭”的阴影。此外,必须识别出具体的目发v人ƈ充分发挥其作用。实践过E中易犯? 错误是误一个部门、一个机构作为项目的发v人,q样的结果是决策时有很多人,但真正需要项目发起h提供资源、予以协调时却找不到人?/p>
2.促成利益相关者的参与
不仅是在{划zd中,在整个Y仉目的生命周期内都必须目利益相关者的参与Q必要与利益相兌一起启动项目。由于Y仉目的成果改? Z的生zL工作方式。因此,客户必须在项目策划阶D就了解目成果对其生活或工作方式的影响Q他们必d发相应的政策、流E等以准备接受项目成果。目? 众多的ERP目之所以失败,重要的一个原因是Z误认为ERP目仅是一个信息系l项目,该项目带来的仅仅是一个信息品。其实,ERP目带来的是一 新的q营方式Q如果企业在没有做相应调整的情况下强行引入ERPQ将会企业q行的乱速度加快而不是更好。事实表明,促软g目成功的最重要的要素莫 q于利益相关者的全过E参与。项目经理圈?/p>
3.培育/q用行业专家目l理圈子
软g目的h(hun)值是Z实现某些商业目的Q它们一般是p业专家而不是由软g开发h员挖掘出来的。许多Y件企业被投标h所困扰Q其原因有来自市 场竞争方面的Q更多的则是软g企业没有能够挖掘目的h(hun)值所致。目前,许多软g企业的弱点在于缺乏行业专Ӟ它们没有意识到行业专家也是专业h员,而只? Y件开发h员作Z业h员对待。在目定义zd中,软g开发h员常犯的错误有三点:需求镀金、需求过滤和需求包办。所谓镀金,是指软g开发h员不֮? 的实际需求,片面和夸大技术先q?所谓需求过滤,是指软g开发h员根据自q技术偏好对客户的需求进行了主观{?所谓需求包办,是指客户需求分 析委托给“专业?#8221;软g开发h员,而他们也乐得如此。实践证明,~Z行业专家的项目策划所产生出来的东西一般是能力q剩的、不适用的,甚至是完全不能用 的。如果Y件企业没有自q行业专家Q必d于利用外部的行业专家?/p>
4.不可忽视目的验收标?/p>
寚w目目标一致性重视程度不够,是项目启动过E中普遍存在的一个问题。很多项目管理者低C达成目目标一致性的隑ֺQ在q方面投入的_֊? 够,往往单地认ؓ目标已经达成一致。很多项目其实是在目标没有定义清楚的情况下匆忙启动的。因此,软g目{划的结果必M利益相关者对目目标的理? 达成一致。要做到q一点,最有效的办法是讑֮目的验收标准。可以以目的客户ؓ例说明这一炏V客L(fng)需求包含多个方面,其中既有寚w目成果特性的要求Q? 又有客户在感情等斚w的需求。简单说来,客户的需求可以分Zc:目l理圈子
W一cL“Musts”Q即如果~少了就不能实现目基本目的的成果特?
W二cL“Wants”Q即客户希望得到的能够丰富项目成果的东西?br />二、基于统计数据的目计划
软g目计划q程面(f)的最大挑战就是计划的准确性差。据l计Q在对Y仉目进度与成本估算Ӟ开发者的估算比现实要乐观Q大U低20%? 30%;大多数项目实际完成时间超q估进度的25%?00%Q少数的q度估算_度达C10%Q能控制?%之内的项目十分罕见。要提高软g目? 划的准确性,需要把握以下三点:目理培训
1.加强基础数据的统计与分析
软g目都是h独特性的Q不能照搬其他项目的l验作ؓ制定本项目计划的依据。因此,在企业范围内加强寚w目基数据的统计分析以得出规律是十 分必要的。项目管理既是科学又是艺术,׃文化的差异,西方发达国家的是理中的U学性,而我国的l大多数企业的是理中的艺术性。由于不重视? 数据的收集和l计QY仉目的计划常常是凭l验?#8220;拍脑?#8221;而定的,企业q没有够的l计数据来支持计划的制定。科学管理尽是在上个世U初Q对刉业 和体力工人提出的Q但其中提出?#8220;不能度量׃能控?#8221;的理念依然值得软g企业在管理项目时采纳?/p>
2.以面向学习和改善pȝ的评价原则促q数据统计training.mypm.net
评h(hun)方式决定h们的行ؓQ要x变h们的习惯Q仅靠讲道理是难以见效的Q还必须辅之以相应的评h(hun)体系。Y件企业在目理评h(hun)q程的一个误? 是将评h(hun)的重Ҏ(gu)在h的方面,而忽视了很多目问题在于理pȝ本nq个事实。据l计Qh员的敬业_和能力不够只占项目失败原因的10%左右Q在大约 90%的原因来自于目理pȝ的架构与程{方面?/p>
3.谨防里程陷?/p>
众所周知Q里E碑是项目计划与控制中的一个极为重要的概念Q也正因为如此,Z也易于过于依赖里E碑Q反而ə目计划落空。里E碑陷阱表现在以 下几个方面:首先Qh们在软g目的里E碑被设定以后,认ؓ“目标理是只问结果,不计q程”Q从而忽视对q程的监控而导致项目里E碑不能按期辑ֈ。大? 数Y件企业的从业人员属于知识工作者,他们Ҏ(gu)权的要求较强烈,q方面的误区更易发生。第二,寚wE碑控制不严。因为大部分里程毕竟只是一些项目的中间 l果Q在目q程中h们易于放村֯里程变更的控制Q易于出现里E碑大多按期完成而项目却难以按期完成的现象。项目活动彼此是有关联的Q一个里E碑的gq? 会导致连锁反应,甚至可能D目工期的失控。第三,里程的讄仅仅由项目组Ҏ(gu)目本n的特点而定Q忽视了与利益相兌的沟通ƈ得到他们的承诺?/p>
三、基于专业分工的目资源动态调?/strong>
在Y仉目失败的原因中,目l织和h员的问题占到40%以上。因此,寚w目资源的有效l织和调度是十分重要的。对于Y件企业来_最重要的资源莫q于人力资源Q要在项目中充分l织和调度h力资源,需要做好以下两点:bbs.mypm.net
1. 实现人力资源?#8220;分类分”理
׃没有对h力资源做C业分工基上的动态调度,大量企业的h力成本难以降低,目l织q行的效果也难以保证。由于Y件行业竞争的加剧Q降? 目成本成了当务之急,而降低项目所占用的h力资源成本更是重中之重。目前,许多软g企业寚w目h力资源的使用可以?#8220;5个hq?个h的活Q拿5个h? ?#8221;来概括。要x变这一点,做到“3个hq?个h的活Q拿4个h的钱”q种理想状态,有效的办法是实现人力资源?#8220;分类分”理。中创Y仉取的“? cdU?#8221;是指企业员工划分ؓ需求分析员、系l分析员、设计h员、编码h员、测试h员和QA{,q界定其不同的等U,能够做到可以量Z同类型、不同层 ơ的人员的小时h(hun)根{这Uh(hun)格是制定目人力资源预算和成本控制的基础。目前,很多企业“复合型h?#8221;Q这Ҏ(gu)产生一个误区。在许多软g企业的项? 中,有相当多的h既做设计又做~码q做试Q这不仅佉K目的q行效率低、出错率高,也ə目的h力成本提高、h员还不满意。合理的方式是在专业分工?#8220;? cdU?#8221;的基上,通过有效的项目团队组l机制将各类人员集成h?/p>
2.实现人力资源的动态调?/p>
众所周知Q有多种目的组l方式。只有既能聚集于目目标的实玎ͼ又能充分、有效调度企业资源的目l织方式才是合理的。项目组l是一U(f)时? 的、动态的l织Q由于它不应该有冗余人员Q因此,资源调度的有效性基于资源调度的动态性,理想的状态是“需要的时候,需要的?不需要的时候,不需? 的h能走”。企业能做到q一点,必须要有两个条gQh员已l?#8220;分类分”Q以及企业的各职能部门成?#8220;资源?#8221;。实践表明,“分类分”和动态调度将能 软g企业在项目实施过E中提高效率、降低h力资源的l构性成本和提高员工的整体满意度。www.mypm.net
四、基于可视化工具的项目监?/strong>
目理的指导思想在于不仅x目的成果,q要x目的过E。调查表明,?5%的Y件企业处于开发流E的混ؕ状态,过50%的Y件企? 需要改q其配置理Q大U有60%的Y件企业遭受着不同E度的质量保障体pȝ困扰。对目q程控制的忽视,导致项目范围的蔓g{项目风险的增加。要做好 寚w目过E的有效监控Q需要做好以下两点:目理者联盟文?/p>
1.目q程的监控要做到可视化blog.mypm.net
目理是一U典型的pȝ理Q也是一U典型的变化理。项目过E控制的目标在于寚w目成?包括中间成果)的可预见、项目资源的可调度、项? 问题的可q溯、项目组l效的可评h(hun){几个方面。在一个Y仉目中Q有成百上千的相互关联的zdQ一个活动在工期、资源和预算{方面的变化对整个目产生 q锁反应。项目管理的定律之一?#8220;鬼藏在l节?#8221;Q项目经理和高层理人员必须在对目各种zd的变动全面了解的基础上,才能定工作的焦炏V同P? 于项目组成员存在不同的分工,要他们都能够明了各自的工作寚w目的目标起到什么作用和影响Q不能仅靠鼓׃们提高对目的整体责LQ也不能仅靠评h(hun)? 制来驱动他们共同承担目的责任,q必M他们能够直观地看C们的工作与项目目标之间的动态关pR即便是一个经验丰富的目团队Q如果不能完全理解项? 的每一个组成部分,不能形象、直观地了解目的各部分之间的关联关p,也容易犯“一叉目,不见泰山”的错误。只有将目的运行做到可视化才能够帮助他? 解决q些问题?/p>
2.要Ş成企业范围的数字经pȝ目理者联盟文?/p>
要做到项目过E控制的可视化,必须借助于项目管理的工具。有很多目理的方法和工具Q如WBS、网l图、甘特图{方法以及Microsoft Project{工h助于可视化。然而,q些Ҏ(gu)和工具大多ؓ单个目服务的,要在整个企业范围内做到这一点,需要开发专门的可视化项目管理数据^台。bbs.mypm.net
五、着g提高企业目理整体能力的知识管?/strong>
与国际先q的软g企业相比Q我国Y件企业普遍不重视对知识的理Q企业项目的成功度过多地依赖于项目经理,目理的水准是目l理的水准,? 不是企业的水准。Y件企业属于知识型企业Q其无Ş资能够占到总资产的70%以上Q管理无形资产的能力成Y件企业的重要竞争力。企业的无Ş资包括? 大部分:一部分是企业Ş象,另一部分是企业能力。Y件企业Ş象的树立靠的是成功的案例(目)Q而企业能力包括属于企业的知识和属于员工的才干两方面。对 于企业能力的理是要可能将员工的才q{化ؓ企业的知识,q提高这U知识水q뀂只有这h能提高Y件企业的目理成熟度。要理好企业的目理整体 能力需要做好以下两点:
1.建立和管理好目事g库{自项目管理者联?/p>
׃信息技术的飞速发展,能否按期完工成了判断软g目是否成功的极为重要的指标。控刉目工期有很多Ҏ(gu)Q其中最常用的是关键路线? (CPM)。然而,军_软g目工期能否q期完成的因素大多是那些事g(issue)Q即需要被解决的障性问题。事件常怸是项目组成员能够独自解决 的,它们需要依靠整个企业的力量Q甚至需要利用外部的专业资源。ؓ了做到这一点,中创软g着力于软g目事g库的。项目尽量有其独Ҏ(gu),但借鉴一个企 业内部,从同cd的项目之间的l验教训提炼出来的知识是十分有h(hun)值的。中创Y件事件库理的主要职能是把公叔R目管理中的各U成功、失败的案例攑֜数字? l系l中Q相关h员遇到问题时Q可随时在数字神l系l根?#8220;关键?#8221;q行查询Q参考以前类似问题是如何处理Q从而提供帮助。training.mypm.net
2.做好目收尾的经验ȝ
与项目启动前的项目策划一P目的正式收是十分重要的。收作用不仅寚w目的利益相关者有一个正式的交代Q还有一个重要职能是寚w目整? q程中的l验教训予以提炼QŞ成企业的知识财富。知识管理的目的是ؓ了管理变化,没有_的知识,企业难以知道该如何应对目中的变化。知识管理包括知 识的挖掘、整理和使用{内宏V把知识挖掘出来Q是一仉常艰苦的工g。企业的知识往往是隐含、散落在员工体中,有时不是大家不想表达出来Q而是可能q没 有意识到。因此,需要将员工的隐性知识{化ؓ公司的显性知识。ؓ了管理好知识Q徏立项目管理办公室Q专门负责对目理相关文档q行分类、整理和l计Q负 责适合本企业的目理工具、模板和Ҏ(gu)的开发、研I及对员工运用的培训?/p>
要提高Y件企业项目管理的成熟度,企业需要付苦的努力Q在某种E度上要重塑企业文化。项目管理机制的推行必须从高层开始就坚定信念、全力以
赴、勇于实践,q必要有够的耐心才能获得理想的成效。项目管理是一个实践课题,有时候虽然说h非常单,但真正实施v来有大量具体问题要做。如果企
业不愿意真正地去投入、去认真地做的话Q那么期望得到理想的目理成果只能是一句空话,是不可能成功的。{自项目管理者联?/p>
(zhn)剧的主要环节在“目控制”
从项目选择来看Q掩护大部队转移时派出兵力阻L攻,q是正确的?
问题出在计划上。作战时间和资源? 配值得商榷Q区?7人的队伍Q能否挡住具有优势兵力的敌h多次q攻Q能否拒敌至?时Q在计划Ӟ恐怕连团长心里都打鼓。在选择目l理子地Ӟ 在hq个资源上也是有问题的。如果作长的谷子地指挥素质高明的话,׃应在开头那D战中Q?个尖兵遭伏击Q就呼啦啦一片从正面冲上去,而是要正面Y 攻,侧翼l过。谷子地在后面战斗中Qƈ没有充分利用地利{因素进行智取y打,而是一x命。从q点看,团长挑选谷子地的连队实施阻击,实则是个冒险Q打? 仗光靠勇字还不行?
执行不折不扣。虽然敌众我寡,困难重重Q但战士们英勇作战,佉K击项目得C折不扣的执行。就执行质量而言Q虽然坚?2时之久Q可付出了全q阵亡的代h(hun)?
本项目的(zhn)剧正是凝结?#8220;控制”q个环节。项目控制的要素主要有范围、质量、时间、成本。团长策划这个项目时Q基本上是不惜时间、不惜h力的Q? Dq个目的控制环节无法实施。一个鲁莽的团长Q下了一个鲁莽的命o。由于通讯无法联络的缘故,作ؓ目l理的谷子地与阻击项目严重脱节,无法真正行 目l理的权力。虽然有战士企图假装听到集结P试图挽救最后几名战士的生命Q但l究不是目l理Q无法行使够的权力ȝ理和协调目工作?
Ҏ(gu)战争常识Q将军带兵外出打仗,有时难以与总部保持信息畅通,怎么办呢Q一般就会再l出一个预备方案,指示军随机应变。这样项?a target="_blank">风险׃大大降低Q至不会全军覆没?
l果令h遗憾。项目管理一般应辑ֈq样几个斚w的满意,l织L(fng)、客h意、相兛_益者满意、成员愉快、项目经理满意。就谷子地这个项目来看, l织L(fng)是部分达C。但是,其他几方面,没有一斚w满意。我们看到这个项目很隑֯烈士本n以及其家属交待,d战下来居然只有连长一个hzM来,作ؓ? 目执行负责hQ项目失败了Q资源耗尽了,应该付相应责仅R作为项目经理的谷子圎ͼ׃偶然的原因活下来Q却怀着l生的愧疚。甚至那个最大的责Q人,团长? 泽水Q最后也是由于同L(fng)原因Q做了同样失败的目Q在另一场阻L中,?sh)台被打坏,接不CU的撤退命oQ拼上了更多的战士的生命Q自׃牺牲在战? 中?
《集l号》的(zhn)剧恰恰是企业在目q展中经帔R到的困惑?#8220;1345”分析模型是否能够解决企业的这些难题?
一炚w莽多一炚w目管?
目_企业_目衎ͼ企业衰。一个企业发展离不开目。在企业理中,我们是有条gd习项目管理知识的Q但实施目Ӟ很多时候的实际情况是Q决{的时候很鲁莽Q计划的时候不周到Q执行的时候不坚决Q控制的时候不得力Q结束的时候当然就无法得到各个斚w的满意?
我们可以用到目理?#8220;1345”分析模型Q一个目标、三个管理、四个控制、五个满意)来解决上q问题。项目管理的内容很多Q归Uv来,得出q样一个简单可操作的模型:
一个目标:作ؓ目Q它的主要目标必L正确、清晰、可行的。企业家不能像刘泽水那样Q简单地下个无边界的命oQ而不能不能实行?
三个理Q资源管理?a target="_blank">沟?/a>? 理、风险管理。资源管理就是对可操作的资源q行适当地调配。沟通管理是指对目的实施和反馈环节q行理。风险管理是寚w低项目风险、最大程度达到项目目 标实现的理。不仅要lQ务,q要l资源。其实,我们要向诸葛亮学习,士出征Q情冉|变怎么办,联系不上怎么办?事先都要估计刎ͼl个“锦囊”Q到了关 键时L开Q也是目中的应急方案?
四个控制Q项目范围、项目时间、项目质量、项目成本。如何来评h(hun)一个好目Q四个字“多、快、好、省”。项目完成的工作多;有效旉内的工作业W大;目质量高;成本低,用最低的成本完成d。控制好q四个因素,是项目成功完成的关键?
五个满意Q组l获益、客h意、相兛_益者满意、成员愉快、项目经理满意?
战场上《集l号》已l画上了句号Q但商场上的《集l号》还在不断上演,如果我们的领D多一些智慧,一些鲁莽,学一炚w目管理,哪怕只?0分钟Q了解一下上面这个模型,在我们事业的发展中,怿《集l号》这L(fng)(zhn)剧一定会大ؓ减少Q?
Scrum 开发流E通常?30
?或者更短的一D|?Z个阶D,由客h供新产品的需求规格开始,开发团队与客户于每一个阶D开始时挑选该完成的规格部分,开发团队必d力于
30 天后交付成果Q团队每天用 15 分钟开会检查每个成员的q度与计划,了解所遭遇的困隑ƈ设法排除?br />
?Scrum较传l开发模型的优点
Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的囄使用传统的Y件开发模?瀑布模型、螺旋模型或q代模型)。随着pȝ因素Q内部和外部因素Q的复杂度增加,目成功的可能性就q速降低?br />
下图是Scrum模型和传l模型的Ҏ(gu)Q?br />
?Scrum模型
一) 有关Scrum的几个名?br />
backlog: 可以预知的所有Q务, 包括功能性的和非功能性的所有Q务?br />
sprint:一ơ跌代开发的旉周期Q一般最多以30天ؓ一个周?在这D|间内Q开发团队需要完成一个制定的backlog,q且最l成果是一个增量的Q可以交付的产品?br />
sprint backlog:一个sprint周期内所需要完成的d?br />
scrumMaster: 负责监督整个Scrumq程Q修订计划的一个团队成员?br />
time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box?5分钟?br />
sprint
planning meeting:
在启动每个sprint前召开。一般ؓ一天时_8时Q。该会议需要制定的d是:产品Owner和团队成员将backlog分解成小的功能模?
军_在即进行的sprint里需要完成多小功能模块Q确定好q个Product
Backlog的Q务优先。另外,该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的q些模块的工作量以小时计?br />
Daily Scrum meetingQ开发团队成员召开Q一般ؓ15分钟。每个开发成员需要向ScrumMaster汇报三个目Q今天完成了什么? 是否遇到了障? 卛_要做什么?通过该会议,团队成员可以怺了解目q度?br />
Sprint review meetingQ在每个Sprintl束后,q个Team这个Sprint的工作成果演C给Product Owner和其他相关的人员。一般该会议为4时?/p>
Sprint retrospective meetingQ对刚结束的Sprintq行ȝ。会议的参与人员为团队开发的内部人员。一般该会议为3时?/p>
二)实施Scrum的过E简单介l?br />
1) 整个品的backlog分解成Sprint Backlog,q个Sprint Backlog是按照目前的人力物力条g可以完成的?br />
2) 召开sprint planning meetingQ划分,定q个Sprint内需要完成的dQ标注Q务的优先Uƈ分配l每个成员。注意这里的d是以时计算的,q不是按人天计算?br />
3) q入sprint开发周期,在这个周期内Q每天需要召开Daily Scrum meeting?br />
4) 整个sprint周期l束Q召开Sprint review meetingQ将成果演示lProduct Owner.
5) 团队成员最后召开Sprint retrospective meetingQȝ问题和经验?br />
6) q样周而复始,按照同样的步骤进行下一ơSprint.
整个q程如下图所C:
The diagrams in this article are all from web site: http://www.controlchaos.com. Thanks very much!
参考:
http://www.controlchaos.com/about/
http://www.microsoft.com/Taiwan/msdn/columns/200311softdev.htm
另外一:
Scrum是一U灵zȝ软g理q程Q它可以帮助你驾驭P代,递增的Y件开发过E。这个轻量的q程可以作ؓ包装器,也就是说你可以把Scrum与其它灵zȝq程框架l合hQ比如说RUP?
RUPQRational Unified ProcessQRational l一q程Q,是一U被q泛使用的Y件过E框架。它可以很好地迎合你的Y件开发过E的需要,q可以容U_他技术。Scrum是一pd有趣的,用来包装灉|软g目的项目管理模式?br />
Scrum
提供了一U经验方法,它得团队成员能够独立地Q集中地在创造性的环境下工作。它发现了Y件工E的C会意义。这一q程是迅速,有适应性,自组l的Q它代表
了从序开发过E以来的重大变化。Scrum认ؓ软g的开发不应用和一般制造业相同的方法,也就是不应采用一U反复的模式。这U重复得输入和输出参数
更加Ҏ(gu)预测和描qͼ但这q不是当今Y件工E的有益目标。现代Y件工E的主要挑战包括上市旉Q投资回报,以及影响֮的需要等。RUP和其他敏捯Y件工
E过E能够很好地q接q些挑战?br />
Scrum区别于其他开发过E之处是什么?最显而易见的不同是每天的短会,通常在每天的同一旉在同一个房间内举行。这个会议也叫ScrumQ在会议中每个团队成员仅׃下三点发aQ?/p>
自上ơScrum会议后你做了什么?
从现在到下次Scrum会议的时间里你准备做什么?
你在工作中遇C哪些困难Q?
Scrum团队的组?/strong>
?
于一个Scrum团队最多由7人组成,会议应当不超q?5分钟。Scrum理?L会议Qƈ且对整个目的成败负责。他們每个成员的发aq设法解?
会议中提到的各种障碍。Scrum理者在会上寚w提出即时的解决Ҏ(gu)或指|使团队不断向着目标前进。Scrum会议不同于项目会议,对团队来_?
起到了快速简报的作用。如果问题得不到解决Q团队成员应向Scrum理者或大项目成员提疑?
只有团队成员可以在Scrum会议上发aQ但是允许有旁听者。对于h数多?人的目团队QScrum与其扩大团队规模不如团队分l。分l可 依据功能Q结构主体,或者应用,包括子应用等q行。分l后各个子团队就可以q行工作了,而且Scrum理者可以通过Scrum会议对各个子团队的工作进 行同步。Scrum甚至可以兼顾在其他地方工作的团队成员?
Scrum团队不止是一个程序员队伍Q它由各U背景下的不同角色组合而成Q包括商业分析者,设计师,E序员和试者等{。更多时候,成员可以w兼多职Q正的l合军_了团队的能力和效率?br />
目规划
Scrum的P代过E被UCؓ“疾跑”Q时间ؓ30天。在RUP中,q代q程通常??周之_每次“疾跑”都以获得可执行可试的代码ؓl束?/p>
产品拥有者持有品订单,他控制ƈ区分功能的开发次序,但是工作量的评估是由Scrum团队来完成的。品风险的所有承担者,包括Scrum团队和品所有者,共同视订单,然后Ҏ(gu)优先U次序决定先开发哪一功能。除M先QRUP的P代规划过E也是基于风险的?/p>
现在团队定义?#8220;疾跑”目标已经成ؓ了进展控制的指导?#8220;疾跑”q程一旦开始,团队全部与外界的交流都必ȝ由Scrum理者进行。Scrum理者务必保证团队能够专心于既定目标而不受外界干扰?/p>
Scrum团队持有自己?#8220;疾跑”订单Q上面记录了更多关于待实现目标的具体d的细节。在团队?#8220;疾跑”的作用有更多了解以后Q团队成员就可以调整原始的品评伎ͼq将“疾跑”q程中获得的信息加入C品订单中。这些做法对Scrumq度回溯都是有益的?/p>
Scrum团队由每天的Scrum会议Q每月的“疾跑”计划?#8220;疾跑”审查会议紧密相连Q鉴于此Q整个组l必然存在一U纵向的透明度。这׃得组l? 上的问题和挑战清晰明显。由于团队成员都亲自观察整个目Q交也变得简短,q速和有效。团队是自组l的Q着g“疾跑”的目标,q样最大限度发挥了 每一个团队成员的作用。Scrum理者充当一个问题和交流?#8220;据交换所”Q而不是一个控制整个团队的老板?/p>
“疾跑”审查会议持箋半天。在会上Q团队向目的风险承担者展C完成的功能模块。团队按照既定的“疾跑”目标来演C完成的内容?/p>
订单Q?#8220;疾跑”计划和回,理承诺Q每日Scrum会议Q进度回溯,以及其他Scrum技术都是基于主要用于Y仉目管理的q程模式的。这些模式在q去的大项目和不同商业领域中都获得了成功?br />