What are we going to do?

Some people say that the plan is accurate to the hour, so that it can be controlled.

Some people say that the plan cannot keep up with the changes, and there is no plan in your hands. Going with the changes is the plan.

As a manager, he certainly hopes to monitor the project progress in real time and detect risks in a timely manner. Some managers may wish to report the progress once every day, which may be necessary in some industries. However, I personally think it is a little exaggerated to do a half-day progress report in the IT industry.

How detailed is the plan? Here are my personal understandings and opinions on the granularity of the plan. If there are any mistakes, please point out that you should not make a picture. (Note: I have been engaged in product development for a long time and have 1.1 experiences in software product development .) Hahaha ^_^

First: a plan is required. If there is no plan, there is no target, there is no motivation, and the whole project is like a waste of water, and there is a risk of failure at any time. I personally think that product development should be combined with waterfall development and agile development. Instead of simply relying on one model. The waterfall development cycle is long, the development is complete, and the product is outdated. Agile development is suitable for projects. However, the emphasis on Agility during software product development will lead to inaccurate product positioning and confusion for the core value of products. In my opinion, combining the two is a good choice. waterfall development specifies the product positioning and core technologies, and uses agile development to quickly respond to the functional requirements of software product customization.

Second: software products must first develop a major direction and regularly propose new product concepts. These concepts need to be integrated with the market and fed back, and the Sales Department also needs time to instill this concept, so it takes a long time to advance.

Third: product development is divided into multiple milestones based on the major direction, and corresponding plans are formulated based on milestones. I personally think that it is a reasonable model to set software milestones based on factors such as the priority of product functions and the development cycle of a quarter. In the product development process, you will receive some user requirements and ideas from all directions. It is not long or short to use a quarter as a time period to absorb and digest these requirements. If there is no major demand change or increase, do not extend milestones as far as possible, because milestones will often cause inconvenience to other departments (such as sales departments and product implementation departments. If you encounter major changes during this period, there are two solutions:

A. work overtime. I think most IT companies choose this method. I personally dislike overtime. I generally require efficient work, So I generally adopt the second approach. (Of course, overtime is inevitable)

B. extend other development plans to the next milestone on the premise that necessary functions are met.

Point 4: split into monthly plans based on milestones.

Fifth: Split the monthly plan into weekly plans. The weekly plan is relatively flexible. I personally think that it is appropriate to split a plan into weekly plan granularity. As a manager, you have to spend a lot of time doing it. It is difficult to control the development progress of a plan that is too long. During the weekly plan, we should try our best to put the features with a higher priority in the early stage, because the features of the entire software should not be affected at any time in the development process due to some urgent changes to the user's needs.

Sixth point: after the implementation of the weekly plan, the summary is inevitable. It is necessary to take 30 minutes to summarize the weekly departmental meetings. At the same time, we have also trained our subordinates in their presentation skills.