原文https://www.cnblogs.com/amazonove/articles/4876611.html
这是前一阵给团队培训，提高团队工作绩效时写的。
四个原则：
l 瓶颈性任务最优先解决原则
l 高不确定性的任务优先解决原则
l 前置性原则
l 复杂多变任务的处理原则
瓶颈性任务最优先解决原则
比如说，上面这个任务分解，B、C、F这条线是瓶颈线。是最优先解决的线。
高不确定性的任务优先解决原则
满足下列两条之一的任务是高不确定性任务：
· 困难的、没有实现方案的；
· 无法预估完成期限的；
还是以上面那张图为例子，假设A任务是高不确定性的任务，它可能无法解决，可能解决需要很长时间。它很可能比我们计划的时间要长，从而影响进度。比如说，任务图会变成这样子：
所以，这类任务要优先解决。解决步骤如下：
第一步，寻找最小实现方案，如果技术不可行，寻找替代方案；如果技术上可行，做出最小的实现，消除风险和不确定性，估计完全解决需要多长时间，将高不确定性任务转变为普通的任务；
第二步，按照普通任务的处理方式来进行优先级排程。
前置性原则
比如说，上面的图，B是C的前置任务，B应该在C之前解决。
这里有两个例外：
（1）如果后置性任务属于高不确定性任务，那么需要想办法解除后置任务对前置任务的依赖，把它优先处理；
也就是说，如果C任务是高风险、不确定性的任务，那么就要想办法解除C对B的依赖，优先解决C，做出C的最小可行性方案，将它变成普通任务；然后，再按照B优先于C的原则来处理；
（2）如果有多余的资源或人手，应该想办法解除后置任务对前置任务的依赖，将这个任务尽量的和前置任务并行处理；
复杂多变任务的处理原则
对于复杂的任务，需求可能发生变化的任务的处理是项目管理的难点。这种处理的原则是：
产品层面多沟通！！多沟通！！多沟通！！这种情况下，聊天比写代码重要！！
技术层面多分解！！多分解！！多分解！！分解成不同的模块，通过模块组合来实现需求，当需求发生变化时，换一种组合方式就行了，或者换一个模块就行了。切忌整个代码都是铁板一块！！这样，需求一变，会改很多很多东西！！
四个技能
l 沟通
l 解除依赖关系
l 最小实现方案
l 分解
沟通
沟通很重要，尤其是对复杂性任务，越复杂的任务越需要沟通。
这是解决复杂性任务的必备技能！
沟通也不简单，有可能三个人讨论一件事情时，最开始20分钟，三个人感觉讨论的都是一个事情，随着讨论的深入，20分钟之后，突然发现，三个人谈的表面上是一个事情，实际上心中所想的互相之间有很大区别。
多聊天，多画原型。
解除依赖关系
解除依赖关系，将不能并行的任务变成可以并行的任务，这是缩短项目时间的必备技能！
如果有多余的人手，想办法解除任务之间的依赖关系。
假设甲做A任务需要2天，乙做B任务需要3天，A任务是B任务的前置条件。如果不解除依赖关系，那么项目得5天做完。解除依赖关系后，就只需要3天。
最小实现方案
用最快的时间，实现最小实现方案，来评估高风险任务的可行性、所需人手和时间。
这是解决高风险任务的必备技能！
分解
把一个功能分解成更细的功能，这是进一步提高工作绩效的必备技能！
就像电脑一样，需求变了，换个零件、换个外壳就解决了。如果全是铁板一块，那就麻烦大了。另一点，软件代码的重用成本几乎为零，分解之后，这些就变成了代码资产了，需要A功能？需要B模块？需要C产品？直接从代码资产里拿些出来，组合组合即可。分解的要点就是尽量的解耦，尽量的不依赖于实现。
