《Spring Boot 實戰紀實》之如何攥寫需求文檔

時間 2020-11-29

標籤 javascript css html java git 程序員 github spring 數據庫 bootstrap 欄目 Spring 简体版

原文原文鏈接

前言
(思惟篇)人人都是產品經理
- 1.需求文檔
  - 1.1 需求管理
  - 1.2 如何攥寫需求文檔
  - 1.3 需求關鍵點文檔
- 2 原型設計
  - 2.1 缺失的邏輯
  - 2.2 讓想法躍然紙上
- 3 開發設計文檔
  - 3.1 功能梳理
  - 3.2 數據庫設計
- 4 制定開發任務和計劃
  - 4.1 時間管理
  - 4.2 任務管理(任務拆分+排期)
(技術篇) 碼農的自我修養
5 Java基礎
- 5.1 Java環境搭建
- 5.2 Java基本語法
- 5.3 Java流程控制
- 5.4 Java 集合
- 5.5 Java 類與對象
- 5.6 構造方法
- 5.7 封裝,繼承,多態
- 5.8 Java抽象/接口
- 5.9 Java經常使用類
- 5.10 Java異常處理
- 5.11 異常的定義及捕獲
- 5.12 Java多線程/線程池
- 5.13 Java的反射機制
- 5.14 Java的23種設計模式
6 Spring框架
- 6.1 瞭解spring
- 6.2 Spring帶給Java開發的便利
- 6.2 Spring ioc/aop
7 SpringMVC
- 7.1 瞭解springMVC
8 SpringBoot
- 8.1 MVC 模型
- 8.2 攔截器
- 8.3 過濾器
- 8.4 POJO
- 8.5 controller
9 MyBaits plus
8 Web基礎
- html+css
- javascript
- bootstrap
(實戰篇) 打造本身的輪子
- 10 項目架構
- 11 網站母版構建
  - 11.1 thymeleaf介紹
  - 11.2 使用thymeleaf構建網站模板
- 12 首頁
  - 12.1 banner
  - 12.2 輪播圖
  - 12.3 文章分頁
  - 12.4 編碼實現
- 13 登陸
  - 13.1 功能點介紹
  - 13.2 知識點
  - 13.3 編碼實現
- 14 註冊
  - 14.1 功能點介紹
  - 14.2 知識點
  - 14.3 編碼實現
- 15 用戶管理
  - 10.1 功能點介紹
  - 10.2 知識點
  - 10.3 編碼實現
- 16 權限控制
  - 10.1 功能點介紹
  - 10.2 知識點
  - 10.3 編碼實現
- 17 權限控制
  - 11.1 功能點介紹
  - 10.2 知識點
  - 10.3 編碼實現
總結
源碼
參考

若是一個崗位有幾個候選人，永遠考慮那個擁有更強寫做能力的人。不管這我的是設計師、程序員、市場或銷售人員，寫做能力老是能夠帶來回報的。有效、簡潔的寫做能帶來有效、簡潔的代碼、設計、郵件、即時通信等等。css

寫做帶來：
更深度的思考，更認真的生活，更清晰的溝通，更有效的社交，更強大的心裏。html

工欲善其事,必先利其器

君子生非異也，善假於物也java

思想當然重要,可是善於藉助工具表達本身的思想也很重要。這裏介紹一些好用的寫做方面的工具。git

Markdown

根據百度百科-markdown,Markdown是一種輕量級標記語言，創始人爲約翰·格魯伯（英語：John Gruber）。它容許人們使用易讀易寫的純文本格式編寫文檔，而後轉換成有效的XHTML（或者HTML）文檔。程序員

Markdown是一種簡單的格式化文本的方法，讓排版變得簡答,在任何設備上看起來都很棒。有道筆記,印象筆記,博客園,vscode,github,碼雲等都支持markdown語法。github

相關教程spring

Markdown編輯器教程。數據庫
想學 Markdown？這篇文章幫你快速上手。bootstrap

思惟導圖

對於某些需求涵蓋功能點較多,後者分支較多場景,使用思惟導圖呈現更直觀。好比,這是我整理的考試系統的前期需求的一個思惟導圖：

如今有不少工具都支持畫思惟導圖:

流程圖

程序員童鞋對流程圖確定不會陌生,常見程序流程圖設計應該是信手拈來。針對複雜需求,有時候使用語言和文字難以描述清楚。這個時候,流程圖該上場了。

流程圖在整個需求的整理中的核心,他能將產品業務背後的邏輯展現出來。這個須要你對吃透需求,而後內化,加工,再輸出。說句題外話,若是你參與了這個需求,必定要摳細節,流程越細化,越有助於成功的實現需求。。

這裏推薦幾個經常使用的流程圖工具：

processon
Edraw
draw.io【開源】

換位思考

接到需求以後,技術同窗每每會先思考技術實現,而後陷入技術細節,這也是大多數技術人的通病。

在此前的文章《需求管理》中,我曾指出技術同窗要放下傲慢和偏見,跳出技術思惟。這對於需求的理解和整理相當重要。

跳出技術思惟,而後換位思考,這有助於全方位,多角度的理解需求。一個功能可能由不一樣的角色人員使用,視角不一樣,需求不一樣。你須要像導演拍電影同樣,針對不一樣角色，一個場景一個場景的拍攝,最終串聯成一個完整的電影做品。

這個需求,「不作」

懂得拒絕是一門藝術。

技術人不是一個沒有靈魂的代碼工具。"這是需求爸爸提的,我無法拒絕","這是產品爸爸喊作的,無論個人事"。當出現問題的時候,咱們常常聽到技術同窗這樣說。

不合理的需求,對用戶不友好的需求,低收益,高投入的需求,要勇於拒絕。固然,拒絕也是一門藝術,這就是與人溝通的藝術。若是通過深思熟慮,你可以給出比較合理的解釋或者提出更有建設性的方案,我想這樣纔會更加容易讓人接受。

閉環

閉環這個詞,真是互聯網領域的萬金油。可是,筆者這裏特指產品需求邏輯的閉環。

筆者曾經待過一個互聯網教育創業公司。由於參與人不少都是TOB行業經驗的人。你們都是知道,TOB公司的產品賣出去不少時候是線下的操做。好比,微軟公司,我作操做系統一流,我贏家通吃。可是,TOC就不必定了,個體用戶更加註重用戶體驗,好比曾經的電商百團大戰的競爭,後面的共享單車的競爭,消費者能夠直接用腳投票的。

咱們作了一個課程官網,包括課程展現,訂閱充值的官網。官網上線以後,市場同事也作了宣傳,可是發現基本上沒人註冊,不少用戶都是讓咱們幫忙註冊。通過研究發現了緣由: