活動運營（四）如何撰寫活動開發需求

01-29

五一節快樂，勞動最光榮！

首先說句抱歉，因個人最近生活發生了些變化，包括事業上，家庭上等，因此距離上一次更新已拖了近1個多月的時間。現在一切事情已處理完畢，接下來會按時更新，感謝未取關的各位耐心等待哈。

活動運營系列已推送完前面三篇，今天更新最後一篇——如何撰寫線上活動的開發／設計需求。

如何快速構思一個線上活動 √

如何寫一份線上活動方案 √

如何進行活動原型設計√

如何撰寫線上活動的開發／設計需求

因為設計需求相對而言比較簡單，且原則相差不大，因此本篇主講開發需求。

基於上一篇的經典三問頗受好評，本篇延續 是什麼、為什麼、怎麼做 的框架來簡單科普。

需求文檔是什麼？

國際慣例，先看度娘——

度娘居然沒有……好吧……

其實所謂需求文檔，就是以用書面的形式，向程序員告知活動的具體開發需求。

可能有人會問，上一篇講交互設計，不就已經清楚解釋我們的開發需求了么？

其實交互設計只是把活動頁面中的需求提出來了，但是很多規則、邏輯其實是不體現在頁面前端的，比如說獎品的設置，抽獎的概率和次數限制等等，這些都需要更加詳盡的文檔（結合交互設計）來說明。

為什麼需要撰寫需求文檔？

之所以要撰寫需求文檔，就是為了讓程序員按照你設想的計划去開發整個活動。開發需求越細緻，則開發出來的效果越符合預期。

有的人可能還不理解，程序員不是萬能的么，我說下我要幹什麼，他們不就能全部搞定么？

是是是，他們當然能搞定，畢竟這是一群可以改變世界的人嘛（溜須拍馬之嫌）。

但是，你好歹得跟人家說清楚具體怎麼做吧。

比如說你想把大象放進冰箱，你不能只跟程序猿們說請把大象放進冰箱。

為什麼不能？

因為你想啊，把大象放進冰箱可以有好多種選擇，

是要整隻扔進去？切塊放進去（好殘忍）？是頭朝下？還是臉朝外？

所以，為了開發GG更好地按照你的設想來做，你應該這麼告訴他：

第一步，請打開冰箱門

第二步，請把大象完整地放進冰箱，並且頭部朝上

第三步，請關上冰箱門

因此勒，為了讓活動按照你設想的方向進行，就要儘可能詳細地寫清楚你的開發需求拉。

怎麼寫？

大概分為兩步。

第一步，需求溝通

在實際工作中發現，無論怎樣，文字描述終究無法很清晰講清楚一個活動需求的，且每個人對文字的理解還存在偏差。因此最好的辦法，是撰寫需求之前，先跟程序員碰下（人數不多的叫碰頭會，大家碰一碰，把不清楚的地方確認下；人數多的，該叫評審會了，把相關人員拉一起，由策劃人講解活動需求，然後開發哥哥們逐一確認）。

第二步，撰寫需求文檔

需求確認了，接下來就是需求文檔撰寫了，大致的結構如下（當然這是活動策劃的開發需求，產品方向的會更加細緻一些，此處不講）

（1）活動規則與流程：寫明整體活動規則及流程

（2）活動頁面示意：結合交互設計，展示頁面示意

（3）具體功能需求：解釋每個頁面涉及的前後端邏輯需求、功能需求

（4）報表需求：活動需要監控哪些數據，報表央視等等

關於開發需求的原則，重點強調兩個

（1）儘可能詳細

如上述，開發需求越細緻，則開發效果就越接近原本設想。

就如簡單的一個頁面切換，就有許多種不同形式。是要點擊後，直接跳轉至下一活動頁面，還是要通過頁面向右／向左／向上／向下移動的方式進入到下一個活動頁面？

因此，開發需求儘可能詳細。

（2）儘可能簡潔

開發需求就是為了解釋需求所用，所以廢話請儘可能的少，因為程序員GG們真的很忙（溜須拍馬+2）。開發需求里不需要長篇大論，不需要咬文嚼字，用儘可能少，儘可能清楚的語言，把你想做的事情交代清楚即可。

以上，就是關於如何撰寫線上活動開發需求的內部。

按照慣例還是分享一份需求文檔做參考吧。不一定很嚴謹完善，僅供參考。

關注公眾號：羊陪家，直接回復：開發需求

活動運營系列的四篇暫告一段落。關於運營還有一些主題，比如如何寫活動總結，如何寫年度運營計劃等等，會陸續更新的。大家在運營方面有什麼問題，也可以向我留言，合適的話會整理成文章進行解答分享。

另外，從5月份開始，公眾號（羊陪家）會開始更新一些關於個人理財方面的分享，這也是本人特別特別想分享的一個領域，敬請期待，歡迎探討。