我们还犯了一个错误，就是正式开发的时候，我们一上手就开发基础框架。大家都知道一个系统的基础框架的重要xìng。但是我们却用刚刚学会的新技术开发我们以后业务模块都要深度依赖的基础框架。我想起了某公司一套战略xìng的大型产品的开发：用的是新技术JAVA，大家都还是新团队，做的也是新产品，全体程序员都已经封闭开发了，居然有人提出了一套自己也未经过商业规模应用验证的基础框架，并且自己实现了一个小DEMO。大家一看这个小DEMO非常有思想，就决定让整套产品线都应用这套基础框架。

    我想象他们的痛，和我很神似。所以，我现在如果面临新产品、新团队、老技术，我都不会让大家一上手就开发基础框架。

    去年，我就面临了一个老团队、老技术，但是是全新一代产品的开发。

    具体情况是这样的，经过几年发展，我们的现有产品渐渐老化，所以决定要开发新一代的产品。上一代的产品是C/S结构，而且是适合单客户使用的。这次，我们要开发B/S结构，而且是适合集团客户使用的。

    让上一代产品的开发团队继续维护上一代产品。让新一代开发由新的开发团队去执行。所以，我们就招聘了新的团队（当时公司对开发新产品有不同的利益冲突团体，还没有达成一致，招聘新团队既有为新一代产品开发做准备的目的，也有其他的目的，造成这支新团队的打造过程中往往出现两种极端：要么好几个人都管，要么三不管）。刚开始并没有去动手设计与开发新一代系统，而是为客户定制开发了一两个其他IT项目。所以说还算接触了客户行业，大家彼此在一起工作也快八个月了，算是一个老团队。

    但是这支团队对客户、对现有的产品并不深刻了解，虽然我给团队多次讲解过业务，也让大家分析学习现有产品，阅读现有产品的说明书，根据新的业务模式也组织大家一起分析业务设计功能、编写功能设计说明书，但理解上确实还不够令人满意，大部分人还是似懂非懂。遗憾的是，在老板的规划下，新一代的系统开发必须启动。

    如果这时候开发基础框架，大家根本不理解以后这个基础框架之上要编写什么样的应用代码，那么这个基础框架就会变成形式，以后的应用代码怎么都觉得这个基础框架没什么用，用起来也是格格不入，不像是螺丝对螺母那样合缝。

    所以，我先安排团队开发了系统管理工具。这是个没有具体业务的，而且通用的，而且也是基础框架的一部份的开发工作。但是，由于系统管理工具，涉及到了新的组织结构模式，新的权限控制模式，这是大家不太熟悉的。而且编码架构风格和他们以往的开发不太一样。所以开发起来也是疑问不断，需要实时复查代码，实时解答问题。

    终于开发完毕，我们开了一个总结会。大家都总结了对这次开发的体会，并且讨论出来以后再遇到这样的问题要如何解决，每个人的分工和人员配合流程再次确定，功能和功能的用意再次给大家讲了一次，对于新的编码架构风格再次讲了一次好处和用意。大家都说：如果在开发前就把这些讲清楚了，那么开发就不会遇到这么多问题了。我说：开发前我就是这么讲的，但是大家都不理解。这次经历过来了，就明白了。

    接下来该怎么办？

    我说：重新开发一次系统管理工具。时间为期十个工作日。

    大家都啊了一声。干吗要重新开发，好不容易开发出来就这么废了？

    我对大家说了我的经历，我说：系统管理工具是基础框架的一部份，是以后用户很常用的工具，而这个工具却是我们在不清晰不熟练的阶段开发的，我们如何能把这么重要的基础功能jiāo付给客户呢？尤其以后这个工具要和需要系统结合，这个工具的数据结构目

『加入书签，方便阅读』