一个LIMS项目的经验和教训

一个LIMS项目的经验和教训
LIMS 项目类似与ERP，客户的个性化内容很多。导致项目成败的，往往不是技术问题。比如，在这个珠宝LIMS 项目中，我也做了一些总结和反思。
A. 客户的选择
1）慎选客户；2）一个“专家客户”未必比“小白”客户好。
在这个珠宝项目中，可以说成也萧何败也萧何。这个萧何，就是客户方的CIO。是他，使得整个项目有亮点，质量过关；也是他，使得大量无谓的劳动/返工，以及需求的不靠谱，影响了很多效率。他曾经（大约7年前）是一个程序员，后来不做程序了但管理本单位的IT部分。对于具体业务有一些了解。
因为有利有弊，我是从两个方面看他的。好的方面，他偏执，认真，较真儿。这些好，逼着项目团队进步。我愿意与这样的人做朋友。
但对于一个具体的商业实施项目开发而言，他也有不好的方面，
1）他“人品”有问题。可能很多客户方都会有这样的想法，拿最少的钱办最多的事儿。如果这个项目的合同额是500万，那么他提出的那些要求都没有问题，非常合理 ：） 项目组调侃的是，他老兄总想拿出买鸡的钱，让我们给他一个孔雀。 在这一点上，虽然供需双方是矛盾的，但应该有基准。这个基准就是交付某种特征的产品真正要花销的成本。他在这一点上已经过了，孰不知垃圾工程往往是这样产生的，你给施工队的钱让他给民工发工资都有问题了，那么他不给你豆腐渣工程怎么办？ 怎么解决这个问题呢？ 一是合同签订时，需要成本核算（决算时的实际支出，往往高于预算不少，因为中间可变因素太多了。）；二是必要的勾兑。（这个道理我当然知道，但并没有勾兑他。）
2）他的“技术”问题。因为做过DELPHI程序员以及开发，因此他对一个项目的参与肯定不同于一般的客户。他提出的需求，往往不仅仅是需求了。而是“真需求+朦胧的需求+他认为的解决方案+他海阔天空的想象”。这个很难办，事实证明他的解决方案未必就是对的，很多是错的。毕竟，七八年前的技术，用DELPHI做C/S开发，已经不同于现在的技术环境，不同于.NET下B/S的开发。即使是数据库方面，也还是有不同，虽然说到根儿上，一些最基本的理念和方法是通的。 他喜欢与开发组讨论某个具体的细节你到底准备怎么实现，然后展开热烈的讨论，此时他的个人兴趣爱好已经超过了我们要做的是快速实现需求。项目组的另一项调侃是，他老兄其实不仅仅是想花鸡的钱买孔雀，而是想得到一只凤凰！ 凤凰这玩意儿是神物，可想而不可知。他有很多想象，有很多自己曾经或现在想到但没能做到或没时间去做的事情，他想在这个项目上来实现。相当于大家跟着他一起做实验了，这个我们很受不了，我们不是实验室。不过也有个附带的好处：以后等系统正式上线了，估计谁敢说不好，首先得过他那一关，还轮不到我们操心。因为他估计是把自己当作了这个项目成果之父了。自己的孩子，哪儿有不爱的，谁敢说不漂亮就跟谁急。
慎选客户，是个很难做到的事情。因为对国内目前的IT环境来说，整体上还是买方市场，很难做到能牛到几十万的单子我不做了，就因为我对客户中某个人感觉不爽。但，开始的时候，特别是在招标的单子中，把需求了解清楚，把预算做充分是必须的。然后低于某个价格我就不做，这个是可以做到的。想不要裤子抢单的行为，是不明智的。
这里也涉及到专家客户的问题。 怎样与专家客户打交道呢？ 那是另外的一个话题了。
B. 应对需求（变更/延伸/末端需求）
我相信这是软件开发方面永恒的一个难题。目前我的看法是：1）敏捷开发模式。不奢望需求一成不变，也不怕它变。世界原本如此，怕与抱怨有很何用？ 在敏捷开发的宣言中，不是专门有“响应变化大于遵循计划”吗？按照那种方法去做，瀑布法不适合这一类的项目。2）原型法。空对空的说，往往双方以为差不多了，实际上可能差得远。实实在在的界面原型或程序原型可以解决这个问题。有不少这方面的工具可以利用。3）项目组中，有个得力的需求分析方面的专家。 对业务的了解，需求分析方法和能力，编程能力，沟通能力。在这四项能力中，相对而言“编程能力”最不重要，程序员相对好找。但没有对业务的了解，很难与客户沟通明白或花去很多学习的过程和时间；没有需求分析方面的专业技能，自然其结果也好不到哪儿去；没有良好的沟通能力，那更是障碍重重。 4）重视需求的延伸，从开始就纳入管理的范畴；充分重视末端需求，很多项目开始不可能考虑的面面俱到，往往到了最后才发现一个小小的要求，就能让这事儿泡汤一半。给它留出时间。当然，对同类项目而言，一个有经验的团队会好的多，他们知道大概边界在哪儿，不至于非常离谱。
C. 项目的过程管理
自始自终都按规矩来进行项目管理，不能偷懒。那些过程记录有用，比如，对某个需求变更的记录说明和备忘录。说难听点，哪怕到了最后超期了，你能拿出实实在在的东西证明给客户看，老兄这都是你的原因造成的，有物证在此。这比最后双方空口说白话，公说公的理婆说婆的理，扯不清楚的好。和客户不能扯，他是上帝，上帝有钱。