preface

Whether you’re a would-be programmer on the way to a career or a college student in college, there’s a question that’s on everyone’s mind: “What’s the real R&D process in an enterprise?” Some programmers in small companies are also curious about the r&d process in big companies.

Why do so many people care about the R&D process? Because a reasonable and perfect process represents stability and efficiency. A company with a good process, can greatly save labor costs and time costs; When a developer experiences a good process, he can greatly improve his project/code mastery.

This article will share with you, the research and development process of the Internet big factory now.

Dachang process is good, but it is not accomplished overnight. Each company is different in size and process, so let’s start with the simplest process and see how it evolves step by step.

Evolution of the process

CaoTai team

The process is very simple, there is only one “development” step from requirement creation to completion.

This process can be said to have no process and is often only done in “personal work”. I used to do private work, and many clients only had a simple requirement scenario, such as “the user enters some data and gives analysis suggestions based on a certain formula”, like this program, the developer can complete the function directly according to the description.

Process disadvantages:

The need is not clear, easy to fall into the endless “bickering”.

The user wants feature A at first, and when you make it, the customer says they want feature B, so what you did before is in vain.

So, identifying requirements is the root of the software development tree, and if you don’t do that well, everything else that follows is meaningless.

Clear requirements

This process is often practiced by “start-up outsourcing companies” or “private contractors.”

This process has a “requirement confirmation and analysis” link. As the name implies, this link is mainly to confirm and analyze the requirements put forward by users. Finally, the requirements will be written in the contract, and the subsequent development will be carried out in accordance with the requirements in the contract.

The upper limit is extremely high and the lower limit is extremely low. Done well, it can largely avoid the vagaries of users; Poorly done, with unclear requirements, developers will still have to rework.

Requirements change is one of the most painful things a programmer can do, so it escalates as the process improves.

Process disadvantages:

What the customer wants is usually a written description. In this case, the developer is just relying on his imagination to develop, and his understanding of the requirements is prone to bias.

The prototype

A prototype is a preview of a product that shows what the product will look like.

The prototype diagram is divided into low-fidelity prototype and high-fidelity prototype.

A lo-fi prototype is like a sketch and is used to quickly show the customer or developer what the product looks like, making it easy to modify and adjust.

A high-fidelity prototype is basically the final product, but it also has interactive effects (i.e. pages can be clicked, etc.), and front-end developers can directly follow the prototype diagram for page development.

This process is often used by “small outsourcing companies” and “private contractors”.

Outsourcing companies often have a designer do the prototype design.

Personal work, a lot of customers will directly give you prototype drawings, they usually ask outsourcing designers to draw renderings, and then ask our developers to develop.

Process disadvantages:

After development, the project is delivered directly.

Each Bug in the project is found by the customer during the use of the project, which requires the developer to modify many times before the project can be fully delivered.

Understand that the client is not a professional or your colleague, communication costs are very high, and this form of delivery is extremely time-consuming.

Once I took a private job, the construction period was one month, but it took three or four months to change the details and defects back and forth, and I was exhausted physically and mentally.

Acceptance testing

After the developer realizes the function, the system will be tested by specialized testers. After the test, the product will be accepted. Only after the acceptance can the product be delivered/launched.

“Small and medium-sized outsourcing companies” and “small product companies” will implement this process.

Outsourcing companies, which do not have their own products, mainly undertake projects for development. Demand is coming from customers.

A product company is a company that has its own product and will develop, operate and iterate on it. The requirements come from the business department, the product department.

Although this process is complete, there are corresponding personnel responsible for each link:

  • PM: Product manager. Responsible for demand proposal and product design;
  • UE: Interaction designer. Responsible for designing the layout of the page and the interaction (the interaction is the operation logic of the product, such as what prompts will pop up if you click this button);
  • UI: Visual designer. Responsible for the specific style design of the product (visual is the realistic effect of the product, such as what the icon looks like), UE and UI are often the same person;
  • RD: Developer. Responsible for function realization, mainly divided into back-end, front-end and client developers;
  • QA: Testers. Responsible for product quality testing;
  • OP: operation and maintenance personnel. Responsible for on-line approval and maintenance of hardware status required by products.

Each person is doing his/her own job and will control the link he/she is in. Only when the current link is ok will he/she advance to the next link.

At this time, the reverse and promotion of the process is not just verbal, but engineering management, each link must go through specific steps to advance to the next step, such as sending emails.

There are many collaboration tools/platforms that make it very easy to manage processes. Take Tencent’s TAPD:

Process disadvantages:

While the process is beginning to take shape, it is still rough and there is room for improvement at every step.

Many links were carried out without adequate preparation, and the quality could not be effectively guaranteed.

For example, after the requirements and prototypes are determined, the development is directly coded. If the technical scheme is found unreasonable during the coding process, it will waste a lot of time to change it.

Therefore, there should be a series of design and review before implementing features.

Preparation before development

The following process evolution is basically the process of the major companies in the Internet, and each company may have different choices in each link, but the difference is not too big.

This process mainly reflects a series of steps before the function is realized. The better these steps are, the faster the function will be realized.

Product requirement review

After the requirements are put forward, the product will involve people from various positions to review the product requirements, including interaction/visual design, development and testing.

The product manager will write down the requirements and put together low-fidelity prototypes, product flows, etc., so that everyone can get an idea of the product and requirements.

The product manager then comes up with a document called PRD, which looks something like this:

Every company is different, and it doesn’t have to be documented, but a lot of times these days it’s just annotated on a prototype, and then people review it.

Each position will strive to understand each detail of products and requirements, and prompt their own ideas and express their opinions. For example, the implementation cost of a requirement is too high and needs to be reconsidered, or the unreasonable requirement needs to be improved.

This process will take a long time, after the consensus of opinions, the product manager will determine the version, and then each position will start to carry out their own responsibilities within the design.

The first is the developer, who does the outline and detailed design.

The profile design

Summary design is the design of development scheme, such as how to divide modules, how to select technology, how to design data model, etc.

This part is mainly a general design of the whole project, remember in this stage to the business process, the details of the implementation of too much entanglement, these are detailed design.

The detailed design

Once the outline design is complete, it’s time to work on the details.

This detail refers to the implementation idea of a function, such as a very simple login function is like this:

The more detailed the design, the easier it is to code.

Test case design

Developers need to think and design their code, and testers need to think and design their tests, too, or they will miss feature points.

A test case is a detail of a function point that needs to be tested, how it should be tested, what the preconditions are, what the expected results are, and so on.

Test cases can help testers clarify requirements, provide reference for subsequent testing, and reflect the testing progress during the testing process.

Interactive/visual design

At the same time, designers also need to do interactive and visual design.

This process produces a high-fidelity prototype, which is basically the final appearance of the product.

A comprehensive review

When developers, testers, and designers have finished designing their own content, they get together for a review to see if there are any problems with each design.

For example, developers and testers will check to see if they have the same understanding of each other’s features, otherwise they will waste time when they test and the testers say this is wrong and the developers say this is right.

The product also looks at how well people understand the requirements to avoid misunderstanding.

This part is to change the details, usually not too big, do not take too much time.

After the completion of the link, the developer will implement the function, and the front and back end will conduct joint adjustment. After the joint adjustment, the developer will test by himself, and then the tester will test if there is no problem.

Process disadvantages:

This process is sufficient preparation before the development process, but not sufficient test acceptance after the development process, product quality can not be guaranteed after the launch, easy to cause problems.

Therefore, after the completion of development also need to carry out a series of test acceptance work.

Guarantee after development

As you can see, there’s a lot of work to be done once the development is complete.

Code Review

First of all, big factories usually conduct code Review, that is, the team leader or team member will Review your code. You can get a lot of suggestions in this link, no matter in business or technology, which is the fastest growing link for developers.

Test & First round test

Once the code is fine, the developer submits a test request, and the tester releases the code to the test environment for testing.

Why should developers submit a request at this stage, just release the code.

This is because the test cycle is relatively long, the testers are still testing, you release without authorization, will affect the work of the testers.

Therefore, the test environment can only be published by testers.

Once the test environment is ok, the code branches can be merged and released to the pre-release/sandbox environment by the tester.

Pre-release/sandbox & Round 2 testing

A sandbox environment is one where the system is connected to real data, but the system can only be accessed internally, not by users.

This part is to ensure that there are no problems before going online, so simulate the real environment online, to see if the system can withstand real data.

Once this round of testing is ok, you can merge the code branches again and let the product manager check them out.

The first round of product acceptance & online application & online

The product manager looks to see if the functionality that has been completed matches the requirements.

After acceptance, the application will be launched, and then the code will be published to the online real environment.

Online is “sacred and solemn”, and everyone is eager to burn incense and bathe in fear of problems on the line.

A lot of work needs to be prepared before going online, such as listing the services to go online, relevant personnel involved, changes to the configurations of the online services, deployment steps, and rollback schemes.

Release time is also particular, generally not released on Friday, for fear of problems after the weekend adjustment; Similarly, generally will not be close to the evening release, afraid of bad processing after work.

Some companies also release grayscale versions, which send a new version of the update to some users and release it in full only when the user experience is ok.

Back test & second round of product acceptance

After launch, the testers run a regression test (the third round of testing) and the product is accepted again.

That’s when the requirement ends.

conclusion

From the request to the end of the demand, or quite not easy, through a number of links, and multiple departments/posts to coordinate, all kinds of problems and difficulties have to face.

These processes may differ from company to company, but not by much.

Each company will adjust to its own culture, staffing mix, business direction, and the size of the requirements. For example, if there are small requirements or small changes, the outline/detailed design will not be done. Or some companies put product acceptance after the first round of testing…

The ultimate goal of the process is to save labor cost and time cost and improve product quality. The best process is one that conforms to the actual situation of the company.

Small companies blindly adopt large companies’ processes, but increase communication costs; Big companies tend to pile up technical debt when their processes are old and unwilling to improve.

As a company and as a developer, we need to keep learning and improving so that we won’t be left behind!

I’m RudeCrab, a RudeCrab, and I’ll see you in the next article.

Follow the “RudeCrab” wechat official account to bully with crabs.