preface
As the individual enters a new work environment, the new environment means new problems, some problems are personal, some problems are team problems. In the process of solving one problem after another, there must be some good methodology, which is worth recording and settling.
In line with the attitude of being responsible for the company, we do not discuss the specific business, data and relevant sensitive issues of the company here. I am only talking about my personal feelings and understanding here.
What is holding back efficiency gains?
Perhaps for most teams, there will be such a problem. If the team has less than 10 people, it can maintain a certain efficiency. If the team has more than 10 people, the cost of communication, the cost of business handover, the cost of process approval and so on will become a huge obstacle to the improvement of efficiency. Even when I say these so-called “costs”, they are all big empty words, the so-called impact on efficiency, too complicated.
When there is a need
When meeting a demand, the product will first digest, produce prototype, see the UI, produce the design drawing, the front end through the design drawing, make the page, the back end to provide service, the front and back end interface docking, test function test, and finally online. In the whole process, as long as there is a problem in one link, the throughput of the whole business will drop rapidly.
If I were a front end, what would I be facing at this point?
The whole process is actually composed of individuals. If I were a front end, I would face such problems:
For r the requirements, may not understand thoroughly, the product out of the prototype diagram, I made the result, but is completely not what the product wants.
For the product, maybe the prototype of the product design, but I think there is a problem, because from the point of view of technical implementation, this design has logical holes.
In the face of UI, the product may be right, but THE UI design is not to design the diagram, and the front-end development cycle is so much, hindered the front-end progress.
To the back end here, the front-end development depends on the interface documentation, the back end students can not give out the interface documentation, why? The e backend students think there is something wrong with the prototype design of the product, and we have to butt up with the specific implementation method of the product.
At this point, the test feels that the front end is doing the wrong thing and has to achieve another effect. Or a bug in old code is found during testing.
If I was a new guy
I would be a bit overwhelmed and I would not understand the various business terms my colleagues were using.
When making a new requirement, I don’t understand the overall architecture.
The e test came out with a bug in the old code, I don’t know if it’s my code or where the problem is.
If the backend you work with changes. When you feel like you don’t know anything about the new backend.
The final summary
Efficiency exploded. A team of 20 May not produce as much as a team of 10.
What do most businesses do
These complex problems, we can not even figure out a line, try to ask the heart, how on earth to do?
We can look at the consensus in the industry, how do we do it? Let me just list a few.
1. Demand discussion
This is the most basic solution. The product clarizes the needs, sets up a conference room, and the product tells us what we are going to do next. What are the risks? Can technology be implemented?
The requirements seminar, it solves a lot of problems, it tries to get people to understand what we do, it tries to get people to avoid technical risks in advance, it tries to get people to understand one thing in the same channel.
2. Team leader mechanism
How to ensure the progress of business? How are choke points monitored at each node of the project cycle? How to coordinate the resources of front end, back end, product and test? That’s the role of a team leader.
3. Standard development process
The typical corporate development process, as I mentioned above, goes from product, to UI, to development, to testing. Defines when to publish UI diagrams, when to publish interface documents, gives a schedule, and so on.
What other pain points do we have?
Yes, the question here is for everyone, why are there so many teams that are still so inefficient?
Let’s think about some process issues:
If the prototype diagram is defective when the product is talking about requirements, when can it be corrected?
During the development process, how to do if the product has new requirement change?
When will UED provide detailed design drawings? What if it does not meet the requirements?
What if you encounter a project architecture design flaw that cannot be bypassed during development?
When can a test give you a test case? Does testing bugs in old code count as bugs?
See? There’s always a problem.
4. The detailed normative process is the way to solve these problems
Some people ask, what is detailed, what counts as detailed? In fact, there is no answer, the real answer lies in their own team.
There are large and small teams, small and fine teams, too cumbersome process, will restrict their productivity.
Everyone is very familiar with the business and knows what we need to do. At this time, we sit together every day. In fact, we don’t even need to hold a demand meeting.
Such as is now a probably dozens of technical team, everybody is not so familiar with, can the business are not familiar with, so, in order to solve the problem of demand to understand, we want to open demand, in order to let the demand will be more effective, we have to make the product meeting outline given a day or two days in advance and PRD figure, in order to guarantee the accuracy of the test, we want to make test to write test cases, In order to ensure test coverage, test case reviews, in order to ensure the project cycle schedule, we need everyone to participate in the complex process…
But the goal is to ensure the quality and efficiency of the output.
The so-called normative process is the process developed by the characteristics of their own team.
Problem: If our business is too big
Complex business teams often have higher requirements for our developers. If we have five concurrent requirements at the same time, the front-end, back-end, testing and products of each requirement are different, and our requirements are more likely to rely on a variety of middle-stage and third parties.
Who drives the whole demand? Obviously a Team Leader is not enough.
5. Ensure the progress of complex requirements in the way of project owner
We need to have a virtual role, which is the project owner. The project owner is in charge of the entire project cycle.
Generally speaking, the project owner has some characteristics: he is very familiar with the business; Is a front-line developer, can personally experience the current bottleneck problems encountered; Low cost of communication, good communication for everyone in the project.
Question: What would happen if we didn’t have GitLab?
Git provides a huge aspect to our code management, and without such a basic tool it would be almost impossible to collaborate on multi-developer projects…
Common enterprise-level development tools include: GitLab, Wiki, RAP, JIRA, Dingding. Solves a whole bunch of our problems.
But t there are too many constraints on our productivity.
For example, every time we go online, we need the help of operation and maintenance students, every time we release a test package, we may have to manually deploy a platform, and even some companies use the way of uploading files to deploy the code.
For example, as our project gets bigger, the compilation speed becomes super slow, and this line of code takes about 4 seconds to reflect.
For example, every time we develop, as long as it is a new requirement, we have to rewrite a lot of similar code.
Good infrastructure is the key to improving efficiency
To solve these problems is, in essence, the construction of infrastructure.
We can do automatic deployment platform.
We can do high efficiency scaffold tool development.
We can do component library construction.
We can do the development of automated test tools.
All of this is infrastructure.
Question: Some teams are special, some applications are written in this framework, some applications are written in that framework, what is the problem?
There e are many such teams in the industry, many large factories feel that their technology is cattle, it does not matter what frame, indeed, in the eyes of cattle, write what is no problem.
But we have to look at the problem from another point of view, the essence of technology is to support the business, when the business is very complex, if there is no framework, it is actually likely to cause the result is no precipitation.
The so-called immaterial precipitation is that the basic components I deposited in framework A are not available in framework B’s business.
7, unified technical system and standards, reduce the involvement cost of developers
Imagine a scenario, if we want to make 100 apps, if we use a unified framework, due to the relevance of business, we can pull out a large number of mid-platform components, provided for these apps to use.
If be different frame, make public thing, too laborious.
In a unified technology system, I can customize a lot of things:
Similar project structure..
Uniform code style.
Instead of repeating the wheel, all the difficulties are solved.
In this way, our focus is basically on the business level, and the business throughput of team members will be greatly improved.
Question: what happens if our service is too miscellaneous?
Here the so-called miscellaneous, there may be a service at the beginning, with the development of business, to dozens of services.
At this time, service A may depend on service B, and service B in turn depends on service A. In our entire dozens of applications, due to the initial stage, we did not consider too much, resulting in now even a small change in requirements, the cost is extremely large.
We don’t know at which stage the data went wrong, causing the original application to go wrong.
We also do not know which services will have performance bottlenecks that will cause service instability.
We also do not know whether the definition of our data table is standard, and whether the deletion of a field will affect other services.
Perfect architecture design, revitalize business productivity
We need to reconstruct the whole system.
We need to split up the business and separate the business boundaries.
We need to layer the architecture, such as figuring out what is the business layer, what is the mid-stage layer.
Service dependencies, how to sort out.
Do a good job of the entire architecture design, to go to the future of the business.
Question: What if the leader decides something that the team doesn’t agree with?
There e are often some such problems, the leader said how to do, the underling listen, then forget.
Sometimes,, people feel that the leader is stupid and unreliable.
Sometimes,, the leadership feel that the people under the hand, are vegetables chicken, even a little things are not good.
The e so-called efficiency, foothold are people. How to deal with people.
Solving the problem of good people is the key to improving efficiency
For example, as soon as I joined a team, I came to a requirement. The project was very complicated, and as a result, I failed.
In fact, this is a common problem, many old employees will be out of line failure, let alone new employees. The key question is, as a team, is there any relevant business training for new recruits? Or even values training? Are you responsible for employee growth? In fact, it is a two-way process. Through the cultivation of the company, employees grow up, and they feed the company’s business and assume greater value.
Essentially, it’s about keeping the interests of the team and the individual as much in sync as possible
One thing, the leader thought of, and then tell everyone how to do, obviously can not succeed. Not that the idea of leadership is bad, but the idea of leadership, how to make everyone feel good, but also let everyone know how to do.
In essence, we need to achieve consensus.
The human problem is a very complicated one, involving a series of problems such as personnel recruitment, personnel training, values, skills and personality.
But the core is to manage two relationships: team and individual, superior and subordinate.
Let the team and individuals, frequency synchronization, reach consensus, full participation, common growth, can truly achieve the purpose of improving quality and increasing production.