在產品需求文檔中，寫得很詳細、很到位，但是這依舊不能完全100%的避免問題的出現，也就是大家常說的“問題常有，不然就見鬼了！”

　　

今天一大早起來，沖了個涼。爽，爽，爽… 在過去的一周，著實很忙碌，一方面是產品版本迭代更新；另一方面是產品進入實施階段。記得之前和大家分享過“需求文檔”，說到文檔中應該盡可能描述清楚需求，以免相關實施方存在疑惑。確實，在產品需求文檔中，寫得很詳細、很到位，但是這依舊不能完全100%的避免問題的出現，也就是大家常說的“問題常有，不然就見鬼了！”

產品實施過程中究竟為什么會復現各種問題？

產品實施過程

文檔問題：不是說文檔已經寫完全、詳細了嗎？怎么還有問題呢？

是的文檔是可以根據既定的規則將問題描述清楚，可你不能控制的是人的因素，這個最核心因素：

a.因為不同人的理解事物的角度和方法存在差異，對于文檔中既有描述，理解上難免有誤差；直接溝通是最好的解決方案；

b.需求方，比如：市場部、客服等等，臨時修改/增加需求必然導致先前撰寫好的文檔造成修改；如果再加上信息傳播不及時，造成各方信息不對稱，那必然會導致實施過程中理想與現實的沖突；可能有人會問，都進入研發階段了，需求不是早就定了嗎？是的，理論上是需求都凍結了，可又有誰能保證需求百分百的一點都不被修改/增加呢？反正，小編能力有限、智商捉急、Too young Too Naive ,暫時還沒那個能力100%管控。

c.由于需求方需求的增加，相應的需求文檔也要做調整，那么調整的過程必然會有些許的遺漏。又有人，會問：能不能仔細點，將問題都扼殺在文檔里？小編說一句，可以！這對產品人本身也是極高的要求，在時間的保證下，還是應該保證文檔的每一處的無死角。當問題出現的時候，直面交流還是最佳的解決辦法。

d.需求評審時，技術評估誤差。在需求評審會議上，技術研發的老大哥都會對現有產品邏輯的合理性及其技術實現方案做技術評估。過多認為因素及經驗參與的過程，存在偏差同樣是合乎情理的。在產品/項目的問題的實際解決過程中，出現技術難點或實現上的復雜點，有時候也需要適當的調整需求，以便于快速的解決問題。

e.全員產品，技術大牛們在實現產品時，提出了一些更好的產品優化方案并且易于解決/實現。在一家全員產品型的創新型公司，必然是不可能視而不見的，對合理的需求，也會做出相應的調整，體現在文檔和產品之中。

產品設計流程

有這么多的問題究竟該如何去規避？或者說在遇到這些問題的時候，如何更好的解決呢？項目/產品進入研發實施階段，更多涉及到的實現，而不是邏輯上的問題；而這些邏輯上的細節也都在文檔中一一做了詳細說明。需求文檔（PRD）也自然成為產品與研發測試紙質化交流的唯一事實依據，實施過程中文檔的及時維護是重中之重，這真的就夠了嗎？一起往下看：

a.研發大牛們心有疑惑，產品應該如何？隨傳隨到，即刻解答！是的，在產品/項目實施過程，產品應該時刻準備著，準備沖到研發部為研發大哥們消除心中以后。此謂“開心消消樂”！搭建良好的溝通機制及問題相應機制，是很有實用性的。

b.需求方增加/修改需求，應該及時更新到文檔，并且文檔中應標識與上一版本不一樣的地方，以便開發大哥們整悶了！同時，也有必要在文檔最前面文檔修訂記錄中，記錄每次修改的內容，以便后期查詢，需求變動的記錄。

c.文檔更新了，不算完；還需要及時地通過各種渠道通知項目有關成員文檔（PRD）變更的情況，依據實際情況而言，還是那句話：面對面的交流時最好的方式！一般，小編是QQ吼2句，最關鍵的是會親自去說一聲…研發哥哥很忙的，說不定的QQ已被屏蔽…

產品實施過程，不僅僅是圍繞文檔而展開的，還有很多其他關鍵點需要留意：時間節點、項目進度、產品還原度，這些也是很關鍵的。

項目實施的流程化

1、需求評審后，項目經理會對項目完成時間點做一個粗略的評估，那么具體的實施過程中，項目進展的如何呢？是不是延期了？是不是提前了？是不是穩步進行？這些都是產品需要去把控跟進的，對項目進度的把控設計到產品能否按時完成上線。

2、產品實現的過程中，技術大牛們是否創意無限，一發不可收拾，沒有按照需求來，而是直接率性而為呢？產品真實需求還原度也是產品需要把控的一個方面。只有真正符合需求的產品，才是用戶/產品（PM）想要的。

對用戶來講，產品是能滿足其需求的實物/服務；對我來說，產品也是一個過程——從出生到長大的成長過程。項目/產品實施作為產品整個生命周期的閉環環節，是產品由需求/創意/想法轉變成現實產品。實施的過程的主角是“研發”，儼然不是產品（PM）；可實際情況是，產品依舊需要不離不棄，初心不變，相伴產品一生。

原創文章，作者：愛運營，如若轉載，請注明出處：https://www.iyunying.org/yunying/cpyy/58873.html