， 看 不 出 實質 內容 。 知道 各 類 文件 何時 交件 很 重要 ， 但是 我們 也 要 知道 這些 文件 完成 的 條件 。 接下來 ， 我們 列出 各 類 文件 所 需 的 其他 步驟 ， 亦即 「 作業 流程 」 ， 讓 各 組 成員 更 能 掌握 實質 進度 。 加上 作業 流程 之後 ， 就 能 算出 這 個 專案 總共 要 花 多久 時間 。 從頭到尾 ， 把 軟體 交到 客戶 手 裡 ， 要 花 九 個 月 的 時間 。 這 是 修改 程式 所 需 的 代價 。 如果 每 個 月 平均 的 人力 薪資 和 費用 為 一百萬 ， 總共 耗資 就 是 九百萬 。 對於 本 公司 這樣 的 規模 來 說 ， 這 不可 是 小 數字 。 所以 在 動工 之前 ， 先 比較 一下 之前 的 開發 成本 。 要 釐清 這 一 點 ， 這 次 我們 用 前 一 章 提到 的 時間 序列 圖 。 這 種 圖 我們 應當 很 眼熟 ， 這 是 把 數量 和 時間 結合 在一起 ， 用來 表示 數量 在 一 段 時間 內 的 變化 。 股價 走勢圖 是 常見 的 例子 ， 此外 也 可 用來 表示 任何 價格 、 數量 、 溫度 的 變化 。 我們 用 序列圖 顯示 軟體 的 開發 成本 和 過去 相比 有 何 差異 。 既然 現在 估算 需要 九百萬 ， 那 我們 最好 要 瞭解 一下 ， 之前 要 多少 ？ 如果 現在 比較 便宜 ， 那 就 好 辦 。 若是 貴 很多 ， 就 得 精打細算 。 用 橫軸 表示 時間 進程 ， 縱軸 表示 數量 ， 依照 歷史 資料 畫出 開發 成本 。 公司 自 一九九六年 成立 ， 並 在 當年 推出 第一 版 「 超級 會計 經理 」 軟體 。 當年 的 成本 還 不到 五十萬 ， 靠 著 十 名 組員 不眠不休 ， 花 了 一 整 年 才 搞定 。 兩 年 後 推出 第二 版 ， 成本 漲到 兩百萬 ， 因為 組員 增為 四十 人 。 二○○○年 推出 的 第三 版 ， 成本 暴漲 為 六百萬 ， 也 奠定 了 SAX 公司 在 業界 的 龍頭 地位 。 但 到 了 二○○一年 底 ， 市場 一 片 蕭條 ， 為 求 生存 ， 公司 被迫 裁員 。 雖然 推出 新版 ， 但 由於 人事 成本 降低 ， 版本 更新 的 程度 也 相對 保守 。 但 自此 之後 ， 各 版本 的 開發 成本 便 持續 攀升 。 二○○六年 推出 的 第六 版 耗資 六百萬 ， 從 二○○二年 以後 的 趨勢 來 看 ， 目前 估算 九百萬 應該 算是 合理 。 但 這樣 的 資料 恐怕 還 不 夠 。 為了 說服 老闆 ， 還 得 考慮 公司 的 營收 狀況 ， 看 過去 幾 年 的 業績 是否 跟 得 上 成本 ？ 我們 用 同 一 張 圖 ， 橫軸 一樣 是 時間 ， 但 縱軸 改成 公司 當年 的 營收 。 從 一九九六年 開始 ， 當年 僅 一百萬 左右 ， 接下來 四 年 衝到 兩千一百萬 。 無獨有偶 ， 二○○一年 哀鴻遍野 ， 接下來 兩 年 業績 掉 了 不只 一半 ， 即使 當 市場 復甦 ， 業績 還是 沒 啥 起色 。 到 了 二○○四年 ， 營收 開始 大幅 攀升 ， 次 年 達 三千萬 ， 然後 就 陷入 停頓 ， 業績 不振 ， 營收 持平 。 促使 我們 開始 思索 問題 的 緣由 。 分開來 看 ， 兩 張 圖 各自 有 它 的 意義 。 從 第一 張 看來 ， 似乎 開發 成本 有 持續 增加 的 趨勢 。 看 第二 張 ， 發現 營收 面臨 瓶頸 __UNDEF__ （ 雖然 還是 不錯 ） 。 只有 把 兩 張 圖 疊 在一起 ， 才 能 發現 問題 所在 。 因為 縱軸 座標 不同 ， 必須 作 些 調整 ， 成本圖 要 往 下 壓 一點 。 兩 張 圖 疊 在一起 ， 很 容易 就 兩 者 的 走勢 進行 對照 。 看 了 上面 的 圖 ， 老闆 應該 會 提出 這樣 的 問題 ： 四 年 前 多 投資 三成 的 成本 ， 讓 我們 的 營收 漲 了 三 倍 ， 但 兩 年 前 又 多 花 三成 的 成本 ， 營收 卻 毫無 起色 。 既然 這樣 ， 現在 多 花 三成 的 成本 ， 會 有 什麼 好處 ？ 既然 知道 老闆 將 會 問 什麼 ， 我們 要 好好 斟酌 該 怎麼 回應 。 CHAPTER 13 要 怎樣 才 能 增加 業績 ？─ 解決 「 如何 」 問題 的 圖 HOW CAN IMPROVE OUR BUSINESS?Pictures That Solve a How Problem 怎麼 解決 問題 ？ 我們 又 碰到 新 的 難題 ： 怎樣 才 能 說服 老闆 （ 還 有 說服 自己 ） ， 要 提升 業績 ， 就 要 投資 九百萬 修改 軟體 ？ 我們 得 面對 現實 ， 要 老闆 掏 那麼多 錢 ， 肯定 沒 那麼 容易 。 話 雖 如此 ， 該 做 的 還是 要 做 ， 但 挑明 了 說 不見得 是 正確 的 方式 。 其實 呢 ， 我們 根本 不必 多 費唇舌 ， 而是 要 給 他們 看 個 明白 。 重點 提示 ： 流程圖 可 顯示 因果 關係 我們 在 前面 幾 章 看到 ， 不同 的 物件 如何 在 時間 內 彼此 互動 — — 在 質 、 量 或 位置 發生 改變 ， 但是 我們 現在 看到 彼此 之間 的 相互 影響 ， 也 就 看到 因果 關係 。 當 我們 要 顯示 因果 關係 的 時候 ， 就 畫 個 流程圖 。 傑森 打算 徹底 翻修 程式 ， 需要 畫 很 複雜 的 流程圖 。 我們 不用 一 開始 就 畫 得 那麼 複雜 ， 先 從 比較 簡單 的 例子 開始 練習 ， 來 琢磨 琢磨 公司 主管 的 決策 心態 。 我們 從 框架圖 得知 ， 流程圖 的 座標 是 從 動作 到 反應 ， 最初 的 動作 就 是 起點 。 所以 我們 從 主管 會 先 問 的 第一 個 問題 開始 ： 「 你 把 問題 講 清楚 了 嗎 ？ 」 接著 再 問 ： 「 有 沒有 什麼 解決 方案 ？ 」 如果 兩 個 問題 都 答 不 上來 ， 那 就 沒 戲唱 ， 可以 走出 老闆 的 辦公室 了 。 我們 必須 把 問題 釐清 ， 並 提出 解決 方案 。 接下來 要 討論 你 的 方案 在 技術 層面 是否 可行 ， 若 不行 ， 那 就 罷了 。 財務 上 是否 合理 ？ 不行 的話 ， 立刻 否決 。 如果 都 沒 問題 ， 就 開始 慎重 考慮 。 這些 主管 是 軟體 業界 的 老兵 ， 自然 有 足夠 的 判斷力 。 他們 會 斟酌 ： 「 這樣 能 真的 解決 問題 嗎 ？ 」 如果 估計 至少 有 四分之三 的 成功率 ， 老闆 通常 就 會 答應 ， 否則 的話 ， 就 暫且 作罷 。 現在 我們 知道 ， 進到 大 會議室 的 時候 會 碰到 什麼 場面 。 首先 ， 我們 要 把 問題 釐清 ， 並 提出 一 套 解決 方案 。 我們 還是 用 流程圖 來 呈現 這 個 問題 ， 不過 ， 這 一 次 事情 會 複雜 得多 ， 而且 我們 一 出師 就 是 壞 消息 ： 業績 沒有 起色 。 業績 沒有 起色 的 原因 可能 有 三 點 。 一 ， 客戶 本身 遇到 瓶頸 ， 沒有 成長 （ 並非 如此 ， 據說 過去 兩