例1
例2
例3
今天在公司羣中看到三段這樣的對話，我陷入思考，才發覺Frank的處理方式是多麼的出衆。
我們所在的技術部也負責着每日的軟件問題處理，處理由技術支持無法解決移交的問題，主要爲軟件異常與數據修復兩類。
資源配置
a. 註冊一個“數據修復”的QQ
b. 有一個“問題處理”的企業QQ
c. 每個人有一個對外的QQ，名字一致爲“公司名+技術支持+數字編號”
d. 技術支持人員和研發組人員共建一個QQ羣
人員配置
每天有2個人來負責，1人爲主導，1人爲輔助
如果問題處理負荷>2人，可以將問題轉發到團隊內部羣裏，其他人主動輔助處理
處理流程
數據修復
a. 每天主導負責的人員登陸該QQ
b. 任何人可以直接有問題的數據庫發送至指定的“數據修復”的QQ郵箱中（利用QQ郵箱的及時通知）
PS： 是否需要修復數據有很簡單的鑑別方式問題處理—企業QQ
a. 每天主導負責的人員登陸該企業QQ
b. 技術支持直接將企業QQ上的用戶（soft有問題）無縫轉接給上面的企業QQ（企業QQ的優點）問題處理—主動添加
a. 大家肯定會登陸自己的QQ（羣里人員到位了）
b. 負責處理問題的2個人登陸着對外的QQ
c. 技術支持將不是企業QQ上的用戶信息發在羣裏
d. 羣裏研發組當前版本負責問題處理的兩個人員會主動回覆get到
e. 處理問題的2個人用對外QQ添加用戶
f. 解決問題……
g. 問題解決方案總結在羣裏或分享在知識庫中
PS： 市場部等人員不在電腦旁，用手機QQ等方式
這樣的處理流程帶來的好處：
對內，分工明確，共同成長，不影響團結
問題來了不會有“是不是我該去處理一下”、“我處理別人也在處理重了”等問題
每個版本大家輪流來主導負責，鍛鍊相關的軟硬技能
內部值班分配靈活調整，外部不需要關心（遇到假期等情況大家有事調換一下）
不會出現霸權
- 員工入職有先後，早入職的員工對用戶問題處理的越多經驗也越豐富；
- 早入職的員工也是被其他部門最爲熟知的；
- 本着大家輪流坐莊學習，但其他組的人員會將問題單發給早入職的員工，這讓這個版本負責的人很尷尬（這裏反省一下，我在v5.40的版本中主導處理，遇到這種情況，情緒化越發嚴重，影響團結）
- 不會出現老人離職，用戶問題處理無法正常運作的問題
對外，隨時可以找到人處理問題
o，這就是封裝?!
缺點呢？缺點應該是設計吧？需要去設計的，不是面向過程一樣，遇水搭橋就可以了。
在現實中還有一個難點：需要各個部門配合，例如修復數據，不發送到指定郵箱，就要找組裏人員單聊
不過在程序中這是有點，接口指定出來了，不會暴露內部細節
人比程序複雜
組裏一開始人員少的時候，也沒有上面這樣的處理流程，因爲沒有必要；當組內人員多了，也出現了和其他組一樣的問題，纔有了這套流程；讓我想到了面向對象的起源也是因爲這個時代軟件功能越發複雜而衍生的
雖然一開始有這個流程，但也會出現各種問題。想其他部門開始的時候沒有配合；內部主導和輔助職責不明確；組裏每個人都可以處理，但是如果你解決了問題，將問題解決方案和用戶反饋給這個版本負責的人，讓他在羣裏去公佈，這樣的做法應該更好吧……
這讓我想到封裝、重構、好的設計方案這些都不是一次就能完成的。都是迭代的結果。
