我曾走過訪談、開發、維運一條龍時代，也曾經和PM合作完成專案，常常會覺得，有些PM一起合作時，專案就是順暢無阻，有些PM的專案，總是一路紅燈。
每個PM做專案的方式不同，訪談的方向、準備的方式也不同，這就是做專案的有趣之處；有些PM的專精時程管理，有些PM擅長規劃媒體網站的呈現，有的PM簡報能力極佳，短短一場會議就能取得user的信任，和不同PM合作其實都能偷學到他擅長的部份，不足之處，工程師就要往前站一些，給予系統或技術上的支援。
當然，工程師心中都有一個小本本，討論起來發現，瀟灑小姐幾乎都位居各家小本本榜首，看起來就是個笑瞇瞇的小姐姐，她用的工具都非常基本，做的事好像也沒什麼特別，但不知道為什麼，和她一起工作，就是特別輕鬆。
她其中一個特點，就是很會畫圈圈。
所謂畫圈圈的能力就是，明確界定專案範圍，清楚理解以本次專案的資源需要完成哪些關鍵目標，我們訪談時的重點就是80%條件相同的計算邏輯，也就是圈圈內要完成的功能；剩下20%的例外或是異常，我們和user都該理解，則是應該要用額外的方式處理。
盡量避免為了發生頻率20%的例外，影響80%的系統設計。
舉一個簡單的例子，我們的核心目標若是「計算正職人員三節獎金，金額為薪資0.5個月」，圈圈內的確認就是三節的定義、計算的時間、是否有領取門檻、計算的公式等等；至於其他不是以此邏輯計算三節獎金的人員，如約聘人員皆以服務年資乘固定費率計算，就並非圈圈內需要完成的工作。
通常user在UAT階段很常提出一些極其例外的狀況，但現有系統可能無法處理的問題，可能訪談階段都沒有提及，這個階段的往來，就很需要讓user理解系統範圍，才能討論超出圈圈外的工作，是否有必要追加資源處理。
剛開始碰到這種狀況時，我會生氣，也會慌亂，會不小心把場面搞得像攻防戰，也曾經不小心答應了不該答應的需求追加。
我後來大概能理解多數客戶的心情，越接近驗收上線階段，相對會沒有安全感，負責規劃的窗口也是需要跟主管交代的，有時候可能只是主管隨口一問，或者是臨時有新狀況需要諮詢，有時候user的想法只是需要建議，不見得都是咎責或推卸責任。
畫圈圈講起來十分簡單，但實際上，需要不斷練習反覆調整，才能繪製出適合我們個人的圈。