导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:954841
  •  

2007-9-28 20:31 | [原创]项目简要总结

关键字:IT项目经理

过程无法让你成熟,过程是帮你发现问题,通过团队和自我学习走向成熟。

过程和结果谁重要,着眼于短期利益结果重要,但基于长远专业化发展必须注重过程得规范和积累。

强调过程不是扼杀个性,正如强调法律是为了获取更大的自由。

1.项目进度和周期

估算,变更和未知风险对项目进度有重要的影响
项目大多数任务的粒度周期应该为项目周期的10%-15%
在项目前期跟踪频率适合为项目周期的10-15%,后期适合为5-10%
在发现进度偏差后要选择根源而不是仅仅应急的解决偏差

2.缺陷和Bug的密度

系统测试阶段的Bug密度为3-5个/KLOC代码比较适宜。
对Bug的分析很重要,应该转换为后期的培训和规程的完善。
Bug本身也有质量,对Bug本身质量的关注应该多于对单纯缺陷密度的关注。

3.缺陷泄漏和缺陷移除

需求缺陷的泄漏和发版后的泄漏故障是两个重要的关注点。
对缺陷泄漏的关注应该多于对缺陷密度本身的关注。
COPQ是重要的考察指标,当COPQ和估算差距不大的时候说明缺陷移除较好。

4.需求变更情况

需求变更引起实际工作量增加才是一个重点考察指标。
用户需求挖掘,非功能性需求,业务规则是最容易引起需求变更地方。

5.开发生产率

编码生产率在250-300行/天。总生产率在100-150行/天。
统一开发模式和框架,能够复用的全部抽取为黑盒复用是形成组织PCB基础。

6.软件产品的规模

规模是整个估算的基础,规模估算不准确直接影响到总体工作量估算。

迫切需要统一需求用例编写的粒度,形成可用的规模数据。最近改进中已经形成以用例总流数作为规模的改进。

7.评审的作用

对可设计和实现性评审比较好。但对于可测试性和非功能性评审需要加强。
评审是从多角度看问题,重点是发现遗漏,而不是帮作者解决责任心的。
缺陷的泄漏情况是评审是否有效的关键指标。
要在……
编辑 | 阅读全文(1986) | 回复(0),人月&神话 发表于 2007-9-28 20:31
关键字:IT项目经理

对于特定的招标型项目,用户需求一般会体现在SOW工作说明书或招标相关文件里面。用户需求是从用户期望角度出发,提出的为了解决用户实际问题而提出的产 品在功能或非功能上应该具备的各种特性。对于IT项目,最好是在项目启动阶段就已经确定好了用户需求,用户需求是软件项目范围的重要输入,在项目计划阶段 或执行阶段还在确定用户需求必然会存在范围蔓延或镀金的问题。项目范围不明确和不受控是导致IT项目频繁变更和延期的重要原因。

1.用户需求和产品需求的关系

用户需求是从特定用户角度出发,而产品需求则是从推出通用化的产品出发,这是两者最重要的区别。不考虑产品需求,不从产品通用性出发会导致项目最终产品只 能满足特定用户需求,完全是一单子买卖,首先是导致产品营销范围狭隘,同时也不利于推出通用化的产品,形成企业的核心竞争力。

用户需求需要向产品需求转换,转换的重点就是考虑用户需求的共性,考虑如何使产品每具备一个功能特性就能够满足更多的用户需求。用户需求收集->分 析和归类->该需求的根源->抽取共性->形成产品需求,通过这种方式形成的产品需求有利于后期产品的通用化。我们在软件产品开发过程 中使用一些框架,公用组件,分层等各种架构要素目的正是为了满足产品的可扩展性和配置性,而不是单单满足当前的用户需求,虽然这样在软件开发过程中可能会 花更多的工作量,但投入的成本是完全值得的。

2.用户需求和软件需求的关系

用户需求通过分析,开发和挖掘后形成软件需求。用户需求和产品需求就已经确定了产品范围,软件需求开发属于项目执行阶段的工作,其重要的输入就是产品的范 围。用户需求是从用户角度,而软件需求更多是从系统实现角度考虑。用户需求回答我要什么,而软件需求回答系统通过什么方式,途径提供给用户你需要的。

需求挖掘和开发是软件需求要解决的重要事情,用户需求提出的需要什么背后隐……
编辑 | 阅读全文(1893) | 回复(0),人月&神话 发表于 2007-9-28 20:30

PMBOK知识体系将团队组建放在了人力资源管理中执行阶段,如果真是在项目执行阶段才组建团队则为时已晚,项目执行过程是要按项目目标完成交付物,而不是用于团队的组建和磨合。什么时候开始团队组建?应该是越早越好,但有个前提,就是根据项目的目标以及根据你要开发的产品,已经明确了你需要什么样的团队成员。

系统性的描述团队组建的文章很多,在这里仅仅从一些团队组建关注点出发谈谈自己的感受。
 
1.团队需要什么样的人
 
团队需要什么样知识和技能的人员是团队组建前的必要条件。如买卖双方的交易一样,项目在选择团队成员,项目成员也在选择项目和项目经理。所以团队组建前搞清楚你需要的什么样的人后,还得搞清楚你或团队能够带给项目成员什么?只有双方真正获益才可能组建高绩效的团队。后期在团队建设中讲的规则,奖励或惩罚才可能真正发挥作用。如果找的是把项目作为临时垫脚石,或仅仅是为个项目的名给自己镀金的人,这样的项目成员根本就不会把项目当一回事,再怎么制定各种规则都无济于事。
 
其次,招募的团队成员是否有良好的职业精神,勇于承担责任,积极学习的心态更加重要。缺乏的知识技能可以学习,但良好的职业精神,工作习惯和价值观却不是短时间能够学来的。成员可以有自己的工作和学习方式,但勇于负责,做一件事情就把它做好的态度则对谁都是一样的。
 
团队需要什么样的人?现有知识技能匹配,学习能力,职业精神三个方面是最重要的。如果要排序则是职业精神->学习能力->现有知识技能水平。不要讲组建团队看做一个短视的行为,如果要打造长期的有战斗力的团队,这个顺序至关重要。项目后期团队建设中出现的诸多问题往往正是由于前期团队组建中的只考虑眼前利益造成的。
 
2.如何招募到你需要的人
 
招募一个团队成员是一件谨慎的事情,外企的招聘往往会经历多轮的笔试和面试,……
编辑 | 阅读全文(2006) | 回复(0),人月&神话 发表于 2007-9-25 22:28
关键字:IT项目经理

适合刚接触项目管理阅读,也适合作为项目管理参考书,该书网站提供了大量的项目管理模板可以下载。

编辑 | 阅读全文(2663) | 回复(26),人月&神话 发表于 2007-9-22 22:43

项目经理接受委任后,个人认为最重要的一件事情就是进行干系人分析。或者讲在启动前或被委任前就应该进行干系人分析,很简单的道理,比如高层管理都对项目不支持,项目经理再有能力也无法使项目实现目标。

干系人是对你项目的目标达成有影响的所有人,如果要关注项目开发出的产品所带来的长期效益,则干系人应该是对项目所开发的产品的整个生命周期都有影响的所 有人员。干系人的识别,干系人分析都不是干系人管理的最终目标,最终目的都将落到项目经理如何利用分析的结果,通过自身所拥有的资源,技能,沟通等去影响 干系人的行为,以达成项目的目标。

1.项目的出资方和赞助人

对于赞助人始终关注的如何使自己的投资有最丰厚和深远的回报,同时又将风险控制到最低。 跟个人投资是一个道理,投多少钱不是问题,关键是如何保证投入有低风险,稳定和客观的回报。因此赞助人不仅仅关注项目本身是否成功按目标完成,而是关心产品能否成功按计划推入市场和创造效益。

对于项目周期较长的时候,为了项目本身降低风险和满足干系人预期,项目迭代开发就显得更加重要。迭代开发可以保证将项目分为多个迭代周期,每个迭代版本都 是可用的而不是一个半成品,项目最终交付成果会分为多个迭代版本交付,赞助人可以尽可能早的看到项目所创造的产品或成果。同时采用迭代开发每个迭代版本都 可以尽可能早的投入市场和进行市场推广,资金不用一次性的全部投入,可以通过市场的反馈不断的纠正方向和需求。

2.项目高层领导

高层领导一般是期望项目取得成功的,但高层领导关注的是PPM(项目组合管理),因此项目经理一定要清楚在多项目,自己的项目在高层领导眼中的优先级和地 位。明白了这点才能够分析在多项目资源冲突的情况下,自己的项目如何去通过高层领导协调更多的资源。项目经理需要让高层领导更加了解自己的项目,需要及时 准备的定期反馈和汇报项目进展,当出现资源问题时候需要有说服力的……
编辑 | 阅读全文(2460) | 回复(0),人月&神话 发表于 2007-9-22 22:23
关键字:IT项目经理

是否是项目立项审批通过就代表项目启动?真正的项目启动应该包含三个方面的重要内容,一是项目或产品初步范围已经确定,二是项目的目标已经确定,三是已经选择了委任了项目经理。如果安装PMBOK的说法,这几个方面的内容都应该在项目章程中得到体现。项目章程也可以简化到项目启动会议既要,但关键点都在于项目经理确定,并给予了法定的正式权力。



1.项目经理的选择和委任


在高层领导支持,项目目标也明确的情况下如果项目还失败,项目经理应该负完全的责任。项目经理也可以选择是否接受项目,但一旦接受了就应该对项目的成败负责。


选择项目经理无定法,仍然关注平衡。如果是已有项目团队,团队成员技能都很强,那项目经理重点是团队建设和资源整合。如果团队技能弱,但责任心和态度积极,那项目经理必须是技能强,必须是一个能够传授知识的好教练。关于项目经理知识和技能层次,原来有文章阐述过,在这里不再多谈。两个关键点就是项目成员愿意和你一起把事情做成功,另外一个是你能够使项目成员有能力把事情做成功。
高层管理或者说PMO如果愿意在项目经理选择上多花些时间,完全是对产品和项目负责任的态度。基于强矩阵或项目型的组织中,高层管理要能够轻松,就是其下一层的项目经理能够真正管理其整个项目团队,项目中99%的问题都能够由项目经理解决。在这种金字塔型的权力型结构中,取决定性因素的不是塔尖,也不是塔底,而是中层。而项目经理正是这种结构中的中坚力量。


2.项目目标


不要简单的把项目目标理解为进度目标,项目目标必须要包含进度,成本和质量三方面的目标。否则我们虽然按时完工的做出来的产品可能无法卖出去,或者预审超支。在这种情况下项目仍然是失败的。


项目目标是如何确定的?是根据项目可研和项目立项后确定的。确定项目目标是为了保证我们最终产出的项目成果能够赢利,能够为企业或客户带来实际的价值。很多时候项目经理不会考虑为何要制定这样的目标,只知道是高层制定的,项目按照……
编辑 | 阅读全文(1102) | 回复(4),人月&神话 发表于 2007-9-18 21:33
关键字:IT项目经理 立项

最近在看漫索公司林锐博士的相关培训ppt,从最早推出的CMMI三级精简并行过程SPP,到现在的RDMS产品,还是很多值得借鉴的地方。今天先看下项目立项管理:
 
 
1.立项管理的重要性
立项管理应该说是新产品研发管理的或者说IPD的一个重要内容。人在江湖,最怕的就是跟错人,站错队;而对于企业最怕的就是战略性决策和方向选择的失误。项目管理中的项目计划是保证实现项目的目标,而立项管理正是去确定项目的目标,现在竞争如此积累,立项决策是否正确直接导致整个企业的成败。
 
项目计划是保证如何做成功的问题,而立项是要解决做什么的问题。你需要开发的产品,不管什么客户需求出发VOC还是产品核心竞争力,唯一关注点就是效益和利润。这个问题展开就是前期需要投入多少?能否盈利?什么时候能够盈利?能否持久的盈利?整个立项报告的内容都将围绕这些核心内容展开。
 
2.构思->调查->可行性研究
 
这里把构思放在第一位太重要了,在《像外行一样思考,像专家一样实践》这本书已经提到过,我们是无法去穷举我们想做的事情和所有做事情的方法的,唯一可以采用的就是先根据自己的经验构思或假设,再去证明构思的正确性。
 
构思的目的就是提出假设,能够提出好的构思的往往是有丰富经验的人,他们有很好的前瞻性和敏锐的市场洞察力。有了构思需要去证明构思可行,而最有力的证据就是数据,拿数据来说话。因此在可研里面必须要先看到这样的步骤:
 
现状分析->数据收集方案->数据收集->数据分析和预测->财务成本效益分析
 
步骤都知道是这样,真正的难点却在于你要开发的新产品……
编辑 | 阅读全文(2556) | 回复(3),人月&神话 发表于 2007-9-18 21:26
关键字:IT项目经理

1.在对客户的访谈还没有完成之前就开始计划和行动


由于巨大的压力,项目团队面临着在一个详细的项目计划没有完成之前就开始项目活动.这将导致大量的困难和错误,不仅花费了时间和金钱,而且还使整个项目团队都感到沮丧.

原因分析

在没有对客户和项目赞助商有一个详尽的访谈就开始计划和行动的原因,主要体现在以下三点.

第一,在美国文化中我们已经用持续计划替代了活动这个词,这就意味着为了表示我们已经开始执行项目,我们期望我们的所有发生的活动都是有记录的,即使当时 还没有开始计划.除非项目经理和赞助人能够意识到计划之前必须完成对客户的详细访谈,并且制定精确的目标,否则我们将持续的进行着模糊的计划,而这样的结 果就是导致大量的返工.

第二,没有人愿意花时间来了解商业目标和项目目标.这就意味着项目团队面临着还美元理解项目真正目标就不得不在项目执行中才开始计划.在项目执行过程中不 断的计划这种方式决定不是一种能够充分利益人力和其它资源的高效方法.在大多数情况下,都会导致项目延期,预算超支和大量无法达成期望事情.

第三,项目经理和项目赞助人没有真正看到在项目开始前搞获取到所有客户需求信息的益处.一些项目经理经常受到喜欢把各种信息分解成相互孤立和分散的小块, 而不是整合的一大块来看待的文化熏陶,这就意味着,大多数的项目都是仅仅为了实现短期或片面的项目目标而计划和执行,而理解到整个项目最终完成应该达到如 何目标.

访谈和调研的必要性

为了完整的理解整个项目的目标和愿景,访谈客户是最佳的方式。除非项目经理或赞助人在这个领域有充足的经验和知识,否则将导致项目的周期或成本都超过预算,而且导致大量的返工。在项目正式开始前,提前做充足的客户访谈和调研将确保我们真正理解项目的目标和客户预期。

2.依据少得可怜得项目信息进行至上而下的计划

项目计划的责任始终都是每次研讨会的热点讨论……
编辑 | 阅读全文(2021) | 回复(4),人月&神话 发表于 2007-9-16 18:16
关键字:IT项目经理

INTRODUCTION

BASIC PRINCIPLES
Ten Axioms for Success
Scope Triangle
The Critical Path
The Mythical Man Month

SCOPE
Scope, Visions and Goals
Requirements
Requirements capture
Documenting Requirements
Traceability

PLANNING
The Purpose of a Project Plan
The Fine Art of Scheduling
Costing and Budgeting

Risk Management

Change Management
EXECUTION
Staying on track
Managing People

IMPLEMENTATION

REVIEW

GLOSSARY

编辑 | 阅读全文(16445) | 回复(329),人月&神话 发表于 2007-9-16 18:11
关键字:IT项目经理

* Justify the project by building a strong documented business case.
   
* Understand the key business drivers of your business.
深刻理解你的商业目标,项目管理前必须清楚为何做,才能为目标努力

   
* Get buy-in and support from top management; i.e., make sure to have a strong sponsor.(高层管理支持)
   

* Be specific about requirements and state them in a way that makes it easy for vendors to respond and think along with you.(需求明确定义)
   
* Avoid reliance on new, unproven technology.
(避免依赖新的,没有证明过的技术)
   
* Ensure the vendors can meet their commitments.(保证供应商履行承诺)
   
* Ensure your organization can meet your own commitments.(组织履行承诺)
   
* Clearly communicate project team roles and responsibilities.
(清楚的沟通项目团队各成员的角色和责任)
&nbs……
编辑 | 阅读全文(2413) | 回复(3),人月&神话 发表于 2007-9-16 18:4
关键字:IT项目管理

1.以目标导向来做事情


首先要明白该做什么,其次才是如何做。目标是项目管理的重要特征,项目经理做事原则都是围绕项目目标展开,对于有利于项目目标达成而又不违背项目经理职业道德和行为准则的事情都是该做的事情。

目标有短期目标和常用目标,把当前项目按目标完成可能是短期目标,通过一年时间带出一个高效的团队可能是一个长期目标。对于非临时项目的项目经理,更加应 该着眼于项目长期目标,而不是太在意于当前项目的短期利益。只有意识到这点,才能够认识到培训,教练,团队,自发,团队语言和规则等在整个项目中的重要 性。

2.对自己定义的目标进行分解

对于软件项目,项目经理根据商业或用户需求会定义软件产品发布后的故障率小于0.5个/KLOC代码。要达到这个目标就需要结合项目的时间过程分析影响该 目标的要素,各个阶段交付物的质量,缺陷的泄露,测试的水平,需求的变更和稳定性,前期的需求设计和开发规范,团队规则,开发人员的责任心多方面因素都可 能影响到该目标的实现。

一个总体目标的达成绝对不是简单的改善一项影响要素就可以达成的,而且各个要素间还存在这正反作用,必须要综合性的系统思考。确定出期望的各个要素的区间 水平,然后将这些期望值列入到计划中进行跟踪和控制。这一系列的过程要表明的都是你做的每一件事情都是有目的的,都是为了实现当初定义的目标而服务,绝不 是无中生有。

3.具体实际操作的关注点

首先对于风险和危机的重视度远大于对问题的重视度。不是说问题解决不重要,而是项目经理应该更多的管理风险和消除隐患,不让风险转换为真正的问题。项目经 理必须有足够的问题前瞻性和敏锐的洞察力,发现各种征兆和危机,危机发生前应对往往仅仅是项目经理找成员谈谈心,或者说组织一次关于规程的培训,但危机如 果发生造成的损失会远远大于风险应对的成本。

项目经理应该更多的取做教练,而不是去做领导。管理者要懂得授……
编辑 | 阅读全文(3884) | 回复(7),人月&神话 发表于 2007-9-13 20:53
关键字:IT项目管理

Project Scope Is Not Defined On PowerPoint Slides


项目范围不是定义在ppt幻灯片中的(说明项目范围必须得到明确的定义,通过范围说明书,WBS和WBS字典对项目范围进行准确的定义,项目做的任何事情都应该在项目范围内)

Project Schedules Do Not a Project Plan Make

一个项目计划要做的不仅仅是项目进度表

Projects Are Not Managed From Behind a Spreadsheet

Some project managers secretly want to be statisticians. They love to calculate all of the various metrics pertaining to their project such as the percentages of deliverables completed, tasks currently on schedule, tasks that should have started, of variance from budget, etc. These are all good to know. The problem is that they spend so much time summarizing and restating data in their spreadsheets, they never talk to the team members about how the project is going and what problems they are having. Without that connection with the team, th……
编辑 | 阅读全文(2311) | 回复(1),人月&神话 发表于 2007-9-13 20:51

项目跟踪控制的目的是保证项目目标的达成。项目周期是重要的项目目标,因此进度控制是重要的监控内容,同时软件产品的质量,成本等也应该根据当初定义的目标进行监控。否则到了时间点,产品完成了但质量和成本都达不到要求,仍然是失败。

有监控但项目仍然延期,或者说仍然达不到当初定义的质量和成本要求,原因何在?只跟踪不控制,只发现问题不找寻根源和解决问题,只应急处理问题而不是提前观察各种征兆是监控中最常见的现象。


进度跟踪中发现进度偏差的根源分析


1.任务本身的估算问题

任务本身的工作量估算是否合理?进度出现偏差首先要考虑的工作量的估算是否合理,是否考虑了工作中存在的技术难 点,是否考虑了项目成员自身的技能,是否考虑了其它应该考虑的风险。任务计划下达给项目成员时候应该获取承诺,但很多时候获取承诺是无用的,是否可以承诺 或者是否能完成承诺跟项目成员的个人经验和技能有太大的关系。

当偏差出在估算上,而且后续项目都是采用的相同估算模式的情况,调整项目计划往往是必须的了。对于短期型的项目,如果这个时候才发现是项目成员技能问题,而想通过培训来提高技能以取得立竿见影的效果往往已经是不现实的。


如果项目任务中存在着技术攻关或技术难点需要解决,对于这种任务往往是很难估计工作量的,而且一旦在技术问题上被卡住往往对项目进度产生致命的影响。唯一 的方式就是把无法预测和不透明的东西转换为透明,在项目开始之前就应该进行风险分析和应对,提前进行技术问题的预研,开发原型,积累相关的知识和经验。


估算问题的根源又出在历史项目或版本对项目历史数据的采集和分析不够,准确的估算依赖于专家的经验,但专家的经验同样是依赖于历史项目和历史数据。估算问 题的根源还在于对项目成员技能和生产率水平没有较清楚的认识,一个软件类任务的完成往往存在着巨大的个人生产率差异和进度差异。


2.任务本身的粒度问题

对于一个软件项目,出现1……
编辑 | 阅读全文(2585) | 回复(3),人月&神话 发表于 2007-9-7 22:33

2007-8-30 22:40 | 时间管理-践行GTD

关键字:时间管理

关注了这么久时间管理,平时工作和学习中也在应用时间管理。时间管理最终要落实到行动上,只说不做是不可能达到目标的。GTD即是Getting Things Done,原来关注过GTD但一直没有深入去研究,GTD里面关注目标,关注任务,关注行动,关注步骤依赖,关注任务分解,关注效率和时间记录。如果把这些加起来完全就是一个小型的个人项目管理,所以把个人时间管理理解为小型个人项目管理是有道理的。

从项目管理角度有利于我们更好的去理解个人时间和行动管理。使时间管理从艺术和经验的角度转向方向和科学的角度。践行很重要,理论使我们知道如何做?但要做得更好,就必须提高效率,要提高效率则必须不断的实践总结,对方法,工具和步骤进行验证。找到最适合自己的方法。

虽然你可以在会跑后回头看走是如何简单,但在不会走之前是绝对不会跑的。虽然你最后可以无招胜有招,但必须经历有招的过程。

先整理褪墨网站关于时间管理和GTD内容,供后续学习。

关于GTD的个人网站:

生活帮(http://www.lifebang.com
褪墨(http://www.mifengtd.cn

GTDLife(http://www.gtdlife.cn


关于GTD工具
ThinkingRock软件(http://www.thinkingrock.com.au/download.php
)

关于GTD在线工具

易做网(
http://www.ezzuo.com)
易做网可以算是国内这一领域的先驱,作者受37signals影响,也用ROR构建了这个网站。网站功能完全按照GTD的思想来实现,突出工具性。 可惜现在因为各种原因停止开发了。

mindpin(http://www.mindpin.com)

刚刚上线的思维导图网站,用户可以根据样例和模板来生成自己的思维导图。同时引入了SNS的特性,可以建立"拼友圈&qu……
编辑 | 阅读全文(3644) | 回复(1),人月&神话 发表于 2007-8-30 22:40
从问题开始

先搞清楚问题的定义,问题定义两方面作用:一个方面是协助你去分析和解决问题(问题定义未书面 化),一个方面是提问的时候必须要搞清楚问题的定义(提问的智慧),问题定义包含时间,地点,人物,操作对象,操作步骤(人机料法环)。问题是你和你的期 望间的差距Gap叫做问题。所以这使我们在挖掘问题定义的过程中就发现有些问题根本不是问题(在细化问题定义过程中就解决了问题)。

问题定义还需要搞清楚这是一个普遍问题还是特殊问题,除了说明问题什么时候发生还有说明什么时候不发生。

问题定义例子分析:我今天的电脑无法上网了(请补充三个问题帮我完善我这个问题)

时间管理

不联系到事件、任务和问题管理,就没有计划和目标,没有计划目标就谈不上时间管理 的实际运作。我们看到一个任务或事件来了后,你的时间管理过程始终伴随着你对任务的分析定位和渐进细化的过程。时间管理要转到行动管理,行动管理即计划- >分解->收集->选择->行动->跟踪管理->总结,类似于PDCA循环。

GTD有个法则就是如果一个任务可以在二分钟内完成,那么代表这件任务必须马上完成。我需要把这 个法则扩展一下,如果一个重要的任务能在30分钟-1个小时内马上完成,代表这个任务必须马上完成。当两者冲突的时候,在时间Gap允许,应该优先重要事 情的完成。(场景:今天有20件事情我完成了15件,还剩余5件)

解决问题的方法和步骤

有哪些解决问题的方法(知识库,Google搜索,平时自我总结,降低自我预期, 提问,找寻协助,自我假设探索)。对于诺基亚的解决问题七步法(确认问题->分析问题->确认原因->需求对策->计划行动- >实施对策->评估结果)。确认原因也可以讲是确认根源,探索一个问题根源即本质是解决问题治本的方法。计划行动里面一个重点是问题到实施行 ……
编辑 | 阅读全文(2161) | 回复(5),人月&神话 发表于 2007-8-30 22:38
(共 973 条) 1 2 ... 8 9 10 11 12 ... 64 65 翻页至

仅列出标题