2014年12月27日 星期六

如何培養你的『溝通力』

這是一篇欠了很久的文章。不寫,是因為我覺得這主題要寫的好著實不容易,但偏偏『溝通』這件事情,是專案管理當中非常重要的一環,也是工程師想要蛻變或升級的一個必學功課。(因此這一篇讀起來要有點耐心)

在溝通這件事情上,身為開發人員或PM的你,理論上應該要非常有經驗。從專案一開始(甚至說還沒開始)『溝通』就持續在發生。在presale介紹產品時,在SA洽談規格時,在UAT面對客戶的挑剔時,在專案延遲面對客戶的責難時...

你肯定會發現,需要『溝通力』的場合真是無所不在。

既然需要溝通的場合天天發生,那表示,大部分的PM或工程師,都能夠順利的做好『溝通』這件事嗎? 完全沒有,甚至可以說,大部分的專案都是敗在溝通上面的。特別是工程背景的技術人員,在面對溝通上,總是常常犯著有形無形的錯,卻始終不自知。然而,這是個性和訓練背景的不同使然,可能真的是非戰之罪。

但只要有機會,工程師必須調整自己,才能夠往另一個層次的方向邁進。

備註:上面所說的,正好就是資深技術人員不一定能夠成為好的PM的原因,雖然我自己找的PM,都堅持必須要有技術背景,但我也非常清楚,對於有技術背景的專業人員,由於受的訓練與思考模式的不同,其實相當不容易跳過這個gap。


接著,我們就來談談溝通這件事情。

首先,你第一個你必須注意的事情是,溝通是一件需要花時間的工作。大多數的工程師喜歡思考、也喜歡動手、甚至喜歡談技術,但不喜歡說話,特別是不喜歡耐心的聽別人說話。

『不喜歡耐心的聽別人說話』,是溝通的第一個致命傷。(你認為自己算是很有耐心? 或覺得這應該是個容易克服的問題? 請先往下看再說...)

你必須知道一件事情(這是一個心態的調整),所謂的溝通,並非是想盡辦法(透過技術或是專業)說服對方,而是給對方一個說服自己的機會。意思是,當你想要和對方溝通,如果你的潛在目的是只想讓對方照你的意思做,那不叫溝通,基本上那就是談判(或是說服)。

溝通是,你必須抽離自己的角色和立場,從一個第三者的角度來看,你自己所在意的,和對方所在意的,兩者之間有多大的距離,為了讓雙方都滿意,該如何找出具有創造性的第三選擇,而非只執著在自己要的結果或對方想要的結果上面。(想深入了解這個概念,可以參考柯維的『第三選擇』一書)

柯維在第三選擇中說:「溝通中的傾聽是你讓對方充分表達並且了解對方的感受,到足以為對方辯護的程度,否則你其實並沒有聽進去任何東西。」

注意,溝通的目標絕對不是妥協,不是企圖守住自己底線的妥協、或是試圖讓對方妥協,而是找出兩者均感到滿意的新的另一種可能性。要完成這樣的工作,不耐心傾聽別人說話,是不可能達成的。

因此,溝通的第一件事情,是真心的想要並且真正的理解對方到底在意的是什麼。

而要真正理解對方在意的是什麼,第一個要素就是『傾聽』。不幸的是,工程師都很聰明,而愈是聰明的人愈沒有耐性傾聽。

你可能過去在很多書上看到過介紹傾聽的許多技巧,甚至包含身體該擺什麼姿勢,該怎樣運用手勢或是表情....然而我要說的是,這些技巧,如果只是停留在『技巧』的階段,則你並非是真心的想了解對方。著重技巧的傾聽,充其量只是一種行為上的敷衍(像是在告訴對方,我現在花了時間聽你說話囉,等一下就換我說了,你準備好好聽著吧!)。人的相處很微妙,如果你不是真心的想要了解對方的想法,相信我,時間一長,對方肯定會知道。

因此針對傾聽,我只推薦一個做法,是我在教會和第三選擇一書上多次學到的,就是『複述』。當你在傾聽對方的想法時,必須要練習絕不打斷對方發言,直到每一個對方主動停下來的段落,你要複述你所聽到的(複述他所說的),直到對方(注意,不是你自己)確定你理解他的想法為止。

例如...用以下這樣的方式詢問,讓對方協助你確認你自己是真的知道他的想法...
『所以,你的意思是.....』
『因此,你認為最重要的是...』
『我感受到你在意的是...』

這很花時間,且違反人性。要求你不辯解、不反駁、只複述對方所說的,直到對方都講完並且認為你聽懂了為止。你甚至可能擔心這樣是否會給對一種懦弱的感覺,但相信我,這麼做絕對值得。

你或許也會質疑,有時候事情就是只有『對』或『錯』、『要』或『不要』、『是』與『不是』,就算知道對方的想法之後,又有什麼用呢?

如果你常常用這個角度來思考,我得要衷心的提醒你,你被這個世代(特別是台灣當代)非黑即白、非藍即綠的二分法思想荼毒太深,必須立刻回頭,否則可能找不到岸。(工程師特別容易陷入這樣的true/false陷阱)

在這個世界上,太多事情落在 0 與 1 之間。但有趣的是 0 與 1 之間所能找到的解答絕不只是妥協,而是第三種對雙方都更好的可能性。但,這是什麼意思呢?

我們在專案或人生中可能碰到很多衝突。業主要金額低,但同時要品質高、專案人力不足,但時程又很急、這個月底要驗收,但客戶又要增加功能...有太多太多太多『看起來』是衝突的問題,這時候高德拉特TOC理論中學習到的衝突圖,總是可以提供我很大的幫助。

以一個簡化的例子來看,請先看下圖右方綠色的部分...

 
看上圖這個例子,在專案中PM覺得需要更多的人力,而老闆則堅持專案不該再增加人力。兩者之間顯然發生了衝突。一般人碰到這種衝突或意見不合,都會反射性的啟動『防衛模式』,開始聚焦在自己的立場和角度,並且找出各種論點去支持自己的看法,導致兩方的態度漸行漸遠,最終完全沒有交集。最後,事情只能透過妥協或折衷(雙方都不滿意,但勉強可以接受)的方式來解決。

但高德拉特和柯維建議我們不要這麼做,而是透過溝通、傾聽,去了解對方心裡想的是什麼? 到底他在乎的是什麼? 透過繪出衝突圖,你會發現PM在乎的是『讓手中的專案能夠順利完成』,而老闆則碰到『其他專案也有迫切人力需求』的情況。

理解了雙方背後所在意的因素之後,接著要找出兩者共同的目標(價值觀),因為我們只能在價值觀一致的情況下溝通(不要不信邪,價值觀不同,是沒法溝通的)。PM和老闆透過溝通,最後發現其實雙方在意的都是『如何將人力資源進行更有效的規劃與使用』。有了這個基礎,兩方之間就可以找到一致的價值觀,開始尋求對雙方都更好且彼此都滿意的作法。

能夠瞭解這之間的差異嗎? 如果不透過溝通,雙方解決問題時,最終只會透過談判或協調的方式,產生的結論幾乎都不是最佳解,而是0與1之間的妥協值。然而,透過溝通,則是找出雙方所堅持的問題背後的原因與動機,且尋求出一個兩者一致的價值觀,並且找出兩全其美、皆大歡喜的第三選擇。(這不是妥協,而是找到一個更好的新方法)

上面這個例子,是一個最小Scope的演練,在你的專案中、每天的生活中,會有非常多這樣的例子,由於這真的是一個違反人性的習慣,你必須一直練習、一直練習,直到你反射性的會傾聽,下意識的想去了解跟你不同的意見的人的看法,直到這時候,你才會逐漸感受到這個技巧的用處與價值。

備註:在台灣,我們非常幸運,幾乎每周都有一個議題,讓我們可以練習。例如公車專用道要不要拆、服貿該不該簽訂、鐵路要不要穿過水庫、證所稅該不該課徵...每天,台灣社會總是被二元化的思維所制約,正反雙方只堅持立場,不肯去尋求或理解對方的思維。

前面說過,這是一個違反人性的練習,所以想要培養出你的溝通力,你必須從你自己開始,你無法要求對方這麼做。也就是說,你不能拿著這篇文章,或是柯維的『第三選擇』、高德拉特的『限制理論』,丟到對方面前,要求對方傾聽你說話,你只能自己先這麼做,並且透過上面提過的技巧,引導對方和你一起找到彼此共同的價值觀,並尋求對彼此更好的解決方案。

沒有人說溝通是一件不費力或是很簡單的事情,也絕非只是說說話、開個電話會議、或是發一封mail就能解決的(我曾說過,email不是拿來溝通用的,email是用來記錄的)。然而,當技術人員能夠徹底的掌握到溝通的原則後(注意,是原則,不是技巧),所能夠發揮的力量,絕對是你難以想像的。

後記: 我真的很建議工程師先看完高德拉特的『目標』一書,接著你可以從他的續集『 絕不是靠運氣』中,學習到衝突圖的使用技巧,四本高德拉特讀完之後,接著看柯維的『第三選擇』,柯維和高德拉特這兩位作者的十幾本書,都是我長年放在書架上(大概重複看了二十年),並且常常在研討會送學員和team member的經典著作。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月25日 星期四

保持模糊的共識?

最近在新聞上,又有政治人物談起一個有些古老的議題,也就是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就談定了。至於工作範圍,人力預估…等文件內容,就算不是『天書』,也是PM透過經驗和直覺所產出的猜測數據

接著,專案開始,如果這時候開始細談規格,發現距離賠錢不遠,還有踩煞車的可能,然而,事情卻不會那麼簡單。

好不容易案子接進來了,團隊成立。人員安排好了,做了一個月你想停掉這個案子? 這責任要誰扛啊? 而且沒有下去做,你怎麼知道一定會delay呢? 怎麼知道會做不完? 加加班ㄍㄧㄣ一下,或許…應該可以的啦。

內外壓力夾殺之下,乙方PM慢慢接受專案現況,把案子撐下去。這時候關鍵來了,你猜日後甲乙雙方會更努力認真的釐清規格,算出到底有多少差距? 還是索性把頭埋在土裡,能不碰乾脆不碰?

是了,事已至此,清楚的釐清規格,只會造成雙方痛苦,甲方會發現專案一定Delay,乙方得接受案子一定賠錢,再繼續釐清下去,甲乙雙方都非加班不可,既然如此,乾脆保持模糊,大家眼不見為淨。

但,保持模糊有何好處?

首先,面對驗收時,可以用談判的方式來解決,有經驗的PM都知道,驗收不一定是照功能清單Check box勾勾勾,也可以用交換的,到時候拿這個功能換這個功能,拿那個功能換另一個功能,或許可行,因此,乙方PM想著的是…客戶頭都洗一半了,諒他也不敢打掉重練吧?

甲方PM心裡想的是:『規格沒搞清楚是你的責任,想要我付錢當然就是要照我說的來驗收啊,反正我到時候不簽驗收看你是能怎樣?』然而問題在於,同一個規格的文字描述,甲方想的是ABC,乙方想的是甲乙丙,兩者看是相似卻有差別,最後誰說了算呢?

既然規格不清有那麼多風險,那談到很清楚再簽約不是比較好嗎? 問題來了,那前面談規格的那一段成本算誰的? 規格要談的很清楚,就必須花時間,要花時間,就等於要花錢。這錢要誰出? (甲乙雙方都會覺得這是對方該負擔的) 更重要的是,那這樣還要不要成案? 如果談了三個月中途生變,豈不是賠了夫人又折兵?

所以,這種『創造性的規格模糊』,就在矛盾和妥協當中出現了。

在我經歷過的專案當中,需求和規格在很清楚的狀況下才開始進行開發的案子極少,有相當高的比例是在簽約時,規格都還沒有釐清。那規格不清晰怎麼會有預估金額呢? 不要問我,我也覺得很不可思議,但台灣大部分的軟體專案就這麼幹了。

規格模糊並非只有壞處,有時候可能就是得要這樣,才能夠面對瞬息萬變的用戶需求(Really???)。時程較長的大型專案,想要釐清規格恐怕也很難。有時候開發到1/3的階段,用戶需求已經大幅改變,搞不好連當時談規格的用戶都已經離職,一開始談的再詳細也是沒用。(對,規格書很清楚,但end-user會跟你說,這系統他不能用啊,他知道規格書這樣寫,但他不能用你要他簽驗收,他還是簽不下去啊…)

也因此,問題不在規格的模糊,而是在怎麼控制變更。

PM把規格和需求的變更視為常態(從心態上一開始就當作理所當然,這就是會發生的事情),你就不會擔心(憂慮)規格模糊的問題(而應該在各方面做好面對變更的準備,包含合約)。然而,模糊的規格當然還是必須在日後開發前確認與釐清,這也是我們在Scrum當中,會有Planning Meeting與Sprint安排的原因之一。

規格的模糊並非罪惡,然而在何時,怎樣用適當的方式把規格釐清,讓開發團隊可以即時的進入開發,並且讓客戶滿意,則是專案管理上的一個溝通藝術。

過去在waterfall時代,規格的模糊也常常發生,但往往卻導致UAT驗收的那一刻,你才發現這不是客戶要的(客戶也才發現你根本沒聽懂他說什麼),如今在agile時代,規格的模糊依舊會發生,但我們卻不害怕變動,透過頻繁的溝通讓變動與規格的釐清在你的掌握中,透過每一個Sprint的Demo/Review讓你的成果被客戶所認同,隨時與客戶保持互動,讓客戶知道你正在為他努力,你也在乎他的需要,這才是PO/PM該達成的使命。

因此,身為PM/PO,不需要害怕規格模糊。但是,千萬別忘記,刻意保持的模糊,是為了達成某個共識(例如成案),然而終有一天,模糊的事情必須被釐清,隱藏的問題必定被揭露,屆時,就看彼此準備的有多充分了,專案上如此,政治上其實也是。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月20日 星期六

[經驗分享]如何用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可以很清楚的知道整個專案的健康狀況,也能夠反映出專案能夠準時完成的可能性。在管理上是相當好用的報表。

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月18日 星期四

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

Task的建立與撰寫

Taskbacklog的子階,一般來說,我讓PO來建立Backlog,由Team MemberScrum Master來展開Backlog建立Task

Backlog代表著是要待完成的功能(任務),而Task則是具體展出來的開發工作。Backlog多半沒有技術的用詞,最好的寫法是以非技術的term來撰寫(stakeholders也能看懂),而Task則是該功能(任務)的拆解開來的具體工作了,所以有一些技術的term並無不可。

PO所撰寫好的Backlogs展開(或拆解)tasks,是在ScrumPlanning Meeting中發生的,所以一開始專案Kick-off前後,可能根本只有Backlogs而沒有tasks
 
還記得嗎? Backlogs中有一個effort欄位,寫的是預估時間。

在台灣,專案成案前,往往必須告訴客戶預估金額和時間,但Tasks都還沒有展開,能算出100%準確的預估時間嗎? 我不認為可能。依照Backlogs所估出的時程也僅僅為估算而已。專案團隊最好不要讓POSales以為這是時程上的『承諾』。

而真正到了專案開始進行,把Backlogs展成Tasks之後,POteam才會慢慢了解(認清)專案的真相,一些被隱藏的工時才會慢慢出現,特別是3-5Sprint之後,就可以清楚的知道自己的預估是否準確,從而進行修正。

也因此,落實到合約的簽訂,如果可以,最好在總時程和總金額尚保留一點空間。(我承認在台灣很難)

在操作的實務上,Sale依舊可以依照過去的報價方式(把預估膨脹個幾倍)來報價,但對於POScrum MasterTeam(甚至客戶)來說,在運行Scrum之後,專案的透明度無疑地提高了。

(關於專案報價與成案問題,可以參考飛機上的27A - 談敏捷開發的成案問題)

如何建立Task


Work分類項目下,你可以看到Backlog Items,請留意當滑鼠移動到下圖Backlog Items的藍色長條圖示右方後,會看到其實右方有一個比較淡色的灰色長條,你可以點選它:




點選之後,會發現該長條變成黃色了,如此一來可以展開Task




 
如果你的Backlog尚未建立任何Task,可能會跟上圖一樣,只看到階層狀(如果有階層的話)Backlogs但你可以按下左方的『+ 』符號,則可以在該Backlogs底下建立一個新的Task


建立Task的畫面與建立Backlogs差不多,除了都可以Assign給特定的Team Member之外,也可以描述Description,一般來說,我讓team members在這裡寫下該工作的規格與進行的狀況(也可以寫在右邊的History),便於開發也便於事後追蹤。
 
由於剩餘工時的欄位內容(數值)會在該task被check in為done時清空為0,因此,如果你想保留每一個Task所花費的工時(實際花費工時),則必須要特別將該數值(實際工時)寫在另一個欄位中(我們是寫在Task的Backlog Priority欄位中,因為該欄位具體用途不大,在Backlog中已經有Priority了)。
 

剩餘時數 與 燃盡圖

 
而effort欄位在Task這邊變成了remaining work(剩餘工時),這個欄位是讓開發人員隨時(一般來說是每天)更新該工作預估還要多少時間才能全部做完。基本上這部分是用來產生燃盡圖(Burndown Chart):
 

從燃盡圖上,PO/PM可以看的出來工作目前進行的狀況(完成度),圖中的黑線是平均理想線(也就是假設在Sprint結束前,工作都會被如期完成),如果圖形顯示出來,顏色區塊是低於黑色直線(像是上圖中的2/8, 2/9),表示工作進行得很順利,甚至可能提早完成,反之,如果顏色區塊都高於黑色直線(像是上圖中的2/14),表示順利如期完成的機會恐怕不高。

當然,燃盡圖要有意義,前提是team member必須天天更新remaining work時數,且數值必須真實。不過需要強調一下,實務上,我們看燃盡圖也只是為了得知專案真實的狀況,並非要壓迫(壓榨)哪一個developer,逼著team在期限內完成工作。

指派工作負責人員


你可以在建立Task的時候就指派該Task的負責人員,但這比較不符合Scrum的精神(後面我們會提原因)。在指派人員的介面操作上,也有兩種不同的方式,例如在底下新增畫面中,選擇Assigned To欄位中的team member:



但用這樣的方式來設定,如果你沒有在一開始建立task的時候就指派負責人,那日後指派時得要把每一個task都Double Click點開,非常辛苦&麻煩,也不方便調整或一次指派多個task。

 因此,有另外一個更好的方式。

 你可以在Sprint當中作tasks的指派,請參考下圖:


當某一個Backlog被分派到某個Sprint當中之後,你可以在左方點選該Sprint的黃色Bar,接著會出現上圖右方的畫面,請注意其中有一個Capacity選項:

你點選之後,可以設置團隊每一位成員的每天可用工時。別忘記設定完成之後要按下 鈕。
接著,請切回Backlog,並且將Work Details要設為On,接著你就可以透過拖曳的方式,將某一個task指派給特定的Member了:




從上圖右下方的圖表中你也可以看的出來,每一位team member的工作量是否爆表,或是還有餘裕可以接收更多的task,工作量爆表的Member會以紅色顯示,而綠色則表示尚有餘裕: 



 
本篇收錄自 - 『敏捷開發專案管理與架構設計實務

2014年12月8日 星期一

這些問題都不在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卻覺得面對面溝通沒有效率,所以希望用文件來取代面對面溝通。(這是真的,因為很多developer溝通起來像鬼打牆,繞來繞去兩小時後還在討論一樣的問題)

但其實,用文件溝通是『經過研究指出最無效的溝通方式之一』,我始終不相信透過文件溝通會比面對面溝通來的有效且明確。

文字,其實是一種抽象的表達,有時候用錄影的影片,效果都比文字來的好上一大截。

我強烈的不建議團隊用文件來取代溝通,特別是描述性質的文件,描述功能、描述bug、描述規格...等。我希望PM/PO打從心裡質疑文件,而把文件當作一種紀錄工具而非溝通工具

我常常讓PM/PO跟客戶談規格的時候,一邊打開VS Online的backlog/features,並且同時當著客戶的面把功能敲入系統,但請注意,這不是拿來跟客戶或developer『溝通』用的文件,而只是一種備忘,避免漏掉了某一個客戶提到的需求。

有各種技巧和方法來描述user story,你在坊間可以看到各種優雅或是前衛的方式,甚至搭配影音或是ppt slide,有太多太多方式聲稱可以清晰地描述規格,但我建議你,不要太過於全盤相信。只透過文件的溝通,永遠不能取代面對面的交談。

我衷心地建議PM和開發人員:我們可以竭盡所能地要求文件清晰,但不要以為文件就是溝通的工具。溝通,除了理解對方想表達的內容,還包含接收對方的感受。

有些Developer會說,我之所以選擇寫code,就是不希望碰到用戶,難道不能只看規格書來寫程式嗎? 我只能說,Developer,請多加訓練自己溝通的技巧,面對客戶、面對用戶,去了解對方真正的需求,去感受到對方的情緒,少說話,多聽,複述對方的需求,直到對方認為你了解他心裡所想的,那才是溝通。

截至目前為止,我從未讀過可以讓我"感受到用戶情緒"的文件,文件是死的,但人是活的。所以,千萬不要只看文件去理解規格,不管是features/bugs都是。

請不要誤會我覺得文件不重要,文件是重要的,但文件不是拿來溝通的。人,才具有溝通的能力,隔了一層文件,只能有最基礎的認知和理解,而不容易掌握到全局。developer千萬別放棄自己溝通的能力...傳統認為SA/PM才需要具備溝通技巧的時代慢慢要過去了...

如果有機會,我們改天再來談談溝通的問題