技術困難的非技術性解決方案

   

    最近在看一本關於軟體測試的書時，其中作者提到並非所有的缺陷都要修複，即使修複一個缺陷也未必要去修改代碼，通過在使用者手冊中加以注釋，或者為使用者提供相應的特殊培訓，都可以看做是對某種缺陷的修複方案。
    由此想到，在項目的開發過程中，很多的問題或者困難都可以採用類似的思路，即對技術問題用非技術性的思路去解決。比如在很多不太規範的Team Dev裡，項目的合約中常常規定的一些需求，在技術上要麼是根本不可能實現的，要麼就是實現起來代價太高，根本不可能在期望的時間點完成。這個時候如果開發人員硬著頭皮去尋找技術解決方案，也許是得不償失，既浪費了寶貴的開發時間，又延誤了其他基本需求的解決，同時還有可能帶來管理層對其能力和態度的疑慮。
    如果換個思路，先構思一個可行的替代方案，然後試試與團隊中籤合約的人進行一下溝通，既讓其理解原方案的技術困難，又給其提供一個替代方案供其與終端使用者協商。當然，商務人員未必真的讓使用者知曉方案的實際修改情況，多一事總不如少一事吧，但是他們在知道了困難和替代方案後，就會有相應的心裡準備，同時也會增加對開發人員的理解，至於使用者那邊，其實對他們來說未必是最大的困難:)，這樣一來，也許能獲得皆大歡喜的結果呢？