During software development, I often encounter this problem: "When a software function is implemented, the business personnel say one set, and the software personnel say one set ". Here, we can find out a pair of friends who are both conflicting and dependent on business and software. What the business personnel and software personnel say seems to be in conflict. In fact, they are the same: the business cannot replace the software, and the software cannot replace the business. Business personnel cannot replace software personnel, and software personnel cannot replace business personnel. The relationship between business and software in business software can be described as follows: business is the soul of software, and software is the body of business and a unity of interdependence. Business (industry) software can be implemented only when the business personnel and software personnel work closely together. In this process, the business personnel are responsible for refining the functions to be implemented by the software one by one and classifying and summarizing them; software engineers re-split these business needs (so software developers should have a thorough understanding of the business) and classify and summarize the business from the perspective of software implementation. The software interface can be determined by the discussion of business personnel and software personnel. In the initial stage of software development, the demand review stage. Software personnel and business personnel should be involved. The business personnel of the participants must have certain software development knowledge, while the software developers must have the necessary business knowledge. When you need to pay attention to the demand review process, the business personnel must give the software developers a clear explanation of the business context, otherwise, the software developed by the software developer may not be what the business Engineer wants. In fact, the demand review process of software products is a process of mutual learning. The software learns some necessary business knowledge, and the business also learns the necessary software development knowledge. Only in this way can the business software be fully functional and the software performance be superior. In business (industry) software projects, there should not be business personnel who are on behalf of each other and directly instruct software personnel on how to implement them. This should be resolutely put an end to it. The business personnel should consider the problem. After all, the starting point is the business requirements. They will not care about the software design principles, and may not fully understand the entire software design concept (reuse and expansion) of the software ). If a business engineer adds a field and a field, the software code will soon be in disorder. The consequence of code disorder is that the project's code is messy, and the maintenance cost is higher. At the end of the project, do not die or make ends meet. Of course, the company also has a solution to this situation: "Allow software developers to work overtime for free". This can indeed work for a while. But imagine if you are a programmer and encounter such a problem, will you work overtime all day to change the garbled code left by others without any idea? The personnel involved in the Requirement Review, summary and detailed software design review should be: business personnel, senior software developers and architects, and other project stakeholders. Other developers will be able to explain business needs by senior developers and business personnel in the future, so that business personnel can further understand the software requirements and understand the business) therefore, the relationship between business and software, as well as between business personnel and software developers should be clearly seen during business software development. Only by clarifying these relationships can business software development projects be on the right track.
To be continued
