what is your "Dream" project?

"Dream" project, 梦幻般完美的项目？梦寐以求的项目？我被拷问到了这个问题：what is your "Dream" project？

其实一直以来我寻找去实现一个"Dream" project很久啦，所以很兴奋被问到这个问题，嘿嘿。就我个人来讲，对于这个问题的答案，我愿意从"Dream" project的目标、手段、场景这三个方面来回答。

目标

"Dream" project就是不断地被愉悦满足的过程，对我来说绝非追求完美。

设计并实现一个项目，说毫无瑕疵既然是绝无可能的，要能最大程度的使用户满意，则是一个项目所追求的首要目标，归根结底，是人在用工具。一个开始有较多缺陷但用户认可其价值的项目，能让用户渐入佳境。而一个较少缺陷用户却不认可的项目只会把事情弄糟，非不巧，实弄巧成拙也！

要做有建设性的事。做一个新项目，总要有建设性贡献体现出新意才行，不然作出一个新东西来干什么？应当就像挠痒恰挠到了痒处，使人浑身三万六千个毛孔无一个不舒坦。隔靴搔痒，使人浑不得劲还左右别扭的哪里有建设性？那是噱头。

要把事做到极致。无法把一个项目做到完美，但把它做得足够深入总是可以的，无法把一个项目方方面面都做到极致，但把其关键处做到极致总是可以的。

要能保持演化。"Dream" project不是天生丽质，它也是千刀万剐方成佛。就比如一个新生儿一开始走路跌跌撞撞（一开始走路有很多缺陷），坚持下去（不断演化），最后不但学会了走，更学会了跑，没准以后还能学会飞（呵呵）。如果他不学走路总是爬（一开始爬缺陷较少较容易），那这辈子可想而知。

要能丢下包袱。这世间总是在变化的，一个"Dream" project也应当不断弃旧迎新，才能总是保证轻装上阵。有很多项目最初实现的很好，却被历史包袱连累，旧事物不舍得打破抛弃，渐渐地项目团队和用户双双被时间拖垮。什么是包袱什么是行李？对"Dream" project而言，代码，文档，UI都是包袱，只有实现过程中积累出来的有关面对变化保持flexible的特定建模经验和能力才是行李。

手段

保证资源的充分利用。足够的时间和金钱，往往不能创造出成功的项目，有限但并非贫瘠的人力物力，创造出来的项目，却可能褶褶生辉，有压力才有动力，限制驱动创新。

统一认识。一个团队必须有坚定的统一的认识，什么都可以变，可以有分歧，基本出发点不能变，不能有分歧，否则不如回高老庄好了。

作足够好的事，而不是作足够多的事。伤其十指不如断其一指，想一开始就给方方面面打好基础的想法是错误的，资源有限摊子却越铺越大，就最后什么都不是。

保持协作。开发团队内部之间，开发团队与客户方之间，都要有足够的沟通和协作，说出来写出来的东西，总是会和想的有误差，紧密协作才能保证项目的实现不断往正确方向修正。

保持激情。一个有激情的团队才能创造出有激情的作品，一个有激情的用户才能描绘最激动人心的蓝图。

保持纯粹。一个"Dream" project只做该做的事，而不是做能做的事。觉得一个功能好就应该加到系统中的想法是危险的，也许能用不如必须要用，不信你把所有能用的化妆品都抹脸上试试？

技术并非那么重要。技术相当于化学反应中催化剂，好的技术仅是促进"Dream" project的实现而已。

放弃依赖理论或者工具而成功的想法。RUP阿，MSF阿想想也就算了，VSTS系统阿也并非万金油，刻意强调团队角色划分也是有害的。沉迷这些东西，容易画虎不成反类犬，就像一个人卖弄口才，没人会觉得他的话有道理，只会说他油嘴滑舌，效果适得其反。

流程只是规避风险的手段之一。流程规范化完整化本身就是一种风险，把人像工具一样限制死，也许能做出完成的项目，但决不会是成功的项目，更不会是"Dream" project。

场景

我理想中的"Dream" project是这样子的，在我以前当项目经理时我也曾试图实践过的：

• 成员构成：4至7人的开发团队，开发与测试2:1（不是常规的1:2），开发人员自己单元测试，测试人员集成alpha测试，客户方beta测试，有一个team lead，不用项目经理，客户方开发项目则有一个客户代表，开发产品则有一个产品经理，性格互补，能力各有所长均是熟手，关系融洽，能就事论事地争论问题。
• 项目规模：代码规模10万行以下（不含单元测试代码），二级功能模块（最小粒度功能的一次抽象视为二级功能）30~50个左右。若项目再大则需要拆分子项目，子团队。
• 开发周期：每周一次团队全部成员与客户方的（客户代表或产品经理）集中沟通，约1小时，平时也能保证不必是即时但能是有效的沟通。单元测试代码+用户手册等于所有文档并保持同步更新。有bug库和版本管理工具，版本分支并行开发同时不超过2个。每个月一个里程碑，每三个月一次大版本更新，每十二个月一次功能级代码重构。
• 资源保证：团队成员有足够的稳定性，不会突然大量流失，客户方需求有基本共识不会大幅度更改，总能保证未来一月的时间和财力是团队可支配的。
• 项目效果：项目每一个里程碑版本要有至少1个（保证版本更新的意义）不超过5个（保证实现的质量和深度）的新功能。不必刻意避免bug，但必须保证流畅。功能不必完美，但一是一二是二，不能求妥协搞个1.5，要必须保证纯粹。项目UI不能只是简单堆砌，要必须保证简洁统一。
• 项目周期：开发周期和维护周期1:1至1:3，维护期团队可减少到1至2人，开发周期至多不超过2年，然后项目关闭，再有新的需求，则启动新项目。

这样的场景，基本上能满足我前面提到的目标和手段，欢迎你对我的浅薄认识和经验提出批评意见:)