目錄
- 前言
- (思維篇)人人都是產品經理
- 1.需求文件
- 1.1 需求管理
- 1.2 如何攥寫需求文件
- 1.3 需求關鍵點文件
- 2 原型設計
- 2.1 缺失的邏輯
- 2.2 讓想法躍然紙上
- 3 開發設計文件
- 3.1 功能梳理
- 3.2 資料庫設計
- 4 制定開發任務和計劃
- 4.1 時間管理
- 4.2 任務管理(任務拆分+排期)
- 1.需求文件
- (技術篇) 碼農的自我修養
- 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,留言獲取該電子書。