筆者與開發和架構的好友討論了兩個問題：文檔要多細致、為什么開發說功能實現不了。希望讀完文章的你能得到一些啟發。

近期和開發和架構的好友一起探討了軟件開發中的產品文檔細致程度和技術可行性評估方面的細節問題，我們從各自的角色和職責出發，更全面地回答了這兩個問題：

1. 產品和交互文檔需要寫多細致呢？
2. 為什么開發會說這個功能實現不了？

1. 產品和交互文檔需要寫多細致呢？

提出這個問題的原因是：

我平時寫產品和交互文檔的時候擔心文檔寫的細致需要花費許多時間，如果開發根本不看，會產生不必要的浪費，而且敏捷宣言中有一條就是“工作的軟件高于詳盡的文檔”；但是也有如果文檔寫的少了，開發遺漏細節的擔心，所以拋出這個問題問問文檔的使用者們（重要干系人）。

1.1 架構好友的觀點

因為每個開發的能力和經驗不一樣，就算是約定俗成的技術實現方式，也不能做到都知道，如果文檔不寫出來，可能有些開發實現的細致一些，有些開發實現的粗糙一些，那還是寫出來比較好。

她認為開發是比較喜歡需求和交互文檔細一點的。而且，文檔寫的細致驗收時標準也明確。

1.2 前端好友的觀點

文檔不用寫的太精細，交互設計和視覺設計規范中有的內容不用寫，有疑問的地方我會直接找PM和設計師溝通的。

1.3 測試好友的觀點

文檔越精細越好，這樣我可以直接從產品和交互文檔copy進測試用例里面，比如：“文字折行，最多三行，超出部分使用省略號”需要細致到這種程度，如果同時將這些直接體現在原型圖上，那就更好了。

這樣，測試標準和PM想要的標準會更統一。

1.4 我自己的經驗

文檔需要寫得精細一些，因為從需求到開發可能會經歷很長的時間，當時的想法如果不記錄下來，到后面可能自己都不記得與團隊討論過的一些很細節的點了。需求文檔描述的不夠細致，會帶來溝通成本和不必要的返工。需求可以一開始盡可能的考慮清楚，當然如果中途有補充和變動，在敏捷開發的模式下，必要的變更大家都是可以理解的。

跟產品和交互文檔的使用者們討論之后，我們都更傾向于將文檔寫得細致一點的觀點，以下為我在日常項目中的文檔，此處原型圖不方便公開。

1.5 我在日常項目中的文檔

產品功能列表

產品PRD文檔

流程圖

原型圖和交互文檔（必備，配圖略）

2. 為什么開發說這個功能實現不了？

對于這個問題，大多數沒有技術背景的產品經理都會遇到，我們的疑問是開發真的實現不了，還是不想做呢？

我的幾個開發好友，坦誠的跟我說過確實存在技術忽悠PM的事情存在，有時真的是任務太重了，或是產品經理的腦洞太大了，不得已而為之。

人人都是產品經理平臺中梁鋒的文章已經給出很好的答案——《研發說方案無法實現，產品經理怎么辦？》?梁鋒將方案無法實現歸納為四種情況：

1. 確實無法實現
2. 不知道可以實現
3. 不知道是否可以實現
4. 可以實現但是就是說不能實現

2.1 確實無法實現

產品經理需要自己想想做這個功能的目的是什么，是否可以通過其他方案來實現，條條大路通羅馬。

區別于開發的技術思維，產品經理一定要具有業務思維，不要技術說不能實現或是時間來不及的時候，就無可奈何、束手無策了。

舉個真實的例子：在開發多項目并存，資源緊張的情況下，關于點滴日報系統新增下載團隊周報功能，開發評估需要兩周，并且兩周后才可以開工，意思是用戶一個月之后才能使用該功能，短期內確實無法完成該任務的開發。

產品經理不能開發一說沒辦法了，就認為沒辦法，不能讓用戶等著呀，產品經理需要另想辦法，讓用戶可以提前使用該功能。

開發只是從技術的角度給PM建議，PM還需要有業務思維，急用戶之所急，痛用戶之所痛。

我們當時的解決方案是，可以每周五從SQL中導出團隊周報發給用戶（Manager權限用戶），直至這個功能開發好。這樣用戶的需求就可以提前滿足了。

2.2&2.3? 不知道可以實現、不知道是否可以實現

這是因為開發人員的水平問題，PM可以咨詢技術專家，調研行業和競品解決方案.

2.4 可以實現但是就是說不能實現

PM可以將這個功能的意義講給開發聽，獲得開發的認同感和參與感；亦或是開發任務太重了？

如果真的拿不準開發到底能不能實現，架構好友支了一招：

當開發說功能不能實現時，產品經理可以這樣說：我上家公司做過這個功能，要不我幫你問問他們是怎實現的？

當然，產品經理如果能問出開發說需求不能實現背后的原因，雙方好好溝通，一起想辦法解決問題是更好的解決方案。

另外，產品經理平時需要多多學習技術知識，才能和開發無障礙的溝通。

以上為工作日常的碎碎念，你會不會也有這種小糾結呢？感謝以上提供觀點的開發小伙伴們。

#專欄作家#

沈子硯，公眾號：UXHub，人人都是產品經理專欄作家。江南大學設計學院碩士，專注于產品設計、產品體驗、產品運營。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議