為什麼沒有什麼是顯而易見的:軟件開發中的溝通藝術

已發表: 2020-10-22

我們都必須在日常生活中相互交流。 在私人生活中,在學校,在工作中。 無處不在,無​​時無刻不在。 有些人比其他人有更好的溝通技巧,但歸根結底,我們都會時不時地犯錯。

雖然一些錯誤的溝通對我們的生活影響不大(如果你點了不含酒精的啤酒,這不是世界末日;))有些可能會產生更大的後果(指出要拔錯的牙齒)。 軟件開發中的溝通誤解是後者,可能會產生財務影響。

我們所有人最常見的問題之一就是假設另一個人可以讀懂我們的想法。 有時我們都為此感到內疚。 你有沒有聽過這句話:“這很明顯!”? 我敢打賭你有。

我不相信客觀的顯而易見性。 我們認為有些事情對每個人來說都是顯而易見的,但對一個人來說清楚的事情,對其他人來說可能並不那麼明顯。 為了在軟件開發中實現有效的溝通,讓我們停止相信讀心術,只說我們的想法。

為什麼說起來容易做起來難? 我們先來分析一下通信過程。

溝通要素

50 多年前,羅曼·雅各布森(Roman Jakobson)提出了一種溝通模型,該模型對於通過相互理解來分析問題非常有用。 看一下圖表:

很明顯,通信不僅僅是發送者和接收者之間的消息。 上下文、渠道和代碼會影響消息,並可以改變單詞的接收。 即使其中兩個因素存在而缺少一個因素,也會出現問題。

由於我們具體討論的是軟件開發中的通信,因此如果我們錯過了上述任何因素,我們應該分析在項目細化會議期間會發生什麼。 換句話說,讓我們仔細看看溝通在項目管理中的重要性。

始終提供上下文

上下文提供了對任何問題的大局的解釋。 人們可能看不到將產品的目標群體告訴後端開發人員的意義。 似乎開發團隊只需要知道他們需要什麼,而不是背後的業務原因。 沒有東西會離事實很遠。

軟件開發中的通信不僅僅是功能需求。 您可以為團隊提供的上下文越多越好。 正確介紹產品概念可能會很耗時,而且可能看起來浪費時間和金錢,但從長遠來看,它有助於避免糟糕的技術實施。

如果團隊知道產品的長期計劃是什麼,他們可以提供更合適的技術解決方案。 即使您不想在食品配送移動應用的第一個版本中實施促銷代碼,也最好讓軟件程序員知道它會在下一個版本中推出。

為確保您提供了完整的背景信息,請問問自己是否已經分享了您所擁有的所有信息。 如果你發現自己在想‘這對開發人員來說並不重要,他們不需要知道這一點,至少問問團隊這些信息是否可以幫助他們。 您可能會對其他人認為至關重要的因素感到驚訝。

明智地使用渠道

渠道是項目管理中經常被遺忘的溝通因素。 如今,當開發團隊經常在不同國家工作時,當後端在印度(現在,多達 85% 的美國公司將大部分業務外包給印度)時,前端開發在波蘭,產品負責人在美國,我們都使用許多不同的工具進行交流。

選擇正確的渠道並有效地使用它可能會產生影響。 電話會議、電子郵件和聊天很棒,可以讓我們保持聯繫。 但它們也為信息被誤解創造了新的方式。

我們不能假裝在線聊天與在同一個房間與團隊進行對話是一樣的。 我們能做的就是牢記遠程通信的局限性,並努力克服它們。

有效遠程通信的技巧

  1. 通過電話會議進行對話時打開相機。 視情況而定,非語言交流可佔信息的 50% 以上。 例如,如果你在別人能看到你的時候諷刺你,那就更容易被抓住。 您還可以查看對話者的實時反應。 您可以注意到其他人是否對您的話感到困惑。
  2. 在聊天中使用單獨的房間對對話進行分類。 當項目複雜時,軟件開發中的溝通也趨於復雜,新的討論話題不斷出現。 分開的房間可以讓您保持信息井井有條,並以更少的麻煩到達適當的收件人。
  3. 在通過聊天寫作時標記消息的收件人。 跟踪每個對話並不容易。 確保通知您正在寫信的人符合您的最大利益。
  4. 在書面對話中,適當時使用表情符號。 不要用太多但要讓聽眾知道你在開玩笑說周五下午的部署

通信代碼審查

在工作之初,您需要建立一個通用代碼以同樣的方式理解主要術語。 即使是“顯而易見的”。 例如,我們有一個要求:“作為用戶,我只能在早上下訂單,以便可以在同一天發送所選擇的產品”。 看起來很清楚,不是嗎?

嗯……那麼早上在這個功能中到底意味著什麼? 早上什麼時候開始? 當太陽升起或在一個確切的時間,即早上 7 點? 如果在上午 7 點,您想到的是哪個時區?

項目管理中的溝通,尤其是 IT 中的溝通,需要非常清晰。 沒有猜測的地方。 在我們的案例中,它可能會導致無法在 10 點之前訂購產品(當主要開發人員起床時,這對他來說就是早上的意義),並且應用程序所有者因缺乏早起的訂單而蒙受損失。

常用通信代碼的最佳實踐

  1. 使用常用術語創建詞彙表。 它在項目開始時很有幫助,對於新加入者了解開發團隊所說的語言非常有用。
  2. 詢問接收者他們如何理解要求或短語也很好。 我不是在談論無用的:“一切都清楚了嗎?”。 請明確點。 詢問詳情。 確保你被理解。 進行通信代碼審查。

    讓我們再看一下我們的例子:為了對“早上”這個詞達成一個共同的理解,請使用它的人重新表述它。
  3. 經驗法則是,在軟件開發中重複溝通比為猜謎遊戲留出空間要好。

專業知識問題

除了上面提到的項目管理中的所有溝通方法之外,在討論軟件需求時,還有一件更重要的事情需要牢記。 無論是初創公司還是企業產品,在大多數情況下,在客戶進入軟件公司之前,他們都會花費大量時間考慮他們的產品。 花在這上面的時間越多,他們在這個話題上的經驗就越豐富。

當您是專家時,很容易忘記並非您周圍的每個人都擁有與您相同的領域知識。 這意味著對您來說顯而易見的問題對於您正在與之交談的開發團隊來說並不那麼清楚。

如何避免專業知識問題

  1. 退後一步,回到產品之旅的起點,向開發團隊解釋您所做的所有決定。 當他們了解這一切是如何開始時,他們會找到更好的技術解決方案,甚至會填補您思維方式的空白。
  2. 允許團隊根據需要提出盡可能多的問題。 諺語說沒有愚蠢的問題一點也不誇張。

軟件工程團隊如何有效溝通

盡可能清楚! 沒有溝通不暢的地方,因為後果可能是痛苦的。 請記住,沒有客觀的顯而易見性,最好重複幾次,而不是錯過重要信息。

研討會圖標

將您的想法變成出色的數字產品

我們一起工作吧

請記住所有三個溝通因素,並仔細檢查您的信息是否按您的意圖理解。 隨著時間的推移,軟件開發中的溝通對你來說會更容易,正確地解釋需求將不再是問題。

如果您正在尋找一個在應用程序開發和通信方面都堪稱專家的軟件公司,那就別無所求!

只需與我們的 Miquido 專家交談,將您的想法變為現實!