## 目錄 - [前言](https://www.52interview.com/book/36/0) - (思維篇)人人都是產品經理 - 1.需求文件 - 1.1 [需求管理](https://www.52interview.com/book/36/342) - 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 編碼實現 - 總結 - 原始碼 - 參考 --- ## 導航 - 羅馬不是一天建成的 - 傲慢與偏見 - 人人都是產品經理 - 鋒利的郵件 - 需求蒐集 - 需求整理 - 四象限法則 - 最後 > 想要打造出一個好的產品真不是一件容易的事情,需要靈感,需要需求蒐集和整理,需要技術研發投入,需要客戶的反饋。每一個環節都是很重要的,而作為技術開發者或者或專案經理,對需求的理解和管理是重中之重。有時候甚至應該把自己當成一個主導者來開展工作。 #### 羅馬不是一天建成   通常公司是以專案為單位來開展工作的,這裡分享一下自己曾經在團隊中使用的需求管理的策略,僅供參考。

  需求來源可以來自市場、使用者調研、運營、測試、開發、使用者反饋、產品經理等等。不同部門,不同干係人之間的需要建立良好,順暢的溝通機制,絕對不是短時間就是能完成的事情。**需求管理體系需要長時間的磨合和企業文化薰陶**。   從上圖可以看出,專案負責人對於專案成功和失敗至關重要。要順利交付一個滿意的產品或專案其實對開發人員有著極高的要求,懂產品,懂業務,懂技術。**而具備這種綜合素質的人才的培養,也是需要長期的經驗積累的**。 #### 傲慢與偏見   十多年的職業生涯,我見識過太多傲嬌的程式設計師,這似乎是程式設計師的通病。技術人員總是容易陷入細節。他們倔強,逞強,單純,愛鑽牛角尖。   或許是因為長期和技術打交道。外界給技術童鞋打上了“木訥”,"不善言辭"的標籤。而技術的同學卻又容易因技術而莫名的自嗨。技術是工具,生活和工作的主體是人,希望技術的同學們放下傲慢和偏見,跳出技術思維。積極的見識不同的人,放下包袱,培養自己與人溝通的能力。 #### 人人都是產品經理   "專人專事"或許是對員工潛能的最大束縛,網際網路行業尤甚。"兩耳不聞窗外事,一心只想寫程式碼"。這是很多技術同學的心態。筆者建議技術的同學也應該主動培養自己的產品思維。人人都是客戶,人人都是產品經理。有個網站[人人都是產品經理](http://www.woshipm.com/)值得大家去看。   從產品的角度思考問題,你的格局將不再侷限於程式碼的實現。**值得注意的是,技術人和工具人(產品經理)的大部分工作就是圍著產品轉**。 #### 鋒利的郵件   沒有人會對郵件陌生。儘管現在職場中有很多溝通工具,如企業微信,釘釘,QQ,郵件等,但是公認最為正式的還是郵件。通常每個入職的新人,公司都會分配一個郵箱號,這個郵箱大概率就是內部系統賬戶,它將貫穿你的在這家公司開展工作的生命週期。   工作郵件大致可分為以下四類： - 確認郵件——做留存   口頭、電話、會議交流的事情，郵件進行確認，這是一個好習慣，為了減少跨部門的扯皮情況發生，我們習慣將重要的決議通過郵件形式進行確認。 - 需求郵件——有細節   對於參與人員較多的事項,要把細節寫清楚、量化出來，這樣需求才精確，接需求的人知道怎麼做，結果也不會太讓你難受。 - 反饋郵件——有反應   收到別人的需求郵件後，應該儘快反饋。 - 通知郵件——廣播站   通知型別的郵件。如國家法定節日通知,公司組織機構調整等,這類郵件不需要回復。   善用郵件,將會幫助您提高工作效率。[《職場大佬告訴你,如何正確的寫郵件》](https://www.jianshu.com/p/3e5b05b944eb)值得一讀。 #### 需求的蒐集 > 很多公司是在需求管理方面沒有嚴格的制度和完善的流程。這會導致大量的時間浪費,也會引發出工作不聚焦的問題。我想網際網路996現象與此有著千絲萬縷的關係。   我曾供職於一家saas軟體公司,負責業務技術支撐工作。我的組員只有5人,但是我們同時負責了官網,devops平臺等工作,其中涉及的支撐部門包括市場,運營,產品,開發,財務等多個部門,需求總是源源不斷。但限於沒有一套規範的管理體系,需求總是會以不同形式紛至沓來。甚至有人直接過來說需要馬上匯出報表。這種場景,我想大家是不陌生的。

  應對這種情況,首先就是要有一個統一的渠道來蒐集需求,比如郵件,杜絕不斷有人來打擾你的工作主線。   制定需求蒐集表單。實際上很多軟體公司也在想辦法如何提高協同工作效率,儘可能地減少人力資源浪費。這其中,比較有效地就是工單系統,筆者曾經參與開發過這樣的系統,的確能夠帶來工作效率的提升。當然,為了圖省事,可以制定一個需求模板,讓需求方按照模板來提需求,也能達到效果。 #### 需求整理 > 由於認知的差異,資訊不對稱等原因,需求的資訊總是參差不齊,往往需要加工之後才會變得有效。   需求方往往會開門見山的提出訴求,而不會告訴你完成這些需求的背後的邏輯,甚至有些名詞可能也會讓你捉摸不透。而你需要無效需求進行駁回或者追問,有效需求將加入需求池。   常見的需求管理工具有很多，比如[tower](https://tower.im/),Project,筆者比較喜歡用excel,或者騰訊線上協作文件。   任務池大致如下,僅供參考:

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

  應該將自己絕大多數的時間分配在第二象限重要但不緊急的事情上,有計劃的去執行,制定時間表,各個擊破。 #### 最後   管理是一門藝術,德魯克大師的《卓有成效的管理者》（珍藏版）非常推薦大家去看。需要的童鞋可以發郵件給**[email protected]**,留言獲取該電子書。 ### 參考 - [《Spring Boot 實戰紀實》](https://www.52interview.com/bo