《軟體設計師要思考那些問題》

     我現在看到這個話題，自己也感到吃驚。我也不知道當時我在制定編寫計劃的時候是如何考慮的。這個話題實在是太大了，如果要寫好的話，不亞於寫個設計師工作大全了。但是我是一個很機械的人，定了就寫吧。說真的，做了幾十年的軟體設計我從來沒有定下心來考慮這個話題，那今天就試著寫寫吧。各位讀者可以先不看我寫的東西，自己試著考慮這些問題。看看兩者有什麼相同和不同之處，這樣大家可能對這個問題有更全面的瞭解。

這裡的軟體設計師是指軟體公司以及企業單位從事軟體開發的IT人員。他們所要開發的軟體是指外部使用者和企業內部使用者兩個方面。下面將不再特別區分這兩種情況。

   這段時間我一直在觀察我周圍的各種各樣的軟體設計師，也和他們進行了各種溝通，也談過項目的總體構架，也談過功能的具體實現。我不斷地在觀察他們所說所做的背後的原因，讓我有更多的感慨。他們大都關注具體問題的如何解決，根本不注意問題的解決方案，不去注意自己的方法和別人的方法的不同之處，就事論事。就像很多中學生只關心試題的答案一樣，不去深入掌握解決問題的方法，結果就造成做過的題會做，沒做過的題不會做的狀況，這樣的學生如何能夠獲得穩定的好成績呀。

感慨這麼多，還是回到本次話題吧。我還是想換個思路，這次不是把軟體設計師要思考的問題都羅列出來，而是要把如何寫好這個話題的思路展示給大家，這個思路就一種解決問題的方法。掌握了這個方法我們就可以將這個話題寫得更好。

1、 軟體設計師要思考那些問題的範圍

軟體設計師要思考那些問題首先要確定思考的範圍。這個思考範圍是要對設計師是有用的，有重要作用的。那些無關緊要的內容，可以捨棄，我們必須突出重點。

從這個角度出發，我認為從軟體製作周期內每個環節來討論軟體設計要思考的問題是比較合理和科學的。這裡我強調了軟體製作、周期、環節這三個重要的要點。很多人在考慮軟體設計師要考慮問題時，立即會想到採用什麼技術，某個功能怎麼能具體實現這樣的具體問題。如果，你要問他為啥這樣想，他就會反問拿到這些問題不重要嗎？不需要考慮嗎？如果你回答不重要，他立即會講出很多重要的理由，你回答重要，缺附和了他那種淩亂和具體的思維方式。

一個好的軟體設計師應該閉上眼睛就能把他要思考的問題一個不漏的講出來。這就說明了他掌握了那種職業的方法。如果他講不出來，或者今天這樣講或明天那樣講說明他根本沒有對這個問題有系統性的認知。對於這種軟體設計師，你都可以閉上眼睛就可以知道他是如何走一步看一步的進行自己的設計的。

1） 軟體製作

從軟體製作這個方面來思考，表明了軟體設計師的職業所然，是有明顯的職業針對性的。如果我們從工資收入、人際關係等方面來思考問題，那就不僅僅是軟體設計師了，其他的諸如專案經理、管理者、文秘等等都可能思考這些問題的。

2） 周期

軟體製作是一個過程，也可以看作一個周期（相對於下一個項目）。軟體設計師是這個過程的參與者，是全過程的參與者。因此，我們要站在軟體製作的整個周期來思考些問題。而不是在這個過程中某一點來思考一些問題。很多設計師並沒有軟體製作的周期意識，只有別人問到他的時候，他才說這個他知道。其實他真的不知道。因為知道了，別人也不會問他了，知道了，也不會把思考點只集中諸如需求分析、方案設計上面了。

3） 環節

軟體製作是一個周期，而且它是一個可以劃分的。因此，軟體製作就可以有各種各樣的環節。無論這個環節怎麼去劃分，但是這些環節一定包含了軟體製作的全過程。所以，環節和全部環節是我們必須要表達的。很多軟體設計師並不在意軟體製作的環節和全部的環節。還是那種自然主義思想，做到那邊算那邊。

我把軟體製作分成10個環節：   1、需求 2、需求分析、3、軟體構架設計 4、軟體詳細設計及文檔 5、開發階段 6、測試階段 7、上線階段 8、投產運行 9、使用者反饋、10、日常維護。

面對這些環節，程式員都是有很多很多思考問題的。

2、 如何編寫思考的問題

   當我們明確了程式員思考的範圍之後，我們就可以在這個範圍內進行進一步的思考。比如我們面對需求這個環節，我們要去如何思考，我們面對軟體設詳細設計，我們要去如何思考。當我們掌握了這種思考方法後，我們就可以對其他環節進行更加有效思考了。

   一般的軟體設計師並不關心思考方法，面對需求可能直觀地想到了需求書、想到了功能；面對軟體設計可能立即想到語言選擇、採用什麼技術、基本的演算法。如果你去問他為啥要這樣想，他又會同樣的找出他說所講的重要性。這種隨想隨說的思維方式和需要極強的邏輯性的軟體設計師的職業特點是完全不符合的。

   對於一個問題的思考每個人有每個思考方法，但是，這並不意味每種思考方法都是對的。判斷對錯的一個標準，就是思考的結果能夠更好更快更科學地解決問題。這個“更”一般人都是和原來的自己比，也就是說通過思考自己比原來想的更好了。這樣的“更”含金量價值不高。這個“更”應該和你周圍的同伴相比，應該和你認為的高手相比。這樣思考的結果才更有說服力。對於軟體設計師來說這種思考的結果是必須的，不採用最好的思考結果，就不可能產生最好的軟體。

   對於軟體設計師如何在某個環節的思考方法問題，我認為首先要明確這個環節的思考得目的，也就是說搞清楚為啥在這個環節要思考，不思考行嗎？第二步把這個環節的有關思考的對象羅列出來，對象的顆粒度越細，思考的問題就越深入。第三步將思考的對象之間的關係以及程度羅列出來，第四步對這些對象和關係相互之間進行組合思考，第五步對每個思考加入自己的經驗和其他人經驗進行有效地驗證，或進行有效推論。第六步，對所有思考進行歸納得出思考的結論。

   其中第一步是很重要的，它是你思考的基礎和範圍，如果你的對象在這個範圍內收集的比較全，這樣你的思考的全面性就得到了保證。在全面性基礎上，我們才可以去考慮內容的合理性。

我們以需求這個環節為例，看看我們所要思考的問題。

首先我們要把需求環節思考的目標給明確起來：那就是軟體設計師要對需求本身和需求環境有一個充分的瞭解，尤其是對需求的瞭解渠道和瞭解結果有一個充分瞭解了。只有對需求這個環節充分瞭解之後，我們才可能進入需求分析環節。否則，到了需求分析環節，你可能還要回到需求這個環節再次思考。

第二，將所有思考對象儘可能的羅列出來。例如，需求提出者、本人、其他需要掌握需求者、需求書、需求環境、時間要求。這些大類的對象還可以細分成很多小的對象，對象的顆粒度越細，思考的問題就越深入。例如，需求提出者的屬性，提出者是單位，還是個人，提出者所在的企業、提出者所在的行業等。

第三、將對象之間的關係和關係程度進行羅列。例如，將需求書與本人之間對象的擷取、閱讀、理解、掌握羅列出來，對這些關係程度如：擷取：沒有問題、困難、暫時無法擷取；閱讀：完全閱讀、不能全部閱讀、無法閱讀；理解：完全理解、部分理解、不理解；掌握：完全掌握、不完全掌握、不掌握等也羅列起來。

第四、第五、第六因篇幅問題我就不在舉例了。 

我就需求環節可以舉出數以百計的問題來，我在這裡隨意地提出幾個思考問題，並把思考這些問題的目的也進行了說明。

1、 提出項目的使用者是什麼企業事業單位？屬於何種行業？其在行業中的地位如何？

    問題的目的是要明確項目的分類，評估項目建成後項目的行業地位。強調行業是從行業的角度上來看待這個項目，以便這個項目可以歸屬到某個行業項目之中。或從某個行業項目之中擷取相關需求經驗。

2、 提出需求的使用者是企業中的什麼部門，是屬於企業哪一類部門，生產業務部門？管理部門？辦公部門？

    問題的目的是明確項目的應用分類，是屬於業務系統、MIS系統、辦公系統。通過分類可以利用不同類型系統的規律對項目進行分析。

3、提出需求是軟體公司自身嗎？軟體公司提出開發軟體的原型需求的企業和部門是什嗎？

問題的目的是瞭解需求來源的渠道，如果是自身軟體軟體，渠道相對容易暢通，如果其他企業則要考慮渠道是否暢通問題。

 

4、使用者提出需求的原因是什嗎？是因為企業產品業務發展的要求？是企業內部管理的要求？還是外部監管要求？是企業上層業務的要求，還是企業下級部門的要求？

   其問題的目的是進一步瞭解需求的來源、瞭解需求的重要程度和緊迫程度，這對下面的各個環節都是十分重要的。

5、提出需求要解決什麼問題？業務的流程的電腦化？產品生產的電腦化，減輕原來的手工操作、提高工作效率？滿足上下級管理的要求？實現管理手段的資訊化？原來的系統地升級改造？實現軟體的商品化？

   其問題的目的是進一步對項目進行分類，通過分類歸屬，可以按照所屬歸類進行不同的處理和分析。

6、需求是提出急迫嗎？項目要求完成時間急迫嗎？

   其問題的目的是瞭解項目的緊迫性程度，不同的時間要求，可能決定不同的設計方案。

7、需求有完整的需求說明書嗎？如果是外部強制要求，外部有相關檔案和需求說明嗎？

   其問題的目的是瞭解項目需求書的是否存在，是否完整，相關外部需求能否擷取。如果存在問題，則要考慮如何去解決這些問題。

8、當需求不完整的時候，使用者能指定需求解釋人員嗎？

   其問題的目的是能否建立面對面的溝通渠道，這個渠道能否滿足對需求瞭解的要求。實踐中指定的解釋人員可能也不是能夠解釋通需求的。

9、根據以往經驗初步判斷，這個項目或軟體是屬於大項目？中項目？小項目？根據以往經驗和開發隊伍初步判斷這個項目或軟體是否有技術痛點、這個痛點能否克服、大概需要多長時間能夠完成。

   其目的對項目進行分類利用原有的開發經驗對其作出初步的判斷。

10、與之交流的使用者屬於什麼類型？外向？內向？需求是否熟悉？表達是否清晰？是否有充足的時間？當無法與之交流的時候，是否可以請求換人或增加需求人員？

   其問題是為項目的需求溝通做好各種準備工作，因為不同溝通對象會產生不同的溝通效果和效率，因此，要為有效溝通進行充分的準備。

 

我可能在本文中過分強調軟體設計師的思考方式了，這也是我感到無奈的地方。本文的題目可以改成“軟體設計師應該如何思考問題”。軟體設計師可以將數以百計的思考對象和數以十計的對象關係進行排列組合，那是怎麼樣的無窮無盡的思考話題呀。要思考的問題可以無窮無盡，而思考問題的方法卻十分有限，我們真的可能要關注方法了，先方法後問題，也許我們可能收穫更多。如果讀者有興趣按照軟體製作十個環節，逐一地去思考每個環節中的目的、對象、關係、程度、組合、經驗、結果，你就會發現軟體設計的職業的思考範圍之廣之深之無限。可以這樣說軟體設計師的之間的差距首先是思考方式上的差距，然後是思考範圍上的差距和思考內容上的差距。

下篇：《設計目標是項目之魂，總體設計是項目之魄》