WBS工作分解结构

WBS，不止是工作分解结构，也能更好的管理个人时间，是一个很好的工作和做事的思路和习惯。
先看下WBS的官方定义吧，工作分解结构(WorkBreakdownStructureWBS)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
讲下自己对WBS的理解和认识的过程。
最初安排各个模块后，大家各行其路，自己按照自己的思路开始进行。项目经理问了多久可以完成，自己扫了下需求，然后互相打量了下其他人的眼神。10天吧，大概。可想而知，15天后，我们仍然准备了很多解释工作延期的理由。
然后有了WBS。刚开始自己对WBS的认识很浅显，只是字面意义上的理解：合理分配任务，然后跟踪任务的完成情况。开始的时候，大家对工作的也比较盲目，根据各自模块进行模块功能划分，然后大概的对各个功能的难度和所需时间进行了时间的预估，再安排各个功能模块给个人。问题总是在我们不期望的时候和考虑不周的时候如期而至。这次虽然比上次进步了，但是仍然有很多的不足。
经过几次的摸爬滚打，自己总结了几点需要在WBS中注意的。
1，WBS一定要自上而下的分配任务。先从总的需求，再到模块功能，再细分到功能的每个实现。不要一开始就太关注某个细节，避免出现因为考虑不周到，对项目的某些功能进行遗漏。
2，WBS一定要有可操作性。何为可操作性？比如说，我要锻炼身体。就要问自己怎么锻炼，每天5分钟短跑，10个俯卧撑。这个每天5分钟短跑，10个俯卧撑就是可以操作的。只有具有可操作性，才能正确的预估时间。 这点也是本人感觉最难的，因为分解到可操作性就要能估计完成时间，如果分解不够详细，可能最后整个项目的时间估计会出现很大偏差，如果估计过于详细，会浪费太多时间，在合适的阶段估计到该阶段需要的详细程度。需要大家在实际的工作中不断的总结经验，不断的改进，才能越来越准确的WBS。
3，WBS最好分解到小时为单位，不要超过一天为宜。时间太长，就没有实际的操作性，而且时间长，也说明问题分解的不够明白。如果分解到12个小时一个任务，很有可能存在自己分解不够细致，导致在实际的开发过程中遇到自己没有考虑到问题，造成延期，带来项目风险。
从WBS中也得到了很多启发。比如，生活中遇到的很多问题，如果没有一定的思路，都很棘手。但是如果用WBS的方式来分析问题，首先从大的方向将问题分解，然后一点一点的将大问题分解成小问题，直至分解成可以操作的各个小步骤，然后这个时候就可以一步一步的完成各个小步骤，小目标。不但可以较快的找到解决问题的方法，而且可以作为估算自己的时间成本和其他成本一个依据。
再者，生活中经常为自己定各种各样的目标。很多人习惯把目标定的比较远，但是实际的操作性差，而且不能很好的检查自己的完成情况。比如说，一个月读完某本书。其实是可以将任务分解，先粗略的看下各个章节的内容量和难易度，然后将各个章节分别击破。第一周看1，2，3，4章，第二周看，4，5章，等。这样不但具有很强的操作性，每周任务相对每天又有很大的灵活性，可以适当的调整每天的时间，而且，如果到了周五发现还有很多没有读完，又能很好的监督自己，加快进度。
分享这些，一来是自己可以整理下思路，以便在今后能更好的应用WBS的方式来工作和学习，二来是希望大家也能从中得到一些启发，对今后的工作和生活有帮助。