How did I lose control of the team?

I'm an unqualified technical director , In the last three months or so . I take from 40 Multiple R & D teams （ Include requirements 、 Development 、 test ） Pull it out 20 More than one person to open up territory for the company . In the last three months , Let's fight together . In the process , I spend more than half a month all night , Till the early morning 4/5 There are countless days to order , Till the early morning 1/2 Some days are more used to . Most of the team didn't have weekends for almost two months , Hard work , It's a real peak experience . But three months later , I came back to the company with failure and a whole body of painful lessons .

In this experience, I feel how I lost the control of the team . What I call team control , It's not that the brothers didn't listen , Not following the plan . It's about me... To the entire development team 、 Test team 、 The requirements team has a new understanding , A new understanding of the team , I have met more than 20 people again . Because of the judgment error of individual and team ability and the judgment error of project difficulty , It led to the painful lesson .

I will share with you the difficulties and problems I have encountered , I will also share my decisions with you , And share with you all the mistakes I realized . I hope to remind everyone who is facing this situation .

Project and team background

1. There are four projects in three months , There is no formal project manager , There are only three trainee project managers
2. Among the three internship project managers , One with a small sustainability project （ Front and rear end together 3 people ） Nearly a year ; A small project with too much （4 people ） A month ; One with two small and medium-sized projects （7 people ）, Half a year in total
3. Development colleagues are relatively young , The longest working life is three years . Vigorous but inexperienced
4. Old colleagues and new colleagues account for half of the team , More than half of my colleagues have been in the company for less than a year
5. Four projects are based on the same customer to provide the basic version （ Or framework ） Development
6. The basic framework used by the client is too old , The front and back frames of more than ten years ago , The front-end uses the technology specially the side door , Learning costs a lot
7. The frame is in a mess , Watch is fast 2000 Zhang , It's a framework, but it contains all kinds of business code , And you have to use
8. It is difficult to configure the environment for development and debugging , The project must run in linux On , Only remote debugging . The project is too large , Start slowly , Compile it once 10 More minutes . Our team is not familiar with this pattern , It took a while to fumble
9. The client company is large , There are many R & D departments . Department coordination accounts for more than half of the development process , It needs to be connected with all kinds of equipment , All developed by other departments . Departments kick each other , It's difficult to find someone to help

A wrong ： Overestimate team level

1. I think I know my colleagues well , In fact, the understanding is too one-sided . In the past year , Because the project is relatively stable . Continuous output is within control , The customer was quite satisfied . This led me to the illusion that our team was good
2. The whole team is facing a new environment , Weak adaptability . It's hard to produce quickly and stably , The project started for two weeks , Basically in a familiar environment 、 Be familiar with the status of the project , There has been no effective output . Lead to waste of time
3. Such as A Newly recruited 3 More than a month , In other projects , The evaluation given by the project leader is not bad , That led me to put him in an important development position . But at the beginning of the project , I found out A The technical level is a little bad , Multiple tables associated query sql I can't write well . No one can take his place at this time , I can only go up and help him
   Such as B Over the past year , With the project has been stable without major problems . But in the new project , The ability of understanding is weak and cannot understand the needs quickly and comprehensively . At the same time, it also exposed some B There is no fatal flaw in risk awareness , Can't identify risks , Identify the risks and don't give feedback , This led to multiple ticket skipping

reflection ：

1. Assessment is very important , Comprehensive assessment feedback is more important

   • In terms of people and teams , The most deadly question , I think it's about the assessment mechanism . For a variety of reasons , The understanding of colleagues is too one-sided . Put people in the wrong place in terms of employment . The sniper is in the main position , The main attacker is in the position of commander . It's strange that we don't lose the battle
   • Stand in a high position , It's easy to misjudge the abilities of the following colleagues . In my opinion , In the case of a small number of people , The best way to get to know everyone , It's a fight . In a battle , Observe everyone's attitude performance every day 、 Efficiency output 、 Code quality 、 The coordinated ability 、 External communication ability, etc . After a project down , Can have a more comprehensive understanding of the members of this project team . But this way, you can't just look outside the project , And we need to work together on the same project
   • To know a person from many sides , Listen to more than one person . For someone like that A Come on , It's because I only heard one person's words that there was a big miscalculation （ some A In another project , Only the export function , No access to database ）

2. Don't look at people with still eyes , People are changing

   • People are changing , And I used my experience to judge you . Some overestimate , Some underestimated . Didn't assign the most suitable person to the most suitable project
   • Past mistakes or functions should not be recorded in today's accounts , Keep up with your changes , Keep new understanding of you all . Don't look at people in their own eyes
   • It should also be through positive guidance , Help colleagues to overcome their shortcomings . Instead of letting it go , To live and die by oneself . That's the only way , Team can improve , This is also a leader The best thing to do , I'm far behind in this respect

3. It's not advisable to decide people because of things

   • some D Because of a technical pre research work , Let me think he's average . But in this project , He became the most stable output link
   • thus it can be seen , It can't be because someone does a good or bad job , I've made a model for this man , A preconceived conclusion . To evaluate an individual objectively , Need to know all his history and all his work . That's what the first one says , There should be a comprehensive assessment feedback mechanism

Error 2 ： Underestimate the difficulty of the project

1. The total number of projects is 4 individual , Each project （ Only support IE） We need to develop middleware with additional customers 、 plug-in unit （ActiveX）、 A variety of hardware equipment docking . Equipment that has not been connected with hardware before , Underestimated the difficulty of docking
2. middleware 、 plug-in unit 、 I never thought of the docking of hardware equipment , There are no documents . You can only search for history code learning tests , Or go to the relevant departments to ask . And in the previous communication process , In my mind, the default docking is documented or directed by a special person , Didn't ask clearly
3. The front end uses the framework （2006 The framework and version of ） Too old , Due to the lack of understanding of the front end , Wrong estimate of learning curve , The front-end colleagues of the team are very hard at the early stage of development , Progress has also been delayed for a long time in this area
4. The difficulty of cross department communication is far beyond my imagination , In the previous communication process , Make clear that there is a special person in charge of cross department communication , But in practice , All become our own docking . All departments play ball with each other , What kind of camera is it （ Testing requires a specific type of camera , I don't know what model I borrowed from the receiver ）, I can spend 3 I ran five floors an hour to get the answer . Let alone code level guidance
5. I didn't know the real situation of the customer's frame , I think it's in spring On the enclosed scaffolding . I didn't expect that the framework contained fast 2000 A watch , Millions of historical codes . There are three different sets of user modules （ The framework will be based on customization , Regularly integrate customized content into the framework trunk , It leads to all kinds of useless legacy code ）, It's more difficult to find the function you want to use

reflection ：

1. Experience is very important , But experience is also deadly

   • In this early communication , A lot of me think , I think it's all empiricism . For example, the problem of docking documents , Ask more , Maybe it's very different
   • Experience can also be one of the risks , Need to be alert

2. Try to get more information

   • The information of the four projects is not comprehensive , More information is missing from me , And I thought that was the whole story . The lack of information is the loss of direction in judgment
   • In existing information , To dig out more problems and information , And find the right person to confirm . The more information, the more accurate direction can be provided for judgment
   • It's also unclear about the situation of the receiver , Need to push the receiver to find the right person to get , Get relatively accurate and complete information

3. Key points and difficulties of the project

   • In these projects , Some projects don't grasp the key points and difficulties at the beginning . For example, the core function of project a is storage , And need to use customer self-developed storage devices , At the beginning of the project, this key issue was not locked , Lead to rework of all the core functions of the later project
   • Generally, we adopt the elimination method to lock in the key points and difficulties . List all visible and hidden function points on the page , Exclude the independent modules with less association by exclusion . What remains is the key element of the difficulties
   • Make clear the relationship of each core element , Get the final functional diagram （ Business Architecture ）

Error of three ： Tactical mistakes , Facing too many projects at the same time

1. Looking back , It's wrong to take on too many projects at the same time when there are not enough people . But it's really a dilemma , You can't simply sum up... By mistake or right
2. To take or not to take , This is a game process . Whether the comprehensive analysis project is sure to be done by us , Reanalyze the ability to complete , Think it over before you come to a conclusion

reflection ：

1. There is always a shortage of resources in projects , Never think about having the right resources for your project 、 personnel . After all, the best people can't be waiting for your project all the time
2. Taking events is like playing cards , A good hand makes a good project . And winning a bad hand is your ability

Error four ： Management is not easy

1. The last mistake , It's when the project is empty , I had to take the project . After getting into the details of a project , There is no one who can manage and coordinate all projects
2. Management is very exhausting , It needs special personnel to deal with . One of the major responsibilities of managers is communication and coordination , Especially in the projects that need strong communication
3. Once in a specific project , It's hard to have the energy to sustain other projects
4. Authorization is important , But inspection is more important . The work delivered , Check regularly , Guarantee that the deliverables are complete 、 complete 、 No rework

A summary of the lessons I've learned

1. It is very important to establish a more comprehensive assessment feedback system for understanding the team
2. Don't limit yourself to experience , Communication is better than everything
3. Reflect on every tactical mistake , Guarantee the next accurate strike
4. A special person specializes in , A full-time manager , Don't get caught up in development details , Once a lot of energy is put into development . It's going to be a fatal risk