第三篇中我们提到，软件开发是一项知识密集型工作，开发活动是知识的创造过程。
知识工作具有很强的不确定性，
软件工程中的很多方法，都是为了消除这种不确定性而展开的。
除了可以从工程化的角度，从流程、规范或协作的角度消除不确定性之外，
不同人的做事方式，也会产生不同的影响。
有些人会采用有些行之有效的方法，不仅让自己对事情更有管控力，
还能对外表现得让别人放心，这是很关键的。
本文就探讨一下这些方法，仅当抛砖引玉了。
工作项拆分
任务一般是工作中的最小作业单元，我们每个人的日常工作都是被各种各样的任务所填满，
但如果只着眼于任务的话，就容易产生只见树木不见森林的错觉。
实际上我们需要考虑的是每天甚至每个月，这些任务是如何联系在一起的，
它们是如何作为一个更大项目的子任务出现的，
或者，这个项目是如何作为一个更大战役的子项目出现的。
战役和项目本来应该是管理者自上而下传达的意图，但有些时候，信息传达的可能未必及时，
这就需要我们有从叶子追溯到树根的能力。
除此之外，一个大型任务交给我们手上的话，我们还得学会对它进行拆分。
把它拆分为可以管控的小部分，每个子部分还可以再拆分，
这就需要具备整体思维意识。
什么是整体思维意识呢？
就是把自己放在任务/项目/战役负责人的位置考虑问题，自己对整件事情负责。
不要寄希望于别人。
主要关注以下几个方面：
总共要拆分出哪几个子任务，还有没有尚未考虑到的事情
拆分出来的每个子任务的进度如何
整个任务的卡点在哪里，如何消除卡点，让其他任务可以进展下去
所以具备整体思维意识，会有很强的推动（push）能力，
这不仅仅是自己对任务管控能力的体现，
更重要是可以做到对外透明。
别人不知道我们在做什么，那就相当于什么也没做。
其他人也无从得知怎样提供帮助，以及我们做的事情会不会对他产生影响。
进度计划
学会了向上追溯更大的项目，向下拆分工作项之后，
另一个重要的方法，就是制定进度计划了。
我们需要对每一项工作进行评估，给出大致的工作量，以及完成时间。
我知道把工作量评估准确是一件很难的事情。
但评估的越准确，未来产生的危害就越小。
所以，为期一个月的任务，是值得花费 2-3 天时间来仔细评估工作量的。
主要考察这几个部分：
有哪些需要外部团队/个人协助才能解决的事情
有哪些方案尚未确定的事情
到了截止日期，如果不能做完，优先级是什么
有些事情是依赖外部资源才能解决的，比如依赖了其他团队提供的软件服务，
这时候更是要小心谨慎了，因为很可能一件小事会导致整盘延期。
此外，自己负责的事情，一定要用心摸清底细，不要听别人的判断，
要自己真的去看一下，到底还有多少工作量。
所以事情都了然于胸之后，就要指定进度计划了，并实时跟进每天整件事的进展，
进度落后的情况下不要羞于启齿，而是及时是上报风险。
这样与当前任务相关的其他任务就可以感知到这一点，作出相应的调整了。
没有进度计划，会给人一种无限往下拖着不办的感觉，
别人不知道我们的整体进度到底是怎样的，也就没法安排自己的工作。
系统分析
系统分析特指一种从系统/子系统角度考察技术方案的过程，
是进行技术评审的时候，很常用的一种办法。
我们要从需求、设计、系统关系、时序的角度，方方面面介绍自己的技术方案。
这样可以在着手开发之前把方案确定下来，
尤其是那些与其他系统进行交互的部分。
重点注意以下两点：
自己对需求的理解是不是准确，有没有无法覆盖到的场景
是否需要其他系统进行改造，改动量有多大，需要对方系统负责人评估/排期
自身系统的设计方案是否合理，有没有其他隐患
系统分析不一定是正式的，但是跟团队进行交流的过程是重要的，
自己拍脑袋想出来的方案很多情况下都是有问题的。
这不是由技术能力决定的，而是有很多信息是我们自己不知道的。
要学会开诚布公的，把方案拿出来大家看看，并愿意接受任何调整。
所以说，做软件并不是技术上行得通或者方案优雅就够了，
还要考虑外部影响，以及各利益相关者。
尤其是在一个复杂系统上进行增量开发的话，征得别人同意才能让自己的工作做的更顺利。
很多事情是无法让所有人满意的，那就只能说服对方，
找到一个双方共赢的结合点，才能让工作进展下去。
风险上报
软件项目中大部分的风险都是进度风险，其他的不太常见的例如还有资源风险，
这里我们就只谈进度风险。
进度风险产生的原因是多方面的，可能有以下几种：
承诺的截止日期在早，导致不论如何都会延期
工作量评估的过于乐观，一些不确定因素没有及早暴露出来
依赖方的风险没有及时上报，导致自己延期
消除进度风险是一件极难办到的事情，这也许是软件领域最难解决的问题之一了。
究其原因，或许在于任务项目都是一件资源、质量、时间，三方平衡的产物。
要想质量好、时间短，就必然会投入更多的资源，就是要加钱，
而很多时候资源的投入不可能是无限的，而且还有软件工程本身的属性制约。
软件项目当资源投入到一定程度之后，就无法再缩短时间了。
所以一味的缩短项目时间，可能会导致质量低下，或者功能不全。
这一般是不可忍受的。
所以一个比较的管控办法是，
对功能排优先级，总是在有限资源投入，有限时间，足够高的质量管控前提下，
优先发布更重要的功能。
这样软件项目管理就会变成了这样的事情了：
如何界定功能的优先级
如果对研发过程进行管理，减少浪费让更多功能尽快交付
如何谈判给研发团队争取更多的时间，只做有核心竞争力的事情
所以并不是施加压力，逼迫马儿快跑就完事了，这是体力工作的管理方式。
让马儿快跑只要打它就行了，但是想让它喝水，就得另想办法了。
结语
文本介绍了可适用于个人的管理软件项目不确定性的办法，
重要的一点是，如何做到让别人放心。
现在的软件系统越来越复杂，所以对工程师的要求，也不仅仅是技术技能这一点了，
还需要有很强的沟通和推动能力，有责任心，
但这些说法都很虚，如何才能做到有责任心呢？我想本文或多或少能解决一些疑惑吧。
工程师跳出纯技术的视角之后，关注点才能落在范围更大的事项上，
也才有机会整合资源，做出更有价值的事情。
这并不是一件简单的事情，本身也是需要讲究方法的，需要投入精力的。
这可能是一件有趣的事情吧。