發表文章

如何培養你的『溝通力』

圖片
這是一篇欠了很久的文章。不寫,是因為我覺得這主題要寫的好著實不容易,但偏偏『溝通』這件事情,是專案管理當中非常重要的一環,也是工程師想要蛻變或升級的一個必學功課。(因此這一篇讀起來要有點耐心) 在溝通這件事情上,身為開發人員或PM的你,理論上應該要非常有經驗。從專案一開始(甚至說還沒開始)『溝通』就持續在發生。在presale介紹產品時,在SA洽談規格時,在UAT面對客戶的挑剔時,在專案延遲面對客戶的責難時... 你肯定會發現,需要『溝通力』的場合真是無所不在。 既然需要溝通的場合天天發生,那表示,大部分的PM或工程師,都能夠順利的做好『溝通』這件事嗎? 完全沒有,甚至可以說,大部分的專案都是敗在溝通上面的。特別是工程背景的技術人員,在面對溝通上,總是常常犯著有形無形的錯,卻始終不自知。然而,這是個性和訓練背景的不同使然,可能真的是非戰之罪。 但只要有機會,工程師必須調整自己,才能夠往另一個層次的方向邁進。 備註:上面所說的,正好就是資深技術人員不一定能夠成為好的PM的原因,雖然我自己找的PM,都堅持必須要有技術背景,但我也非常清楚,對於有技術背景的專業人員,由於受的訓練與思考模式的不同,其實相當不容易跳過這個gap。 接著,我們就來談談溝通這件事情。 首先,你第一個你必須注意的事情是, 溝通是一件需要花時間的工作 。大多數的工程師喜歡思考、也喜歡動手、甚至喜歡談技術,但不喜歡說話,特別是不喜歡耐心的聽別人說話。 『不喜歡耐心的聽別人說話』,是溝通的第一個致命傷。(你認為自己算是很有耐心? 或覺得這應該是個容易克服的問題? 請先往下看再說...) 你必須知道一件事情(這是一個心態的調整),所謂的溝通,並非是想盡辦法(透過技術或是專業)說服對方,而是給對方一個說服自己的機會。意思是,當你想要和對方溝通,如果你的潛在目的是只想讓對方照你的意思做,那不叫溝通,基本上那就是談判(或是說服)。 溝通是,你必須抽離自己的角色和立場,從一個第三者的角度來看,你自己所在意的,和對方所在意的,兩者之間有多大的距離,為了讓雙方都滿意,該如何找出具有創造性的第三選擇,而非只執著在自己要的結果或對方想要的結果上面。(想深入了解這個概念,可以參考柯維的『第三選擇』一書) 柯維在 『 第三選擇 』 中說:「溝通中的傾聽是你讓對方充分表達並且了解...

保持模糊的共識?

圖片
最近在新聞上,又有政治人物談起一個有些古老的議題,也就是OO共識。不過一直以來,這個名詞總給人一種虛無飄渺的感覺。有人說OO共識根本不存在,有人說確有這個共識,但實質內容為何? 也不一定人人都可以說的上來… 這種國家大事,可能不是身為市井小民的我們,能夠深入剖析和探討的,但有一個極為類似的問題,則是我們在進行專案管理中,時常發生的狀況。也就是『規格的刻意模糊化』。 很多專案團隊,在驗收時碰到爭議,很大比例的原因,是因為規格不清,或是規格的認知有所差距。我們最常聽到的例子,就是客戶指著規格書中的某一條說:『OO功能 當然 是包含在這條規格裡面的,現在怎麼沒有呢?』或是:『這個機制怎麼可能沒有XX功能? 這 想當然 應該要有的啊,不然怎麼用呢?』從客戶的角度來說,這些OO和XX,本來就是系統該出現的內容, 但對於專案團隊來說,這則是規格書中所沒有的『規格外』的『需求變更』 ,為何兩者之間會有那麼大的落差? 其中一個最主要的原因是,當時談規格的時候『沒談清楚』。但,為什麼會沒談清楚呢? 可能是時間不夠,可能是系統分析師素養不足,也可能是甲乙雙方溝通或表達能力不好,但這些不是我想談的問題(因為以上原因都可以透過訓練來改善),我想談的是另一個看似不該存在,但卻十分常見的原因,就是…甲乙雙方刻意讓規格保持模糊。 這種情況你或許以為不該發生,但實際上卻是最常發生的狀況。 雙方PM為何要刻意讓規格模糊? 理由很簡單,因為雙方都想成案。而模糊化的規格書,最有助於成案(是了,因為可以各自解讀)。有時候靠著一兩張A4的SOW工作範圍說明書,PM和Sale就想把價格和時程談下來,甲方PM可能經歷了漫長的選商和詢價,早已面對(答應上頭老闆)的時程壓力,而乙方Sale正好業績缺的緊,雙方一看對眼,你情我願之下,交易立刻談定,PO馬上開出,接下來的後面一個月皆大歡喜。 甲方PM開始熱鬧的安排Kick-off,乙方Sale本季績效達成,乙方PM接到燙手山芋其實也不太擔心,反正kick-off之後還有半年時間,年底才要驗收。有時候乙方Sale甚至會給PM(人情)壓力,PM也知道規格不清楚會有風險,但不接案難道喝西北風嗎? 先前已經推掉兩三個案子了,總不能Sale拉進來的每個案子都被自己擋掉吧? 如此這般,在沒有詳細規格之前,Deal就談定了。至於工作範圍,人力預估…等...

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (十) 累計流量圖 與 燃盡圖

圖片
再上一篇我們談過了Task的建立之後,接著,我們來看看延伸出的圖表。 在VS Online當中,有兩個比較關鍵的圖表,是與工作進度有關的。一個是先前提過的燃盡圖(BurnDown Chart),另一個則是累計流量圖(Cumulative Flow Diagram)。 由於我們先前看過了燃盡圖,因此我們先來看一下累計流量圖。 累計流量圖(Cumulative Flow Diagram) 累計流量圖主要呈現出專案中每一個Backlog在時間軸上狀態的變化,外觀大致讓如下: 你會看到圖表右邊的四種狀態分別是New、Approved、Committed、與Done。如果你還記得,這四個狀態是Backlog的狀態,可以從Backlog的維護畫面中設定: 但更多的時候,其實我們比較喜歡在Backlog的看板(Board)當中用拖曳的方式來設置(改變)狀態: 一般來說,我讓PO/Scrum Master建立Backlog(剛建立的Backlog狀態為New),但我只讓PO把Backlog從New改為Approved ,一但開發完成,Tester/QA測試無誤,則讓Scrum Master將該Backlog從Approved狀態改為Committed ,PO(或客戶)驗證無誤後,則由PO將Backlog從Committed改為done。 而你看到的累計流量圖,則是這個狀態在時間軸上的變化狀況。也就是說,從圖上看起來,如果綠色的done面積佔有的比例越來越大,則表示這個專案逐漸完成,反之如果灰色的New佔有的範圍越來越大,則表示這個專案的新需求持續增加。 從累計流量圖當中,很容易可以看出整個專案的健康程度,以及完成的比例。 燃盡圖(BurnDown Chart) 燃盡圖我們在前面討論『剩餘時數 與 燃盡圖』討論過,從燃盡圖上我們可以看到在Sprint中所有工作項目(Tasks)的完成度。 某種程度上來說,燃盡圖用以表現出特定Sprint的剩餘工作量(藉此預估是否能夠如期完成),而累計流量圖則可以看出整個專案的整體工作進度(也包含了新需求的成長速度)。 透過這兩張圖表,PO或Scrum Master、Stakeholders可以很清楚的知道整個專案的健康狀況,也能夠反映出專案能夠準時完成的可能性。在管理上是相當好用的...

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (九) 從Backlog展開Tasks

圖片
Task的建立與撰寫 Task 是 backlog 的子階,一般來說,我讓 PO 來建立 Backlog ,由 Team Member 或 Scrum Master 來展開 Backlog 建立 Task 。 Backlog 代表著是要待完成的功能 ( 任務 ) ,而 Task 則是具體展出來的開發工作。 Backlog 多半沒有技術的用詞,最好的寫法是以非技術的 term 來撰寫 ( 讓 stakeholders 也能看懂 ) ,而 Task 則是該功能 ( 任務 ) 的拆解開來的具體工作了,所以有一些技術的 term 並無不可。 將 PO 所撰寫好的 Backlogs 展開 ( 或拆解 ) 成 tasks ,是在 Scrum 的 Planning Meeting 中發生的, 所以一開始專案 Kick-off 前後,可能根本只有 Backlogs 而沒有 tasks 。   還記得嗎 ? Backlogs 中有一個 effort 欄位,寫的是預估時間。 在台灣,專案成案前,往往必須告訴客戶預估金額和時間,但 Tasks 都還沒有展開,能算出 100% 準確的預估時間嗎 ? 我不認為可能。依照 Backlogs 所估出的時程也僅僅為估算而已。專案團隊最好不要讓 PO 或 Sales 以為這是時程上的『承諾』。 而真正到了專案開始進行,把 Backlogs 展成 Tasks 之後, PO 和 team 才會慢慢了解 ( 認清 ) 專案的真相,一些被隱藏的工時才會慢慢出現,特別是 3-5 個 Sprint 之後,就可以清楚的知道自己的預估是否準確,從而進行修正。 也因此,落實到合約的簽訂,如果可以,最好在總時程和總金額尚保留一點空間。 ( 我承認在台灣很難 ) 在操作的實務上, Sale 依舊可以依照過去的報價方式 ( 把預估膨脹個幾倍 ) 來報價,但對於 PO 、 Scrum Master 、 Team( 甚至客戶 ) 來說,在運行 Scrum 之後,專案的透明度無疑地提高了。 ( 關於專案報價與成案問題,可以參考 飛機上的 27A - 談敏捷開發的成案問題 ) 如何 建立Task 在 Work 分類項目下,你可以看到 Backlog Items ,請留意當滑鼠移動到下圖...

這些問題都不在Scrum

圖片
前幾天,China RD Team有一個PM說,想找我問個Scrum相關問題。 內容大概是這樣的,PM問我有沒有什麼好的方法來管理Bug? 沒頭沒尾,我當然反問他:『Visual Studio Online不夠好嗎?』他只說:『覺得太浪費時間了?』我只好問:『怎麼說呢?』 大概的狀況如下: Tester測試後把bug列上了TFS,變成work item,接著就擱在那裏了。首先,這個bug沒有owner,這問題好解,如果很嚴重只需要在team room或是日常溝通或deily scrum時,讓PM/PO/SM把bug指派給特定developer即可,如果不急,最遲最遲Planning Meeting或retrospective meeting做都行。這沒問題,接著,變成developer解完bug後,這個bug就擱在那裏了,tester不會(也不想)去再次驗證,或是tester常常覺得developer改的不是他說的bug,不然就是developer不理解tester所謂的bug是什麼意思??? 劇情到這裡就很玄了,我開始有點聽不懂。 我只好問:『developer和tester都是自己人吧? 在同一間辦公室嗎? 』 PM回答:『他們坐在附近。』 我問:『那,他們都不溝通的嗎?』 PM說:『溝通太浪費時間了!』 我追問:『那它們怎麼確認bug的細節呢?』 PM:『就是寫在TFS上啊』 我:『寫bug description? 包含重現的步驟? 包含測試時採用的帳號? 還有操作的順序? 還有... 』 PM:『沒有,就寫一行,幾個字這樣...』 我:『...』 我只能說,這是素養的問題,這跟Scrum無關。 首先,並不代表你run了Scrum,原本專案中的問題就會消失,頂多大家職責開始變得清楚了,是誰的責任,會比以前更清晰。再說,Scrum讓團隊變得敏捷,但團隊成員中,程度好、程度差並不會因為這樣就有所改變。你還是得去面對以前碰到的問題。包含管理問題。 前面提到的狀況,是軟體開發中很典型的常見狀況。developer和tester之間的溝通障礙,本來,scrum就不鼓勵用文件來溝通,文件頂多是用來記錄,而溝通這種事情,最好是面對面進行的。而PM/PO卻覺得面對面溝通沒有效率,所以希望用文件來取代面對面溝通。(這...

為什麼我要規範所有團隊用同樣的架構開發專案?

圖片
前陣子在上架構與框架設計的課程時候,提到幾件事情。我說... 要設計出好的架構不難,但真正能夠實施(implement)在團隊中的卻很不容易。 架構設計是一種取捨,沒有絕對完美的做法,有得,就有失,架構師除了要有足夠的技術能力,更重要的是,要有足夠的溝通能力。 架構設計只有一件事情最重要,就是能夠實施(implement),無法實施的架構,再美也是枉然。(不能實施的因素有很多,除了設計的好壞,更多的時候是架構師是否能夠同理開發人員技術程度,以及能否在導入時突顯這個設計的優點) 架構與框架的設計與導入,不僅僅是建構開發團隊的基礎,更是一種引導或限制,讓開發人員被框在某一個規範中,在有限制的狀況下自由發揮(我甚至補充,在軟體開發和專案管理的世界中,過度的自由是一種罪惡) 。 我無法在有限的課程時間中,解釋某些事情。因此,趁著有空且記憶猶新,我想來談談我們過去一兩年做的架構設計,以及為何我要求台灣和China幾個團隊中,所有的成員(PO/PM, SD/SM, Developers)都必須採用這樣的架構。 =================================== 先講講背景... 最近這幾年,我們在Web開發上揚棄了從服務器端產生HTML的方式,而改採接近SPA(Single Page Application)的model來進行專案開發,也因此,整個ASP.NET MVC,嚴格說起來,我們只有用WebAPI,其他的部分都是透過我們自己開發的框架(Framework)來搭配與運行。 簡單的架構圖如下:   在這個架構底下,Framework 本身負責 Services Layer(中間橘色的那塊)、Client 端對服務器端 Server Components 的調用(呼叫)、以及 Cross-Cutting Components(左方豎著的那塊)。 採用此Framework 架構的開發人員,只focus 在底下2個部份的開發,而將其他部分交由這個Framework 處理,分別是: Server Components 開發   Server Components 以.NET Assembly(.dll)的形式開發,開發人員可以建立標準 的.NET 4.5.x Class Library,透...

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (八) 重新對應Backlogs與Feature之間的關係,以及專案時程的推估

圖片
先前我們在 這一篇 當中,曾經介紹過如何從Features展開Backlogs,但也有非常多的狀況是直接產生(建立)Backlogs,這時候我們就有可能需要重新連結(對應)Backlogs與Feature之間的關係。在這一篇當中,我們來看看這個部分。   前面說過,你可以從Features展出Backlogs,這部分實際上操作時很簡單,你只需要在Features畫面中,依照底下的方式,就可以透過『+』從Features以展開的方式來撰寫Backlogs了。   但如果你的Backlogs是獨立寫好的,或是先寫了Backlogs,後來想要讓它歸屬於某一個Features,或是調整Backlogs的Features,可以怎麼做呢?請參考下圖: 你可以先把Backlogs與Features的Mapping打開,即可拖曳特定Backlog到特定的Feature身上,以建立(或修改)兩者之間的關係。 此外,如果你觀察Product Backlogs的輸入畫面,會看到畫面右上部分,有一個forcase,可將其設為On,接著,會出現一個Forecasting Velocity讓你輸入調整(每個Sprint的工作量),設定後,即可看到如下圖的預估: 你會發現,系統已經參考了我們輸入的參考工作量,依照Backlogs的順序,計算出會大致落在哪一個Sprint ,這個功能非常的好用,能夠讓客戶一目了然的知道特定的Backlogs大約會何時開始開發。 但請留意一下這張圖,坦白說這張圖乍看之下不是很容易理解,所以我特別用藍底白字的箭頭,標註了一下Sprint。你會發現,編號1,2,3這三個Backlogs,是屬於Sprint 6進行開發的,而編號6,7,8,9則是屬於Sprint 8進行開發的。特別標註是因為,如果你把藍底白字的箭頭拿掉,你可能會以為編號3,4兩個backlog items是屬於Sprint 6,而編號5,6,7,8的backlog items是屬於Sprint 7,那可就誤會大了。 本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

[研討會] 透過雲端彈性且快速地延伸軟體的開發及測試

圖片
http://www.microsoft.com/taiwan/events/azure-enterprise/   在這個場次的研討會中,再一次地跟大家分享,透過VSOnline與Scrum如何讓團隊在專案管理與ALM上有個好的開始。由於時間比較長,因此這回比較完整的介紹了從kick-off開始之後,我們的專案團隊如何透過VS Online處理專案(或產品)開發的每一個Sprint,錯過的朋友,明年應該還有機會喔。   

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (七) Backlogs的異動、歷史紀錄、與Notification機制

圖片
每一個Backlog都有可能因著PO或Team Member的調整,而改變了狀態或內容,這個改變可能來自於團隊成員,也可能是擁有權限的任何人。但你不需要擔心,work item的每一個調整,哪怕只是上傳了一個檔案,或是在description中增加或減少了一個字,你都可以透過History看的一清二楚,因此不僅不用擔心被異動,也不會有資料經過修改後遺失了的問題。 要看到Backlog的History,可以開啟Backlog,接著點選 History:       進入到History之後,你可以更清楚的看到,該Backlog狀態的改變、以及Backlog的所有異動: Backlog和專案中的每一個工作項目(不管是Task/Features/Bugs…etc)都是開發團隊相當關注的部分。也因此,每當這些Work Items有異動的時候,老闆們(或是PO)可能都會想要知道。 因此,VS Online除了讓你可以從Backlogs/Task的History中看到變更之外,還可以透過訂閱的方式,來隨時掌握這些Work Items的異動。 你可以進入Project的首頁,在右上方有個『工具』的圖示: 點選該圖示後,會進入到管理畫面(請留意,必須具有管理權限才可以進入)。進入後請按下Alerts頁標籤,接著會看到底下畫面: 你可以從左方的選單處看到該專案所有的Alert,而右半部則可讓你建立或修改Alert。 當你點選New來新增Alert之後,會看到底下視窗:   你可以選擇Alert的範圍和類型,按下OK後即可新增。在底下的新增畫面中你可以看的出來,是依照剛才選擇的Alert範圍和類型所建立的。當然您也可以自行客製化調整,增加判斷條件,或是這個通知的發送對象。   按下OK鈕之後,這個Alert就建立好了,也同時間生效。此後,一旦Work Item有所變更,訂閱者將會收到類似底下這樣的email:   對於開發團隊來說,是相當好用的機制。   本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (六) 從Features展開Backlogs

圖片
在實務上,專案可以不寫Features,但不可能跳過Backlogs。 由於蒐集好Features之後,基本上Features只是客戶的Wish List,談不上是什麼規格,基本上只是針對系統需求的期待而已。因此,我們會讓PO稍微排一下優先順序(當然是參考客戶的意見),接著,開始把Features展開成為Backlogs。實務上,你也可以把Features視為Backlogs的大項分類。如果系統不是很大,那只寫Backlogs不寫Features(或是用後面會提到的階層式Backlogs取代Features)也並無不可。 如果參考微軟MSDN網站上的翻譯,微軟把Backlogs稱為『待處理項目 』,類型上還分為三種。 不過我倒是覺得,我們可以從比較扼要的角度來看Backlogs(簡化可以降低工具和開發方法導入的困難度)。 在這邊,我們先簡單定義一下。我們將一開始建立好尚未放入Sprint中)的Backlogs,統稱之為Product Backlogs,至於進入Sprint之後,被放入特定Sprint中的Backlogs,我們稱之為Sprint Backlogs。因此,剛寫好的Backlogs,全都是Product Backlogs。 至於何時要將Product Backlogs放入特定Sprint(成為Sprint Backlogs)? 則是Planning Meeting要決定的事情了。(會在後面Planning Meeting中介紹) 此外,剛才前面有提到過,多個backlogs之間,也是可以有階層關係的,例如:   這個階層也可以視為Backlogs的分類,有點像是Features的意味。   Backlogs 的來源其實有很多種可能性,原則上大多是從 Features( 或是上一層的 Backlog) 展開,或是直接從系統分析後的規格書謄過來。   ===================================== 備註:         這邊要做一些說明,一般來說,我並不會希望團隊在run scrum的過程中,額外多一個撰寫系統分析說明書這一段。因此,我們一般是直接針對end-user做系統需求訪...