Product development process: details black hole time

Article Description: Product Development process: details black hole time.

Yes, that's it, because fast, so we are in a hurry, we forget the product logic, messy product structure, ignoring the page flow. This part of the time is ignored in the scheduling period, and this is a big detail time black hole, this black hole affects each of our products

At the earliest time, most of the product design used the waterfall model to do iterations, the previous process is completed before entering the next process. One of the biggest benefits of this pattern is that the next process is relatively well prepared, but the flaw is obvious: the iteration cost is too large and cumbersome. With the development of the internet industry, "fast" has become the industry's most important formula, so similar to "only fast not broken" become a popular product design philosophy. At the same time, the design cycle of many projects has been shortened.

Under the guidance of this fast word we save the detailed MRD writing, using the way of listing the function point to the research and development team to describe the entire product logic and core requirements; As fast as we could, we used the initial prototyping approach to show the product architecture and page logic we needed directly as engineers. Because it's going to be fast so the product staff described the high priority system that we're going to be doing. And say that these systems are our most important place, we prioritize these priorities first, and the researchers quickly assess and straightened the entire requirements description and initial prototypes, So the excitement began to dry ...

It all looks pretty good, doesn't it? We are much faster than before and we have a very important point. But is it really the case?

When the general schedule is finished, the demand is passed. The following developers began to do backend architecture and program logic, product personnel began to comb the needs before, the prototype to do refinement, the designer also began to try visual style. This time we are in a parallel way, we are much better than before.

Many times, things are so wonderful, do not comb do not know a comb startled. It turns out that when we were thinking about the show, we didn't take into account different user flow-oriented pages. Originally a simple data submission process has so many fork ports and leads to different back-end data processing strategies. Product personnel believe that these should be summed up, so the previous display page is subdivided into n different display styles; A previous submission process was split into a separate processing strategy for M. Each module so comb down after the original simple prototype was made perfect, originally a seemingly beautiful page structure was trimmed unusually plump. Previously, product personnel thought that the "simpler, more focused" system proved to be a very complex and heavy system. Of course, this process is the back-end engineers and product designers together to complete.

At this point, the problem arises. According to the previous requirements description and prototype to explain the estimated time of the development engineer on each system is more than one times more. Product personnel in the continuous "perfect" page logic and product architecture, research and development engineers continue to increase the cost of research and development. In the end, when the development cycle was over, we found it! Just finished the first stage ... so, everybody is anxious, do?! Cut the function, take the lower priority thing first, do the "core" thing first. After a flurry of rush, or a few weeks later than expected, on the line of a reluctant to go to the version.

So, what's the problem with the entire product development process in this case? Self-reflection, I think the product personnel caused "details of black hole time" too long, causing engineers to be too optimistic about the development of the project development Cycle Evaluation disorders. The crux of the problem, however, is that it is too fast to forget some of the cumbersome but still effective ways.

At the beginning of the demand, the product staff did not have a good ability to translate business logic into product logic. What is the core chain of the whole business? What motivates users to be driven by what is the power to embody on the product? What are the product modules that we have to do around this core chain?

The transformation of business logic messy will inevitably lead to a large structure of the product messy. In my own custom, before any product or even product module begins, it is necessary to draw a product architecture diagram that exists at the front of the MRD and at the front of the prototype. This has 2 advantages, the product itself can well comb the entire structure of the product and each fulcrum if there is a risk of the scope of the impact, when the demand is delivered, the next process can be clearly recognized first.

The next thing to do when the big product structure comes out is to simulate the process on each feeder, using the flowchart, each module needs. The general approach is to directly use the relevant page prototype to walk the flowchart, the next page of each page is what, there are several extensions, respectively, what page. This way, you can avoid the "detail time black hole" to the maximum extent.

Yes, that's it, because fast, so we are in a hurry, we forget the product logic, messy product structure, ignoring the page flow. This part of the time in the scheduling period is ignored, and this is a big detail time black hole, this black hole affects each of our products. If in the process of research and development, we find that the logic before is wrong, then the problem will be more serious ...

Of course, the situation mentioned in this case is relatively controllable, because the product personnel have relatively independent control rights. If there is more power at the top of the mix, the continuous increase in functionality, and constantly release the demand, then the entire product development process will be even worse. Recently Weibo on the popular a picture, that is the real tangle ( dot here on lookers )

Finally, the mention of "only fast and not broken", can't help but nag a sentence . Do not be "Internet products only fast not broken" into the ditch, this sentence is true, but pay attention to 2 prerequisites: The first shot must be fired, or later you even if the erection of high and no one looked at the same time need to consider whether they have the ability to deal with "fast problem" and timely perfect solution, If you have enough energy to cope with the long front, or the quick knife can easily be stabbed!

Special note: Details black hole time the word comes from a micro-blog , the author drew a very large and tangled product development process. Read a lot of feelings, combined with their feelings to write the above text.