为了介绍立项文档的重要性，下面这篇文章详细介绍了微软的项目立项方法
专注：
- 我们可以少做事，但得把这些事做好，做的非常好
- 如果要列一份清单，就要把其中的条目排好优先次序
- 专注于最终用户
- 不要让用户感受到我们的组织边界
运用5个P工具在项目中实现专注：
- 目的（Purpose）：我们为何存在？我们要为用户交付怎么样的产品，有什么样的数字目标？
- 原则（Principle）: 有哪些规则与关键战略是没有商量余地的？我们的底线是什么？
- 优先级（Priority）: 当我们面临选择的时候该如何做决定？原则和优先级让团队有信心做决定，而不要事事征求领导意见
- 计划（plan）：我们该如何分阶段解决问题？哪些日期节点已经明确敲定，又有哪些功能必须按时间要求上线？
- 人员（people）：谁对计划中的各个关键部分负责？
目的
设定目的时可以回答以下一个或多个问题：
- 我们为何存在？
- 我们为什么要开展业务？
- 我们希望实现怎样的未来成果？
- 我们将交付怎样的方案？
目的的具体表达无关紧要，更重要的是凝练而准确的方向性结论。
原则
认同的原则应该在整个过程中明确传达给每一位参与者。原则在本质上就是所有人应该遵循的规则。
- 项目中存在哪些没有商量余地的规则与关键策略？
- 我们将如何行事？
- 我们将如何对待彼此？
具体如下：
- 我们做出的每一项决定都必须考虑到对最终客户的影响
- 我们可以少做事，但是要把事情做好，做得非常好，我们可以没有能力做好，但不可接受有能力却没做好。总有未来的版本可供我们反思与改进。
- 每一个API都需要配合一个明确的用例进行创建和记录；“车到山前必有路”式的API创建思路不会带来任何助益，反而会留下种种麻烦
- 我们将站在巨人的肩膀上；尽可能整合现有资源，而非一味盲目的从零创建。
- 我们尽可能确保开发人员感受不到我们的组织边界。
如果愿意，也可以将上述原则称为“咒语”。优秀的团队领导者不断带领团队重复实施这些原则（通过示例以及书面与口头沟通）。
优先级
有90%的决定其实并不重要；真正的成功源自确定的10%并专注于将其实现。
计划
计划，是指您自上而下建立的规程。计划负责描述我们如何分阶段解决问题。在五P框架当中，计划应该采取“自上而下”而非“自下而上”的方式; 但在另一方面，大家还应自下而上建立起一套详尽规程，用于确定是否应当削减工作量（仍然遵循您的原则与优先级结论）或减少（极少发生）/增加工作范围。
自上而下的规程应包含所有“已知”日期。这些规程应涵盖假期与会议等可以早期确定的事务。这些都属于我们了解且必须得到解决的工作，因此每当我发现有人没有在时间表中将其明确列出时，我都会感到相当惊讶。在Windows Phone 7项目中，我们敲定的截止日期为“2010年秋季”，而起始日期则为2009年5月。
自上而下的规程还应该包括所有重要的里程碑节点。
人员
我们应明确谁负责哪些工作（更重要的是，他们不负责哪些工作），这样才能保证每个人都理解谁承担着计划中的各个关键性组成部分。
为了说明如何考量五个P中的人员部分，这里我使用RACI框架：
- 责任（Responsible）——为实现可交付成果而开展工作的人 。
- 审批人（Approver）——最终负责以正确方式完成交付成果的人（惟一）。（我不喜欢‘问责’这个词，因为其有着被动的含义。我希望每个人都能‘主动感受’到自己肩负的责任。）
- 顾问（Consulted）——负责提供咨询意见的人; 通常采取双向沟通方式。
- 知情人——不负责、不提供咨询意见，而仅需要了解当前情况的人。
大家可以使用自己熟悉的任何工具，但请明确记录下计划当中各个部分的对应负责人姓名。千万不要把人员分成群组; 对我来说，存在不认识的团队成员是个需要警惕的信号，必须及时跟进。
最后，同样重要的是明确限定谁不负责哪些工作。“知情人”类别就是典型例子。如果Sally负责功能部件A，且功能部件A与功能部件B之间不存在依赖关系，那么Sally应该明确意识到自己不需要为负责功能部件B的个人或小组提供意见或帮助——这能帮助她有效节约精力与时间。
英文原文链接：https://ceklog.kindel.com/2011/06/14/the-5-ps-achieving-focus-in-any-endeavor/
网友评论