当前位置:网站首页>How did I lose control of the team?

How did I lose control of the team?

2020-11-07 20:15:28 zer0black

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

版权声明
本文为[zer0black]所创,转载请带上原文链接,感谢