如果你是非技術人員，我想說：

請不要對技術人員說“這個需求很容易實現”

當一個不懂技術的人試圖對軟體開發時間進行評估時，有一個很基本的直觀指標在輔助他們：以體積或者數量為指標的複雜度。

要麼是根據程式碼的行數，要麼是根據參與的人數。

之前聽朋友講到一個真實的段子：公司老闆讓專案經理，統計每位開發工程師的程式碼行數，根據程式碼行數確定每個人的績效。

另外一個常見的例子就是，產品經理問你需要幾天完成這個需求，你說需要1周，那麼一般接下來的對話就是，“給你加2個人，我要2天做完。”

不幸的是，開發的複雜度，唯一有效的推測方法是技術人員根據過去的經驗。而且還不是每次都管用。作為一名十幾年的技術人員，我知道，根據我之前開發過或者領導的相似專案，我可以估計出現在的這些功能特徵各自要多少開發時間。然而，事實情況中，每個專案在開發過程中都遇到意想不到的事情。比如block issue，人員的突發情況，溝通障礙等等。這些問題，有時在專案開始前，根本不會有所預見。

除此之外，非技術人員會將“最快做完功能”來判別技術人員或者技術團隊的能力，因為背後的“可維護性”或者“可擴充套件性”不是一眼看出來的。

如果你是技術人員，我想說：

請不要對非技術人員說“這個需求技術上無法實現”

參見多年前小馬哥說的，在鵝廠，沒有什麼需求技術上是無法實現的。

很多時候，需求的真正限制，只取決於時間或者資源。

何況，需求並沒有限制我們使用某一種技術去實現。

從15年前的Google, 到StackOverFlow，GitHub和各類垂直技術社群，可以說，任何技術問題都能找到直接答案乃至原始碼。

比我們當年在寢室啃MSDN英文文件找一個解決方案，幸福無數倍了。

所以，我們只是覺得現在想到的方案過於複雜，而且會帶來高額的維護成本或者會帶來一系列的副作用，才不願意去解決。

正確的做法，絕不是急於否定需求。而是站在全域性的角度：

1. 分析需求的核心是什麼？將非核心的干擾先排除掉。

2. 將需求進行有效的拆分，嘗試為每一部分找到一個最優解。

3. 根據優先順序，分步驟完成需求，降低副作用。

4. 開啟好奇心，切勿畏懼技術探索的困難

還是一句老話，無論是技術還是非技術人員，解決溝通問題的關鍵，在於看待問題的方式。

相關閱讀

掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes

歡迎轉載，帶上以下二維碼即可