Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what to do about the old postponement of DeadLine programming". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Rational allocation of resources

One reason for the delay that is easy to ignore is the lack of resources. Therefore, before the start of the project, it is necessary for PM or project Leader to integrate resources, to find the participants and tripartite resources needed by the project, so that the project can start smoothly. You can consider the following:

Staffing, PM can consider staffing before the project starts. Arrange who will do it or how many people will do it according to the workload of the project and the relevant work experience. And do a good job of personnel gradient, I certainly hope that the team is full of experienced "big brother", but in fact, the "big brother" salary is high, the younger brother can not bear it. It is generally reasonable to have a team gradient to bring the new with the old.

Knowledge configuration, the project may involve multiple, many aspects, including product, UI, development, testing, etc. It is best to deploy people with relevant work experience to participate, if not, through recruitment or through knowledge research and other ways to fill the knowledge gap.

Resource allocation, server resources required by the project, tripartite software and hardware resources, etc., should be taken into account as far as possible.

Resource collaboration, in some teams, technical authorization takes precedence over requirements and design authorization; in others, it is subordinate; and in the best teams, there is a collaborative relationship between these types of authorization.

Clear requirements & Review

Requirements document is a product from nothing to visualization process, is an important basis for all the work in the later stage, if the follow-up work process to constantly review the requirements process, it is undoubtedly a waste of time. Therefore, a clear requirement is very important, from the first draft to the final prototype, can be continuously refined through some reviews.

The review recommended that all participants participate in the project, including PM, product manager, development, testing, etc.

The purpose of the review is:

Let the people involved in the project fully understand the project

Find out the deficiencies and supplements in the requirements, and record them for the next review or later work.

Get the people involved in the project to agree and approve what the project needs to do.

Risk control.

There will not be only one review, but try to output some complete prototypes with the least number of times.

Review questions and questions, this is not to deny the product, but through questions to promote the product review process, so that people know what to do.

The final output is the prototype manuscript that everyone has always understood and agreed with.

Necessary "business requirements into technical requirements"

This process is actually a necessary stage in the process of the project, but most teams often ignore it, or do not do enough, causing confusion among later code developers. Some teams also feel that this is also OK, our engineers are very experienced and have a good understanding of the code structure, but the lack of documented process often makes it impossible for follow-up maintenance personnel to start.

This part of the work will have different answers depending on the business, and each IT architect's focus on the answer to this question is more or less unique.

Here is a suggested process:

Abstract the service model and sort out the services we are going to provide with the customer as the core.

The service process starts from the customer experience service, and the arrangement of the interaction process among the client, the server and other service providers.

Task decomposition, the tasks in the process will be divided into small tasks, as detailed as possible, and output work list, each work separately evaluate the completion time.

Reasonable progress

First of all, what is the purpose of the schedule? there are three points:

The first is a commitment, a commitment to when the task is completed, to determine when and what work will be delivered by each person.

Second: everyone strives to regard their own tasks as an integral part of the whole project, and can combine their own tasks with those of others, if everyone can complete their own tasks on time and reasonably, so as not to affect the work of others, it is a benign promotion for the whole progress.

Third, it provides a tool that can track projects and divide work into manageable pieces. Dividing the work into one or two days can help the team better understand what they need to do.

We need to use good tools to manage progress. Documentation, traceability, and collaborative development are essential to the project. Smart teams will find some tools, or develop their own tools to help them, such as Jira or GitLab WorkFlow.

Personally, I also prefer to develop or find some tools to improve team efficiency, because any written, artificially supervised rules and regulations are not as effective as using a tool to monitor, prompt and help people to come. It is suggested that the team should accumulate experience according to their own situation and find the most suitable tool for the team. Again, the ultimate goal is "Everything is OK!"

Build a cohesive team

Keeping your team cohesive is the most powerful weapon to deal with any postponement. PM or team leader can make efforts in the following areas:

Communicate

The whole process of the project is accompanied by an important element, communication, or to be exact, quality communication. There are five basic states of communication: communication, receipt, understanding, consent, and transformation into effective action.

Communication also often fails, the reasons are not clear enough, do not listen, understanding errors lead to the team from opinions on things to personal attacks, there is ridicule. The team is made up of every natural person, and it is possible for the newly established project team to be strange and distrustful of each other.

Here are a few suggestions:

Make clear the roles and their respective tasks

Self-introduction, through the past work and life background, let us know each other better

Motivate, challenge. Each role gains mutual trust through efforts to output results.

Clear project goals, let each role ignore some unnecessary, work towards the same goal

The project manager starts with himself and strives to help others and make the team more United.

Put proper pressure on the team

Pressure is a compulsive and restrained influence or force that exerts and relieves stress is something that every team should consider, which can be divided into:

Exerting pressure can be artificially positive pressure, and people who work harder and improve their performance in difficult times will be rewarded (such as salary increases, promotions, bonuses) and negative pressures, including scolding and making people feel guilty. or threats to make people work hard in this way. I personally advocate using more positive pressure to estimate others and appropriately using some negative emotions. It's just a strategy depending on the situation of the project.

To relieve stress, most of it is to give up temporary work, organize sports and travel with money (if there is much in the team). Personally, I prefer tea parties. We can get to know each other while drinking tea.

Proper heroic complex

In fact, a small amount of heroism is a good thing for the whole team, which can improve the overall efficiency and competitiveness of the team. But watching too many heroic or hacker movies can cause instability in the project.

From the perspective of past work experience, there are more work in programmers, especially those who have worked for a year or two, or those who have just entered a team eager to prove themselves, or even have worked for many years, mainly in that there is no reasonable code design and there is a need to go directly to the code. An overconfident evaluation time. Do it only for yourself, indifferent to the work of others, and will not actively cooperate.

So after the programmer interview, I often ask some related questions, for example, do you think which of the colleagues in the company in the past had better skills? Did you learn anything from him or whose code design do you think is more powerful? Let's take a look at each other's sense of teamwork.

Face the mistake bravely

Iterative development will inevitably have a lot of problems, and the team that is ready to deal with and solve all kinds of problems is strong.

Closed-loop thinking of problem solving: the project goes smoothly-> the problem occurs-- > realize that this is indeed a serious mistake-- > calm down-- > find out where the problem is-- > solve and go online-- > the problem is not happening-- > the project is going smoothly.

Try to make the cycle as short as possible, the project from a smooth final to a smooth closed loop, and finally hold a question review meeting if necessary.

Finally, we need to note that the delay is not to deny their own team and their own efforts, PM should lead you to review the project and sum up the project experience. Don't make the same mistakes in the next iteration cycle, the most important thing is to make progress in the team process.

This is the end of the content of "what to do with the old postponement of programming for DeadLine". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.