文件究竟價值在哪？

軟體開發的世界，無數人一再強調「文件」的重要性，卻沒有人能很清楚說出為什麼要文件。

我有一個新創圈的朋友，當初他組建了一個團隊，有專案經理、工程師等等人員。但是礙於公司規模實在沒有很多預算請一個強大的團隊，每個都是能力不高的 junior 。然而，初建產品最忌諱的就是著急和貪求完整，他一直急著要把產品開發出來，但需求一直不明確，因為他沒辦法具體讓PM很清楚他想要什麼，也經常覺得「這樣好像比較好」再改動需求，甚至有「少了這功能好像這產品就不是很有吸引力」在追加MVP的複雜度。

我當下覺非常不對，我告訴他，停止你的開發方式，立刻開始寫文件！他非常反彈覺得「寫文件是沒有產出的事」，希望工程師盡快把Code寫出來。大概經過了2個多月的開發，團隊也有各種磨擦和爭執，PM和工程師鬧了翻臉。後來，PM和工程師都離職了，那堆程式碼根本沒人想要接手，任何工程師都想開發自己的程式，什麼都沒做出來。最終還是當初文件最有價值，工程文件讓下一個工程師能夠上手，PM畫的設計稿、需求列表讓下一個人知道要做什麼。

文件不可能詳細到一看就懂，也不可能是解藥萬靈丹，也不是文件有了產品就沒有問題。但是，從這段故事可以知道，文件是「標準」和「抵抗風險」的關鍵工具。可能有工程師會說「Facebook 不也提倡代碼即文件」這種說法？這其實是他們想逃避寫文件的作法，因為這個只建立在團隊成員都非常成熟，產出的程式都非常易懂的情況。但大部分的公司並沒有那個條件、能力、預算請一群頂尖的人才，這時候文件才更彰顯價值。

而寫文件來說，最關鍵的角色就是「產品經理」和「設計師」。看似對程式碼毫無產值的兩個角色，實際上是產出文件的骨幹。需求文字化的角色和需求視覺化的角色，有了這兩個角色才能推動好的產品。如何定義這兩個角色的價值？就是溝通力、文件易讀性、文件細節理解力、成本管控能力。

至於文件要寫些什麼這就是另一個議題了⋯⋯