I have been engaged in front-end development for three and a half years. While improving my technical ability, I have gradually enriched my business experience. When I first entered the workplace, I felt uneasy when I got the design draft, and I did not know how much I expected the schedule to be. Feel that the product design is not reasonable, looking for product manager PK, but was simply persuaded, the results or fall into the pit. With the development, launch and summary of one project after another, the pit I once fell into became my way to avoid the pit (although I still fell into new pits), and the project progressed much more smoothly. It not only improves the efficiency of personal development, but also makes the members of the project and cooperative team more mature, forming a win-win situation. Let’s start with the front-end development and the collaboration of the various role members in the project.
The product manager
The product manager is usually the first contact on a project. The product manager connects with the demander side and the implementation side (design/development) to convert the requirements into function points and hand them to the implementation side for implementation. As a developer, it is common to mock product managers for their undisciplined design. The reason for this is often due to the product manager’s insufficient understanding of the requirements or overpainting the picture. But most of the time, the product manager plays an important role. Students who have experienced the project without product manager will be deeply impressed by this point: the demand from the direct demand side, business/sales/boss often needs to be translated and confirmed for many times before it can truly meet the demand. What impressed me most was the requirement raised by the personnel of the company: to add the function of email push to the employee forum. Hr’s requirement at that time was just one sentence: “You want to be able to automatically push new posts and popular posts, and manually specify recommended posts, preferably with pictures.” From this, we need to extract such three requirements: 1. Automatic push of new posts; 2. Automatically push hot posts; 3, the option is to push recommendation posts, and to attach illustrations. After refining, the requirements need to be refined again, such as the time range of hot posts, the number of new posts and hot posts, as well as the source of illustrations and the absence of pictures, etc., which need to be confirmed with the demander repeatedly. Thus, the docking with the product manager is actually indirect docking customer needs. If you’re unlucky enough to have an unreliable product manager, to avoid falling into the trap, you have to help the product manager figure out the requirements. The trick is to ask, “What is the feature you want to implement?” “Why this feature?” “What are the customer needs?” And so on. Finally, the perfect results are put into the product documentation, “mutual verification”. Sometimes the product manager will also take on part of the interaction designer’s job, drawing detailed prototypes. At this point, in addition to identifying requirements, it is best to clarify priorities. Because some of the more refined product managers will emphasize a lot of detail features, but often not from the customer’s real needs, or at least not high priority. At this point, if the development cycle is limited, consider working with the product manager to do it in the next iteration.
Interaction/visual designer
Interaction/visual designers design and optimize interactions/details based on product prototypes designed by product managers to improve the details and greatly improve the user experience. In general, designers are experts at interaction and visuals themselves, and unless you have a solid theory of fact, there’s no point in arguing with a designer about an interaction or visual design. Professionals do professional things. On two things, however, as the development is the need to focus on: 1, the standard consistency: due to various reasons, such as the lack of standards, the lack of documentation, personnel of level difference, lack of communication and so on, can lead to different pages on the same project, or even the same page in the same class function, appear a variety of interactive or visual style. This not only affects the efficiency of development, but also reduces the user experience. As developers, especially in the days of front-end componentization, they tend to be more familiar with interaction or visual specifications than designers. At this point, you need to be good at analyzing whether certain functional modules are similar and whether they can be implemented using the same component. Communicate as soon as you can, and designers are usually open to suggestions. 2. Commonality: The commonality here is more reflected in the component design. For example, if the designer may give more than one set of dimensions for different scene layouts, it may be advisable to adopt a grid layout and determine several grid ratios with the designer. This eliminates the need to write several width values for different scenarios. In addition, when discussing a design or feature point with designers, including product managers, it should be analyzed from a rational perspective, such as is it necessary for the original requirements? Is there overdesign? Is there duplication of function points? Avoid all of a sudden from the perspective of technical implementation, often lead to a lot of unnecessary debates, such as the classic mantra: “The need is simple, I don’t care how to achieve”. Only when a feature is determined to be needed should a project schedule factor be added. At this point, you can consider either extending the development cycle due to technical implementation difficulties, or adopting some quick implementation solution, negotiating with the designer and tweaking the design slightly. Of course, not all projects have interactive/visual designers. For projects without designers, on the one hand, there is little need for styling by assembling existing components; On the other hand, as a front-end engineer, I should have certain aesthetic ability, especially the ability to design and write some interactive animations. So with or without a designer, there are small “liberties” you can make with the details to improve the end user experience.
The backend development
At present, there is a very important link in the project under the mode of front and back end separation, that is, front and back end joint adjustment. Although it is the same development, it often hurts each other because of different focus. For the front end, usually due to the following points: 1. The front end of the interface is not friendly, for example, the data structure of the return value is deeply nested, or the front-end assembly of data after multiple requests; 2. Front-end implementation vs back-end implementation, such as paging, filtering, numerical calculation, etc. 3. Standard problems, such as consistency of interface field naming, whether it conforms to the same naming standard, error format, etc.; 4. Lack of detailed API documentation; 5. Backend services are unstable or buggy. For these problems, on the one hand, can be solved through technical means. For example, build an API management system, define the API according to the specification, and constrain API developers to write detailed documentation in a fixed format before releasing the API; At the same time, provide a testing environment for back-end self-testing; Or front-end deployment of the BFF layer, merging apis, etc. On the other hand, there are a few principles that front-end developers need to stick to when facing disagreements: 1. Back-end apis should be as independent of specific front-end interfaces as possible. This not only benefits API reuse, but also avoids the impact of heavy front-end logic on page performance; 2. Single point of maintenance principle: Sometimes, there are logic or functions that can be done on both ends, such as error message translation. At this point, uphold the principle of maintaining in one place, rather than each; 3. User first principle: The back end will consider atomicity more when defining the API; The front end is directly facing the user and requires more consideration of the user experience. But both the front end and the back end ultimately serve the user. So, for some apis that may affect the user experience, stick to the user first and even recruit interaction/design students to help solve the problem. In addition, the front end is often passive as the downstream of the project path. At this time, you need to learn to turn passivity into initiative. For example, use techniques such as mock data to reduce dependence on back-end development schedules. In addition to technical means, in the process of communicating problems, we should hold the mentality of finding solutions together, analyze problems together with the back end and find the best solution, so as to facilitate the rapid and sound progress of the project.
test
After the completion of joint commissioning, it is usually necessary to carry out testing and enter the testing stage before the project goes online. When you get to this stage, it can be frustrating to have a system that you thought was perfect but still has a lot of bugs. If that’s all, it’s actually okay. After all, it’s your own problem. But sometimes, depending on the tester, there are a lot of surprises. In terms of the tests I have experienced, I found that testers can be roughly divided into two categories: 1. Experienced testers can quickly locate problems and point them to the responsible party more accurately. In addition, they can make some suggestions on interaction or function optimization; 2. Novice testers, who do not know the cause of the problem, usually submit it to the front end first, or do not have a clear understanding of product design, or mention some invalid bugs; The former is fine, except that it will mention some bugs that you think are new features for you to fix. The latter requires a lot of patience. But there’s another way to think about it. In the second case, the test is actually more similar to the scenario of real users using the system. Instead of impatiently emphasizing whether it’s a BUG, ask yourself if this part of the feature design needs to be optimized. Will it cause problems for real users? You can even proactively engage the product manager to see if the product design needs to be adjusted or implemented as a requirement for the next iteration. In this way, you are virtually the enabler of project optimization. Also, don’t simply dismiss questions from your tests if you find bugs that aren’t your own. Help the tester to bring the relevant parties together to solve the problem more efficiently.
To change
“Change” is the most troublesome thing for developers. Often, a seemingly small change may involve many related problems and greatly affect the development efficiency. However, the reality is that changes can come from the demander side, product managers, interaction/visual designers, and even backend developers. Some changes “seem” inevitable, like getting feedback from users during development that they want to add a feature. Some changes may seem unnecessary but are strongly insisted upon, such as a button that the interaction designer felt was out of place before launch and needed to be adjusted. Many times, seemingly inevitable requirements changes can be avoided in product design, or better addressed, such as in the next iteration. Seemingly unnecessary features do not necessarily mean that they cannot be added. In my view, the key is to do the following things well; First, assess the scope of impact of the change. For large systems, small changes in product design can have a big impact, especially on common modules such as billing. Some small changes, if not properly scoped, may affect other modules or even become unusable; Second, assess how long it will take. Typically, a project’s go-live node is defined. Or, the time of the test will be strictly set and the test will have its own schedule. Once a requirement point is changed and the time is not properly assessed, in case of delay, the progress of the whole project will be affected; Third, weigh benefits against time. We should not insist that the requirements are already set in the beginning, and I will not accept any requirements changes in this edition. After all, most of the changes were made to optimize the product. If a change is assessed to have no impact on the time it takes to go live, it can be changed. However, if a certain change may be directly requested by the customer, it seems inevitable to change, but the modification needs to greatly extend the project cycle, at this time, it is necessary to make a trade-off, or adjust human resources, or adjust the technical solution. In short, we should not blindly reject or easily accept changes. We should fully weigh the advantages and disadvantages and make a reasonable judgment.
analyse
The word “rematch” originally comes from the game of Go. It refers to playing the game again after the end of a game to analyze the outcome of the whole game. For some large projects, a review at the end of the project can summarize some problems or experience to improve the efficiency of subsequent projects. Therefore, it is necessary to have a rematch. For example, I once worked on a project where, in the early stages of the project, the documentation provided by the product manager was very concise (only one page), but the project logic was far more complex than the documentation described. As a result, there are multiple requests to confirm requirements with product managers throughout the development process. In addition, in the middle of the project, the visual designer also made several visual adjustments, so that the whole project was much longer than expected. For this project, a review was made. Before recheck, special statistics of some data as a basis, such as the number of product document changes, the number of design draft changes and so on. In the meeting, uphold the attitude of things rather than people, list facts to point out the reasons affecting the efficiency of the project, and put forward optimization plans. For example, the product manager needs to prepare enough perfect documents before the project development; Visual designers need to organize review after the completion of the visual draft, as far as possible to avoid making adjustments after development. By optimizing the precipitation and promoting the implementation of the scheme, the subsequent projects are successfully guaranteed to avoid the same problems, thus improving the efficiency.
An enemy or an assistant.
Whose project am I working on? In my early days, I understood the projects I was working on as tasks. All I have to think about is how to implement them in code. But now, I realize, my first concern is not how, but why do I do this project? Specifically, what is the problem solved by the requirements of the project itself? What are the benefits? And then think, does the design of the product meet the demand itself? Is it the best solution? Will it cause some problems? In other words, on a project, think of yourself as a project owner, not just a doer. My partners, including product manager, designer, back-end development and testing, are my assistants, helping me to complete the project and push it to launch successfully. The premise, of course, is that you need to take the initiative to fully understand and acknowledge the project to make it truly “my project.” In this way, when THERE are problems in the cooperation, I will work hard in a positive direction for the project, rather than just satisfied with my own part of the work. For example, if there is a problem with an interface on the backend, you can report it to the backend and determine whether the problem is caused by the API GATEWAY or whether the value of a field is incorrect based on your own experience. This can help the backend solve the problem faster. This is not only conducive to the overall progress of the project, but also to reduce the cost of communication. After all, if I do not provide enough information and suggestions, I may increase the frequency of communication, which will also affect my development efficiency. In conclusion, remember, partners are not enemies, they are my assistants, we are partners working together for the same goal.
Mature business vs. start-up business
In all the projects I have worked on, there are mature product businesses and start-up product businesses, and the overall development process is quite different. For mature product business, the whole project process and role division are basically relatively complete. But that doesn’t mean the development process will be smooth. Some established processes may not be strictly followed, or a role may not be professional enough. When this happens, you need to compare the way you work with the characters mentioned above. In some cases, there will be problems with the partner, such as working attitude and responsibility. At this time, it may not be solved by one’s own efforts, but need to record the relevant process, and timely feedback to the superior to solve the problem. Startups tend to focus more on “speed” than mature businesses. Because the start-up business is likely in the market exploration period, the need to quickly complete the product promotion market; At the same time to timely iteration, to meet customer needs. In this case, the whole r&d process, or the division of roles, may not be complete. For example, there may not be full-time testing, but a product manager may work part-time; Or, not necessarily a designer, maybe we need the front-end to take advantage of off-the-shelf components and a little bit of aesthetic freedom. Obviously, at such times, it is often unrealistic to formulate a rigorous and complete R&D process in advance. So how do you ensure development efficiency under these conditions? In my opinion, the following points need to be done: First, with the help of technological means. For example, the most commonly used mock data decouples front-end and back-end development time. Startups may lack a lot of infrastructure compared to mature businesses, which requires more engineering work to optimize workflow and reduce communication costs. Techniques are also used to quickly build projects using off-the-shelf scaffolding tools or well-developed frames, such as DVA. Second, we need to improve our project management ability. The most basic point is to be able to assess requirements priorities. For front-end development, in addition to the basic functions achieved by calling back-end apis, a large part of the work is to improve user friendliness. For the start-up business, this part of the flexibility is relatively large. Compared with mature business, start-up business, especially technology-based start-up business, users have a relatively high tolerance for experience problems. Therefore, when the project time is relatively tight, reasonable assessment of demand priority and reasonable arrangement of RESEARCH and development time are crucial to ensure that the project goes online as scheduled. Third, complain less and make more suggestions. After all, start-up businesses have to face adverse factors such as tight project cycle, incomplete standardized process, and lack of infrastructure at the same time, so they will naturally encounter many problems. At this time, instead of just being the discoverer of the problem, we should try our best to be the problem-solver, or at least the problem-solver, which is beneficial to the whole team and the project.
conclusion
Software engineering and civil engineering are both engineering. There are some parallels: If I focus only on the work I was assigned to do, such as moving or laying bricks, if the whole design or a link goes wrong, even if I did a good job, the whole project will be affected, and even the perfect wall I built will be torn down and rebuilt. If I zoom in and see how my wall works throughout the building, I may find that the wall was not thick enough, and I may have avoided a rework by adding one more layer. If you zoom in further, you may also find that the bricks are placed too far away and that it takes a long time to transport them. Design drawings are not clear enough, always easy to read wrong… For the project development process, there are more or less process, personnel, norms and other aspects of the problem, at this time need subjective initiative, to break these problems, rather than choose to ignore and endure. Tell yourself that I want to get the whole project right, not just the task at hand, so you’ll find a way to push through problems. This is not only beneficial to the project, but also a personal ability to improve, isn’t it?