搜尋此網誌

工商服務

2014年8月25日 星期一

Facebook 第 30 號員工 Noah 從照顧小孩的 4 天當中所學到的 9 堂經營管理課

↑ 我與老婆大人抱著兩位想睡午覺的兒子們。( 2014 年 8 月攝於宜蘭幾米公園

一直以來,我都很好奇人們如何兼顧事業與家庭,比方說如果白天要上班,然後晚上下班回家還要自己照顧幼兒,他們的生活是否過得一團糟呢?我除了想聽聽別人訴苦,也想尋找解決之道,畢竟在我自己的經驗裡,要兼顧真的非常不容易。時間分配經常出問題,有時候工作多做一點(犧牲了陪伴小孩講故事的時間),有時候家事多做一點(哄小孩睡覺,結果自己也睡著了),無論是哪一種情況,最後同樣都令人感到沮喪。

上週在信箱裡面收到一封電子報,講的正好就是這種情況。標題是〈 What Babysitting Taught Me About Business 〉,作者 Noah 曾經是 Facebook 的第 30 號員工,現在則是自己創辦的 AppSumo 的執行長。最近他自告奮勇幫哥哥照顧 6 個月大的嬰兒,在那 4 天的時間裡面,他學到了 9 件事。簡單翻譯和摘要心得如下:

1. 時間有限,促進生產力提昇

只有在嬰兒睡覺時才有辦法工作,所以在那個片段的時間裡,必須非常專心,待辦事項依照優先順序完成,生產力於是大幅提昇。同感:弄完小孩、做完家事,往往忙到沒時間滑手機、玩臉書。

2. 有益的事,就盡量多去做吧

把嬰兒餵飽一點,他就會睡得比較久,照顧者也就可以有比較多的時間可以做自己的事。啟發:如果某個方法對於業績有幫助的話,就多多益善吧。

3. 解決問題,只用最簡單作法

嬰兒不會說話,他們只會哭,然而哭的原因不外乎:餓了(餵他喝奶)、尿布髒了(換尿布)、想要抱抱(抱他)。啟發:事業上遇到的大小問題,往往也都能夠從根本用最簡單的方法解決和滿足。

4. 拋開成見,判斷才不會失真

如果看到有人對著幼兒吼叫,想必會覺得照顧者很可怕,直到你自己也照顧幼兒,才知道原來真的有太多事情會讓人想抓狂。啟發:無論是在面試員工、跟客戶溝通、跟員工開會,都應該盡量拋開成見,多設身處地為他們著想。富有同理心往往可以讓事情進展得更順利。

5. 看書之外,也可嘗試用聽的

呼應第 1 點,因為陪伴幼兒的時間變多了,於是自己可以自由運用的時間就變少了。如果沒有時間看書,那麼不妨利用推著嬰兒車散步的時候,聽聽有聲書或者 Podcast 。啟發:創業家必須不斷地學習,精進各項技能。

6. 善用授權,不需要事事親為

忽略不重要的事,那些事你總是可以找到別人代勞。同樣呼應第 1 點,因為時間有限,所以你只能夠從待辦事項清單上面優先順序最高的那幾項開始做。啟發:從經營事業的角度來看,意味著你必須清楚知道哪些東西可以真正為你帶來獲利,而哪些東西可以外包或授權給別人去做。

7. 顧好自己,才能照顧好別人

如果沒有辦法照顧好自己,就更不用說要照顧好幼兒了。啟發:維持運動習慣,運動可以帶來活力,幼兒也可以因此獲得更好的照顧。

8. 突破極限,資源少也能做事

既然許多方面都被牽絆住了,就要接受並且調適。例如想辦法一隻手餵奶,另一隻手敲鍵盤。啟發:就跟經營事業一樣,資源經常很少,但是業績目標很高,因此時時刻刻都要想盡辦法突破現況的侷限。

9. 多拍些嬰兒照片,人們超愛

人們都愛看可愛的嬰兒照片。啟發:經營事業也一樣,應該只給客戶們喜歡和感興趣的東西,背後的辛酸故事通常他們並不見得想知道。

讀後感想就是,作者 Noah 的 9 點裡面有 3 點和「時間不夠」有關,可見大部分的幼兒照顧者都很介意這件事。或許奇步應用可以從開發優化時間管理的 App 這方面來發想點子,科科!

2014年8月8日 星期五

〈 Deliver Project on Time 敏捷專案管理實務〉聽課心得

↑ 專注講課的 Xdite 以及上課講義。


↑ 午餐 Buffet 和下午茶點心以及無限供應的汽水。

◎時間: 2014 年 7 月 25 日 10:30-16:10
◎地點:台北 CLBC
◎講師:鄭伊廷( Xdite )

7 月底自掏腰包跑去台北上了知名 Ruby on Rails 開發者 Xdite 的專案管理課程,試圖尋找一種解藥,來平衡我目前白天要上班、晚上要帶小孩、然後還要營運奇步應用的這種忙亂生活。聽完課之後,也果然有了一些想法和具體作為(列在本文最後面的結論裡面), 無印良品 A5 尺寸的筆記本寫了 3 頁滿載而歸。

我當天搭 9 點的高鐵到台北,是第 1 個踏進上課教室的學員(從現場安排的座位數目來看, 7 月班這個梯次的學員大約 20 人,人數約前兩個梯次的一半)。早到的好處就是可以選擇坐第一排,與講師有最多的問答互動。當天也果然讓我有機會對話了幾次,詢問了 4 、 5 個問題, Xdite 有問必答,而且是經過實務經驗淬鍊而來的答案,聽來格外受用。

基於對頂尖講師(她曾在多場國際 RubyConf 研討會開講)和頂尖開發者(也曾榮獲 Facebook 2012 World Hack 全球首獎)的好奇,我稍微觀察了一下 Xdite 。她戴著超厚的眼鏡,頭腦思路清晰、回答問題的速度超快,投影片沒有標題、只有白底黑字,也沒有使用控制上下頁的簡報筆,穿著 T 恤、短褲、便鞋,一個人就搞定整天的課程和 Q&A 了。

整堂課分成 3 段,每段各約 1.5 個小時。第 1 段是早上 10: 30 到 12:00 ,講的是用戶故事( User Story ,針對操作情境的描述);第 2 段是午休後的 13:00 到 14:30 ,講的是專案管理和 Issue Tracking 的技巧;第 3 段是吃完點心後的 15:00 到 16:30 ,講的是 Redmine 這套專案管理工具。

也許你並不是真的打算導入 Redmine (基於 Ruby on Rails 的 Open Source 專案,在台灣 Ruby on Rails 社群大概花費新台幣 3,000 元可以找到人從無到有搞定,或者國外也有租賃服務,月租費大約新台幣 700 元),但是在 Redmine 裡面所運用、所延伸的專案管理技巧是放諸四海皆準的,所以仍然有極高的參考價值。

許多公司導入專案管理系統之所以失敗的原因,就在於 RD 根本不知道做某些功能的緣由。所以「 No Story, Only Tickets! 」是不可行的。這裡的 Story 就是 User Story ,而 Ticket 則是專案管理系統中的任務執行單位,所以才會有「開票」(在管理系統上建立一張描述和指派任務的 Ticket )和「切票」(將大的功能細切成較小的容易描述和執行的 Ticket )等說法。 PM 在規劃功能的時候,必須輔以「 User Story 」,以便把功能拆出來。

聽到這裡有個空檔,於是我舉手問了第 1 個問題:是否會將 User Story 作為合約的一部分,或者單純只是作為開票的輔助? Xdite 回覆說:兩者皆是,大型接案公司都這是這麼做的,也就是 User Story 既是合約的一部分,也是專案管理工具開票的依據。關於專案報價和時程的估算,以 Pivotal Labs 的模式為例,他們會先切 User Story ,接著評估實作時間,最後才報價。這個過程中首先派去和 Product Owner (客戶)進行需求訪談的是 PM ,然後才是資深工程師。

有趣的是, Pivotal Labs 在合約上不會保證在 Delivery Day 之前要完成哪些功能,只保證會集中火力盡量去做(根據講好的優先順序來完成功能項目)。形同租用員工給客戶,簽的是「時數約」。台灣少有這樣的公司,除非公司夠強,不過 Xdite 的公司向來是這樣簽約的。另外如果到了 Xdite 出馬但是談了 2 次還無法簽約的客戶,她就會選擇放掉,因為有時候客戶只是藉此機會進行比價而已。

在簽約技巧方面,複雜的、非主要的、需要花時間 Survey 的功能,不要簽入主約,放在附約就好。

關於 User Story 的撰寫,基本上是以「角色」為導向的,由角色的觀點出發,寫出有價值的功能和需求。其句型是:誰需要什麼來完成什麼。例如:老闆要能夠透過後端網頁看到訂單數量、客戶要能夠使用信用卡結帳。

User Story 通常要發展到第 7 或第 8 版左右才算是最終的版本。每則 User Story 的時程大約 1 個禮拜( 5 天,每天 5 個小時),包含實作、套版、測試,由整個團隊共同執行,團隊裡面包含 Senior 和 Junior 工程師。當然票還是有分簡單和複雜的,所以通常是 Junior 三張簡單的,然後 Senior 三張複雜的。

現場有做 15 分鐘的習作, Xdite 要求學員將一個第 3 版左右的「線上商店」 User Story 拆分發展到第 6 版左右,票瞬間多了 3 倍的量。舉例而言,光是「身為消費者,要能找到商品並結帳」這項就至少可以拆分成「消費者要能搜尋商品」、「消費者要能產生訂單」、「消費者要能用信用卡結帳」等比較細的票了。

切記一點,不要讓 Product Owner 用仿真畫面來討論,因為會沒完沒了。 User Story 加低保真草圖( Low Fidelity Prototype )才是王道!初期不應該被 PhotoShop 繪製的設計圖來引導,那是套版階段的事情。 Xdite 說她不接這種客戶,因為太危險了。

另一方面, RD 若要避免被賣掉,應該主動參與 User Story 討論。

User Story 有所謂的 SMART ( Specific 明確、 Measurable 可量測、 Achievable 可實現、 Relevant 切題、 Time-boxed 時效性)撰寫原則。課程當中舉了幾個例子,像「 User-friendly 」這樣的字眼就太過主觀了,不符合 Specific 和 Measurable 原則,而「 要像 Google 一樣」也有同樣的問題,其實 Product Owner 想講的應該是「搜尋功能要有一邊輸入、一邊補完的 Auto-complete 功能」之類的。

除此之外, User Story 本來就應該邀請(甚至強迫) Product Owner 進來一起討論,一起使用專案管理工具(例如 Redmine )。但是這麼做又怕太過於透明,所以不想給 Product Owner 看到的東西,就開別的版去討論。原則上大部分的東西都可以讓 Product Owner 看,除了技術細節、人力分配、金錢、工時之外。

題外話, Xdite 在回答學員問題時透露,在她的公司,所有員工都是一起吃午餐的,這樣可以凝聚向心力,而老闆也可以知道大家的近況。

另一方面,票與票之間難免有前後順序或者可以同時進行的關聯性,為了避免卡關,也為了讓後續的相關功能得以完成,可以先做一些不實作商業邏輯的假按鈕,例如「以信用卡付款」按鈕按了之後會產生訂單但是並沒有真的進行結帳動作。

Issue Tracking 系統還可以用來分享讀書心得的筆記,在 Xdite 公司的 Wiki 上,甚至看得到公司搬家(因為生意興隆,所以辦公室越換越大的緣故)要拜地基主的標準流程。

在 Redmine 的操作上,不一定要使用子母票,切勿因為想要巢狀而巢狀。初期只有母票(樹枝)無妨,之後再慢慢長出子票(樹葉)。此外有技術細節的樹,也應該要有用來測試和驗收的樹,前者可能有 500 張票,而後者則有 100 張票。

吃完下午茶點心之後,進入本堂課的最大賣點,也就是 Xdite 分享參加 Facebook World Hack 2012 並獲得首獎的經驗,故事高潮迭起而且可以學到很多實用技巧,鼓勵大家去上她的課,在此就不贅述了。關於這次獲獎的報導,可以參考 Mr. JamieInsideT 客邦的文章。

最後再回過頭來看一下課程名稱《 Deliver Project on Time 》,到底 User Story 對於專案準時上線有什麼幫助呢?因為好的 User Story 可以幫助開出準確的票、分配準確的人力和時間等資源,進而估算出準確的時程。而時程知道了,專案自然準時上線。 Xdite 說他最高記錄是一次(還是一天,我忘記了)要管理 150 張票,哇賽!

上完這堂課之後,我決定:
  1. 把與客戶討論出來的東西寫成 User Story 當作合約附件,同時也當作驗收的標準。
  2. 儘管奇步應用目前只有兩人規模,但是還是要想辦法導入專案管理工具。
★強力推薦:來去 KKTIX 查看 Xdite 公司的所有課程
★工商服務:來去博客來購買無印良品 A5 尺寸 96 頁筆記本
★工商服務:來去博客來購買《笑談軟體工程:例外處理設計的逆襲》
★工商服務:來去博客來購買《笑談軟體工程:敏捷開發法的逆襲》