Software crisis is a term used in the early days of computing science for the difficulty of writing useful and efficient computer programs in the required time. The software crisis was due to the rapid increases in computer power and the complexity of the problems that could not be tackled. With the increase in the complexity of the software, many software problems arose because existing methods were inadequate. —— Wikipedia: Software crisis
诚如上述背景中提到的那样，管理好软件项目是一项极难的工作，这不仅取决于人力成本的昂贵，更重要的我们无法明确的描述要交付的东西是什么。软件开发的本质困难和瓶颈不在于人力方面，而在于整个组织的 沟通效率。
健康的项目管理心态
有过多年经验的开发者们，或多或少都经历过失败的软件项目吧，也许还听说过「死亡行军」的说法。我第一次知道这个概念，还是是在《代码之殇》这本书上。「死亡行军」指的是，在一个注定会失败的项目中持续投入人力，以期望它能奇迹般的成功。反正我们已经尽力了，不是吗？我们知道完不成，但是我们不是已经在加班了么。
不是这样的，这并不是一种健康的软件项目管理心态。也许我们经历过的很多类似的项目，都已经麻木了，但其实不应该自暴自弃。从《项目百态》这本书中，我们会发现软件项目的成功是一种极其「反人类」的实践，或者说它是一种非常不稳定的状态，只要有一个明显的错误，都会导致失败，而要想成功，必须克服掉一系列困难。
项目成功的要素
1. 大脑中的概念
软件项目跟其他类型的（体力密集型）项目，有着本质的不同。软件项目所要加工的素材在项目参与者的脑袋里面，并没有实质的东西。代码其实只是很小的一部分，代码只是自动化任务的人机沟通媒介，至于为什么要如此编写代码之类的信息，并没有写在代码中。做成什么样，为什么要做这件事情，在人们的脑袋里面，不在代码中。
这里并没有提及产品设计，虽然它在软件项目中非常重要，但是产品设计的困难并不局限于软件项目，任何其他类型的项目，产品研发和设计都是非常关键的一个环节。假设在整个项目组内，已经至少有一个人大概想清楚最终的交付结果的话，软件项目执行困难的问题，才犹如洪水猛兽凸显出来。
2. 失败因素
在列举项目成功的要素之前，我想先列举一下有哪些因素会导致项目失败。
不确定的预期：项目组无法快速得到做什么和不做什么的反馈
不确定的人力：项目组成员都兼职在当前项目中，对于人力的投入没有明确的预算
不确定的方案：解决方案的共识难以快速达成，或者总是力求完美，或者有权决策的人总是不在场
这三点其实是有逻辑关联的，「预期」代表终态，「人力投入」代表动力，「方案」代表路径。任何事情从现状开始，如果终态不明，路径不清，动力不足，那就不可能成功。反之，如果一个项目能够 同时解决 以上三个问题，它就能成功（这里需要肯定的语气）。
3. 成功的策略
为了应对以上三个问题，我们需要为每一种不确定性（预期、人力、方案），考虑适当的举措。以下汇总了我常用的一些办法。
（1）如何对齐预期
对齐预期是一个持续的过程，但每一次对齐预期的时间点仍然是越快越好。在对齐预期之前，我们先要想明白的一个问题是「要对齐谁的预期」，这样就不会找错人，或者出现频繁对齐的情况。
常见的人物角色，大概包括三类：客户/用户代表、利益相关方、技术专家。在邀请会议的时候，客户/用户代表、利益相关方 必须邀请到会，具有一票否决权。技术专家当然是越多越好，但所提建议是否被接受，应当由发起人来决定。
除此之外，我们应当以小步快跑的方式，持续不断的将交付产物向 客户/用户代表、利益相关方 进行审查，以尽早的订正现状与预期的差距。最好的办法是，项目负责人定期向整个项目组发周报。
（2）如何确定人力
要知道，人力投入不足的主要原因并不在于偷懒，而在于事项的优先级。所以并不是没有时间，而是优先级不够高，否则一天三催也是没有用的。不对齐优先级，即使有再多的时间，还是没有时间投入到给定的工作任务中。对齐优先级并不是一件简单的事情，因为这意味着原计划要做的事情就不能做了。
不幸的是，很多团队的情况是，具体执行开发任务的工程师没有调整自身工作的职权。所以，一旦任务分配下来，更多是不得不接受，而不是向上反馈说任务满了，做不过来了。因为要这样说的话，可能会被认为是工作能力不太行，或者说是工作不饱和。解决这个问题的办法是，提升每个人任务堆积的可见性，避免单点过载。
因此，确定人力和优先级，要找到资源的投入方才可以。这是一个 人力投入、工作重心 调整的问题，而不仅仅是字面上确定什么优先级最高，让大家放在心上。当资源的所有方对现有投入不能割舍的话，优先级就永远无法对齐。
（3）如何确定方案
方案需要经过讨论才能执行，这是为了尽快达成共识，让变更的影响更可控。所以方案并不是讨论出来的，而是宣告出来的。开会是用时间换共识的一种商业模式。
有了共识，才能以一种 更顺利（多方支持）、更可控（意外出错）的方式 向下执行。所以我们说，项目执行的效率，在很大程度上取决于共识达成的效率。如果一个项目总是在方案层面难以达成共识，它就快不起来。
我常用的一个共识达成思路是这样的：
先定义问题，方案只解决所定义的问题，问题定义改变时，方案应该重新确定。
有了问题之后，方案并不唯一，发起人应当秉持开放的心态，接受方案被调整。
即便是方案可调整，仍然需要给出默认选项，而不是将决策过程放到会议中做。
达成了共识之后，需要将共识记录下来，将信息重组一下，形成标准技术文档。
积力所举，众智所为
「积力之所举，则无不胜也；众智之所为，则无不成也」出自《淮南子·主术训》，千人之中必有栋梁之材，万人聚集没有办不成的事。重要的不是自己能做什么，而是能否聚合集体的力量形成合力。
很多软件团队没有清晰的项目观，无法快速看清哪个人当前在哪个项目中，每个项目的规划和里程碑节点是什么，都有哪些风险，需要怎样的资源协调和对齐。在这种情况下可以说，软件团队尚未发挥其真正的战斗力出来。要想形成合力，需要对每个季度、半年要交付的项目有明确的计划。每个里程碑节点，可以提前规划出来。有计划的行事，总是把人力配置到最有成效的那些项目中。
另一方面，只有提升工作的可见性，每个人的任务负荷才能识别出来，这些都是项目的隐患，也是需要重点关注的地方。工作太忙是有问题的，忙意味着有可能不能完成工作，忙也意味着对结果的预期太高了。这肯定是对现有工作模式的一种挑战，也会让一部分人的利益受损，所以肯定会遇到阻力。预期的结果并不是要求大家更忙了（工作饱和），而是团队的整体产能再提高一个段位。
小结
本文介绍了我对软件项目管理的一些认识，以及以何种方式建立科学的项目观。
如果你所在的团队存在以上问题，我觉得这些想法也许会有帮助，
对团队项目进行整理，保证重点项目风险可控
识别/培养/招聘 对项目管理有兴趣的工程师，共同分担整个团队的项目管理压力
全员提升工作和项目的可见性，识别工作压力瓶颈，项目进展可见
孤立系统的熵，永不减少