Developing apps requires a role

Developing apps requires a role:

The development of a mobile app application software, requires a number of processes, a variety of job roles division, simply explained as follows:

1. The development process includes:
(1) User demand analysis
(2) Product prototype design
(3) UI visual design
(4) Database setup
(5) Service-side development
(6) iOS Client Development/android client Development
(7) App test
(8) Upload to the App Store.
iOS is submitted to Apple's App store, and Android is submitted to all of China's Android app stores.

2, the corresponding jobs include:
(1) Product Manager
(2) UI Designer
(3) Database architect
(4) service-side engineer
(5) iOS client engineer
(6) Android client engineer
(7) Test engineer
(8) Operations personnel
(9) Promotion personnel.

A mobile app project can be large and small, but it is inseparable from the following members: Product manager, UI designer, front-end development, backend development, testing, and more. How to properly arrange the work of the project members to ensure the smooth progress of the project? A clear and reasonable project development process control is important.

The project development process is generally divided into 3 stages

The first stage: demand planning.

In the requirements phase of the product manager in-house requirements discussion: Discuss the next version of what needs to focus on, what functions, how to do. Through repeated research, discussion, output interactive program.

Confirm the feasibility of the requirements: the product after the output of the interactive program to find the appropriate development and discussion of the feasibility of the project, the discussion phase of the product and development of different ways of thinking, often will wipe out new sparks, new surprises, but the discussion control is not good or will evolve into a product and programmer of the tear Force War, hehe.

UI design: Designers will make the interactive solution of the product more vivid, but not all the beautiful design can be achieved. In this process, the Product manager needs to coordinate the communication between the designer and the front-end personnel to develop the design specifications. At the same time ensure the quality of the design draft, the progress of the draft.

Demand presentation: The Product manager pulls all the members of the project into the picture after integrating the interaction and implementation logic with the bug, other optimization requirements, etc., into the full version requirements document. The purpose of the preaching is to make the project members clear about what the new version needs to focus on, what function to do, why to do it (emphasis), how to do it, explain the interaction plan or design draft, give everyone a whole impression, let everyone understand the meaning of version function.

Phase II: Demand development.

Project start: After the requirement is preached, develop the requirement review according to the product requirement document, evaluate the research and development period, the time of the measurement, the pre-release time point and the official release time. The product launches the item according to the result of the review.

Research and Development: in the process of demand development, product follow up research and development progress, maintain and develop communication to ensure that needs are correctly understood, timely solve the new problems found in the development process.

Test Cases: Product, test, development together confirm version test cases, and synchronize the requirements and details of the changes in the development process.

Measurement: Product acceptance Development Output function module, and output experience regression document; Test the requirement logic according to the use case, make bug, optimize to develop. After the intranet environment test passes, the test continues to validate the pre-release environment and the formal environment.

Phase three: Version release.

Customer Service Training: During the test verification process, the product is pre-released to customer service to train the new version of the content.

Release: Back-end development, operation and maintenance personnel will code published outside the network environment, the front-end output outside the formal package. Product operations will be formally uploaded to the DA Zhuo market or Ios-appstore arraignment.

Upgrade: All Android Channel packs are updated, or Appsore approved, and the new version does not find any problems when the backend development and operations personnel open the upgrade configuration and send upgrade notifications.

Operation Report: The release of the version is not finished yet, the operator after the release of the new version, collect user feedback, data monitoring, data analysis, evaluation of the new version of the features and impact, verify the new version features and output under the release requirements development and optimization recommendations.

From the above application development process, each version of the development will go through the above 3 stages 12 links, the theoretical picture is a complete line, but how to ensure smooth process? How can I maximize the productivity of project members? This is a great test of the Product Manager/Project manager's version planning capabilities. Of course, the tacit understanding between project members and communication is also very important.

From the author's practical experience, to ensure smooth assembly line, the ideal product requirements document to lead the front-end development of 2 versions, design leading front-end development of 1 versions, back-end development leading front-end development of half a version. That is, at the time of the current project launch, the product manager has been in the research and discussion under the release requirements; The design begins with a version of the manuscript; When the current project is more than half, the backend has completed the current version of the requirement and is ready to prepare for the next version of the requirement.

Version planning is a product manager based on demand priorities and development progress estimates, that is, what each version to do, what the focus is, research and development time, on-line time and so on. In general, each release of a project should have its meaning and main features.

The first version of the app is relatively long: apps need to match the development environment, identify app technology frameworks, and develop basic systems. For long-time versions like this, product managers and technology need to phase out development requirements and set milestones (as little as 3) at each milestone (up to a maximum of 1 weeks) at a time when the product manager needs to confirm the completion of the issue, identify issues to adjust the development plan in a timely manner, control project risks, Ensure the project is completed on schedule.

each subsequent development should have at least one important function, and the development cycle of the version should be controlled within 2 weeks-3 weeks. This benefit on the one hand is to ensure that the project members have a good development rhythm, to maximize the efficiency of research and development, on the other hand to ensure that each version has new things to the user experience, as well as meet the major market application first conditions, access to free promotional resources (PS: General starting activities can get thousands of to tens of thousands of free users, is still quite attractive). Of course, major features on-line, to ensure the stability of the post-launch version, you can extend the development cycle to 1 months, or grayscale publishing. To avoid scheduling more than one months of development cycles, set the long version to a number of milestone acceptance. The experience of the research and development cycle too long often lead to research and development technical personnel distracted, work procrastination, enthusiasm decline.

In general, it is not recommended to publish small versions frequently, because each release requires testing, packaging, publishing the market, sending upgrade configurations and escalation reminders, and so on. Frequent release of small versions results in increased testing and operational duplication of work, resulting in
Waste of resources, the user side to see frequent upgrade reminders is also a very annoying thing. In addition, it is recommended that no more than 4 client versions of the extranet operate. Maintenance of the old version of the cost is still relatively high, such as the new function to test
New and old version compatibility, and a variety of background data interface upgrade, update compatibility issues and so on.

In special cases, when there are urgent bugs and vulnerabilities, it is recommended that an Bugfix version be released urgently.

Such as:

Developing apps requires a role