Problems in mobile game team collaboration

Zookeeper

I have experienced several mobile game projects, including standalone games and online games. My company is not large, and my team size ranges from several to more than a dozen. I have encountered many team collaboration problems during this period, and I believe it can also represent most of the domestic teams. I would like to make a simple comment.

1. unreasonable development plan formulation.Leading and planning too many intervention plans, regardless of whether there is sufficient development time. As a result, the defect rate is high under the code quality, and the overall development cycle increases.

My point of view:

1) as the core personnel, it is necessary for the product manager to have a certain understanding of each technology, such as art, program, and planning. The main process, main beauty, and main strategy respectively develop work plans, which are reviewed and integrated by the manager.

2) level-by-level management, and mutual intervention is not allowed.

2. Bad habits of program first.In general, due to the "replaced by other diagrams", functions are developed rashly when resources are missing or insufficient documents, but are constantly modified in the future, resulting in resource confusion and repeated project modifications, perform repeated tests.

My opinion: it is very difficult for everyone to start a project at the same time. Everyone has something to do. Even if the employee's salary is your blood and sweat savings, you have to accept that the total number of employees is not 100%, besides, work should have been relaxed and work-and-rest. What we can do is to make it as reasonable as possible.

Interspersed work. For example, when a project is in an iterative testing and modification stage, planning can develop detailed documents for the next stage. When art resources are still being prepared, technical personnel can perform difficult project pre-Research and code reconstruction.

3. The plan lacks execution.Well-developed iteration plans cannot be well executed and are often interrupted by special circumstances (such as unscheduled packaging, additional resource adjustment, meetings, function addition and modification, and forced bug fixing ), this results in a waste of time or additional work.

My point of view:

1) with less dogmatism, there is no need to prepare a bunch of ppt files and hold a long meeting when you stop at work and talk about things you will understand briefly.

2) for additional modifications, the project manager must withstand the above pressure and strictly follow the course plan. If the change is necessary, consult with relevant personnel to adjust and extend the current plan.

3) technically improved access to www.cgzhw.com's game programming network is a good technical website.

4. Chaotic resources.After multiple modifications, you will often find multiple batches of resources in the package, including large and small resources, Pinyin, English, border, and border.

My opinion: the project manager needs to communicate with relevant personnel in advance to develop the resource format and name.

5. Chaotic testing and Bug Management.

1) Many mobile game teams do not have a good testing mechanism, do not do bug trace, or even have no specialized testing positions.

2) The tester does not have a strict test plan and responsibility mechanism, and submits bugs at any time during testing. As a result, the development plan conflicts with the bug fixing mechanism. Because it is a parallel processing, it is impossible to arrange a rigorous bug review, there may even be a lot of bugs.

3) The team lacks a spot check and acceptance mechanism for the testing work. As a result, once a new problem occurs in the tested functions, it becomes the responsibility of developers.

My point is to understand test-driven development, develop test plans, and write necessary test cases. Use common bug trace tools, such as mantis and bug free. After each development cycle is completed, a special test, bug modification, and bug review time will be arranged.

6. low morale.The team is not valued by the company. The lack of team building, encouragement, and other reasons will lead to low team morale.

My point of view:

1) Overtime is the culprit affecting morale and productivity. Many companies are confused. Do you really think that they are dedicated to working overtime at night? Do you really think that the employees who came here early this morning will be very energetic when you leave at the previous day? If we are under pressure to show our leaders how to work overtime, there will be more team building and more benefits. On the contrary, I work overtime and have a lot of activities. Is it useful to draw a pie?

2) more encouragement. This is the lowest-cost means to boost morale, but many will not use it. For example, if your team has completed a phase of work, even if there are more problems, please smile and affirm his work first. If you can say "wow, even you have done this well. "I believe that he will not be upset when you make more suggestions.