評估 。 複雜 產品 的 開發 過程 裡 ， 最 困難 的 部分 是 管理 。 要 組織 許多 不同 的 人 、 團隊 、 部門 ， 和 他們 溝通 協調 ， 同步 作業 。 大型 的 計畫 尤其 難 管 ， 這 不僅 是 因為 要 管理 許多 不同 的 人 ， 也 是 因為 長 時間 的 開發 過程 會 自然 發生 許多 困難 。 如果 一 個 計畫 花上 好幾 年 來 完成 ， 它 所 牽涉 的 需求 及 技術 可能 會 隨 時間 而 改變 ， 使得 某些 工作 變 得 過時 或 無關緊要 。 要 使用 產品 的 人 可能 會 改變 ， 而 參與 開發 的 人員 則 肯定 會 變動 。 也許 是 因為 生病 、 受傷 、 退休 、 升遷 、 調職 或 跳槽 ， 有 些 人 會 離開 這 個 計畫 。 不管 原因 為 何 ， 尋找 替補 人員 ， 等 他們 提高 能力 水準 ， 能夠 進入 狀況 ， 會 浪費 相當 多 的 時間 。 有時 甚至 不可能 完全 替補 ， 因為 有關 計畫 決策 和 方法 的 關鍵 知識 ， 是 我們 所 稱 的 隱性 知識 （ implicit k nowledge ） ； 也就是說 ， 它 只 存在 於 工作 者 的 腦 中 。 當 這 個 人 離開 了 ， 他 的 隱性 知識 就 跟 著 不見了 。 管理 龐大 的 開發 計畫 的確 是 一 項 艱鉅 的 挑戰 。 我 剛剛 怎麼說 的 ？ 現實 通常 不 是 那麼 一 回 事 前 一 節 描述 產品 開發 中 ， 以 人 為 中心 的 設計 過程 。 但是 有關 理論 和 實踐 之間 的 區別 ， 有 這麼 一 個 老 笑話 ： 從 理論 上 來 說 ， 理論 和 實踐 之間 沒有 區別 。 從 實踐 上 來 說 ， 區別 可 大 了 。 人本 設計 描述 的 是 一 種 理想 的 過程 ， 但是 商業 環境 中 的 現實 考量 ， 常常 迫使 我們 無法 照 理想 中 的 方式 進行 。 一 個 消費性 產品 的 設計 團隊 裡 ， 一 位 心灰意冷 的 設計師 告訴 我 ， 即使 他 的 公司 聲稱 他們 相信 使用 者 經驗 的 價值 ， 並且 遵循 人本 設計 的 原則 ， 在 現實 中 ， 公司 的 新 產品 只 關心 兩 件 事 ：1 .
 
因為 要 跟上 競爭 對手 的 產品 ， 所以 添加 新 功能 。 2 .
 
因為 有 新 科技 ， 所以 增加 了 新 功能 。 「 難道 我們 不 需要 在乎 人 的 需求 嗎 ？ 」 他 覺得 自己 多此一問 ， 「 顯然 公司 覺得 不 需要 。 」 這 是 個 常見 的 情況 。 市場 導向 的 壓力 ， 加上 技術 導向 的 文化 ， 會 不斷 在 產品 上 增加 新 功能 、 複雜性 和 混亂 。 但 即使 是 有心 了 解 客戶 需求 的 公司 ， 也 經常 因為 產品 開發 過程 中 的 嚴峻 挑戰 而 挫敗 ， 尤其 是 時間 不足 和 資金 缺乏 的 挑戰 。 因為 看過 了 很多 產品 屈服 於 這些 挑戰 ， 我 提出 了 所謂 的 「 產品 開發 定律 」 ： 諾曼 的 產品 開發 定律 ： 一 個 產品 開始 開發 的 那 一 天 ， 就 已經 落後 進度 、 超過 預算 了 。 產品 的 推出 總是 伴隨 著 時間 和 預算 的 限制 。 在 一般 情況 下 ， 推出 的 日程表 是 外界 因素 決定 的 ， 包括 節日 、 特別 的 產品 發布 時機 ， 以及 製造 工廠 的 時間表 。 我 曾經 做 過 一 項 產品 ， 只有 四 個 星期 的 時間 ， 完全 不切實際 ， 那 是 因為 在 西班牙 的 工廠 要 開始 放假 ； 如果 等到 工人 度假 回來 才 開工 ， 產品 會 趕不 上 聖誕節 的 銷售 旺季 。 此外 ， 產品 開發 的 啟動 也 需要 些 時間 。 人們 不可能 會 坐 在 那裡 ， 什麼 都 不 做 ， 光 是 等 著 被 叫 去 開發 產品 。 一 個 開發 團隊 必須 召集 、 審核 人選 ， 然後 把 人 從 他們 目前 的 工作 職位 上 調過來 。 這 一切 都 需要 時間 ， 而 常常 在 進度 中 不 曾 安排 這樣 的 時間 。 想像 一下 ： 一 個 設計 團隊 接到 命令 ， 要 開始 開發 一 個 新 產品 。 團隊 的 成員 集體 歡呼 ： 「 太 好 了 ！ 我們 會 立刻 派出 我們 的 設計 研究 人員 ， 開始 研究 產品 的 目標 群體 ！ 」 「 你 這 研究 ， 要 花 多 長 時間 ？ 」 產品 經理 問道 。 「 哦 ， 很 快 ！ 大概 花 一 兩 個 星期 安排 ， 然後 實地 觀察 兩 個 星期 ， 再 一 兩 個 星期 整理 研究 成果 。 總共 四五 個 星期 就 夠 了 。 」 「 對不起 ， 」 產品 經理 說 ： 「 我們 沒 那 個 時間 ， 何況 我們 也 沒有 派 隊 去 實地 觀察 兩 個 星期 的 預算 。 」 設計 者 不 同意 ： 「 但是 如果 我們 真的 想 了 解 目標 群體 ， 這 是 必須 要 做 的 。 」 產品 經理 說 ： 「 你 說 的 沒 錯 ， 但是 進度 已經 落後 了 。 我們 花不起 這 個 時間 或 預算 。 下 次 ， 好 不好 ？ 下 次 我們 一定 會 做 。 」 當然 好 ， 只是 永遠 也 不會 有 下 次 。 當 下 次 機會 來臨 時 ， 同樣 的 爭論會 再度 重複 ， 因為 產品 的 開發 從頭 一 天 起 就 落後 進度 、 超過 預算 。 產品 的 開發 牽涉到 許多 專業 的 複雜 組合 ， 從 設計師 、 工程師 、 程式 編寫 、 生產 、 包裝 、 銷售 、 市場 行銷 和 售後 服務 ， 以及 其他 更多 不同 的 合作 領域 。 一 項 產品 要 能 吸引 既有 的 客戶 以及 新 的 客戶 ， 專利權 問題 更為 設計師 和 工程師 布下 了 一 個 步步 陷阱 的 地雷區 ， 因為 在 今天 ， 設計 或 製造 一 個 與 任何 既有 專利 不 相 衝突 的 產品 幾乎 是 不可能 的 。 這 意味 著 設計師 必須 小心 繞過 許多 可能 觸犯 專利 的 地雷 。 每 一 個 單獨 的 專業 對 產品 都 有 不同 的 看法 ， 也 有 雖 不 相同 ， 但 同樣 具體 的 條件 要 滿足 。 由 各 個 專業 提出 的 要求 往往 互相 矛盾 ， 但是 從 他們 各自 的 角度 來 看 ， 又 都 合情合理 。 然而 在 大多數 公司 裡 ， 這些 專業 分別 獨立 作業 ： 設計 部門 把 設計 交給 工程 部門 ， 工程師 修修 改改 滿足 他們 的 要求 ； 然後 他們 將 結果 交到 編寫 程式 的 開發 部門 ， 他們 又 再 加以 修改 ； 再下來 ， 製造 部門 再 改 一 次 ， 市場 行銷 又 改 一 次 ， 結果 成 了 個 爛攤子 。 這 個 問題 該 如何 解決 ？ 應付 因 時間 緊縮 ， 而 無法 做 前期 設計 研究 的 困難 ， 唯一 的 解決 方法 是 將 它 從 產品 開發 的