软件项目管理心得（二）失败篇

    这是我第二次写关于项目管理的文章。在最近的一段时间内，我经历了两次连续的项目管理失败。 
    第一个失败是前一片文章的asp.net项目，由于客户突然给了我一个完全不可能实现的期限，让我无所适从。
去年八月份，客户将项目的相关要求给我，并让我担任项目的队长。然后我按照一般文档驱动的方式开始准备和完善相关的文档。
在九月份的时候，客户跟我说，要我在11月将项目完工，并对我说，我最好在此之前完成该项目。如果完不成，项目也可以延期。
由于那是我的第一个.net的项目，所以我对项目在什么时候完成没有一个肯定的预期。但是在11月的时候，即使我没有完整项目经验，但是我知道那肯定是完不成的。
    接着客户不同意我的做法，他为了在理想期限中完成项目，决定放弃文档，这让整个团队的合作（我们的队员分散在全国各地的大学中，基本上只有通过文档才能联系）变得举步维艰，并利用QQ这种即使聊工具来联系。
    我在团队中的领导地位完全被他取代，他来召开项目的技术会议并安排各种具体工作。
    在这种压力下，我选择了退出，结果据我所知，现在那个项目也没有完成。
    接下来，我接受了另外一个asp.net的项目，这个项目的期限也只有一个月。然而我在这个项目中仍然采取了文档驱动的模式，并且我的队员也强烈要求以文档驱动的模式推进整个项目。结果我们在一个月的时候只完成了全部的文档和部分的代码工作。幸好在这个时候客户突然提出项目将要延期的信息，否则我的这个项目又要夭折了...
    最近在看敏捷开发与极限编程，上面说到了文档驱动浪费时间的地方。
    不知道我所推行的文档开发是否真的如敏捷开发中所说的那样是对时间的浪费和效率的忽略。但是我总感觉文档可以让我在开发的时候更加得安心，也让我的队员开发时更加的方便。
    在接下来的项目开发中，我将推行极限编程的工程思想，但愿我能够成功...

在我看来，即使使用极限编程，你将会有另一个主题：软件项目管理心得（三）敏捷失败篇

从你文中提到的内容来看，第一个项目中你跟客户的关系没有处理正确（你竟然被他取代了）就注定了项目的失败。

第二个项目只有一个月时间，我觉得这个期限几乎已经决定项目不大可能成功。一个项目的规模就算再小，它还是要在需求分析、设计、编码、测试等工作上花费时间的。另外你仍然采用了文档驱动的模式，是不是花在这方面的时间和工作量多了一点？能否说说你们用于文档的时间和工作量大概是多少？我并不是反对文档驱动，我只是认为文档的工作量要合理，但怎样才叫合理恐怕没有什么统一的标准

你提到下次打算用XP方法，不禁为你担心。如果你没有比较深入地了解某种方式就冒险使用，只看到正面效果而不防备负面作用，后果你未必能够承担......

短期项目对团队的挑战不是一般的大。主管要迅速把握需求，技术要熟悉，团队最好是磨合过的……否则，注定延期或失败。

> 我们的队员分散在全国各地的大学中
> 项目的期限只有一个月

不失败的是神仙。

很新鲜的客户关系哦。客户要来加入开发不是不可以，但要摆正位置恐怕不容易。

有要求的开发过程吗？如果有，按照开发过程走；如果没有，文档驱动有何意义？

为什么要写文档？为了更好的明确用户需求？为了更好的根据需求进行系统设计？更好的分工？更好的进行项目监控？等等等
首先搞清楚为什么写文档，对于不同的项目文档可以写到不同的程度，最重要的是在开发过程中我们写文档是为了更好的去实现各个软件过程，最终实现项目目标，把文档作为一种达到目的的手段，方法，不要作为负担。
条条大道通罗马，在项目初期需要对项目的背景、目标、资源、风险、相关干系人等有一个全面的识别与分析才能找到最适合该项目开发的方式方法。