下载Html格式文件：点击到达下载页

下面做了一张图用以表述这个过程，以及组件库在创建设计一致性方面的过程：

项目失败或亏损的前三大原因为：

1. 缺乏使用者的参与
2. 需求或规格不完整
3. 需求或规格变更


传统需求管理工具不合时宜

在过去，需求管理(Requirement Management)工具或工作表中所储存的数千个需求与上百页的文件早已不合时宜，现在，这些需求更是不适用于目前快速发展的环境。

项目的关系人(Stakeholder) / 需求单位或使用者通常都不是专业人员，一般的需求整理跟定义，光依赖文字叙述以及简易的画面，往往造成对于规格认知的落差，到最后就演变成灾难，无法收拾。

Prototype可以有效定义需求

解决对于需求以及规格认知落差的方式，最好采用原型设计方法(Prototyping Methodology)。制作Prototype是个有效简化文件制作、吸引使用者参与、早期辨认需求遗漏，与将外在需求降到最低的方法。

以项目关系人(stakeholder)与使用者看了有感觉的交互性画面，直接感受设计结果，来取代大量的文字叙述，如此更能抓住使用者的意见回馈，形成共识。

只是传统制作prototype的方法不但昂贵而且费时，让程序设计师很难在开发过程中搭配合作。商务专家(Business Professional)也不断的在使用简报与图标的工具建立Prototype和持续对制作过程与结果不满意之间挣扎着。

Axure RP提供原型设计的效率，进而创造项目效益

为了要能有效且快速的建立Prototype，Axure RP 结合了广受欢迎的简报与图标工具中简易操作的特性和其它必要的功能，这样一来，商务专家就可以在不需要大量文件制作下快速的建立Prototype，而项目成员与项目关系人也可以在不中断开发的情况下轻松完成Prototype。

Axure RP很容易上手且绝对值回票价，所以当项目成员在第一个项目中使用这个工具时就会发现他们的投资已经得到了显著的回报，不只省下了在收集与沟通需求上的时 间与成本，同时也降低了改善需求时的重工，透过Prototype 可以省下惊人的成本，以及预防潜在性的商业损失、机会损失与项目关系人信心丧失等的灾难成本。

言归正传，继续我们的「函授」教学…还记得我前面两封信提到我多年功力的菁华吗？第一个重点是建立共识，第二个重点是配置资源，今天我们要来谈谈第三个重点。

项目成功的第三个关键，以前我只放在心里面，不讲出来的。不讲出来的原因是这个讲法听起来一点也不专业，甚至不入流，那个关键叫做「运气」，不过现在我认为第三个关键可以修正为「双方团队专业程度的乘积」。

为什么「运气」竟然是项目成功的第三关键呢？我们都知道项目时程，范畴，需求都是委托方赋予的，所以如果运气好，遇到好客户，项目就有较高的成功机率。运气好的项目经理，会遇到好的委托方，明理的客户，有合理的时程要求与项目范畴，找得到强力支持项目的高阶主管，预算够用甚至还可以到饭店来个期末庆功。

回想我过去的经验，同时遇到这些极佳条件的机率非常的低，如果遇到了，表示手气好到买到乐透头彩了。只是项目本身都成立在这种理想状况，项目经理就不需要太厉害了，当然也看不出项目经理的贡献。这就是我上一封信提醒你的，没有好牌也要打出好的牌局。

照这个道理来说，项目的命运岂不是永远掌握在客户手中了吗？那项目经理不就得背负着这个原罪，那也太倒霉了，谁还来当项目经理呢？因此把项目成功与否推给「运气」这是很不洽当的想法。就好像把项目能否成功的责任通通推给客户一样，这种讲法是完全说不过去，毕竟客户会将项目委托给你，有一种可能性就是他本身的专业上不足，需要你的协助，哪里可以借口客户水平不足而导致项目失败呢！

不过最近几年，我发现这第三关键「运气」应该修正为「双方团队专业程度的乘积」。这个概念把被动的，运气的，宿命的消极工作观，调整成比较主动的，客观的，积极的工作态度。你听听看有没有道理？

经过我的观察，实际上项目的最后成果，往往都是委托端的努力加上执行端项目团队的努力一起合力创造出来的。假设满分是100%，如果客户的水平达到80%，而项目团队也有80%，那么项目的成功指数就达到80% X 80% = 64%，大于60%勉强及格。

如果你的项目团队的专业指数达到100%，但是遇到一个30%的客户，你想项目会成功吗? 成功指数就只有100% x 30% = 30%，不及格。反之亦然，一个专业水平有100%程度的客户，若遇到只有20%水平的项目团队，大概也就祇有等着遭受打击的份了。

因此在专业水平上能够门当户对的项目团队与客户，才有促成项目成功的底子。重点在于双方的专业必须是互相弥补的：能够提升执行端项目团队水平的客户，是好客户；相对的，能够培养客户素质的项目团队，才是一个好的项目团队。

所谓的双方的专业必须互相弥补，在网站建置类型的项目上，尤其容易看得出来这一点的重要性。委托端－也就是客户，必须很清楚自己的需求，以及所在产业的相关知识（Domain Knowledge）；执行端－也就是你所带领的项目团队，则必须拥有良好的网站规划建置各项专业。

当客户对自己的需求掌握90%，合作初期也能将他们的产业知识传递（或传授）给你的项目团队，再加上你所带领一群专业水平达90%的好手，我们放到公式里头就可以得到90% x 90% = 81%的好成绩。我曾经遇到一个客户，他把产品网站委外给小设计工作室，结果工作室倒了，人跑不见了，他的网站也跟着消失找不回来，因为他连备份的观念都没有。这个情境大概是50% x 40% = 20%吧！下场也够凄惨的。

换个积极的角度来检视第三关键「双方团队专业程度的乘积」。你要创造好的项目成果，在项目一开始就必须考虑到，如何为第三关键的两个变量Ａ，Ｂ创造出好的水平。

变量Ａ是「客户水平」，如果有机会一开始就筛选出好的客户，那很不错，假设没这种条件，就得跟客户「博」感情，借着多次的交互与接触，来教育客户，让客户素质成长。当客户体认到，你来做项目不只是做事情而已，他本身也可以获得很多的成长，客户会越来越信任你，依赖你，以后的事情就会越来越容易做。

变量B是「团队水平」。一样的道理，项目团队的素质，就是项目质量的基础。如果你没有办法筛选，组织出好的项目团队，那么就得借着你手上的资源，陆陆续续将自己的团队素质加以提升，比如花更多的时间在学习，聘请专业顾问，编列课程培训预算等。经历这个过程，你的团队成员也认知到跟着你做项目，不只是做事，自己的专业也会提升，那么团队向心力就会越来越强，大家也会愿意跟随着你，以后的项目就会更容易成功了。

所以，下一次不用太介意客户有多差劲，或者工程师/设计师有多不配合了，这些都是你在项目管理工作上必须经历的，而且这种情况发生时，你更应该要先做自我检讨，与其抱怨，不如更用心去提升各方水平，当你付出更多，很快的，你就会获得更多！不相信吗？试试看便知道！

对新手PM来说，配给什么样的资源往往是别人做的主，这是比较无奈的一点。但是既然公司能够赋予你担任PM的要职，多多少少都相信你具备应用资源/管理资源的能力，换句话说，你自己得评估资源是否足够，万一领了军令上了前线，回头寻求后方火力支持时，才发现后头是漫漫荒野没有后援，恐怕你就准备阵亡了。

「资源」包括什么? 包含为了达成项目任务所需要的「有形资源」，及「无形资源」。

预算是资源，时间是资源，人手是资源，顾问是资源，下包厂商也是资源，为了达成项目所需要的各种实体对象，软件/硬件/图库/音乐版权，项目的大老板的某种授权或背书，皇上给的免死金牌/尚方宝剑等等都属于项目资源。

理论上，拥有「无限」资源的项目，有最大的成功机率。不过这个描述已经违背的「项目 (Project)」的基本定义 (项目本身就有时间限制，否则不叫做项目)。参考wikipedia对Project的定义 英文 中文。

正由于各种资源都有其限制，因此将资源最佳化，达成最佳的项目产出与质量，就是项目之所以得被赋予「管理」概念的由来。

反之，一个项目没有足够的资源，天生就埋下了失败的隐忧，所以，项目的关键成功因素之一就是先取得资源，或者讲白一点，取得足够的资源，而资源当然是越多越好。

但站在项目经理的顶头上司或者项目委托人的立场，通常这两位大人是提供资源的重要人物，他们对于资源的取得或分配，考虑的角度是「资源最佳化」，说穿了，就是「足以达到项目产出基本质量的最低资源」。这不能怪他们，因为从你的角度你也许只看管一个项目，从他们的角度得看管十个或数十个项目，当然得顾及各项目的资源配置。

曾经有很长一段时期，取得项目资源一直是我心目中项目成功的第一重要因素。在踏入这个行业的初期，曾受到一位软件业界前辈的指点，我也跟你一样想寻求项目管理专家的协助，前辈给我一个很重要的观念，我一直记在心里头，他说「项目要成功，首先你要有自己的团队」。换句话说，没有项目团队的项目经理，就像是没有兵的将领，无法战斗。

拥有项目团队(Team)最快的方式，你知道是什么方式吗? 很简单，只要雇用一个英文名字叫做Tim 的人，就可以跟客户宣称我们有 Team了。这是一位好友在非常无奈的情境下，想出来的冷笑话，当时他就在没有Team的情况下苦中作乐，才想得出这种冷笑话。

为了把项目资源做评估与规划，很多项目管理的理论都有谈到。首先项目目标与目的的定义，范畴的界定，规格的界定，人力/预算/时间的估计，将这些林林总总的项目作好完善的安排，形成项目计划，这些细节我们以后再来讨论。

最后，帮你做个心理建设，没有一副好牌却仍能打出一场好牌局的PM，才是真正的高手。如果每个项目都能够赋予项目经理够多好用的筹码，每副都是好牌，坦白说，项目管理就没有什么价值了，我们今天也不用花心思做讨论了。不管你手上拿到什么牌，想办法打出属于你的一场好牌局，这是PM要最用心的地方。

如果你想了解到我过去做网站项目管理心得，那么我可以在这里告诉你，接下来的这个重点是我多年功力的菁华。

评估项目经理能力高低，就看项目管的好不好。影响项目管的好与不好的因素很多，若全面分析所有因素并且逐一探讨跟检视，恐怕讲三天三夜也讲不完。

今天我先讲第一个成功关键因素，这个因素是我认为最难最难的一件事情，如果能够把这件事情做好，即便是项目结果不如预期，但大家可能都不会怪罪到项目经理头上。

第一个关键因素是「建立共识」。

什么叫做共识? 简单说，就是全体人员有相近的看法或者支持相同的决议。

那么哪些人要有共识呢?

首先，你的内部团队要有共识，包括上头的老板，甚至老板的老板，你的技术团队，你的设计团队，你的企画研究幕僚，甚至你的下包厂商，

再加上客户端的共识 (这里所指的客户端，也包含项目委托单位是自己企业机构内的其它部门)，客户的项目小组，客户窗口的老板，或客户窗口的老板的老板。

最后则是你的项目团队与客户端的项目相关人之间要有相同的共识。

项目管理理论所谈到的各种管理作为，有许多都是为了促成共识的措施，包括定义项目的产出规格与质量，项目工作的分工与接力，合约/计划书/会议纪录，沟通技巧与方式 (各种形式的沟通, 会议, 电话, email, 文件…)。

管理项目的共识，根本上必须是项目经理的习惯，连想都不用想，随时随地要意识到让大家形成共识。在项目过程中的每一个动作跟步骤，都要提醒自己是否已经形成共识? 如果还没有共识, 会造成什么后果? 要透过什么样的决策机制来定义共识?

总之，项目的任何一个环节疏忽了建立共识，就有可能埋下后面造成项目范畴或规格变动的隐忧。形成共识，被我视为项目经理的第一要务，只要能够做好共识的塑造与形成，就是大功一件。

由于共识的建立牵涉到人的认知与沟通，偏偏只要跟人有关的事情，就是最难搞定的。只有两种情况，共识相当于等于项目经理的个人意识，此时几乎没有沟通成本或沟通问题。

第一种情况，项目经理自己是委托端及执行端，而且是自己独立执行的项目。这种情况也许很像是有些程序设计师自己设计一些软件或网站，自己玩一玩。

第二种情况，是所有人都听项目经理的。什么情况会这样? 当项目经理的专业够水平，足以服众，此时所谓的共识几乎就是项目经理的个人意见，而这种情况不多见。但假使项目经理的专业水平能够提高，就更有机会快速的凝聚共识。

关于共识的建立，我们会再用更多更多的篇幅来讨论，如果你在这部份有什么心得或问题，我们可以随时回头再来检视这个题目。加油了!

你选择了踏上项目管理这条路，这是很棒的方向，可以学到最广泛的经验，非常恭喜你！在这个行业里头，需要很多项目管理人才，尤其是好的项目管理人才，这绝对是值得你努力耕耘的方向。

你问我：”什么样的项目经理才是好的项目经理？”这个问题很好，但是很难简短的回答。以后我会慢慢告诉你，如何当一个称职的项目经理，不过既然你问的这么诚恳，为师的也不能随随便便回答。

我们换个简单一点的讲法好了，好的项目经理应该要像什么？

首先，好的项目经理要像狮子，要具备狮子的自信与领导气质。狮子是万兽之王，能够镇慑其它动物，像狮子一样的项目经理，就是一个具备领导力的项目经理。任何一个稍具规模的项目都必须整合多人跨领域的团队或资源，才能完成任务，如果团队没有好的领导人，再多个厉害角色凑在一起也只能算是乌合之众。而项目经理名为管理项目，实际上却不只管理项目团队而已，而是必须领导项目团队。至于什么是领导，我们改天再说。你呢？其实也不用想太多，就先当自己还是小狮子吧！总有一天会长大的。

好的项目经理要像磁铁，要能够把项目团队及资源牢牢吸住，但这个牢牢吸住却又不是锁螺丝那么难拆解，万一团队成员要更换或者资源安排到另一个更重要的项目，也不能太难处理，像那句有名的广告词＂有点黏又不会太黏＂就对了。我想强调的重点其实是＂凝聚＂的力量，如果项目经理是够强的磁铁，就会将项目团队紧紧拉拢在一起。而且这个拉拢的力量，是有扩散性的，被吸住的团队成员就像具备磁力的铁片一样，会自动吸住他该关注的项目跟任务。

好的项目经理要像大海，要有肚量。这不是件容易的事情，如果你不当项目经理也许就不用太在意，要当项目经理肚量太小，恐怕很快的就会高血压心脏病了。因为项目经理身处项目风暴的核心，上有老板，下有团队，旁边可能是其它项目团队或者部门主管，外面还有客户跟外发厂商，每个人有每个人的意见跟看法，如果肚量不能像大海，海纳百川而阔，大概天天都在跟其它人争辩意见，那就不妙了。

好的项目经理要像水，不管项目过程有多么崎岖难行，你的身段得柔软地去适应并且抚平。这绝对不是简单的本事，遇到凹陷的地方，这是你的项目团队的不足之处，你必须注入你的能量加以抚平。遇到客户要求过多，就好像平地上冒出的土丘，要不把土丘给抹平，要不就放大水来淹没 (仔细想想…这个描述真有点离谱)。能够让项目的表面看起来平平整整的，那是项目经理的上等功夫。当然，水面下的起起伏伏，那就是鸭子滑水了，该不该让其它人知道你的劳累跟贡献，如何让其它人知道，这就得看场合跟状况了。

好的项目经理要像竹子，韧性要够，要不怕风吹雨打。虽然要像大海听别人的意见，要有水一般柔软的身段，但这可不是教你去奉承逢迎，别忘了项目经理要领导团队不是只靠附和他人意见，最基本的还是自己的专业要够，要挺得住，即便是被巨大的范畴 / 无理的时程要求 / 夸张的需求变更所打击，也不能倒，倒了就没有尊严了。当然很多时候项目经理是可以稍微退一步以取得缓冲，便于在缓冲中找到解决方案。总之，不卑不亢就是最好的态度，只要最后能靠自己的实力站起来不被击倒，以后就会获得他人的尊重与认同了。

用这种讲法好像篇幅再多也讲不完，以后想到再叮咛你，希望到时候你别嫌我太啰唆！