BnosK是一間專門做technical writing服務的公司,同樣的公司在台灣或東亞範圍幾乎是沒有的,但能夠順暢運作的前提是,參與的公司都能正確的使用ticket system,並從中累積自己公司寶貴的產業知識和開發資訊。
先敘述一個真實見過的案例 --- 新創軟體公司 :
某公司裡面,開單系統內幾乎都是標題黨,為了應付老闆,都只有標題如
- 開會討論xx專案
- xx模組做refactor重構
- 設計UI
老闆看到這種情況,只能哀嘆自己怎麼把錢都浪費在這種員工和系統上。
正確的作法是訂立一個能反映真實貢獻的kpi,但這不容易。過去實戰有效的kpi可以綜合如下:
- 這個系統必須能形成一個互相監督的圓環,沒有高高在上不受監管的單位。一個單位的產出,正好是另一個單位業務內容的上游製品。
- 針對三個人以上的會議,必須減少。所有會議的決議或收穫,必須文字有所紀錄。
- 必須能讓未曾經歷過會議或該開發案的人,也能完整搜尋到整個開發的過程。
- 嚴格禁止人員以拉群聊的方式只用email或即時通訊留存紀錄或討論,必須能讓新人也能直接看到過去所有歷史。所有的討論都必須假設有個不在場的第三方能看到。
- 必須像貨運公司的出貨狀態 一樣,可以讓人知道該ticket目前的狀態是"等待、進行中、block, done" 等等
這種和稀泥的作法,到最後變成,出聲音的人或主管不需負責,每次都是說一套做三套,但大家的時間精力有限,這些做法往往都沒按照最佳解去進行,只是按照和稀泥的眾人決策去做,所以必定失敗。也因為這樣,每次失敗都沒有真正的罪魁禍首、事後檢討紀錄或錯誤分析也不會被寫下來,因為從一開始就沒有白紙黑字寫成ticket,曾經真正認真分析執行的人往往受不住這種風氣就跑了。公司只留下這些不受監管或削權的爛咖繼續浪費時間,繼續讓外行人掌權。
鴻海的老闆看的是尿尿有沒有變黃(喝水次數),新創的老闆看的是白板的多寡和ptt的精美程度(中國新創的ptt造車),公部門看的是有沒有準時打卡。我則是看到ticket system 開ticket和如何更新ticket的思維。
技術人員和非技術部門之間溝通的鴻溝太大,基本上是各做各的,平行宇宙。直到死線逼近,才開始壓迫彼此去產生交集。這是非常不好的現象。
- 東西決策或討論過程都不寫ticket,改以文件和死板號做紀錄。
- 因為寫文件太麻煩了,還要寫英文,乾脆寫個標題就好。
- 標題和內容不符合
- 時間越差越遠
- 老闆壓RD要生出文件
- RD救火都沒時間了,還要應付上第一線解釋非業務內的溝通,還要開發,還要被押時間
- 就算勉強生出一點英文了,很多人一看到是英文就直接按返回上一頁,不看或不願意去更新內容了
- 惡性循環
- 溝通更加不良
但可以打破惡性循環的方法如下:
- RD以熟悉的語言或方式做各種紀錄,只要允許別人更動或查得到 (不能只有自己查得到)
- 需要從頭到尾,要記錄的特別只要:
- 改了什麼
- 為什麼改
- 有什麼可能牽動的(之後會牽動的)
- 只要有開會,或是有討論發生,就必須記錄
- 占用詢問資源、開會越多的人,必須產出越多有用的紀錄
- Writer或pm去該處蒐集並了解全貌、比對細節中的矛盾
- 重構為文件
- 大家以產出的資訊量和正確性做kpi,而不是log time在ticket上
- 因為有diff功能在Jira / confluence上,所以這點很容易能看出來
- 也因為有history功能,大家會看到真實寫出有用或飛躍性新內容的人是誰,獲得普遍的認同和讚賞
- 交流因此更加密切
- Sales或FAE,從中提取重構造為適合對外的文件和文宣
目前我推薦小公司(100人上下)使用的開單系統,我會試試Trac (已經不再開發),或OpenProject。Jira太過複雜和笨重。Mentis醜。
對於已經採用jira系統的,則務必要學會JQL。網路上關於JQL詳細的操作教學並不多,這裡有個範例可供參考。
沒有留言:
張貼留言