「 建造 」 的 開發 人員 重複 目前 已 有 的 功能 ， 相反 的 ， 他們 不斷 將 工具 用 在 以往 從未 考慮 過 的 新 任務 上 ， 例如 模擬 彩色 而 非 黑白 螢幕 。 「 建造 」 的 開發 人員 語 帶 敬意 地 說 ： 「 我 給 了 他們 一 把 螺絲起子 ， 而 當 我 回來 時 ， 他們 正 拿 它 建造 金門大橋 。 」 　　 見習 模式 　 在 若干 專案 中 ， 使用 者 利用 本身 工作 情況 的 知識 ， 全權 負起 建立 新 工具 所 需 專技 的 整合 。 他們 通常 移樽 就教 於 工具 設計 人員 ， 實際 見習 以便 開發 和 建立 系統 ， 待 系統 建立 之後 再 帶 至 原來 的 工作 地點 。 想要 自身 擁有 開發 能力 ， 且 不至於 受 開發 人員 牽制 的 使用 者 ， 多半 會 採用 這 種 模式 。 開發 人員 必須 願意 扮演 教師 ， 而 非 提供 者 的 角色 ， 而 使用 者 則 必須 願意 投資 足夠 的 時間 和 資源 ， 以 成為 相關 技術 的 專家 ， 並 在 回到 自己 的 地盤 後 ， 實行 所有 必要 的 改變 。 符合 此 模式 的 專案 能否 成功 ， 端視 它們 是否 符合 上述 的 條件 。 143144 「 高手 」 ： 成功 的 見習 　　 用來 辨認 及 診斷 電路板 製造 問題 的 「 高手 」 （ Adept ） 專家 系統 ， 是 加州 某 工廠 的 兩 位 使用 者 所 建立 的 。 使用 者 之 一 ， 是 長於 找出 電路板 問題 、 經驗 豐富 的 製造 測試 工程師 ， 另 一 位 則 是 負責 找出 多數 瑕疵 的 技師 。 這 兩 人 都 沒有 任何 設計 軟體 程式 的 經驗 。 人工 智慧 軟體 開發 專家 教 他們 如何 操作 獨有 的 專家 系統 框架 後 ， 便 以 導師 和 指導 者 的 身分 ， 從旁 指導 這 兩 位 製造 人員 自行 撰寫 「 百分之九十九 的 程式碼 」 。 在 此 案 中 ， 開發 者 迫切 想 把 責任 轉移給 使用 者 。 「 我們 採用 伐木 工人 的 方法 ： 自己 的 斧頭 自己 磨。 」 　　 「 高手 」 大為 成功 。 在 採用 「 高手 」 前 ， 有 百分之三十八 被 貼上 「 沒 問題 」 標籤 的 電路板 ， 無法 通過 最後 的 「 燒入 」 （ burnin ） 測試 。 由於 診斷 不 出 原因 ， 公司 只好 將 這些 電路板 報廢 ， 造成 極 大 的 浪費 。 「 高手 」 在 六 個 星期 內 ， 便 將 這 類 電路板 的 比率 降到 百分之十九 。 除此之外 ， 該 專案 也 成功 地 將 相當 多 的 科技 軟體 程式 設計 能力 ， 轉移給 使用 者 。 「 教育 成為 另 一 個 目標 ， 」 一 位 專案 的 指導 人員 提到 。 在 新 系統 安裝 之後 ， 技術人員 將 軟體 程式 接收 ， 並 繼續 改善 和 發展 。 一 年 之內 ， 他們 已經 將 無法 診斷出 問題 的 電路板 比率 降到 百分之三 。 這些 板子 甚至 不需 再 重新 測試 ， 因為 報廢 的 成本 反而 變 得 比較 低 。 更 重要 的 或許 是 ， 製造 部門 擁有 了 以往 所 不 具備 的 能力 — — 創造 小型 的 專家 系統 以 協助 製程 的 控制 。 之後 ， 製造 測試 工程師 又 為 工廠 設計 了 若干 類似 的 程式 。 　　 雖然 只要 符合 若干 情況 ， 上述 四 種 使用 者 參與 模式 均 有 成功 的 機會 ， 但 只有 共同 開發 和 見習 模式 牽涉到 整合 兩 個 迥異 團體 — — 軟體 開發 和 使用 人員 的 知識 。 除此之外 ， 見習 模式 對於 使用 者 組織 的 衝擊 ， 相對 地 也 較 低 。 見習 的 使用 者 自行 在 腦海 裡 整合 所 獲得 的 知識 ， 並 擴展 個人 的 能力 ； 他們 時常 會 接續 扮演 開發 人員 的 角色 。 不過 ， 見習 人員 對於 開發 人員 的 團體  不會 有 太 大 的 影響 ， 而 使用 者 團體 也 可能 拒收 見習 人員 所 開發出來 的 創新 知識 。 這 種 情況 對於 企業 程序 能力 的 提昇 ， 並 無 多 大 助益 。 　　 相反 的 ， 共同 開發 專案 迫使 開發 人員 和 使用 者 共同 解決 問題 、 創造 及 整合 知識 ， 而且 共 負責任 能夠 教育 雙方 更 了解 對方 的 領域 （ 見 圖 ４‧３ ） 。 整合 的 層次 在 團體 而 不 在 個人 。 開發 人員 開始 了 解 生產 程序 的 需求 ， 而 生產 人員 也 開始 意識到 新 工具 所 隱藏 的 潛力 。 在 若干 例子 當中 ， 開發 小組 會 繼續 進行 一連串 的 專案 ， 因為 他們 的 合作 揭示 了 更多 改良 程序 的 機會 。 這些 聚合 在一起 的 專案 ， 大幅 提高 了 公司 的 生產 能力 145146 。 公司 不僅 創造 了 更 先進 的 工具 ， 某些 知識 整合 的 障礙 更 因此 而 消弭 。 簡言之 ， 共同 開發 對於 公司 學習 過程 的 影響 ， 遠 超過 其他 任何 模式 。 相互 調適 　　 共同 開發 對於 組織 能力 影響 較 大 的 主因 之 一 在於 ， 開發 過程 提供 科技 和 使用 者 工作 環境 相互 調適 的 機會 （ 目前 許多 公司 推動 「 再 造 工程 」 〔 reengineering 〕 ， 所 持 觀念 便是 讓 組織 的 再 設計 和 科技 設計 同時 進行 、 相互 配合 ） 。 亦即 讓 科技 的 再 發明 能夠 配合 工作 環境 ， 而 組織 也 可 在 使用 新 技術 系統 的 同時 加以 調適 。 負責 推行 新 技術 系統 的 經理人 ， 必須 能夠 認清 並 承擔 起 技術 和 組織 同時 變更 的 責任 。 　　 相互 調適 有 兩 個 要點 ： ‧ 它 以 大大小小 的 回歸 螺旋式 改變 發生 。 ‧ 它 通常 需要 四 個 能力 構面 的 相互 配合 。 __UNDEF__ 這 兩 點 提出 了 經理人 可 用以 提昇 新 科技 對 科技 能力 貢獻 的 助力 。 □ 調適 的 改變 螺旋 — — 由 小 而 大 　　 調適 的 過程 需要 重新 思考 原來 的 決策點 — — 重新 考慮 開發 人員 認為 已經 解決 的 技術 設計 問題 ， 並 將 組織 的 日常 作業 「 解凍 」 。 這些 僅 能 被 視為 螺旋 （ spirals ） 而 非 循環 （ cycles ） ， 因為 ， 經過 重新 考慮 的 決策 和 原先 所 做 的 決策 並 不 完全 相同 。 時間 、 外在 事件 和 學習 效果 等 ， 已然 改變 了 決策 的 環境 。 調適 螺旋 大小 不一 ， 端視 改變 的 幅度 而 定 。 在 科技 調適 的 案例 中 ， 小 螺旋 僅 會 為 新 技術 系統 帶來 微幅 的 調整 ， 而 大 螺旋 則 可能 迫使 開發 者 重回 設計桌 ， 甚至 重新 界定 問題 。 同理 ， 組織 再 設計 的 小 調適 循環 ， 可能 只 需 改變 某 一 特定 角色 或 任務 ； 而 大 循環 則 可能 牽涉到 工廠 、 辦公室 ， 甚至 整