工作分解结构怎么做?
项目经理，如何做好工作分解结构?
如果要说到项目管理中几个难点，那么工作分解结构是会被提到的一个环节。工作分解作为项目计划中的一部分，为什么一直有人抱怨太难，而又如何去相对地改善呢?
1、为什么要做工作分解
在讲原因之前，先简单说一下什么是工作分解。
通俗地来说，就是接到一个大任务，我们不能一下子就做完，那么我们就需要把这个大任务拆分成多个子任务。当然有可能其中有的子任务也比较大，那么就继续往下拆解，直到颗粒度我们感觉合适为止。
2、工作分解的难度
工作分解在项目中进行，主要会碰到2个阻碍。
(1)不知道怎么分解。
这点是在需求确认和讲解后，是很多项目管理者和开发人员经常抱怨的。因为很多人估算时间是很简单粗暴的，需求在脑子里过了一下，然后随口报出一个时间，但往往这个时间是不靠谱的。
为什么会出现这个问题，就是任务分解没有做，或者没有做好。
对于需求没有理解透彻，相关业务逻辑还根本没有去思考;只关注主流程，而对分支不重视;学习新的技术没有预留缓冲时间;开发完毕没有考虑自测时间等等不一而足。
一般以上情况出现，都会把任务的颗粒度做得很大;原因很简单，很多东西没有考虑或者考虑不足的情况下，颗粒度无法继续分解。
最后就是交出来的任务列表很粗糙，甚至有的任务预计一周。这种分解对项目的跟踪管理毫无意义。
(2)懒得去分解。
这点就是态度问题了，觉得这个东西太难了，也懒得去深究。反正做到哪里是哪里，随便估算个时间交差。
往往造成这种情况的，基本都是经历了很多次第一种困难之后，已经对任务分解失去信心，导致恶性循环。
3、工作分解的解决方案
前面一直在说任务分解，其中有个关键词【颗粒度】。
一个简单有效方法就是在颗粒度上做文章。
拒绝大颗粒度的任务分解，比如每一条工作只能控制在一天以内，如果大于一天就继续分解，直到达到目标为止。当然了，如果能把周期控制在小时为单位，那就更好了。
另外把业务模块和技术模块分开估算，不要做成一个大杂烩。业务梳理和技术调研都应该是分开地去开展，而不能就是简单地给归纳到一个画面开发中。
画面内容组件化。把整个画面上的东西归类，有依赖的功能试着做成一个分开组件。然后针对这个组件继续做拆分，忌讳分解的任务没有逻辑，功能散落在各处。
由于工作任务分解确实是一项非常困难的工作，以上的方法也都只是抛砖引玉，具体项目都会有具体的解决方案。但归根结底还是希望用工作分解的方法去帮助我们做好计划，做好追踪。
以上就是小编为大家整理的关于工作分解结构怎么做?的相关信息。