Principles of business modeling

Once you understand who "God" is, you must be patient with God. People who major in science and engineering are generally better at logical thinking, but for stakeholders, this is not necessarily the case. I once encountered a stakeholder who was doing archival work. When understanding the requirements, he rambled and was vague. The method that was clearly rejected one minute was proposed again the next minute. I thought I had a good temper, but in the end I almost lost my temper. Fortunately, I finally managed to survive. I think that after experiencing this incident, my patience index will be greatly improved.

I have a colleague whose patience I admire. In a website project, he was responsible for system analysis. He spent three full days living with the person in charge of the website project. After the final system analysis, he was in good spirits, but the person in charge was dying. Of course, this is just a joke, not to encourage everyone to work hard. The balance between work and rest is still very important. The body is the capital of revolution. But this tells us that if you lack patience, it is difficult to succeed in demand. For example, in a business modeling seminar, although you stipulated that this meeting will discuss high-level requirements, the participants will always argue about trivial matters from time to time. What should you do? I believe this situation is very common.

Patience will still be reflected in communication in the end. Only through patient communication can you uncover the veil of needs. People's behavior will always be guided by their thoughts. If you cannot untie the knot of the stakeholder, you will not be able to understand what he really needs.

One of my project stakeholders behaves very strangely. She always keeps saying one thing: she wants to automatically generate reports. Her needs seemed to fall within this range, but I heard almost nothing else from her. At this time, I decided to give up. I thought there might be no more information from her. But after I learned that report processing took up a lot of her time at work, I changed my mind. After I spent some time helping her clarify her thoughts on report processing, she also gave me a lot of help in other aspects. An important practice of the XP method is to promote "on-site customers". That is, the customer should be with the developer at all times to provide information and make decisions. And this customer must also be an expert in the field and be able to make decisions with the authority.

On-site customers believe that most domestic software organizations cannot do this. But we must work hard in this regard. In my opinion, there are two types of on-site customers: one is project stakeholders, and the other is industry experts. In fact, many software companies will have some management consultants, who are industry experts. According to statistics, the ratio of consultants to developers in software companies in Guangdong Province has reached 3:1. I think this is a good thing. Project stakeholders often have a deep understanding of the transactional aspects of their work, but it is difficult to elevate this to a theoretical level. At this time, some industry experts are needed to help. Letting industry experts and project stakeholders discuss together can also inspire project stakeholders to think of aspects they had never thought of. This is the development of "latent demand". On the other hand, participation also means that project stakeholders need to devote themselves wholeheartedly to the business modeling process and be able to mobilize their enthusiasm. Therefore, a process that is too complex will hinder stakeholder participation. Therefore, it is necessary to use some simple artifacts that can be accepted by customers for business modeling. I have said that the "protagonists" and "use cases" discussed earlier are theories, and they are for developers to see, so that developers can have a clear idea. If you show this to stakeholders, will they understand it? By the time they understand this mechanism, I'm afraid the day lily will be cold. User Story, Feature, and CRC cards are all very good artifacts. They are simple and can meet the needs. Knowledge point: Both materials and features express a simple requirement of the user, which can be completed in a short period of time. Materials are artifacts in the XP method, and features are artifacts in the FDD method. CRC is the abbreviation of class, responsibility, and collaborator. It is a card divided into three parts, which respectively mark the class name, the responsibility of the class, and the cooperative relationship between classes.

It is very close to customers, and you can even fill in the card during the game, which can bring strong customer participation. I think this will be criticized unanimously by developers. After all, changing requirements is one of the things developers hate the most. Yes, I hate it too. However, just as we often say "crying cannot solve the problem", can hating solve the problem? Reject the customer's change request and require the customer to sign the requirements specification. These practices can only be counterproductive. There is no positive meaning.

Necessary requirements change management is important. Because endless and uncontrolled changes will inevitably cause a huge waste of resources. But on the other hand, the criterion for acceptance of demand changes should be "whether it is reasonable", and demand changes require our development work to be carried out iteratively, including requirements, design, implementation and other stages. This way the risk of change can be minimized. We will discuss this further when discussing specific requirements modeling.

The next level of embracing change is to anticipate changes in advance. Develop a list of possible changes to document possible changes. The simplest example is that after a company develops a purchase, sales and inventory system, it hopes to develop an accounting system to connect to it. If you can leave some foreshadowing in advance, I believe you can save a lot of effort. Another way to estimate change is through the use of patterns. But remember, don’t overuse patterns. These are off-topic topics, and I will focus on this aspect in other articles if I have the chance. 7. Practice of business modeling (Practice) Meetings are the most important means of business modeling. Although meetings have always been stigmatized in China, as long as they are well organized, they are a very effective means of communication. A modeling meeting is a large-scale meeting, in other words, all relevant people should participate in the meeting. Because during the business modeling period, the main purpose is to establish high-level requirements for the system, which requires the joint participation of many project stakeholders to ensure the breadth of requirements. Therefore, the scale of the modeling conference is quite large. Funders, senior managers, managers, direct users, developers, everyone should attend or send representatives to the modeling meeting.

If you have ever participated in a large meeting, you know that the larger the meeting, the lower the decision-making efficiency. This is normal. Because when you are alone, there is no need to communicate, and decision-making is most efficient. When two people are together, they need time to communicate to make decisions. When there are three people, it will take longer to communicate and reach an agreement. If there are four, five or even ten or twenty people, most of the time will be spent on communication. What's more, there are still differences of ideas and conflicts of interest between people. Therefore, in order to ensure the efficiency and effectiveness of the meeting, certain rules should be followed:

· Be prepared: If you are going to have a meeting and the participants do not even know the content, what will you do? You have to spend a lot of time explaining the purpose of your meeting first, right? The theme and agenda of the meeting, together with the meeting notice, should be sent to the attendees in advance so that they can be prepared so that they can quickly get to the point when the meeting begins.

·Invite as many people as possible: I have said that a modeling meeting is not a successful meeting if it does not hear the widest possible range of opinions. But in reality, this is often difficult to achieve. Because the target organization, as a customer, is often very pushy, it is simply impossible for everyone to be present before fully understanding the importance of the meeting. Objectively speaking, there may be reasons such as business trips, vacations, important matters, etc. that make it impossible to do this. Here, on the one hand, you need to clarify the interests and harms to the decision-makers of the target organization and let them pay attention to it. On the other hand, you also need to proactively invite project stakeholders to participate. Since it's impossible to invite everyone, just try to invite as many as possible.

·Separate the levels of attendees: I really like conference rooms that have an inner circle and an outer circle. Because it is impossible for me to invite everyone, I first have to ensure that all the core staff can be present and sit in the inner circle, and then the secondary staff sit in the outer circle. Key people are the kind of people who are closely related to your project. For example, in the financial system, the financial director is the core personnel. It is necessary to ensure that all core personnel are present, and as for secondary personnel, the more complete the better.

·Start from the bottom: Chinese people have a bad habit, that is, when the boss says one, he will never say two. So let the bottom level speak first, then the middle level, and then the top level.

Developers don't speak, they either listen or guide everyone to talk. If we let the leaders lecture us from the beginning, then the people at the bottom won’t have to say anything else.

·List all the opinions of all stakeholders: First, let everyone be able to speak freely about the new system, and then list all opinions on the whiteboard. There may be some ideas here that are ridiculous, but that’s okay, just write them down. This is a brainstorming process, and it is easy to generate new ideas. The main job of the hosting developer is to guide and encourage everyone to express more ideas and record them. Let's digress a little here. Some people say that most Chinese people are reluctant to express their opinions in meetings. I don't think you need to worry too much about this in this kind of modeling meeting. Why? Because project stakeholders do not need to take any responsibility for their speeches. If you say it, it will be in vain. Whoever doesn't say it will be in vain.

·Category ideas: Your project stakeholders must be a little tired, their ideas are almost gone, and your whiteboard is probably full. But if you look at the ideas on the whiteboard, many are repeated and many are similar. So you need to use logical concepts to categorize these ideas. You can also guide everyone to do this work.

·Prioritize: Prioritizing ideas is also very important. It can help you identify significant risks and provide guidance when developing iteration plans. Again, this work should also be determined by the project stakeholders.

·Investigating the main business logic: What is the main business logic? It includes the company's main business processes, main business rules, and major algorithms. This is all information that needs to be made clear at the outset and needs to be understood in the modeling session. Of course, you can't say to your project stakeholders, this, next, let's talk about the main business logic. The stakeholders below must be left scratching their heads. You should still guide stakeholders and capture the information you need from their words.

·Pay attention to the meeting time: people are not machines and will get tired. So controlling the length of meetings is critical. Generally, this kind of meeting lasts four or five hours. According to statistics, meetings within two hours will not cause fatigue. So the meeting should be broken into short segments. In addition, you can also decide the number of people participating in each short meeting based on the progress of the meeting. Because, as the meeting progresses, some participants become less important.

·Avoid details: The main goal of the modeling session is to establish high-level requirements. If too much time is spent discussing trivial matters, it will be a waste of everyone's time. There is little point in investigating the details of the requirements at this point. Because you don’t understand many things yet and need to delve deeper. The details at this point won't be of much help to you.

·Avoiding technology: During a modeling meeting, I met a stakeholder responsible for technology. He always kept asking about the technical architecture of the system and promoting his design concepts. I have to reiterate several times that we will find time to discuss technical issues separately. I think that the technician should have a better idea and hope to perform well. This is understandable. But this is not the time to discuss technology. The requirements have not yet been clarified. Isn’t discussing technology implementation putting the cart before the horse?

·Keep records: As the saying goes, a good memory is worse than a bad writing. So it is very important to take good notes during the meeting. Because the cost of such meetings is quite high, it is impossible for your project stakeholders to not work every day and accompany you to meetings. Even if they are willing, their bosses will not. Therefore, to make full use of the results of the meeting, an excellent stenographer is absolutely necessary. In addition, research shows that using a tape recorder will make participants feel reluctant to speak, so do not use a tape recorder. It may feel strange to mention testing in the initial stages of requirements. For every project, there is always a standard to evaluate whether it is successful. Testing here refers to an execution goal to assess the success of a software project.

This goal will be the final condition that software development must meet, and the criterion for determining whether the software is successful or not. Many enterprises do not have a relatively clear goal when constructing information technology. Therefore, when asked about this issue, his answer is often empty words such as my goal is to build the enterprise's ERP system and build the enterprise's information platform. How to develop such software? There is no standard for ending. Will it end when the fees are used up, or will it stop when the decision-makers say it will stop? Goals should have a quantifiable standard.

For example, the purpose of developing a logistics system is to shorten the product turnover cycle and reduce inventory; the purpose of developing a supply chain system is to strengthen connections with suppliers and reduce inventory. These indicators related to specific businesses can be measured by refining them and using multiple sub-indicators, so they can be achieved.

We call this goal a test to remind developers that meeting this goal should be regarded as the final test. No matter how good your software is, if it's not what stakeholders want, what's the use? This is a very simple truth, but in practice, stakeholders and developers often fail to see this due to some specific factors. In fact, we also talked about this goal in the previous article. At that time, we called it vision and scope. It's essentially the same. This "executable goal" can be measured using a number of factors: Business entities are categories in an enterprise that play a key role. Customers, suppliers, employees, orders, vouchers, there are many examples of such business entities. Business entities often become a very critical factor, because in the system, the behavior of roles operating business entities is often assigned to business entities. For example, "calculating prices based on orders" will be completed by multiple business entities in cooperation with each other. Therefore, the quality of business entity design will have a great impact on the system.

The main work of business entity design includes finding the business entity and determining the attributes and behaviors of the business entity.

To determine the business entity, you must first determine the role and find out the business entity from the role's behavior. The role requires us to discuss the target organization. In my personal experience, it is generally easier to find business roles, but remember that one person may hold several business roles, which is often the case. From the behavior of the business role, we can find out what the business role handles. These are the business entities we need. It is worth studying whether the business entity is a separate business entity or an attribute of the business entity. If a thing that is supposed to be an attribute is judged as a business entity, it will only bring some overhead. However, if a business entity that should be listed separately is just judged as an attribute of other business entities, it may bring disastrous consequences. , the biggest possibility is that the system is difficult to expand.

In a human resources management system, the employee class may be a very important business entity, and it may have many attributes. In other systems, such as purchase, sale and inventory, the employee class only plays a role in record and authority management. For another example, in some internal automated processing systems of enterprises, customers may be just attributes of some other entities. However, in the 21st century where customer-centered design is popular, this design has its fatal flaws. To determine the attributes and behaviors of business entities, it is mainly to determine what each class (business entity) does. The attributes are to better describe the class and what the class does. Using CRC cards is a good idea. CRC is the abbreviation of "class", "responsibility" and "collaborator". These information are often presented on a card. Class Name Responsibility 1 Auxiliary 1 of Responsibility 1 Responsibility 2 Auxiliary 2 of Responsibility 2... By making such a CRC card, it is easier to find out the behavior (responsibility) and attributes (auxiliary) of each business entity. You might ask why not just find out the properties and behaviors instead of doing all the trouble. This issue is what we have been emphasizing. In the modeling stage, we are faced with stakeholders who may not understand computer technology at all. Therefore, using methods that are easy for everyone to accept can ensure that the requirements are complete and correct. In software development, there are two extreme misconceptions about planning. In some software organizations, plans are generally not made, or some general and useless plans are made. Some developers believe that planning is futile and it is better to do practical things. For the project manager, there is either no way to deal with this situation, or the developers of the released plan work against the plan, making the plan a dead letter. There is great arbitrariness in project execution, and things that deviate from the direction often happen.

In other organizations, planning is regarded as a top priority, requiring a lot of time and manpower, and the plans made can be described as detailed and exhaustive. And project managers who can write such a plan are also regarded as senior talents. The developer sighed and said, "Those who write programs are not as good as those who write documents."

However, during execution, the original sophisticated plan was often full of loopholes, and the project progress was delayed again and again. We all know the obvious saying: In software development, spend 90% of the time completing 90% of the project, and then another 90% of the time completing the remaining 10% of the project. Why? The plan is unscientific.

In management, planning, also called planning, is defined as "the process of determining goals for an organization and the strategies and means, steps, and procedures to achieve them." For example, I want to push a box to a place. This place is my goal. In order to get there, I need to estimate the route and how fast I need to push it. Then I started pushing and comparing it with the original plan from time to time to see if I needed to adjust the route and speed. This estimate is the plan.

The goal of planning is not to eliminate errors, but to turn all errors into a bunch of carefully planned small mistakes. After studying four design methods, we finally gave up on three. At most, it was just three small mistakes. However, rewriting the program three times because of poor design may cause three big mistakes.

But why do the two extremes mentioned above appear? The first situation is actually the earliest form of the software industry. There is no plan, resource allocation is chaotic, and the software development process is in a chaotic, disorderly, and spontaneous state. The success of the project depends entirely on luck and the individual abilities of the project members. The second situation is actually an advanced form, the most typical representative of which is the waterfall model we mentioned before. So why does such a well-thought-out plan fail so easily? It's simple. You think you've thought it through, but in fact you may not. I have seen people who advertise themselves as well-thought-out plans with a schedule that is seven days a week. It seems he had no intention of giving developers a break in the first place. A plan is an estimate of the future. No one can accurately tell what the situation will be like six months from now. Before September 11, how many people could have predicted that such a big thing would happen on that day? Then why do you predict what will happen half a year or even a year later? Also, do you really know your developers well enough to feel confident making plans on their behalf?

Some people say that plans do not change quickly. This sentence is very correct. It reminds us that it is impossible not to have a plan, and it is not possible to have an executable plan. Plans are not for showing off, they are for execution. When we make plans, we don’t need fancy words or beautiful ideas. But we cannot live without some elements:

·What (WHAT): List in order the work required to achieve the goal;

·When (WHEN): What is needed to complete the work time;

·HOW-WELL: the standard by which the work to be completed is measured;

·RESOURCES: the people needed to complete the work/ Funds, etc.;

·Who (WHO): Who is responsible for completing the task.

But we still cannot escape the problem of the deviation between reality and plans. Although we don't have much certainty about what we expect to happen a year from now, we don't have much certainty about what developers are thinking. But if you think about what will happen in two weeks, you should be able to guess pretty well. This brings us to the concept of iteration. A project consists of several or even dozens of iteration cycles, and each iteration cycle is relatively easy to estimate and plan. This is the idea of ??iteration and a big leap in software engineering technology. Having said that, I want to whet everyone's appetite again. We will leave the discussion of the specific development of iteration plans to the next chapter when we discuss detailed requirements modeling. It's hard for me to imagine how a project would work without training. There is a saying in the military book, "The three armies have not moved, but the food and grass go first." We can understand that we must be fully prepared in advance. The same goes for projects. A training plan should be specified at the beginning and time should be set aside for training. I think that unless it is a perfect team, its members must still have something they don’t understand. If there is no training plan and the learning task is placed on individuals, the risks of the project will become difficult to control. Speaking of training, you may think that everyone is sitting there and listening to a teacher. This is not the case. The training mentioned here is a broad range of training. It can be a set of courses, a meeting, a discussion, or an exchange. The purpose is to equip team members with sufficient knowledge and skills to complete the project.