良好的ticket system、不開會不私訊、與台灣的產業升級

我之所以會想開公司,是發現正確使用ticket system的力量,可以凝聚地理位置很遠的有才能員工,未來公司的定義,不應該是超九晚五前往市中心打卡,擠電車、冒險騎車、高速公路或市區塞車上下班洗澡睡覺的生活。

BnosK是一間專門做technical writing服務的公司,同樣的公司在台灣或東亞範圍幾乎是沒有的,但能夠順暢運作的前提是,參與的公司都能正確的使用ticket system,並從中累積自己公司寶貴的產業知識和開發資訊。


先敘述一個真實見過的案例 --- 新創軟體公司 :

某公司裡面,開單系統內幾乎都是標題黨,為了應付老闆,都只有標題如
  • 開會討論xx專案
  • xx模組做refactor重構
  • 設計UI
這樣的ticket,甚至連請假都開ticket濫竽充數。完全沒有該工作的細部內容或改了什麼。
老闆看到這種情況,只能哀嘆自己怎麼把錢都浪費在這種員工和系統上。



正確的作法是訂立一個能反映真實貢獻的kpi,但這不容易。過去實戰有效的kpi可以綜合如下:

  1. 這個系統必須能形成一個互相監督的圓環,沒有高高在上不受監管的單位。一個單位的產出,正好是另一個單位業務內容的上游製品。
  2. 針對三個人以上的會議,必須減少。所有會議的決議或收穫,必須文字有所紀錄。
  3. 必須能讓未曾經歷過會議或該開發案的人,也能完整搜尋到整個開發的過程。
  4. 嚴格禁止人員以拉群聊的方式只用email或即時通訊留存紀錄或討論,必須能讓新人也能直接看到過去所有歷史。所有的討論都必須假設有個不在場的第三方能看到。
  5. 必須像貨運公司的出貨狀態 一樣,可以讓人知道該ticket目前的狀態是"等待、進行中、block, done" 等等
這間新創公司大約有八成以上的時間是浪費在"開會"和"私訊群"上,但是想透過每天三小時的開會,來凝聚共識和確定大家都理解相同,根本是浪費時間和搞錯重點。原因是,一群笨蛋或局外人的決策或避免得罪人的共識,並不是真正正確的作法。這只是為了避免出錯了可以不用負責的文化,因為沒有人做出決策或出錯後必須做負責補救。所有的決定和行動都是大家覺得這樣勉強可以打圓場,但根本不是該這麼做。我是到了這間新創,才第一次見識到這樣的日式文化。但諷刺的是,他們卻主打自己是美式作風。

這種和稀泥的作法,到最後變成,出聲音的人或主管不需負責,每次都是說一套做三套,但大家的時間精力有限,這些做法往往都沒按照最佳解去進行,只是按照和稀泥的眾人決策去做,所以必定失敗。也因為這樣,每次失敗都沒有真正的罪魁禍首、事後檢討紀錄或錯誤分析也不會被寫下來,因為從一開始就沒有白紙黑字寫成ticket,曾經真正認真分析執行的人往往受不住這種風氣就跑了。公司只留下這些不受監管或削權的爛咖繼續浪費時間,繼續讓外行人掌權。


鴻海的老闆看的是尿尿有沒有變黃(喝水次數),新創的老闆看的是白板的多寡和ptt的精美程度(中國新創的ptt造車),公部門看的是有沒有準時打卡。我則是看到ticket system 開ticket和如何更新ticket的思維。


技術人員和非技術部門之間溝通的鴻溝太大,基本上是各做各的,平行宇宙。直到死線逼近,才開始壓迫彼此去產生交集。這是非常不好的現象。


  1. 東西決策或討論過程都不寫ticket,改以文件和死板號做紀錄。
  2. 因為寫文件太麻煩了,還要寫英文,乾脆寫個標題就好。
  3. 標題和內容不符合
  4. 時間越差越遠
  5. 老闆壓RD要生出文件
  6. RD救火都沒時間了,還要應付上第一線解釋非業務內的溝通,還要開發,還要被押時間
  7. 就算勉強生出一點英文了,很多人一看到是英文就直接按返回上一頁,不看或不願意去更新內容了
  8. 惡性循環
  9. 溝通更加不良


但可以打破惡性循環的方法如下:


  • RD以熟悉的語言或方式做各種紀錄,只要允許別人更動或查得到 (不能只有自己查得到)
  • 需要從頭到尾,要記錄的特別只要:
    • 改了什麼
    • 為什麼改
    • 有什麼可能牽動的(之後會牽動的)
    • 只要有開會,或是有討論發生,就必須記錄
    • 占用詢問資源、開會越多的人,必須產出越多有用的紀錄
    • Writer或pm去該處蒐集並了解全貌、比對細節中的矛盾
    • 重構為文件
  • 大家以產出的資訊量和正確性做kpi,而不是log time在ticket上
  • 因為有diff功能在Jira / confluence上,所以這點很容易能看出來
  • 也因為有history功能,大家會看到真實寫出有用或飛躍性新內容的人是誰,獲得普遍的認同和讚賞
  • 交流因此更加密切
  • Sales或FAE,從中提取重構造為適合對外的文件和文宣

目前我推薦小公司(100人上下)使用的開單系統,我會試試Trac (已經不再開發),或OpenProject。Jira太過複雜和笨重。Mentis醜。

對於已經採用jira系統的,則務必要學會JQL。網路上關於JQL詳細的操作教學並不多,這裡有個範例可供參考。



沒有留言:

張貼留言