導航
- 永遠考慮那個擁有更強寫作能力的人
- 工欲善其事,必先利其器
- markdown
- 思維導圖
- 流程圖
- 換位思考
- 這個需求,「不做」
- 閉環
- 寫作套路
- 鋪墊
- 下定義
- 邏輯清晰
- 說人話
- 視角
- 版本延續性
- 結語
本文摘自《Spring Boot 實戰紀實》,智客工坊出品。
永遠考慮那個擁有更強寫作能力的人
如果一個崗位有幾個候選人，永遠考慮那個擁有更強寫作能力的人。無論這個人是設計師、程式設計師、市場或銷售人員，寫作能力總是可以帶來回報的。有效、簡潔的寫作能帶來有效、簡潔的程式碼、設計、郵件、即時通訊等等。
寫作帶來：
更深度的思考，更認真的生活，更清晰的溝通，更有效的社交， 更強大的內心。
工欲善其事,必先利其器
君子生非異也，善假於物也
思想固然重要,但是善於藉助工具表達自己的思想也很重要。這裡介紹一些好用的寫作方面的工具。
Markdown
根據百度百科-markdown,Markdown是一種輕量級標記語言，創始人為約翰·格魯伯（英語：John Gruber）。 它允許人們使用易讀易寫的純文字格式編寫文件，然後轉換成有效的XHTML（或者HTML）文件。
Markdown是一種簡單的格式化文字的方法，讓排版變得簡答,在任何裝置上看起來都很棒。有道筆記,印象筆記,部落格園,vscode,github,碼雲等都支援markdown語法。
相關教程
思維導圖
對於某些需求涵蓋功能點較多,後者分支較多場景,使用思維導圖呈現更直觀。比如,這是我整理的考試系統的前期需求的一個思維導圖：
現在有很多工具都支援畫思維導圖:
流程圖
程式設計師童鞋對流程圖肯定不會陌生,常見程式流程圖設計應該是信手拈來。針對複雜需求,有時候使用語言和文字難以描述清楚。這個時候,流程圖該上場了。
流程圖在整個需求的整理中的核心,他能將產品業務背後的邏輯展示出來。這個需要你對吃透需求,然後內化,加工,再輸出。說句題外話,如果你參與了這個需求,一定要摳細節,流程越細化,越有助於成功的實現需求。。
這裡推薦幾個常用的流程圖工具：
換位思考
接到需求之後,技術同學往往會先思考技術實現,然後陷入技術細節,這也是大多數技術人的通病。
在此前的文章《需求管理》中,我曾指出技術同學要放下傲慢和偏見,跳出技術思維。這對於需求的理解和整理至關重要。
跳出技術思維,然後換位思考,這有助於全方位,多角度的理解需求。一個功能可能由不同的角色人員使用,視角不同,需求不同。你需要像導演拍電影一樣,針對不同角色，一個場景一個場景的拍攝,最終串聯成一個完整的電影作品。
這個需求,「不做」
懂得拒絕是一門藝術。
技術人不是一個沒有靈魂的程式碼工具。"這是需求爸爸提的,我沒法拒絕","這是產品爸爸喊做的,不管我的事"。當出現問題的時候,我們經常聽到技術同學這樣說。
不合理的需求,對使用者不友好的需求,低收益,高投入的需求,要敢於拒絕。當然,拒絕也是一門藝術,這就是與人溝通的藝術。如果經過深思熟慮,你能夠給出比較合理的解釋或者提出更有建設性的方案,我想這樣才會更加容易讓人接受。
閉環
閉環這個詞,真是網際網路領域的萬金油。但是,筆者這裡特指產品需求邏輯的閉環。
筆者曾經待過一個網際網路教育創業公司。因為參與人很多都是TOB行業經驗的人。大家都是知道,TOB公司的產品賣出去很多時候是線下的操作。比如,微軟公司,我做作業系統一流,我贏家通吃。但是,TOC就不一定了,個體使用者更加註重使用者體驗,比如曾經的電商百團大戰的競爭,後面的共享單車的競爭,消費者可以直接用腳投票的。
我們做了一個課程官網,包括課程展示,訂閱充值的官網。官網上線之後,市場同事也做了宣傳,但是發現基本上沒人註冊,很多使用者都是讓我們幫忙註冊。經過研究發現了原因:
- 因為整合Azure註冊慢,登入頁面,而且極不友好。 這導致使用者放棄註冊。
- 官網沒有展示客服諮詢電話,只有一個使用者建議表單。無法實時聯絡客服。
這個案例,很典型。從市場到技術,我們做了很多工作,但是最終效果不理想。最大的願意就是產品不閉環。使用者想學習課程,但是登入和註冊體驗太差,這就已經擋住了大部分的使用者。
寫作套路
前面我們講了很多坑和避坑策略,那要如何才能寫好需求文件呢？
鋪墊
根據百度百科-鋪墊法。戲劇情節結構的一種手法。在戲劇的進展中，對於某些將要出現的關鍵性情節和起關鍵作用的人物，必須在事前有所準備、暗示；為情節的展開，為高潮的到來，醞釀氣氛，作好準備，鋪平道路。這種手法叫埋伏或伏筆。
其實可以簡單理解為背景說明。在需求文件中,增加一定的背景表述,可以增強事物間的因果聯絡和完整性,不顯突兀。
一般可以在你的需求前增加一個背景交代，
這樣的好處是,其一,讓之前沒有參與的人有個背景認識;其二,為自己後續的觀點(或者設計思路)提供可信依據,至少不知自己拍腦袋想出來的。
下定義
對於不同的業務,有時候會有一些專有名詞,或者是你自己了說明某個事物而定義的名詞。如果不做一些定義的解釋,很難理解。比如,在設計IM聊天時候,可能會有一些定義,可以給出定義。
邏輯清晰
需求文件,不是日記,切記流水賬。排版工整,重難點突出。邏輯清晰,富有層次感。
利用圖表配合文字,有條不紊的表達出合理地邏輯。這樣大家閱讀起來,一目瞭然。
說人話
針對不同的人群一定要設計不同的話術
這裡的人是指不同的受眾。考慮到需求文件面向的物件較多,有技術,業務,測試等,需要拋棄過於專業的技術語言，比如不要出現技術設計的細節,儘量要用自然語言表達。
說句題外話,其實嚴格意義上,需求文件可能是要寫兩份,一類是給技術同學看的,一類是給非技術同學看的。對於前者,你當然可以用類似抽象的uml圖或者直接給出虛擬碼來說明。
視角
子非魚,安知魚之樂
你以為的就是你以為的嗎?很多時候,需求的來源並不單一,比如公司要做一個工單系統,這個工單系統的使用者幾乎涵蓋了公司的各個部門。按照"使用者第一"的要求,我們需要考慮到不同業務方的訴求和使用者習慣。
我們在做需求的時候,就要提前想到。否則,後面的設計一定會違背使用者的意圖。前面,講過的換位思考,或者多角色思考該排上用場了。
在文件中,如何體現呢？通常,可以按照不通視角來描述。這就是類似程式的switch...case...
切記站在上帝視角看待問題。
版本延續性
需求文件很少一次性就讓各方滿意的,或多或少都會有補充和調整。比較好的習慣是使用修訂版本來記錄。
修訂歷史是一個版本的可追溯源，對需求變更歷程有一個清晰的認識。
新建預設為相應模組的首次使用，對於文件的修改以及增加的地方可加入超連結，同時在增加與修改的具體地方進行顏色標示或者其他標誌來進行區分，方便其他人員進行查詢。
結語
寫好一個需求文件,讓人覺得很專業有很多東西需要學習。這裡筆者只根據個人多年的工作經驗,拋磚引玉,歡迎大家怕批評和斧正。