在正常的自动化过程中会发生什么？ 拟定了技术任务，功能要求，体系结构以及许多其他文件。 它描述了所有条件，限制，取决于环境的工作算法，表格的外观，数据验证等。 通常，这些纸的设计和协调要比自动化本身花费的时间更长。
出现一个项目，时间表，任务分解，某个项目经理，甚至几个。 手续接管，即 形式，而不是内容。
很明显，在某些情况下这是采取行动的方式。 例如，如果外部公司从事自动化，那么没有此类文件将无法生存。 他只会在达到失控要求后追赶。 论文保证了稳定性，付款的可预见性和工作交付。 但是对于客户而言，这些纸只能保证一件事-一个漫长而无聊的项目，不会带来任何收益。
在业务编程中，此方法不合适。 让我提醒您，业务编程是一个复杂的更改，同时对于流程，动机，目标，管理系统（由自动化支持）而言。
例如，您决定更改过程。 没有人影响一千人-您的膝盖没有解决方案。 例如，该过程涉及一个部门的五个人。 所有这些人，就像他们的领导者一样，都坐在您旁边-在这里，与他们保持一定距离。 然后，您决定与他们一起更改流程。 他们坐下来，交谈，想通了，想了决定。 例如，您花了一天的时间来更改流程。
在大多数情况下，更改流程后，您需要自动化-您需要对信息系统进行更改。 如果您说的是-您需要技术任务，时间表，由负责人，策展人和赞助商组成的项目，那么仅此而已。 这是您的更改将结束的地方。 一个漫长的具有项目手续的自动化项目将否定过程变更。
尤为重要的是：过程的变化就是实验。 您，即使是经验丰富的业务程序员，也无法确定更改是否有效。 所选择的方法可以在另一个过程中显示出很好的效果，甚至在完全相同的情况下也可以显示出来，但是在不同的公司中显示出来，但是在这种情况下，它可能会失效。
由于这是一个实验，因此它有时间限制-今天已经考虑过了，明天就要发布了，我们仔细观察一个星期并做出决定。 如果一切顺利，请离开。 如果没有，我们会进一步考虑-取消更改，或者改进并改进它。
本周自动化将发生什么？ 如果您选择传统方式，那么一周之内您将只完成技术任务，然后在最佳情况下。 因此，更改的实现将必须手动完成，而无需自动化。 好吧，如果您进行不需要自动化的更改-您可以“肉眼检查”。 如果没有呢？
这就是需要快速自动化的原理。 实际上，其实质在于名称-必须在没有协调和要求的情况下，对系统进行快速更改，而更改的范围必须恰好达到测试您通过更改过程提出的主要假设所需的程度。
您不必担心界面，检查输入数据，代码的最优性，数据结构以及“正确”自动化的其他支柱。 您的任务是快速支持流程变更的自动化，以检查变更是否有效。
快速自动化的原理为所有程序员所熟知。 只有他们知道这不是原则，而是极大的邪恶-人们认为无知，平庸和初学者都从事这种自动化。
部分程序员是正确的。 但是它们有着根本不同的环境。 毕竟，通常情况下如何完成。 有一些“骗子”-业务分析师，用户及其领导者。 他们在那想出了点什么，然后说-所以，很快让我成为一个形状/视野/窗户。 什么，如何，为什么，为什么-不解释。 仍然添加-快来，靴子。 程序员还有什么？ 如果有机会，他将开始努力-说这不可能，因此您需要技术任务，周到的架构，重构等。 但是，通常，作弊是不可能的，程序员只需在极端编程模式下“跪下”就可以快速作弊。
好吧，好吧，和他一起死吧？ 我确切地提出了这一建议-很快，没有麻烦，如果它可行的话？
当“叛徒”看到变革的意义时，关键时刻出现了。 业务程序员只是取消了这些更改，并要求程序员删除引入的代码段。 那“骗子”呢？ 或者，更确切地说，是“骗子”？
他不会取消任何东西。 只需保持原样，并且充其量就可以继续进行更改。 你懂吗 如果不取消以前的版本，它将越来越多地产生新的版本。
这是一个政治时刻，尤其是如果部门负责人想出了这些变化。 对他而言，不要显得愚蠢至为重要，因此，无论他发明了什么废话，他都不会取消它。 此外，如果将其推向墙壁，它将保护其更改。
大多数情况下，没有人会使用所做的更改。 如果您是一名程序员，那么您可能很熟悉这种情况。 他们要求，下令，要求制作某种系统，然后他们没有使用它。 它甚至可以“不屈膝”地完成，但是通常可以满足“正确”自动化的所有要求和条件，但是他们仍然不使用它。 现在你知道为什么了。 以及为什么没人从系统中删除此功能-您现在也知道。
这就是毫无意义的，错综复杂的自动化分层馅饼的发展过程。 程序员笑着说，但随便怎么说。 渣土，非最佳性，曲线结构和体系结构像滚雪球一样增长。 而且，停止这一过程并将其逆转越困难。
另一个问题是所提议的变更总体上毫无意义。
在业务编程中，任何更改都有一个目标，所有参与者都应理解。 该过程应该变得更快，或更可靠或更受控制。 因此，更改的目的和评估其有效性的标准始终很明确。
但是，当更改“就这样”，“使它对我来说更方便”或“很好，也一样！”进行更改时，就无法评估结果。 因此，无论变化多么无意义，变化都将持续存在，无论是在过程中还是在自动化中。
现在您了解了问题所在-流程更改和自动化之间的差距。 当某些人提出了流程中的更改，然后将自动化任务设置给其他人而没有解释其含义和本质时，我们会得到一个普通的混乱，对任何人都没有好处。
按照业务编程的标准，工作是在一个团队中进行的-来自流程的人员和来自自动化的人员。 更好的是，当这项工作由一个人（业务程序员）领导时。 当他自己进行自动化时，甚至会更好。
在这种情况下，我们了解并管理临时更改的生命周期-进行更改的原因，何时开始以及最重要的是何时以及在什么情况下终止。
假设更改是错误的-这是正常的，那没有什么不对。 然后程序员要完成一项不寻常的工作-删除系统中的更改。 当然，他们有时自己做这样的工作-例如重构。 但是在业务编程的情况下，此类工作必须定期进行。
如果更改是正确的？ 然后，“正确的”自动化的所有技能都发挥了作用，程序员为此感到自豪。 您需要估计架构，数据结构，算法，输入数据的验证，接口等。 但是，有什么区别呢？
问题陈述形式的差异。 通常这是一项技术任务，即一张纸。 在我们的例子中，任务是一个原型。 表现出自己的用处和效力的工人，可以说是在战斗中经受了考验。 只需要记住它。 您实际上并不需要协调和讨论任何事情，只需按照创建程序的环境的规则和标准来采用它并构建一个系统。
如果您一直都在从事快速编程，那么您将很快掌握该技能-立即进行操作，以便稍后进行修复。 在这里，程序员的“懒惰”将发挥作用-他将不愿意两次解决相同的问题，他本人将想出如何快速制作原型并将其以最小的努力变成完整的解决方案的方法。 尽管在业务编程中，当然没有完整的解决方案。
现在，它已成为诸如原型设计和建模之类的通用实践，当在开始大型自动化项目之前，以最小的努力迅速而又没有界面的麻烦，他们就可以创建将来系统的特定原型。 众所周知，这与快速自动化原理非常相似，尽管重点当然不是原型的创建方式，而是如何适应不断变化的环境。
如果原型制作只是一家集成公司的营销策略，然后无论如何都会出现一大笔纸，就像技术任务一样，那么这只是一个把戏。 它给客户带来了一种幻想，即“一切都会按照我的需要”，但可惜的是，生活中并非如此。 原型寿命不长，并且会消失不见。
现在您明白了为什么。 自动化几乎总是手推车，而不是马。 马是过程的变化，然后是推车。 但是只有与马匹相依才能骑行。
马转过身，马车跟着。 稍有延迟，有强烈的反冲和漂移，但转过身来。 如果每个马车都过着自己的生活，那么必须由不快乐的程序员来搬运马车。 在大型自动化项目之前创建的大型系统的大型原型是快照，即将马绑在推车上的快照。 一切都很美，每个人都很高兴，每个人都喜欢，但是一天，一周，甚至一个月过去了，马把车扔到了需要的地方。 而且手推车漂亮，优雅，根据所有规范制造，它仍然可以在野外独自站立。
因此，“大”的原型设计是不值得的。 以及“大型”自动化。 为了启动并执行一项大型自动化项目，必须有一个该死的非凡头脑，远见卓识和不可思议的管理人才。 如果这些话是关于您的，那么我衷心祝贺您，并祝您一切顺利。
我建议其余的使用快速自动化的原理。
我再次提醒您：自动化遵循流程的变化。 不是在变更之前，不是在变更之前，不是与变更分开。 他们改变了过程，迅速地自动化了，查看了结果。 好-很快就可以想到。 不好-扔掉。