我之所以會想開公司，是發現正確使用ticket system的力量，可以凝聚地理位置很遠的有才能員工，未來公司的定義，不應該是超九晚五前往市中心打卡，擠電車、冒險騎車、高速公路或市區塞車上下班洗澡睡覺的生活。
先敘述一個真實見過的案例 --- 新創軟體公司 :
某公司裡面，開單系統內幾乎都是標題黨，為了應付老闆，都只有標題如
老闆看到這種情況，只能哀嘆自己怎麼把錢都浪費在這種員工和系統上。
正確的作法是訂立一個能反映真實貢獻的kpi，但這不容易。過去實戰有效的kpi可以綜合如下:
這種和稀泥的作法，到最後變成，出聲音的人或主管不需負責，每次都是說一套做三套，但大家的時間精力有限，這些做法往往都沒按照最佳解去進行，只是按照和稀泥的眾人決策去做，所以必定失敗。也因為這樣，每次失敗都沒有真正的罪魁禍首、事後檢討紀錄或錯誤分析也不會被寫下來，因為從一開始就沒有白紙黑字寫成ticket，曾經真正認真分析執行的人往往受不住這種風氣就跑了。公司只留下這些不受監管或削權的爛咖繼續浪費時間，繼續讓外行人掌權。
鴻海的老闆看的是尿尿有沒有變黃(喝水次數)，新創的老闆看的是白板的多寡和ptt的精美程度(中國新創的ptt造車)，公部門看的是有沒有準時打卡。我則是看到ticket system 開ticket和如何更新ticket的思維。
技術人員和非技術部門之間溝通的鴻溝太大，基本上是各做各的，平行宇宙。直到死線逼近，才開始壓迫彼此去產生交集。這是非常不好的現象。
但可以打破惡性循環的方法如下:
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詳細的操作教學並不多，這裡有個範例可供參考。
留言
張貼留言
Please leave your comments. I will see them in mailbox before approving your messages and replying.