都會女子的異想世界

你知道你的客戶是誰嗎？

一定有人認為我在說廢話吧！

UML 中的 use case diagram中，為什麼要將 actor 畫進來？主要目的是什麼？

這個月接了一個案子，案子不大，客戶要求也不多，因此趁機用來訓練瑪姬寫需求分析。

今天針對某一個畫面的操作，討論使用者各種輸入狀況的可能性，瑪姬和 KiKi 媽咪的進入點完全相反，KiKi 媽咪經驗多、又是寫程式出身的、邏輯也還不錯，所以習慣大約先歸類了百分之70% 左右，就會推理出邏輯，但因為只想到 70% 案例，所以常會漏一、兩邏輯點。瑪姬不會寫程式，因此習慣用使用者案例的方式去想，但舉了很多很多例子，卻不會整理出邏輯。今天，針對瑪姬的做法，討論了如何彙整後，變成邏輯。

很巧地，回家在看「金字塔原理」時，正好看到這個理論。

「XX 電信公司的 CIO 常說，專案經理至少兩天要盯一次進度，我覺得她說的很好！我們要好好學習！」業務副總最近在和我打一個案子，搬出 XX 電信公司 CIO 的名言，要我在簡報上好好的渲染一翻。

我馬上回應，「每兩天盯一次可能來不及，對大專案來說，專案經理從第一個模組開始到最後一個輪完，再加上協調溝通的時間，不可能兩天才去盯一次，每天都忙死了吧！」

當然，這時心裡只想著一件事：

最近接到一個下包的案子，讓 KiKi 媽咪覺得很遺憾！

怎麼說呢？用說的不如用演的。

「決斷力」一書，在前一陣子，在管理類排行榜中也是常客，更是大家討論的管理性話題。尤其在前幾年，幾位有名的領導人對於百年企業做的決斷，更是本書的案例的重點。

其實，它不算是第二課，只是一個插曲。原因發生在一個不算正式的場合。

朋友的朋友，在 A 大廠工作，KiKi 媽咪在去年，利用 3.5 人月（ delay 一個月），完成了 A大廠一個 108 萬的案子。KiKi 媽咪只負責 0.5 個月的專案範圍設定，談好需求後，就交付給其它同仁完成。對這案子，我們幾個人都很驕傲，因為上線後，只發現一個問題，之後，就交付出去了，什麼問題也沒有發生。

朋友的朋友在非正式的場合中，和我抱怨說，自從我們交付了系統後，很多人在評批我們的系統，KiKi 媽咪覺得很奇怪，我沒有接到任何負責這系統人員要求修正系統的需求，為何會有此傳言放出。因此，KiKi 媽咪和朋友的朋友對談了一下，當了解了狀況後，只是會心一笑，這事到為止。

KiKi 媽咪看同仁的文件，先去檢視的，就是「目錄」。

接下來，先不看內容，先看版面的設計。

去年，KiKi  媽咪跑了四大家客戶，兩家客戶都被 KiKi 媽咪拿下來，兩家都還在談，但機率都很大！這四家客戶，都有一個共同點，就是都認同 KiKi 媽咪的專案管理理念及文件管理！

其實，KiKi 媽咪想要整理有關軟體專案管理已經很久了，但一直遲遲沒有下筆．

原因很簡單，看過網路上很多討論的文章，發覺大家都好專業，因此不太敢下手．

在這產業工作十多年來，科技不斷在進步，人員不斷在變化，這產業一直都像新興行業一樣，沒有定下來的一天，讓人追的好辛苦！沒有幾個專案賺錢的．