因為work from home的關係,本來以為公司終於有機會,能培養和強迫大家習慣正常開單的作業流程。但事情卻是往最壞的方向發展,就像是水往低處流一樣,只要沒有額外輸入能量的抽水馬達,大家就開始拉私群或倆倆口頭交代或隨時直接改db/source了,這種情況下寫文件變得更難,因為專案的實際進度或卡關之處,根本沒有人知道全貌或無法查核。以technical writer的情況來說,這可以說是噩夢等級的狀況,而公司繼續置之不理其實就是瘋狂在堆高技術債到了極限。
抱怨到此結束,正常情況下,開單並不是只有寫“我要做什麼”,而是很有技巧的排列表達理清自己的思路,為什麼我最後要選擇這麼做。所以開單的方式,其實是把無頭緒的過程理出來,用有限的選項裡面去提出子選項,最後走到達成該單標題所說的目標。舉例來說,主管說他要喝芒果冰沙,在今天下午兩點的時候。你是工程師(另兩個身份: QA, PM/technical writer的工作內容和方法之後再寫)就要去理清該怎麼在今天早上九點得知該任務需求的情況下,去製作出(未知份量)的芒果冰沙。
你得出這樣的分析:
原料 (2 options),製作,分裝
原料可以直接買芒果,或者買類似的芒果填料果糖 ,還需要冰塊(由於是碎冰加上沒設備,只能自己敲碎) 。原料的部分有三種,其中冰塊是必須的陪襯。你得在原始芒果和芒果口味填料之間做選擇,這是第一關卡,有兩個選項。接下來的製作與分裝關卡,也都各有幾種選項,舉例來說分裝有五個選項,製作有三個方法。
所以簡化的可能性總數其實就是 2*3*5 這樣,但其中會有種種限制或不可能存在,比如適合真芒果切丁的原料&製作路線一旦選擇,可能後面分裝就只剩兩種選項(舉例啦)
開單其實除了列出可能的選項和組合,讓其他人能知道你做了哪些評估或實際嘗試失敗,也能讓人知道你的思路弱點。盡量以二分法,y/n作為每個節點的選擇考量,這樣可以簡化真實的限制為“某個數字閥值以上或以下”。這可以讓後面的人更容易驗證你的作法以及萬一不夠好,可以在上或下的方向去尋找更適合的數值。就像是十分逼近法。
這些同時必須提供讓第三方去驗證或連入的資訊,比如特定source的連接密碼等。因為你想像不到的人往往是真實需要去驗證或使用的人。Technical writer其實就是把這些碎片般的思維和考慮過程曾發生過的誤區,系統性的寫下變成“正向”的思考過程和操作。
真實的世界,在開單系統裡面,其實是滿滿的挫折和無數的小成功。我們只能揀選出成功或被驗證為失敗的已知部分,去寫和完善知識庫而已。
各方的討論,已經思考過的和檢驗過的可能性,將會是開單系統裡面最有價值的部分。
各位可參考台北市政府對於道路房屋重建和建蔽率的這份開會紀錄,實際在開單系統裡面也是像這樣的情況。(一般正常的情況下,也會有人專責把口頭的開會紀錄打出來,誰決定或建議了ˊ什麼,其實就是這樣。但我實際體驗過每個公司的情況,反而是開會都在說空話,以及得避免講到重點或決策。與其對這樣的會議做額外的逐字稿,不如就直接在開單系統上說話算話。畢竟這樣的會議,管理階層往往沒有人想留下把柄或證據,那就不能正式作為輔助決策或討論的分析紀錄。這個會議,也就是沒有效力,只有形式的會議。)
留言
張貼留言
Please leave your comments. I will read them in mailbox and reply.