一个失败的project是如何炼成的？（End）

写了两篇文，还在外围转，这篇回归本质，说说代码分析和码农。

第三，analyze

这个环节大概并非每个公司都具备，但是这个环节是非常重要的。这个环节的人员需要对业务清晰，对产品明确，一旦需求到达这个层面，就是考虑需求如何植入系统的时候了。这决定了产品的走向和结构。一般这个层面的人都是程序员出身或者是DBA等，他们只做技术决定但是不管细节实现。

倘若有幸遇到美好的此环节人员，他会对

            1.客户的无理要求做出驳斥并对需求进行adaptation

            2.明确结构，关键是一个不要总修改的结构

            3.做出必要的业务说明以至于程序员可以理解自己要编的代码

然而，往往，此类人员大多从业经验丰富，但是却与新技术脱离了。有的时候解决方案稍显落后。

第四，码农，码农

一个项目的成功与否，本不应该取决于程序员的水平！程序员本应该是链条上的最后环节，也是最弱的环节，在一定程度上说，如果程序员成为了制约项目成功与否的决定因素，那么链条上的其他环节一定是已经糟糕透了！

如果不幸如此，作为项目的最后防线，码农必须具备除去编码以外的如下能力

     1.沟通！沟通！沟通！

说话，谁不会？还真的未必。本人就是不会沟通的人，最近的失败项目让我开始反思自己的弱点。

沟通分对象

与业务人员consultant的沟通。

试想一下，业务人员对外代表公司的权益和立场，但是对内则代表客户的立场。一方面，他们是可以帮助程序员理清需求的不可缺少的成分，另一方面也是代表客户

鞭笞产品的力量。试想如果这两方力量如果不能一起有效合作，那可真是。。。貌似不可能吧？也许是极品遇到的太多，身边这种例子还真是不胜枚举。最最令人叹为观止的是我们日内瓦的同事们，不是一个consultant和程序员合作有问题，而是整个两个部门都起了冲突，内耗数年，到目前为止都没有偃旗息鼓的态势。单就每个人来说，都是不错的聪明人，但就是不能放在一起工作。。。也许是太聪明了吧，呵呵。

与主管沟通

这个方面是个人最差的一面，也吃亏最多。无需多言，心知肚明。

与程序员沟通

你错了，怎样？我错了，又怎样？

赶脚程序员之间沟通最简单和直接，只有一点：不要互相纠错。谁不犯错呢？最最忌讳的就是指摘他人的错误，可以提建议，但是不能批评。本来程序员的工作就是人对机器的交互工作，那么所剩的那么一点人与人之间的交流，就让他来得愉悦些吧。

与其他公司的沟通

软件发展至今，单纯一个公司很难实现所有的功能，势必要有和其他公司的合作接口。WEB SERVICES的广泛应用也使越来越多的软件之间的沟通成为可能。此时，换位思考是程序员的必然要素。比如，我开发了一个实时检查信贷信用的接口，友方公司需要这个接口。那么我要为他们提供测试平台，测试数据，以及技术文档。

你好，我好，大家好是最高宗旨。

      2.决断

设计美好，实现骨感。

总有一些技术细节是在总体规划中无法发现的，现实的技术实现总是需要程序员本身做决定的。但若，前面的环节没有做好，需要底层技术人员做的决断就更多了。曾经，我犹豫犹豫，求助各方力量，最后发现到了实施阶段只有底层人员最了解情况，那么我开始习惯很多问题自己做决定。一旦出现问题还不是要我来改吗？但是时间也让我学乖了一些，若是影响到产品功能的决定一定要组织开会通知大家或是邮件通知，避免最后出现问题面对所有人的呆萌的不知所以的表情！

     3.预见

怎么讲呢，编代码时间长了，有的时候确实可以预见客户未来的需求（白纸黑字没有写出来，但是代码交付以后要求的改动）。这就看程序员的功力和对产品的了解程度了。

     4.知错（没错）能改吗？

自己写的东西，好像自己的宝贝孩子一样，推翻重来，有这样的勇气吗？如果前面链条发生错误，要重新开始或者做结构的调整，心理上能接受吗？反正本人还没修炼到这样的境界，我需要花很长时间来调整。。。

拉拉杂杂地写了好多，回过头来看也不知道自己写的什么，是自己的发泄吗？

谨以本文献给奋斗在一线的程序员们，愿我们的付出和努力都能有所值得。