最近休息得比較早， 覺得晚上寫日志，一寫就幾個小時，比較影響休息時間，故停寫了幾天，今天突然又想起一些事情要寫寫……

關(guān)于工作規(guī)范的自我評價，我一直都評了3.5，3.5是一個比較尷尬的分?jǐn)?shù)，越形式主義，越主觀，越人性，越會給出超出自己能力的不客觀的分 數(shù)，本來我應(yīng)該給4分(最高是5)的，不過想想還是算了，一方面因為確實從來都是在摸索規(guī)范，如何規(guī)范;一方面因為沒有給出明確的工作規(guī)范，我也不知道什 么才是最規(guī)范的;另一方面，一些所謂的規(guī)范流程，由于還在實驗階段，基本上要使用嚴(yán)格去落實實驗階段的規(guī)范，溝通成本和學(xué)習(xí)成本也非常之大。

對于互聯(lián)網(wǎng)產(chǎn)品策劃來說，最終要拿給大家看的，就是一份策劃文檔，關(guān)于這份策劃文檔，我算是折騰了很久，總結(jié)了一些寫文檔時，要解決的一些問題：

給誰看?

有些策劃文檔，我真的看不懂，有兩方面原因：1.不是我自己寫的，2.不是寫給我看的。

在思考給誰看這個問題時，其實就應(yīng)該不斷的思考自己在公司或策劃項目時所充當(dāng)?shù)慕巧?，給誰看?當(dāng)然是給你和你以外的人員，與自己一樣做其它項目 策劃的人員、技術(shù)開發(fā)人員、美術(shù)設(shè)計、測試人員、市場人員、市場調(diào)研、上司、老板，另外還可能留到其它人員手頭上，正因為這樣，這份寫了你自己名字的文 檔，有可能給你帶來很多影響，不同的人看了文檔，只要你沒有為對方考慮到，就會有很多問題找到你，后期會有很大的溝通成本。

作為文檔作者，你必須不斷的為這些人不斷地做換位思考 ，不斷地跟他們做可行性溝通，特別是技術(shù)、美術(shù)設(shè)計，這關(guān)系到項目是否能順利進(jìn)行的問題。

還沒有寫文檔之前做什么?

其實寫文檔之前，基本上都是頭腦風(fēng)暴，討論和思考，關(guān)鍵是，頭腦風(fēng)暴時，并沒有確認(rèn)誰來做策劃和寫文檔，也沒有確認(rèn)任務(wù)落在誰的身上，如果你是 主策劃，也是項目的主導(dǎo)者，這倒還好，如果不是，又沒有必要的會議記錄，最終寫文檔時，可能之前討論過的一些細(xì)節(jié)，都有可能忘記，所以在寫文檔之前，有必 要做一些分散的記錄，還有一些問題的收集。

當(dāng)然，如果按最規(guī)范的做法和時間允許的情況下，應(yīng)該有市場調(diào)研和數(shù)據(jù)分析，不過我一直認(rèn)為，不需要所有操作都要經(jīng)過形式上的市場調(diào)研和數(shù)據(jù)分 析，一批合格的產(chǎn)品策劃人員本身就應(yīng)該長期跟進(jìn)產(chǎn)品，并深度地在使用產(chǎn)品，成為用戶的一份子，并有可能成為用戶意見領(lǐng)袖，只要是這樣，在寫文檔之前，其實 已經(jīng)掌握了大量的實現(xiàn)和用戶反饋，只是沒有書面的說明，但這些經(jīng)驗性調(diào)研結(jié)果和實現(xiàn)，必須后期整理和書面表達(dá)出來。

開頭寫什么?

項目名?實現(xiàn)方案?項目介紹?我認(rèn)為是：給將要做的事情下一個明確的定義——項目定義。

最好還是解決項目名和項目名詞定義的問題，并通過文字寫下來，這是在解決要做什么的問題，只有明白了做什么，給將要做的事情下一個明確的定義，這個定義必須討論一致通過，再具體到具體實現(xiàn)模型。

項目名和項目名詞定義的標(biāo)準(zhǔn)是——可以單獨復(fù)制傳播放給別人看，當(dāng)別人問這是個什么樣的項目時，負(fù)責(zé)人員總能回答出來，所以，這要方便記憶，方便傳播，并表達(dá)清晰簡潔好理解。

接下來做什么?

解決了項目定義，接下來是確定項目需求和計劃了，接下來應(yīng)該嚴(yán)格根據(jù)定義列出所有與定義相關(guān)的需求點，并做出一些必要的分析，列出解決方案概要。

當(dāng)然如果項目相對比較大，需求點會分步完成，相應(yīng)的解決方案也會分步給出，不過我始終認(rèn)為，初期的項目規(guī)劃，從定義出法，需求點分得越細(xì)越好， 再使用科學(xué)的方法找出最重要的，對復(fù)雜的項目來說，再給出分期的解決方案，要解決哪最重要、最核心、哪個是架構(gòu)、哪個優(yōu)先級更高的問題。

要是這些問題沒有解決好，后期就很容易被人問：這個功能什么時候會做? 沒有計劃好，你答也答不上，要是別人總來咨詢你的計劃和解決方案，這不是什么好事情，這絕對是你的項目要做什么、準(zhǔn)備什么時候做，這些問題沒有考慮周全， 并沒有很好的跟別人溝通，特別是整天關(guān)注你產(chǎn)品的上司。

接下來，需求確認(rèn)。

所謂的需求確認(rèn)，就是確認(rèn)項目定義、項目需求、解決方案、產(chǎn)品上線計劃等問題，確認(rèn)無誤，再進(jìn)行下一步操作，這樣能避免后期做實現(xiàn)方案的很多問 題，如優(yōu)先級、做什么、怎么做這些問題。做需求確認(rèn)時，對產(chǎn)品負(fù)責(zé)人員有很多要求，如何讓項目相當(dāng)?shù)娜藛T、非項目組對項目相當(dāng)?shù)娜藛T明白你的產(chǎn)品方面和思 路?

口頭表達(dá)固然重要，要用到簡單明了的PPT，最簡潔清楚的口頭描述，所謂產(chǎn)品人員的說服力，在需求確認(rèn)會上最容易表現(xiàn)了。另外，工作以外，你也可以有意沒意地在向大家傳達(dá)你的產(chǎn)品理念，讓你的產(chǎn)品設(shè)計更有說服力，這樣能減少很多咨詢分子對你的騷擾。

當(dāng)然通常有經(jīng)驗的設(shè)計人員，在前面兩個步驟沒有明文出現(xiàn)時，已經(jīng)做出模型了，我不否認(rèn)這種做法，因為能完成模型的人員，在完成模型之時，腦海里 已經(jīng)有了初步的產(chǎn)品需求模型，并了解了項目設(shè)計的出發(fā)點，有模型或產(chǎn)品構(gòu)思圖，可以幫助思考問題，口頭經(jīng)過討論和確認(rèn)后的需求，做出核心的產(chǎn)品模型，這樣 更具體的模型測試能得到更多的討論和反饋，減少文檔返工的可能性，減少寫文檔需要重復(fù)修改的時間和溝通成本。

但最終方案的文檔，還是必要從“項目定義”“項目需求和計劃”重新做起，并在模型上不斷做調(diào)整，讓模型更完善可行。

今天先寫到這里……

其實上面過程還有很多細(xì)節(jié)沒有提及，不過靠譜的產(chǎn)品策劃，基本不用看我的這些文字，這些問題都是新手上路過程中慢慢摸索出來的，另外，這日志要表達(dá)的不是什么文檔寫作流程和規(guī)范，我連自己文檔也在沒有規(guī)范的環(huán)境下慢慢摸索和改進(jìn)中……

更多信息請查看IT技術(shù)專欄