Summary of work > Summary of trial period work

Summary of project management trial period


Time is fast, just a short time I came to xx company has been pulling for two months. During this time, I feel the passion and development of xx company every day. In getting along with my colleagues, I got a lot of help. More of this is from my instructor Lu. Every time I meet some unfamiliar tasks or tasks, I can always get his guidance. Now I have a comprehensive understanding of xx company, feel the harmony and friendliness among many colleagues, and the team consciousness of the project team.

In the past two months, I was responsible for the x module's needs discussion, database design, code writing progress management, and also responsible for the development progress management of the x project xx platform, through the cooperation with everyone, basically in the regulations Most of the business needs were completed within the timeframe. Through this project, I also enhanced my experience in project management, learned a lot of business knowledge in x, and comprehensively understood the comprehensive quality and working ability of each member of the project team. In terms of personal business, I have an in-depth understanding of most of x business. In terms of xx evaluation, I mainly understand x, x, x, x and other services. Of course, this is thanks to the careful guidance of Xiao Tang, Xiao Wei, Xiao Feng and others. I am very grateful to them.

In the past x project implementation process, I also found some advantages and problems of the project team. I don’t have much to say about the advantages. It’s mainly that everyone’s hard work is stronger. For some problems in the project team, here I publish some personal opinions, for reference only.

1. Project team control

Since our current project is a brand new combination, there are too many strangers and uncertainties among members, which causes us to be less optimistic about the risk control during the implementation of the planning task. When we are making related planning tasks, we always rely on our first sense to deal with them. Therefore, there are many lags in the implementation process during the implementation process. We only have to work overtime to make up for these lags, excessive overtime and rework. It will inevitably damage the satisfaction of the members of the group to the control of the project team, and of course directly affect the perception and evaluation of the company.

I feel that we always lack some ability to control and foresee. There is always an unpredictable risk in accomplishing anything or a goal. But how to control it to the maximum extent before the risk breaks down, it is something we should consider. And controlled.

2. Project team's collaboration

Speaking of the collaboration of the project team, I feel that we are doing very poorly. In the process of implementing the task, the current project team is like the three kingdoms of ancient China. Every day we are very busy, but the busy one is our own space, and there is too little time for communication and collaboration. The realization of a functional module is not to maximize the satisfaction of the business, but to use their own brains to scribble, create their own wheels, and always impose their own consciousness on the customer.

In the past code writing time, I always found that many colleagues have a problem, and the modules they make are related to the existence of others. At this time, they need to communicate and complete each other. However, many people do not communicate, but download other people's code directly, and then add their own needs, submit the matter, and wait for their specific personnel to find out that their code has been modified one day and not known, and finally encounter problems, mutual Pushing, this is the consequence of lack of communication.

Speaking of collaboration, by the way, the division of labor, the most important thing in the process of code writing is that the division of labor is clear, we need to strictly stipulate that those people have the right to modify the relevant files, those files need to be broadcast before the deletion. Instead of blindly changing, deleting, and adding, do you think about the impact on your project or others before the operation?

3. Project team execution

In terms of execution, I think the main reason is that we need too few specifications and there are few standards that we can rely on. I would like to ask: our "Development Specifications", "Daily Code of Conduct for Project Teams", "System Technology Selection Scheme", "Technical Stereotype Evaluation Criteria", "Pressure Test Evaluation Scope", "Code Inspection Plan", "Code Verification" Standards, Business Process Processing Instructions, Project Risk Prediction Report. Where are the similar standards, I don't see any formed documents exist except for a general development specification.

We have chosen a technical framework like s2, spring, ibatis, dojo, but why do we choose these instead of s1, hibernate, ext, etc. I also clearly remember how we chose, it is very sloppy, Take a table, ok choose them, but why?

Every time we discuss business disputes, I always have a word for you, Zhang said Zhang Youli, Li said Li Youdao. The sky is a war of words, this discussion is not as good as it is, wasting time, and those times are not as good as going home to sleep.

A good development framework must limit and influence the research direction of its users, because our daily coding technology is based on ctrl+c and ctrl+v under the framework, so we need to be cautious and persistent for development choice and maturity. The process, I don't know if the framework we are using now needs to be extended. If so, we should give relevant review instructions such as robustness, compatibility, scalability, maintainability and so on.

Robustness should be balanced to deal with various high-concurrency and sudden risk management; compatibility should be upgraded with continuous technical versions, flexible use of various databases; scalability of various types of usability functions, scalability and flexibility Changeable; maintainability tells us that we need to continually fix bugs and versatility in continuous use, there are special personnel to complete the upgrade of different versions, and the relevant personnel who focus on the system architecture should have a specialization process for the project technology they use. After all, everything is good and bad, and it doesn't understand thoroughly. How do you know where it needs improvement?

4. Coordination of the project team

Finally, let's talk about coordinating power. This is often the case for implementing project planning and implementing process management. I hope that every time we make a plan, we will do a brief review process, which can be done in several people. Many times, people who plan to do are always walking according to their own ideas and ideas. We should complete the project and communicate with the executives who participated in the project to see if they can complete the arrangement within the planned time. And discuss the amendments. Do you have a plan for a task, have you considered the risk of the current plan, and what if the performer does not come to work or leave the job one day? What if a certain period of your project time is occupied by the company's collective activities? What should I do if the company loses power one day? There are too many similar questions, these are the risks of our project, it is unpredictable, should you consider a b plan?

Do not plan to do it blindly. Do not always tell your executor, just do it, do not finish your own overtime, it is very violent.

I have written so many of my own ideas, many of which may be one-sided. For the current project team, I feel very combative. Of course, anything is not born or perfect, let us slowly improve and run it. I sincerely hope that I can accompany the big family of xx company to develop and work together.

recommended article

popular articles