项目任务结构分解一般经过哪些步骤

WBS是面向项目可交付成果的成组的项目元素,项目元素定义和组织软件项目的总的工作范围,未在 WBS中包括的工作就不属于项目的范围。WBS每下降一层就代表对项目工作更加详细的定义和描述。较好的工作分解可以防止遗漏项目的可交付成果,帮助项目经理关注项目目标和澄清职责,建立可视化的项目可交付成果,以便估算工作量和分配工作﹔帮助改进时间、成本和资源估计的准确度﹔帮助项目团队的建立和获得项目人员的承诺;为绩效测量和项目控制定义一个基准,辅助沟通清晰的工作责任;为其他项目计划的制定建立框架,帮助分析项目的最初风险。

WBS具有4种主要用途:①WBS是一个描述思路的规划和设计工具,它帮助项目经理和团队确定和有效地管理项目的工作;2WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具;③WBS是一个展现项目全貌,详细说明为完成项目所必须完成的各项工作的计划工具;④WBS定义了里程碑事件,可以作为项目状况的报告工具,向高级管理者和客户报告项目完成情况。

制作工作分解结构过程生成的关键文件是实际的工作分解结构。分解结构每一组成部分包括工作细目与控制账户,赋予一个唯一的账户编码标识符。这些标识符形成了一种费用、进度与资源信息汇总的层次结构。

工作分解结构不应与其他用来表示项目信息的“分解”结构混为一谈。在某些应用领域或其他知识领域使用的其他结构包括以下几类:

(1）组织分解结构(Organizational Breakdown Structure,OBS):按照层次将工作细目与组织单位形象地、有条理地联系起来的一种项目组织安排图形。

(2〉材料清单(Bill of Material,BOM):将制造产品所需的实体部件、组件和组成部分按照组成关系以表格形式变现出来的正式文件。

(3）风险分解结构(Risk Breakdown Structure,RBS):按照风险类型形象而又有条理地说明已经识别的项目风险的层次结构的一种图形。

(4)资源分解结构(Resource Breakdown Structure,RBS):按照种类和形式而对将用于项目的资源进行划分的层次结构。

计划任务的分配

个人认为，把项目按照任务的方式来完成，是一项非常有价值和有效率的事情。

完成的项目计划虽然是整个团队的承诺，但还是要将计划的任务随着渐进明细后，将任务合理的安排下去，并让团队成员保证按时按质量完成，这样才能保证整个项目按计划完成。需要要明确的是，每一个项目任务都是在项目计划的控制下进行任务的分配。任务有处理时限要求的特征，非常紧急，紧急，一般，宽松。任务有时间特征，立即，尽快，正常，暂缓，延迟和滞后。任务还有优先级的要求，关键，重要，普通，非重要。任务有利于工作量均衡，可以个人独自完成，可以多人同时完成。任务是较小的工作单元，还有利于任务跟踪，估计工作量。此外，任务还有一个特别的作用，就是利用任务完成情况做绩效考评。例如，IT系统上线前的测试环境的工作任务，属于关键、一般正常性的工作任务，只要在系统部署前完成即可。

采用明确和简洁的任务描述，明确的责任方式，以及明确的验收标准或结果来分配和传达任务，有利于项目经理和团队成员理解任务，任务根据不同的工作内容，所需要的时间有长有短，还需要项目经理合理安排长期任务，或突然出现的紧急任务。项目经理还要即时监督和检查，及时调整和督促。如果是长期任务，更要进行周期性检查，避免在任务截止日期时出现重大的失误，如果是关键路径上的任务，要仔细检查和组织评审，确保任务的有效完成，避免任务影响整个项目的进度。一个任务就是一个小目标，项目就是这样一个一个小任务目标组成的大目标，一步一个脚印来完成的。

可以采用任务分配单的形式向团队成员分配任务，项目经理做好项目任务的汇总表，然后和项目计划的阶段、工作分解结构相对应，有利于项目工作过程数据的量化及统计，同时也对项目工作和团队成员工作量的有效匹配。

项目经理接手项目以后，会对项目进行展开，并将项目工作分解来着手执行。在进行项目工作分解的时候，一般遵从以下几个主要步骤：

1先明确并识别出项目的各主要组成部分，即明确项目的主要可交付成果。一般来讲，项目的主要组成部分包括项目的可交付成果和项目管理的本身。在进行这一步时需 需要解答的问题是：要实现项目的目标需要完成哪些主要工作？（一般情况下，项目的主要工作是指贯穿项目始终的工作，它在项目分解结构中主要被列在第二层。）

2第二步的工作是：确定每个可交付成果的详细程度是否已经达到了足以编制恰当的成本和历时估算。 “ 恰当 ” 的含义可能会随着项目的进程而发生一定的变化，因为对于将来产生的一项可交付成果进行分解也许是不大可能的。对每个可交付成果，如果已经足够详细，则进入到第四步，否则接着进入第三步 —— 这意味着不同的可交付成果可能有不同的分解层次。

3确定可交付成果的组成元素。组成元素应当用切实的、可验证的结果来描述，以便于进行绩效测量。与主要元素一样，组成元素的定义应该根据项目工作实际上是如何组织和完成的。切实、可验证的结果既可包括产品，又可包括服务。这一步要解决的问题是：要完成上述各组成部分，有哪些更具体的工作要做。对于各组成部分的更小的构成部分，应该说明需要取得哪些可以核实的结果以及完成这些更小组成部分的先后顺序。

4核实分解的正确性。即需要回答下列问题：（ 1 ）最底层项对项目分解来说是否是必需而且充分的呢？如果不是，则必须修改组成元素（添加、删除或重新定义）；（ 2 ）每项的定义是否清晰完整？如果不完整，描述则需要修改或扩展；（ 3 ）每项是否都能够恰当地编制进度和预算？是否能够分配到接受职责并能够圆满完成这项工作的具体组织单元（例如部门、项目队伍或个人）？如果不能，需要做必要的修改，以便于提供合适的管理控制。

IT项目管理中开发项目时都分四大类的角色：管理、前端UI、后台开发、测试这几类角色。

部门经理

协调部门内和企业内的资源分配，协调各部门的沟通，并承上启下地为部门的整体业绩负责

项目经理

协调项目内的资源分配，如日常沟通，进度管理等，为项目负责

产品经理

调研客户需求，进行需求分析，形成MRD文档，对产品规划，根据市场需求和分享规划产品发展路线，设计产品商业和服务模式，并定义相关功能模块

技术经理

协调项目内的技术活动，推动主要技术决策，技术的可行性研究，评价、确认并文档化软件架构等

UI设计师

旨在设计项目开发中的具体界面，与人进行交互的UI界面

绘画制作

根据需要来绘制设计各种不同的静态资源

后台开发

项目组长

协调小组成员分工，指导、分配、落实小组成员工作，发挥团队职能优势，不断提高小组成员工作效率，优化工作流程，推进项目研发进度

系统架构师

主要负责大系统项目的架构设计

软件工程师  

编写代码，同时编写项目文档，如需求，详细设计，架构设计，用户手册，开发计划等；

程序员

编写代码，实现功能；

测试

软件测试工程师 

主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象

扩展资料

软件质量保证

创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。

IT项目管理

IT项目管理是项目管理在IT领域的应用，结合IT行业特点运用项目管理技术、理念和方法，包括9大知识领域（项目综合、范围、时间、成本、质量、人力资源、沟通、风险和采购管理）以及启动、计划、实施、控制和收尾等过程组成。

特点

1、任务的明确性

2、管理工具的先进性

3、信息沟通的及时性

4、资源提供的必要性

5、测试完善的严谨性

6、度量的准确性

7、项目管理的贯穿性

参考资料：百度百科—IT项目管理

VUCA一词起源于上世纪90年代的美国军方，是Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）的首字母缩写。VUCA概括了后互联网时代的世界特征——复杂多变。我们所处的世界变化越来越快，知识边界不断被突破，项目管理也不例外。

传统的项目管理虽然认识到项目具有渐进明细的特点，但在计划、执行、监控过程中还是明显强调瀑布特点：制定计划前要“清晰、完备、准确地界定项目的工作范围(SOW)，作为整个项目工作的基础”，然后是“分解出足够详细的工作步骤(WBS)”， 把WBS作为整个项目计划、执行、监控的核心。虽然传统的项目管理中也提到滚动计划，但还是以稳定为基调，把适应变化作为辅助，而VUCA时代恰恰是以变化为最大特点，传统的项目管理方法很难适应这个前提，从而使得计划赶不上变化，项目计划往往成为一纸空文。

传统的项目执行出现问题，多归因为项目工作范围界定不够准确、项目计划不够详尽。应对的策略也很粗暴：一方面是在合同谈判的时候尽量界定清楚、不含糊其辞；另一方面在合同执行的时候，据理力争，合同约定之外的尽量拒绝。

由于各种原因，合同约定一般很难满足SMART原则，“聪明的”乙方则会跟客户约定以“签字后的需求规格说明书”作为验收依据。这样“需求规格说明书”就成了双方的“必争之地”。在项目费用、执行周期固定的情况下，甲方项目经理自然希望乙方能提供更多的、更高品质的功能，至少可以更好地向领导交差；乙方项目经理则希望能以最小的资源投入、冒最少的风险、尽快交付，能拿到更多的项目奖金。

在“合同谈判”胜过“合作共赢”的情况下，乙方项目团队虽然在需求调研上投入大量的精力，但客户不愿配合、拒不签字的场景时有可见，更有甚者乙方会设计晦涩的需求文档、复杂的变更流程，甚至应用了多种心理效应，就是为了约束客户不要再变了。

对于第一种变更，乙方需求分析人员如果有丰富的领域知识与实 *** 经验，能设身处地地分析，大多能够避免。但由于人的思维定势及碎片化倾向，一次很难考虑周全，难免会有遗漏，譬如酒店管理系统中的入住功能，“团队入住希望能住到相邻房间”这样的约束，可能事先很难想到，只有在系统投入使用后才能发现这个不便。为避免这类变更，传统的做法是加大需求捕获与分析的力度，这容易事倍功半，也容易造成“过度工程”的问题。

对于第二种变更，传统的项目管理中一般归到风险范畴，譬如甲方换了领导或项目负责人，组织结构调整，外部环境发生重大变化、设备不到位等等，这些都是风险，都会给项目工作范围带来变化。传统的应对策略是识别、分析、跟踪、应对风险，增加缓冲资源与时间。但风险的概率特性，为管理层提供了侥幸的借口，风险缓冲很容易被上级砍掉，风险被直接转嫁给员工，通过员工的加班加点来弥补。

第三类变更，不是由于问题变了，而是解决问题的方式变了。在汽车没被发明的年代，客户希望更早到达目的地，只会想要一辆更快的马车，而福特却造出了汽车。同样的问题不同的解决方案，效果自然不一样，项目工作范围也会截然不同。

VUCA时代，复杂与变化已经成为主旋律。在这个强调以客户为中心，强调为客户带来价值的时代，项目还要因循计划、不拥抱变化，一方面确实不易做到，另一方面也一定会损害客户关系。

VUCA时代的IT项目管理该如何开展呢？

项目管理的七个常用的项目管理方法包括WBS工作分解结构法、PERT项目评价与审查技术法、Gantt图法、关键路径法（CPM）、里程碑计划法、RACI矩阵法、风险管理。

一、WBS工作分解结构法

将整个项目按照工作分解为若干个独立的子任务，并以树状图的形式进行表示，从而达到清晰明确、具体详细的目的。特点包括层次结构、明确任务范围、确定任务优先级、易于沟通等。

二、PERT项目评价与审查技术法

用于分析和计算项目完成时间、风险和成本等因素，以帮助管理者作出决策。 PERT项目评估确定项目目标、确定活动的持续时间、建立网络计划图、评估资源需求、确定关键路径、确定浮动时间、监控项目进度等。

三、Gantt图法

以时间为轴，将任务和资源安排在不同的时间段，方便管理者进行计划和控制。制定工作分解结构、确定任务的持续时间、确定任务的依赖关系、绘制Gantt图、监控项目进度等。

四、关键路径法（CPM）

识别项目中的关键路径，即决定项目最短完成时间的路径，以便进行优化和控制。制定工作分解结构、确定任务的持续时间、确定任务的依赖关系、计算最早开始时间和最晚开始时间、计算最短完成时间、监控项目进度等。

五、里程碑计划法

将项目划分为一系列里程碑，以便管理者和参与者更好地掌握项目进展情况。确定项目的目标和关键阶段、制定里程碑计划、确定每个里程碑的前置条件、跟踪和监测等。

六、RACI矩阵法

用于定义项目中每个角色的职责和权责，以确保每个参与者清楚知道自己在项目中扮演的角色。包括确定项目的目标和任务、确定项目角色和责任、审查和确认、持续更新。

七、风险管理

在项目的整个生命周期中识别、评估和应对可能出现的风险，以降低项目失败的可能性。包括风险识别、风险评估、风险控制、风险监测。

以上就是关于项目管理工作分解的用途及种类全部的内容，包括:项目管理工作分解的用途及种类、项目管理：计划任务的分配、项目任务结构分解一般经过哪些步骤等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！