
0人評分過此書
大約有90%的產品開發案是失敗的,其中30%並沒有開發出任何產品,其他的雖然有產品問世,但人們不喜歡,或從來不使用;即便使用了,也是毛病一大堆。
做好需求分析,是新產品成功的關鍵
本書是暢銷書《你想通了嗎?》兩位作者又一傑作。他們總結與各大小企業合作60餘年的經驗,來探討新產品開發過程中最困難的部分——如何設計出「高品質」的產品或系統。在本書裡,「品質」的定義是:「符合客戶的需求」。
為什麼有那麼多新產品的專案會胎死腹中?為什麼新東西要符合客戶的需求這麼難?由此看來,客戶需求、品質、與客戶溝通、設計等等環節,都大有學問。而且,可能客戶「自己都說不清楚自己要什麼」。
因此,要做出客戶想要的產品或系統,不僅需要專案管理的技巧,還要先做好「客戶需求分析」,這就是本書的主題,內容包括:需求要件(requirements)、減少語意曖昧(ambiguity)、使用者參與、激發概念的會議、專案命名、調和衝突、客戶要什麼(功能、特性、限制、偏好、期望)、技術審查、測試使用者滿意度、黑箱測試等等。還有許多實際案例,以及豐富的心得分享與建議。
本書中提到的技巧,曾經成功運用於許多產品或系統──包括電腦硬體、電腦軟體、汽車、家具、建築、消費性產品、書籍、影片、訓練課程等等。
本書對於新產品專案的所有利害關係人——團隊成員、客戶、使用者、還有必須綜觀全局掌控進度的經理人,都大有幫助。本書可以幫助你有效帶領團隊,讓新產品專案邁向成功!
做好需求分析,是新產品成功的關鍵
本書是暢銷書《你想通了嗎?》兩位作者又一傑作。他們總結與各大小企業合作60餘年的經驗,來探討新產品開發過程中最困難的部分——如何設計出「高品質」的產品或系統。在本書裡,「品質」的定義是:「符合客戶的需求」。
為什麼有那麼多新產品的專案會胎死腹中?為什麼新東西要符合客戶的需求這麼難?由此看來,客戶需求、品質、與客戶溝通、設計等等環節,都大有學問。而且,可能客戶「自己都說不清楚自己要什麼」。
因此,要做出客戶想要的產品或系統,不僅需要專案管理的技巧,還要先做好「客戶需求分析」,這就是本書的主題,內容包括:需求要件(requirements)、減少語意曖昧(ambiguity)、使用者參與、激發概念的會議、專案命名、調和衝突、客戶要什麼(功能、特性、限制、偏好、期望)、技術審查、測試使用者滿意度、黑箱測試等等。還有許多實際案例,以及豐富的心得分享與建議。
本書中提到的技巧,曾經成功運用於許多產品或系統──包括電腦硬體、電腦軟體、汽車、家具、建築、消費性產品、書籍、影片、訓練課程等等。
本書對於新產品專案的所有利害關係人——團隊成員、客戶、使用者、還有必須綜觀全局掌控進度的經理人,都大有幫助。本書可以幫助你有效帶領團隊,讓新產品專案邁向成功!
- 致台灣讀者
- 〔推薦序〕 從需求到設計,解析消費者的需求
- 前言
-
第一部 先有一點共識
-
1 光有方法,還不夠
-
1.1 CASE、CAD,和蟑螂必殺器
-
1.2 方法改變了問題
-
1.3 圖表和表示法
-
1.4 確認圖表可以被每個人看懂
-
1.5 需求要件圖表並非需求要件本身
-
1.6 心得與建議
-
1.7 摘要
-
-
2 需求要件語意曖昧
-
2.1 語意曖昧的實例
-
2.2 語意曖昧的代價
-
2.3 去除語意曖昧
-
2.4 心得與建議
-
2.5 摘要
-
-
3 語意曖昧的原因
-
3.1 一個實例:收斂性設計程序研討會
-
3.2 測驗
-
3.3 叢狀分布
-
3.4 題目語意曖昧
-
3.5 心得與建議
-
3.6 摘要
-
-
4 直接詢問法的侷限
-
4.1 決策樹
-
4.2 語意曖昧的結果
-
4.3 哪裡可能出錯?
-
4.4 真實世界比我們想像的還要真實
-
4.5 心得與建議
-
4.6 摘要
-
-
-
第二部 起步的方式
-
5 開始
-
5.1 一個共通的起點
-
5.2 將眾多起點共通化
-
5.3 存在之假設
-
5.4 電梯的實例
-
5.5 心得與建議
-
5.6 摘要
-
-
6 開放式問題
-
6.1 程序性開放式問題
-
6.2 開放式問題的潛在威力
-
6.3 實質性開放式問題
-
6.4 後設問題
-
6.5 開放式問題的優點
-
6.6 心得與建議
-
6.7 摘要
-
-
7 找到對的人參與
-
7.1 尋找適當人選
-
7.2 使用者參與
-
7.3 參與
-
7.4 擬定徵召使用者計畫
-
7.5 心得與建議
-
7.6 摘要
-
-
8 有效率的會議
-
8.1 會議:令人又愛又恨的工具
-
8.2 參與與安全感
-
8.3 不去開會,也有安全感
-
8.4 規畫會議
-
8.5 心得與建議
-
8.6 摘要
-
-
9 努力減少語意曖昧
-
9.1 運用記憶法
-
9.2 從語意曖昧調查法開始
-
9.3 「瑪莉曾有一隻小羊」的啟示
-
9.4 「瑪莉詐騙股票交易員」
-
9.5 運用上述兩種方法於星星問題
-
9.6 心得與建議
-
9.7 摘要
-
-
-
第三部 探索各種可能性
-
10 激發概念的會議
-
10.1 典型的腦力冰風暴
-
10.2 腦力激盪的第一部分
-
10.3 腦力激盪的第二部分
-
10.4 心得與建議
-
10.5 摘要
-
-
11 運用右腦
-
11.1 繪圖工具
-
11.2 腦力繪圖
-
11.3 運用右腦的例子
-
11.4 心得與建議
-
11.5 摘要
-
-
12 專案的名稱
-
12.1 作業名稱、暱稱、正式名稱
-
12.2 名稱的影響
-
12.3 命名法
-
12.4 心得與建議
-
12.5 摘要
-
-
-
13 調和衝突
-
13.1 處理不重要的衝突
-
13.1.1 用錯時間,用錯專案
-
13.2 專心一意
-
13.3 處理重要衝突
-
13.4 心得與建議
-
13.5 摘要
-
-
-
第四部 釐清客戶的期望
-
14 功能
-
14.1 界定功能
-
14.2 掌握所有的功能需求
-
14.3 心得與建議
-
14.4 摘要
-
-
15 特性
-
15.1 特性表
-
15.2 將特性表加以轉化
-
15.3 配置特性於功能
-
15.4 刪除一些特性
-
15.5 心得與建議
-
15.6 摘要
-
-
16 限制
-
16.1 界定限制
-
16.2 限制即是疆界
-
16.3 測試限制
-
16.4 相互關聯的限制
-
16.5 限制過度嚴苛
-
16.6 限制的心理學
-
16.7 限制創造自由
-
16.8 心得與建議
-
16.9 摘要
-
-
17 偏好
-
17.1 定義偏好
-
17.2 讓偏好可以度量
-
17.3 區分限制與偏好
-
17.4 受限制的偏好
-
17.5 重塑限制使成為偏好
-
17.6 心得與建議
-
17.7 摘要
-
-
18 期望
-
18.1 限制期望的理由
-
18.2 限制期望程序
-
18.3 要勇敢地設置限制
-
18.4 心得與建議
-
18.5 摘要
-
-
-
第五部 大幅提升成功機率
-
19 判斷語意曖昧的基準
-
19.1 度量語意曖昧
-
19.2 運用基準進行測試
-
19.3 心得與建議
-
19.4 摘要
-
-
20 技術審查
-
20.1 草率了事的例子
-
20.2 技術審查的作用
-
20.3 審查報告
-
20.4 常用的審查方式
-
20.5 理想與現實
-
20.6 心得與建議
-
20.7 摘要
-
-
21 測試滿意度
-
21.1 測試使用者滿意度
-
21.2 測試表的效用
-
21.3 滿意度測試的其他功能
-
21.4 其他測試
-
21.5 心得與建議
-
21.6 摘要
-
-
22 測試案例
-
22.1 黑箱測試
-
22.2 運用測試案例
-
22.3 將測試案例做成文件
-
22.4 心得與建議
-
22.5 摘要
-
-
23 研究現有產品
-
23.1 以現有產品為基準
-
23.2 訪談
-
23.3 以特點取代功能
-
23.4 心得與建議
-
23.5 摘要
-
-
24 意見合致
-
24.1 決策從何而來?
-
24.2 錯誤的假設從何而來?
-
24.3 意見合致的決策
-
24.4 心得與建議
-
24.5 摘要
-
-
25 結束
-
25.1 對於結束的恐懼
-
25.2 一了百了的勇氣
-
25.3 富貴險中求
-
25.4 心得與建議
-
25.5 摘要
-
-
- 參考書目
- 致謝
- 出版地 : 臺灣
- 語言 : 繁體中文
評分與評論
請登入後再留言與評分