软件开发项目从头到尾都会是一个挑战。在一开始，我们不喜欢花时间去好好地进行计划，而且我们假定已经了解了客户的需要，因而匆匆地去制定商业需求。最初我们觉得设计工作很有意思，但后来我们就发现技术环境比我们想象的要更加复杂，并因此而感到头疼。编码工作之后，我们还要做测试工作，时间长了会变得很无聊。最后，我们就只想着要做完这个可恨的项目，但是这里还有一个任务—实现。

实现经常又被称作部署，对于这个专栏来讲，两个词汇的意思是一样的。要实现一个应用软件没有一个单一的途径，它取决于你的项目和解决方案的特性。一些实现工作就像在说“我们现在活着”一样的容易。当解决方案是全新的而你正在对即将成型的生产环境进行开发和测试时，这种类型的实现可以起作用。这种情况下，实现工作处于这样的状态：头一天解决方案还处于开发状态，而第二天它就应用于生产。

另一个极端是项目本身就是实现工作。例如，你也许有一个应用软件需要在全世界范围内你的分公司中进行部署，这会花上数月的时间来完成并要求包括有计划，分析，设计等的一个完整的生存周期。

当你考虑到要进行实现时，你总是应该首先了解其中所涉及的复杂性。如果实现工作相对的简单，那就没有必要制定详细的实现过程。因此在这个专栏中，我将关注于当你面对复杂的实现要求时要考虑的策略。

早作计划

项目管理之中的很多优秀的例子都与早期计划有关系。事实上，如果你的开发人员对花上这么多时间进行计划的需要提出疑问，你就可以指出计划的目的之一就是确定实现工作的复杂性。如果实现工作非常庞大，你在开始就要在分析阶段中创建一个实现策略。这个文件将描述实现工作的整体方法途径，范围，假定和风险等等。你可以在这里做出一些关于实现工作如何进行的基本决策。例如，你可以决定在实现过程中是否要进行平行测试，或是在一个特定的阶段中系统是否要关闭。

下一次你要考虑到实现工作就是在设计阶段。这里你将创建一个较低级别的实现计划。如果你创建一个初始策略文件，实现计划将会加入很多详细内容。如果你没有创建策略文件，你就需要从更高的层次上理解你想要完成什么，但然后你就很快地跳入了计划细节之中了。实现计划用来设置实现工作的整体时间进度，确定谁将进行这方面的工作，列出所涉及的公司组织，估计工作量和持续时间等的参数。如果实现工作涉及到新的处理过程，你就需要解决如何对用户进行培训和谁来进行培训的问题。如果实现工作需要发生在多个位置之上，你就需要对整体的顺序给出描述。要注意实现计划提供了可以与你的出资人和项目团队共享的详细信息，这一点是很重要的。然而，它还没有到达实际工作计划的级别。

建构实现工作计划

到目前为止，我们已经完成了实现策略（在分析阶段）和实现计划（在设计阶段）。然而，我们仍要为部署工作实际地去建构工作计划行动。这应当在建构阶段完成。在这一点上，你已经经历了从高到底的级别，因此你剩下的工作就是去实际地定义行动，从属，时间和负责人员等等。

当你确实到达了实现阶段的时候，你就已经准备好了一个工作计划，而且你能够确信它可以完成你的需要，因为你已经有了从高到底的计划。

沟通永远是关键

在进行计划之外，实现工作的另一个关键元素就是沟通（这里，我们谈到的还是一个复杂的实现工作，如果不是这样，你也许只需将解决方案投入生产过程之中并对你的所做给出解释就可以解决问题和客户的抱怨）。如果你采取一个与前面所描述的类似的方法，那么你一直都在进行沟通。实现策略意在从一个客户的观点关注于处理过程，而且在进行之前应该得到他们的许可。实现计划应该贯彻给所涉及的所有人，你只需要不断地进行信息的沟通并确保每个人对实现工作做好准备。

如果你没有准备实现策略和计划，你仍然需要尽可能早地与人进行沟通。举个例子，我的经验显示，在开发人员和基础架构人员之间有着一种天生的摩擦点，这就是因为实现工作的具体细节没有得到沟通，或是进行沟通的时候已经太迟了。有多少次你看到一个团队准备好要实现一个客户机—服务器应用软件，但是发现他们需要让工作站支持团队在桌面上安装这个应用软件？当然，如果由于缺乏沟通导致支持团队没有做好准备，他们是不会高兴的。其它的摩擦点包括当部署应用软件或是出现重大改变时没有能够给出事先的警告，因为他们可能要接听很多来自用户的电话。第三点是开发团队在发现服务器环境需要变动时为时已晚。再一次，如果这个需要在实现工作开始之前得到沟通，通常就不会造成麻烦。

计划和沟通带动成功的实现工作

在这个专栏中，我们从一个方法论的角度上来看待实现工作。关键点在于早期计划并经常沟通，以防意外发生。即使是最复杂的实现工作也可以通过从头到脚的计划和良好的沟通得以成功地管理。另一方面，即使是最简单的实现工作也可能被糟糕的计划和沟通所破坏。在这个系列的下一篇文章之中，我们将看一看实现工作的详细内容和需要考虑并注意的地方。