最近2天一直想写篇关于项目管理的文章，但是一直写不下去，感觉这话题有点大，自己其实也没有专门学过，有的都是经验之谈，零碎不成体系。
不过既然都想了这么久，不写出来总有点不甘心，所以今天还是硬着头皮把这几天对它的思考分享给你，希望对你有所启发，对我自己来说也算个总结。
先说说我自己对项目管理的理解，作为一名产品经理，从我的角度出发，项目管理做的事就是确保我的计划、我的想法能按时按质不超成本地实现，可以说是通过对过程的控制来保证最后的达成。接下来，我会根据这个理解，从3个角度来说说如何做好项目管理：
从任务的角度
项目是由多个大大小小的任务组成在一起的，这意味着把这些任务都做完，项目也就完成了。从这个思路出发，我们可以把关注点放到任务本身上去，思考哪些因素会影响到它，下面说说我的思考：
1）任务的分类
在这里，我只把任务分成了串行任务和并行任务2类，简单不复杂。我先来对它们进行定义，串行任务指的是不可同步进行的任务，并行任务则指的是可以同步进行的任务，真的很简单。注意一下，这只是我自己对它们的定义，如果你有不同意见，请以我的为准。
对任务做这样的定义，是因为在项目推进的过程中，我们需要知道哪些任务是可以同步做的，哪些任务是不可同步的，需要等待其他任务做完才能开始。知道这些有什么好处呢？我的回答是4个字：提高效率。
举个例子。最近有个小项目，需要做个宣传海报，分解起来任务很简单，就是文案、设计和印刷。那这里面的任务哪个是并行的，哪个是串行的呢？
印刷明显是串行的，明显要等文案和设计都做好才行。那文案和设计呢？有些人可能会认为文案和设计是并行的任务，其实正好相反。设计往往需要等待文案做好，才知道该如何做设计、如何配色。
所以在我看来，在这个例子中，3个都是串行任务。硬要文案和设计同步做的话，效果肯定不理想。但对于串行任务，我们真的只能眼睁睁等着一个做完才能开始另外一个吗？我的答案是否定的。
虽然它们是串行任务，但彼此是相关联的。就算做不到并行，也可以做到小并行。什么意思呢？设计理论上需要等到文案完成才能开始，但是我们细想就会发现，其实只需要知道文案大概表达的是什么、有哪些关键因素、字数有多少等，就可以开始做设计了。
那意味着，文案那边如果先把这些想好告诉设计，那它们是可以并行的，这也是我所说的小并行。串行的任务之间，往往后者知道前者一些关键的信息就可以开始了，并不需要等待前者全部完成，这点很关键。
在我看来，任务都可以并行是最好的，我认为这样效率是最高的，前提是有足够的人手做并行，当然如果人手实在不够，其实都是串行。对此，我的原则就是能并行就并行，不能并行就小并行。
还有，我们容易把串行任务当成是并行任务，把并行任务当成串行任务来对待。所以要学会分清楚它们之间的区别，别把串行任务当作并行任务，也别把并行任务当作串行任务，例子就不举了。
2）任务的风险
什么叫任务的风险？在意料之外发生的，而且影响到任务是否能完成的事情，我就把它叫做风险。对于风险，我们需要考虑下面两点：
第一点，如何预防意外的发生。有句话说得很有道理，“求其上者得其中，求其中者得其下，求其下者无所得”。我觉得这句话放在预防意外发生上，也很适用。
意外发生之后，可能会导致两个结果，一是任务无法完成，二是任务不够时间完成。根据那句话和这两个结果，我们可以把任务调高，把时间调紧来预防意外的发生，这也可以叫做安全边际。
举个例子。我今天的任务是6点下班前，派500张传单。如果我想这项任务不发生意外的话，我就可以把任务调高，派600张，同时把时间也调紧，在5点前排完。
通过适当地把任务调高，把时间调紧，我们可以有效地预防意外的发生。如果我们把任务和时间都安排得刚刚好，容不得一点意外发生的话，这项目本身就变得十分脆弱。
当然你也不要抬杠说，把30天的项目压缩到10天去完成，这也是不科学的。这里只是说明应对风险的原则，在你做项目计划的时候就要考虑进去，尽量让项目变得更加坚韧，能承受风险。
第二点，意外发生之后如何处理。上面说的预防，我把它称作静态预防，在项目开始之前就要想好。那在意外发生之后，就需要用到动态预防，防止风险漫延到其他任务上，导致整个项目出现不可控。
动态预防与静态预防的处理方式是一样的，只是需要我们在项目中、任务中设置关键的考核点来监督进度是否符合预期，不符合的话，就把下一阶段的任务调高，时间调紧来对冲风险，道理并不复杂。
注意，在应对任务的风险中，我只是选取了其中一个角度做分析。这个角度我认为更具有普遍性、适用性，对于其他的应对方式，我暂时还总结不出套路。
3）任务的难点
在项目里总会有一些难点，这些难点完成不了，会直接影响到整个项目。对此，我的应对方法是：一是把困难的任务放到前面做，这样就算出现问题的话，还能时间做调整；二是准备好plan B。这道理并不复杂，在这里我就不展开了。
从时间的角度
项目无法按期完成有可能是因为上面所说的原因导致了延期，也有可能是因为错误估算了时间。你想想，明明需要100天才能完成的项目，你硬要50天来完成，有可能吗？但这并不一定是你的错，可能只是你错误地估算了时间而已。所以接下来，我会从这个角度出发，来说说该如何为项目估算时间：
1）任务的颗粒度
我们直接去估算一个项目需要的时间，是非常困难的。因为对于项目你可能只是模糊地知道需要做些什么，而具体要做什么却根本还没去细想。如果你随便定个时间，这很有可能导致项目无法按时完成。
对此，我们需要把项目中的任务层层分解，分解到能够估算到时间的颗粒度为止。举个例子，你突然问我下去买菜需要多少时间，我是无法回答的，只能大概说个时间出来。但是如果我做分解的话，就能知道下楼需要5分钟、从楼下到市场需要10分钟、在市场买菜的时间需要20分钟，所以来回的时间一共需要50分钟。
从例子中可以知道，任务需要分解到能估算到时间的颗粒度才行，所以当你不能一眼看出需要多少时间的话，那就是任务的颗粒度不够小，还需要继续分解。
当我们把项目里所有的任务都分解到可估算时间后，那一共需要的时间也就大致出来了，但这还不够，请继续看下面的分析。
2）任务的压缩性
要准确估算时间，除了颗粒度之外，你还需要考虑任务的压缩性。把所有任务的压缩性加起来，就变成了项目时间的弹性，也就是估算的时间范围。
举个例子。我大学读书的时候是8点上课的，但奇怪的是，无论7点起床，还是7点半起床，我都能刚好8点踩点到课室。这是为什么呢？明显是因为晚起床之后，我就刷牙快、穿衣快、走路快，所以还是能继续踩点。
所以当我们在估算时间的时候，把可压缩任务的压缩时间计算出来，就可以得到最快的和正常的完成时间。这个压缩出来的最快时间可以让我们面对突如其来的变化时更加从容，而且心里更加有底。比如，临时增加任务，但是总的时间不能变，这时候你就需要知道最快的完成时间。
3）任务的叠加性
上面我们已经根据颗粒度和压缩性2方面估算出任务所需的时间范围，但这还不够，把它们时间加起来也不是项目的总时间。因为刚才估算的时间并没有考虑并行的情况，也就是几个任务同时做的情况，所以不能简单粗暴地加起来。
几个任务同时开展，相当于把任务叠加在一起，我把它称作叠加性。在这种叠加的情况下，完成的总时间取决于时间最长的那个任务，而不是把它们的时间都加在一起。这些可同时做的任务就是上面说的并行任务。
在我们做估算的时候，要把并行任务的时间算好，而能并行多少任务则需要看你项目的人手和难度来定。并行的任务不是越多越好，虽然可能会节省时间，但也要考虑到后期人手浪费的问题和任务本身难度的问题。同时，对于串行任务的小并行处理方式，这也会影响到时间的估算，这点也要注意。
当我们把颗粒度、压缩性、叠加性考虑到任务上，其实就可以得出一张关于任务的时间表，也可以称作甘特图。有了它，我们就可以更有效地监督整个项目的进程，根据项目实际的推进情况随时做出调整，做到有的放矢。
可能你会不理解我为什么会花这么多的精力来说估算时间，但我可以很负责任的告诉你，我见过太多的人因为没有估算好时间，导致项目无法按时完成。如果项目只有你一个人还好，如果需要团队合作的话，你估算错了，后面的人都会受到影响，甚至后续的计划也被迫调整。你说严不严重，而且养成估算时间的好习惯，对你生活也很有好处。
从人的角度
看了一下字数，篇幅有点多，所以”从人的角度“就下篇文章再写吧，有兴趣的朋友敬请期待。
最后总结一下，我们分别从任务、时间和人3个角度来思考如何做好项目管理，如何让项目推进的过程变得更加顺畅、更加可控。但这可能与你想的项目管理不一样，因为我也并没有系统地学过项目管理，更没有考过pmp证书，思路也与网上其他人不太一样。
这些内容都是我在工作过程中，自己总结出来的经验，而且只选取了我认为重要的点来做分析，细想起来其实还不够全面。但还是希望对你有所帮助，能把这些经验应用到生活工作中。
下面还有我写的几篇文章，有兴趣的可以了解一下。
原创不易，求关注，求传播，公众号也叫【假装是个思想家】，谢谢~
