A few reliable things are required to avoid the risks of mobile client projects

I. Reliable Objectives
Theoretically, a project must be balanced among several elements. To put it bluntly, it means how much time, resources, and things are there. This principle is very simple, and there is not much to do.
The internet mobile client project should not be regarded as a year. You can set a half-year goal and a three-month plan. When the pursuit of speed in the industry leads to R & D, product, and UI iteration, a long period of planning will inevitably cause numerous problems. Listen to the famous saying of Daniel Zhang Xiaolong: satisfying basic functions, and then fast iteration based on user feedback is king. Eliminate user requirements for door close manufacturing.

2. reliable resources
Pay attention to the number of dry goods in your hand:
Your brothers have no intention of messing with you, but some strangers to processes and businesses are definitely project bombs. This is common in mobile development with fast talent flow.
What do you do? Draw a structure for you, or tell you the requirements? Or is it just a zombie? Whatever it is, it is important for both of you to pull out the things in his head and tell him the things in your mind.
Did the product department transfer a freshman to you? The new girl in the UI was originally an iOS player, right? A just-in-row test will throw you some bugs that make you hi. Do you know the server interface? Every one of these problems can make you say that every day should not be taken into consideration.

Iii. Reliable execution
Anyone wants to be responsible, but no one wants to pay for mistakes. Therefore, we need to develop a plan and improve the process to help everyone become a saint.
1. It will take time to elaborate your development documents, product documents, and ui, but it will avoid fire-fighting in the later stages of the project.
2. Tell everyone to record every problem they have encountered, with no subject restrictions. The tool has no comments, the product's braid, And the UI buttons should all become luminous, and so on. Even if there is no obvious benefit to the current problem, it will definitely make the next execution process smoother.
3. Everyone is planning to change things. You can ask him for time. Do not promise the "What will happen", "what will happen", or "What will happen later.
4. Everything is defective. Do not make perfect things. Make sure that everything is stable and reliable and meets the original plan.

4. Reliable details
Mobile product development needs to deal with a variety of screens. It is really difficult to achieve good people. Here are some points to mention:
1. If you want to fit all the screen sizes, cover the following machines that meet these requirements: 3. X inch, 4. x, 5 (default), 7 (large), 8 (X-large), 10 (X-large), 1.0, 1.5, 2.0 density.
2. In order to ensure the user experience, the GUI Design should be at least two sets of mobile phone and 10-inch pad solutions.
2. 2.2, 2.3, 3.0, 3.2, 4.0, and are available for Android machines with major updates. Every major version iteration of Android will bring about some API changes. At the android update speed, we cannot understand every pitfall (especially when using hidden APIs ). So try to test more.
3. Special models are always painful. The p1000 super large font settings, 800x600 resolution of the host machine, and special models such as inexplicable font enlargement will be harassed from time to time. If you only want to customize a specific machine, congratulations. Otherwise, we suggest you try these methods:
(1) There are always so many classic arcade games on the market that it is very painful to apply for a purchase.
(2) If one of the major manufacturers on the render server is enough, he will calculate one hundred models, and several dozen guns will be assigned to the foundry after the framework is changed.
(3) do not forget the star machines whose frameworks such as Kindle Fire and happy pad have been changed.
(4) The machines of several major international manufacturers must have at least one. They have a one-stop hardware and software program, and they know what they are doing on the framework layer.
4. You can always find many unsatisfactory places that have been missed by R & D, products, and ui, leaving them to test, and finally making them more painful. Everyone in the team needs to be aware of details, but more people need to be responsible for this.
5. Before designing a dashboard for each interface, you should at least consider whether it works on a 10-inch tablet or a small mobile phone. Do not expect that the UI and product can take everything into account. R & D adaptation experience is the best say.
6. For a very fine but important experience, don't hold on to the idea of "I should be able to do it", raise a hand-written demo, and place it on several classic machines for a run.

V. Reliable Technology
Any new technology used in the project must be fully qualified for commercial use and then applied to the project. With regard to commercial standards, I have summarized the following points with my own experiences:
1. The application results are as expected. Does the speed, memory, and CPU of the software module meet expectations? If it is related to the GUI, will the effect and experience meet the expectations?
2. The impact on other modules is controllable. Will it be related to other modules?
3. The simulated environment is consistent with the real environment. Don't pick up a test demo. If it looks good, just take a shot. Be sure to check in a real application environment. If the project does not have enough time or resources to simulate the real environment separately, put it in the first milestone.
4. Options. Multiple solutions are available to everyone. Go to the best place, but make the worst plan.
5. Technically handsome things are useless if productivity is not converted. Successful projects do not require technical worship.