上篇文我們光是隨手舉例文件就有如此百百種，當然 PM 可不是文件產生器，而文件的產生與職責分配為什麼有那麼多分歧呢？期待透過文章可以跟讀者們聊聊有哪些因素

上篇文我們光是隨手舉例文件就有如此百百種，當然 PM 可不是文件產生器，而文件的產生與職責分配為什麼有那麼多分歧呢？期待透過文章可以跟讀者們聊聊有哪些因素！

分歧原因

一、組織人員不足

常見情況在於新創企業，或是中大型企業的新部門，受限於組織規模必須要一人身兼多職，人的時間有限又要做很多事情，事情通常是做廣不做深，如果要做深又一定會捨棄些事情不做。
另外，事情通常沒有做完、也沒有做得完美的時候，我們應聚焦在該如何解決問題，而不是一昧的強調人員不足，站在公司立場，未必有資金聘請足夠的人力。

二、組織認知不同

即使是要完整的工程師、設計師、資料工程師、測試人員等編制，卻還是會遇到情況，發生在於組織成長後卻沒有重新定義「R&R」，處在有人做就好的心態，當然包含了每個人對於職能定義不同。
舉例而言，有些流程只要是「人」，不存在需要必要技能都可以學得會去寫的時刻，往往會有爭執你寫可以、我寫也可以。
例如軟體 PM，我們每次有釋出版本，會投過開發環境、測試環境、前置正式環境、正式環境的流程該怎麼做，當組織有 PM、QA、Release Manager，就會需要良好的溝通彼此定義自己的職掌。

三、溝通效果不足

跨部門團隊的認知常常有分歧，導致一個權力較大的一方往往不寫文件，將責任推給其他部門，例如工程師可能會說寫程式就沒時間，當然是 PM 要負責寫，這時會發生 PM 不了解技術細節，又要開會當工程師的窗口來撰寫文件。延伸而來，就會期望有技術背景的 PM，更嚴重就是直接讓技術 PM 看程式碼寫技術文件，這豈不就讓 PM 的職掌超出範圍，本末倒置。

曾經筆者就有遇到朋友是作為軟體 PM，卻要寫資料庫欄位定義書，向組織人員反應卻會被提及「你會做那你可以先做」、「PM 最好懂一些順便做一做」、「該開發人員不想做」、「該開發人員做的品質不好」等相關緣由，變得自己成為技術文件產生器。

我們可以這樣做

真的遇到這些事情時，PM 們、設計師們、工程師們總是帶有點焦慮或生氣，上演了踢皮球大戰，這時候作為專業工作者，雖然有適度情緒是必要，但我們是來解決問題，而不是製造問題，遇到這些事情，我們可以這麼做：

1. 掉球－先接手，後轉手，沒人做，就會是開發的卡點，可以先到自己手上，但要不斷的上上下下表明未來一定要由更專業的人做。
2. 被迫接球－避開沒必要的爭執：針對原則爭執而沒有範例沒有意義，更何況跟自己的主管對立通常沒有好事，因此可以先做了之後，大家一起發現問題，就會知道該怎麼交手才是好的方向。雖然要花比較多時間，但總歸有效。
3. 選擇性接球－大家說都可以的時候：這時先評估「自己有沒有時間做」，或是跟組織討論真正的問題發生在哪裡，再來釐清有無替代方案。通常我們遇到問題，不要先想解決方法，而是去想問題背後的問的 QBQ ( The Question behind the Question )。

小結論

聽到此，期望大家未來在寫文件時，能夠把玻璃心撿起來，好好思考文件為何而生、為何而寫。除非自己的職涯想要成為專業的 Technical Writer，就不要讓文件成為你日常工作的大部份卡點。當然更不是鼓勵大家都不寫文件，未來會跟讀者們說明文件還是有期必要，作為 PM 或是專業工作者是避免不了。因此，期許我們一起成為更專業的工作者。

這篇文章 軟體業 PM 常見的踢皮球大戰上演在這邊！面對3大問題可以如何解決？｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。