10 months ago

Q: 如何讓專案管理系統上的 User Story 可跟程式碼進度同步 (a.k.a 可驗收)?

這當中手續有點複雜,我從幾個原則開始說明。

Ticket branch 使用專案管理系統的票號命名

很多人是使用 gitflow 這個流程去管理程式碼,坦白來說我覺得「不夠用」(a.k.a 很難用)。因為實際上:

  • 你面對的隊友程度不同,所以 feature 切的 ticket 粒度也不同
  • 實務上遇到的狀況是隊友程度不同,狀況緊急也不同,很多時候你無法強求寫 test,一大包的 pull request 混在一起的 branch,沒有辦法做驗收測試 (也就是風險很大,因為就算綠燈,你也還要測使用者介面,然後一個豬 pull request 就會污染大家)
  • 喪失決策歷史。不是每個人寫 code 習慣都很好,且懂得寫好的 commit log,或者交代他為什麼要做這個 pull request。

所以我們的作法就是,拉 pull-request 的程度必須到 ticket level 等級,然後用 ticket 號碼為 branch 命名。這麼做的好處有幾個:

  • 大家知道這個 branch 為何而開
  • 討論決策在 issue tracking 上可以追朔得到
  • 該 branch 至少解決了「 1 個明確需要處理的問題」

單支 Ticket branch 要 deliverable

所謂單支 ticket branch 要 deliverable,是指很多時候,我們理想要在一個 branch 裡面解決一個 User Story,但這是不可能做到的。這在設計一整個 workflow,或者是要 Refactor 一整組功能時,最容易發生。

狀況一:Refactor

工程師 refactor 的很開心,測試也綠燈。送上去 deploy,爆得亂七八糟,然後其他人因為這組 pull reqest,被搞得此次 release delay 連連。

而 release manager 要是擋了這組 pull request,又會回退到大家不開心。

我設計的 policy 是這樣,即便是 refactor 一整組功能。也必須要遵守這樣一系列的原則:

  • 單支必須要過可以自動測試
  • 單支必須要過同事手動使用者測試,而手動測試不能佔到同事 15 分鐘以上的時間,否則就是粒度太大

也就是這隻 pull request 必須要小到直接 hotfix 上去也不能死人。

狀況二:開發複雜的功能

如果是開發複雜的功能,那麼原則,大 ticket 專注在驗收「流程」,小 Ticket 專注在「功能」。假設今天我們要實作一個 Markdown 編輯器,除了要支援 Markdown 語法之外,還要可以拖拉上傳圖片。那麼 Ticket 可以切成這樣

  • (1) 產生文章編輯器後台。(純 Text Field 與純 Text Area )
  • (2) 把 Ticket Area 掛上 CodeMirror
  • (3) 實作後台上傳功能,用 File Field 實作
  • (4) 把 File Field 重構成拖拉上傳
  • (5) 把拖拉上傳的 Event Listenr 跟 CodeMirror 掛勾

也就是先解決「可完成 workflow」的功能,然後再把每一個小功能當作是 bug,「修復」上去。

如此一來,所有的功能都可以獨立驗收。

工程部分的原則

這當中最重要的原則精神就是,就是一天至少 15 支 pull request,也可以放心的 deploy,不用擔心晚上需要加班救火。

客戶方面的結案建議

在前面一篇我們提到了第一階段要能夠實作 continuous deployment。是因為很多外包的客戶,對於自己外包出去的進度不安心。

用這樣的過程,你可以將驗收階段切成比較無風險的三階段:

  • 工程期間,只驗收 workflow 與基本功能
  • 驗收階段,驗收細節與 bug 修復
  • 美術階段,驗收 UI 細節

這三件事分開驗收,感覺雖然比較麻煩,但是對於雙方信任程度與金錢、法律責任會有相當大的加分。

系列文章

 
10 months ago

寫完創業團隊如何做專案管理。下一篇我要來寫的主題是工程團隊如何做專案與程式碼管理。以前我寫過很多調度專案的文章,但是執行細節我都沒有寫(a.k.a 不想寫 XD)。這一系列我希望解答一些常見的主要實作問題。

Q: 上 Issue Tracking 的 User Story 第一版粒度要切到多細?

這要分兩個層面來說。跟客戶簽約的 User Story 或者是工程團隊的 User Story。基本上是以 Interaction 粒度來切。

跟客戶簽約的 User Story

跟客戶簽合約的 User Story 的最小 Interaction 是 1-3 天。也就是 User Story 的粒度是切到剛好到 billable(在收費程度上無爭議)。(更細反而有爭議)

工程團隊內部時做的 User Story

假設這個專案只是內部的專案的話,那麼 User Story 的粒度是要切到 0.5 - 1 天左右,也就是要切到能

  • 粗抓大概工程時間線
  • 細抓到你可以找到工程 Risk 結點

大致上的專案規模

所以一個要做 2 個月的中型專案,大約上 issue tracking 之前

  • 與客戶簽約的 User Story 版本大概是 60-100 條左右
  • 自己內部開發的 User Story 版本大概是 100-200 條左右

結案大概會是 350 條 User Story 左右(含驗收)

Q: 收到 User Story 後要如何排定 Milestone?

我會用 Deadline-Driven + MoSCow method 的方式去排 Milestone。

  • 先將 1/3 的工期,預留給 deploy 收尾的 story (或者稱 epic,就是技術細節)
  • 再將 2/3 的工期,切成 3 段。

第一段:前期基礎

第一小段,做前期準備,比如說做

  • Continous Deployment 架構。讓之後隨時的工期都會有可驗收的進度
  • 找出高風險的 User Story,比如說信用卡刷卡需要先書面申請,先委託給其他單位去跑行政作業
  • 找出有多少頁需要進行畫面設計

第二段:主要工程開發

實作主線架構。這時候的重點在於

  • 完成主要功能
  • 無法完成主要功能的話,至少要能完成主要功能「User Story」的 workflow

這個階段的目的是,邊做邊盤點團隊有多少資源。同時藉由 workflow 的拓展,把下一步未知的風險出來。
這時候就可以透過 MoSCow Method 去對所有的 User Story 去做 Milestone優先權升降。

MosCow Method 將資源分成

  • Must have
  • Should have
  • Could have
  • Won't have

這階段應該專注於把 must have 的功能或者是 workflow 做完

第三階段:次要工程開發

完成了第二階段後,若有時間的話,接下來在這階段可以實作 should have

然後把 could have 的優先權,拉到驗收階段。然後誠實跟你的 Product Owner ( PM 或者是客戶)告白,won't have 就是 won't have 了。

驗收階段

因為我們留了一大段驗收階段的時間,這時候就可以心無旁騖的實作 could have

甚至是最後 finalize 的效能調校與 bug 修正。

Template

這是我以前的切票示範。

系列文章

 
10 months ago

小小的系列,總共六篇。

這一系列文章,其實也算自己的一個觀念掙脫蛻變。

我是一個從最底層工程師掙扎爬起來的創業者。從自己只是執行者,帶 1-5 個人、5-10 個人、10-50。小公司、大公司都做過。瀑布流、敏捷專案都經歷過。

我曾經認為公司成長不了是因為內部亂成一團,到處失火,所以跑去學專案管理。學成並精通專案管理以後發現,專案管理並沒有辦法救公司。甚至專案管理的極致,甚至會扼殺成員的主動性。

敏捷沒有辦法讓公司成長

我曾經也相信「一開始」就做好專案管理的規劃,是一個專案日後快速成長的關鍵。但我卻發現 Startup 的「機會」,是存在混亂與風險之中,而不是在完美的時程與 User Story 中。越規劃只會讓團隊越栽在「規劃」與「現實狀況」的掙扎之中。

最後我開始好奇,以前曾經相信的這些「假設」與「鄉野傳奇」是怎麼來的。

經過反覆的思考,我才越來越發現:專案管理是一個「工業化革命」下誕生的「名詞」。目的從來不是解決小組織的挑戰,而是「大組織確定命令後」,為了大幅加速命令執行速度的手法。

不管是「瀑布流」或者是「敏捷」管理。本質上還是只是「假設一個不知道當初時空背景以及誰下的命令」,「埋頭努力執行」的手段。「敏捷」本身並沒有大幅掙脫這樣的輪迴。只是讓中間的冗事被執行的機率被降低了。

所以大家還是能見到在 Startup 界聽到的真實誇張,卻不讓人意外的極端例子:「一個拿到投資的頂尖團隊,完美的執行敏捷手段,最後卻做出一個市場沒人要的垃圾」。

專注於「協作」而非「管理」

環顧世界上,更多產品能夠成長的團隊多半是這樣的狀況:

  • 亂七八糟半路自學程式的 Founder
  • 莫名其妙的打中市場需求
  • 雖然拿到很多錢,但是雇人非常謹慎
  • 很少聽到他們分享什麼專案管理的文章,但是卻可以做出厲害以及暢銷的產品體驗
  • 他們一直提到「同一價值觀」這件事

我從這一兩年來,深入研究成長這個主題後,才開始發現。原來「專案管理」這個技巧一點都不重要。更重要的是「專案協作」。

  • 管理指的是「控制人去做你想做的事」
  • 協作指的是「提供工具與基礎設施,讓眾人齊一往同一目標奮鬥」

總結

現在的這個社會,你越仔細觀察,越發現絕大多數的人,做事的方法是類似的:

  • 假定一個遠大目標
  • 制定高速成長的完美計畫
  • 招募一大幫「個體優秀」的團隊成員
  • 利用完美的敏捷技巧,快速達成當初的遠大目標

看似完美,但是最後會掉入相似的結局。不斷的投注完美的想像,最後無法承受現實生活中的挑戰,最後崩潰。差別只在於專案目標不同,成員名字不同。

很多人以為異軍突起的 Startup 成功都是機遇。事實上真的不是。他們都有共同的特點,與共同的做事方式。也就是在這六篇文章,裡面我提的方法會造成的結果:

  • 共同目標與價值觀
  • 互助扶持的同步
  • 專注於應對現實的變動,而不是成為一個完美稻草人
  • 找出正確以及有價值的 TA 與產品方向
  • 不再同樣的蠢事上犯錯

這才是 Startup 需要的做事手段與價值觀。

 
10 months ago

最後一招,就是進行 After Action Review。

我在之前的文章,也有提過 After Action Review 這套工具

What is After Action Review?

After Action Review 最早在大眾前曝光,是在 HBR( Harverd Business Review ) 上。這個方法也非常單純:

只有一組共三個問題:

  • What was supposed to happen? What actually happened? Why were there differences?
  • What worked? What didn't? Why?
  • What would you do differently next time?

在每次專案完工後,立刻做這件事。

為什麼我們需要 After Action Review?

不知道各位有沒有遇到一個狀況,公司做某件事很久了,老是出現同一個致命的狀況,漏水。但是因為犯錯的是某個你不能動的人,結果這個致命錯誤就一直繼續上演。首先是他,接著破窗效應,其他人有樣學樣。

為什麼這些事情會一再上演?因為在傳統的做事觀念當中,為了「人和」。每次專案有人當中搞砸了,大家要不是避而不談。不然就是承諾下次會改善,但從來沒有做到。

然後下次再發生時,每個人只是用情緒字眼,在事情當下時謾罵,平撫自己愧疚的情緒,等待時間沖淡。然後下次發生類似事情時,再重新輪迴一次。

After Action Review 透過對事不對人,並且以書面形式的檢討,強迫檢討改進。避免相同蠢事不再重複發生。

美國陸軍如何用 After Action Review

很多人以為 After Action Review 是 HBR 發明的,其實不然。AAR 最初發明的起源是美國陸軍。一般在社會中重複的犯錯,不會死人。但是在軍隊中,重複的犯錯,會死一大堆人。

美國陸軍發明了這種 Review 方法,防止了致命的錯誤一再上演。然後利用每一場戰役、演習後的 After Action Review 所產生的經驗與教訓,整理成冊。編輯成各種教戰指南與 SOP。提升部隊的戰力。

我們內部如何使用 After Action Review

  1. 首先,我們會針對每一次的事件挫折,執行 After Action Review。
  2. 可以 quick win 的東西先修正。
  3. 接著再針對沒有辦法一時之間的修正,檢討是否跟 NPS 重疊,來決定執行的優先權。
  4. 改正的方法紀錄整理回去變成 SOP。下次執行同樣的活動時,用 SOP 照表跑一遍。

Summary

很多人往往以為「成長」,就是去學習快速前進的方法,大步前進。

事實上這樣的「仙丹」非常罕見。

事實上「成長」還有另外一種方向,當別人一直無法克服的輪迴,你能掙脫並且往前,這也算成長。而這件事,非常困難。用了 AAR,它能幫助你加速突破。

系列文章

 
10 months ago

第五招是,根據 NPS 改進產品

NPS 是什麼?

NPS 全名是 Net Prmoter Score,用大白話翻譯是客戶願意幫你傳播的分數。NPS 被譽為在 Customer Success 界的聖杯問題(The Ultimate Question)。

如果你只能問客戶一個問題,那麼問這個問題就夠了。我在以前的文章有談過這個指標

為什麼要根據 NPS 改進呢?

Startup 有千奇百怪、堆積如山的改善 feedback 需要做。但是 Startup 也意味著資源稀少。不可能什麼人什麼角度的 Feedback 都照單全收。

如果照單全收,團隊可能面臨兩個下場

  • 加班加到死也做不完
  • 產品改成四不像

如何利用 NPS 聚焦?

NPS 把顧客分為三種人。一種是正面口碑傳播者,一種是中立者,一種是負面口碑者。

利用中立者改善產品

  • 中立者是正確的 TA
  • 但是你的產品發生了一些小差錯
  • 讓他們不願意主動傳播

如果你可以讓這些顧客主動傳播。那就再好不過了。產品需要成長,而這些「小差錯」就是會妨礙你成長的真正原因。

捨棄負面口碑者,切割市場

每一個產品都有適合他的顧客與市場。但創業者通常會很貪心,通通想要。但事實上你不可能迎合所有階層的顧客與口味。如果通通照單全收這樣的建議,產品只會被改到四不像。

比較好的做法,是在這個產品線中,大膽捨棄負面口碑者這個客群。

這個產品的這群人,不是你要的。你也不需要因為他們的意見改進這個產品。

如果你真的很想要這群人,你應該再開一個產品線賣給這群人。

比如說你的桌子做得很好,客戶希望桌子內建椅子,你試做了這個 prototype,反而引來惡評。那麼這時候,你不應該是繼續強化內建椅子的這個功能。而是推出單獨的椅子產品,去搭配這張桌子。如果把桌子產品改成內建椅子產品,你只會失去桌子族群,而且把你的 TA 狹小到那群「需要四不像」產品的顧客。

系列文章

 
10 months ago

第四招是,每日執行 Standup Meeting。

坦白說,這是我認為這四招當中最重要的一招了。當你的公司如果只有兩個人,什麼都可以用口頭交代的方式。但是一旦成員到達三人以上。就會發生溝通不良,或者短期目標不一致所以導致執行優先權狀態不一致的狀態。

Agile 專案管理中的 Standup Meeting 可以很好的解決這一個問題。

What is Standup meeting ?

Standup Meeting 是一種團隊例會,長度只有 15 分鐘,也只能有 15 分鐘。在開會時每個人都必須保持站立。(防止有人太囉唆)。這個會議強制各位同事參加。

每個人在會議中都要依序報告三個規定的問題:

  • 昨天我完成了什麼
  • 今天我要去完成什麼
  • 在過程中遇到了什麼樣的阻力

Why we need Standup Meeting?

抓出腳步不一致的人(當然這不是主要重點)

感覺回答這三個問題很容易對吧。非也,如果是對充滿幹勁的人來說,回答這三個問題超容易。但是對於偷懶或散失鬥志的人,超級難。對於偷懶的人,編造這三個問題超級困難。

P.S. 這裏有兩個訣竅

  • 絕對不允許同事在 Standup 前臨時請假翹班
  • 不要因為貪圖快速,而允許「只用軟體」線上 Standup,這樣大家只會拿到一堆假的濫竽充數互相自慰的報告。

聚焦

從大家的 Standup 大致上就會發現,這一週大家的重點與優先權是什麼。需要協作的狀態是什麼。而不是大家無頭蒼蠅一樣在忙不同焦點的專案。

互助

Standup 不是跟老闆回報的會議,也不是回報同事互相監視的會議。而是一個「互助」會議。

在這個會議裡面,關於專案的進度,大家應該要誠實回報,沒有做、或做砸都沒有關係,重點是我們可以修補彌補這件事。自己不擅長沒關係,遇到專案阻力,也許同事也不同的想法以及專精可以幫助你解決眼前的問題。

畢竟快速往一致的目標前進,才是這個團隊需要的。

我們團隊怎麼做?

我們團隊目前的方式是:

  • 每天下午 1:30 Standup Meeting
  • 用 Hackpad 在 Meeting 之後記錄 Standup meeting 內容。

Hackpad 格式是:

  • 昨天與今天我做了什麼
  • 今天預計要做什麼
  • 今天我做的東西遇到什麼困難需要別人幫忙的點
  • 明天我預計要做什麼

當作寫日記一樣。

這樣的好處是當翻到前幾天日記的時候,你很容易回憶起幾天前我們做了哪些事情。

系列文章

 
10 months ago

我在創業日子裡面體悟最深的。就是在大公司裡面,做一件事情你擁有有無限的時間與資源。但是在小公司裡,你可能只有三天時間以及一個人手。

我以前熱愛打 Hackathon,我在打 Hackathon 這種需要嚴密調配資源的遊戲裡面,鍛鍊出一種做專案的 mindset 與實踐的方法。具體分為兩個步驟:

Deadline-Driven Planning

小公司的專案裡,通常只有 Deadline 是明確的,其他結構全部不明確。而且 100% 的情況,你不會有任何時間資源去「按照順序去規劃並完成所有你想要完成的事」。

這是跟在公司裡面「假裝敏捷」有很大的差異。按照一般公司的步驟在創業公司裡面做專案。常常會出現「手術成功」,但「病人已經死了」的悲劇。

而且後來,我更進一步地發現,絕大多數人會搞砸專案的原因,往往是因為資源太多,而非太少。如果你把時間抓得非常緊迫,那反而會逼出人類的危機感,自動過濾出「哪一些是是真的該做的」。

就跟期中交作業,期末準備考試一樣的原理。缺少時間,人類自然就會自動按照危機感把該做的事自動做有效的劃分。

所以我在 Startup 裡面執行專案的方式,是把每一個案子都當作 Hackathon 在打一樣。利用 Hackpad 盤點資源,然後用 Deadline-Driven 的方式,把看似無盡的時間與資源,切成幾塊有明確的時間區塊。

每個時間區塊有自己的 KeyResult。這樣就能確保不至於有太大的超時。

MoSCoW method

接下來我會將 Key Result 再次區分,用 MosCow Method 排優先權。

MosCow Method 是把所有的需求照

  • Must have
  • Should have
  • Could have
  • Won't have

的方式區分。

MosCow Method 配合時間倒序的專案管理方式特別有效。如果是用正向順序進行專案管理,人們往往會將需求通通定義為「Must Have」。

而如果將 Key Result 鎖在在有限的時間內,反而會迫使人們去決定重要順序。所有人的精力只會 Focus 在 Must have 與 Should have。

團隊可以在很短的時間,不拖泥帶水的取得 MVP 與 small wins。這正是 Startup 最需要的戰果。

系列文章

 
11 months ago

目標有了。接下來我想談步驟。我覺得創業公司第一件該做的事,是要導入 OKR。

什麼是 OKR 呢?

知乎上有一篇文章,把 OKR 的原理解釋得非常詳細:https://www.zhihu.com/question/22471467。這裏我就不花篇幅照搬運一次了。

這裏我只歸結重點。

OKR

  • O 是 Object 目標
  • KR 是 Key Result 關鍵成果
  • 將公司階段目標「量化」
  • 具體聚焦公司當下最重要的大目標
  • 下層執行者具體「承諾」自己為了完成「組織大目標」所要完成的「個人工作承諾小目標」。

OKR 是為了指出公司成長北極星

為什麼引入 OKR 是第一件事,也是最重要的事?

創業公司最需要的就是聚焦。創業階段是一段非常混亂的時期。創業團隊會同時

  • 湧入太多的機會
  • 湧入太多的員工
  • 產生太多的方向

眼前有一萬件事情要解決,但你卻只有 5 個人。

如果團隊不聚焦,很容易就被自己人踩到或者是殺掉。

創業跟在公司「上班」也非常不一樣。在「公司」你總希望事情平順進行,在創業每天都會有驚嚇。保持同一個方向前進變成是很困難的事情。

OKR 就是用來確保這個團隊裡,至少 1-3 個月內,大家的成長目標是一致的。而且不是漫無目的的 bullshit,而是實際可量化的指標與方向。

系列文章

 
11 months ago

在這篇文章裡,我要來談:「在創業公司裡面如何做專案管理」。這是一篇我認為難度很高的題目。

當然,在幾年前的我,是根本不這麼覺得的。甚至大部份熟 Agile 的 RD 都不會這麼覺得。不就是 Lean 嘛、Agile 嘛,少掉公司內囉唆的規格而已。

Agile is not completly for "Startup"

後來我自己在創業過程中,也不斷的思索這些問題。但想來想去,總覺得現有流行的敏捷管理,套在 Startup 的模式裡,總是怪怪的。甚至一些精闢的敏捷經典文,立論沒有錯,但是在這樣的場景內,總覺得哪裡歪了。

後來我理解到這樣的幾個現實,為什麼我會覺得他們歪

  • 現有的敏捷開發,誕生的環境不是為了「Startup」。是因為一定規模的公司,人太多,為了改良使用「傳統瀑布流方式規劃專案」,提出的新架構。「增加效率」「減少浪費」。
  • 大部份的敏捷提倡與實踐者,是 Engineering 部門的人。這些人跟「真正市場」與「付錢的真正用戶」非常的疏離與脫節。也許敏捷可以快速迭代成「他們想像的產品樣子」。但是做出來的東西,沒有滿足市場上任何人的需求。
  • 既然都請得起 Engineering 「部門」。那麼這間公司定義不再是 Startup。而是 Company
  • 專案管理本身的其一目的是「消除風險」。而創業處處都是「驚喜」與「風險」。未知的機會與市場隨時會把你帶向另一個高峰。如果你真的在 Startup 做了非常好的的(so-called)「專案管理」,恭喜你,你的創業公司也離死亡不遠了。最常聽到的是技術團隊創業的公司,"Doing Perfect Agile" 卻把自己管到死掉了。

這就是為什麼我覺得「創業公司 Startup 如何做專案管理」是一個難度很高的主題。

For Growth, not for Risk Management

但是很多 Startup,還是非常希望引入「專案管理」,主要是太多的混亂、與眼前的機會爆發,反而把前進腳步打亂了,到了一個某一個臨界點。原本知道怎麼做把 MVP 做到 pre-PMF 的 Founder。反而不知道怎麼再繼續走下去了。

這時候就會面臨下一個問題「繼續維持高成長,但是公司不再混亂」。這就是我在這篇想要談的目標。

在這裡我有一個目前歸納出的重點:在創業階段的專案管理

  • 不需要傳統專案管理的「風險管理導向」技巧
  • 需要的是「成長導向」的專案管理技巧

系列文章

 
11 months ago

有很多人問在軟體界, Growth 與 Marketing 有什麼差別呢?

我覺得可以從三個角度來論述切割。其實這一篇也是在講 Growth Team 的職責守備範圍。

1. Brand 品牌

首先,「品牌」在傳統產品以及 Marketing 中,是相當重要的。你會圍繞著「品牌」這個核心進行行銷( Marketing),進行Branding、PR、Event 等等。

而消費者會固定消費固定一間品牌公司產出的牙膏、肥皂、等等等等等。

但是「品牌」在「軟體」行銷世界中,其實重要性「沒那麼高」。

消費者在軟體世界的行為 pattern 裡面其實不太會理會「品牌」這個元素。而 Branding、PR、Event 能起到的作用也沒有那麼高。

2. Growth Marketing 技術。

以前做 Marketing 的行銷效果是很難被量測的。

而現在 Growth 有一大塊的執行與操作手法在講:如何更精確的量測「效益」以及「影響」層面。
用「最有效率的方式正確執行」。

這部分跟我們在第一段講的圍繞著品牌做行銷,手法與結果非常不一樣。

3. Growth Product

實作「產品」的哪一個部分,對於成長能夠造成巨大的影響。

NUX ( New User Experience)、Viral、Referral、Share 等等。

而成長團隊主要在做什麼呢?品牌是絕對不在 Growth Team 的守備範圍裡面。

Growth Team 的負責範圍,只有

  • Growth Marketing
  • Growth Product

這也是 Growth 與 Marketing 的界線所在的地方。

 

宣傳連結

  1. 免費 Rails 學習手冊

    Buy Rails 101
  2. Intro to Growth Hack


    Growth GrowthSchool

    預購 8 折 中