※ 引述《karst10607 (新陳代謝)》之銘言： : 最近公司的主管突然想到 : 我們應該要去搜尋世界各大科技軟體公司使用的文件管理工具 : 才能跟上面報備我們的tool chain應該怎麼更新或列出明確使用規範 : 比方說我們用confluence, jira, google doc, slack, github : 可是沒有規範大家必須把什麼樣的資料記錄在confluence，於是資訊會四散 : 回報會出現在spreadsheet或g doc的某個comment裡面之類的 : 不回報到特定jira或負責人，或是回報故意模糊，其實就是要甩鍋的節奏 : 這很正常，但公司已經到了有點無法管理的狀態了 : 我跟主管說，可是其他公司怎麼用各種軟體管理工作流程應該算是它們的機密耶 : 但主管執意說就是要去上網蒐，不管你用什麼方法 : 其實就是暗示你用自己的人脈和過去的經驗去挖 : 我說有三個合法的辦法，就是上網搜尋比如某工具 + 抱怨功能 : 第一招: 比如 SDL + search : Confluence + search : 就會看到某前公司的職員抱怨分享以前在哪任職時公司內的文件工具或作法如何 : 比如有人開單超級懶，用對話截圖取代打字或code snippet，結果單當然都找不到資訊 : 因為沒有ocr，這些單資訊都是空的 : 第二招: : 公司如Atlassian會瘋狂用客戶幫自己軟體背書 : 都是講轉移到自家服務，但其他細節或使用方式都不會多說 : NASA好像也是他們客戶 : 第三招: : 根據過去某些公司招人時，留下的使用工具等公開資訊 : 類似新聞或徵才條件 : 比如boeing公司的工程文件新聞 : 我確實是可以分享過去面試的時候，或是任職的公司怎麼管理文件 : 但我比較擔心這會有什麼營業問題嗎? 即使並沒有顯示的內容開發機密 : 我的工作就是做這方面的，所以有一些經驗 : 但日商文化就是: 先輩就是官，官大學問大， : 台商有些偏製造業的會有DCC (document control center) : 資料只進不出，只更新不刪除，標示過期作廢而已 : 但偏軟體的通常不會是這種模式 : 各位先進會建議我怎麼做? : 要認真做不是不行，只是每次都要用職業道德和職業生命當底線，有點討厭 : 題外話: 今天經過一間古本行，發現原來日本的出版文化很像抵抗焚書坑儒的精神 : 當時只印刷千本的照片或報導，其實是為了數十年後被挖掘出來的實體證據， : 因為主流大眾媒體是不斷被政府和企業在進行操弄和刪除報導的 : 反過來，也有些報社和出版社，即使在被摸頭的情況下，依然刻意留下蛛絲馬跡給後人 : 一方面是為了自保，另一方面是為了銷量 : 如果身處這樣的社會，也許會覺得只要有耐性，什麼都能被找出真相 : 但資訊軟體業，即使用git還是能甩鍋的，關鍵的描述不計入就好了... 根據過去經驗，我看到比較好順的做法是， 將部門文件資產，分成四類管理： 專案管理：可用Jira，或類似工具。 文件管理：可以用 FTP or NAS。 code：各種git工具。 知識管理：可用confluence，或類似工具。 工具不太重要， 你把Jira換成office 356上的excel也可。 你把confluence換成 gitlab wiki也無所謂。 你把文件管理換成Windows網路分享資料夾也可。 重點是 如何將整個產品生命周期的重要文件，重要知識，都可管理起來。 以一個產品功能的整個開發流程為例： PM先與團隊的 Technical Lead討論某個功能是否的技術上可做。 確認可做，討論一下優先權與工作量。 接下來，PM會用Jira先把使用者需求， 拆成Epic或 story，或Scenario。 不夠細的story再拆成小的story，直到這個story可在一個版本周期內開發完。 也就是保證每個story都可在固定時間內關閉。 工程師壓力也小。 這個story就是，PM，tech lead，開發者，測試，共同交流的地方。有疑問，完成什麼，只要是需要被記錄與的全在此討論。 如果是閒聊專案，不需要紀錄的，就用即時通訊講一下就好。 所以專案的需求，開發，測試，紀錄全部可管理起來，可搜尋。 開發前，tech lead會寫規格書，xxx系統1.0.4版，系統設計。然後透過系統規格書與大家討論做法。並分配工作。 這種產品設計規格書，產品release note，deployment 手冊，會統一放在一個部門專門的FTP或NAS管理。因此，你要看整個軟體產品發展歷程，設計文件，每個版本都有。 開發人員就開發程式碼，利用git管理程式碼版本，分支。git工具通常會與CI/CD工具結合，控管大家上傳程式碼品質。 我以前待過的公司，每天還會自動啟動CI流程檢查每天的程式碼，因此，大家程式碼修改可追朔，程式碼品質可管理。 管理上，不允許上傳CI不會過的程式，每日自動CI沒過，不能下班。否則影響考績。不會有人為了應付，上傳不可run的程式。 CI過了以後，才會有code review。 code review，很多人只做，程式碼有沒有bug的review。但真正有在知識管理的公司，還要確認程式碼風格，架構，不要有只有一個人看得懂的 magic number… 由於CI/CI流程有接jira。所以CI有沒有過都會更新在story或issue，確保大家都能同步知道現在程式碼狀態。另外，Jira也有綁mail通知功能，所以有緊急重要的事情，都可以不上Jira就知道。 接下來是技術知識管理。 很多解bug的流程，常常犯的錯，系統性能瓶頸，為什麼上線了會有bug，當初技術選澤，survey技術或產品的文件…這些用一個知識管理交流系統存放。例如confluence。 不管是專案的市場survey，需求的技術選型，debug過程，只要是對別人有幫助，管理者都要求要寫，要放在知識管理系統中。知識管理系統最重要是能全文搜尋就好，讓人方便搜到過去人的經驗。 當初我前公司還規定與鼓勵，根據職級不同，每半年要求不同的篇數，來保障資深人員不要只出一張嘴。要寫文件傳承知識。然後沒達篇數低標的扣分，每季會評選好的文章做獎勵。 整個流程包含，四大類工具： 專案管理：可用Jira，或類似工具。 文件管理：可以用 FTP or NAS。 code：各種git工具。 每間公司文化與流程不同，應該是先去盤點自己公司軟體生命週期，該做什事情，各階段該產生什麼產出物，來決定適合工具，而不是照別人公司的建議照抄。 再談談到管理： 工作那麼累了，同事又彼此藏東西亂坑人， 我幹嘛要去記錄，分享這些記錄，文件，知識？ 我是從來沒看過一個組織，不靠管理， 能自動自發做好這些啦， 是我，我也模糊紀錄，應付文件，到處藏經驗啊。這樣我才輕鬆，我的考績才會好。 我待過的公司，大部分都是失敗的，即使號稱走CMMI ,L4的組織也是失敗的，要查文件一堆，但內容打開來，全是廢文，應付式的文件占全部。 唯一比較成功的部門，想要什麼文件或紀錄，大概都搜得到，管理有以下特色： 1.專案生命周期，每一階段要生什麼文件，紀錄，用什麼系統存，有標準做法。且每個專案一致。 例如上述說過，Jira用來做需求紀錄，這個系統開發的進度，不會有第二個地方紀錄。系統的SDS，部署方式，就放在某個FTP位置不會有第二個地方。這些事情，新人來的時候，我們都會一步一步指導。 我當時進這家公司，還是新人時，我也覺得麻煩啊，各種流程都規範要上傳文件，上傳知識到某個地方。 但是真的各種bug出現，流程不過，自己去搜以前的文後，就知道這組織的用心了，回頭看還會很感謝這種組織的。 流程與文件管，管理者要負全責， 沒做好是管理者的問題，不是開發者的問題。 很多人認為，專案開發流程生文件浪費時間？ 有痛過的就知道，應該倒過來想， 不生文件討論，更浪費大家時間呢？ 不生文件與流程，線上又出了個bug損失幾萬的廣告播放量，誰負責？ 員工不懂文件怎麼寫？那也是管理沒做好， 要嘛招人有問題，要嘛，管理者沒指導。 事情是否成功，管理者責任最大。 2. 文件的產生與紀錄，要綁定部門與個人利益。 例如，Jira沒按照規範做，人家問你問題你不回，人家發issue給你，你超過24小時不回，SDS，測試文件都沒有… 直接影響了個人與部門考評。(與獎金) 看起來很嚴厲，其實也是管理能力的差別而已。 爛的管理者只會罵人： 你怎麼不去把文件上傳，扣你考績。 好的管理者，懂得鼓勵，懂得當個教練， 營造出文件分享可幫助別人， 可以增加自己影響力， 可以讓跨部門的人認識有你這個專家， 為自己考績加分的氣氛。 管理者本身也該把知識分享， 納入每次的考評作為參考，做得好的就大聲鼓勵。 文件與知識管理成功的特徵，就是： 1.流程產生什麼文件，有建立規範。 2.文件分享知識分享，綁定個人利益。 用什麼工具，才能文件或知識管理成功， 根本不是重點。 沒有人會無緣無故分享知識的，除非對自己有利。 至於怎麼樣的管理手段，可以將知識分享綁定利益，就是管理者的能力了。 看的少的只會罵人，批評人， 看得多的自然有更好的手段。 原PO： 了解別人怎麼使用工作做專案知識管理， 應付一下就好 (我也分享給你了) 部門能否管理好文件或知識重點在於： 1.自己公司的流程，產出物，適合的工具盤點。 2. Manager有沒有待過成功團隊， 自己有沒有能力管理好部門知識。管理者有沒有看過成功例子，深刻體會人性就是不愛分享，要綁定利益才是關鍵。導入後是否順暢要靠管理者溝通能力。 以上是個人經驗分享，不是標準答案。 如果見解不同很正常，大家的經驗不同而已。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.73.78.150 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1719833895.A.D0C.html