启动：确立一个项目或一个项目阶段。

规划：为完成项目，制定和维护一个可操作的计划。

执行：协调人力和其他资源以执行计划。

监控：通过监控和进度测量及必要时采取纠正措施以确保项目目标的实现。

收尾：正式验收项目或项目阶段并使其有条不紊地圆满结束。

 

PMP考试采用客观的选择题形式，共计200题，其中25题不计成绩。答题时间：9：00～13：00，共计4个小时。从2005年9月30日开始，报名PMP考试的新生的及格线为61%（200道单选题中抽查25道不计分，即答对106道题）

有小伙伴看到这里不禁发出轻蔑的奸笑，搞了半天原来都是选择题，那太Soesay了.额。。。先别急着下结论，让我们先看看考PMP的最重要的一本书（这里说的是最重要的，意思就是还有其他辅助书籍，你懂得）

 　　　　　　　　　　　　　　　　　　　　　　　　　　　　（PMP考试主教材）

那要小伙伴就比较好奇了，看这本书的侧面貌似有些厚度，那这本书里面都有哪些内容呢？

恩，这个问题问的好～

以上就是整本PMBOK的主体所有内容，当然，如果要面对考试，光看上面一本肯定不是够的（主要是开始难以理解，全文看上去都是讲的：输入-技术工具-输出），所以会有很多辅助书籍来帮助读者理解PMBOK，小弟统计了下几个月看的考试资料相关书籍，有图有真相

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

好了， 有小伙伴看到这里已经犯晕了，并准备开启开喷模式了。先别喷，下面才是今天我想讲的重点。

职业路线图

　　　　　　　　　　　　　　　　　　　　（图片来源于网络）

术语表

图中使用了很多术语，这里先做解释，只有我们大家都说同一种语言，沟通才会顺畅。

• 程序员：撰写代码，生产软件，辅助提高社会生产率的脑力劳动者。据说喝的是咖啡，抽的是烟，产的是代码。他们是计算机诞生后才逐渐兴起的一个群体，鱼龙混杂，有高飞天上的白富美，也有低到尘埃里的矮矬穷，总之虽一类而九流具足。
• 初级工程师：入门程序员，怀揣着IT行业多金的遐想进入了IT江湖，开始了练级打怪求升级的游戏之路。
• 中级工程师：经过几年的打拼，有一定的拷贝、粘贴功底，掌握了太祖长拳或罗汉掌之类的一技之长，打字速度变快了，双眼变得稍稍有些迷人了，对零壹世界有了比初级工程师更深刻的认识。
• 高级工程师：拷贝、粘贴之术出神入化，又习得搭积木和沙滩上盖大楼的绝技，还能像江湖郎中一样给病入膏肓的代码开药了。
• 架构师：坚信技术可以让人牛X，抵制了各种旁门左道的火辣诱惑，闭关多年，终于一生二、二生三、三生万物了，能够坐而论道、指手画脚了，觉得自己形神具备有仙人之资，偶尔来个仙人指路挺爽。
• 技术专家：看过各种江湖流派，最终在某条羊肠小道之上月黑风高之夜顿悟辟邪剑法，从而成为一代旁门高手，在自己的领域里无人能及。
• CTO：史上最强的技术流？不一定。不过有一点高度是肯定的：会当凌绝顶，一览众山小。正统的CTO专门研究各种武技，寻求能在未来的江湖中克敌制胜的秘辛。国内江湖乱象纷呈，很多CTO其实在打杂做管理。
• 小组组长：这并不是一个正式的头衔，在《江湖异闻录》中，小组组长被掌门委以突袭带头人的角色，只因为他有带头大哥的潜力，能激发大家的战斗力。虽然没有掌握绩效考评之类的绝杀技，不过也是通往管理之路的必经过程。
• 项目组长：管的事儿有点儿多了，要带人，要带项目，要和产品经理搞好关系，通常也得和小分队的成员不分你我，总之什么都干，干的是项目经理的活，只是没有名分。没关系，等带好一个项目，又有项目经理的缺时就可以顶上去了。
• 项目经理：这是一个正式的打杂的，终于有了名分了。
• 高级项目经理：又叫项目群经理。他搬了把凳子以便让自己站得更高，能够看清楚纷乱的江湖里多个项目的情况，通常需要协调这个协调那个，找项目经理谈谈话，抚慰一下项目经理或项目组长委屈的心，有时也会被来自上面的压力压得喘不过气来。
• 部门（项目）总监：So，不知道要说什么了，开始管各种事儿了，评估项目开发过程，拟定考评、绩效、职级等各种制度，或者今天跑这个项目聊聊天，明天跑那个项目聊聊天，后者自己左右互搏和自己聊聊天，看起来闲人一个。

就这么多吧，其它的也不想说了。因为我们要讨论的是程序员的出路……

　　　　　

程序员 路在何方

图中框起来的，是程序员的主旋律。

程序员，专业人士也，与瓦工、木匠、发型师、保洁员等类似，不过是社会万千分工之一种，没什么高大上，也没什么矮矬穷，只不过时代大潮中被滚滚洪流裹夹着前进的一群人而已，所谓泯然众人矣，就是说的这个。

So，该说什么啦？

你怎么混进来的

不忘初衷。

不忘初心。

你是不是忘了当初为什么要干这个？

那就想想吧。有好处。

有的人是为了程序员的高薪

有的人是想要一份体面稳定的工作而已，别出差

有的人是过来打酱油的早抱定了过两年就走的心

有的人想了解这个世界，试试看自己合不合适

有的人就喜欢计算机的世界，如鱼得水

有的人觉得这个行当既专业又神秘，感觉倍儿棒

有的人喜欢挑战，因为软件开发每一刻都有战斗的感觉，各种问题纷至沓来

有的人就喜欢不断学习新技术，为技术而生，而没有哪个行业像这个一样时刻都要学习

有的人喜欢这个行当的成就感，持续不断的小刺激总让人高潮不断

有的人渴望有自己的软件作品

有的人想用软件改变世界

有的人觉得这是一片净土，罕见尔虞我诈，不必江海寄余生

有的人觉得这行门槛低，谁都可以来搞两下

有的人是来发动战争的，攻破别人的防线感觉很爽

有的人是冲着 IT 界牛人半数都出柜这一点来的

……

总之各种理由都有，你也一定有自己的那一个。对吧，你自己的。　　

将来去哪儿

　　　　　　你今天的选择，决定了明天的路。

有些人听说IT行业薪资高，巴巴地进来了，可是干了两三年，工资还是四五千，只好失望的走了。其实除非你有经天纬地之才，没有一开始就高薪的道理。先做事，后有钱。先想钱，钱难来。做程序员搞开发大抵是酱紫的。听说有个哥们跳到了华为，天天晚上十一二点的搞，有一天他终于不慎抱恙，晚上九点多回去了，被整个组的人鄙视；可是华为熬过三年，钱多多的，年终奖和分红抵得上你一年的工资。关键是，你熬得住吗？你媳妇熬得住吗？

我想说的是，作为程序员，心态决定你的将来。你自己怎么看待你所从事的工作，你是享受它、厌烦它、无所谓、爱恨交加……这些决定了你将在这条路上走多远。

我们生活在一张社会关系网中，因为别人能够看到你你才存在，这是《作为意识与表象的世界》，你看到的人、别人看到的你，都只是作为观察者的那个人想看到的，而非真实的人。虽然真实的人客观存在，但没有人能看到这样一个真实的、完整的人，包括你自己。

你看到你想看到的，他看到他想看到的，张三看到张三想看到的，李四看到李四想看到的……周围一圈人对你的意识构造了社会化关系中的你，但那只是你的一小部分。仅此而已。如果别人不知道你，你就不存在。为了存在，你就要在别人面前出现，这就是“存在感”。

我原来有个同事，程序很厉害，是公司的高级工程师，后来不干了，开便利店去了。

    有个同学在做直播创业.....

    这都是跳出三界外的故事。其实也很平常，你的选择，你做主。如果你觉得这个行当不是人待的地方，再也不要受这罪了，那就走吧。如果一份工作带给你的痛苦比欢乐多很多，确实没有留恋的必要。真的，你肯定是走错了路。

 

项目管理与软件开发的质量、效率、最终成果息息相关，下面主要围绕软件项目的风险评估、成本预算、客户沟通、需要分析、开发管理、成品交付等多个流程进行分析。
在现今国内的项目的管理形式十分零乱，对管理欠缺重视，以致很多项目因为失去管理而最终折腰。
很多的实战形人才只重视于开发环节，而对其他的流程欠缺认识，因而导致项目欠缺有条理的、阶段化的管理。

 

软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面：

1.      产品规模风险

项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关：

(1)  估算产品规模的方法

(2)  产品规模估算的信任度

(3)  产品规模与以前产品规模平均值的偏差

(4)  产品的用户数

(5)  复用软件的多少

(6)  产品需求变更的多少

2.      需求风险

很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的，这些的风险因素有:

(1)  对产品缺少清晰的认识

(2)  对产品需求缺少认同

(3)  在做需求分析过程中客户参与不够

(4)  没有优先需求

(5)  由于不确定的需要导致新的市场

(6)  不断变化需求

(7)  缺少有效的需求变化管理过程

(8)  对需求的变化缺少相关分析等

3.      相关性风险

许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险， 能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题,与外部环境相关的因素有：

(1)  客户供应条目或信息

(2)  交互成员或交互团体依赖性

(3)  内部或外部转包商的关系

(4)  经验丰富人员的可得性

(5)  项目的复用性

4.      技术风险

软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。 在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。关于技术主要有下面这些风险因素：

(1)  缺乏培训

(2)  对方法、工具和技术理解的不够

(3)  应用领域的经验不足

(4)  对新的技术和开发方法应用不熟悉

5.      管理风险

尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足——不能检查到自己的错误。因而，使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：

(1)  计划和任务定义不够充分

(2)  对实际项目状态不了解

(3)  项目所有者和决策者分不清

(4)  不切实际的承诺

(5)  不能与员工之间的进行充分地沟通

6.      安全风险

软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方 面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们 软件项目潜在的风险。

7.      回避风险的方式

(1)  以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。再以书面方便形成《用户需求》这一重要的文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。

(2)  设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。

(3)  需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。

(4)  控制系统的复杂程度，过于简单的系统结构，对用户来使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。

(5)  从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。

(6)  设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。

成本预算

1.      成本预算方式

(1)  自上而下的预算方法

自上而下的预方法主要是依据上层、中层项目管理人员的管理经验进行判断，对构成项目整体成本的子项目成本进行估计，并把这些判断估计的结果传递给低一层的管理人员，在此基础上由这一层的管理人员对组成项目的子任务和子项目的成本进行估计，然后继续向下一层传递他们的成本估计，直到传递到最低一层。

使用此预算方式，在上层的管理人员根据他们的经验进行的费用估计分解到下层时，可能会出现下层人员认为上层的估计不足以完成相应任务的情况。这时，下层人员不一定会表达出自己的真实观点，不一定会和上层管理人员进行理智地讨论，从而得出更为合理的预算分配方案。在实际中，他们往往只能沉默地等待上层管理者自行发现问题并予以纠正，这样往往会给项目带来诸多问题。

自上而下更适用于项目启动的前期，与真实费用相差在30% ~ 70%之间。

Scrum使用自上而下的成本预算方式，它不会立即精确地确定成本，而是以最大限度容纳客户对未来产品要求所产生的变更。

(2)  自下而上的预算方法

自下而上方法要求运用WBS（Work Breakdown Structure，工作分解结构）对项目的所有工作任务的时间和预算进行仔细考察。最初，预算是针对资源（团队成员的工作时间、硬件的配置）进行的，项目经理在此之上再加上适当的间接费用（如培训费用、管理费用、不可预见费等）以及项目要达到的利润目标就形成了项目的总预算。自下而上的预算方法要求全面考虑所有涉及到的工作任务，更适用于项目的初期与中期，它能准备地评估项目的成本，与真实费用相差在5% ~ 10%之间。

2.      确定项目支出

总体成本预算就是结合下列多个成本预算方式综合计算的开发成本：

(1)  零基数预算

在成本预算的初期应该使用零基数的计算原则，而不可以使用类似于：以上一年总体费用加上20% 这样粗略的方式计算项目成本。

(2)  软硬件成本、物品成本

物品成本是指类似于：服务器（RAM 硬盘 CPU NIC卡 RAID簇）成本、维护成本、机房租金、光纤通讯成本、软件成本等的成本。

计算成本时需要考虑组装硬盘需时的长短，技术人员需要具备的质素，产品供应商能否提供保证质量，管理时是否需要额外的管理人员这些多方因素。

(3)  软件许可证成本

(4)  外包成本

当使用类似：视频、短信、移动电信类服务、门户网站等子项目时可以考虑以外包形式完成，以降低开发成本。

(5)  人力资源成本

计算人力资源成本时应该使用以最高和最低的工作效率估算平均效率的方式，计算出人力资源的平均成本。

(6)  维修保养成本

客户沟通的过程

从客户沟通的方向出发来看，软件项目可分为：需求识别、方案定制、项目实施、项目结束等4个不同的阶段，各个阶段都具有不同的沟通重点。

1.  需求识别阶段

(1)  文本沟通

在需求识别的前期，应该通过问卷、原型展示、界面展示、逻辑处理展示、准化文档模板等方式进行全方位多角度的分析，随时将不明确之处反馈给客户,以期待客户解答。并以文本记录的方式建立需要分析书，并要求客户审核需求分析书，以达到需要分析与客户的真实期望高度一致的结果。

(2)  业务逻辑沟通

在进行业务沟通时，应该了解客户的行业语言，以促进业务分析的过程，越过应用需求和开发之间的鸿沟。沟通过程提倡以草图或者可视信息化的方式进行, 针对不同层面的企业用户提供最适合的操作界面。以多角度的方式思考问题，要抓住需求重点,尤其是客户方领导所关注的创新类和实用类需求。

(3)  需求变更的规范化管理

需求变更在软件开发类项目中是可以理解的,但必须对需求变更做好规范化的管理，以避免出现需求无止境变更的风险。需求变更必须由统一的负责人提出,并且由用户需求的审核领导者认可。需求变更的提出应该是定期而不是随时的，开发方应该做好详细的文本记录,让客户了解需求变更的实际情况和开发方为之所付出的成本代价。

2.  方案定制阶段

该阶段项目的主要任务是与客户共同制定一个以前期明确的需求、双方的资源、项目开始的阶段、实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划,从本阶段开始争取客户全面参与项目的管理，并以双方的共同利益考虑项目实施的具体计划与风险规避。

3.  项目实施阶段

在该阶段,软件项目团队应该与客户共同领导项目的实施。同时,项目团队应实时评估客户满意度,并通过持续改进的方式提高客户满意度,还应要求客户参加必要的培训,以及在必要时检查项目产品。在出现客户的需求变更前,应主动与客户沟通交流,使客户充分了解项目的每个环节,以及变更带来的影响,减少需求变更。如果出现客户需求变更,应与客户一起共同解决由变更引起的成本、进度、质量变化。

4.  结束阶段

该阶段主要进行项目成果的移交，并把系统交付给维护人员，帮助客户实现商务目标，结清各种款项。完成这些工作后应该进行项目评估，审核此项目的成果并总结项目经验。

5.  售前人员注意事项

在产品型项目作为开发成果时，相关销售人员应该注意：对产品的推销不应该过分承诺。如果过分承诺,会给后续的项目实施带来困难;一旦承诺没有兑现,也会降低客户满意度,影响今后合作。如果有附加承诺,一定要以文本形式记录，让实施项目经理知晓并传达给项目组成员。