一个项目跟了3年了，始终是BUG不断，需求永远没有停止，这是个什么项目
作为一个Leader，一半的工作是在解决bug，另一半时间基本是需求讨论，任务安排。动力也是相当澎湃（Bug，需求驱动*呵呵），过五关，斩六将，一个个的BUG在我的keydown下被消灭了，一个个的用户需求变成程序功能了。
系统是asp.net框架的网站，数据访问采用了openFx框架(其实就是实体映射，简单的数据处理不用写SQL语句，复杂的还是写存储过程调用)，后勤系统是CS架构的Winformy应用程序，另外还有2个手机APP支持，采用WCF交互数据，框架没什么问题，起码绝大部门的BUG都不是框架的原因，所以我对这个框架还是挺信任的。我基本总结，bug是出在业务逻辑开发这块上面。
我们的业务逻辑怎么开发呢？由于我们系统是内部的订单管理系统，大部分还是内部人员使用。所以是由各个业务部门的系统接口人负责提出所需要的功能，由我们IT负责实现，IT这边分工有需求兼测试人员，项目组长，程序员，这个时候需求人员和用户沟通所需要的功能，大的功能是项目组长和需求人员一同和用户沟通，功能如何开发主导还是在项目组长，需求人员只是记录具体的实现方式，整理成文档，交开发人员完成coding.之后需求人员对任务进行测试，通过后项目组长将任务发布上线。并且和用户代表一起对上线后的功能进行验证。这样一个开发流程就完成了。可是这个功能在交付后经常会出来很多的bug。而且在用户体验上也感觉不是很好。为此，boss对我们的IT团队的成见还是挺大的，而我们也时刻和用户解释着系统怎么使用，时刻担负着各种罪名。
我要说的一点是我们的需求文档基本上开发时能见到，功能上线后就无据可查了，小的改动都没有进入文档，也没人维护文档，文档其实是有的，只是后期的文档基本和程序功能相差太大，没人愿意去看了。一旦有出现系统问题，测试人员只能凭着记忆检查是否是系统问题，实在不行就找开发查代码检查。因此解决问题的效率也是比较低下，反复沟通，线上的bug开发人员没有数据库权限，没办法调试，所以基本上是开发组长检查代码，检查数据，查询日志来分析bug的原因，立即处理掉，或者屏蔽功能，安排任务重新开发并测试，之后上线。对于需求文档人云异云，有些说整理文档人力成本大，系统开发局限大，对快速开发不利，有些说没有文档，开发没有标准，后期有问题无处可查，总之，现在我们文档由于人力不够依然还是没人维护。
程序员这边其实也挺*的，没有什么开发规范可遵守，基本靠程序员自觉写备注，自己组织代码，按照当时的需求文档或者口头描述进行开发，当然开发之前项目组长对数据库设计已经完成，大体实现方式也是组长确定好的，口头和组员描述清楚，让组员参照开发，详细的设计文档就没有了，写文档也是太费时间，为了赶进度，或者说小公司没有那么多的人力成本投入。遇到技术难关，组长和组员一同查资料，共同解决。
系统的规模其实也算中等吧，代码行数约50W行，年处理订单量约100W个，并有上升趋势，用户数约5W，实时在线平均300人。第一年开发测试约12人，后两年平均5人。现在系统是每周发布一次更新，基本上发布时会有各种问题，脚本没更新到，代码没更新到的，数据为匹配好的，一个中午就在解决问题，到了上班时，员工上班了，也陆续发现一些问题，然后一下午多半就在解决问题，之后的一个星期系统能够平稳一些，偶尔出来些BUG，立即解决。
系统这么多的BUG，这么多的更新，始终伴随着没有很好的办法解决。我想这也是软件的通病吧，可能有些软件要求严格一些，bug会少一些，而我们的bug实在太多了。以前是开发一个任务发布一次，现在是每周发布一次，也减少了一些BUG出现的几率。需求方面，现在也进行了控制，项目组长兼产品经理职务，对需求进行把关，过滤掉了很多效益不高，要求不合理的需求，需求量也减少了。我们还可以有多一些的时间对系统进行优化，部分代码进行重构，以确保提高系统可维护性，可扩展性。在代码控制方面，组长在发布前一天检查组员代码，对一些代码结构性不是很合理的要求改正，必要的重构代码，重新测试。我希望在我们的团队的共同努力下，系统能够更稳定的长久运行，为用户提供更多的便利，为公司带来更多的利益，为软件同行带去更多的经验。