這也是個常遇到的問題。如果管理者對于某個工程師的具體問題進行指導，會陷入過度微觀管理的境地。我們需要找到宏觀解決辦法。一，我們基于Scrum的“團隊有共同的目標”這一規則，利用前面提到的集體所有權，當出現這些問題時，用團隊中所有可以使用的力量來幫助其擺脫困境，而不是任其他人袖手旁觀。當然這里會牽扯到績效評定的問題，比如：提供幫助的人會覺得，他的幫助無助于自己績效評定的提高，為什么要提供幫助。這需要人力資源部門在使用Scrum開發的團隊的績效評估中，盡量消除那些傾向個人的因素，還要包含團隊協作的因素，廣泛聽取個方面的意見，更頻繁地評估績效等等。
二，即使動用所有可以使用的力量，如果某個難題真的無法逾越，為了減少不能按時交付的風險，產品負責人應當站出來，并有所作為。要么重新評估Backlog的優先級，使無法繼續的Backlog遲一點交付，先做一些相對較低優先級的Backlog，以保證整體交付時間不至于延長；要么減少部分功能，給出更多的時間去攻克難題�？傊庠郊夹g上難關會使團隊的生產率下降，產品負責人必須作出取舍。
7. 有些開發人員水平相對不高，如何保證他們的代碼質量？
當然首先讓較有經驗的人Review其要提交的代碼，這幾乎是所有管理者會做的事。除此之外，管理者有責任幫助這些人（也包括水平較高的人）提高水平，他們可以看一些書，上網看資料，讀別人的代碼等等，途經還是很多的。但問題是你如何去衡量其是否真正有所收獲。我們的經驗是，在每年大約3月份為每個工程師制定整個年度的目標，每個人的目標包括產品上的，技術上的，個人能力上的等4到5項。半年后和一年后，要做兩次Performance Review，目標是否實現，也會跟績效評定掛鉤。我們在制定目標時，遵循SMART原則，即：
Specific（明確的）：目標應該按照明確的結果和成效表述。
Measurable（可衡量的）：目標的完成情況應該可以衡量和驗證。
Aligned（結盟的）：目標應該與公司的商業策略保持一致。
Realistic（現實的）：目標雖然應具挑戰性，但更應該能在給定的條件和環境下實現。
Time-Bound（有時限的）：目標應該包括一個實現的具體時間。
比如：某個人制定了“初步掌握本地化技術”的目標，他要確定實現時間，要描述學習的途經和步驟，要通過將技術施加到公司現有的產品中，為公司產品的本地化/國際化/全球化作一些探索，并制作Presentation給團隊演示他的成果，并準備回答其他人提出的問題。團隊還為了配合其實現目標，組織Tech Talk的活動，供大家分享每個人的學習成果。通過這些手段，提高開發人員的自學興趣，并逐步提高開發人員的技術水平。
8. 如何提高開發人員的主觀能動性？
提高開發人員的主觀能動性，少不了激勵機制。不能讓開發人員感到，5年以后的他和現在比不會有什么進步。你要讓他感到他所從事的是一個職業（Career），而不只是一份工作（Job）。否則，他們是不會主動投入到工作中的。我們的經驗是提供一套職業發展的框架�？蚣苤贫�2類發展道路，管理類（Managerial Path）和技術類（Technical Path），6個職業級別（1-3級是Entry/Associate，Intermediate，Senior。4級管理類是Manager/Senior Manager，技術類是Principal/Senior Principal。5級管理類是Director/Senior Director，技術類是Fellow/Architect。6級是Executive Management）。每個級別都有13個方面的具體要求，包括：范圍（Scope）、跨職能（Cross Functional）、層次（Level）、知識（Knowledge）、指導（Guidance）、問題解決（Problem Solving）、遞交成果（Delivering Result）、責任感（Responsbility）、導師（Mentoring）、交流（Communication）、自學（Self-Learning），運作監督（Operational Oversight），客戶響應（Customer Responsiveness）。每年有2次提高級別的機會，開發人員一旦具備了升級的條件，他的Supervisor將會提出申請，一旦批準，他的頭銜隨之提高，薪水也會有相對較大提高。從而使每個開發人員覺得“有奔頭”，自然他們的主觀能動性也提高了。
上面的“套路”涉及了軟件研發團隊管理中的研發過程、技術實踐、文檔管理、激勵機制等一些方面。但只是九牛一毛，研發團隊管理涵蓋的內容還有很多很多，還需要管理者在不斷探索和實踐的道路上學習和掌握。
