[ZT] contractual Communication (Author: Wang Yonggang June 2004)

xiaoxiao2021-03-06  40

Contractual Communication (Wang Wei Gang June 2004) 1 Problem In the software development project, no one will deny communication importance in addition to a few self-righteous guys. But people tend to pay attention to communication skills while neglecting learning skills and communication methods. For example, I have experienced a unconfilled communication failure. If I have more understanding of communication, there is no need to complain about the sky here. Things happened three years ago. In a beautiful coastal city, it is a building that is comparable to the aerospace center before defeating a model. It is back to the mountain sea, next to a golf course and a famous car track. People who drive from the highways next to the highways are hard to think, this is beautiful, the chic building is actually a software development center created by a large state-owned bank investment. At that time, I was fortunate here to participate in a software project development work. What I said, "Participation" means that I will lead our company, I am constant in this software development center, and form a joint project group with a R & D department of the center. Cooperative development set will be within the whole range Promoted software products. This project involves two teams in our company and the development center, there are two competent leaders - I and the department manager of the development center, also involved our company, development center and development center - large state-owned bank three The interests of the aspects. I want to come now, develop software in such an intricate environment, and any communication problems will be normal. Things are due to the dispute between the two teams about the software architecture program. The software products we have to develop must provide services to hundreds of branches throughout the country, while also ensuring absolute security and reliability of data. Based on our past experience, such software is best adopted in a centralized deployment architecture, that is, deploying server software on a high-performance server of the Bank's national data center, distributing users across the country through security remote access mechanism Complete business operations. However, it is greatly impractive that all technicians headed by old H actually oppose centralized architectures with the old H, which is recommended to use the scattered deployment mode, that is, install a server in each country. All servers are associated with each other, together with data acquisition, distribution, synchronization, and query operations. It is necessary to declare that the purpose of this case is to discuss communication issues in software development, rather than distinguishing different distributed system architectures. In fact, both decentralized architectures or centralized architectures, they don't have advanced and backward differences, only problems for applicable and not applicable. I believe that if the reader understands the specific needs of our project and the actual operation environment of the software, most people will agree that centralized deployment is an architectural solution that is best suited for this project. However, what I encountered at the time, our company's technical personnel, regardless of the perspective analysis, I feel that the solution for the decentralized deployment is difficult, the operation is low, the maintenance cost is high, and it is not easy to ensure data. Safe, the team of development centers is to pass the results of our analysis, and persist in the decentralized architecture. During architectural analysis, as representatives of cooperation, I repeatedly argued with old H in project meetings, private chat, telephone communication, email, work dinner, etc., but never found a common point. I put a few technical reasons for the absolute standing to demonstrate the superiority of the centralized architecture in this project, but the old H is always simply, almost unfairly determined our plan stupid, naive, and It is the only feasible solution that said the decentralized architecture is. So far, I still remember that I have repeated more than 30 times with the following dialogue processes like the following, with the old H. I have repeated more than 30 times in half a month. When I communicate, if I said : "According to our calculations, the centralized architecture can save more than 500 hardware devices." Old H will say: "The old brother, we develop software, not hardware."

The decentralized architecture is the only choice. "If I said:" The centralized architecture does not need to develop data synchronization modules, which saves two people's workload. "Old H will definitely say:" Then spend two people, because the decentralized architecture is the only choice. "At this time, I generally say:" Use a centralized architecture, managers can more easily monitor and even dynamically modify the business process. "Old H will say:" As long as we have enough efforts, the decentralized architecture can also achieve the features you said, because .. The decentralized architecture is the only choice, why do you always admit this? "Every time I discuss what I must say is:" Centralized architecture can reduce the trouble of install and manage server software in each branch. "And the answer to the old H must also be:" Is it really trouble? But you know that you don't know that the decentralized architecture is the only choice. You don't recognize the advantages of the decentralized architecture, isn't this not a fun? "To be honest, I am still young and happy. I am very reluctant and recognizable. I can't tolerate someone else in more than 30 discussions in almost Hui. Guy. Finally, at the last discussion on the software architecture, I can't press the excited mood, stand up and say loudly to the old H: "We come here, sincerely cooperate with you to develop software. When designing software architecture, our business is indeed from the development center and banks. In addition, we also repeatedly explain the superiority of centralized architectures in the technical level. But I really don't understand what you think. You can adhere to the reasons for the decentralized architecture, you are not worth it. You have the only choice of a decentralized architecture that is ridiculous. To say, you are all people who are doing technology, why is this time this time is so uncomfortable? "I don't know how much waves have been thrown in my heart, I only know

Tao, I have been included in the "worst partner" blacklist, and our company and development centers have to come here. One month later, the development center is signed with another company and develops the same software product based on the decentralized architecture. Obviously, this event is ended in the complete failure of me and our company. If I still have a remorse for three years ago, I think, the most worthy of my reflection is that I have a brighter that I communicated. Now, everyone may wish to summarize, when faced with the collaborators who do not speak "technical truth", can we use other better communication skills? I mean, we can not communicate through effective communication, both the cooperative relationship with the development center, and is not as good as the company later, and moved to the development center's significant time-fitting scheme? 2 Some external questions, several large-scale state-owned banks have created relatively independent software R & D institutions in recent years (similar to other industries such as telecommunications, energy, electricity). Many people do not understand this: Bank is not a software company, why do you need a special development center? If the bank's software is developed by the development center, what other software developers do? It is said that the answer to this question and the argument of "IT outsourcing" a few years ago. In the past, IT talents in state-owned banks mainly concentrated on the scientific and technological sectors of the head office and all branches, and they were responsible for the maintenance of IT systems within the line and some software development. The software used inside the bank is mainly solved by two ways to be solved by the external purchases (core business systems and external applications of core business systems and technical difficulty) and self-research (including systematic and technically difficult peripheral applications with personalized business processes). In the past, the domestic IT boundary is highly passed: large enterprises can only save costs and improve IT levels to maximize the cost and improve IT levels, in order to make sufficient strength to compete with foreign companies after joining the WTO. However, for large state-owned enterprises, especially large state-owned banks, IT outsourcing is easy and doing difficulties. It is not to say that the domestic bank dares to let other enterprises manage their confidential data like some companies that have already achieved IT outsourcing, and the laxation of the IT staff in large state-owned banks will make All the people of the extravagant outsourcing is called hard. So, the domestic banks have grown out a road with Chinese characteristics: first investing in the construction of the software development center for independent operation, independent accounting, gathering the IT talents in the bank's internal level; then, Step-by-step, the development center assumes most of the research and development of most self-advantages, the software version of the whole line; when the time is mature, directly convert the brand's brand into "a certain software company" and achieve the bank's IT business overall outsourcing . This idea looks seamless, but also leaves enough room for future development - even if it is no longer needed to operate the IT outsourcing, banks can easily change the development center back to the IT department directly under the management, continue to maintain traditional ways It works. The only thing is not enough, such software development centers (or a future company) have become a competitor of all mirrors in the financial industry software companies and system integrators - this is an extremely horrible thing, because In the case of other conditions, the outsiders are also competitive, but the bank's own bone! Fortunately, the most horrible day has not yet come. In the actual operation of many banks, similar development centers become the best place to resettlement and diversion of the IT staff.

The result of doing this is that many development centers have inherently undergone many sinks of state-owned enterprises, and the phenomenon of foreign line leaders is not uncommon. The technical quality and work efficiency of developers are also worried. The overall research and development level of the development center is from the initial Ideal is far away. Because of this, some companies have good relations with banks, and there are also quite technical companies to obtain opportunities for developing software products and development centers, and the development center and other companies have not immediately led to the emergence of industry monopoly. I don't know if I explain whether the reader understands the background of this case. The main purpose of this article is to discuss communication skills during software development, but before case analysis, readers can know: "I" in the case is a partner of the cooperative company, "Old H" is the representative of the development center, and developed The center is also a sole proprietorship established by the bank (which is the actual customer of the development software), which is an inequality of cooperative relationship. In short, in a similar cooperation process, the development center can make a squid of our partners, and our company can't speculate in the development center as you want - unless we never want to do any business in this bank. 3 Case Study No matter how we emphasize communication in software development, it is not too much. Because today's software development is a teamwork process, and effective communication is the best to ensure team goals and behavioral consistency. means. In fact, almost all heavyweight and lightweight software engineering theories have design different methods and models for communication in the project. For example, the communication model given in the Microsoft Solution Frame (MSF) is shown in Figure 1. Figure 1 MSF Project Communication Model In Figure 1 We can see that communication in software development projects includes at least the following types: Program Management Development Test Release Management Product Management User Experience Business Perspective Technology Perspective End User End User Customer Operations and Support Sector Project Sponsor Technical Committee Project Group

.. Communication within the project group - Communication between different working roles in the project group (the basic work role of MSF recommendations), including: .. Communication related to business: .. Project group members Communication for Planning and Product Management; .. Communication to Software Demand and Specifications; .. Communication for Software Functional Testing; .. ... Communication; .. Communication between project management personnel and developers; .. Communication between developers and software publishing people; .. Communication between developers and technical support; ... External communication - the communication between the project groups and the external relevant personnel of the project group, including: .. communication with business: .. Communication with customers (discuss business processes, software delivery methods, etc.); Communicate with the project sponsor and managers (discuss project progress and project results); .. Communication with end users (discussions such as demand details, etc.); .. .... Communicate with the technical committee or technical person in charge of the company (technical review); .. Communication with operations and support (software issuance and support); .. Communicate with end users (technical support for end users and Help); .. .. Although different software engineering theories are different from the classification of project communication, we can know that in a common software development project, developers must properly be properly known as the MSF project communication model. Different types of communication work such as internal and project groups in the project group; Different techniques and methods solve communication problems. In combination with the classification system, investigate the communication process I described in this case, we are not difficult to find that the communication between my and development center is not just the communication between different roles or different managers within the project team. . In fact, old H is one of the administrators of the project team, and is our partner, and is also a member of the R & D institution created by the software customer (bank). The complexity of the old H identity determines the communication between us covers communication within the project group, but also covers communication outside the project group. If I use the same way to communicate with the old H, our communication will inevitably encounter. It is obvious that this is the communication failure in the case, and ultimately lost the opportunity of cooperation with the development center. One. So, how can we see different types of communication needs? Communication is a communication method between people and people, and people are the subject involved in communication. Different communication types are mainly reflected in the participation of the subjects of communication, and different subjects will have different behavioral features and individual needs during communication. This passage is quite puzzled, and the programmer who likes to study technology may not like this way. It doesn't matter, we can use an example related to software development to explain the problem. If we regard each unit within the software as a spiritual individual, then in the software operation, there is also a fair communication line within the software (of course, the software also has external communication lines, such as software user interface and Communication between operators, but we only discuss communication within the software).

For example, each message delivery between the service procedure and the client program, the application service is per transaction request for the database, the interface code each invokes the chart control plot operation, the process definition program records and passes to the workflow engine. Every business model .. They are all communicated inside the software. An excellent software can always guarantee the smooth progress of all internal communication behaviors, and a failed software will always hinder the normal communication of information in a communication. In this sense, as long as we can use some technical means to define and manage the communication process within the software, ensure that the communication channels are unobstructed, the software we have developed will be able to have good performance in the actual operating environment. Under the guidance of this idea, many technical means can enhance the role of internal communication. For example, I talked about the problem of software interface design in "From" Magic Integration Needle "Talk" 2. In fact, the software interface is the behavior rule, interface of communication defined between software components, modules or subsystems. Whether the design is mainly due to whether the interface can ensure that communication between communication objects and behavioral rules have consistent understanding and understanding. For another example, when we carefully study the communication between classes and classes in object-oriented code, methods and methods, we can find a complete communication rule if we can define a complete communication rule if you can define a complete communication rule for each class or method. For example, in detail the external interface of classes and methods, they define their logic rules that must be met before and after communication, give remedies when communication barriers, while using specifications, they can be recorded by computer understanding, we do not Can you guarantee the smooth communication between the software and ultimately improve the quality and availability of software? Further, if you use a common term (such as "contract") to call this formal communication rule, we will not get a new design concept - contract design

(Design By Contract)? Don't misunderstand, I am not in the inventor Bertrand Meyer who pretending to contract, I mean that the contract design does not mysteriously, it is just a description of the internal communication rules of the software. . In the best interpreter - Eiffel language in contractual design, a typical contract code (that is, the communication rules I said) as follows: Class Communication Feature Sample Is Require - Method must be implemented (Communication) must Satisfied Conditions DO - Method Perform (Communication) Procedure EnSure - Method End (Communication) Method End End Eiffel Language Definition The Contract of End Eiffl Language Definition Or communication between methods and methods, if such a contract is transplanted into people and people's communication process, is it still able to play? It should be said that the syntax related to contract and abnormal processing in the EIFFEL language also reflects certain basic guidelines in interpersonal communication, including: First, communication between communication should meet certain prerequisites before formal communication, such as both parties The topic to be discussed is recognized, both parties are very familiar with the discussion objects. These prerequisites are generally equivalent to the Require code block in the Eiffel language. In case of this case, the communication between me and the old H is basically satisfied, because we are quite understanding of decentralized or centralized architectures, and there is also a topic recognized at the time of discussion - determine the architecture of the software . Second, communication processes should have established steps and communication channels approved by both parties. The DO code block of each method in the Eiffel language is the definition of communication channels and steps. I have a established channels and steps with my old H, because I have experience in project management, using different communication channels such as meetings, chat, email, and other disorders. Third, communication between communication should try to ensure that the results of this communication meet certain set conditions - the condition is to ensure the full essential conditions for the smooth future. This criterion can correspond to the EnSure code block in the Eiffel language. In this article, an important condition that I must ensure that our company and development centers will not break this rupture; and old H as customer developers, there is no need to make sure this The condition is 100% established. This is similar to two mutual calls in Eiffel, one of which is quite complicated ENSURE code block, and the other is not to consider the consequences of the method. In this unsatisfactory communication process, I ended because I didn't bear it, I chose the way to resist the good communication with the old H chambers, destroy my established communication bottom line, which is the direct cause of the failed I communicated. Finally, communication between the two sides should have sufficient ideological preparation and pre-design a remedy. This is equivalent to the RESCUE code block in the Eiffel language. In the case, I obviously prepares the old H et al. Not to think about the problem in the communication process. When the incompetent communication is repeated more than 30 times, my exception handling code (actually I have accumulated before. Experience in interpersonal relationships) completely collapse and eventually leads to failure. In fact, if you prepare an emergency plan before discussion (for example, when the other party is stunned, the communication is suspended, one side requires the relevant sales representative of the company to do coordination work on the spot), I may not be so passive.

In short, the Eiffel language reminds us that before interpersonal communication, both parties involved in communication can make the most reasonable communication contract for different communication objects, different communication channels, and put them into practice when communicating. For example, the old H in the case is both our cooperative development partner, and the technical representative of the client, and the administrator of the project. His multiple identity is self-evollable. I have to prepare a variety of possible conditions before communicating, otherwise it will be lost in communication. However, when I communicate with the old H is just because I am not prepared before communicating? Is there anything deeper? That's right, the example of my old H communication failed reflect an important specialty of interpersonal communication: everyone who participated in communication will have their own specific goals or interests. This qualification cannot find the corresponding syntax in the Eiffel language. The reason is very simple: the Eiffel language contract is a communication between the software unit, and the software unit will only work according to the process or rule given by the programmer, and there is no such interest appeal like a living person. We have never heard which OCX control will select the background color according to its own phased target when responding to the WM_PAINT message (such as all CPU resources or the favor of another OCX control within 1 hour), but we have Someone who often meets the communication between the communication is not to lose the face, and has to use the communication method of turning angle. That is, in addition to the general contract that has already been mentioned above, we must pay attention to the true intentions of each other when interpersonal communication. If you must describe a complete interpersonal communication contract with a similar eiffel language, we have to add a purpose keyword for the Eiffel language to form the "Human Eiffel" language below (in the style of Bertrand Meyer, we can make This defined communication process is called "contractual communication": Class Communication Feature Sample IS PURPOSE - Communication Subject Require - Condition DO - Communication and Step ENSURE - must be Communicated before communication Satisfaction

Rescue - The remedies when communicating, end end here, the PURPOSE code block reflects the "real" target of the communication body, because anyone who has independent thinking will be in the process of communication Choose a communication method for yourself, or more or less hidden your true intentions. Of course, whether exposure to communication targets is also related to everyone's cultural background and living habits, and foreign people like to go through the technology exchange, and Chinese often take euphemist or folding. From this perspective, when these Chinese programmers are communicating with people, they should pay more attention to the true motivation of the other party, so as not to fail to fail now. In this case, I can't convince the old H, because I don't understand his true intention. I was completely considering problems from the technical perspective, and I thought I thought for the interests of banks and development centers. However, when countless times with the old H, I have never thought about it, and the old H is not as I am, except for technical problems. Even when I have found that the old H is in Hu Broken, I don't want to think more than the factors other than the technology. In fact, when I think that I think it is straightforward and stands up with the old H, my goal (the best software product) has not known a few thousand miles with the goal of the old H! Afterwards, after the in-depth investigation of a sales staff of our company, I fully understood the true thoughts of the old H at the time: The development center follows the shortcomings of many state-owned enterprises, and the middle management of the old H must come to the head, must be ensured In the case of qualifications, do not make any mistakes, and try to take the leadership; for the software project we have developed, a direct leader of the old H has taken a similar system in Malaysia, which is dispersed. Architecture; After returning to the country, only a few words of praising the decentralized architecture, the old H hi immediately determined that the decentralized architecture is the only choice; in fact, it is the only way to say that the decentralized architecture is unique Choose, it is not said that the decentralized architecture is the only choice for ensuring the absolute security of the old H. Hey, I am really regret now! If I communicate with the old H, I know how to try to figure out the true motivation of the other party. At that time, I had more than 30 opportunities to explore the old H 's ideas, but I actually waste all the time in an unnecessary technical discussion! Even if I ask yourself a few, even if I find the old H Hu stunned, ask the relevant sales staff and the old H draw relationship, set a set of his heart, our project will not end in failure. Moreover, after learning the true intention of the old H, if we operate, we can even change the understanding of the old H and its leaders on the decentralized architecture. For example, as long as the salesperson arranges old H and its leaders to visit our successful cases of centralized architecture achieved in other banks, tell them that the risk of using centralized architecture is lower, easier to ensure that the system is going smoothly (this sentence of this sentence is The centralized architecture is more advantageous for their future), and our proposal programs are entirely possible to become the preferred architectural solution for the development center. This kind of thing, why didn't I try it? All in all, once there is a technique in technology communication, the root cause of the problem cannot be classified into the technical category, we need to understand what attitude towards each other in communication, or what kind of purpose. Only in this way can we manage to guide different goals of communication participants to a win-win road. The final result of communication is inevitably compromising, and the premise of compromises is to understand the true intentions of all participants.

In terms of inferior terms, this communication skill is actually a communication under "Empathy" guidance, that is, when a conflict or misunderstanding occurs, if the parties can be based on "people, heart The way of thinking with this reason, standing at the other party thinks, maybe you can understand the original intention of the other party, find the best communication method. Of course, "compromise" here is not the principle of the principle, and the intent of the study is not to be able to housing the corner of the horizon when we communicate. The purpose of any technical communication is collaborative and win-win, rather than finger pick and attack - no matter what our communication is a colleague, customer or partner, we should always remember this. 4 Supplementary This article describes the guidelines and qualities of interpersonal communication more when discussing communication. In the communication process of actual software development project, we must also work hard to learn a variety of specific communication methods. To make We need to sum up and summarize it carefully. Another small problem related to communication is: Before the technical communication, the communication should ensure that the awareness of technical nouns and technical terms is exactly the same. The name is not constant, and the unified understanding is clearly the prerequisite for any communication. GOF's "design mode" book has pointed out that a unified naming of 23 design patterns helps improve technicians' communication efficiency 4, which proves the importance of unified noun glossics from the other side. In fact, I have seen communication chaos because the terminology is inconsistent. At that time, two system analysts discussed how many subsystems should be included in a software. System analysts have developed distributed systems often developed a distributed system. The "subsystem" concept in his mind can actually directly correspond to a separately deployable component in a distributed system; system analysts B will develop object-oriented ways Single software is more familiar, the "subsystem" in his mind is actually a collection of specific interfaces and responsibilities. In this way, the two people have a different understanding of the subsystem, and the problem of the so-called "subsystem" is not happy, it is endless. Until some bystanders found that their debate was not to the horse's mouth, they suddenly realized that before the technical communication, there would be necessary to exchange their respective "javelin" or "slang". 5 Summary .. Communication also needs to follow certain established rules; .. The most important thing in communication is to understand the true intention of the other party;. 1 Microsoft. Msf team model. Http://www.microsoft.com/msf/, 2003 2 Wang Wei Gang. Talking from "Magic Integration Needle". Programmer. August 2003. 3 Rexmen. People get along with people. Http://mis.im.tku.edu.tw/~rex14a/p/p/, 2004 4 Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Mass .: Addison-Wesley, 1995

转载请注明原文地址:https://www.9cbs.com/read-85886.html

New Post(0)