筆者與開發和架構的好友討論了兩個問題：文檔要多細緻、為什麼開發說功能實現不了。希望讀完文章的你能得到一些啟發。
近期和開發和架構的好友一起探討了軟體開發中的產品文檔細緻程度和技術可行性評估方面的細節問題，我們從各自的角色和職責出發，更全面地回答了這兩個問題：
- 產品和交互文檔需要寫多細緻呢？
- 為什麼開發會說這個功能實現不了？
1. 產品和交互文檔需要寫多細緻呢？
提出這個問題的原因是：
我平時寫產品和交互文檔的時候擔心文檔寫的細緻需要花費許多時間，如果開發根本不看，會產生不必要的浪費，而且敏捷宣言中有一條就是「工作的軟體高於詳盡的文檔」；但是也有如果文檔寫的少了，開發遺漏細節的擔心，所以拋出這個問題問問文檔的使用者們（重要干係人）。
1.1 架構好友的觀點
因為每個開發的能力和經驗不一樣，就算是約定俗成的技術實現方式，也不能做到都知道，如果文檔不寫出來，可能有些開發實現的細緻一些，有些開發實現的粗糙一些，那還是寫出來比較好。
她認為開發是比較喜歡需求和交互文檔細一點的。而且，文檔寫的細緻驗收時標準也明確。
1.2 前端好友的觀點
文檔不用寫的太精細，交互設計和視覺設計規範中有的內容不用寫，有疑問的地方我會直接找PM和設計師溝通的。
1.3 測試好友的觀點
文檔越精細越好，這樣我可以直接從產品和交互文檔copy進測試用例裡面，比如：「文字折行，最多三行，超出部分使用省略號」需要細緻到這種程度，如果同時將這些直接體現在原型圖上，那就更好了。
這樣，測試標準和PM想要的標準會更統一。
1.4 我自己的經驗
文檔需要寫得精細一些，因為從需求到開發可能會經歷很長的時間，當時的想法如果不記錄下來，到後面可能自己都不記得與團隊討論過的一些很細節的點了。需求文檔描述的不夠細緻，會帶來溝通成本和不必要的返工。需求可以一開始儘可能的考慮清楚，當然如果中途有補充和變動，在敏捷開發的模式下，必要的變更大家都是可以理解的。
跟產品和交互文檔的使用者們討論之後，我們都更傾向於將文檔寫得細緻一點的觀點，以下為我在日常項目中的文檔，此處原型圖不方便公開。
1.5 我在日常項目中的文檔
產品功能列表
產品PRD文檔
流程圖
原型圖和交互文檔（必備，配圖略）
2. 為什麼開發說這個功能實現不了？
對於這個問題，大多數沒有技術背景的產品經理都會遇到，我們的疑問是開發真的實現不了，還是不想做呢？
我的幾個開發好友，坦誠的跟我說過確實存在技術忽悠PM的事情存在，有時真的是任務太重了，或是產品經理的腦洞太大了，不得已而為之。
人人都是產品經理平台中梁鋒的文章已經給出很好的答案——《研發說方案無法實現，產品經理怎麼辦？》 梁鋒將方案無法實現歸納為四種情況：
- 確實無法實現
- 不知道可以實現
- 不知道是否可以實現
- 可以實現但是就是說不能實現
2.1 確實無法實現
產品經理需要自己想想做這個功能的目的是什麼，是否可以通過其他方案來實現，條條大路通羅馬。
區別於開發的技術思維，產品經理一定要具有業務思維，不要技術說不能實現或是時間來不及的時候，就無可奈何、束手無策了。
舉個真實的例子：在開發多項目並存，資源緊張的情況下，關於點滴日報系統新增下載團隊周報功能，開發評估需要兩周，並且兩周后才可以開工，意思是用戶一個月之後才能使用該功能，短期內確實無法完成該任務的開發。
產品經理不能開發一說沒辦法了，就認為沒辦法，不能讓用戶等著呀，產品經理需要另想辦法，讓用戶可以提前使用該功能。
開發只是從技術的角度給PM建議，PM還需要有業務思維，急用戶之所急，痛用戶之所痛。
我們當時的解決方案是，可以每周五從SQL中導出團隊周報發給用戶（Manager許可權用戶），直至這個功能開發好。這樣用戶的需求就可以提前滿足了。
2.2&2.3 不知道可以實現、不知道是否可以實現
這是因為開發人員的水平問題，PM可以諮詢技術專家，調研行業和競品解決方案.
2.4 可以實現但是就是說不能實現
PM可以將這個功能的意義講給開發聽，獲得開發的認同感和參與感；亦或是開發任務太重了？
如果真的拿不準開發到底能不能實現，架構好友支了一招：
當開發說功能不能實現時，產品經理可以這樣說：我上家公司做過這個功能，要不我幫你問問他們是怎實現的？
當然，產品經理如果能問出開發說需求不能實現背後的原因，雙方好好溝通，一起想辦法解決問題是更好的解決方案。
另外，產品經理平時需要多多學習技術知識，才能和開發無障礙的溝通。
以上為工作日常的碎碎念，你會不會也有這種小糾結呢？感謝以上提供觀點的開發小夥伴們。
#專欄作家#
沈子硯，公眾號：UXHub，人人都是產品經理專欄作家。江南大學設計學院碩士，專註於產品設計、產品體驗、產品運營。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議