本节书摘来自异步社区《嵌入式系统开发之道——菜鸟成长日志与项目经理的私房菜》一书中的第2章，第02-02节，作者 邱毅凌,更多章节内容可以访问云栖社区“异步社区”公众号查看。
02-02项目管理基本概念
PM：“首先感谢大家抽空来上这堂课。项目管理目的在于建立一套知识体系，提供高效完成项目的流程指导。任何性质的工作都可以是一个项目，所以，学习项目管理最重要的还是思想！这门课当然无法在短时间内解说所有项目管理的细节，但今天的教材是基于我多年的项目管理经验，体现个人认为所有项目成员都必须知道的项目管理思想、流程与工具，并适时提示嵌入式系统开发项目应该注意的地方。
这门课的副标题为‘所有参与项目成员都必须知道的项目管理知识’，也就是说，我所设定的目标对象并不仅仅只是项目管理者。如果你被指派加入某个项目，我希望你能认真地从这个简报里学到一些正确的思想，以后就能用更有效率的方式工作，相信对你日后的职业生涯也会有很大的帮助。
首先，我们来看关于项目一些‘不能说的秘密’。
2-2-1 何谓项目
当企业想要培养具备某种技术专长，且可为公司所用的人才时，必须经过长时间、计划性的培训。例如，当公司给你一个之前从未做过的开发任务时，一定会给你时间自我学习，或采用师徒制（找个师父带着你在工作中学习），甚至是直接送你去外部的教育培训中心上相关课程（培训）等。
然而，电子产业的项目经理通常都由技术人员直接晋升，大部分的项目经理在就任之前，多半是位兢兢业业、优秀且精干的工程师！通常直到被升任为负责某项目的项目经理之前，都未受过完整的‘项目管理’培训。
照理说，不胜任的项目经理对项目的‘危害’，远远超过一位工程师的影响，而企业花了这么多的时间与金钱，将工程师培养为技术专家之后，居然是为了指派他去做不熟悉的‘管理’工作？这真的是十分奇怪的现象！正因为大部分的项目经理都是这么产生的，因此，管理不善往往成为大部分项目延误、超支，甚至失败的主要原因。
领导与管理是截然不同的概念，领导或许需要天份，也需要实际的战绩来服人，但管理的技巧与思想绝对是可以学到的，而项目管理更是一门成熟且已有无数实践实例的知识体系，项目的思想也已广为电子产品开发行业所接受，无论你将来是要开发手机、网络设备、玩具、家电等，你都曾是某项嵌入式系统开发项目中的成员。
现在，你还会觉得项目管理的思想与工具对你来说不重要吗？
大部分的人身处于项目之中，却不见得真的了解‘项目’到底是什么。以下我们就来了解项目的定义。
项目的特性如同幻灯片所述，有明确的开始与结束时间，且每个项目都是独一无二的。例如：工厂生产线上完成每项成品组装的过程并不算是项目，但设计组装流程，并尽可能精简步骤的过程，则可以使用项目的思想来执行。
在嵌入式系统项目中，软件开发所占比重很大，相对于其他种类的项目，软件项目有其特殊性。举例来说，建筑业有很明确的工序与材料选择规范，只要按照规范来做，项目质量就得以确保，则失败的可能较小。但软件开发只有软件工程这套开发‘原则’，且软件质量水平很难加以量化，使得软件项目管理难度大增。
嵌入式系统开发还牵涉到硬件及诸多限制，就算同所有软件项目的种类相比，说嵌入式系统是最复杂的都不为过。稍后我们会提到软件估价与复杂度评估，在所有评估方法中，都把嵌入式系统的复杂度设为最高。简而言之，嵌入式系统里一行程序的‘价格’，往往高于其他种类的软件项目。
在座各位都是从事嵌入式系统开发的，对嵌入式系统项目的特性，以及开发时可能会遇到的限制等，应该都有深刻的体会，在此我就不再赘述了。
项目管理试图规范‘任何符合项目定义工作’的执行流程，以增加项目成功的机率，而软件开发也是一种项目，自然可以运用项目管理的知识加以管理，项目管理与软件工程是两套独立的知识体系，我们在开发软件时也必须按照软件工程的精神来执行，但实际上，两者的规范是否有所冲突呢？
答案是否定的。两者的基本思想其实是完全相同，都是将项目的执行流程定义为‘规划→执行→控制’的循环，只是软件工程会针对软件开发的特性，而发展出特有的思想与工具。
美国PMI（Project Management Institute，项目管理协会）收集来自世界许多项目运行的实例，并分析与归纳出一套目前广为接受的项目管理知识体系。我们现在的课程内容基本上都是以这套知识体系为出发点。但刚刚说过，每件项目都有其独特性，不可能有完美的流程可完全套用在所有的项目上，所以在讲解项目管理的知识体系时，首重思想与应用，而非其中的条文。
一般人对嵌入式系统项目有两个最大的误解：
- 项目经理必须是位软硬件全才，只会出张嘴的项目经理无法带领项目成功。嵌入式系统项目牵涉的领域非常广泛，项目经理居中协调、review都已经没时间了，怎么还会有空去写code？如果你项目中的PM每天埋头写code，他其实是想要掩饰自己在管理与沟通上的无力感。项目中的每位成员都有其重要使命，有的人是写程序、有的人是硬件设计，而项目经理的任务之一就是按照计划进行沟通协调，每个人都应该先把自己分内的工作做好，才能去帮助其他人，这个道理我想大家应该都知道吧！话说回来，身为嵌入式系统的项目经理，想要做好沟通协调，自然不能什么技术都不懂，否则，很容易就会被项目成员所蒙蔽。
- 只要经过不断的测试，就能够保证产品的质量。这已经是上世纪中叶的旧观念了，认为只要先把东西做出来，然后不断测试与debug，只要测试人员够精干，迟早可以把所有问题都找出来并解决。但现代产品的复杂度远比当时高出不知多少，且软件复杂度更是指数级的倍增，只靠事后测试是无法保证产品质量的。
现代的思想是：质量是规划出来的。特别是软件系统，若项目前期的设计工作做得扎实，执行时期不断监控，自然测试时期的bug就会较少，且修改bug的投入也较小！
2-2-2 何谓项目经理
在了解项目的定义之后，接下来，我将和各位介绍项目经理的职责。
目前的企业普遍采用矩阵型组织，在座的工程师们，你们在组织中会有一位直属老板（Functional Manager）。例如：软件部门课长、硬件部门经理等，当工程师被指派参与某个项目时，在项目运行期间，项目经理则是你另一位老板。在组织中，项目经理的角色其实有点尴尬，他并非项目成员的直属上司，但却要带领所有项目成员完成项目，而这正是幻灯片中‘责任大于权力’的意思。
因此，项目经理必须具备极佳的沟通技巧，让工程师的直属上司愿意支持此项目，使得项目成员可以更专注在此项目上。
项目和一般研发团队的运行有着本质上的差异，前者是要在限期内完成指定目标，而后者则是根据既定的长期发展计划前进。因此，主事者需要的管理风格与人格特质也不尽相同。一般而言，项目运行的节奏较快，项目经理必须强迫自己，从老板到客户的诸多信息中去挖掘并定义出项目的目标，在项目执行阶段，必须能心平气和应付所有突发事件的袭击。
项目在不同阶段会有不同的特性，因此，项目经理在项目的不同阶段，必须适时做角色变换。
- 项目初期：目标尚未确定，项目团队也刚组成，成员彼此间默契不足。此时，项目经理必须主动明快的制订决策，并积极地指派工作。越是混沌不明的状况，领导者越是需要花更多的精力带领所有人找出正确的方向。
- 项目目标已确认：紧接着就是拟定计划。项目计划为项目的蓝图，对项目成败影响甚大，由于项目经理是最了解项目目标的人，因此，项目经理一定要全程参与计划拟定，必要时指引方向并协调纷争。
- 项目计划已定案：项目经理的主要工作转变为监督项目执行，随时检验查看实际的项目进度是否与计划有落差，执行风险管控与变更管理，并主动提供工程人员需要的协助与资源。
- 项目后期：项目团队的技术能力已成长到能够完成计划，且团队成员间的默契也已形成，此阶段项目经理只需管控进度，放手让项目成员发挥。
2-2-3 项目管理的基本概念
某项目会被启动的背景并不一定，有的是经过长期的评估，有的只是两家公司老板在酒酣耳热下随口敲定。经常项目经理在被指派新项目时，连具体目标是什么都不清楚。例如，客户可能说：‘开发一台像iPod Nano的MP3随身听，最好可以支持所有的音乐格式，希望圣诞节或农历春节前可以上市’。此时项目经理的老板会说：‘去告诉每个研发团队的经理，全力支持这个项目，请他们提供所有你需要的资源—好好干！这个项目别再delay了。’
客户的规格说得不清不楚，老板的指令下得模模糊糊，项目经理在设法理清项目规格的同时，还要协调各单位，以取得项目运行所需的资源（人与钱）。除此之外，项目经理还必须将所有与此项目有关的人连接起来，否则，这些关系人是不会主动投注心力在这个新项目上的。
在执行项目时，最常听到的一句话是：‘计划赶不上变化，变化赶不上老板的一句话’。所谓计划是对未来事物的规划，确实没有人能够完美地预知未来，因此，执行计划本来就是一个不断对计划进行微调，使之与实际状况吻合的过程，而且在拟定计划的过程中，能让项目成员对项目的目标与可能发生的问题有更深入的思考与分析，也就是说，即使无法制定出完美的计划，我们仍必须认真地将项目计划做出来。
在项目管理知识体系中，有许多工具与方法可以在执行阶段缩小计划与实际状况误差，稍后我们会陆续谈到。
相信大家对PDCA（Plan→Do→Check→Act）应该都不陌生吧！老板们总是将PDCA挂在嘴边，但请大家不要因此而认为PDCA只是个打官腔、不实用的论调。相反地，我希望各位在执行项目、开发软件，甚至进行任何工作时，都要切记这4个英文字母。
即便是天纵英明的神人，面对没做过或不熟练的工作时，也很难一次就把事情做对，都是一边做、一边检查、一边改善，直到做对为止。项目管理与软件工程的基本思想都是PDCA，整个项目要PDCA，某个模块的开发要PDCA，系统的测试工作也要PDCA。放大来看，项目从大到小的所有事情，都需要PDCA！
PDCA是一种做事的方法与态度，我希望在座各位都能掌握其精髓，这对各位在职场与私人生活中都会有很大的帮助。
幻灯片里的图称为项目管理的铁三角，但我比较喜欢‘质能守恒’这个说法—意即人力、时间及其他资源不可能被无限制地压榨出来。
举例来说，某件项目计划表明需要5个人、花费10万元、限期两个月、通过日系大厂的质量检验，当项目运行到一半时，在其他条件都不变更的前提下，客户希望项目能够提前一个月完成。
根据项目铁三角的原理，当你要缩短三角形的某一边，又要保持三角形的面积不变，则势必有另一个边或另两个边的边长必须加长。也就是说，根据拟定好的计划，如果必须缩短执行时间，要不增加成本或人力，要不减少或简化产品功能，不然，就只能降低质量的要求。否则只有一种可能－之前所拟定的计划肯定大有问题，要不是灌水灌得太严重，就是太过低估工程人员的能力。
在项目管理理论中有谈到为项目计划‘灌水’的原则4，以降低项目失败的风险，但等到执行时期才来大幅修改某些项目属性，却要不更动其他属性是完全不可能的。此时必须启动变更管制系统，否则计划表只会变成废纸一张，之后该项目的执行将完全失去准则、进度完全无法追踪。
因此，做好变更管理将是PM非常重要的工作，变更是一定会发生的，如何有效地管理变更是很重要的一门学问。
根据统计，85%的项目是在超过时间、未达质量标准、耗用过多资源的状况下完成，这也说明要让一个项目顺利结项并非易事，而要成功完成一个项目更显困难。根据我个人的经验，若三角形的三边（质量/规格、成本、进度）在一开始时没有构想清楚，过程中也没有做好变更管理的话，通常最后都会让项目成员之间弄得很不愉快，为了赶付交期，而牺牲质量，可能要求员工加班，进而垫高成本。
在进入项目管理知识的细节之前，我必须先强调一项重点—项目管理知识体系并未要求所有项目必须全盘导入它所提供的工具，重点还是放在思想的传达上。
但以我管理项目多年的经验，仍然认为有许多工具应该是必备的，例如：
- 一件项目是否能为公司赚到钱？是否会让团队陷入无法结项的泥沼？该不该启动一个项目必须经过严谨的评估，有个方法叫做SWOT5。
- 要解决项目经理‘责多于权’所导致的问题，老板在项目启动时千万别忘了颁发‘项目的圣旨’—项目授权书。
- 弄清楚项目的规格后，接着要细分工作，并为细部工作进行排序与设定进度……这一系列工作是拟定项目计划时的重要流程。项目管理知识体系提供了许多实用的工具与方法，其中的WBS可说是项目计划的基石，关键路径则是控制项目进度时最重要的信息。
- 我们刚刚在‘无意间’已经讲了不少关于变更管理的重要性，但它偏偏是常被项目经理忽略的一项工具。
在座的各位应该都曾经参加过一项或一项以上的项目，请问你们的项目里有这些东西吗？如果没有，我可以直接地说，这些项目并非用最佳的方式在执行，一定还有改善的空间！接下来的课程内容都会提到这些重要的工具及思想，麻烦你们带回各自的项目中。
项目管理知识体系统合了不少在管理学里已证明有效的工具，例如：幻灯片中提到的‘挣值管理’或激励理论，并非所有项目都必须导入这些工具才能成功，但他山之石，可以攻玉，既然已经有一套完整的项目管理知识体系摆在那里，我们这些靠执行电子产品开发项目过日子的人，就算无法应用它所有的工具，至少也要学得正确的思想。
项目管理不像软件工程有那么多不同的学派，不同体系间的差距并不大。我们接下来讲的内容是基于美国项目管理协会（PMI）制定的知识体系，是目前全世界最多人学习的项目管理知识，权威性与可执行性毋庸置疑。
