最近一直在和團隊在做一款服務于軟件研發的工具，得以有計劃從理論上和實操上重新思考軟件研發這件事。接下來想從軟件研發本來的樣子，怎樣更好的開發一款軟件兩方面談談。
軟件研發工作本來的樣子
一個完整的軟件研發流程大致包括市場調查、用戶分析、產品定義、交互設計、UI設計、軟件開發、測試這幾個階段。一個完整的軟件開發團隊通常包括項目經理、產品經理、交互設計師、UI設計師、前后端工程師、測試人員這些角色。產品經理會負責市場調查、用戶分析、產品定義，交互設計師和UI設計師分別負責交互設計和UI設計，工程師負責軟件開發，測試人員負責軟件的測試，而項目經理則對項目的質量、成本、工期負責。當然有些成員會身兼數職，比如在敏捷研發中，產品經理通常也扮演了項目經理的角色，而交互設計的工作一般都由產品經理和UI設計師分攤。
在我看來，整個軟件開發流程就像沙漏里的沙一樣，先匯聚一點，再發散出去，最后落地。為什么這么說呢？首先說明匯聚的那一點代表什么，是產品需求文檔。這文檔算是軟件開發流程中的集大成者。產品需求文檔把軟件開發流程切割成前后兩個部分，前一部分的核心內容是研究怎么做，后一部分的核心內容就是做出來。具體來說，就是產品經理、交互設計師和UI設計師通過市場調查，用戶研究，界面設計等工作，研究軟件到底怎么做，輸出調研報告、原型、設計圖等各種文檔成果，然后他們把成果匯集整理成一份產品需求文檔；之后工程師和測試人員的工作就是根據產品需求文檔的指導精神，輸出代碼、用例、缺陷等，就是在把軟件給做出來。要指出的是產品需求文檔只是一個信息傳達介質，形式是很豐富的。
除了漏斗的形式，軟件開發還有不少其他特點。首先是研發流程各階段的關系特點。雖然流程前后各階段有強烈的依賴關系，但后一階段不必等到前一階段完全完成才開始，經常在前一階段進行到一個特定時點時就可以開始了。比如測試不能在還沒有代碼的時候就測試，但可以早早就開始書寫用例，一旦有了可測的模塊便可以進入測試；UI設計不能在還沒有產品原型圖的時候就開始設計，但可以在核心頁面原型出了后就開始確定風格；諸如此類。
其次，軟件開發項目中，對工期的預測和把控是非常困難的工作。這主要由于兩個原因造成。一方面是產品經理在產品定義過程中，基本不可能考慮到所有細節，有些因為疏忽大意而漏掉，有些因為認知不到而忽略，這部分內容如果在開發過程中產生比較大的問題，可能就會影響工期。另外就是產品經理、項目管理人員不一定懂技術，和蓋房子不一樣，代碼不像磚頭那樣直觀可見，這樣的情況下，開發工作不管順利與否，都要等到有了成型可見的界面后，才能得到最有效反饋，這種反饋的滯后很容易導致巨大的返工成本。基于同樣的原因，項目管理人員在計劃工期的時候也常陷入手足無措的境地。
另外，軟件研發的成員，很多時候都是多窗口并行工作，輸入和輸出交錯進行。為了能輸出正確的東西，需要輸入各種不同類型的信息。舉個例子，一名工程師，開發時可能要同時打開編輯器、終端進行代碼編寫，同時也要打開產品需求文檔查看產品開發需求，打開文件管理器調用素材，以及不知道多少個瀏覽器標簽頁來解決編碼中所遇到的問題，此外，還有一個或多個隨身預覽結果的窗口，可能是瀏覽器或模擬器。這就是為什么程序員通常都需要兩臺屏幕，只有這樣才能應付這種錯綜復雜的工作。在這樣的情況下，如果不能合理安排窗口，總是來回切換的話，工作效率很低，而且很容易煩躁。
追求更好的軟件研發是在追求什么
軟件研發的目的很明確，就是開發出質量上層、解決問題的軟件來。和任何項目都一樣，軟件開發也遵從項目三角形的表述，技術、人員等客觀條件一定，項目的質量受成本、范圍、和時間限制。要開發更多的功能，必然影響到開發周期和開發成本；要降低開發成本，必然影響到開發周期和開發范圍；要縮短開發時間也一樣。要開發出高質量的軟件，必須保證這個三角形的閉合。一個有經驗的項目經理，面對項目三角形的時候，通常固定一邊，調整一邊，投資一邊。但我們說這不是更好的軟件研發，更好的軟件研發不是去調整平衡三條邊，而是讓三角形整體變大，即相同的任務，現在花更少的時間和成本。而這里面又分為三塊，完成常規任務的效率更高，面對高難度任務也能順利完成，盡量少的犯錯誤。
如何更高效的完成常規任務，在軟件研發中，工作時間是可以分為兩部分的，一部分用來獨自工作，另一部分用來溝通。要想提高獨自工作的效率，就兩點，自動化可自動化的流程，復用可復用的組建。復用可復用的組建就要求每個成員在工作中注意積累和總結，因為現在很多項目都不是一錘子買賣，而是小步快跑的方式，所以這樣的積累是很有價值，而且價值越來越大的。自動化可自動化的流程，就要求團隊善于運用工具，有了工具，切圖標志、數據分析、代碼編譯、版本部署等工作都可以節約特別多時間。
提升溝通效率稍微復雜一點，這要求團隊建立順暢的信息傳輸和反饋渠道和機制，來保證團隊信息同步，需求傳達準確，反饋即時有效。在我心中，最理想的軟件研發是由一個人完成的：你獲得了一個點子，通過問卷、訪談等方法確定了這個點子可行；接著你把看得見的和看不見的問題都想的清楚通徹了，并根據自己理解定義出了軟件，還畫出了產品設計圖；然后你又自己把軟件開發了出來，自己測試了一下，覺得沒問題就上線發布了。在這個過程中，你對該產品的思考和認知一脈相承，不需要和任何人去面對面溝通、不需要花時間制作任何文檔，也不需要考慮標注切圖的問題，因為這一切都是你的，不做這些也不會影響你下一步的進行。然而這樣的通才并不常見，況且實在趕時間的話，就算一個人什么都會，也做不過來。所以我們還得有個團隊。從這個方面來想，一個人工作不涉及到的任務分配、談話、郵件、會議、各式文檔等都是因溝通而存在的。
能提高溝通效率的方式很多，仁者見仁智者見智，但這里我想給你介紹幾點工作中覺得特別重要又容易忽視的幾點。首先，要明確計劃，雖然軟件開發中可能遇到各種突發情況，甚至戰略方向都會改變，但制定計劃依然是必要的，有一份詳盡的計劃，能按照計劃實行當然最好，不能按照計劃實行，也能讓團隊成員對我們在做什么、要去哪、為什么變化了有個譜，可以更容易理解最新的信息，更準確解讀接收的需求。其次，要根據成員的特點優化關鍵文檔的展現形式，拿產品需求文檔舉例，產品經理可以采取各種不同的工具和敘述方式來制作產品需求文檔，說不上孰好孰壞，根據團隊成員的工作習慣和工作場景，選擇讓工作更舒服的方式最好。再次，讓變更有跡可循，任何文檔，當變更了，都需要記下何時何地何人做了何等變更，為什么；人和新需求，要記錄何時何地何人提出了這等需求，為什么；任何回憶，也要記錄何時何地何人討論的問題和達成的成果。只有這樣，思路才能是完整的，在之后做類似決策時才是有據可考的。最后，要即時反饋即時糾錯，現在的軟件開發已經在往這個方向發展了，所說的敏捷開發就有此意，但有時候依然不夠，如果可能的話，嘗試周穩定版本甚至日穩定版本都是有幫助的，畢竟問題總是越早發現，糾錯成本越小。
如何順利完成高難度任務，也是個見仁見智的問題。這里就簡單的介紹一下我覺得靠譜的方法。一是工作的形式上，在面對困難任務時，可以改變各顧各的形式，采用結對編程，即兩個人用一臺電腦編程，在思考和交流中，更容易碰撞出靈感；如果兩個人都不行，那可以采用特種部隊的方法，這個特種部隊可以由不同類型的成員組成，從不同的思路去思考同一個問題，這樣的小組專門在特定的時間負責攻克特定的任務，完成任務就可以就地解散。另一種是建立團隊資源庫，各種各樣的問題，在哪里、找誰有可能得到答案，都可以收集起來，這樣遇到問題時不至于手足無措。
怎樣避免少犯錯誤呢？錯誤可分為看得見的錯誤和看不見的錯誤。看得見的錯誤當然有些因為馬虎，有些因為確實難解決，前一種坑可以通過評審盡量避免、后一種坑則和前面說的攻克高難度任務差不多。看不見的錯誤主要因為經驗不足，而經驗不足就要努力積累經驗。可以建立一個公共的的知識庫，積累一整套認知論和方法論，然后再通過不斷的的總結和復盤去迭代。更重要的是，這個知識庫要使用優質的文檔管理軟件來建立，至少是方便搜索查找的，如果經驗積累了卻無法提取，也是徒勞。此外，即時收集反饋和糾錯也很重要，不僅減少錯誤，也減少已犯的錯誤造成的損失。
結語
以上談了對軟件開發的一些理解，隨著互聯網的發展，這個行業已經發展得挺健全了，我所說的這些認識和方法也不是我這一家的洞察和思考，說到底，能不能開發出更高質量的軟件，還得看能不能結合團隊特征調節流程、找好工具、認真實行，畢竟一個幾十人的團隊就已經算得上一個復雜系統，和復雜系統打交道從來就不容易。
