没有注明[攻]的帖子,可以不回答吧. :)

Steve

举一个简单的例子，来说明我期望看见的数字是什么？大家说不要长期加班，我通过一些项目分析可以看见，在研发阶段，如果不加班，每人天产出代码行是320行（这是一个很高的数字，因为项目相对简单），通过适度加班，代码行基本上是390行（但是人员已经很疲惫，而且Bug率明显增多）；长期的周末和通宵的情况下，每人天增加到410行，但是Bug严重增加，而且使得产品安装在客户那里的时候，出现比较严重的问题。于是，我们说，不要长期加班，但是做为短期的一种手段来说，还是可以使用的……
不然我们仅仅说，加班好，或者加班不好，谁都有理由，但是，结论是什么呢？
另外，我想说，为什么没有确凿可靠的数据呢？你的项目计划中，会有成本估算，总结的时候，有成本计算。如果缺乏这些数据统计，我们如何说某一件流程是值得做得，那件流程不值得做呢？
难道都是靠论述和分析？至少我知道我的老板绝对听不得这种话，对于用这种话提出的各种建议和意见，一句话就给打回来了“去再调查调查，你无法用事实和数据证明你的观点，你就不用抱怨我不接受你的意见”。我想，这句话对于很多人都有用。
呵呵……

下面说说我具体如何操作，来防止风险的发生：
1 合同方面：在合同后面附带有Spec（功能性、非功能性需求），然后在附录中有一个条款是：我可以在Spec范围内，进行需求变更，但是超出Spec的功能，需要额外收费（这也就是为什么我挑选这个项目来外包，因为他的需求变化风险不大，而且功能相对比较单一）。比如我要一个登录界面，那么我要修改各种登录的流程都是可以的，但是如果我加入了SSO需求，就不被对方所接受；在合同中定义了了Rough schedule，如果每超过一个里程碑一天，则扣除1%的合同费用。如果电信初验每延缓一天通过，扣除10%的费用（当然是我们去执行初验，但是他们那个WAP模块如果无法通过初验，则进行扣款）。在维护期阶段，我同样可以提出流程上的一些修改，但是无法增加新的功能。但是我也有足够的理智，这时候在改变大的流程是不现实的，因为只有10%的尾款在我这里，他们不会很认真去干的。但是通过后续的条款，可以使得至少Bug他们需要修复。同时考虑到WAP的适配性问题，我们提交了3款测试手机给他们，和一个模拟器，在这三款手机和模拟器，做为测试环境；我们的项目经理有权对他们的代码进行Codereview，如果发现不符合我们编码规范的代码，项目经理有权提出重写要求，由我和对方公司老总最终决定；
2 在项目之初，我确定了一个项目经理，负责整个项目推进，在最初期，项目经理向对方的PM说明了我们的需求，并且负责Spec的设计和撰写，并且沟通清楚我们的里程碑的意义和时间点。然后提交给他们adapter访问接口和Adapter的Class模块（除了接口层以外，经过内部调度接口的加密编译，这在Java里面有工具，不详细说明了），然后在外部建立一个环境，除了他们的WAP以外，Adapter后后台数据库都已经建设完毕，他们的WAP放上来以后，就可以模拟运行程序了。
3 项目经理在过程中主要负责进行Code Review，以及一些具体技术问题的回答，以及源代码回收和发放测试团队进行测试；内部有一个简单的冒烟测试过程（这个项目的一个失败就是，我们应该试图去建立一个自动化的冒烟，因为这个测试已经进行了很多次，成本上应该能够覆盖自动化测试的成本，但是当时图轻松，就没有去做，结果测试多花了不少精力），如果冒烟通过，则表示这个版本我可以接受，如果无法接受，则退回，重新提交；用这种方式来避免对方随意的Code，然后把成本全部推卸到我们这里。一般提交周期是1周2次内部Release；
3 在后期进行全面测试的时候，采用一天release一次，通过外部可以访问的Bug系统来进行Bug提交和Fix记录；我同时可以收到Bug分析报告，初步分析现在项目的Fix bug过程是否正常；
4 在执行之初，有明确定义的组间协同计划来定义相互之间的接口和协同方式；在发生风险以后，我们的沟通会上升到Face2Face的层面；每周进行一次，如果这样的情况下，还是发生大量风险，将由我，市场，和对方总经理沟通解决这些问题；
5 初验的情况，由我们的工程师在现场配合电信初验，他们工程师远程支持；

最后这个项目的结果是：
1 里程碑发生2次Delay（都是发生在早期，我没有申请对对方公司扣款，因为我不希望他们把这部分费用看成沉没费用），最后提交和初验全部一次性通过；
2 成本为内部研发的60%-70%左右，我是使用代码量除以我们Web项目的代码量得到的结论（Web部分和Wap部分难度等等比较类似，但是Web部分的JS代码比较多，而且JS代码不容易调试，所以这部分成本我无法独立考虑出来，可能有一定的偏差）
3 那个公司对于这种合作方式很满意，原因很简单：他们通过这样的项目锻炼起来一支团队，并且他期待通过这种方式，可以切入我们的业务中，最终达到一些固定周期的合同（虽然对于这一点，他没有如愿）。
4 我只说好的，不说问题，不符合我的性格。说说问题吧：这个项目暴露出来的问题如下：在设计理解上存在一些偏差，这些问题往往只有在Code Review的时候才有发现，风险比较大；同时，这个项目的设计难度不大，但是层次封装不够合理，造成对方的一些误解，采用了一些错误的方法来完成功能；需要项目经理具备比较高的沟通协调能力来推进项目；对于细节需求的执行不够得力，这些问题往往出现在中期发现不少很细节的需求执行不到位，给项目造成风险比较大，后面需要加大一些CheckList的细节控制；对于我们的Bug流程执行不规范，为Bug分析造成一定的影响，这一点以后需要考虑在合同中定义一些关键路径需要对方执行，看看效果如何；在项目中增加一个较大的需求变化，引起不少震动，以后需要多考虑一下这方面的组间定义和先期的追加功能的价格条款，否则比较被动……；
大致如此吧。但是最终的结果是：我还是比较满意的。至少他符合我认同的两个成功的要素：事情完成了，而且比较少地占用我的资源或者我的成本。

呵呵，你们可以自己考虑，如果进行。但是我不觉得这种方式可以称之为好，仅仅是无奈之举而已。