需求這個話題大家已經聊得很多了，我說一下個人的看法，不涉及需求管理的全過程，只講需求的收集和分析，這一期內容不管是專案經理還是產品經理，只要是pm都可以聽，另外做運營的同仁們也可以聽聽，希望大家聽完後會有自己的結論。
我們知道，不同的組織，或者同乙個組織不同型別、不同規模的專案，收集和分析需求的方法是不同的，所以脫離具體的環境和專案說方法其實就是在耍流氓，具體的方法我們就先放在一邊，我們先聊聊需要注意的問題和常用的工具吧。
先說案例。話說當年，某電商的乙個核心部門發起了乙個專案，目標是要優化**鏈的相關環節，從而提公升效率、降低成本、改善使用者體驗。現在，我們假定專案剛剛被發起，你已經被指定負責這個專案，下一步就要收集和分析需求了，你的整體思路是什麼？
聽到這裡，熟悉電商業務的pm現在應該已經在掐著指頭數這專案大概會涉及到多少部門和產品了，沒錯，這個專案當時涉及到了十幾個部門和產品。
結合這個案例，我就說在收集和分析需求過程裡需要注意的地方，總共有7點：
第一點，確保戰略跟隨和商業價值。
如今，大部分的網際網路組織其實是缺少持續穩定的收入**的，這就意味著組織所花的每一分錢從道理上來講一定要產生期望的商業價值，這些商業價值既可以是創造的營收、使用者滿意度的提公升，也可以是效率的改進，總之不管商業價值是什麼，都要符合戰略規劃的需要，這是對所有需求最最基本的要求。
第二點，需要明確總體需求的控制者。
就上面的這個例子來講，這個專案涉及到了十幾個部門和十幾個產品，那總體的需求應該是誰來負責把控呢？是專案經理還是產品經理？很清楚，產品經理只負責自己的產品所對應的需求，而總體需求一定是專案經理負責控制，這一點雖然很明確，但還是需要在專案裡廣而告之。
第三點，需要盡可能弄清楚需求背後的真實動機。
我們都知道，需求只是表象，源自於需求提供方的內在動機，雖然網際網路倡導協作、信任、共贏，還在實現扁平化、去控制等等，可實際上我們的動機好像並沒有真正地簡單過，而且越是大組織、大專案，這些動機也就越不簡單。有的需求方和你說提的這些需求是為了提高效率，有可能他說的是實話，但對於有的需求方來說，他提出的需求其實另有深意。如果我們不了解真實的動機，一些所謂的需求其實就變得非常的可笑，這樣的需求如果落地交付，我們也許會收穫可笑的結果。
第四點，利益相關方的分析一定要做。
大家要是做專案管理的話，對於利益相關方這個概念一定是很熟了，在pmi也就是美國專案管理協會的詞典裡，利益相關方這個詞又叫做專案干係人，我們以後就統一叫做利益相關方或者利益相關者吧。利益相關方這個概念對於專業的專案經理來說已經是很熟了，但對於產品經理來說，可能了解的人還不是很多，我強調一點，談需求必談利益相關方，如果利益相關方的識別和分析都不做的話，做需求是沒有意義的。
第六點，需求不等同於功能需求。
很多時候，需求方和pm只要一提需求，就會大談特談各種功能，其實我們都知道需求除了功能之外，還有很多其他的種類，常見的有效能、質量、安全、可擴充套件、運維、相容性、介面、資料等，另外，管理方面的需求也是很容易被忽視的，我們在收集、分析功能需求的時候也要把這些種類的需求都要過一遍，盡量不要遺漏。
第七點，需求要盡可能保證合規。
合規這個問題在不同的組織、不同的發展階段重要性是不一樣的，網際網路因為自帶顛覆、變革的屬性，所以目前網際網路的有些領域確實是在踩法律和道德的紅線，而且在組織內部，有時候越是高層管理者、越是風口行業，也就越會有意無意地忽視合規的問題。法無禁止皆可為，這句話基本沒毛病，但是如果我們發現要交付的產品和服務違反了法律和道德的話，作為pm需要盡可能地堅持合規，盡量避免發生後續的悲劇。最近一段時間網際網路也發生了幾件比較大的負面事件，這些事件也需要我們引以為鑑。
好了，需要注意的地方我已經說完了，之所以說這幾點，是因為我發現這幾點pm比較容易忽略。
下面我們來快速過一遍在收集和分析需求過程中經常用到的工具。
首先最常用的工具就是訪談、組織結構圖和業務流程圖，另外還有乙個常用的工具就是調查問卷，調查問卷如果設計好了的話，還是挺有價值的。
下乙個工具是business usecase，也就是業務用例，用來收集和分析業務需求也是不錯的。
利益相關方分析矩陣主要用來在多個維度分析利益相關方應該如何引導和對待。
頭腦風暴、焦點小組就不多說了，主要用於分析需求。
評審會議就不說了，大家都做過。
再有就是思維導圖，大家已經用的比較多了。
再有就是需求跟蹤矩陣，這是乙個非常有價值的需求工具，建議大家使用。
還有pbs、pfd，主要用來把分析好的需求做分解，類似於wbs。
再有就是moscow，用於確定需求的優先順序。
另外還有多指標評分表，多指標評分表也是用來確定需求優先順序，只不過這個評分表會涉及到多指標的換算，至於是哪些指標、多大的權重，這個需要自己根據情況來確定。
至於5w、5w2h主要用於需求的收集，大家都已經用的比較多了。
競品分析和可用性測試產品經理們都已經很熟了，可以用來輔助確定和驗證需求。
下乙個就是userstory和usecase，也就是使用者故事和用例，它們都是很好的需求分析工具，需要根據專案和團隊的情況靈活選用，我個人更偏重於usecase。
最後就是產品經理們最熟悉的prd+原型了，關於怎麼寫prd，怎麼畫原型，大家在網上很容易就能找到很多資料，prd我建議還是用usecase來描述和分析需求，原型起到乙個輔助的作用就可以了，當然也有人認為沒必要寫prd，純畫原型就可以了。這件事情其實沒有絕對的對和錯，需要具體情況具體分析，但我認為圖形和文字是兩種不同的資訊表現形式，文字和圖形對於人腦刺激的區域也不同，完全用原型法來描述和分析需求，出現問題幾乎是必然的，這其實不是我們能力的問題，而是因為人的左右腦功能結構決定的，所以我還是建議需求主要以文字為主，圖形為輔的模式，這種模式對於團隊其實是有好處的。
剛才我們說的例子是乙個典型的專案，既有專案經理，也有產品經理，所以上面說的這些工具有的是專案經理用，有的是產品經理用。至於上面所說的這些工具用哪些不用哪些，如果你所在的組織有pmo，可以和pmo聊聊，他們會給你具體的建議。
好了，這期節目我們就聊到這裡，我們下期節目見。
企業建站時需要注意的問題
先說一下企業站註冊網域名稱和空間的問題。這方面的問題我遇到過兩個問題。前幾天乙個企業站交給我們團隊進行seo優化，我們在向他們要ftp帳號的時候，他卻告訴我們不知道什麼是ftp帳號。在我們解釋清楚了什麼是ftp帳號之後，他告訴了我乙個非常鬱悶的答案，他的ftp帳號在為他們建站的那個團隊手裡，並且他們...
配置時需要注意的
搭建的時候肯定不會在同一臺主機上搭建。大多都是在不同的伺服器上安裝不同的角色 追蹤器主機上的 配置檔案填寫的是 當前主機的ip 儲存節點主機上的 bind addr 填的就是當前主機的ip 配置中tracker server 填的蹤器的ip和埠 儲存節點的輪詢 就是在新增一次tracker serv...
Logistic回歸分析時幾個需要注意的問題
logistic回歸分析中，到底樣本量多大才算夠，這一直是個令許多人困惑的問題。儘管有的人從理論角度提出了logistic回歸分析中的樣本含量估計，但從使用角度來看多數並不現實。直到現在，這一問題尚無廣為接受的答案。根據國外一些大牛的看法，如果樣本量小於100，logistic回歸的最大似然估計可能...