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

戎"碼"一生發表於2020-11-21

目錄

  • 前言
  • (思維篇)人人都是產品經理
    • 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,或者騰訊線上協作文件。

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



四象限法則

計劃總是趕不上變化。

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



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

最後

  管理是一門藝術,德魯克大師的《卓有成效的管理者》(珍藏版)非常推薦大家去看。需要的童鞋可以發郵件給zhikecore@foxmail.com,留言獲取該電子書。

參考

相關文章