2013年12月17日 星期二

敏捷做廣播:NPR的聲態革命

徐柏峰
在需要快速求新求變的產業中,廣播電視(Broadcasters)是非常適合敏捷管理的行業。從越戰期間就開播,至今已經有40多年歷史的「(美國)全國公共廣播電台」(National Public Radio, NPR),歷經金融海嘯的衝擊,選擇用敏捷的工作方式,整合資訊和內容部門的產能,成功掌握新媒體的潮流,拉近了和民眾之間的距離。
NPR是全球知名廣播電台
        NPR從阿富汗喀布爾到中國北京,在17個國家都有特派員,NPR推出的節目,在全美透過975個公共電台聯播,每周固定聽眾估計超過2,600萬人,觸達量(Reach)比全美主要報紙總流通量(Total Circulation)還要高。國內很多英文補習班,還以NPR的線上影音新聞作為教材,足見NPR的影響力有多大。[1]
Source: http://www.niemanlab.org/2012/03/nprs-audience-shrunk-a-hair-in-2011-pushing-public-radio-further-toward-a-digital-future/


金融海嘯來襲,大製作節目應聲倒地
2008年全球金融海嘯之前,NPR正在規劃一個晨間新聞雜誌類的節目,專案代號叫做Bryant Park Project,當時鎖定對象是年輕聽眾,為了「確保製作品質」,專案規劃期間就動員了為數可觀的記者、製作人和編輯團隊,光是第1年的預算就編列了200萬美元,而且執行細節保密到家,唯恐消息走漏,便宜了友台。只可惜,計畫趕不上變化,Bryant Park節目一推出就遇到金融海嘯,再加上播出效果不如預期,製作單位只撐了10個月就喊卡,緊接著,由於整個電台預算縮水,節目部門只好勒緊褲帶,忍痛接著再砍掉Day to DayNews and Notes2個新聞節目。
資訊部門率先敏捷,與內容部門通力合作
大約在同一段期間,NPR找來Washington Post Newsweek Interactive的技術主管Zach Brand,帶領NPR的資訊團隊,花了89個月的時間,導入敏捷陣營的Scrum  Framework來開發數位產品,並開始重新打造NPR.org官網。[2] 這支「變身」後的敏捷團隊,走的是正統Scrum路線,總歸起來有6大特色:
第一,資訊部門化整為零。NPR,資訊部門的核心工作是開發網頁、APP和多媒體管理系統等平台,讓內容部門的同仁使用。整個資訊部門同仁大約45人,根據專案需求,每 3-10 人組成一支敏捷團隊,在任何時間,資訊部門都有23個敏捷團隊在運作。[3]
第二,團隊成員各司其職。開發產品的團隊分成3種角色:1名產品代言人(Product Owner, PO)1Scrum Master1組開發團隊(Team)PO代表客戶聲音(voice of the user),負責回答開發人員有關產品的所有疑問,並定期根據市場需要,排定先做什麼後做什麼,也決定工作成果何時才能對外釋出。Scrum Master 要維繫整個團隊的工作流程,並幫開發團隊排除萬難。至於Team,就是一群跨領域的做事專家,必須同心協力,盡全力交付對PO承諾的功能。針對每個功能,PO決定要什麼,Team決定怎麼做,各司其職,互不侵犯。[4]



第三,用SprintDaily Scrum規劃進度。如果交付項目是新媒體型態的新聞,Team的產品開發分工就包含設計、使用介面和軟體開發等角色,開發以2周為1(Sprint),每次專案結束,Team成員各自歸建。為了讓整個Team掌握最即時的資訊,專案每天舉行站立會議(Daily Scrum),每人都回答3個問題:昨天做了什麼?今天打算做什麼?以及,遇到甚麼困難?至於困難該如何排解,就留到會後讓成員之間彼此交流意見。
第四,以User Story描述需求。在整個專案的第1期,NPR的團隊一面啟動專案,一面透過第1期的Sprint Planning會議寫出整個專案預計開發的使用者故事(User Stories),需求的表達方式為:身為某某角色,我要能夠執行某某功能,如此一來我就可以…。例如,身為一個使用者,我要能夠儲存日曆上的事件,如此一來我就可以自訂行事曆。
第五,定期展示工作成果,並檢討工作流程。在每個開發周期的最後,團隊透過實績展示,讓利害關係人檢視實際交付的成果。除此之外,團隊還會再舉行一場回顧會議,讓夥伴們檢討大家工作配合上,有沒有什麼可以改善的地方。在NPR乾脆就把這場會,戲稱為討論怎們開會的會議。
第六、鼓勵面對面溝通。NPR的內容部門,負責製作編製新聞和音樂,資訊部門不作內容,而是透過平台播出數位內容。在敏捷化之前,部門之間是各做各的(silo),後來在Zach Brand帶領下,資訊部門先導入敏捷方法了,開發團隊就追著內容部門要需求,無意中就把內容製作人帶進產品開發流程中,成為團隊的一員,這個做法意外打破了部門之間的溝通障礙。原來,敏捷團隊講求信任,Team承諾定期交出「會運作的產品」(working product)PO則是專責(dedicated)Team一起打拼。內容部門的代表參與團隊工作後,開始看到實際交付的成果,體驗到敏捷的價值,回到部門報告時,自然就肯定敏捷的做法,有些部門還因此開始向資訊部門打探,怎麼參加教育訓練。後來NPR編輯台(Newsroom)和節目製作部門的敏捷化,就是這樣開始的。
NPR改用敏捷作節目,定位內容為公共Beta
NPR全面採用敏捷開發數位產品沒過多久,NPR的跨平台APP,以及把25萬筆新聞節目公開分享的NPR API,就雙雙獲得2010年線上新聞業獎(Online Journalism Award)的肯定。[5] 一波接著一波的成功經驗,讓沉寂5年沒新推作品的NPR節目部重新活躍起來。約莫從2012年初開始,NPR一口氣推出的幾檔膾炙人口的新節目,包括TED Radio HourDebuts Today Ask Me AnotherCabinet of Wonders。不過,這波新節目的做法,完全擺脫以前大製作的窠臼,而是順應時勢,改用輕巧的敏捷專案管理。
    敏捷專案管理的核心理念,講求產品要儘早而且頻繁地交付。NPR的製作單位,在共體時艱的氣氛下,在新節目改用Live來節省成本,並把既有用節目舊瓶換新酒的方式,根據聽眾的反應,逐步改善播出內容,所有節目內容,都只預先規劃幾集來試播,而不是根據事先的大規劃,照本宣科一路做下去。另外,為了確保節目內容符合觀眾胃口,製作單位邀請聽眾和在地的節目導播,一起把節目定位成公共的Beta版。正因為是Beta版,所以節目內容大走社交媒體路線,節目現場播出,很多聽眾同時透過Twitter Facebook 在互動,製作單位就利用網友的回應訊息,作為節目逐步改善的直接依據。
NPR敏捷推出的新節目,在市場上受到聽眾的肯定。對此,新上任的節目副總Eric Nuzum表示,以往NPR的節目講究大製作,要花上幾年的時間,從規劃、準備到播出,才能知道節目有沒有人氣,耗費的預算,動輒是幾百萬美元。現在用敏捷的作法,既便宜又有效。至於省下多少成本,事涉NPR的營運機密,Eric Nuzum就沒有公開表示了。[6] 目前,NPR內部持續在做敏捷的教育訓練,確保新進員工能夠快速上手,而除了Scrum以外,資訊部門現在也開始採用Lean的原則,朝消除流程浪費的目標邁進。
(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®,以及台灣、中國兩地首位專案風險管理師PMI-RMP®)




[1] 2009年間,華盛頓郵報(The Washington Post)曾刊文表示,雖然報紙、雜誌和電視新聞的讀者數量急遽下滑,但NPR卻是逆勢成長,寫下周收聽2,360萬人的紀錄。請見Paul Farhi. “Consider This: NPR Achieves Record Ratings.” The Washington Post, March 24, 2009. 到了2013年,NPR的周收聽人數已經突破2,600萬人。請參考 ”Top Ten Facts about NPR.” 網址http://www-s1.npr.org/about/aboutnpr/
[2] Zach Brand的簡介,請參考http://www.npr.org/people/133759696/zach-brand
[4] 根據筆者實際運作敏捷團隊的經驗,如果能讓POTeam各司其職,團隊的士氣自然就會高昂,技術的問題通常就能順利解決。
[5] 有關NPR API,請參考http://www.npr.org/api/index
[6] Erica Malouf, “NPR’s Gone Agile…Even Their Newsroom!” See http://www.innovation-series.com/2013/10/23/nprs-gone-agile-even-their-newsroom/

2013年11月25日 星期一

鴻海,客戶要的是敏捷

徐柏峰
日前美國亞利桑那州州長Janice Brewer來台參訪,鴻海董事長郭台銘親自接待。郭董在會後表示,「世界在改變,美國也在改變」,包括Apple在內,AmazonFacebookGoogle美國大企業,都希望鴻海能在當地提供快速樣品能力和新產品開發能力。[1]
        其實,郭董提到的這幾家世界級大咖,就是全球最具代表性的幾家敏捷企業:
        先就Apple來說,在Steve Jobs還健在的時候,就是終極產品代言人(Product Owner, PO),負責定義Apple產品需要提供什麼功能,才能取悅消費者;Apple經常把重要的產品功能,交付給小團隊負責,例如,當年MAC上的Safari瀏覽器,就是透過2名工程師合作轉移到iPAD上面;Apple企業內部建立「擔責員工」(Directly Responsible Individual, DRI)的環境,任何一個任務出錯時,都一定找得到一個必須負責的窗口;公司文化鼓勵的是「做大事,而不是省大金」(do great work, not save dollars)[2]
        再說Amazon吧!身為全球最大的網路線上零售商之一,Amazon成立第5(1999),就開始導入敏捷實務,而在2004~20095年間,Amazon的開發部門徹頭徹尾轉型,大量使用Scrum的工作方法。[3]
        另外,Facebook內部敏捷管理行之有年,早在2011年初,Facebook把工程師、美工、資料專家、專案經理和行銷人員合組成Collocated團隊,以及快速開發和每日站立會議(Daily Standup Meeting)這些敏捷實務,就曾獲得Time的專題報導。[4]
擷取自 http://content.time.com/time/video/player/0,32068,712448402001_2037228,00.html

        至於已經是搜尋引擎代名詞的Google,在2006年間就首次導入Agile,執行大型的分散式專案,當年還請到Scrum的共同創始人Jeff Sutherland,在Retrospective時到場幫忙分析Google的敏捷經驗教訓。[5]
        接觸過敏捷專案管理的人都知道,敏捷是一種以人為本的工作文化,團隊由跨部門的通才組成,快速依據客戶需求,循序漸進交付客戶在每個開發期間「最急著看到的東西」(=最有價值的東西)。客戶因為經常可以看到實際的成果,因此對團隊產生信任;公司不再一昧地追求Cost down,也不鼓勵個人績效,因為團體成績重於個人成績,而團隊士氣才是產能的動力;主管不再把壓力轉嫁在團隊身上,而是挺身而出,想盡辦法幫團隊排除工作的障礙。
        世界大廠對鴻海的期盼,正是台灣轉型的契機。如果像鴻海這麼大的集團,也能夠由上而下體會到敏捷的精隨,日後其他企業再紛紛跟進,或許就能把打造出「客戶放心、團隊開心」的敏捷台灣了。
(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®,以及台灣、中國兩地首位專案風險管理師PMI-RMP®)




[1] 「郭台銘:美大企業盼鴻海開發能力」,2013/11/09,中央廣播電台,參考:http://news.rti.org.tw/index_newsContent.aspx?nid=463134; 「鴻海 擬赴美東西岸設總部」,2013/11/09,聯合理財網,請見http://udn.com/NEWS/FINANCE/FIN3/8285103.shtml
[2] Steve Denning, “Is Apple True ‘Agile’?” See http://www.forbes.com/sites/stevedenning/2012/02/03/is-apple-truly-agile/
[4] David Ramel, “How Facebook Does Agile,” Application Development Trends. See http://adtmag.com/articles/2011/01/14/how-facebook-does-agile.aspx
[5] Jeff Sutherland, “Agile Project Management: Lessons Learned from Google,” InfoQ. See http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland

敏捷專案管理: 寂寞星球的聰明律師

徐柏峰
        在一般人的印象中,法律工作應該很難敏捷吧?法務的工作吃緊,不但要負責制定合約制定、協商客戶,還要提供法律諮詢,而法律文字通常又要琢磨很久,想要求快求變的敏捷起來,簡直是天方夜譚。日前,全球最大的旅遊書籍出版商-寂寞星球(Lonely Planet),有一群聰明的律師,用創意導入敏捷的工作方式,顛覆了我們對法務工作的刻板印象。
圖片來源: Lonely Planet Legal Affairs: smart people + lean work practices = innovation,網址http://lunatractor.com/not-just-an-it-thing-our-book/lonely-planet-legal-affairs-smart-people-lean-work-practices-innovation/
        寂寞星球的法務部門,過去也是過著死亡行軍地爆肝人生,每天加不完的班,客戶搞不清楚狀況就要訂合約,可是往往合約做出來之後需求才真的浮現,雖然工作累個半死,公司卻缺乏管理法務工作進度的機制,導致其他部門的同事,以為法務閒著沒事,因此不斷插件,造成地法務時間被嚴重切割,士氣低落。大約從2008年開始,這群法律人從IT部門學來敏捷方法,大約花了3個月,自創了一套融合Scrum、Kaban和Lean的工作方式,在辦公室豎起大大的工作看板,把每個客戶的法務需求寫在便條貼上,團隊以每周為一期,在看板上排定任務的優先順序,成員每天上班第一件事,就是開15分鐘的站立會議,根據自己的法律專長,選擇當天要執行的任務,而任務看板上,則把每個任務的進度,分為待辦、進行中、卡關、和客戶確認(相當於測試)和完工等5個狀態。自從導入這個做事方法,客戶可以視覺化看到工作進度,團隊做事也覺得有方向感,從此效能增加、士氣大振,成為非IT產業引入敏捷的知名案例。
Lonely Planet Legal Affairs: smart people + lean work practices = innovation,網址http://lunatractor.com/not-just-an-it-thing-our-book/lonely-planet-legal-affairs-smart-people-lean-work-practices-innovation/
(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®,以及台灣、中國兩地首位專案風險管理師PMI-RMP®)

2013年11月18日 星期一

敏捷專案管理:即刻救援的故事Chile Ayuda

徐柏峰
        突如其來的一場天災,讓全世界見證到敏捷的效率。
照片為 Claudio Núñez 所攝
照片為 Claudio Núñez 所攝
2010227日凌晨334分,南美洲的智利傳出芮氏規模8.8的強震,緊接著引發的大海嘯浪高3公尺,沿海地區受到重創。這場史上第6大的地震,不但奪走700條人命,也讓人口僅有1700萬的智利,多達150萬人無家可歸。地震發生後不久,一名叫佩德羅‧佛安德斯‧舒斯特(Pedro Fuentes Schuster)的智利青年,在推特(Twitter)發文徵求各方志士挺身而出,幫同胞走出難關。
Agile
摘自Agile 2011: One earthquake, 300 volunteers and 6 days to build a portal
        推文發出1天內,來自各地的60名義工,湧入聖地牙哥市馬波丘河畔(Mapocho River)的1間辦公室,啟動一個名為救援智利(Chile Ayuda)的入口網站開發專案,期望在最短時間內幫災民找到親友,並把善款和賑災物資,發放到最需要的地方。
        透過社群媒體的串聯,專案團隊2周內就膨脹到300人,所有成員依照專長不同,分為工程師(Engineer),媒體記者(Journalists)、網頁設計師(Web Designers)和理事會(Board)等4個工作小組。如此龐大的義工部隊,讓原本只能容納20個人的辦公室,時時刻刻的擠著上百個人。從專案管理的角度來看,這是個超高難度的專案:時間緊迫、需求持續演進,雖說人多好辦事,但團隊臨時成軍,義工之間大多不認識,光是溝通協調就是一大挑戰。秉持著和時間賽跑救人的理念,佩德羅靈機一動,想到用敏捷的方式,管理這個即刻救援的大型專案。他把軟體敏捷團隊常用的Scrum Framework稍做微調,當成大家做事的框架:
  • 原本最長30天1期的開發周期(稱為Sprint),縮短1天就是1期
  • 每天舉行3次站立會議(Stand-up Meeting),讓團隊成員間匯報進度,並設定未來8個小時的優先目標
  • 用看板(Kanban Boards)顯示工作和進度,讓成員自己挑任務,不必等人指派
  • 由於成員眾多,為了避免亂槍打鳥的大鍋炒會議,團隊和團隊之間的溝通,透過Holacracy的雙向連結方式,各派一員代表團隊溝通,促進快速達成決策
        另外,夜以繼日的趕工,讓很多人累到睜不開眼睛,一群義工們二話不說,現場就幫夥伴們「馬一節」,成為專案溫馨的插曲。
摘自Chile Ayuda網站影片
        這個即刻救援的大型團隊,當時雖然不受外界看好,還受到政客試圖插花作秀的壓力,但透過敏捷的工作方式,只花了6個工作天,就做出Chile Ayuda入口網站,也整合了Google Person Finder、Twitter stream和Facebook的App,即時幫3500名受災者找到親友,專案的Facebook專頁迅速累積了150,000 名粉絲,成為敏捷救人的知名案例。

畫面取自 http://www.chileayuda.com/
(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®,以及台灣、中國兩地首位專案風險管理師PMI-RMP®)



2013年11月9日 星期六

親愛的,我們家變敏捷了

(圖片取自Bruce Feiler個人網站)

徐柏峰

對從事文字工作的人來說,如果能寫出一本書登上紐約時報(New York Times)暢銷書排行(Best Sellers),這輩子就已經揚名立萬了,如果能夠寫出好幾本暢銷書,後半輩子就有接不完的通告,跑不完的演講。已經達到這個境界的美國名人布鲁斯.法伊勒(Bruce Feiler),頂著暢銷作家的光環,既主持節目,又在紐約時報擔綱寫家庭版專欄,上有高堂下有一雙稚女的他,深感要在這個時代當爸媽,壓力實在太大,因此他花了3年的時間,跑遍大江南北,走訪很多專家學者,希望求得讓家庭快樂美滿的妙方。在偶然的機會下,布魯斯聽說有1位宅爸肩負全家6口的經濟重擔,家裡有4個正在「轉大人」的小孩,其中有1個是自閉症,還有1個是過動兒,但全家在混亂中透過另類的方式運作,孩子們會自動自發管理自己,不必爸媽操心。布魯斯既羨慕又驚奇,決定一探究竟,經過一番訪查後發現,原來宅爸是非常熱愛工作(或說中毒很深)的軟體工程師,竟然把全家老小編成「家庭團隊」,把親子關係當成專案來管理,宅爸把公司開發產品專案的遊戲規則拿回家用,這套方法就是敏捷式專案管理!

        學國際關係出身的布魯斯,立刻決定發揮跨界精神,把宅男宅女管理軟體專案的方法學起來,拿自己的妻小來做實驗,研發讓家庭和樂融融的密技。布魯斯沒有花大錢請顧問來做AS IS TO BE分析,而是把老婆小孩集合起來,先土製了一個簡易看板,全家一起規劃每日待辦工作清單(Morning Checklist ),接下來的每1天,2個女兒每天對著工作清單,做完1件就自己消掉1件,這樣過了1個星期,家裡吼小孩的聲音頓時減少了大半,受到這個實驗成功的激勵,布魯斯這一家人又把敏捷的定期展示會議,改造成家庭會議(Family Meeting),還參考敏捷軟體開發宣言,制定了自己的敏捷家庭宣言(Agile Family Manifesto)。布魯斯後來把自己家裡導入敏捷方法的點點滴滴,彙整成上百個最佳實務,寫成1本《快樂家庭的秘密》(The Secrets of Happy Families),這本書推出沒多久,就登上紐約時報暢銷排行榜前5名,也幫布魯斯寫下10年內連續6本書上榜的紀錄,也成為敏捷最另類的導入案例。
(本文作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®,以及台灣、中國兩地首位專案風險管理師PMI-RMP®)