需求文檔:沒有標準、只有溝通

20 評論 1.2萬 瀏覽 175 收藏 14 分鐘

雖然標準的文檔在一定程度上能夠在這些內容表述清楚,通過原型具現出來。但是切記,這些還是需要根據當前公司文化來,按需輸出。一味追求所謂標準的需求文檔,不去思考為什么這樣寫,寫這些的意義是什么,反而落了下層。

這次寫這個其實也算是有感而發,起因是一個產品朋友小李向我吐槽,他在一個創業團隊,公司正在從探索期向成長期度過。原來的測試工作都是小李和研發相互協同的,也就是他們各自客串下測試。

后面公司慢慢向成長期過度,員工從10個演變成了50多號人,其他城市也有分公司,加起來快100號人,研發人員也就從2人變成了近10人。因為業務發展迅速,要全力負責業務線上的事情,就招了個測試。之后便是他們找我吐槽的原因。

小李給我說,測試來的第一周,給了他第一個任務,就是熟悉業務,了解公司當前的運營模式,以及基本功能。隨后便帶著他去見了每一個部門相關對接人,甚至帶到兄弟部門去認識下部門的領導。希望后面有問題可以直接有效的溝通,不然后面公司在擴展下,這種機會就很少了。

隨后也帶到了研發那里,一一介紹,給研發表示,這是新來的測試,以后大家就是工作上的一家人我,畫外音就是讓研發不要刁難測試。

就這樣過了2周,小李覺得半個月時間基本的業務和一些功能應該熟悉了,那么就開始對相關功能就行上手測試吧。

這個時候小李他們的公司也在瘋狂的擴展,并且還是獲得了融資,這使得小李的工作更忙了。但是小李還是和她約好時間,進行相關功能的對接。

對接的時候,小李拿著草圖給測試,進行了相關的講解。想讓他根據草圖和上面的文字先進行簡單的測試。但是測試老說,沒有文檔測試不了。

小李說當時他很困惑,雖然當初很多功能都是idea,直接在會議室假設出來,但是之后去探索驗證之后,很多都完善到草圖上了。他就直接給他說那些草圖就是就可以直接完成測試。

后面測試就直接懟了小李,說你這是草圖,根本就不是需求文檔。小李就直接說,原來公司處于探索業務,變換的很快,都是根據草圖來進行研發的,這個草圖上都有,為什么不能作為測試依據?

那時,兩人爭得不可開交,爭到最后,測試就說她來自己寫一份,說小李根本不是產品。

小李說到這里我也是吃驚了,畢竟都說出這樣的話了,連忙問小李草圖上有哪些東西,小李表示上面很多是手繪的原型和注釋,以及后續方向,并且上面也簡單的寫了公司的業務方向以及后期如何做這些內容。

還因為怕看不懂,專門還整理了,整理之后還給研發他們看,他們都說沒問題,他也不知道問題出在哪里。

后面我也想了想這個問題,真的是沒有需求文檔而引起的嗎?寫個需求文檔他的標準是什么?

需求文檔的作用

工作中,對于產品寫需求文檔還有個很常見的事情就是,我們花了大量的時間,將產品所有細節都推敲的完畢,都仔仔細細的寫在了需求文檔上面,甚至寫完后還反復和研發、業務部門核對了,確保沒有問題之后,交付給了相關干系人。結果他們因為工作安排,時間緊湊要么就沒看,要么就簡單的看了幾眼就放在了一邊。這個無疑是打擊我們。

但是這個好處是十分的明顯:

  • 后期研發中出現了什么問題,這個鍋產品肯定不背。為什么?研發自己不看文檔,文檔里面寫的清清楚楚,這個地方要這樣處理,是你們自己不根據文檔來研發。
  • 如果出現了人員的離職或者是新增,那他可以通過需求文檔快速的了解項目。減少他的熟悉時間。

換個角度,不寫需求文檔。那就是我們可以從作出決定,快速的推進至研發階段。等于開完會就直接開工,而不需要將所有細節都寫的清清楚楚。

有種說法,人無完人,事無巨細。但是這個對研發團隊要求很高,首先團隊必須具備作出決定的能力,其次大家要有相同的行為準則和職業素養,這個就體現在相關代碼規范、設計規范、原型規范上。

因為如果配合出現了失誤,包括功能和功能之間的不協調,ui配色和尺寸的不統一。那么就直接涼了。

寫需求文檔的作用是什么

需求文檔的作用主要就是為了保證目標一致性,讓研發或是其他配合人員能夠清晰的了解我們在做什么,了解當下我們需要解決的問題、面對的場景是什么,對于成功的定義是什么。

總結起來就是只要寫出的東西,弄夠幫助團隊成員,作出正確的結果的東西,那就是需求文檔,需求文檔沒有標準,只有溝通。

我不希望約束的說,需求文檔這樣寫才對,你那樣寫不對。我認為需求文檔對于個人來說,想這么寫就這么想,想那樣寫就那樣寫。但是對于工作,還是根據公司要求來,畢竟吃飯嘛。

但是,不管是寫需求文檔還是說需求文檔,我還是認為包含下面這些信息,對于團隊,還是個人都還是有很大的好處。

  1. 問題和方案;
  2. 證明問題和方案;
  3. 成功的定義;
  4. 場景;
  5. 功能描述。

第一:問題和方案

人與人之間有著明顯的差異性和共同性,更別說不同職位了。前端、后端、測試、UI、產品、運營等職位,對于相同的事物和問題都會有著自己的見解和解決方案,并且因為職業壁壘原因,常會雞同鴨講,這是最常見的。

(工作中例子太多了,產品要增加個功能,直接給研發說,結果研發說沒必要。這就是很典型的研發不知道說在什么樣子的背景下,遇見的這個問題。)

我們首先要明確這個新增加的功能要解決了什么問題。其中包括了簡要的背景,這個背景可以說一句話,例如:支付成功人數很低。也可以說相關的用戶調研、市場反饋、數據趨勢等,用于證實這個功能或產品是我們團隊要做的。

第二:證明問題和方案

我們需要證實兩個東西:一個是問題,一個是方案。

要給其他人說明這個問題是真實存在的,而不是我想當然的。因為職業問題,很多研發或者是其他的部門的人都會認為(不絕對哈,但確實有這樣現象),產品是技術部門的“門面”,“吹拉彈唱”樣樣都會。讓人誤以為產品經理是個只會“吹?!钡摹敖浑H花”。

但確實行業內,包括當初我自己出現過隨隨便便寫個我認為的問題,而沒去證實他,之后草草丟給研發。

方案,也是同樣的問題,不去窮舉,不去關注相關競品的解決方案,也就推進到研發階段。我想這也大家都會經歷的一個過程。

同樣我能夠想象到出,當我們經歷多了之后,簡簡單單說一個方案之后,這個方案真的可能是最優方案,畢竟天才和蠢材說出相關的解決方案,前者是經歷過很多失敗的方案之后說的,后者可能是運氣好,正好說中罷了。叫他說出其中緣由,那就漏底了。

第三:成功的定義

我們要清晰的告訴其他人,這個功能對于成功的定義是什么。

這里的成功有兩個意思:成功的研發出來;這個功能推出后取得的效果。

成功的研發出來這個很好理解,就是還原度,百分之一百的還原出功能。只有保證這個功能能夠百分之一百的還原,我們才能通過市場、通過用戶去驗證這個功能或說這個方案是否成功。不然對于團隊和我們來說就是,資源浪費。

我們要將成功進行定義,只有這樣才能得到有效的反饋。不然我們無法確認得到的結果,到底是成沒成功。

第四:場景

場景說產品工作中最重要的東西,自始至終貫穿整個產品的一生。我這里不在過多闡述,文末我會發個我使用的場景還原方式。

第五:功能描述

功能描述包含的了很多東西,如:業務、流程、反饋、架構等,如果是文檔的還會包括原型、狀態、迭代記錄等問題。

我們需要讓其他人了解業務的流程,讓每一個人清晰的知道,我們的業務環節。就像我們說的,如果你們團隊很強大,幾乎人人都是業務方面的小能手,那么你覺得還需要相關圖嗎?

反之,我們為了能夠清晰的表述業務,不一定要去畫精美的圖來表示,只要能夠理解,寫個1234都可以。

我們需要讓其他人了解當前產品的架構,不管是信息還是功能,這樣能夠盡可能的復用,減少開發成本。不然研發不清楚,瓜兮兮的跑去寫代碼,結果要寫完了發現,這尼瑪其他模塊有,可以直接調用或者是改一下就能用。

現在寫出來了還不能用(開發:代碼耦合度高)只能去改原來的,那么確實是很尷尬。

所以可以告知用戶,這個功能在原產品上是存在的或是已經實現過了,因為代碼真的不像我們說的,這個功能很簡單,隨便加一個字段就行。

最后

其實小李那些草圖里面的內容確實是包含所有需求文檔有的東西,只是相對于所謂的需求文檔,沒成體系罷了。也不是說那個測試的問題,我只是覺得太過去追求所謂的需求文檔,反而不知道需求文檔的真實目的。

雖然標準的文檔在一定程度上能夠在這些內容表述清楚,通過原型具現出來。但是切記,這些還是需要根據當前公司文化來,按需輸出。一味追求所謂標準的需求文檔,不去思考為什么這樣寫,寫這些的意義是什么。反而落了下層。

補充一點的就是,大部分研發都不喜歡開會,特別是那種你在這三四十頁的需求文檔,一開就開幾個小時那種。先不說他們記不記得住,這個開會的成本是真的高。

所以我推薦產品在開會前計算下每次開會的成本是多少(計算方法是,每一個參會人的小時工資之和),開會不要隨意的開,每一次開會都是耐心的挑戰、資源的挑戰。

 

作者:wcof,在努力做產品不做產品經理的人;微信公眾號:wcof(ID:wcofPM)

本文由 @Wcof 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 【高階產品1元福利好課:產品管理者的溝通技巧??!】

    ? 奇魚微辦公產品副總裁@黃喆老師
    ? 1小時產品管理者溝通技巧拆解!
    ? 原價108元,特惠1元!

    立即點擊預約聽課>>>http://3.woshipm.cn/byy26b

    回復
  2. 說好的文末場景還原方式呢 ??

    回復
  3. 回復
  4. 呵呵,我就是個傻白甜

    回復
    1. 什么是傻白甜

      回復
  5. 需求還是有標準的, 但是這個標準在大的方面,可能大家都一樣。
    但是在細節方面,還是根據公司具體實踐來的,產品和研發相互磨合得出來的。

    回復
  6. 重點在于你的想法和認知與開發人員達成一致,所要追求的模板只不過是需要一種方式/流程來清楚的表達自己的想法。一份完善的需求文檔是產品開發以及測試共同深度詳細的討論之后的結果,畢竟有些需求會被砍掉,先寫個大綱討論之后再來完善文檔也沒什么問題,而不是糾結于一份文檔浪費太多的時間。

    回復
    1. 畢竟對于大多數公司來說,時間,真的是金錢。

      回復
  7. 小李的問題我遇到過類似情況。在需求說明較為標準和完善的情況下,給新來的測試同事做了講解,但是測試結果還是很令人不滿意。但是站在開發、測試等其它職位的角度來看,他們對業務不了解,對需求不清晰是很正常的,因為只有產品經理是深度鉆研業務和背景的,其它職位只要了解到能夠完成工作的程度就足夠了。所以產品經理的職責就是在不同的時段下通過各類溝通方式,反復確保開發和測試對需求理解不出現偏差,最終達到可交付的成果。至于溝通的形式,可以是完善標準的需求說明,可以是頻繁的問答,只要達到目的就可以。
    我一直認為,產品經理是最應該能夠換位思考的角色。你不能默認別人的認知程度都跟你一樣,而是應該從對方的角色去辨別他的預期認識程度和實際認知程度,然后有針對性的溝通。
    至于文章中的案例,各打一大板吧。小李同志在自身工作不完善的情況下,還不去反思,是有問題的。反之,測試同志在需求不完善的情況下,還是可以利用專業技能去測試一些基本問題的,而且不要懷著不懈或者甩鍋的情緒,去直接否認對方的工作成果,要良性、有效的溝通。不針對、不吵架是社會人的基本素養。

    回復
    1. 對的,我就是讓他去想一想,產品的能力要求中,就有一個有效溝通的要求。我說,如果你讓其他人看不懂,那就是你自身的問題,不能怪別人。

      回復
    2. 如果產品當時不反駁,而是去改進呢,還各打一大板嗎

      回復
    3. 改進當然是好的,主要目的不是要判斷誰對誰錯,對于公司來講,目的是如何高效的推進工作,對于個人來講(不論是產品或是測試,或是其他角色),是努力提升自己,讓自己變得更優秀,您說是吧

      回復
  8. 產品不把文檔寫規范,有些鍋還得你背。

    回復
    1. 沒錯,但確實在工作還是會出現理想狀態和現實狀態。理想狀態是我想把這些細節都寫清楚?,F實狀態是,老板:你咋個還在寫哦,快點開發哦,這個很急。之后3小時內催了5詞。:(

      回復
  9. 不能過于追求標準,但至少要能讓大多數人理解。如果那個草稿的模式只有你們一些熟悉的老員工能看懂,那就還是無效溝通。文檔的除了溝通還有能夠留底的作用。

    回復
    1. 那個草稿對于他們老員工應該是有效溝通,但是在對外的情況下,確確實實是無效。這個也算是因地(公司)而異吧。

      回復
  10. 一個說明的東西需要寫標準?開發那么忙,哪有心情和時間看這個?重點需要寫出就行,那些不相關的不要寫

    回復
  11. 沒寫過

    回復
  12. 確實有的時候過分追求標準化可能本末倒置了

    回復
  13. 需求文檔只是溝通的工具,只要能達到預期結果,那就不用論太多……

    回復