A month ago, we launched a project that looks like a "lightning plan" and completed the system revision in two weeks, including prototype design, interface design, development, testing, and launch. The time is tight and the task is heavy. It looks a bit like an incomplete task. Finally, through the close cooperation of the entire team, and overtime work including weekends, the task was completed on time. However, this is just done, but it is not brilliant. This is the first time that I have participated in a complete project development with the entire team. From before to after the launch, it seems that the entire process is not so smooth, and there are many details worth thinking about. However, it is too late to investigate the issue. Now it is necessary to calm down and review and think about the advantages that can be followed and the disadvantages that need to be improved. Our current team is no different from a small entrepreneurial team:
- No complete project has been developed between members, and a break-in is missing.
- Our work processes, communication methods, and development processes are not strictly regulated. Most of them come to an agreement through instant communication. It is agile to say it is nice to hear it, but it is primitive to say it is hard to hear it.
- There is no clear process for requirement modification and code joint debugging, and no standardized documents are formed. It will be difficult to review the previous records in the future.
- In order to quickly complete the project, it sacrifices the time required to design the code architecture. Without a good architecture, it will be effort-consuming to change or expand the requirements in the future
These features determine that we will inevitably develop with the current process, but is there any way to improve the resulting problems? The answer must be yes. Now we need to review the entire process and look for the answer. When determining the requirements, all of our staff had a meeting. About five hours later, they had to go through all the things they had to do, and there were doubts about how they should be done on the spot. It should be said that all the doubts are solved, because we understand that such a meeting will not come again, and we will proceed with development. I think it is better that we will always come to a conclusion after the discussion about how to do this and how to do it. It can be said that we will "Have Results", which is very important. If you just stay at the level of Problem Discovery and problem proposal, then this will be the same as not going to happen. This is a point worth using. But will we have no defects? Apparently not. There are too many features involved in this revision, because it is a revision rather than a new one, so many of them are not seen. What we don't see is some hidden business logic, which can only happen in specific scenarios. Our old system logic is complicated. Our staff are new from product to development, and lack a comprehensive understanding of the old system. We sorted out new requirements, but there was a fatal flaw: we did not fully consider the conflicts between new requirements and old logic, we do not have a clear understanding of the reason why the old logic did that, the association between functional points or the preconditions. This fatal defect directly leads to the constant discovery of omissions in the development process, so that we have to improve the missing items first. The final development volume roughly estimates that there are 1.5 times of requirements documents above. In fact, many people have such experiences, and even feel that this is a good news. Many project development projects do not need to change. But this is not a good thing. How can we improve it? We held a five-hour demand seminar. Isn't it enough? Of course not enough, because we only open it once. Because we are revising and restructuring, we will inevitably find things that were not considered during the first discussion during the development process. After some problems have been accumulated, do we need to re-pick up the requirement document, review it again, and then a short seminar to add or cut out the necessary things. Our development process is still relatively smooth. Due to the limited time, we have adopted simple processing, repeated iterations, and rapid prototyping solutions, and some new design ideas have not been adopted, instead, it follows the original safer practice. For example, we plan to reduce the number of requests and make some page content obtained asynchronously. However, considering that there will be many changes, we will give up and copy and paste a lot of code, each page is also requested as originally. The page loading speed is not improved, but it ensures security. Let's talk about elegance or something. That's even worse. We hold a meeting every morning about 15 minutes to report the progress of yesterday and check today's task. Let everyone know, this is a good job. Now I need to ask a question. Is there any problem in the development process? Yes. Because we have had rework. In addition to the reasons for demand changes, due to lack of consideration, there is no clear solution, so I am eager to write code. As a result, when I write more than half of the code, I find that the solution is incorrect, and finally I will re-develop the solution, this is still very damaging. Now you need to tell yourself: even if the time is urgent, you have to think clearly before you start. As a matter of fact, there is a clear and correct solution, encoding will not take much time, and this 1.1 will cause misunderstandings. I think that the project is mainly to write code. After the development is complete, it is a tight test. We do not have a dedicated test group. What is the style of the entrepreneurial team. As a result, two interns from other groups, as well as product managers, developers, and customer service sisters, formed a test team. The product test was completed on Saturday and Sunday. The test method is the original function test. To put it bluntly, you can click here on the page as a user to run each function block again to see where it is going wrong. We do not have any auxiliary tools such as the bug library. After testing a round, the tester sends a group email to notify us, or communicates directly through IM, and then develops bugs Based on emails and discussion groups. This test process is obviously problematic. For a comparison, if we build a bug library, the standardized process is like this: the tester submits a bug to the database => the Development Manager/team lead assigns a bug to the team member => the developer changes the bug => the developer submits the bug to the test team for retesting => the tester marks that the bug passes/the bug still exists. submit it to the database again. The above process seems redundant, but the loss of any loop cannot ensure that a bug can be finally solved, and let everyone know that the bug has been handled. This is very important. Everyone can have a clear control over every question. Otherwise, when users come to us, our answers can only be vague, because we do not know whether the problem is solved or not. From our actual situation, we have encountered the following problems:
- It is easy to handle bugs by comparing emails, because the bug cannot be marked as handled or not handled, or the test error is not handled. It depends on the memory of the human brain. When a bug is raised in the discussion group, it is easier to omit it, because developers may not see this information at all.
- Bug claim. Some bugs need to be changed by the front-end, some need to be changed by the back-end, and no one has to allocate them in a unified manner. The division of labor is unclear. The team members claim their own bugs or communicate with each other. The time cost is too high.
- After the development and modification of the Bug, no response email is sent to the test to describe how the bug is handled. The final handling result of a bug is only clearly developed, and there is no document to record. There is no re-test of the Bug mentioned in the test, but it is finished after the test is completed. This lack of interactive communication leads to vague understanding of the results.
In this case, our testing process does have many problems, which directly leads to continuous feedback from users after our products are launched, most of which are bugs. Why did we do this? The answer is only one word: fast. In a limited time, a startup team cannot establish such a complete test process. This is also an objective fact. It seems that there is no solution to this problem. Is it true? At this time, we may need to go back to the root of the problem and think about the question: do we waste time or time to establish a complete workflow? The answer is not so absolute. Through the original communication method and the original workflow, we finally launched the product. After the product was launched, the stability period lasted for two weeks. The customer service team was busy with bugs. The Development Team is also busy. We have set up a discussion group in which we all report the problems we have found. The bug is like a bomb, and the development process is so full. At this stage, we are in the same predicament as the test phase. Too messy. All the problems found at this time are scattered, and even no emails are collected. Therefore, they are all mentioned in the discussion group. When changing the code, the developer noticed what problems were raised in the discussion group. Sometimes a bug has been modified for a long time, and N bugs have been collected in the discussion group. Sometimes, if you speak too much, you will miss out on some issues. At this time, it is easy to forget the number of bugs that exist by the human brain. At this time, there will be a situation where someone in the discussion group reflects a problem but no one responds. At the same time, due to the omission of feedback, the customer service and operation will feel that the response is not timely and cannot be explained to the user. All in all, it is a word: Chaos. The problem is obvious. We lack a person to coordinate our work. It should be the role of a project manager. However, a startup team like this, whether it is product or development, will strive to be on the front line. No one can take the initiative to co-ordinate the project, or sort out all the feedback, you have made a list one by one. If we can't assign a person to coordinate the progress, we have to draw a person out to do this. I think the most appropriate one is the product manager, and at the same time assume the QA role. At this time, product managers have high requirements and must communicate effectively with developers quickly. The so-called effective communication means that we must come to a conclusion about how to solve this problem, start now. The entire process is driven by the product manager. Sometimes I feel that the project is too fast to think about. In fact, this is a terrible thing. Project Development like this "lightning plan" is a very valuable experience. If you cannot learn something from it, it is really a pity. Now we have time to calm down and think about it. Our shortcomings are obvious and we must make targeted adjustments in our future work. Only in this way can we improve our performance, otherwise, it will always be a repetitive machine. Having no code word for a long time, I feel that the entire line of text is a little stiff. I recently read why I insisted on writing a blog, and I strongly agree with the point in view, because writing can encourage you to constantly think, and thinking is crucial to improving people.
