Today I answered a question on Zhihu "How to communicate with engineers about time progress? , I thought a lot after answering, and felt it necessary to summarize how to effectively evaluate the time progress of engineers? this problem.
1. Task dismantling
I'm not going to discuss how the plan is made here, just the importance of task breakdown for an engineer's assessment of the duration. Usually, most engineers don't do task disassembly and don't know how to do it. When you ask an engineer how long it will take to develop this project, he will tell you that it will take 10 days, but you don't understand why it takes 10 days, maybe he himself doesn't know why it takes 10 days, just based on the past empirically assessed. There are still 10 days not equal to 10 working days. This is a trap. Don't be fooled by 10 days. If it is 10 working days, it means 2 weeks, which is 14 days.
The most important step in task disassembly is system design. No matter what method you use, whether it is written, oral, blackboard drawing, or very NB using UML, you must complete this step, according to project requirements, application scenarios, etc. The factor design system breaks down a large function into small functions. Usually, I like to design the system in an interface-oriented way, so that all the people involved in the project development (front-end and back-end) are interface-oriented development. When discussing and communicating, everyone only needs to demonstrate the input, output and rationality of the interface. , do not have to care about the internal implementation of the respective interface. When a large function is disassembled to a sufficiently small granularity, time evaluation is performed only for a single interface implementation, which is much easier and the time obtained is relatively reasonable.
2. Communication
Before the project starts to develop, the project personnel must communicate fully, and the communication must be barrier-free, and the communication process must be active, especially the developers. In my past experience, many developers will not take the initiative to seek help from products, requirements, and interaction personnel. When encountering unreasonable demand problems, they will not take the initiative to raise them. They will not find this out until the development is almost completed or even completed. The problem, by then, may be a lot more serious. It is very important for developers to share the information of the project with the participants and ensure that everyone has a consistent understanding. Unclear and wrong requirements will directly affect the system design process, resulting in functional deviations in development.
Requirement changes must be careful, any change in requirements may lead to changes in the construction period. Usually, after an interface is defined and development begins, it is very risky to change the requirements. The change of a requirement is serious enough to make the whole system roll back to the design stage. Before the change, the engineer must be fully communicated, and then the requirements can be changed as appropriate.
3. Reasonable evaluation time
If you want to increase the time of evaluating engineers reasonably, it is necessary to fully understand the work and rest rules of engineers, and whether it is important to know what each engineer is doing every day. Usually engineers will work on the same things for a fixed period of time each day, and the things handled during this period may include:
- Deal with daily bugs
- Read technical documentation
- A small amount of rest time (swiping Weibo, watching Zhihu, etc.)
This fixed time should be removed when evaluating how much time an engineer can spend on a project each day. For example, it takes a total of 100 hours to complete the project development, and the engineer has a fixed time of 3 hours per day, then the development cycle of this project is 100/(8-3)=20 working days.
In addition, during the project period, there may be unexpected situations, such as the insertion of some emergency events, or the engineer taking a sick leave or something. These are risks that need to be considered, and generally will be increased by 1/4 to 1/ 3 times as a buffer period for development.
If all the above 3 points are fulfilled, it is enough to deal with some small projects. For large-scale projects, more adequate system design is required, including feasibility analysis, design documents, technical research, test cases, etc., and project management also requires more professional people to complete (risk control is also a part of project management).
PS: Rule 3 does not apply to hard-working startup teams.
For Example:
Taking my mobile phone Sohu Gallery 2.0 project as an example, it is recommended that you first open " http://m.sohu.com/p/419214/ " to see a function implemented by Gallery 2.0. Gallery 2.0 is a revision of the previous Gallery 1.0. I did not participate in the development of this project, but handed it over to two other developers to complete. I participated in the design process and made subsequent development and launch plans.
At the initial stage of the gallery project, after fully communicating the requirements with the product and interaction personnel, I grasped the most important requirement. When I click on the picture contained in the news text page, the gallery will be opened to display a large image. However, there are functional differences between viewing a large image on the text page and viewing the final page of a group image in a gallery list. In order to solve these functional differences, I designed the main frame of group image browsing as a core function, and loaded different functions in the form of plug-ins. components to achieve differentiated display. Finally, in order to decouple the main text view from the core functions of the group picture, I designed a group picture adapter for the text page, so that the group picture and the text page are isolated from each other. The group picture does not care how the text page uses it. You can implement some special functions that are unexpected from the core functions of the group map according to your own needs.
After the front-end design is completed, the involved interfaces are described in detail, including: input, output, and implemented functions. When everyone is discussing and working, they are all interface-oriented, and they can be responsible for each other's interfaces. Gallery 2.0 confirms a total of 1 core function, 6 plugins, and 1 body page adapter. For the core function of the group map, you can actually continue to disassemble it, but I think it is unnecessary, because this function can be developed in 2 days. Both developers are newcomers and do not have much experience in JS development, so they will be relatively slow. Finally, I confirmed with the developers that it takes 50 hours of work to develop these functions and complete debugging, and it takes 5 hours per day to develop. Then it takes 10 working days, which is 5 working days for 2 people. When I finally communicated with the product, I set aside 2 days for anti-risk time for the delivery of 7 working days.
In the end, the project was completed very smoothly. Clear project requirements, only some detailed adjustments were made in the development and did not affect the construction period. In fact, it only took 5 days to complete the development, which is exactly the same as the estimated time. According to the 7-day delivery, we also completed the project 2 days ahead of schedule.
summary
In the past, I have experienced many large and small projects, written formal design documents, drawn detailed UML, and compiled complete test cases. I don't think these are necessary conditions to ensure the development progress of engineers. In daily work, you should know more about engineers, communicate more, be familiar with each engineer's ability, share information after analyzing the project requirements, disassemble the tasks in enough detail, and let everyone reach the same project goals and arrange them reasonably Development time, and finally ensure that the development progress can be carried out according to the project plan.
Finally, I would like to share with you an interesting article "Several Gorgeous Development Methods" .
Original article, please indicate the source for reprint http://zhangdaiping.iteye.com