失败经验总结：对一个“失败”项目的审视

我并非牛人，却已经做过很多傻B的项目。有的项目初期设计非常牛B，但是随着时间的推移、人员的更迭、预算的缩水，到头来变成了一款鸡肋的产品——食之无味弃之可惜。

以下几篇文章，我会从架构设计、实际编码、人员管理等诸多方面来分析一款我设想得很牛B，最后却做得很傻B的项目。当然，我这里所谓“傻B”，指的是一种主观上的失败，只是从产品的架构上、编码上、人员管理上分析得出来的一种结论，这种结论与该款产品的持续开发可能性及盈利可能性等无关。

我们来了解一下这个产品的产生环境以及需要解决的问题（这是个网吧行业的产品——牛B的产品各有千秋，傻B的产品却总有相似的缺陷和遗憾。即便没有涉足过网吧行业的朋友，但凡有过开发上的失败教训，相信也能从中感同身受）。

近年来，网吧计费产品市场有了新的需求：
 

对于网吧业主来说：随着众所周知的原因，网吧行业已经逐渐变成了江河日下的薄利行业。同时有些网吧的网管和外部公司串通，盗取网吧收入的现象比较严重，因此网吧业主需要一款能够帮助他们杜绝网管盗帐的产品出现，即便这款产品仅仅能够实现每天向网吧业主报告网管是否盗帐的功能也行（而以前的网吧管理软件都是简单地对每个网吧的费用进行计算）。

对于网吧计费软件公司来说：网吧计费系统经过10余年的发展后，针对独立网吧而言可以创新的业务越来越少。失去了新业务的刺激，网吧计费软件的收入必然下降。此时很多网吧计费软件公司希望借助当前最流行的大数据概念，为网吧提供新的、具有一定粘度的业务。同时也希望通过一款产品将网吧数据进行收集，从而通过后续数据的分析将自己从一个软件生产—销售商转变为网吧业务服务提供商（服务为王啊！）。而此时的网管盗帐事件的频发刚好给了一个机会。

此款产品的设计就落在了我的肩上。我当时分析此款产品的主要目的应该是以下两个：

1：解决网吧网管盗帐问题。

2：汇集网吧数据：

一来为网吧提供大连锁的功能，

二来这些数据将作为以后为网吧提供更详细服务的依据。

三来当网吧硬盘出现损坏，或者网吧网管直接删除数据库中营业数据时我们能够提供实时的数据恢复。

OK,分析结束后，就开始书写设计文档了。由于我开发过游戏服务端，而此款产品从架构上来看和MMO游戏有些类似，因此设计架构对于我来说毫无压力。架构设计、产品立项文档、性能分析等等一气呵成。哈哈，心中有点沾沾自喜。

接下来就是人员工作划分：
 

我需要开发11款服务端程序，不要紧，咱有服务端开发模板。所以服务端开发毫无压力可言。客户端开发1人是非常精通网吧业务的小伙，也无压力。至于DBA不怕，2个人都是对于SQLSERVER非常熟悉的人，应该没有问题。性能方面，为了提高效率，我们采用了直接调用存储过程的方式来进行业务处理。好，说干就干。我们行动了起来（殊不知如此轻率的决定却为以后项目进入泥潭埋下了祸根）。

从立项到开始进入测试（中间衍生出了另一个产品），共用了几个月的时间。当开始测试的时，才觉得噩梦开始了（不仅是产品设计方面的噩梦，公司由于变动也遇到了最大的一场动荡。）

出处：http://fxh7622.blog.51cto.com/63841/1430058