scenario

We often encounter inaccurate front-end estimation. This article shares the third part of the series on how to give a more accurate time when determining the schedule of formal project approval.

The red line items

The following things should be absolutely avoided, otherwise there will be a serious risk of delay in the middle and later stages of the project.

  • Interface documentation must be presented in front and back end breakdown, at least in the early and middle phases of the development cycle, including major business interfaces, business models
  • The business logic of the core process, different users, and other boundary cases must be considered
  • UI design draft, interaction draft, 90% must be finalized
  • Before and after the end of the system, as well as the early and middle stage of development, must be for the possible risk of the part of a certain description and record, to the project team, product description
  • The requirements of project organization must be prioritized, and the details of the requirements must be adjustable, with some room for choice in the event that r&d cannot be achieved
  • The buffer time must be 30-50% of the normal development time
  • Make some progress determination every day, adjust priorities and follow-up plan in time

Add topics to your journal

Evaluation of time

  • Style section: 1.5D (hashtag style, Topic selection mode page, diary post success page), points on details
  • Business logic part: 0.5D topic display field, query topic classification and list interface, submit diary
  • Data model: Different classifications of 0.5D topics, state impact on display, and business logic
  • Product interaction and page hopping: 0.5D
  • Interface intermodulation: 0.5D

Under the condition that the basic logic is smooth, the above function needs 4 days, including buffer, it should be about 5.5 days.

Another example: a personal homepage with a topic entry

For example, in a relatively unfamiliar applet environment, adding a topic entry to a page of personal interest looks like a div display without requesting an interface, but in fact there are many pits. Do the full enumeration:

  • You need to find the entry to this page
  • Implementing UI components
  • Example Query the attention status of a topic
  • Make the topic list entry, click to realize the jump
  • Whether to update when switching between different tabs
  • Whether to update when returned from the list
  • Whether to update when the top is double-clicked
  • Some materials use pictures or ICONS
  • How components are invoked and communicated

Familiar with the situation, 2-3 hours; For unfamiliar situations, 0.5 days is recommended

The basic principle of

Let accurate estimation become the norm

Compared with fast delivery for a short period of time with a bunch of bugs and resource mobilization, delivery on time is more important, we should ensure a function point on there is enough time to deal with various problems, rather than a rough feel this thing is very simple, is 1 to 2 hours, especially the toC business, general layouts and interactive version will be more strict, There will be a number of detailed inspections.

So don’t worry about others say you do things slowly, in the case of quality assurance, there is no problem with slow, the problem is to let others expect too much of you, and then can not be fulfilled.

Use buffer time to ensure quality

Buffer time is not used to reduce work pressure, but to increase work pressure. In the case of buffer time, we should try our best to improve details, discuss details, optimize the overall architecture and performance, ensure the overall delivery quality, and provide good codes and documents for the next iteration.

To design something, to sharpen it for the future

Instead of just writing repetitive code, which is inefficient, we should focus on maintaining some logical, component efficient ways of using it.

After the accumulation of some scenarios, businesses and projects, the proportion of buffer should be smaller and smaller in the iteration of accumulation nature, and the delivery time of the same and similar requirements should be shorter and shorter, so as to provide more and more standard and fast delivery technical products.

And that design, that thinking, should also be part of the front end evaluation. If you feel that some part of the requirement is similar this time, or that it is the same as last time, then it is important to mention that the front end has a refinement work that separates the common components.

Related articles

  • The project’s analyse
  • Phased refinement