## 2.2　與你的團隊溝通 成功的溝通需要你考慮討論內容以及在開始談話以前怎樣去說。你所做的溝通應該針對每一種情形做相應調整：要知道在一個環境中奏效的事情未必能在另外一種情形中起作用。 與你的團隊溝通時，要計劃涵蓋項目工作與人員方面的話題。項目工作要包括增加收入、降低項目風險、提升生產率的策略等開發涉及的方面。人員方面的話題應包括指導、培訓、矯正錯誤、答復問題、化解憂慮、討論長期問題和新觀念、工作上所需的幫助以及職業規劃幫助等。 通常，管理人員只側重項目工作，針對當前那些推動公司短期成功的實際問題。然而，溝通時不能不涉及其他可能會導致降低生產效率、增加人員流動、質量問題、失去機會以及降低積極性等問題。至少要花1/5以上的溝通時間跳出當前項目來談問題。要考慮到項目相關問題與員工個人相關問題間溝通方法的不同；每一種溝通方式都需要相對應的場合以確保溝通能正確解決相關問題。下面的章節討論了與你的團隊溝通的方法，包括一對一、項目溝通、團隊會議以及非正式談話。 ### 2.2.1　一對一 一周一次與個別開發人員舉行一對一例會給經理們提供了最好的機會來討論大部分人員問題。（相對而言，團隊建設則需要通過團隊會議來發展員工間友好關系并增強相互配合。）如果你的團隊多于6人，鑒于時間關系，你可以隔周搞一次一對一例會。 一對一例會提供了建立信任感及傾聽個人觀點的機會。讓員工來引導最初的討論。交談初始避免討論當前任務及所面對的問題。有時，開發人員并不知道如何開頭，你可以通過詢問如下問題作為開始。 * 你對你的工作有何憂慮？ * 近來遇到問題了么？ * 你有改進想法么？ * 你需要增加設備和軟件么？ * 你的長期職業規劃是什么？ * 你有可分享的想法么？ 一對一的會議非常適合討論問題、提供建議、商定問題的解決方案以及分配任務或要求針對某一問題提供解決方案。任務分工要明確，但是要避免對解決方案闡述得過于詳細。相反，應該像這樣成功地達成一致意見：給員工解決問題的授權，并提供建議。總的來說，不要立即將解決問題的任務分給提出問題的人。如果你習慣這樣做，你的員工將不會再提問題來引起你的注意。 > 不去傾聽 > 在我職業生涯的早期，我的老板是一個不愿意傾聽的人。當我帶著問題找他想知道下一步如何處理時，他會打斷討論并開始給我下指示。他總是在我說清楚我能解決的問題之前發布命令。我后來就不再跟他討論問題了。 > ——軟件經理 如果你想利用一對一會議推進項目進程，就要等到把別的話題討論完再進行項目狀態討論。如果你開始討論項目情況，將會耗費你全部的會議時間而其他問題不再會引起你的注意。 ### 2.2.2　項目溝通 你如何舉辦項目溝通取決于項目規模以及發布周期。項目發布周期較短時，每日站立例會——所有參會者站著開15～20分鐘會議——可能比較合適。經理每天同一時間安排會議，要求參會者就前一天的進展、今天的計劃以及需要的緊急求助做簡短陳述。站著開會不是為了解決問題或討論話題。相反，任何發現的問題可以落實到具體人員去解決跟蹤。 對于發布周期較長的項目，每周一次的項目狀態例會，同時結合走到同事的辦公桌前與他們交流討論的方式，可能比較有用。這個周例會通常30分鐘～1小時。項目狀態以及日程安排會議通常要包含一些細節討論，除此之外還應包括下幾周的計劃。也應包括團隊發現的一些風險以及項目經理指派一些人共同來應對并減緩那些風險。 你也可以憑借企業內網/維基（intranet/wiki）發布通告、電子郵件、白板通知或正式評審會等方式與你的團隊進行項目溝通。一些項目成員不是總會知道整體項目狀態或最近的項目或時間表變化。不與團隊溝通整體狀態可能導致混亂，而清楚地傳達這一信息不僅可提升工作積極性還可以提高項目成功的可能性。如果你為你的團隊提供正式的項目進展信息，他們會更愿意在早期指出問題和差異，而且他們也愿意把他們的進展狀態報告給你。 與團隊進行進展狀態溝通時，要根據工作量的大小規范報告的內容和頻率。項目進展狀態描述應該包括近期已完成的工作、下一階段要解決的問題、產品已修改的功能、截止到今天的完成狀態、遇到的問題以及當前存在的風險。 按時完成項目依賴于準確的進展狀態信息，這些狀態信息中應包括為項目中途更正留有的時間。 ### 2.2.3　團隊會議 定期安排項目會議將增強團隊凝聚力并提升團隊業績。團隊會議可根據團隊的大小每周或每兩周舉行一次。會議可辦成論壇形式用以討論總體問題或為新流程和政策提供培訓機會。團隊會議也可以允許團隊成員們討論相關內容或提出問題。 會議不應該是即興活動，不管怎樣，你應該事先準備一個議事日程或主題列表。在你桌面上打開一個文件并保持打開狀態，根據大家提到的內容隨時增加信息要點條目；這個文件將是下一次會議議事日程的基礎。一個確定的議事日程將有助于會議短小并且避免漫無邊際的討論。事先分發議事日程將使會議更有效率。 過長的會議會消耗精力并影響你們的成本底線，所以要盡可能把會議開得短小。長時間的會議也是代價高昂的——如一個12個人的團隊耗時2小時的會議等同于3個工程人日（24小時）。 要允許工程師們說出對諸如政策以及高層管理人員決策等問題的憂慮。跟蹤這些問題并且每周和團隊一起對它們進行評審，即使你們還沒有答案。要確認提供了相關問題的進展狀態并進行相應的補充，這些問題中既包括先前會議提出的那些公開議題，也要包含正致力于關閉的問題。 有時候，一個有不滿情緒的工程師也可能利用團隊會議去抱怨訴苦。如果這個工程師跨越了從建設性建議到破壞性抱怨的底線，那么就簡短地打斷談話并讓他單獨和你會面一起討論他的困惑。 規范的開發小組會議不適合進行細節技術討論。建立單獨的技術會議機制，這樣可以把重點放在特定的話題，并使得大多數會議開得比較隨意，以便人們不需要都出席并隨時可以退出。否則，那些與特定技術主題不相關的工程師們就要花費時間自始至終地來聽取對他們沒有意義的討論。