项目观后感

项目观后感合集7篇。

到底该如何写好有关作品名的观后感呢？好的电影可以激发我们浓浓的兴趣，就算时隔多年，再次观看仍然充满感动。通过阅读和写作我们可以获取知识和技能，经常写观后感，可以让自己的思维更加丰富，我们听了一场关于“项目观后感”的演讲让我们思考了很多，经过阅读本页你的认识会更加全面！

项目观后感 篇1

偶然间借到了这本书，于是在空闲时间断断续续看了，吸引我去阅读的理由是它所说的，任何事情无论大小都可以当做一个项目来进行管理，并且它可以综合和概括项目计划的细节和任务状态，有利于计划的进行和更高层次的理解，简单概括就是“把一件事简单又全面的说”。

为什么我觉得适合我呢，首先我是一个喜欢在事情发生前就做计划打算的人，虽然经常也会有冲动去做一些“突发行为”（比如突然买票从外地回家之类的），但大多数时刻还是喜欢计划在心的一种安定感，其次我是一个很关心细节的人，但在工作中有时候太过于着眼于眼前的事不利于了解大局，因此我也希望可以从中得到一些经验或者可以借鉴的方法。

一页纸项目中将所需内容包括项目负责人，名称、目标、风险、成本等十二个项目，文中表示，一页纸项目管理就像是手表的表面，利益相关人更在乎的是项目的关键信息、成本等，因此它的目的是将这些更简单的呈现出来，这是关乎于沟通的一个工作，但简单并不等于简化，在沟通中往往是简单的沟通是更有效。

文中提到项目经理是一个非常重要的角色，因为他要和高层管理、下级、同级别三种身份的人做到完美沟通，这在我看来是一个很具有挑战性的角色，比如我可能和同龄人相处起来还比较自在，但是与上级就往往会放不开，有时会词不达意。在我进单位几个月后有一个带两名实习生做项目的机会，如何既传递出自己的要求，不过于严苛，又树立一些威信不至于说话得不到反馈，引起他们的重视在我看来是有一定难度，我似乎做的也没有那么好，因此这种能在不同身份的人面前都能沟通自如的能力是我比较想要拥有的。

从以前我就认为我始终希望是像诸葛亮一样的角色，只要是认定足够专业厉害的领导人，就尽力辅佐他并且被领导，不需要拥有太多的权力，具备什么领导力，只要可以发挥我的能力就行了，但是到后来感觉到，总会有那么些时刻，你终将有挺身而出去承担自己责任的机会，比如大学时有一次拍摄，虽然大家没有具体去安排什么职务，我还是不自觉就到了类似于导演＋统筹的位置，这大概与我挺身而出的性格和喜欢操心、表达自己想法的意愿有关系。因此在这之前，我能做什么，我可以做什么，我要学习什么，除了忐忑不安，还有一些隐隐的期待。

项目经理的重要之处还在于负责人的选择，负责人将直接关系到项目的成败，不多又不少，还要合理搭配，使他们发挥自己的效能，即使是两位性格不合的人，也未必不会被放在一起，因为这更考验自己对问题的处理能力，这同时也是对自己的一种信任。

矩阵在我看来算是该模式的基础又核心之处，它将子目标、主要任务及风险、报告日期、成本、评价指标，团队成员一起探讨有关这些内容的确定串联在一起，作文使这个项目管理能够参考大多数人的意见，规避了一些隐患。大家一起在讨论的状态是我非常喜欢的，我回想起大学比较开心的一段时期，是我们话剧社排一个话剧时，大家一起有说有笑，想各种包袱的时刻，那会产生一种团结的力量，使我们心都在往一个方向使，并且对最终结果充满期待。

这样看起来它和okr也有相似之处，okr强调的一点就是要让我们的目标，公司的大目标每个人都要清楚，而不是只着眼于自己手头的事，并且在实验过程中也能不断调节目标的重要程度，着手去做更重要的事。

责任分工的重要性不言而喻，其中负责人根据重要等级分为了A.B.C三种，项目参与人根据主要任务的不同被安排不同等级的负责，这意味着每个人都有不同程度重要的任务，可能在这个任务中你是主要的人，在另一个任务中你是辅佐的人，这种身份的转换特别锻炼能力，并且每个人都或多或少的参与不同项目的进程。

有意思的是，后面还判断了哪些人适合管理项目的最佳组合，按部就班型、以终为始型与高瞻远瞩型的三类交叉，就拥有了全部成功的能力。高瞻远瞩的目标思考，按部就班的活力专注，以始为终的习惯授权，挺身而出，让人不自觉的会想去带入自己到底是哪一种人，我觉得我倒是有些按部就班+以终为始的矛盾感，既习惯于朝着既定的方向去走，然后每天又常常想要推翻自己，以想要成为的人来倒推自己所要走的路，说来确实是很纠结，大概用网上的一句话来说就是：间接性踌躇满志，持续性混吃等死！

言下之意，想太多！

项目观后感 篇2

众志成城，新王加冕

我不知道葡萄牙什么时候成了悲伤的代名词。从未在大赛中染指过冠军奖杯，这对于一个所谓的“传统强队”来讲是非常遗憾的。即使比1966年的黑豹尤西比奥（eusebio）好，也无法超越博比查尔顿（bobby charlton）；即使比2004年的**一代好，菲戈和鲁伊科斯塔也无法阻止希腊神话。

北京时间凌晨，罗纳尔多因伤提前离开了欧洲杯决赛！没人能在赛前预料到这一幕。在欧洲杯决赛中，葡萄牙球星克里斯蒂亚诺·罗纳尔多受伤，25分钟后离开！他是葡萄牙队中最大牌的球星，也是球队历史最佳射手；他是首位连续4届欧洲杯进球的

球员，更是葡萄牙队的队长。12年前，在葡萄牙举行的欧洲杯上，罗纳尔多很年轻，尽管他

在当届欧洲杯中表现可圈可点，但在决赛中葡萄牙败给希腊后，c罗还是像孩子一般流下了

伤心的眼泪。12年的历程为c罗贴上了许多标签，也为他带来了诸多荣誉。

队长的离开没有给球队带来任何崩溃的迹象。他们来这里不仅仅是为了举起奖杯，更是为了举起整个国家

浪漫的法国人一次又一次地浪费机会，葡萄牙在加时赛中给了东道主致命的一击。这是一次团队足球的胜利。没有船长，水手们联合起来，最后航行到了辉煌的彼岸。

与你同行，是亘古不变的承诺

与你同行，是坚实的精神支柱

与你同行，是永恒的战斗宣言。

今夜的c罗是痛苦的，他曾眼含热泪，伤退离场；今夜的c罗又是幸福的，因为队友们团结一心，战胜了法国，让他可以拥抱亲吻第一座国家队奖杯。

与他们在绿地上一样，太湖旅游的建立志在为游客打建一站式智能旅游服务平台。通过凝聚力极强的团队和市场化、专业化的运作，为打造“自在滨湖”旅游目的地品牌，精诚团结，踏实前行。

时间的长河，总有几个令人痛哭流涕的时刻，但只要勇敢前行，总会有扭转命运的机会。搏上一切，就没有不可能。

逆境不屈，方显傲骨，球场的你们一脸倔强，一种疯狂，一种昂扬。给了相信自己的勇气

星星从不暗淡。他们总是为清醒的人点亮整个夜空。虽然仲夏之夜已成为一场梦，但那一对骄傲，始终屹立在风中，永不迷失。

项目观后感 篇3

内容简介：书中内容由问题和解答两大部分组成，问题部分提供了205道选择题，涵盖了项目管理的主要概念和主题，解答部分是对这些选择题的答案分析，并清楚地标明了答案所在PMBOK指南的具体位置。《项目管理知识体系指南(第4版)疑难解答》能够帮助读者更深刻、更全面地理解项目管理知识体系指南中的内容，从而更好地掌握项目管理最新的国际标准。

项目管理知识体系指南疑难解答的读后感，来自淘宝网的网友：本书是美国项目管理协会（PMI）的权威经典著作，已经成为美国项目管理的国家标准之一，也是当今项目管理知识与实践领域的事实上的世界标准。本书中文简体字版由PMI独家授权在中国出版发行，其内容与第3版相比有一定更新，共分为5大部分12章内容，以精辟的语言更新了项目管理5大过程组的定义及项目管理9大知识领域的介绍。 本书由资深项目管理专家翻译，并由PMI组织的专家委员会最后审定。

项目管理知识体系指南疑难解答的读后感，来自卓越网的网友：最近在读这本书，非常简洁的内容，适合边读较详细的英文PM书籍时对照着看，这样效果非常不错，毕竟是权威教材。但是不大适合详细学习，因为里面的内容只是提纲挈领。 对于项目管理一直就非常迷茫，想系统性地读一些书构建属于自己的知识体系和框架，从中有可以结合实际工作经验提出自己的一些疑惑。 学无止境.....

项目观后感 篇4

“requestforproposalfor appointment of third partyinspection and monitoring agencies for projects (tpima)” 读后感

突然想到潘老师在我们辅修课刚一开始的布置的一个作业，写一个“rfp“的读后感。潘老师给我们的资料是”requestforproposalfor appointment of third partyinspection and monitoring agencies for projects (tpima)”。挑战的一面是所有的单词都是英语，这无疑增加了我阅读的难度。一开始，我很难阅读。除了一些不为人知的词汇外，还有一些专业术语。

不过结合潘老师先前的一些讲解和字典的辅助，我坚持完整的读了下来。

当我读第一遍时，总觉得有些地方不太清楚，于是，我又读了一遍我们的课本《成功的项目管理》（《successful project management (2nd edition)》作者：jack gido， james p.clements）张金成译的第2章《识别需求》，根据书上的理论知识，结合实际分析的“rfp“，我觉得自己收获颇多。

众所周知，编制需求建议书的目的是从顾客的角度全面、详细地阐述满足已识别需求的工作。一份优秀的需求建议书能让承约商或项目团队明确客户的期望，以便能准备一份全面的申请书，以可行的**满足客户的需求。

首先，通过该“rfp”background，我了解到，这个项目的提出背景是：在促进改革一体化和城市化进程中，为提供基础服务，提高城市贫民住房率、提高社区活动、提高城市地方和半国营机构对市民的义务的背景下提出的。

在“need for tpim“中，该”rfp”的对承约商的要求是①***②能成本控制③能时间控制④提高计划和预算⑤能控制现金流的流动和使用⑥能衡量项目的产出⑦能衡量jnnurm的影响

在“scope of services“中，该 “rfp”要求的服务范围: 第

一、在项目前期阶段，能够**在初级阶段的成本和时间花费，能够**项目计划和进程，测试项目文件和测试竞标文件和过程……它在项目不同阶段：建设进行阶段、测试和试验阶段以及建设完成后阶段都有要求。

在“time frame“中他们对承约商要求是项目生命周期应是项目整个过程。

在” scope of services and deliverables”中，本“rfp“要求承约商保护文件内容、在项目不同阶段访查施工地点、**填充和**所有检测报告，及时在狭小独立的文件中捕捉质量反馈；提供建议、跟上报告进程等。

它还提到了利益冲突：tpima不允许雇佣jnnurm的人员等

在“mechani**“中，“rfp“提到要拓展合作、分享信息、向tpima提供帮助。

在投标和评标中，建议分别进行技术标和财务标。

“rfp”还提出需求的内容和评价（proposals – content and evaluation）说明：要提供员工的cvs ，设备的费用要分开说明，技术竞标先进行，技术合格的继续进行财政竞标等。

另外，我认为最重要的是附录。

在技术竞标的模式（technical bid format）中有以下要求如：如何准备技术竞标，详细评价技术竞标的进程、和提交建议书的范本；申请承约商的组织和经验**，要求承约商如实填写；要求承约商详细描述为申请该工作的方法、技术、工作计划； 给出了团队组成和分工计划**；给出了公司员工的简历的模式；公司内部员工的冲突信息

财务标格式的具体要求如下：承包人拟进行的项目投标的财务标**。

最后，质量控制清单详细列出了承包商要完成的工作。

如上所述，一个好的rfp使承包商或项目团队能够澄清客户的期望，从而准备一个全面的应用程序，用可行的**来满足客户的需求。结合怎么准备需求建议书和所给的“rfp”内容我想说一下自己的一些收获：

（1） rfp必须提供工作说明书中涉及的项目范围，并总结承包商或项目团队需要执行的任务或工作单元。

⑵需求建议书中必需包含客户要求（customer resquirements）要定义好规格和属性包括;大小、数量、颜色、重量、速度、以及其承约商提出的解决方案必须满足的物理参数和操作参数。应当列明任何由客户提供的物品

（3） 需求建议书应说明客户期望或项目团队提供的可交付成果类型。交付物是承约商提供的实体内容

⑷.需求建议书中应当列明任何应由客户提供的物品

⑸说明需要客户审批的内容

⑹提到客户想使用的合同类型。因为合同有的是按固定**订立的，这样，不论承约商的实际成本多少，客户都按既定的数目付款；有的合同视时间、原材料而定，这样，不管实际成本多少，客户都会向承约商如数支付报酬。

⑺表明客户想用的付款方式

⑻表明项目完成所要求的进度计划

⑼指导并说明承约商申请书的格式和内容。因为如果客户希望在多个承包商之间对应用程序进行比较和评估，以便同时进行比较和评估。

（10） 说明客户希望潜在承包商提交申请的截止日期

⑾可能包括评价标准。客户将利用它来评估相互竞争的承包商的应用，以便选择其中一个来执行项目，包括：承包商在类似项目中的经验、承包商提出的技术方法、进度、成本

（12） 招标书很少披露客户愿意为本项目分配多少，因为客户希望承包商提交的申请以最合理的成本满足招标书中列出的要求。

我知道本需求建议书我理解的还不太透彻，一方面是由于自己英语水平有限，但我知道，大学时学习知识，提高素质的阶段，既然我了解了自己的不足，就一定会努力弥补的，另外，还要感谢潘老师给我们布置的这个作业，虽然，刚一开始，真的不太情愿做，但是，当我坚持完成时，真的有所收获，这或许也是一个理论联系实际的经历吧。

武汉理工大学（余家头校区）

计算机科学与技术学院

******

项目观后感 篇5

李沙沙0906014

看进去之后方才知道老大的用心良苦，自己在处理工作中的事情时，不管用户是对是错，用户提出问题，我的思想总是跟着用户的问题来解决问题。在这本书中针对我目前的情况有详细的解析。

这些书带给我的启发不仅仅是关于高级it项目管理这门课程的，也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的j.m.

朱兰将一个项目定义为一个计划要解决的问题。这个定义使我们认识到，项目管理就是大规模地处理问题。在我们的生活中，我们也经常遇到各种各样的问题。在项目管理过程中，随着工作的进展，我们也指出了解决生活中问题的正确思路和方法。

项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。

书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。对于我工作中，用户正常使用tajima的流程，就是我期望的东西，而体验到的东西都是，用户不按正常流程执行。

问题就在于，用户更本不按流程走。对于用户来说，用户期望的是他们可以直接改变供应商或单价，以满足采购或财务的需要。他们的经验是，供应商不能在系统中更改，单价不能在更新采购订单后更新。

所以用户的问题是：采购订单不能更新供应商，单价不能满足财务需求？到底是谁的问题？

当出现这种情况，我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到：

“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！

因为在寻找解决方案的过程中，我错误地定义了我正在解决的问题。用户入库拒收的库位选错了，入错了库位。我首先将问题的定义为：

将入错库位的数据调整至正确的库位。一股脑的想如何去调整，用哪种调整方案最简单？结果表面上是以经解决了，可过不了多久此类情况又会发生。

其实遇到这种问题应该先想想，库位选错的原因是什么，是不是之前的培训没有到位？如何杜绝这种情况再次发生？现在该做些什么？

应该教会用户在开单时就先确认库位。如在开单时就选错库位就点选取消，重新开过单据。还有一次，财务部提出采购部在采购单上更新了价格，但出入库记录的金额还是没有，希望我们帮忙解决。

我的第一个想法是帮助财务部门将采购订单上的最新价格导出给财务部门，方便快捷。但没有想到问题的起源是：采购部在入仓之前没有输入价格，而要在入库之后才补上，导致现在这种问题。

解决这一问题的方法是让采购部门在入库前填写价格。入库时，系统自动取价，不输出财务。

书中有个章节“什么是真正的问题？”里面有指出：“每种解决方法都会带来新的问题”，回想过去的工作，的确存在很多问题解决之后，产生了更大的问题。

针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。如果采购部门一直在退单价，就不会意识到退单价是一种错误的方式。

因为时间关系，我还没读完这本书。我有时间的时候需要经常看。在今后的工作中，需先将问题定义清楚，找到真正的问题，再去找寻解决这个问题的最佳解决方法：解决后产生的问题，没有解决前的棘手且最不棘手的解决方法。

书中有说到一句：“问题其实就是你期望的东西和你体验的东西的差别”。在一个项目的过程中，我们不可避免地需要与用户沟通。当然，在交流的过程中，我们会遇到一些问题。

不管用户是对是错，用户提出问题，我的思想总是跟着用户的问题来解决问题。在这本书中针对这种情况有详细的解析。我往往把用户的问题定义成了问题。

想尽方法帮用户解决。读完此书，以后在用户提出问题后，需先想想问题到底出在哪里？找出问题的真正定义！

书中还有说到：“在寻找问题定义的道路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？

没有！因为在寻找解决方案的过程中，我错误地定义了我正在解决的问题。书中有个章节“什么是真正的问题？

”里面有指出：“每种解决方法都会带来新的问题”，的确存在很多问题解决之后，产生了更大的问题。针对这种现象,书中指出：

“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，慢慢的就会无法意识到它们的存在。

《项目经理案头手册》一书对整个项目过程进行了透彻的分析。刘易斯循序渐进地教我们如何从头到尾地计划、执行和控制一个项目，如何选择项目经理和能解决问题的项ii团队，如何用wbs，pert，cpm和甘特图编制项目计划，如何设计项目控制系统，如何利用挣值分析跟踪项目，如何与团队中各层次的成员进行有效沟通，如何在项目完成后进行经验教训总结。为项目经理展示了如何成功管理不同大小、不同类型的项目，内容讲解深入浅出，案例丰富全面，既深刻地分析了项目管理的本质及一些项目管理现象的内在含义，又简单明了地介绍了实践中具体应该如何操作，很好地实现了理论性和操作性的结合。

美国著名项目管理专家刘易斯为我们提出了16步管理模式。从16步管理模式可以看出项目战略规划的定位：概念确立。

它是对要做的事情有一个框架设计，有一个想法；问题的定义。即对长远目标说明。第二步是进一步完善和明确第一步；为项目制定备选方案和战略计划。

提供战略计划的思路、备选方案和总体思路；战略计划的评价和选择。就是在选择方案的同时，有一个从总体技术路线到总体项目管理策略的评价和选择；战略的确立。就是确定具体的战略、目标；制订项目的实施计划。

这是一个更具体的二级项目计划，即如何实施；项目利益相关者批准计划。这里的规划包括战略规划、初步规划和详细规划。在这些项目实施之前，有一个审批流程；签署项目计划。项目批准人和参与项目的相管理益相关者应签署项目计划，对计划做出承诺，建立项目跟踪记录，编制项目进度日志或周、月和记录，根据记录的信息进行知识管理，并实施项目计划。

实施项目是指正式实施计划并推进项目；监督项目进度。计划开始实施之后，就要考虑计划执行得如何，有无问题，要对进展情况进行监控、监测和控制；审查项目定义。项目实施后，需要进行一些评审，包括对原工作的评审，以及对项目目标定义的评审。如果有任何问题，返回步骤2，修改项目的定义，并检查项目的策略。

首先，对目标或项目的定义进行评估，然后审查战略计划和战略制订是否存在问题。如果有任何问题，请返回步骤4，并修改项目策略；项目实施计划。具体规划工作流程，审核部分细节，如有问题及时修改；循环。按照整个过程不断地从计划的执行到监测、评审，有问题就要修改计划，然后再执行，再评审，这个过程一直延续到全部工作结束；总结经验教训。

项目完成后，及时总结经验教训，提出一些问题，为以后的项目提供指导和参考；项目结束。这是一个完整的项目管理过程。从这个过程可以看出，项目的整个战略规划实际上是在制订项目的项细规划和实施方案之前。在项目计划的时候，首先要有一个总体的战略计划，在总体的战略计划指导下再开展具体的项目计划。

书中指出项目在结束时失败，而是在开始时失败。在开展项目时，首先要明确项目的任务、前景、目标和宗旨。确定是否要进行此项目。

当我们决定要开始一个项目后，就应该制定相应的战略计划，战略要回答“我们怎样对这项工作展开活动”这样的广泛问题，而制定实施计划则要求一丝不苟，换句话说，制定实施计划有关怎样做这项工作的详细事宜。计划包括回答有关做什么、做谁、何时、何地、多长时间以及如何做的问题。

其次要对项目进度进行详细计划。项目进度计划编制既是一门科学，又是一门艺术。关于日程安排，真正的重点是找到一种在最短时间内完成项目的方法，并尽可能多地并行开展活动。

项目管理科学的一个方面涉及到资源的平衡，它是由计算机操作完成的，有很多算法。但是，同首次进行项目人力资源分配应用的技术相比，其结果差不多。

另外，资源计划也是重要的一环。完成一项活动的时间取决于分配给它的资源，并且如果没有相应数量的资源，工作就不能按计划完成。如果项目经理不能解决资源分配的问题，项目进度计划就不会成功。

此外，要对项目控制和评审。要达到项目目标，有必要采取适合的项目控制和评审。项目检查有三种类型：

即状况、设计和工作过程检查。状况检查主要检查项目是否在进度计划和预算之内、范围是否正确、绩效的要求有没有问题。而设计检查仅仅适用于包括设计工作的项目，检查中经常要问的问题是达到规范了吗？

用户界面友好吗？我们有能力制造吗？市场需要我们开发的产品吗？

投资回报及其他的产品开发理由荏苒适合吗？之所以进行项目需要检查时因为：随着项目管理水平的提高，同时提高项目绩效；确保项目工作质量不居于进度和成本问题之后；尽早找出开发问题，以便提前采取措施；识别应采取不同管理方式的其他项目领域；确保业主获知项目状况。

在项目即将结束之时应该总结经验教训，若失败，则分析失败原因，可以从以下几个层次进行分析：（1）项目管理环境中的失败 。这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的“配合”。

它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型，以及缺乏高层管理部门对项目的支持等。 项目不具备正确的组织结构、项目经理或者团队（以技能、经验、权力、正规性、复杂性来衡量）来“配合”项目。（2）项目管理系统中的失败 。

这些失败的根源可以追溯到项目领导及错误实践。它们包括项目经理在项目生命周期中对系统方法的忽略，以及项目管理技巧的错误应用等。具体的可以归结为：

不胜任的项目经理；忽略了项目的系统本质 ；管理技巧不恰当或者错误的运用 。（3）在计划和控制过程中的失败 ：项目中没有良好的沟通 ；没有用户的参与 ；不充分的项目计划；不充分的项目定义；糟糕的时间和资源估计；不正确的工期安排和资源处理；在执行阶段为数众多的变更 ；不恰当的控制 ；项目终止的计划很拙劣 。

同样项目成功也应该总结经验。要取得项目成功，项目的目标定义、项目的系统、整体系统控制、整体计划，包括战略计划、实施计划、日程计划要通过详细、认真地预算、估算，保证项目能够得到充分的资源。在项目的实施过程当中，要通过经常性的审查、控制和评审来保证项目能够按计划不断地推进。

除此之外，组织目标的实现还需要在组织上保证。包括项目经理的领导艺术、项目经理的管理才能、管理技能以及相关的技能、组织结构和团队建设方面。所有的这些，都是保证项目走向成功必不可少的环节。

《微软研发制胜策略》和《微软项目求生法则》两本书也给了我很多启发。求生法则从求生心态、求生准备、逐步迈向成功以及完成任务几方面向我们阐述软件项目是如何存活的。作者利用在研究与工作中获得的经验告诉我们项目开发过程中的规划、设计、管理、质量控制、测试与完工所需的策略与观念，并利用大量技巧建立一套精简可靠的框架来成功的管理项目。

软件项目的存活不是一种意外的结果。要让一个项目成功所需的努力并非特别困难或耗时，只是需要从项目开始进行的第一天就勤奋努力到最后一天而已。软件项目是发现与发明的过程。

发现与发明融合为一的最佳方式是透过“阶段性完成”的做法，将产品的功能分阶段完成，而最重要的功能最早完成。当项目进行时，许多活动交互重叠，把产品由抽象概念转化成具体成果。项目进行中的源代码倾向以s形曲线而非线性成长，而大部分的程序代码都是在项目中间第三部分完成的。

追踪程序代码的成长提供对项目状态的洞悉力。执行良好的项目也可以由一名上层主管选择最有成效的一组来进行追踪。

软件项目被切分成三个概念阶段。在项目初期，焦点摆在“发现”，特别是发现使用者的真正需要。透过技术性调查、与使用者访谈和建立接口雏形，把不确定性的概念转换成确定的观念，这就是第一阶段的特色。

在项目进行中期，焦点移到了“发明”上。往大方向看，开发人员要发明软件构架与设计方式。细节的地方，如每个函数式或对象类别也不能忽略。

如同发现阶段般，发明阶段的特征在于将不确定的概念转换成确定的观念。如果有其他特性，则发明阶段的不确定度要高得多。在发现阶段，开发人员可以确定答案“就在”某个地方。

可是在发明阶段，就不能以此类推。在项目的最后部分，焦点又转移了，这次摆在实作上。不同于发现与发明阶段的是，实作阶段的不确定性少多了，故可发掘出许多已确定的观念并可实现成具体成果。

本文提供的项目规划依循着“阶段性完成”的轮廓进行。由于她将项目中开发的软件分阶段完成，而不是到了项目结尾才一次完成，这种方式称做“阶段性完成”。 在每个实作阶段中，项目团队进行细节设计、程序写作、除错与测试，在每个阶段都建立出可能推出的产品。

分阶段完成有以下好处：关键功能更早出现；早期预警问题；减少报告负担；阶段性完成可降低估计失误；阶段性完成均衡了弹性与效率。阶段性完成的做法听来似乎毫无缺点，其实则不然。

阶段性完成的做法要付出相当代价。因为项目团队需要时间准备各种可推出的软件，在每个阶段重复测试已经测试过的功能，推出软件前进行相关的版本管制工作，提供试用的不同版本软件没预料到的问题的解决方案（如果阶段性完成的软件真的拿出去给人使用），还有规划阶段性发行这种做法的好坏等等，都会提高项目的负担。阶段性完成并不是万灵丹，不过总合起来，那些额外的负担相对于明显改善了的状态、质量与时间的匹配、精确预估与降低风险等来说，不过是一点小小的付出而已。

项目观后感 篇6

初次阅读这份设计书，误把重点放在数字城市这个概念上了，跟随导师的指导后我进一步的对这篇设计书再学习了一遍，我认识到了，我当初写的那篇心得确实太浅显，眼光只停留在关于数字城市这一方面的一些概念性的知识。而不是从专业的角度来学习这本项目设计书。这也说明当时我们的专业水平相当低，相关的理论知识也很缺乏，找不到一定的高度来理解和学习这本设计书。

当然，学习这篇设计书需要从数字城市这个概念入手，但是核心问题还是在地理空间框架这个方面，我们的学习不能只停留在概念和表面上的学习，更要深入到专业领域，熟悉相关理论，了解操作流程。再用专业的眼光去审读这篇设计书后我发现我学到的比初次读的时候更多，仿佛登上几个台阶之后向下俯揽，收于眼底的风景更加广阔，更加系统，更有组织地理解设计书的思路和要求。

下面我将我对这份设计书的理解，和有关于地理空间框架以及数字城市方面的拓展学习做一个简短的总结，我明白这当中也许存在某些误解和偏差，望栗老师阅读完之后给与批评指正。

首先从概念入手，说实话对于我跨专业的我，开始对城市地理空间框架这个概念确实不太明白，那就用最快捷的方式，就是百度一下。必须首先理解这一概念，这是深入学习的前提。

城市地理空间框架数据是按照一定的规则收集和组织起来的一组地理空间数据，用来描述城市地理空间框架要素的空间特征、属性特征和时间特征。城市空间框架数据的扩展非常广泛，不仅包括城市基本地形信息，还包括一些反映城市自然、人文、经济等基本信息，具有基础性、广泛适用性和经常适用性。

明白它是什么之后，下面就要学习它的内容组成：城市空间框架数据的形式多种多样,除了表达城市基础地形要素最主要的数字线划图(dl g) 、数字高程模型(dem) 、数字正射影像(dom) 和数字栅格图(drg) ,即所谓的“4d 产品”外,还有表达各类城市专题空间数据的矢量和属性的存在形式;表达相同内容信息的城市空间框架数据也可拥有不同的比例尺和分辨率。因此,对于城市空间数据框架中空间数据内容、形式和尺度的确定,应当从数据生产周期、成本和质量的特点以及城市实际应用的需求上着手,根据其特点和需求的不同,选用不同的数据内容、形式和不同的比例尺、分辨率,只有这样才能使城市空间数据框架建设真正起到应有的作用 。

此外，框架数据的建设应遵循相应的国家标准、行业标准和地方标准。

城市地理空间框架数据一般由基础地理空间数据和专题地理空间数据组成。

基础地理空间数据提供了有关自然、人文、经济、环境等要素的几何位置、形态特征和相关关系，使用户能够按照地理坐标或空间位置集成、检索、展示他们所关心的各种城市信息，进行空间分布特征、运行状态、变化态势等的分析模拟。基础地理空间数据是专题地理空间数据和gis应用服务系统的空间定位基础，反映了城市的自然地理条件和社会经济条件。根据“数字城市”建设的内在要求，基础地理空间数据主要包括综合管线数据、行政区划数据、道路数据、水体数据、地名数据、建筑物数据、地下空间设施数据、地址数据、地籍数据、测量控制点数据等。

基础地理空间框架数据的质量应通过数据志和质量元素来描述,数据志将完整、准确地描述数据源、数据获取与加工过程、数据内容取舍以及数据更新维护等情况;质量元素将包括数据的完整性、位置精度、时态精度、逻辑一致性和属性精度。

专题地理空间数据是指与空间相关的其他城市专题信息，这些数据包括土地利用现状数据、规划用地数据、园林绿地数据、公共服务设施数据以及特殊管理区域数据等城市专题信息 ，并且可以根据各个城市的自身特点和需要进行扩展。与基础地理空间框架数据类似，专题地理空间框架数据的质量也需要通过数据日志和质量元素来描述。

这当中涉及两个从未接触到的概念：“数据志”，“数据质量”。

数据日志是指数据仓库系统中一个仓库数据项的准确历史记录，即数据采集、转换、集成到现状的全过程的相关描述和信息。数据日志由两部分组成：初始数据集和作用于数据集的数据处理过程。

获取数据志的过程称为数据跟踪。数据志跟踪技术是数据仓库研究中一个最新的前沿性课题，不仅可以支持更全面，更深入的数据分析，还可以帮助技术人员验证源数据、清洗规则和转换处理的正确性，从而提高数据仓库的质量。

数据质量元素是描述数据质量的信息项，包括位置精度、属性精度、逻辑一致性、完整性、现状和数据描述。在数据分析和数据仓库领域，数据质量是由数据质量元素来描述的。数据质量元素分为两类：

数据质量的量化元素和数据质量的非量化元素。数据质量量化元素用于描述数据集满足预设质量标准和指标的程度，并提供量化质量信息。数据质量的非量化元素提供了全面的、非量化的质量信息。

既然上述概念说城市地理空间框架是一组地理空间数据，那么它的作用和意义是什么？地理空间数据框架是地理空间框架的基础参考框架,它为国民经济和社会信息化提供统一的空间定位与基础地理信息公共平台,对于信息资源按照地理空间进行整合和实现信息共享具有十分重要的作用。城市地理空间基础框架是“数字城市”建设的核心任务之一。

构建城市地理空间数据框架的首要任务是建立城市空间数据基准，关键是在数据基准之上建立城市空间数据库。

项目观后感 篇7

按照事业部的要求，抽时间阅读了郭致星的《做项目，不得不这么干》一书。虽然大道理都是CMMI、项目管理所必须的，但书中有很多活生生的案例，能给我们更多的启发。本书从实用出发，系统介绍了项目管理中的难题和建议的处理方法，根据大量的实践经验，尤其是从失败中得到的经验教训，总结出现不确定和可变的项目管理过程中，造就卓有成效的项目经理所需的关键因素及技巧，是一本实践性和指导性都很强的项目管理工具书。我们的项目管理者真应该静下新来仔细体会，并选择合适的内容在项目管理中进行实践，逐步提高项目管控能力。

在沟通中最重要的事情就是听到没有说出来的话--彼得德鲁克；

分析痛点，也就是表现出来的最担心的方面，重复的就是痛点；

这些都是项目管理的重要过程需求获取时的真知灼见。我们都提到要打开客户的需求，但要真正做到谈何容易。需求获取准确性的问题，需要理解客户的需求，弄清需求背后的真实业务，重视干系人潜在或者隐含的需求，是项目最终成功的关键因素之一。书中提到的一个观点：避免出现选择性知觉，获取真实需求，挖掘痛点感觉在需求过程中尤其重要。可能我们是某个领域的专家，但客户的真实意图并一定跟我们潜意识理解的一致，因此需求调研的核心是澄清而不是说服就显得尤其重要了。

书中提到：研发包括研究和开发两种不同的活动：前者指对新技术、新工艺、新方法的研究，后者是对新产品、新服务等的开发；前者主要是创造性活动；后者是研究成果的集成性、应用性活动。没有研究，企业就没有未来的竞争力，没有开发，企业就难以生存。研发项目的根本是开发，没有开发出产品的研发项目就是失败的项目，因此研发的项目要以市场为导向，能尽快地应用到实际开发项目中，为企业创造价值。仔细回想一下我们的平台研发项目，贴近需求并保证适当的前瞻性才是重要的，我们推出的产品与技术是为兄弟部门服务的，也就是要切实解决他们的痛点问题，只有这样的开发技术和工具才能够得到迅速的推广并在使用过程中不断完善。前瞻性是我们技术研发人员必须具备的技能，并不是推动平台研发的必要条件，因此平台项目在进行研发时，需要贴近开发需求，瞄准项目开发过程中的痛点，在开发效率与可测试性等方面持续提升。

高素质复合型人才是难以自拔的陷阱，当项目的执行效率不那么令人满意时。员工素质不高是管理者常挂在口头的词汇，实际上，过渡依赖高素质复合型人才会是组织忽视积累属于组织的知识和技能，反过来又会使企业更加依赖这些高素质的复合型人员。当企业没有属于自己的核心知识和技能时，缺乏高素质人才是我们最好也是最没用的借口。

尽管大量的统计结果表明，项目失败的原因大多来自组织、管理方面，单纯由于技术原因造成的项目失败的比例很低，但是在大量的项目实施过程中，技术问题却是大家最常用以说明问题的理由，因此技术问题成为了档箭神器，当然参与的技术人员也自然地背起了黑锅。书中提到的这些真是说出了开发人员的心声，於我心有戚戚焉。

读完这本书，心中不禁产生一个疑问：书中讲的内容我们在CMMI规程规范中都能找到相关的影子，为什么实际项目在执行中总有这样那样的问题呢？回顾一下我们公司的CMMI研发管理的过程文件，从最初的生命周期模型选择、项目立项过程中的过程裁剪、项目计划、需求获取与需求开发、设计有敏捷开发、测试与发布、直到项目实施过程，都有比较详细的指导方法，是这些内容和措施水土不服？估计有这方面的原因，更多的原因则是意识形态上的问题，认为过程管理是一个付出远大于收益的过程，除了一些大项目，在项目过程中发挥不了多大的作用。另外缺少必要的项目总结和经验积累、并根据经验教训不断完善过程文件，使之运行更加高效。

再分析一下部门的研发项目，项目经理更多是技术层面的领导者，在项目立项目标确立、项目评审和计划实施中并不尽科学和严格，另外开发内容也没有贴近公司或者事业部的痛点，开发人员费大力气做出的产品在技术上虽然有竞争力，但由于很难在公司内推广，造成一定的技术浪费，同时开发人员也没有获得应有的成就感，必然会产生一定程度的挫败感。我们的研发经理需要多掌握项目管理知识，理论联系实际，分析自己的短板，明确团队和项目的目标，认真审视和对待项目计划，使得研发工作更加科学和高效。