工作目标(POS)梳理5W1H法：

结合IT项目可做如下的对照：

1.要做什么或不做什么(What)- 需求定义

2.为什么要做(Why) -项目的提出背景

3.何时完成(When) -项目的时间要求

4.需要什么资源(What Resource)-项目依赖的资源

5.在哪里做(Where)-项目的合作方式

6.如何评价(How)-项目的验收的里程碑

项目目标（POS）满足的SMART原则:

1.Specific(明确的)

所谓明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可，或没有将目标有效的传达给相关成员。

2.Measurable(可测量的)

衡量性就是指目标应该是明确的，而不是模糊的。应该有一组明确的数据，作为衡量是否达成目标的依据。如果制定的目标没有办法衡量，就无法判断这个目标是否实现。

3.Achievable(可实现的)

目标是要能够被执行人所接受的，如果上司利用一些行政手段，利用权利性的影响力一厢情愿地把自己所制定的目标强压给下属，下属典型的反映是一种心理和行为上的抗拒：我可以接受，但是否完成这个目标，有没有最终的把握，这个可不好说。一旦有一天这个目标真完成不了的时候，下属有一百个理由可以推卸责任：你看我早就说了，这个目标肯定完成不了，但你坚持要压给我。

4.Relevant(相关的)

目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标，但对其他的目标完全不相关，或者相关度很低，那这个目标即使被达到了，意义也不是很大。

5.Time-bound(时间限制的)

目标特性的时限性就是指目标是有时间限制的。没有时间限制的目标没有办法考核，或带来考核的不公。上下级之间对目标轻重缓急的认识程度不同，上司着急，但下面不知道。到头来上司可以暴跳如雷，而下属觉得委屈。这种没有明确的时间限定的方式也会带来考核的不公正，伤害工作关系，伤害下属的工作热情。

四象限法

项目管理9大领域

项目三个目标

时间、成本和质量，对应的就是"快好省"。

1. 时间：项目计划在什么时候完成？有哪些工作，分别在什么时候完成？是否发生了偏差？如果有偏差，怎么处理？

2. 成本：项目计划花多少钱？每项子任务分别打算用多少钱（多少人月）来完成？是否发生了偏差？如果有偏差，怎么处理？

3. 质量：软件功能完整吗？软件操作方便吗？运行结果正确吗？运行效率够快吗？软件代码符合规范吗？客户用起来满意吗？

5）项目管理方法

1. 以客户为中心

2. 以目标为导向

3. 以计划为基础

4. 以控制为手段

6）打造"凝胶型"团队

在这样的团队中，大家有着清晰的共同目标，彼此合拍，每个人都是全身心的投入，每个人贡献自己全部的智慧和力量，团队显示出超强的战斗力。

"凝胶型"团队可以分两种，星形和网格型：

理事的原则

1）项目执行的常见误区

1. 目标不清

2. 不能坚持目标

3. 抓不住重点

4. 拖延症

5. 只管项目整体，对细节不知

6. 盲目求快

7. 无效沟通

2）重要细节应问5个为什么

"连问5个为什么"的工作方法，可以用来问自己，刨根问底，分析项目中的潜在问题。

例如"总体目标达成情况"，"团队士气如何"，"有哪些潜在的风险"，"软件总体质量如何"......

3）项目执行为快不破

抓住重点的20%，也就是"二八法则"。注意以下问题：

1. 重点处理客户的核心业务需求

2. 将核心人员用在核心问题上

3. 面对问题时，要分析主要因素，并加以处理

4. 将大部分时间处理少部分重要的工作

4）打造团队执行力

1. 有效沟通，在沟通中经常会出现失真的情况，导致理解出现偏差

项目管理中的迷雾

其实胸有成竹只是一种表面现象，就好像一座冰山露出水面的部分，水面以下还有庞大的支撑。

1）响应变化重于遵循计划

变化的原因可能是因为计划不周导致的。例如XX项目中，有个咨询专家的功能，客户端展示的像一个聊天界面，后台的回复页面却不像聊天一样有历史记录，这样导致人员在回复的时候，不清楚过去聊了些啥。当初设计这个咨询，仅仅是一个反馈的结构，并没有考虑到后面会变成聊天模式，设计上的一个缺陷，后面只能返工修改。

出现的原因有以下几点：

1. 经验不足或过分依赖经验

2. 考虑不周，所谓"百密必有一疏"

响应变化重于遵循计划有2个重要思想：

1. 拥抱变化，而不是追赶变化。应对变化，高声呼唤"让暴风来的更猛烈些吧！"

2. 计划中应包括如何应对变化

3）滚动计划以适应变化

项目执行中会出现意外情况，产生偏差，有些可以修正，有些无法弥补，这时候就根据实际情况来"修改路线"。注意以下2个问题：

1. 要随时评估项目，要时刻有一副如何到达目标的地图。许多次小的变动可能让你的地图失效。

2. 思考变更的原因与必要性。需求变更通常是客户提出的，而客户的想法有时候不是深思熟虑的，我们就得帮助他们想透彻、理清楚。

滚动计划有2个方面的内涵：

1. 计划需要认识的加深而修改。在项目启动的时候就要做计划，即使需求没确定，其实需求调研需求分析也是计划的一部分。

2. 近期计划细致些，远期计划粗略些

4）在现有的资源下做出成绩

1. 把项目组调动起来，充分挖掘，在不影响项目把控的情况下亲力亲为。

2. 用好现有的资源，用好每一个人。首先要把事情理清楚，让大家明明白白的做事。

5）怎样对待需求变更

1. 需求没变，是我们对需求的理解在变。也就是我们没有理解清楚客户的需求。

2. 管理需求，减少变更。深入挖掘需求，不要停留表面，需求评审不可少。

3. 变更流程要书面化正规化，提出申请、评审（是否有必要变更、是否有替代方案、对其他功能影响等）、跟踪（监控评估变更的效果，避免产生新的问题）