《Spring Boot 實戰紀實》之需求管理

2020 年 11 月 21 日
筆記
JAVA, 管理

前言
(思維篇)人人都是產品經理
- 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 編碼實現
總結
源碼
參考

想要打造出一個好的產品真不是一件容易的事情,需要靈感,需要需求搜集和整理,需要技術研發投入,需要客戶的反饋。每一個環節都是很重要的,而作為技術開發者或者或項目經理,對需求的理解和管理是重中之重。有時候甚至應該把自己當成一個主導者來開展工作。

羅馬不是一天建成

通常公司是以項目為單位來開展工作的,這裡分享一下自己曾經在團隊中使用的需求管理的策略,僅供參考。

需求來源可以來自市場、用戶調研、運營、測試、開發、用戶反饋、產品經理等等。不同部門,不同干係人之間的需要建立良好,順暢的溝通機制,絕對不是短時間就是能完成的事情。需求管理體系需要長時間的磨合和企業文化熏陶。

從上圖可以看出,項目負責人對於項目成功和失敗至關重要。要順利交付一個滿意的產品或項目其實對開發人員有着極高的要求,懂產品,懂業務,懂技術。而具備這種綜合素質的人才的培養,也是需要長期的經驗積累的。

傲慢與偏見

十多年的職業生涯,我見識過太多傲嬌的程序員,這似乎是程序員的通病。技術人員總是容易陷入細節。他們倔強,逞強,單純,愛鑽牛角尖。

或許是因為長期和技術打交道。外界給技術童鞋打上了「木訥」,”不善言辭”的標籤。而技術的同學卻又容易因技術而莫名的自嗨。技術是工具,生活和工作的主體是人,希望技術的同學們放下傲慢和偏見,跳出技術思維。積極的見識不同的人,放下包袱,培養自己與人溝通的能力。

人人都是產品經理

”專人專事”或許是對員工潛能的最大束縛,互聯網行業尤甚。”兩耳不聞窗外事,一心只想寫代碼”。這是很多技術同學的心態。筆者建議技術的同學也應該主動培養自己的產品思維。人人都是客戶,人人都是產品經理。有個網站人人都是產品經理值得大家去看。

從產品的角度思考問題,你的格局將不再局限於代碼的實現。值得注意的是,技術人和工具人(產品經理)的大部分工作就是圍着產品轉。

鋒利的郵件

沒有人會對郵件陌生。儘管現在職場中有很多溝通工具,如企業微信,釘釘,QQ,郵件等,但是公認最為正式的還是郵件。通常每個入職的新人,公司都會分配一個郵箱號,這個郵箱大概率就是內部系統賬戶,它將貫穿你的在這家公司開展工作的生命周期。

工作郵件大致可分為以下四類：

確認郵件——做留存

口頭、電話、會議交流的事情，郵件進行確認，這是一個好習慣，為了減少跨部門的扯皮情況發生，我們習慣將重要的決議通過郵件形式進行確認。

需求郵件——有細節

對於參與人員較多的事項,要把細節寫清楚、量化出來，這樣需求才精確，接需求的人知道怎麼做，結果也不會太讓你難受。

反饋郵件——有反應

收到別人的需求郵件後，應該儘快反饋。

通知郵件——廣播站

通知類型的郵件。如國家法定節日通知,公司組織機構調整等,這類郵件不需要回復。

善用郵件,將會幫助您提高工作效率。《職場大佬告訴你,如何正確的寫郵件》值得一讀。

需求的搜集

很多公司是在需求管理方面沒有嚴格的制度和完善的流程。這會導致大量的時間浪費,也會引發出工作不聚焦的問題。我想互聯網996現象與此有着千絲萬縷的關係。

我曾供職於一家saas軟件公司,負責業務技術支撐工作。我的組員只有5人,但是我們同時負責了官網,devops平台等工作,其中涉及的支撐部門包括市場,運營,產品,開發,財務等多個部門,需求總是源源不斷。但限於沒有一套規範的管理體系,需求總是會以不同形式紛至沓來。甚至有人直接過來說需要馬上導出報表。這種場景,我想大家是不陌生的。

應對這種情況,首先就是要有一個統一的渠道來搜集需求,比如郵件,杜絕不斷有人來打擾你的工作主線。

制定需求搜集表單。實際上很多軟件公司也在想辦法如何提高協同工作效率,儘可能地減少人力資源浪費。這其中,比較有效地就是工單系統,筆者曾經參與開發過這樣的系統,的確能夠帶來工作效率的提升。當然,為了圖省事,可以制定一個需求模板,讓需求方按照模板來提需求,也能達到效果。

需求整理

由於認知的差異,信息不對稱等原因,需求的信息總是參差不齊,往往需要加工之後才會變得有效。

需求方往往會開門見山的提出訴求,而不會告訴你完成這些需求的背後的邏輯,甚至有些名詞可能也會讓你捉摸不透。而你需要無效需求進行駁回或者追問,有效需求將加入需求池。

常見的需求管理工具有很多，比如tower,Project,筆者比較喜歡用excel,或者騰訊在線協作文檔。

任務池大致如下,僅供參考:

四象限法則

計劃總是趕不上變化。

對於任務池的管理又不得不提到時間的管理,在人數和時間確定的情況下,任務其實是不確定的。每天都有可能冒出來一些臨時性任務,這樣就導致我們的計劃無法兌現。

應該將自己絕大多數的時間分配在第二象限重要但不緊急的事情上,有計劃的去執行,制定時間表,各個擊破。

最後

管理是一門藝術,德魯克大師的《卓有成效的管理者》（珍藏版）非常推薦大家去看。需要的童鞋可以發郵件給[email protected],留言獲取該電子書。

參考

《Spring Boot 實戰紀實》

Tags: JAVA 管理