如何進行團隊溝通

不論身在哪一個工做崗位，都要進行溝通，今天跟你們分享一下，初入職場的溝通方式、原則以及如何才能進行高效的團隊溝通！

在工做和生活中，70%的錯誤是因爲不善於溝通, 或者是不善於談話形成的，卡耐基說過：'溝通的最高境界是： 說，要說到別人很願意聽！ 聽，要聽到別人很願意說!「一我的只有與他人準確、及時地溝通，才能創建起牢固的、長久的人際關係，進而可以使得本身在事業上左右逢源、如虎添翼、最終取得成功。

1、在實際開發中，在項目啓動前期，最重要的工做莫過於瞭解客戶的需求，在需求調研時，在與客戶進行問卷調查、訪談、開需求會議時都離不開有效的溝通。在項目開發過程當中，項目組成員之間的溝通更直接地影響着軟件生產的效率和質量。

      在軟件開發中，如何才能進行及時有效的溝通？在實際開發中，由於軟件工程師的工做與不少崗位有交集，因此與其溝通、交流的崗位相對比較多，主要有項目經理、架構師、客戶、測試工程師、運維工程師、其餘軟件工程師、Ul設計師等，在一些公司可能還須要與產品經理和質量工程師進行溝通。

2、團隊溝通的原則：

　　★在開發過程當中，不論在與客戶、領導仍是同事交流時，首先要思路清晰，明確本身想表達什麼，本身的觀點是什麼，在表達時要簡單明確、有條理。沒有人願意聽漫無目的、喋喋不休的論述，因此這也是 "職業素養訓練」 部分要求你們鍛鍊溝通表達的目的。另外，團隊中的每個成員必須確，咱們所作的都是爲了把工做作得更好，因此有問題只針對事不要針對人。

　　舉個例子：測試工程師測試時，發現你的 Bug 不少，反饋後，你就要進行確認並修改，此時咱們不能認爲測試工程師是和咱們過不去，測試Bug是他們的職責，咱們要作的就是提升技術水平，寫出更高質量的程序；

　　　　★在工做中團隊成員間的溝通要遵照如下幾個原：

　　　　　　1）、毫不口出惡言，不說不應說的話；

　　　　　　2）、不批評、不指責、不抱怨、不攻擊、不說教；

　　　　　　3）、有錯就認可，敢於承擔責任；

　　　　　　4）、表達清晰，簡單明確；

  ●與上級溝通：

    ★在企業工做中咱們發現，軟件工程師在與同級的同事溝通時通常比較順暢、輕鬆，而與上級溝通時經常存在一些障礙，如下是與上級溝通時的方法和思路：

　　◆溝通要真心、坦誠、尊重、服從上級、但不吹捧

　　◆不要惟惟諾諾，不要恃才傲物

　　◆不要怕說，要勇於說

　　◆要主動報告，讓上級對工做進度瞭如指掌

　　◆主動而不越權

　　◆須要上級提供幫助時，要明確提出

　　◆不發牢騷，不要只提問題，而沒有解決方案

　　◆真誠接受批評，要有氣量，不必頂嘴也不要不在意，

　　★在任何一個團隊中，你的上級都但願你能脫穎而出，能承擔更多的責任。當你能作得更多、作的得更好時，你在團隊中的影響力就會提高，發展空間就會越大；

3、團隊溝通的形式：

●在開發過程當中，軟件工程師經常使用的溝通方式通常有當面溝通、會議溝通、郵件溝通和文檔溝通等；

　　如圖:

　　　　　　

●當面溝通：

　　★不管是在工做仍是生活中，當面溝通都是最經常使用的溝通方式。尤爲在工做中，當面溝通是一最有效的溝通方式，能夠下降溝通成本在。

　　★在一些軟件開發企業中，有一種奇怪的現象：不少軟件工程師在開發中，遇到問題習慣上網尋找答案，並不向有經驗的同事請教。上網查找解決方法是一種獨立解決問題的能力，值得確定，但有時候對於一些與業務相關的問題，網上是沒有現成答案的，這時候但願你能虛心向身邊有經驗同事請教，不要以爲請教別人問題就顯得本身無知。每一個人都是從初級程序員成長到高級程序員，只要你努力技術水平很快就會提高，當前重要的是按時、高質量地完成工做任務，因此軟件工程師與同事當面溝通要注意的第一條就是要虛心，不嘲諷別人。

　　★在工做中，當面溝通不是嘮嗑、聊天，軟件開發是腦力勞動、你們須要一個安靜、平和的環境，因此在與同事當面溝通時不要聲音太大、時長過久而影晌別人，要針對問題核心進行交流，提升溝通的效率；

　　★在當面溝經過程中，若是與對方意見達不成一致時，不要爭論，爭論對於問題的解決沒有任何的意義，正確的作法是向上反映請示領導，在向領導反映問題時不要抱怨對方，更不能說對方的壞話，作到對事不對人。若是是技術問題， 則要經過技術手段驗證你的觀點；

●會議溝通：

       ★做爲軟件工程師，可能要參加各類名樣的會議、如項目啓動會、需求調研會、需求評審會、項目組立會、項目組臨時會議、項目總結……

　　★對於軟件開發團隊來該如何高效地召開會議是管理者要解決的一個重要問題，如下經過項目組會議和立會說明如何提升會議的效率：

　　　　1）、項目組會議：

　　　　　　▲在召開項目組正式會議前，先要明確如下幾點：

　　　　　　▲會議主題是什麼，根據這個主題肯定需肯定須要哪些人蔘加, 不要邀請無關的人；

　　　　　　▲肯定會議時間，確認參會者都有時間參加；

　　　　　　▲確認會議時間有空閒的會議室；

　　　　　　▲根據會議內容預估會議時長；

　　　　　　▲由誰主持，由誰作會議紀要；

　　　　　　▲會前參會者須要提早作哪些準備；

　　◆當咱們想清楚這些內容後，那咱們的會議基本上就是有準備、有目的的，接下來發送會議通知，

　　◆會議通知通常要提早半天或一天發送給全部參會者並抄送給上級領導，以便你們有充分的準備並安排好本身的工做。若是會前須要你們提早閱讀相關資科，要將資料以附件的形式發給參會者，並要求你們在會前閱讀。在會議通知的正文中，要寫清楚會議的主題、會議時間段、會議地點、會議主持人、會議小祕書 (作會議紀要) 及會議紀律等；

　　◆在召開項目紹會議時，會議主持人和參會者要圍繞會議主題進行討論發言，會議主持人要負責會議紀律，避免在會議中討論與本次主題無關的內容，應把會議時間控制在預估時間內，避免拖延。

　　◆在會議過程當中，參會者須要積極發言提出本身的看法，發言時要注意突出重點，思路清晰，表達簡單且準確，不許出現會上保留意見，會後拒不執行等陽奉陰違的現象；

　　◆在會議中，會議小祕書應該詳細記錄會議過程，包括分配給各個參會者的任務、造成的決議、待確認或待解決的問題等，會議小祕書應該在會後儘快整理出會議紀要，提交會議主持人審覈會議紀要發送給全部參會者，並抄送給主管領導；

　　◆全部參會者必須嚴格執行會議中造成的決議、安排的工做，項目經理要對決議執行狀況和待解決的問題進行跟蹤；

 　　2）、立會：

　　　　◆項目組各類正式或臨時會議能夠起到集中解決問題、造成統一思想的做用，但過多，過於頻繁和冗長的會議確定會影響工做效率，影響整個團隊的戰鬥力。針對這個問題，在軟件工程 Scrum敏捷軟件開發模型。

　　　　◆如下對每日立會作詳細說明，極力推薦同窗們在學習、工做中採用這種溝通方式：

　　　　　　⑴、立會形式：

　　　　　　　　☉每日立會是在天天早上開始工做前，全部項目組成員站着圍成一圈 (因此稱爲立會)，每人利三分鐘左右時間簡述昨天作了什麼工做，遇到什麼問題，今天要作什麼工做，須要什麼支持等。項目經理和項目組成員能夠對其餘成員遇到的問題進行解答，項目經理也能夠在立會上給項目組成員安排工做。

　　　　　　⑵、立會召開要求：

        　　　　　 ☉立會不要變成工做彙報，每日立會期待的發言應該是雙向的，每一個成員都應該積極說出本身的工做狀況和遇到的問題，並期待別人對本身的問題給出建議和反饋；

　　　　　　　　　　☆在立會發言時，每一個成員不能報喜不報憂，要主動說出本身的問題和建議，以便獲得及的幫助和支持；

　　　　　　　　　　☆立會開的時間不宜太長，應該按每人三分鐘左右肯定總時間；

　　　　　　　　　　☆立會中不宜解決細節問題，細節問題只說解決方法和思路，具體解決應該放在會後。例如你在開發中遇到一個技術難題，項目經理能夠安排某個成員在會後幫你起解決，而不應放在會上長時間討論；

　　　　　　　　　　☆在召開立會時，項目經理或會議主持人要把握時間，注意立會紀律，不說無關內容或討過於細節的內容。

　　■立會能夠安排項目組成員輪流主持並作簡單會議紀要，在會後由主持人將每人的工做進度，遇到的問題，解決方法和思路、今日工做等內容，以郵件方式發送給立會全部成員，可抄送給主管領導；

　　　　　　⑶、立會的好處：

　　　　　　　　☉經過每日立會，能夠快速讓項目組成員儘快把心收到工做中，進入工做狀態；

　　　　　　　　☉經過每日立會，可讓項目組成員快速回憶昨天的工做，能很好地規劃今天的工做並分清重點。

　　　　　　　　☉經過每日立會，項目組成員能夠及時交流，瞭解彼此的工做進度及出現的問題，並有利於問題的及時解決；

　　　　　　　　☉經過每日立會及會議紀要，可讓項目經理或部門經理及時瞭解項目進度，項目組成員每日的工做內容等，下降管理成本；

　　　　　　　　☉經過每日立會，項目經理和部門經理能夠及時發現問題，作好風險控制，更好地協調資源。

　　■調資項目組每日立會能夠提升項目組溝通和工做效率，能夠減小項目組會議的頻次，針對不一樣的公司、不一樣的項目、不一樣的公司文化，以及團隊的成熟度不一樣均可能決定團隊然每日立會有所不一樣；因此，各個團隊須要根據本身團隊的特色對每日立會進行改進，以適應本身的團隊。例如，有的團隊在召開每日立會時，能夠請測試工程師和質量工程師等與項目組工做有交集的同事參加；

　　▲總之，只有持續地探索，總結和不斷地小步改進，才能找到適合本團隊的模式；

●郵件溝通：郵件溝通是每一個公司都會使用的溝通方式幾乎每一個公司都有本身的專用郵箱，在一些公司有些員工對郵件溝通的依賴程度甚至已經超越了當面溝通；

   ◆如下是編寫工做郵件須要注意的事項：

      ▲工做郵件時，先要根據發送的內容肯定該郵件是否要抄送給其餘人；

　　▲必須編寫郵件主題，郵件主題應該簡明扼要，能體現郵件的核心內容；

　　▲肯定郵件是否要添加附件。對於工做郵件，儘可能將內容展示在正文中，在公司內部也可攜帶附件，但在正文中須要說明附件中所含文件的內容及用途；

　　▲編寫稱呼，稱呼要符合公司的文化。例如，從事的是教育工做，同事之間習慣"老師" 稱呼，有些公司習慣稱呼 "先生"、 「女士’等。不一樣的公司文化差別比較大， 男女同事之間也存在差別，因此在發郵件以前能夠問一下同事，避免引發尷尬；

　　▲郵件正文應該簡單明瞭，不要長篇大論，若是內容過長，建議當面溝通；

　　▲在郵件模板中應該編寫你的簽名，簽名中能夠包含你所屬的部門，你的職務，公司地址，你的電話等。這樣作可讓收件A方便地知道你的信息，若是須要電話溝通也能夠很方便聯繫你，另外，編寫簽名也能夠表現出咱們很專業，

　◆在團隊中，郵件溝通可使用在如下場合：

      ▲發送各種通知，會議紀要，傳送文檔，資料；

　　▲在當面溝通後使用郵件對溝通結果進行確認. 以防對方忘記；

　　▲對簡單事務進行溝通；

◆在工做中，應該避免就一個問題使用郵件頻繁溝通或爭論，這樣只能讓事情變得更糟糕。另外，對於一些不容易在郵件中說清楚的事情和重要的事情，建議要當面溝通，要知道你發送了郵件不表明對方立刻就能看到，可能他此時並不在電腦前，因此重要的事情在發送了郵件後要電話或當面確認。即使如此，在工做中郵件仍是主要的交流、溝通工具；在工做時間要保證郵箱全天打開。設定時接收 (三分鐘一次) , 避免耽誤事情；

●文檔溝通：

　　◆每個項目組都有適合本身團隊的管理方式。在一些公司爲了不項目風險，還會使用一些文檔做爲溝通的手段，如要求員工天天下班前提交日報，每週提交週報；

　　◆日報不只僅是用來填寫的，更重要的是能提早發現項目進度風險；當有突發事件，如需求變動，人員變更等發生時，能夠及時調整，保證項目進度。

　　◆實際開發過程當中，一些較大項目都擁有數十或數百的成員和模塊，一天的延遲可能會迅速疊加，而且產生各類各樣的難以預料的問題。而這些問題的嚴重性每每超過了團隊能夠恢復的程度，無是小團隊仍是大團隊，日報能夠跟蹤項目，把工做分紅一天或者兩天的量。這樣可以幫助團隊成員更好地理解他們到底須要作些什麼。日報也能夠幫助項目經理提早發現問題，及時調整，更有效控制整個項目進展過程；

  舉個例子：一份完整的工做日報：

★日報將放在項目管理工具上，由小組組長維護。小組內人員天天下班前，填寫工做日報，由組組長彙總，負責交付項目經理；

　　▲下面對日報進行說明：

　　　　To: 接收者；

　　　　From：發送者；

　　　　部門/項目：所屬的項目組名稱；

　　　　日期：填寫日報的日期；

　　　　問題與風險：當日完成任務中遇到的問題和問題可能引起的風險；

　　　　變動：當日是否按照前日製訂的計劃執行，若是不是，則須要詳細說明計劃變動後的內容；

　　　　完成的工做： 當日主要完成的工做任務；

　　　　明日計劃：第二天須要完成的工做任務；

　　　　意見和建議：對項目的意見和建議；

　　　　度量: 對軟件項目進行數據定義，收集以及分析的持續性定量化過程，主要包含預算修訂，極度修訂，得到價值；

　　◆編寫日報的基本步驟：

　　　　一、必須清楚日報在天天下班前提交；

　　　　二、先填寫當日完成的任務、進度狀況；

　　　　三、填寫當日完成任務過程當中遇到的問題及如何解決，有無辦法解決問題，詳細描述；

　　　　四、制訂明日計劃；

　　◆在咱們的階段項目開發過程當中，日報管理以小組爲單位，組長和組員的職責以下：

　　　　★組長的職責：

　　　　　　☉負責督促組員填寫日報；

　　　　　　☉負責對當日計劃執行狀況進行描述；

　　　　　　☉負賁明日的工做計劃安排卜；

　　　　　　☉負責彙總當日已經解決的問題和遺留的問題；

　　　　　　☉負貴將彙總結果提交教員；

　　　　★組員的職責：

　　　　　　☉按時填寫日報；

　　　　　　☉如實填寫日報的各項內容；

　　　　　◇組員天天下班前提交當日日報給組長，組長負責整理當日日報，同時將彙總結果提交給經理。