Reflection on the latest project

Over the years, Zookeeper has not had much successful experience, but more and more failed experiences. Today, I will spend some time reflecting on it. It's always confusing. What I wrote below is not specific to anyone.

I. No management core

 

Without this important cohesion, the people below can be said to be fighting for individual soldiers in a single fight. How can they make the project well. There are also the following problems:

1. The problems encountered by team members cannot be promptly assisted and solved, which may cause more and more frustration.

2. unattended development documents. development tasks are split if they are not scientifically formulated.

3. Since no one urged me, readmine was useless and did not play its role at all.

4. personnel cannot be reasonably allocated, and there are fewer and even gaps between members.

5. The requirement cannot be effectively controlled. Do it later, do it later, and do nothing at last, resulting in lower morale.

6. The opinions and conflicts encountered in the project cannot be effectively coordinated, and the ideas of team members cannot be consistent.

7. Developers cannot control their progress.

8. There is no scheduled time to confirm the results of the phase.

Many of the following problems are caused by the lack of a management core and the linkage effect.

 

2. Chaotic demands

 

According to the specifications, the demand management should have only one entrance and one exit. After obtaining the demand, we should analyze and refine the demand, then convert it into executable operations, draw a prototype, and create a new one.

The current situation is that, when development and planning are inconsistent, the requirements are directly determined with the developers. Today we need to change this way, and tomorrow we will continue to change without control, the original development plan was constantly inserted with new function modifications, which were totally different from the plan. In the end, the predefined function could not be completed on the specified date.

Developers are not involved in the requirement discussion. When people listen to the requirement, they send the requirement to the developer, which often leads to deviations. Finally, the developer pays the bill, it is time-consuming and labor-consuming to overturn and modify the functional pages and affect developers' mood.

It is often entangled in the details of some needs, one step in place, and strive to achieve the best user experience and effect. I personally think that the quality of user experience can be determined only after the real user has used it. In the development stage, a usable software is quickly taken out, and then based on various data, improve user experience. The development of the project is gradual and clear. The development at the beginning cannot predict all aspects. If we cannot predict it, we should do a good job first, and then change it later, with available software, let's talk about everything.

It also dragged down testers and often complained that the developers started submitting code tests only when they got online, and complained that the developers did not perform tests well. A bunch of bugs are coming soon. There is no time left for them, making it very difficult for them to do. Sometimes it is almost the launch day, there is no software, there is no test, others are very busy, but they are very idle.

3. Do not understand business

 

Before the development starts, developers should use the software on the market to experience the process in actual operations. The actual operation is much more effective than the above mentioned. In the process of operation, you will be able to understand where the software on the market is not doing well, where it is doing well, and truly switch to the user's location. It is often said that you need to think differently, but it is really difficult to do it, but it is much easier to make yourself a real user.

Developers do not understand the business, which is a weakness and causes many problems. The first is the biggest problem.

1. Unable to question the rationality of the demand. Even if there is something wrong with the above-mentioned requirement, we will continue coding, and finally rework.

2. It is difficult to put forward some good suggestions to the project, and sometimes it cannot communicate effectively with the highest decision-makers.

3. There may be some deviations when developers estimate their workload.

4. Code Design has an impact, and the business can better design the code structure and expansion.

5. Technically improved access to www.cgzhw.com's game programming network is a very good technical website.

Iv. Communication congestion

 

　　1. Between testers and developers:

At the beginning, testers were unfamiliar with the system and raised many usability issues. Some bugs were not a problem in the eyes of developers-they were designed in that way. After the proposal, put it on readmine and assign it to the developers who think it is natural to be smooth here. But these problems hanging on readmine are hung like this, without modification or feedback. Their work is very difficult to expand. There is a small gap between testing and development, and the team cohesion is getting lower and lower.

After discussion, we will provide a solution. An intermediate Administrator is required to analyze the submitted problem, locate the problem based on his understanding, and transfer it to a developer for tracking. The tester has a single job and won't always urge her to modify the problem.

2. Between the Web end and the server:

This project requires coordination between different terminals, and the Web end needs to provide interface assistance from the server, so that interfaces provided over there are always delayed, even if you open a task in readmine, still did not give the interface at the scheduled time, one reminders, two reminders, three reminders, no results. There is also a lack of intermediate coordinator, who needs to communicate, arrange time, allocate manpower, and meet the needs of the Web end. Developers are equal, and there is no command relationship between them. There is a small gap between developers, and the team cohesion is reduced again.

3. between developers and demand providers:

The demand is provided directly from the highest decision maker, and sometimes through several others. Due to the constant changes in requirements and frequent deviations in communication, developers do not trust them very much and often confirm their requirements repeatedly, but it will be changed in the end. It is unrealistic for them to confirm the prototype or design process one by one with the highest decision-makers. This will often lead to being overturned and directly affect developers, developers also need to rework after implementation. There is a lack of managers in this place, and they need to uniform the demand. This beast is destroying various related personnel. The erratic changes make their work difficult. There is a small gap between developers and demand providers, and the team cohesion is bound to decrease again.

Reflection on the latest project