“焦油坑”历险记

软件工程界前辈 Brooks 在他不朽名著《人月神话》中，形象的用“焦油坑”来形容那些失败的大型软件开发项目。第一次阅读到那段文字的时候，只是感觉比较新奇，对那些陷入困境的软件项目实际情况并没有多少实质性的认识。在最近自己接网上一个实验性项目的过程中，我终于体会了一把“焦油坑”的味道（虽然是微型规模的“坑”）。不幸的是，我的下场和大多数落入焦油坑的史前动物一样，在剧烈挣扎之后，沉入了坑底－－－我刚通知了客户关于项目失败的事实。

本来这是一个很有意思的项目，结合了跨平台 GUI 框架、2D/3D 图形绘制、GIS 数据处理等具体技术，还有使用的是我最喜爱的 Ruby/C 编程语言，工程量也不大，可以说是一个很适合我单独完成的项目。去年年底，客户跟我联系，经过一些细节的讨论，我确定承接了该项目的开发。由于是一个验证性的项目，用户给予了我很大的自由度，不具体规定完成时间。但是在这么好的条件下，我却把事情搞杂了，这个问题值得我反思。

对于项目的失败，客户和我都负有责任，当然主要原因在我，因为客户把主动权都交给我了。不过正是这过度的自由，是导致项目失败的一个重要原因。下面细说几点我从这个失败项目中得到的教训，给自己提个醒，下次遇到相同情况要注意。

* 对项目总体和各组成部分要有一个清晰的认识。
这个就是《人月神话》中 Brooks 反复强调的“概念的完整性”，对一个项目的整体和各部分都没弄清楚，就别奢谈成功完成项目了。而去年的我，正是在对项目不甚理解的情况贸然接手的。初期架构师对项目总体没把握很正常，但是到最后实现阶段，实现者对项目概况还是不清晰就是悲剧了。由于项目的实验性，我面临的窘境就是到很晚的阶段，才在大脑中勾画出最后项目要呈现的样子（这个跟下一点教训有关）。然后自己对目标平台的编程方法，具体行业知识也比较欠缺，项目的失败几乎是一开始就注定的。

* 项目开发中交流的重要性
我这个人算典型的 Computer Nerds，技术没什么长进，性格倒是越来越孤僻，整天对着电脑，一天说不上几句话。喜静少言，虽然是个人性格问题，无可厚非；但是在软件开发过程中，这却不是好习惯了。因为客户没有提供详细的项目需求，我对很多细节问题一直模模糊糊。开始跟客户一直是英文 Email 联系（客户是一个在美国的华人），我个人有限的英文水平，常常限制了我的表达；加上客户本身比较繁忙，不能仔细解释我的各种疑问，所以有时候我全靠“悟” 来解决问题，这就造成我无法完成项目的“概念完整性”，最后导致了失败。所以说，Communication/交流很重要，我们跟客户的交互要像敏捷开发那样，“Communicat Early, Communicat More”。

* 做商业项目要有约束，自由散漫的开发方式不适合商业项目。
由于客户的理解和支持，没有了时间限制，我几乎是用玩的方式来做设计、写代码的。高兴的时候写代码到深夜，没心情的时候几天不动键盘。初期新奇体验新技术、新挑战的阶段没有问题，感觉收获挺大，连续攻克了几个技术问题。但是到后期，几个关键地方卡住了，反复几轮尝试均失败。由于没有压力束缚，我开始消极回避，所以一直没能进一步突破，项目时间拖久了，人心理上也开始疲倦，这时候慢慢体会了身处焦油坑的滋味。这样拖着对双方都没好处，最好在自己良心谴责之下，我通知了客户放弃继续开发项目的事实。Game over，我被淘汰出局。

* 认准的事情，要坚持到底。
我对该项目的最大的一个遗憾，就是我主动投降了，没有坚持到底。做事情要坚持到底，很浅显的道理，但是自己却做不到，开始怀疑自己的 RP 是不是有问题了。凭良心讲，项目后期，我没有尽最大的努力去完成它，如果继续尝试，应该还有完成的希望的。只是在最困难的时候，我选择了逃避（就是因为太没约束了）。这样的行为，让我表现出相当的不“Professinal”，而这个正是在当前社会立身的根本。性格耶？人品耶？反正这次要强烈鄙视自己一个。不得不承认，“我还是 too joung, sometimes naive”。

尽管项目失败了，我还是在这个过程中学到了不少东西，技术上的、为人处世的东西都有。由于没有压力，做项目的过程还是挺愉悦的，能让我慢慢研究 C-Ruby 之间互动的方法，处理大数据量时候节省内存的策略。感谢那位善良友好的客户，让我有机会参与如此有意思的 Project，就像一次愉悦的旅行，虽然没有到达目的地，但是沿途的景色让人流连忘返。

以上就是我一次不光彩的“焦油坑”历险记，但愿仁慈的读者您不会取笑我。
［全文完］

这也是一次很难得的“外包”的经历吧，呵呵。。。

呵呵，确实是一次挺“古怪”的外包经历，让自己学到不少东西。
本篇文字可能过于偏向‘网文’风格，略显虚浮的态度请大家包涵。
（本来发自己blog的，后来一想转篇到JE来）

我觉得既真诚又真实，挺好的啊，对大家也是一个借鉴。。。

楼主再坚持一下说不定结果就会不一样。。。。

本还有几会...
不过你发现的东西看着好像少了什么
能否再仔细说一说么
(不要细节主要是开发流程上面)

我不是狂热CMMI也不是狂热XPer
只是发现上面几点只是最后一点是致命的
想知道是否有其它的问题还没发现?

前面说了，这是一个实验性项目，客户没有详细的项目规划，所以开发流程基本上是这样的：
客户大概说明需求 ==> 我建模、设计、编程、反馈 ==> 用户提出改进要求 ==> 我按要求改进、反馈
这个过程反复进行，直到达到用户要求为止。

貌似很合理的过程，这样反复迭代、每次完善一点设计，最终应该达到目标。
但是这里忽略了人的因素，在多轮反复之后，项目代码仍然无法满足用户首期目标，我的热情开始减退；
加上遇到技术瓶颈，我尝试了多个实现方案，拿出较满意结果发给用户，但对方并不认可。

在项目初期我们商定把项目分成 5 个部分，当一个部分完成后，用户才发那部分报酬给我。
其实该项目的总体预算也不多，我花了数个月在上面，但是首期目标都没实现。
我怕再拖下去会影响本职工作，所以放弃了继续开发（因为是尝试性项目没有签合同，所以没有违约的顾虑）。
没有金刚钻，不揽瓷器活。可能是自己的开发能力、经验还不足吧，不过这个教训自己是吸取了。

恩，那就是你水平不行了。
不过放弃不是一个好的办法，这种时候比较合适的是找人具体咨询一下。

另外，你这个和“焦油坑”还是差很多的，真正的“焦油坑”是撤出成本极高的项目。
我们公司目前就有这样的一个项目，但是一旦放弃这个项目就意味着同时要放弃该客户的多个项目，所以只能靠项目间的交叉补贴继续维持这个根本没有了结希望的项目。