在產品設計中運用到的軟體工程知識有哪些？

01-07

本人IT專業，大學過軟體工程這門課，可惜沒學到家（現在看來主要是缺少實踐），現在在產品設計的工作中經常與軟體工程的知識交替混淆，想嘗試整理清楚，試圖對自己的產品工作方法論進行優化。
我自己的思路：
1 如何進行產品設計：產品工作的分析設計過程和文檔；
2 如何進行軟體設計開發：軟體工程中軟體的分析設計建模過程和文檔；
3 整理出比較可借鑒的文檔案例參考（最好有對產出文檔的過程解釋）

新年首答，謝邀！

首先，應該把「產品」與「軟體」，「產品工程」與「軟體工程」之間的邏輯關係搞清楚，這樣才不至於混淆。（坊間所說的「產品」大多是指互聯網產品，那麼以下就以互聯網產品為例。）

產品就等於軟體嗎？常常不是。

研發一個互聯網產品，該產品常常（至少）包含了三個主要部分：硬體、軟體與服務，如下圖所示：

產品大筐

與軟體、硬體分別對應的有：軟體工程（包含資料庫）；計算機工程，網路工程，機房工程，其他設備工程等等；最大筐是產品工程。

產品之上，還有沒有更大的概念（筐）呢？有，例如產品家族|組合（product family or portfolio）。

以上只是一種分類法，然而不同公司對到底什麼是「產品」可能有著不同的定義，有的可能不含硬體，有的可能不含服務等等。

可見，一個全面的「產品」概念、範疇常常是大於（或等於）「軟體」的，「產品工程」自然也常常大於「軟體工程」。當然，如果你們開發的「產品」是一個純軟體，那麼此時的「產品」就等於「軟體」，「產品工程」就等於「軟體工程」了。

儘管以上我們分析了，產品的概念常常大於軟體，然而軟體開發或軟體工程仍然是產品研發中的核心工作與主要任務，尤其在互聯網團隊中，大部分人其實還是做的是軟體。所以，許多情況下，產品研發的主體內容是軟體開發，自然離不開軟體工程方法論。

我自己的思路：
1 如何進行產品設計：產品工作的分析設計過程和文檔；
2 如何進行軟體設計開發：軟體工程中軟體的分析設計建模過程和文檔；

根據以上分析，我的建議是不要把產品與軟體分割開了，好像是兩個並行的系統，兩條平行線；公司的研發流程，產品設計搞一套，軟體設計再搞一套。

其實，既然產品包含了軟體，那麼產品的分析、設計與建模過程自然就包含了產品中軟體的分析、設計與建模過程，兩者的開發過程是一個有機、統一的整體，最好合二為一。

現在回到題主關心的問題，產品設計會用到軟體工程中的哪些知識（點）呢？

看下圖，我在「編程之鑽」中歸納出了軟體工程與編程工作的幾個核心領域：

坊間所說的「產品設計」，主要對應於上圖軟體工程內核中的「需求分析」與「設計與編碼」這兩塊。

產品設計，首先要分析市場和用戶的需求，確定滿足、實現哪些需求具有商業價值（business value），然後根據大致明確的有效需求來決定，未來的產品應該長什麼樣，怎麼組成，具有哪些功能，可以提供哪些服務，具有哪些屬性。。。這部分產品設計工作，顯然與軟體工程中的系統需求（或軟體需求）分析直接有關，下面先來說說需求分析。

產品設計與需求分析

過去這二十年，我觀察，主要的軟體工程需求分析實用技術無非這 3 種：

特性（Feature）
用戶故事（User Story）
用例故事（Use Case）

特性在 1990 年代曾經很流行，《微軟的秘密》這本經典名著里有記載。

用戶故事是 XP 之父 Kent Beck 於 1990 年代中期發明的。2001 年以後，隨著「敏捷運動 1.0」的興起逐漸開始熱起來，後來對推廣用戶故事功勞最大的當屬 Scrum 認證與培訓，在國內主要是 2010 後的那幾年。然而，我對用戶故事的整體評價是比較低的。說實話，用戶故事卡片沒多大用處，尤其對於分析和管理複雜的產品需求。

用例（故事）是 Ivar Jacobson 於 1980 年代中期發明的，主要發源地是愛立信，1990 年代後期隨著 UML、UP 的興起而傳入中國，目前採用用例技術的代表性公司有 IBM（RUP）、Oracle（OUM）。我本人研究用例技術也快 20 年了。簡單一句話，分析複雜的產品需求與細節，還得靠用例（外加 UML、SysML 或 BPMN）。

用例有多重要？建議閱讀此題：

FAQ-產品經理對產品細節需要給出到什麼程度，才不會被開發罵？www.zhihu.com

我的建議是：Agile 2 時代的產品設計，最好排除 XP（極限編程）帶來的迷思，勇敢地把 Use Case（用例故事）與 UML 一起用上。

產品需求分析，大致可分為業務需求（business requirements）分析與系統需求（system requirements）分析兩步。

採用 Use Case+UML 進行業務（需求）分析的具體流程，請參考這題：

FAQ-產品的業務分析流程是怎樣的？www.zhihu.com

有空我再把第二部分（系統需求分析）的流程補上。

。。。

做產品10多年，也和很多優秀的產品經理合作過，但會發現計算機相關專業出身的，會有更好的結構化思維，抽象思維，對象思維。

對於產出，UML，包括use case，時序圖等表達方法是非常高效的需求傳遞方式。而我們都知道，UML就是軟體工程思想中的重點。

去年剛好做過一個與軟體工程相關的內容，希望這個可以幫到你。知群傳送門

針對題目簡單說下，

軟體工程知識對產品設計的啟示我覺得有三方面：

1、宏觀的設計

軟體研發講究利用原型來驗證需求，利用增量、迭代來應對變化，持續交付價值。

產品設計應當合理地安排功能需求，既要避免設計不足也要避免過度設計。

至於如何做到合理適度，目前還沒有找到比較好的描述方式。

我覺得只要做到不讓開發團隊覺得需求變更不合理就可以算作適度了。

2、微觀的設計

軟體研發的核心是邏輯而不是編碼。

產品設計的核心也是邏輯而不是界面。

產品設計應做好邏輯的輸出，需求用例、流程圖、數據模型、介面文檔都是傳遞邏輯很好的方式。

另外儘早地引入測試，全員參與設計可以極大程度彌補邏輯設計的缺陷。

3、團隊的組織

組織溝通方式決定系統設計，理想的軟體研發方式是按照功能特性來構建產品與組織團隊的。

這樣的劃分方法可以減少必須的溝通成本，加強各組內人員的參與度，從而提高產出效率與質量。

合理控制需求、理清業務邏輯、優化團隊協作，學習軟體工程做好這三點就夠了。

軟體工程最精華的部分就是【UML】；最容易被忽略的部分是【軟體測試】方法論；底層開發思考方式是【設計模式】。

沒錯，這三個關鍵領域你隨便搜索一下都有一大堆學習資料和專業書籍。

既然業界已經有成熟的理論和最佳實踐，你只需要看書，認真理解就好，沒有其他捷徑，也不需要即興發揮。

補充一下，無論UML算不算軟體工程的概念範疇（大家在評論區的確存在爭議），但是下面這些書籍和資料的確能解決題主的疑惑：

1.如何在產品設計中正確的【記錄和表達需求】；

2.如何養成【面向對象】的抽象思維；

3.如何合理選擇運用【耦合】和【內聚】保留產品的擴展性。

4.如何設計一套嚴謹高效，並具有容錯機制的【用戶任務系統】。（就是所謂閉環）

在真實項目中，幾乎不會有人輸出完整的UML（很費時費力），但是核心業務的描述文檔都會或多或少的帶有UML的影子。

主要是你要理解程序員能幹什麼以及他們普遍怎麼干，你自己會不會不一定有所謂。

然後，你要搞清楚什麼樣的需求對程序員來說才是好的需求。好的需求是明確定義好輸入輸出以及所有的限制，但完全不限定「如何」實現的。比如，「點擊這個地方進入下個屏幕，過程中有1秒淡入淡出效果，且鎖死全部滑鼠和鍵盤輸出。如果讀取失敗，跳出錯誤信息並返回上一屏幕。」這種定義的很細的就會比較討人喜歡。相反，如果你只說「做漂亮」，程序員會想殺了你。切記你不能拒絕討論細節，但同樣也不能陷入細節里。

然後是不能總讓人返工。一般來說，改動頁面元素的顏色，大小，文字，字體等等都不花時間，但改版式和改流程一般都會很花時間。另一方面，如果一開始就能預見版式和流程可能出現的變化，程序開發的時候可以預先做出設計，以後改的時候會省很多事。

為了做到這兩點，你必須盡量搞明白你的產品邏輯。你是給誰設計的？對方用你的產品幹什麼？你產品開發的工期如何？最重要的是什麼？有什麼是絕對不能改變的限制，而有哪些是可能改變的？誰對哪些東西負責，誰有權決定什麼？

都搞清了作為一個產品就算是走上正軌了。

看了下回答，沒有質量高的，鑒於很多牛人是某一方面技術了得，對於工程問題可能一竅不通，很多工程牛人不上知乎，我簡要說一點點。

產品設計和軟體工程不沾邊。

簡單來說，產品設計是個技術活，軟體工程是解決讓一伙人按時保證質量的完成軟體交付的方法。

產品設計屬於技術領域的事情，我也不太懂先不談，本文主要講講軟體工程。

軟體工程作為一個學問提出來是因為軟體規模急劇擴大，以至於必須依靠很多人一起協同工作才能完成。

軟體工程從無到有的一個里程錶的事件是第一次有人提出來分階段開發的模型，也就是說，當第一次有人把軟體開發分為了獨立的階段開始，比如概念階段，設計階段，開發階段和測試階段的時候，軟體工程的作為一個科學就橫空出世了。這是一次從0到1的過程，後面提的各種模型基本就是改良和演化，包活什麼瀑布模型，原型法，各種迭代模型，都只是修修補補錦上添花。

軟體工程歷史上還有一個重要的事件就是cmm軟體能力成熟度的提出，他提出了衡量軟體能力成熟度的標準，通過這套標準，你很容易估算某個團隊（公司）的軟體能力，如果你是處於一個改進中的團隊，你也很容易找到團隊需要努力改進的方向。我建議所有的軟體開發團隊都需要學習cmm的內容，一方面可以清楚自己處於一個什麼樣的水平，另一方面可以找到改進的方向。如果有機會，我可以詳細的解釋一下cmm0到5級的各個原則和建議。

當然軟體工程運用到的工具非常的多，比如首先是各個階段的文檔模板，建模工具，配置管理工具，流程管理工具，代碼check，review工具，度量工具，測試框架，以及各種測試和構建工具等等，不一而足。我看到有些回答中，提到軟體工程，首先就把uml拋出來了，uml只是眾多建模工具的一種，並且uml只適合某一些工程項目。實際上很多傳統項目通過設計文檔，數據流圖，框圖和序列圖就可以完成概要設計，不一定是通過這種面向對象的建模方法，還有更多的項目採用敏捷的迭代開發思路，更不適合使用這麼重型的構建工具。這裡舉這個例子只是為了說明，軟體工程中工具的使用是為了軟體工程的實踐，水無常勢，兵無定型，如何達到最佳實踐，還是需要時時刻刻使用cmm的衡量標準來指導和自省。

軟體工程在實踐中有很多活動組成，有些階段的活動我們稱之為軟體設計流程，有些稱之為軟體開發流程，有些稱之為軟體測試流程，根據業務的不用還有發布流程，部署流程，驗收流程等等。團隊管理者一般來說需要熟悉各個活動對軟體的質量，進度的影響，比如軟體開發流程中，單元測試這個活動如果沒做，對某個模塊它的質量會有多大影響，以及能節省多少開發時間，代碼review呢？這些東西需要你對團隊成員的素質，模塊的劃分，模塊的開發難度等有一個清楚的認識，並且必要的時候可以提供出度量數據來佐證你的判斷從而做出決策。

總而言之，軟體工程是一個工程實踐的方法論，最好的學習方法就是參與各個階段的實踐過程中，並體會各個活動的意義，並按照cmm標準進行自省和改進。

軟體工程里的流程管理可以用在產品設計流程管理里，這些都是通用的。

軟體工程里的需求收集，就相當於產品設計里的用戶研究方法，只不過更偏重業務。

對軟體屬性的度量可以用在給產品設定指標里，比如 usability 這些東西在軟體工程里是放在 software quality 里講的。

軟體工程描述用戶和系統交互使用 use case，類似於產品設計里的 user scenario，不過更偏系統層面。

作為一個產品經理，其實最重要的是要清楚在技術層面可實現什麼，能實現什麼。

只有了解到這個層面，才能將產品設計發揮的淋漓盡致。

web信息結構這本書你去看看