Learning Time

【读书笔记】关于项目管理的一些思考 ——对《项目百态》的理解(六)


6 项目经理的自我修养

6.1 项目经理的风格:感性、理性和中庸

感性的项目经理关注成员的精神状态,宏观的项目行进方向,使用富有情感的沟通方式,使用开放性结论,倾向乐观主义,不再整体框架内谈论细节。

理性的项目经理关注项目的基本状态,使用数字说话,对事务进行条理分明的分析,给出确定的结论、建议和计划,几乎任何评论的都是可衡量的。

中庸的项目经理处于两者之间。

6.2 项目经理不是记者

记者只负责报道真实情况,而项目经理的职责是:保证项目达成目标。

一些项目经理对项目的情况了如指掌,但却假设项目失败也与己无关,他们坚持认为了解项目情况并汇报给上级是他们的职责,这些人显然是不合格的项目经理。项目经理首先要确保项目的成功,报告只是达成目标的一种手段,而不能用来代替目标。

况且,一个好的项目报告并不仅仅是反映项目进展情况而已,它应该是有结论和观点的:

不使用海量数据:仅使用经过慎重选择的,有限的衡量指标。

重点信息和次要信息层级鲜明:帮助团队找到关键点。

提供结论:而不只是数据的堆积。

除了反映现实情况,还能够预估未来。

反映出趋势:时间、数量等等。

各项衡量指标有明确的定义:每个成员都应该清楚指标代表什么,避免产生误解。

6.3 当好团队的保姆

一个优秀的项目经理除了分配任务,制定计划,寻求最佳的资源组合之外,还应扮演团队保姆的角色,让团队成员能够不受打扰的专注在项目上。他们为成员提供最好的工作环境、帮助员工提高工作技能、为员工设定合适的挑战、保障团队不受外来事务的影响。

糟糕的项目经理是这样的:他们热心解决(或参与)办公室政治、专注于行政管理和流程管理。在他们看来,与领导沟通、绘制各类图表比与成员沟通更重要,还有不少人,承担了太多的实际工作,而不是腾出时间去解决团队的需求。

6.4 神一样的项目经理对组织来说未必是好事

如果一个项目经理总是能让各方满意,则组织需要注意的是,这些完美的工作到底是依赖于团队的运作还是项目经理的个人能力?如果是后者,对组织来说并不是健康的发展方式。作为项目经理来讲,在工作中也应该逐步建立起团队合作的机制,培养一些管理人员和领导人员,而不是亲力亲为管理所有的事项,虽然在某些组织中,对手下放权和培养可能会对自己的地位造成冲击,但这是一个合格的领导人必须要做的事情。

6.5 在第一时间说不

出于政治因素,大多数时候项目经理都不得不应承一个又一个新加入的需求,虽然他明白加入新的东西,不断扩展项目范围会拖慢进度,增加投入,最终使项目陷入泥潭,但这是一个关乎“项目交付物”和“政治影响力”的两难选择,是项目经理必须面对的问题。

人们虽然都听过“少即是多”,但心里总还是会认为“多才是多”。从公司层面来看,当人们奇怪为何公司的发展如此缓慢的时候,检视一遍自身正在做的事情是有必要的,也许正是因为有太多的项目、产品、战略拖慢了公司的脚步,才使之最终一事无成。

6.6 做个发明者

即便是显而易见的好主意,对于组织来说,也不会很快被接受。人本质上是不愿意改变的,由人组成的组织则更抗拒变化,他们会不停的论证新的想法,分析风险,而迟迟不愿行动,越庞大的组织越是如此。但这并不是组织的错,毕竟新的想法即使再好也只是理论上的,而实施的风险和成本是组织必须要考虑的。

解决之道是把自己从倡导者变成发明者。提出一个好点子的人是倡导者,而不断提出好点子的人则是发明者,正是这个区别使某些人与众不同。从倡导者转变为发明者需要的是实实在在的努力,这或许需要很久,而正是因为这一点,也会使人们更愿意接受你的想法,因为它经过了考验。

把创新变成自己的基因吧,当组织里有越来越多这样的人,组织自然就存在了这样的特点,而无须费尽心机去寻找“创新”。

6.7 学会关注细节

许多公司希望追求完美的产品,因此他们到处挖人,并妄图去压榨设计师的智慧,这种做法效果甚微。实际上,完美的设计不仅在于设计人员,还受到经理的极大影响。如果一个经理关注细节,当他用心去欣赏某人的作品,也许会发现许多此前未曾注意的细节,两人会因此获得某种默契,这时,经理在设计人员的眼里就不再是个不错的经理,而是“值得一直跟随的老板”,最终形成良性循环,设计人员会更加努力,不仅仅是为了追求完美的设计,还为了获得自己所认同的人的欣赏。


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


【读书笔记】关于项目管理的一些思考 ——对《项目百态》的理解(五)

5.项目80%的工作是沟通

5.1 沉默不代表同意

每个人对于承诺的内容以及什么代表承诺都有着不同的理解,当某人提出要求时,另一人沉默,是否能代表他们互相达成了协议呢?当然不是,这种误解导致了项目中各类突发事件的发生。一个行之有效的方法是:公开声明少量的重要承诺,写下来,共享给相关人士。承诺者与被承诺者应确保对内容和遣词用句的理解是一致的。

只有说了“同意”,才是真正的同意。

5.2 选择合适的沟通方式

无论何时何地,语言沟通都是最有效的沟通方式,而书面则是最有效的记录方式,团队需要做的就是:说,然后写下来。

不要迷信任何一种沟通方式,任何方式都有适用的场景和范围,大公司也可以用快捷高效的对话完成决策,小公司也会将延续性的决策记录在案。

避免成为邮件狂人:在大公司或分布式团队中,邮件成为主要的沟通方式,慢慢的,人们会认为处理完邮件即完成了工作,越来越多的人被加入到抄送列表,通常的后果是,能够在一个简短会议上决定的东西在邮件中争论了几天也得不到解决。

5.3 让接口保持统一和简单

项目中复杂的人类接口容易导致复杂的产品接口。所以我们需要定义每一个接口,避免不同的人对接口做出不同的假设。需要定义的接口不仅仅是产品的,还有团队和团队之间,工作组与工作组之间,人与人之间的。

5.4 冲突总是存在,它并不意味着沟通失败

由于每个人的想法是不同的,所以在工作中总会存在冲突,但很多人会将冲突归咎于沟通问题,来转移真正的冲突,其潜在的观点是:我们是同事,因此我们不应该有冲突,如果出现不同的看法,那一定是我们沟通不够。但实际上,大家都很清楚彼此的想法,但却讨厌对方的看法。为了避免成为“不够职业的人”,人们宁可放弃去想办法有效的解决冲突,而是把精力放在了努力改善沟通上,这通常是于事无补的,冲突一直在那里,即使你千方百计的想要避开,但最终还是会无可避免的面对它。


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


【读书笔记】关于项目管理的一些思考 ——对《项目百态》的理解(四)


4.项目的最终目的是交付好的产品

4.1产品设计的美学

在产品设计中追求尽善尽美并不是镀金,而是一种态度。

镀金强调的是不断的通过堆叠特性或无必要的外在装饰,而追求美的设计只能通过减少特性来实现。最好的设计都是简洁的、功能明确的、易于测试的。即便对其进行修改,也不会带来新的麻烦。它会让你觉得没有比这更好的方式来实现产品的功能了。

 “美到极致不是增无可增,而是减无可减。”------Antoinede Saint-Exupery

4.2尽早修复那些低质量的数据

随着时间的推移,系统中存储的数据会因为变更的不断发生而导致质量下降,通常这类问题会拖延至无法修复的程度,然后再来一次成本高昂的“全面整理”。

对底层来讲,数据修复意味着逐个核对并改正错误的数据,而消息在传递到组织高层时被美化了,高层会认为数据修复是通过某种很巧妙的手段将错误的数据一下子就改正过来,所以我们在发现问题产生的时候总是倾向于去修复软件而不是数据本身(因为数据总是多的可怕,而软件总是易于修复的),最终,资源被投入到了“更巧妙”的方式上,比如变更软件的某种处理方式,但修复软件带来了更多的变更,因此导致数据质量进一步下降。

所以,数据质量降低的问题一旦被发现,就应该在第一时间进行修复,否则将积重难返,未来会付出重大的代价。


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


【读书笔记】关于项目管理的一些思考 ——对《项目百态》的理解(二)


2.人是一切的基础

2.1 让团队参与招聘

招聘是需要团队合作的项目。无论招聘什么职位的人员,寻找一个真正合适的人从来都不简单,但往往又很重要。

对于招聘,大多数公司是这么做的:HR找人,约人,第一轮面试,应聘者的未来上司进行第二轮面试,然后决定是否聘用此人。不过,如果想要打造一个以团队合作为价值核心的组织,或许可以考虑让团队的成员参与其中。

初步筛选仍是需要的,或许是HR,或许是经理,或许是团队中的某个核心成员,比如技术最强的那个,或许是以上方式的组合。通过筛选的应聘者接下来将面对整个团队,团队成员作为面试官对可能在未来成为同事的人进行提问,甚至让应聘者暂时加入团队一起工作几个小时,最后大家一起决定是否接纳应聘者。也许团队成员都认为不错的人会因为经理出于其他考虑最终进行了否决,但一个团队成员都不认同的人,很明显经理没有任何理由去雇佣他。

以上的做法至少有以下几个好处:

1.当前团队成员绝对不会被迫接受自己不愿意与其共事的人,他们有否决权。

2.应聘者能更加了解团队,他可以接触到未来的同事而不仅仅是老板,也可以了解真实的工作情况,感受公司的文化。

3.经理可以借鉴团队对应聘者的评价而不仅仅依靠自身的揣测,同时他也会知道团队在一定程度上接受了新员工,而这意味者个人在领导和管理方面的成功。

4.作为整支团队,成员在参与同事预审的过程中可以向其他人学习,参考其他人使用的问题和标准,即“我的同事究竟在意哪些方面”,这有利于未来自己在团队中进行调整,还可以在以后的面试中把这些派上用场。经理也能对自己的成员的思维方式有更深的了解。 


2.2 年轻人能带动整个组织的节奏

年轻人可以使组织变的更有活力,更愿意学习和提高。

从成本上看,雇佣年轻人的成本较低,但培养的成本很高,不过,这仍然是值得的,除非组织已经放弃成长。


2.3 尽量把团队成员放在一起

面对面的沟通永远比其他手段要好,很多时候,一个眼神的效果好过一封描述详尽的电子邮件,因为那代表着信任。所以,应该尽可能的把团队成员放在一起,至少是需要频繁进行接触的那些成员。


2.4 记得设定人员储备

出于成本的考虑,组织倾向于使用最精简的人员组成团队,但是一旦项目出现意外,则很容易面对没有替补的状况。项目的损失是显而易见的,最重要的是时间的损失,特别是在项目的中后期,没有任何办法可以弥补这种损失,而如果有参与整个项目的替补队员的话(不需要深度参与),便可以迅速到位,给团队一个“用金钱换取时间”的机会。


2.5 专注才有生产力

对于雇主来说,支出的是员工薪水,购买到的并不是员工的时间(你不知道员工的时间利用率和使用效率)、能力(你无法对能力的价值进行评估)、忠诚(SB老板才会想要这个)诸如此类,你购买的是员工的“全神贯注”,即单位时间内最高的产出率。

为了保证你买到的东西的份量,你必须保证员工在工作的时候能够全神贯注。许多公司采取了一系列措施来保证这一点,良好的工作环境(消除对人不舒服的影响)、丰厚的薪资和福利(消除私人事件对工作的影响)、改进的流程(减少与产出无关的工作)等等。

对于项目来讲,特别是当组织有太多项目在同步进行的时候,还应该尽量避免将某个员工加入不同的项目组,工作内容和背景的切换将占据员工大部分的时间和精力,而这些是无法产生任何东西的,只会被无端端的消耗掉,因此,如果有可能的话,让员工专注于一个项目。


2.6 引导那些能干的员工

有的员工是这样的,他非常聪明能干,喜欢挑战,愿意帮助其他同事做一些他职责范围之外的事。这种人喜欢和大家一起并肩战斗,他热爱工作本身,而跟金钱无关。虽然他并不总是薪水最高的那个人,但薪水是无法激励他的,他也不会为了薪水而跳槽。

作为这种员工的经理,对他的管理很容易,但更容易犯错。通常一个员工很能干的时候,经理会倾向于把更多的、更重要的工作移交给他,而一旦工作变成一种负担,他就再也无法感受到工作的乐趣并最终会选择离开,公司也失去了最好的员工。能干的员工是很容易找到工作的,但组织显然很难找到一位如此之好的员工,所以最终组织失去的要更多。

对于这类员工,经理的角色就是引导他去从事他感兴趣的工作,帮助他排除工作以外的干扰,仅此而已。


2.7 那些越权的人或许是最宝贵的成员

工作中有3种事情:1、明确规定要做的;2、明确规定不要做的;3、无明确规定的。

经理在安排工作的时候,总是尽量避免任务重叠或冲突,也避免产生漏洞,但无可否认的是,要精确的限定任务的每一部分几乎是不可能的,所以那些无明确规定的事情到底由谁去做变成了一个问题。

有些人谨小慎微或中规中矩,他们只做那些明确规定要做的事情,这无可厚非。有些人不但做了明确规定要做的事情,还会去做那些无明确规定的事情,在他看来,为了完成项目,这些都是必须要做的事,甚至,他还会要求批准去参与那些明确规定不要做的事情(通常他们都会有极好的建议才会这么要求)。这类人是团队的宝贵资源。


2.8 团队内部的通用语

太多的项目失败是由于沟通产生的误解,因此,人们醉心于如何统一人与人之间的沟通方法,他们制定了术语表、发明了UML之类的东西试图让所有人对某一个词汇有共同的理解,但效果往往差强人意。

实际上,最好的通用语是在团队内部慢慢形成的,成员们一天又一天的重复某个话题,互相熟悉和理解对方给予某个词汇的定义,调整各自的语法和表达方式,最终形成团队内部的、每个人都理解的通用语。然后,他们会提炼再提炼,将这些定义固化。

因此,任何团队都不会一开始就存在通用语,试图复制其他人创造的通用语也注定失败,只有让团队自己进行磨合,才能有效的改善沟通,减少误解。


2.9 绩效考核总是粉饰过的

在由项目经理提交的绩效报告上,几乎所有人都处于“高于平均”的平均水平,没什么人特别拔尖,也没什么人特别差劲,整体看起来一切都很好。很显然,这是不可能的。

这是因为,即使经理按照HR的标准公正的进行考评,仍然会有意无意的得出错误的结论,比如,A员工的工作一团糟,团队又不可能在项目进行中减少人手或另外换人——那只会增加风险和成本——因此经理不得不将A的工作量调低,并把一些困难的工作移交至其他人,这样,A慢慢就可以将手头的比较简单的工作做的比较好了,也因此,A的绩效得到了提升,但实际上,我们都知道那并不代表他真的做的很好。

这种绩效评定的方式很容易产生不公平的现象:

首先,对于那些卓越的员工来说,你没有让他们知道他们到底有多优秀,他们看到的是,在考核结果上,自己与一群平庸之辈挤在一起,至少没有拉开距离。

其次,对那些糟糕的员工来说,你没有及早让他们知道他们到底有多差,也错失了弥补和改进的机会,有时候,糟糕的绩效并不意味着个人能力的问题,也许是因为双方对工作的理解有误。

最后,对那些中庸的员工来说,没有拉开距离的绩效使他们做出错误的判断,无法对自身进行改善,并且,由于处于中档的人数太多,自认绩效良好的人会认为自己被低估,自认绩效较差的人会认为自己做的已经足够好了。

 

无论如何,这种方式都会对员工的积极性造成大范围的打击,没有人从中受益。因此,如果必须要进行绩效考核,那就不要吝啬给卓越的人奖励,不要担心给糟糕人警告,基于实际的平均水准,讲出事实,对所有人都有好处。另外,如果要进行绩效考核,那组织就必须考虑如何对工作内容进行定级(重要程度、优先级、难度等)。


2.10 远程管理团队

越来越多的组织将团队分散到世界各地,而管理这些不同地点的团队带来了很多麻烦,虽然人们对于这种模式有不同的观点,但是无可否认,这种方式大大增加了沟通成本,带来了许多不必要的风险。以下一些建议对这种模式也许有用:

1.本地迭代。对于需要快速迭代的工作,最好还是由同一地点的团队完成。

2.做好生产率在最初会下降的心理准备,团队需要时间来适应新的合作模式。

3.认识到其他地点的团队与本地团队没有区别。他们同样喜欢富有挑战性的工作,而不喜欢仅仅被当作廉价劳动力。

4.树立各个地点的目标。让统一地点的团队有些精神上的追求和共同的目标(这一点无论对远程团队还是本地团队都是很重要的)。


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


【读书笔记】关于项目管理的一些思考——对《项目百态》的理解(一)

一直以来都很喜欢读Tom DeMarco的书,他的书很少有教条的理论,而是着重于对项目管理的本质进行剖析。前段时间看了《项目百态——深入理解软件项目行为模式》,总体感觉不错,适合想要了解软件项目管理、企业管理、软件工程的人员。本书并没有采用逻辑的结构阐述某个观点,而是将一些经验和理念分散到不同的行为模式中,让读者自己去发掘,这点比较有意思。本书还用大量的篇幅进行了组织文化方面的探讨,令人印象深刻。

本文是对书本的内容做一些回顾,对书中的观点加入了自己的理解,算一篇读书笔记,也算是对最近思考的一些总结。

1.需求是一切的源头

1.1把握真实的需求是一个艰难的互相学习的过程

虽然最终交付物的功能或性能指标全部满足,但如果最终用户反映产品“不好用”,那依然是个失败的项目,通常这种失败源自需求分析阶段的工作。

对于软件项目来说,用户交互是非常重要的一环,在范围界定时就应明确的反映出来,并持续给予关注,及时调整。这里的用户交互并非单指UI或UE,交互设计固然重要,但把握到用户“真正的需求”,即,最终产品如何与客户业务相结合,则更为重要。

头痛医头脚痛医脚看起来是最省心省力的,但资源的浪费也是最可怕的,同时,最终用户还不买账。集中精力研究真正的需求,解决真正的问题,结果才能事半功倍,否则,项目最终只会贴满创可贴并被人遗忘在某个角落。

如果希望项目最终产生正确的产品或服务,必须深刻理解消费者的需求和支撑那些需求的特性。这种理解只有当消费者和开发者各自向对方学习的时候才会出现,而最难做到的就是让所有干系人意识到同心协力互相教学的必要性。

我们都知道,在项目开始的时候就指望每个项目干系人能想象出最终产品的样子是不现实的,希望统一这些人的想法就更不可能。因此在搜集需求的时候,往往是一个团队和客户互相了解、互相学习的过程,但是,以下一些障碍会阻碍这个进程:

1.客户太过熟悉自己的工作,因此对某些细节视而不见--因为他们以为开发人员已经知道了。

2.客户也许不具备良好的沟通技能,无法正确或精确的表达自己的意图,也许会对不停的提问变得不耐烦。

3.客户在没看到实物的时候去想象自己到底想要什么东西是极其困难的。

4.事先签署的需求规格书会让客户背负责任,因此,他们不得不强行指定许多内容,以免遗漏了什么东西。最终,需求收集者退化成了抄录员,双方没有了探索性的互动。

5.营销阶段的解决方案很少能解决真实的、更高层次的需求,要知道,它不是真实的东西,它也只不过是想象出来的而已。

6.没有及早开始互相学习,等到干系人脑海中的想法已经定型,改变就变得非常困难,再去学习新的东西也越来越难。于是,项目失去了创新的基石。

1.2想探寻真实的需求,请尽早并尽快向客户提供原型

很少有人愿意从零开始,但大多数人都是不错的改良者,因此,我们应该尽早并尽快的树立一个稻草人让客户进行批判,甚至我们应该故意做出一些错误的东西来测试客户的反应,原型的作用是一种需求钓饵,让我们可判断客户重视的点在哪里,其设计哲学在于尽早犯错,频繁犯错。

原型会带来以下回报:

1.每次评审之后,如果我们都使用新的原型设计来替代掉旧的(重新设计原型),可能会得到更好的主意。

2.对原型不停的改进,最终或许会得到一个完美的设计。

3.原型或者就是客户需要的(别指望它会发生,如果发生了,一定是奇迹,如果是奇迹,就要小心了——你可能在其它地方犯错了。)

1.3小心范围蔓延——需求或特性并不是越多越好

Peter Keen的论文描述过这种现象:那些想要挫败新项目的人没必要冒着风险跳出来反对。恰恰相反,他们可以通过提议数十个能够“帮助项目达成卓越目标”的附加特性和改进措施,给项目以最积极的投票。

实际上,每个人都自然而然的认为自己的需求是最重要的,因此在项目中不断加入新的、无关痛痒的特性,而这些零碎加入的特性并没有考虑到产品的一致性,没有考虑如何去与实际的业务结合,并且这些特性的成本/收益未知。虽然这些建议看上去富有建设性,但这种行为增加了项目的风险和成本,间接增加了项目死亡的可能性:项目的目标开始变得不清晰,产品的定位开始模糊,项目成员对进度、变更做出决定的方式不一致,等到产品发布的时候,已经没有折中或挽回的余地了,最后只能将一锅大杂烩交付给客户。

这种情况的产生从本质上来说,是因为项目对于“什么是属于范围内的”以及“什么是超出范围的”没有客观定义,所以额外的需求很容易从不同的来源渗透进来。避免这种情况的发生需要做到以下几点,并且团队的所有人都应该培养这种意识:

1.尽可能早的,干脆利索的定义项目目标和非项目目标。

2.声明项目范围,并以“精确定义输入/输出数据”的形式时刻保持更新。

3.拒绝那些对目标没有积极效应而又明显超出项目范围的需求。

4.遵循变更流程,对新加入的需求进行评估。

另外,采用迭代方式并经常进行特性评估的团队能够在一定程度上避免出现此类情况,因为每次评估会强制重新排定特性的优先级。团队可以选择一些具备高优先级的特性加入到项目中,另外一些会被暂时搁置到下一次评估或直接放弃,一直到列表中只剩下成本高于收益的特性,这个时候项目或许就可以宣告完工了。

1.4最终兵器:找一个关注产品和业务结合的人

很多项目失败是因为缺少一个人专门负责并确保最终的业务流程——从用户的角度来看——尽量顺利地开展。

所以,项目中需要存在这样一个人:他不需要为预算或计划负责,只关注产品如何与目标环境交互,特别是产品与最终用户的交互。他负责用户体验的一致性,并且这种工作贯穿整个项目的始终。这个人关注的是整个项目对于客户而言的最佳的结果,一直到最细微的细节。他可以不是团队内部的成员,也许是客户方的人员,但只要有一个人不断的询问子项目之间的协同状况,就足够了。


===============

其它章节

关于项目管理的一些思考——对《项目百态》的理解(一)

关于项目管理的一些思考——对《项目百态》的理解(二)

关于项目管理的一些思考——对《项目百态》的理解(三)

关于项目管理的一些思考——对《项目百态》的理解(四)

关于项目管理的一些思考——对《项目百态》的理解(五)

关于项目管理的一些思考——对《项目百态》的理解(六)

关于项目管理的一些思考——对《项目百态》的理解(七)


【读书笔记】《learn more,study less》

这本书的内容并不多,秉承了老外一向的传统,把一些人们日常在应用的手段总结成一个一个的技术,看起来林林总总,其实有用的并不太多,对于我来讲,比较有提示性的内容包括:

 

1.       在不同知识体系之间建立联系。有助于理解知识的原理和结构,比如,如果在同时学习时间管理和项目管理的话,就会发现两者之间存在许多相似之处,通过比较,可以总结出两者的相同点和不同点,有利于加深理解和记忆。

2.       知识的拓展。也就是在学习的时候需要具备独立思考的能力,所谓“尽信书不如无书”,在理解了作者的观点之后,要广度和深度上探究知识点的来源、背景、内部关系和外部关系,诀窍在于多问“为什么”。

3.       知识的应用。如果学了知识但毫无用武之地,人们学起来就没兴趣,无法实践也造成知识体系不完善及产生错误,而且很容易便会遗忘这些知识和技能,因此要“学以致用”。但在这之前,首先要搞明白自己的生活和工作到底需要哪些知识。

 

至于后面的如何提高效率和培养习惯之类的已经是烂大街的内容,这里不再总结。

【读书笔记】《把时间当作朋友》

刚刚看完了李笑来的《把时间当作朋友》这本书,会去读这本书是因为看了他的《人人都可以用英语》,对我学习英语帮助不小,觉得他写时间管理该也不会差到哪里去,便抱着偷懒的态度读一读(为了逃避去看《敏捷项目管理指南》-_-!),没想到一路看下来,收获颇丰。

书只有两百多页,因为不是专业书籍,读完大概只花了不到20个小时。书名里虽有时间两个字,但关于时间管理的内容只占整本书的一小部分,并不是我想象的那种专讲时间管理的各种方法和工具的书籍。整本书更像是在阐述关于个人提升的“道”,而非时间管理的“术”。正像序言和补记中讲的,这本书花了很多篇幅向读者强调“心智的力量”,它所讲的“心智”并不是《秘密》里面所说的那种具有强烈唯心主义论的“心智”,而是通过正确的逻辑推论向读者说明“人不能控制时间,却可以控制自己”这个道理。

书中讲了很多关于珍惜时间、独立思考、持续学习的重要性,其中有许多道理是自己之前从未思考过的,比如如何正确的认识自卑和自负、如何衡量时间、怎样理性的控制自己、如何使自己更具耐心、凡事提前准备的好处等等。在读完整本书之后,读者会明白,所谓的时间管理,其重点并不在于运用什么样的工具、方法和技巧使时间“看起来变的更多”,而在于,人需要不断的提升自身的修养和能力,才能让自己的时间变的更有价值。从这点来讲,为了让自己的时间具有更大的价值,就必须去做具有实际意义的事情。读一本书、写一份报告、给亲朋好友打个电话、背几个单词都比把时间浪费在那些让自己看起来很忙但却毫无意义的事情上面要好的多。时间是公平的,对任何人来讲,每天的时间都是一样的,时间的流逝速度也相同,如果能够充分的利用时间,无疑等于比那些不善利用时间的人拥有了更长同时也更丰富的人生。

回想自己过去的30年,已浪费了太多太多时间。曾经沉迷于游戏、享乐、甚至是拼命搜集学习资料这些无谓的事情当中,仅仅是为了获得那种虚幻的满足感,却没有一件事情是真正坚持下来的,时不时为此懊恼不已,但又转头就忘。所幸结婚之后(感谢Amy!),开始慢慢思考起自己的人生究竟想要怎么样过,也为此做过一些努力,学习了不少东西,现在回过头去看,还是远远不够的。每次看到自己学习资料的文件夹足有100多G,买的书大部分都还没看,就只能感叹人生太短,要做的太多。

在女儿来到这个世界之后,生活压力随之增大,责任感和紧迫感也越来越强烈,却是人生中最充实的一段时间。做了人生规划、制定了学习目标,按照计划一步一步执行,虽然距自己的理想状态还有差距,但已经可以感觉到自己的进步。学习给人带来的满足感是令人愉悦的,甚至还伴随着优越感,看看自己周围那些无所事事、整日抱怨的人,就会觉得自己至少在精神上还不算贫瘠。

珍惜时间,增强心智、培养耐心、努力提升和完善自身,若是能够坚持做到这些,接下来的路会更有意义吧,我想。

显示更多内容