在創(chuàng)業(yè)團隊中，產品經(jīng)理的角色至關重要，尤其是在產品開發(fā)過程中，需求列表的編寫更是關鍵環(huán)節(jié)。本文將深入探討如何在創(chuàng)業(yè)團隊中高效編寫需求列表，確保產品開發(fā)的順利進行。

“Design is not just what it looks like and feels like. Design is how it works.

設計不僅僅是外觀和感覺，設計還關乎它是如何工作的?！?/p>

——Steve Jobs

史蒂夫·喬布斯

上一篇，我們講了如何寫B(tài)RD，這是產品設計分層中的戰(zhàn)略層的產出物。

這里有人可能會問，為什么和所了解的“用戶體驗的五要素”的戰(zhàn)略層內容不太一樣呢？

確實，可能跟經(jīng)典的《用戶體驗的要素》這本書中所闡述的戰(zhàn)略層產出，有那么一些區(qū)別。

但沒有關系，活學活用。

我認為從本質上來說，產品的任何產出，必須要跟相關合作方有充分的共識后才有意義。

BRD就是和資源權利的擁有者（老板、客戶）所溝通后的產出。

那么同樣，今天我們所講的需求列表，就是按照“用戶體驗的五要素”的范圍層的本質定義，和項目組成員溝通后的結果。

1、什么是需求列表？本質上是任務清單

照樣先回答一個很基礎的問題，什么是需求列表？為什么說需求列表就是范圍層的產出。

那讓我們梳理一下需求列表的三個要素：做什么？誰來做？做多久？

做什么？

我們講了如何寫B(tài)RD，如果這一步通過了，不就已經(jīng)相當于領取到了重要的任務，那么下一步就要開干了。

可以點擊鏈接回顧一下，上次講過用黃金圈法則來寫B(tài)RD，其中講到了How（怎么做？方法、措施）和What（做什么？執(zhí)行、成果）的時候，其實就已經(jīng)相當于是需求列表的雛形了。

要做什么，本質上就是對目標進行任務分解。

如何做好任務分解呢？

我思考了很多，暫時還沒有能成制式的回答，只能說要依靠于：

1. 一定的項目管理經(jīng)驗；
2. 不僅僅對產品工作，而且對其他合作部門的大致工作都會有所了解（這其實也屬于產品經(jīng)理的素養(yǎng)之一）。

為了更好的來做說明，還是拿之前所舉過的例子來嘗試做一下任務分解：

某電商產品要加入信用支付。

經(jīng)過之前的上一步，通過BRD已經(jīng)闡述清楚：

市場上已有多個競品使用了此功能，并且預計可以較大的提升預訂轉化率。

并且獲得了立項資格。

那么，可能就根據(jù)經(jīng)驗，完成了如下的任務分解：

注意，表格中的每個大任務都可以分解成具體可執(zhí)行的任務，我僅僅只羅列出了產品的，其他部門的工作就不舉例了。

而在第2項產品的產出中，我羅列出了功能清單，這便是符合《用戶體驗的要素》的范圍層定義之一，其中還有內容或信息清單，屬于運營工作的部分。

但從更大的角度上來說，這樣一份的需求列表，會在整個項目工作中更加落地，更加實用。

誰來做？

此時就是組建項目組成員，讓我們加入一下：

做多久？

再把每一項的時間規(guī)劃一下，這樣就組成了互聯(lián)網(wǎng)公司的資源消耗大頭之一，也就是項目成本。

注意了，以上還是僅作虛擬舉例。真實的需求列表有可能會比這個要充實的多，也可執(zhí)行的多。

2、還有哪些要點呢？

做好內部溝通，先開小會再開大會

做需求列表的過程，其實也就是組建項目組的過程，考驗的也是一定的項目管理的能力。

我建議按照如下的方式來進展：

1. 列出方案：總結BRD已闡述清楚的目標，羅列出一個簡單的需求列表，切記不要直接拿BRD去做溝通，否則有拿老板或客戶去壓人的意思；
2. 索要資源：一一和各部門負責人要資源，同時確定更加合理的各部分的需求分解；
3. 正式立項：最后召集項目組的成員開大會，簡單的再次闡述目的，并展示需求列表，同時這也算是正式的立項大會。

當然，根據(jù)具體情況，也要靈活應對。

要可適用于項目進度看板

最終的需求列表，一定同時也等同于項目進度看板。

按照經(jīng)典的管理方式，也就是通過甘特圖來進行呈現(xiàn)。

可以使用微軟的project軟件，當然現(xiàn)在有很多在線的工具，支持的也挺好。

……