（转载）如何提高软件项目的交付成功率

在大量的软件团队与项目的管理实践中，经常将软件项目与建筑项目进行类比，认为两者之间的关联性、相似性非常强。然而，我们回头看看真正的软件项目实践的结果就会发现，软件的质量、交付满意度、成本控制等完全不能和建筑项目相提并论 （如果哪个建筑工程的质量像软件一样Bug巨多、边用边改，楼估计早塌了）。

是研发人员偷懒了？是项目经理没努力工作？

1. 都不是，软件项目的开发阶段特有的复杂性是导致项目成功率低的核心原因（一家之言，深度的分析还是要参看Brooks博士的《人月神话》 *_*），情况分有三不懂：
2. 代码别的岗位看不懂。导致产品经理、甚至客户无法进入到研发的语境中进行探讨、检查与思考，经常产品一句话，研发做得想死；
3. 代码换研发后看不懂。由于阅读别人写的代码需要进入原作者的问题思考逻辑，大多数研发不喜欢阅读、修改别人的代码。因此，一旦出现核心人员离职等原因撤出项目，换一个研发来接手原来的代码，项目的质量、进度立即收到极大影响；
4. 代码久了之后自己看不懂。导致项目长期维护后修改周期长、改一个问题出三个问题的情况频频发生。

各路大神为了解决问题不断的研究理论并从各个层面付诸于行动，从瀑布流程中极度重视设计、到敏捷开发拥抱变化、从TDD（测试驱动开发）到MDD（模型驱动开发）、从原生开发到中台化、从SOA到微服务。

经过不断的进化，解决了诸多的问题。然而理论很完美、现实很骨感，软件项目的成功（本文中成功的定义是成本、质量、进度以及客户需求匹配度四个方面取得了均衡）仍然充满了不确定性。

为此，我们开始探讨、验证更激进的解决方案，我们称之为LDD（逻辑驱动开发）。（我们开发了一套图形化开发设计平台和运行时解释引擎）让软件的业务逻辑实现只绘制一个逻辑图（类流程图，每个执行步骤中进行些许配置即可），让代码只是在必要的时候成为其中一个步骤甚至只是一个步骤中的部分配置，以此来解决三不懂的问题：

1. 别的岗位可以看懂。产品经理可以和研发一起针对每个业务逻辑的实现进行走查了，走查时候可以清晰的看到逻辑的实现方式，确保与产品设计时的思路可以是满足的。同时，产品经理也可以带着逻辑图与客户进行交流，帮助客户更好的理解产品的实现思路，为软件项目的成功提供前置保障。
2. 别的研发可以看懂。由于就是一个类流程图的逻辑实现图，好理解，研发人员进行更换/离职时，其他研发同事的介入会更简单。同时，由于能快速、准确的理解实现的方式，也就不容易出现业务逻辑开发中常见的改一个问题、出三个Bug的情况了。
3. 代码自己能看懂。对项目中的整体逻辑思路，研发人员往往是不容易遗忘的（容易遗忘的是写代码的细节想法），通过逻辑图，时间过得再久也能轻松修改以前自己的程序。

从各个（MIS类）项目的实践情况来看，软件项目的开发质量、效率有了非常明显的提升，而且从长期来看可以有效解决人员流动后导致的企业/项目风险。

我们目前已经把这个平台进行了SAAS化封装（并且在持续升级中），如果有小伙伴感兴趣，请加我们的团队公用微信账号（jmcoding_net），并关注我们的网站（https://www.jmcoding.net）或者我们的开发平台（https://dev.jmcoding.net），我们可以一起研究、一起来写更多的组件（逻辑的每个执行步骤都是通过一个组件进行执行，计划中我们团队自己实现的后续组件代码将全部开源）。引擎的使用时免费的；设计器的个人使用也是免费的；我们还可以为企业做本地化部署服务哦（为了开发平台可以长期的优化、开发下去，针对企业服务有少量的费用收取）。

来来来，看看我们的一个业务逻辑怎么用图画出来（顺便说一句：设计平台的所有后端逻辑接口也都是使用逻辑图的方式实现的）：