我正在寻找在启动环境中跟踪开发人员和其他所有人（支持人员/管理人员）的业务规则的最佳方法。我们面临的挑战是，我们的业务模式需要相当多的不同业务规则，这些业务规则几乎可以随时创建，并在此之后有机地发展。在运行这个项目3年以上之后，我们有很多这样的规则，通常唯一能确定应用程序在某种情况下应该做什么的方法是找到负责该过程的模块并分析其代码和评论。只要你有一个开发人员从头开始创建整个应用程序，这一切都很好，但是每个新开发人员都需要遍历整个代码库才能理解应用程序的工作方式。更大的问题是，非技术人员甚至没有这种选择，因此每天都被迫几乎问我应用程序如何处理某些案件。
快速示例 - 我们只有在客户广告系列活动至少72小时后才开始为其付费，但与此同时，我们停止为属于破产帐户的广告系列创建发票，并在一个月内关闭此类帐户首次失败的充电。这不适用于设置为“不收费”的帐户，这些帐户最常见于我们，因为我们自己使用该服务。发票在每个月的1日创建，包括上个月的费用+帐户可能具有的任何当前余额。但是，由于计费部门的问题，一些客户在收到发票后仅4天就会收取费用。除此之外，还会在客户停用其广告系列时创建发票，但只有在广告系列不再符合强制性的6个月合同时才能创建发票，除非客户经理批准提前停用。
我知道，在回答“我们何时向客户收费”这个问题时需要考虑很多规则，但实际上我仍然可以在每个句子的末尾添加一个星号以便披露一些罕见的例外。当然，将业务规则保持在最低限度是最简单的，但我们需要适应不断变化的市场 - 即不到一年前我们没有任何合同。
我到目前为止的一个想法是一个简单的维基，其类别对应于“帐户激活”，“开票”，“收集程序”等区域。另一个想法是拥有巨大的交互式流程图，显示从探矿到帐户停用的整个客户“生命周期”。
您有什么经验/建议？
答案 0 :(得分：0)
维基似乎是一个很好的起点，但你应该放置一些结构，这样它就不会变得一团糟。
答案 1 :(得分：0)
Wiki很好。你需要（至少在发布后的一段时间内）有人负责维护它，谁有足够的时间这样做。
如果您同时拥有技术人员和非技术人员，您可能会发现使用支持WYSIWYG编辑器的Wiki更容易。
您可能还会考虑共享的Google文档文件夹。
答案 2 :(得分：0)
我建议：
结果：业务用户可以跟踪更改（电子表格有历史记录），开发人员可以跟踪哪一段代码是b.rule