声明：本文不是软文，而是广告+xbt！敬请关注
今天偶然看到熊杰06年的一篇文章《成败论英雄》，让我想起今天下午的一个讨论。
时间：2008年12月24日下午
地点：唐-ThoughtWorks会议室
背景：某同事关于自己刚刚结束的项目的Knowledge Sharing即将结束，他自己提出了一个问题：Is it a successful project?
这是一个成功的项目吗？每个人的心里都有一个答案，或肯定或否定，或坚决或犹豫。我对项目本身的详细内容并不了解，其运作形式是我们公司派出员工与客户公司一起工作，并在工作过程中帮助客户建立敏捷团队，改进流程。项目结束的时候，统计下来我们大概花了36个人月左右。而客户估计如果没有我们的参与他们完成这个项目大概需要9个人月左右。就这样一个行将结束时提出的一个小问题引发了最热烈的讨论。我仅靠自己的回忆尽量真实的还原当时的一些讨论，由于记忆力、价值观、个人喜好等各方面的原因，可能跟当时发生的事情完全变形。大家就当个故事听听算了：）
A:我们这是一个Enablement（启动）的项目，这样的项目其目标跟delivery（交付）项目目标是不一样的。我们当然会多花很多时间在用户培训上面。
B:但是，我们跟客户自己估计的时间比例接近于4，这个在客户的高层领导看来可能是一个performance（效率）非常低的一个团队。
C:客户给出的9个人月本身会不会太乐观了呢？因为根据我们的经验，很多team做估计的时候都会给出过于乐观的结果，其后果就是加班和delay。
D:也许这个数字我们可以认为是一个比较乐观的数字，真实的数字也许应该是13到17，可是即使如此，我们也是人家的两倍以上。
E:也许我们应该将两部分分开计算，用于用户培训和团队建设的effort是多少？用于产品交付的effort是多少？这样我们可以让客户心里明白，那些钱是花在什么上面。
F:这个是不可行的，我们没法去计算。
E:也许，我们需要一个模型。我们要说服对方，就要拿出令人信服的数据来。
X:这个36个人月是不是一开始就计算出来的。
L:当然，我们不会最后给客户一个big surprise:)
X:如果那样，我们其实可以认为客户是可以接受这个情况的，而且是基本上理解的。
A:我们回到问题上，什么样的项目算作是成功的项目呢？产品on time, to buget交付显然是不够的，甚至不是主要目标。
X:这个问题很好，我们的客户怎么看待这个项目呢？实现客户价值才是最重要的。
L:当然，所有的开发人员都认为有非常大的收获。
C:我们第一个项目花费的人月是客户端的三倍或者两倍不重要，关键是我们要把这个数字降低到1以下。
Q:其实，我们在这里看到的讲到的都是dev方面的effort，除此之外还有质量保证部门。通过我们的实践QA部门的工作轻松了很多。他们本来需要每天等开发人员check in了代码，基本上就是下班之后才能开始build自己的测试版本，而现在他们可以随时拿到可以测试的版本，而且里面的bug数量有了明显的降低。另一方面，开发人员说是9个人月的工作，可能很多的加班是没有计算在内的，而在我们的团队里面是很少加班的。
X:很好，我提一个可能过于直率的问题：如果是我们的工程师，完全作为delivery（交付）项目来做（即不考虑对客户的培训和组织调整等），我们能不能在9个人月内完成！如果不能，客户，尤其是高层的决策者为啥要选择敏捷呢？他们根本就不care你是不是加班了，他们关心的是成本——人月。
H:当然，这个是有把握的。我们甚至用不了这么长时间，但是这也是建立在我们的工程师对于敏捷实践比较熟悉，而且相对来说经验更为丰富的基础上的。当然，我们也不要加班。
L:问题是客户没有继续跟我们合作，或者至少是没有保持现有形式的合作。这是不是也是一种失败呢？
（点评：这是一个难得的跳出项目的问题。）
X:这个跟我们的开发人员本身不善于跟对方的高层领导打交道有关系，我们还是跟一线干活的工程师关系比较好。
关于项目的成败，熊杰的博客里面还有一些更深入的讨论，有兴趣可以从上面的链接过去看看。我们毕竟是一家商业公司，而不是公益组织，在为客户实现商业价值，为个人实现社会价值的同时，如何才能摆正公司的的位置正视公司利益，也是我们需要考虑的。我们要在行业内发挥更大的影响，需要更多的工作去做，去做更多成功的项目，而如何定义成功可能是我们这群人需要一直探索和思考的一件事情。