從溝通反饋到高效能研發

時間 2019-12-07

標籤溝通反饋高效能研發欄目快樂工作简体版

原文原文鏈接

企業最根本的的競爭優點既不是來自資本實力、發展戰略，也不是來自技術，而是來自團隊協做，由於團隊協做能力是很是強大並且彌足珍貴的。 -- 《團隊協做的五大障礙》程序員

前幾天逛書店翻的一本書，這是開篇的第一句話。聯想了最近思考的一些東西
數據庫

團隊協做可以高效、高質量的前提是什麼？

就是信息同步，是溝通反饋。由於溝通反饋是接收指令、執行並覆命的過程。後端

關於溝通反饋想從兩個方面聊一聊這個高效溝通的話題：
一、平常溝通，好比面對面、IM或郵件；
二、軟件開發流程中的溝通反饋；服務器

平常溝通

通過思考才發問

咱們常常可以在開源技術羣裏見到相似這樣的場景，某個同窗在研究新技術，在安裝或者使用的時候遇到報錯了，假如好的軟件，報錯信息通常都很詳細，指出報錯的緣由和代碼位置，甚至有的軟件解決方法都會有提示，只不過有的報錯是英文，可是仍然會有人稍微遇到問題就複製報錯信息發到羣裏，這樣通常是沒人願意理會的。
前後端分離

拋出問題，也請交代問題的背景

每一個人並非專注負責某一項事情的，當咱們遇到問題不得不向另一個同事求助的時候，能夠嘗試簡單的描述問題、發生時間、發生通過、相關數據。只說結果，若是是別人直接甩問題給咱們，咱們也會一頭霧水，推己及人，思考問題能夠換位想下。
若是是先後端分離的項目或者App，假如方便的，最好能肯定下是客戶端問題仍是接口問題，若是是接口問題，能夠帶上相關連接參數或者響應數據，這對排查來講，再好不過。
交代問題背景的同時，都至關於本身捋了一遍邏輯，說不定就有了新的解決思路。數據庫設計

如何發出問題

工做時間，每一個人的時間都是寶貴的，那就切中要害，簡單扼要：工具

去掉無用的口語，好比在嗎？在忙嗎？如今有沒有時間？有事說事，對方閒下來的時候天然會回覆。
先發出文字描述，再發出佐證你問題的相關圖片。咱們先發了圖片，對方不知道問題和背景，對方也不太會一直盯着聊天窗口等着打字，而後去作別的事，等咱們發了文字，再回來看，這就至關於打斷對方至少兩次。
注意語氣，對於大多數同級的同事，沒有任何人有責任或必須幫你作什麼，因此，咱們是尋求幫助，不是發號施令。對方可以伸出援手最好，無論主觀仍是客觀緣由若是不能，也應該給予確定和感謝。
問題都有優先級，適當的時候拋出適當的問題，可是假若有依賴項或者阻礙開發的問題，應該第一時間的提出來反饋給上級或同事，本身也能合理安排時間。

如何面對他人的求助

敢於承擔，分內的事，確定要主動站出來處理。份外的事兒，若是本身能解決的或順手的事能作的就舉手之勞，若是不能也能夠說下具體緣由或者給對方一個指引，「好比，建議你找XXX問下」。團隊信任千萬不能說「不關我事兒」之類。
勇於說不，對於明顯不靠譜的需求或者問題，勇於說不，就事論事，憑感受每每是不許的，對於有風險的事情，未雨綢繆，擺出本身能作的範圍，講出存在的風險，至於投入和產出的權衡和風險控制交給對方，並說在咱們本身角度上專業的考慮。作能作的，不能作的有風險的也事先說明。

還有一句話是：把不靠譜或不肯定的事情延遲着手，說不定事情就變了或者本身就沒了。學習

大事小事給一個時間預估，無論是交代的事情仍是作開發，對事情完成時間有一個預估，或者根據事情優先級安排，給出一個deadline，讓對方內心也有底。對於一個靠譜的人：凡事有交代，件件有着落，事事有迴音_。_是在職場的座右銘。
切忌承諾過滿，答應作一件事，也給了時間，若是對風險評估不許，也會出現沒有按時交付或者到點完成，因此在前邊承諾deadline和完成狀況的時候都應該合理的留有餘地，由於事情每每有不可控因素。不然：一、沒有按時交付，失去了信任；二、必須按時交付，只有加班。到頭來都是本身消化了風險帶來的後果。

及時主動反饋，溝通閉環

有階段性進展、中間遇到問題、事情作完，對方都有知情權，而且咱們也有義務主動告知對方，若是老是領導追問事情怎麼樣了，可能溝通或工做方式哪裏出了問題。
溝通閉環，特別是領導交代的事情，若是不了了之，只能讓領導以爲咱們是一個靠不住的人，之後怎麼還會安排事情，可能距離危機也不遠了。切勿掉進反饋黑洞裏。測試

開發流程中的溝通

寫文檔不是浪費時間，面向文檔開發也不是可恥

在極客時間《10倍程序員工做法》中，做者屢次強調「以終爲始」的原則和一個概念：DoD（Definition of Done，完成的定義），無論平常溝通，仍是軟件開發，作事情先要知道作什麼，作的事情是什麼樣，達到什麼數據的的事情是咱們想要的，先定義好事情自己，才能讓咱們作好充分的準備，不作無用功、少返工，下降不肯定風險。把肯定的東西儘可能在開始前肯定好、量化好，造成文檔落實下來，這都是團隊各個角色共同參考的惟一的標準。
在標準的軟件開發模式中，前期需求蒐集、需求分析、軟件開發設計、數據庫設計等等都是文檔先行，定義好各類驗收標準才動手寫代碼，而編碼只是軟件開發很小的一部分。只不過在如今不少時候，無形之中都適應了「邊作邊改」的開發模式。無論咱們身處哪一個角色，產品、設計、開發、測試，都應該瞭解軟件開發的完整流程，有一個總體觀、大局觀和團隊感，咱們是分工不一樣可是爲了一個目標作同一件事。軟件開發是一個系統工程。
編碼

我並沒有意誇大開發一個產品的複雜度，可是做爲一個跨部門、多人蔘與的項目，確定要 有依據，有定義和有資料可查、可追溯。聊天記錄並不能成爲嚴格的正式的事物標準。

「一切版本化」，不只僅是代碼、服務器配置、還包括設計稿、各類文檔。
這不只是之後要作什麼、怎麼作的問題，仍是之前作了什麼、誰作的、怎麼作的問題。
不只方便着手作事情的人，也方便人員流動和新人接受學習和重構梳理。
作好文檔，百利無一害，有人會以爲浪費時間，可是欠的早晚要還的，有的還的方式是返工，是重作，是質量和體驗欠缺。
寫文檔也是整理思路的過程，若是本身都捋不清又如何讓別人能明白呢

最輕最高效的溝通方式仍是面對面

爲何明明咱們就幾步遠的距離，還要浪費時間在打字和等待中？特別是若是很緊急的狀況下，爲何不打電話和去座位上找他？IM工具只是工具，不是每一個人都必須分分秒秒都打開對話框等你發消息。
固然，簡單的問題，IM沒問題，只是針對那些幾句話仍然解釋不清楚的狀況。

全體會議要謹慎，若是能夠你們站着說

最重的溝通方式就是開會，咱們都體驗過開會，特別是干係人所有拉在一塊兒。若是不能保證會議提早在議題和內容和與會人思想上有準備的狀況下，開會極可能成爲幾我的的秀場，而剩下的人昏昏欲睡。
國外有的團隊提倡站會，拉近距離，不會像坐着太舒服，發言拖沓而變成茶話會。
因此，開會要謹慎，若是不得不開，得保證開會可以有所準備，儘可能造成決議，讓會議有所產出，若是不能，先面對面討論好。
更多能夠參考