Software Engineering psychology 3-party a project leader PK Party B

(Note: This article will not be reproduced without my consent. It is copyrighted. If you need to reprint it, please contact me. Thank you)

Last week's Series II (http://www.cnblogs.com/jackyrong/archive/2006/09/05/495791.html) mainly talked about how Party A's project leader can work with Party A's leaders and what should be paid attention. In this article, we will discuss how to cooperate with Party B as the project leader of Party A throughout the project process, learn about Party B's psychology, and how to get along with Party B in harmony.

First, let's continue to review the previous figure.

This time we will focus on "3" in the arrow ". First, let's take a look at what problems Party A will encounter (generally speaking) in the face of Party B's information project owner ). I have listed some of the following common examples:
1. leaders from all walks of life are under great pressure. Leaders have high expectations and have high expectations. However, the time is too short. I feel unsure when I first become Party; some people originally engaged in technology, and now the role has been switched, and it is boring to become a Party.

2. If the project is large, I feel that I have insufficient experience in implementation. My knowledge system structure is very different from that of Party B. In the face of Party B's requirements, new technologies, new implementation methods, and myself
I don't know much about it. I always feel like "Party B's nose is walking.

3. I feel that Party B's supervision is not in place. I always feel that Party B's progress is slow and does not meet the original requirements. So I always urge Party B, but I cannot come up with specific requirements for Party B.

4. During work with Party B, the two sides often disagree with each other. The two sides often find that Party B has cut corners and disputes with Party B.
Some of the above reasons are caused by Party A's own problems. For example, at, I have seen a person in charge of Party A appear in this situation. Of course
This situation is generally caused by the experience of Party A's owner, the newbie of information projects, or the previous technical expertise. This conversion of roles is a bit difficult.

In this case, we recommend that you make psychological adjustments first. If you have experienced problems or the role has just been transferred to Party A, we suggest you think like this: after all, I used to engage in technology. Although I have now switched to a role, although we have to do something different, we do not need to code coding at least. We can grasp the problem from a higher perspective and learn more.
The knowledge of software engineering and management planning can be said to be a sea of sky, you can do "supervisor", there is a feeling of "small boss. Haha, the last time I had a friend who was engaged in technology in the company, he was a technical enthusiast. Later, due to the need to outsource projects to other companies, he naturally became the owner of Party, at first, he felt uncomfortable. He thought it was boring to be the owner of Party A. He had to listen to the instructions of the leaders all day and face Party B. Later, I asked him to rethink according to the above instructions, re-adjust his mental state, and re-feel the pleasure of being a party A. Finally, due to his good technical skills and willingness to learn, the role was quickly converted, and various problems and relationships with various parties were well handled throughout the project.
However, the 2nd point situation should be widespread. The reason may be: due to lack of experience, huge engineering, and insufficient business knowledge in this area, it is not very familiar with some new technologies and methods proposed by Party B, but the time is tight. In this case, we recommend that you:
1. You should be psychologically confident that you are the owner of Party A and you are not omnipotent. Your responsibility is to better inform Party B of your needs, cooperate with Party B, and supervise Party B to complete its work, rather than serving as the adviser of Party B. Therefore, you need to have a clear understanding of the defects in knowledge. If you do not involve too much core business process knowledge, but some fancy knowledge and technologies, there is no need to overemphasize your entire collection. After all, your energy is limited. Check whether the new things proposed by Party B are suitable for use in this project. This involves an evaluation problem. At this time, we recommend that you carefully review the relevant solutions of Party B and ask Party B to provide clear justification and justification. Do not trust Party B on the surface.
. For example, Party B says it is going to be done. Net System, blow to how good, but as a Party A, you can combine the current specific circumstances of the project, and then let Party B make a judgment based on the reasons, that is:
Carefully study the business process and specific circumstances of the Project + ask Party B to give reasons based on + third-party consultation + experience in querying similar cases

The advantage of this practice is "customer-oriented", because you need to know that sometimes the person in charge of Party A may not be a technical engineer! You can also consult a third party. The simplest thing is that you can have a meeting with your staff (usually engaged in technical work) and discuss with them the solution of Party B. If you are the owner of Party A, do not directly expose your subordinates to defects in your knowledge (otherwise, it is too obvious that the lower-level employees may trust and recognize you ), they should discuss with them and indirectly arrange tasks for them to answer and listen to their opinions. Finally, you can query the success or failure experiences of similar cases and collect the relevant information so that you can make suggestions when discussing with Party B.
After doing this well, you 'd better understand the basic principles and applications of the new things proposed by Party B. You do not need to understand things that are too deep, or you can let your hands go down and organize them.

2. Psychologically, you must take the initiative, because after all, you are Party A, you are a customer, and you are God. When dealing with Party B, we should make Party B feel that as the person in charge of Party A, you have a good grasp of the entire project, a general picture, and good control, it is experienced and experienced. This is very important. In particular, If Party A's manager has just taken over, has insufficient experience, or is not a technical background, he must be calm before Party B. We suggest that if you have technical personnel, you should bring them to each meeting. If you encounter new technologies and new solutions from Party B, you should stay calm. If you are not familiar with them, you may delay the discussion at the meeting, or ask the technical staff to answer the questions, which may be placed in front of Party B, show your authority more (or even do it in the next drama, haha ).

The 3rd and 3rd points are mainly due to the lack of quantitative supervision over Party B. In many cases, if there is no third-party supervision, Party A may easily fall into blind supervision. For example, Party B needs to report the progress on a regular basis for formal supervision, lack of fine-grained supervision. Therefore, we have the following suggestions:
1. At the beginning of the project, we should formulate a supervision plan for Party B. For example, the defined meeting system requires participants of Party B and long-term contacts of Party B. The supervision plan should be implemented based on milestones. It should not be too rough. For example, if Party B completes the Demand Survey before reviewing the plan, it can be changed to: require Party B to complete the survey of a certain part of the Demand Survey, it must be submitted to Party A for review once, just like in XP. In addition, it is best to leave some room for Party B, for example, to require Party B to submit within a certain period of time, sometimes
It cannot be too harsh on Party B. Otherwise, Party B may be dissatisfied and the subsequent work may be affected.

2. Make a record every time you have a meeting with Party B to discuss the issue. It is best to keep a recording. Prior to the meeting, we listed the severity of the problem from high to low. We proposed to Party B at the meeting. We 'd better form a table, for example, recording the response of Party B at the time, after the meeting, the response and actual results will be clearly displayed, so that Party B can know exactly what it has done.
Work now. For Principle issues, we should clearly point out to Party B that we are not afraid to offend Party B. We should also record the opinions and solutions put forward by Party B, so we are not in a rush to draw conclusions, because the initiative lies in your hands.

3. For example, a template of a typical supervision plan may be like this (for reference only)

Supervision plan

 

1. Party B's supervision on the Demand Survey results during the demand analysis phase

 

Original plan description
Planned start date of Party B
End date planned by Party B
Actual start date
Actual end date
Completion status
Latency description of Party B
Solution proposed by Party B
Questions raised by Party B
Party A's opinion on this stage
Opinions of both parties on the next stage	Party:   Party B:
Start time of any of the following:
Remarks for this phase	The existing products or documents that can be referenced by both parties at this stage can be listed here
Signature of both leaders:	Party Party B

Of course, if there is a third-party supervisor, the supervisor's opinions and signatures will be added. In this way, in actual operations, we have quantified and standardized, and everyone must abide by them.
Write it here and write it next time. You are welcome to continue your criticism and comments.