網頁制作poluoluo文章簡介：對於互聯網產品策劃來說，最終要拿給大家看的，就是一份策劃文檔，關於這份策劃文檔，我算是折騰了很久，總結了一些寫文檔時，要解決的一些問題.
最近休息得比較早， 覺得晚上寫日志，一寫就幾個小時，比較影響休息時間，故停寫了幾天，今天突然又想起一些事情要寫寫……
關於工作規范的自我評價，我一直都評了3.5，3.5是一個比較尴尬的分數，越形式主義，越主觀，越人性，越會給出超出自己能力的不客觀的分數，本來我應該給4分（最高是5）的，不過想想還是算了，一方面因為確實從來都是在摸索規范，如何規范；一方面因為沒有給出明確的工作規范，我也不知道什麼才是最規范的；另一方面，一些所謂的規范流程，由於還在實驗階段，基本上要使用嚴格去落實實驗階段的規范，溝通成本和學習成本也非常之大。
對於互聯網產品策劃來說，最終要拿給大家看的，就是一份策劃文檔，關於這份策劃文檔，我算是折騰了很久，總結了一些寫文檔時，要解決的一些問題：
給誰看？
有些策劃文檔，我真的看不懂，有兩方面原因：1.不是我自己寫的，2.不是寫給我看的。
在思考給誰看這個問題時，其實就應該不斷的思考自己在公司或策劃項目時所充當的角色，給誰看？當然是給你和你以外的人員，與自己一樣做其它項目策劃的人員、技術開發人員、美術設計、測試人員、市場人員、市場調研、上司、老板，另外還可能留到其它人員手頭上，正因為這樣，這份寫了你自己名字的文檔，有可能給你帶來很多影響，不同的人看了文檔，只要你沒有為對方考慮到，就會有很多問題找到你，後期會有很大的溝通成本。
作為文檔作者，你必須不斷的為這些人不斷地做換位思考 ，不斷地跟他們做可行性溝通，特別是技術、美術設計，這關系到項目是否能順利進行的問題。
還沒有寫文檔之前做什麼？
其實寫文檔之前，基本上都是頭腦風暴，討論和思考，關鍵是，頭腦風暴時，並沒有確認誰來做策劃和寫文檔，也沒有確認任務落在誰的身上，如果你是主策劃，也是項目的主導者，這倒還好，如果不是，又沒有必要的會議記錄，最終寫文檔時，可能之前討論過的一些細節，都有可能忘記，所以在寫文檔之前，有必要做一些分散的記錄，還有一些問題的收集。
當然，如果按最規范的做法和時間允許的情況下，應該有市場調研和數據分析，不過我一直認為，不需要所有操作都要經過形式上的市場調研和數據分析，一批合格的產品策劃人員本身就應該長期跟進產品，並深度地在使用產品，成為用戶的一份子，並有可能成為用戶意見領袖，只要是這樣，在寫文檔之前，其實已經掌握了大量的實現和用戶反饋，只是沒有書面的說明，但這些經驗性調研結果和實現，必須後期整理和書面表達出來。
開頭寫什麼？
項目名？實現方案？項目介紹？我認為是：給將要做的事情下一個明確的定義——項目定義。
最好還是解決項目名和項目名詞定義的問題，並通過文字寫下來，這是在解決要做什麼的問題，只有明白了做什麼，給將要做的事情下一個明確的定義，這個定義必須討論一致通過，再具體到具體實現模型。
項目名和項目名詞定義的標准是——可以單獨復制傳播放給別人看，當別人問這是個什麼樣的項目時，負責人員總能回答出來，所以，這要方便記憶，方便傳播，並表達清晰簡潔好理解。
接下來做什麼？
解決了項目定義，接下來是確定項目需求和計劃了，接下來應該嚴格根據定義列出所有與定義相關的需求點，並做出一些必要的分析，列出解決方案概要。
當然如果項目相對比較大，需求點會分步完成，相應的解決方案也會分步給出，不過我始終認為，初期的項目規劃，從定義出法，需求點分得越細越好，再使用科學的方法找出最重要的，對復雜的項目來說，再給出分期的解決方案，要解決哪最重要、最核心、哪個是架構、哪個優先級更高的問題。
要是這些問題沒有解決好，後期就很容易被人問：這個功能什麼時候會做？ 沒有計劃好，你答也答不上，要是別人總來咨詢你的計劃和解決方案，這不是什麼好事情，這絕對是你的項目要做什麼、准備什麼時候做，這些問題沒有考慮周全，並沒有很好的跟別人溝通，特別是整天關注你產品的上司。
接下來，需求確認
所謂的需求確認，就是確認項目定義、項目需求、解決方案、產品上線計劃等問題，確認無誤，再進行下一步操作，這樣能避免後期做實現方案的很多問題，如優先級、做什麼、怎麼做這些問題。做需求確認時，對產品負責人員有很多要求，如何讓項目相當的人員、非項目組對項目相當的人員明白你的產品方面和思路？
口頭表達固然重要，要用到簡單明了的PPT，最簡潔清楚的口頭描述，所謂產品人員的說服力，在需求確認會上最容易表現了。另外，工作以外，你也可以有意沒意地在向大家傳達你的產品理念，讓你的產品設計更有說服力，這樣能減少很多咨詢分子對你的騷擾。
當然通常有經驗的設計人員，在前面兩個步驟沒有明文出現時，已經做出模型了，我不否認這種做法，因為能完成模型的人員，在完成模型之時，腦海裡已經有了初步的產品需求模型，並了解了項目設計的出發點，有模型或產品構思圖，可以幫助思考問題，口頭經過討論和確認後的需求，做出核心的產品模型，這樣更具體的模型測試能得到更多的討論和反饋，減少文檔返工的可能性，減少寫文檔需要重復修改的時間和溝通成本。
但最終方案的文檔，還是必要從“項目定義”“項目需求和計劃”重新做起，並在模型上不斷做調整，讓模型更完善可行。
今天先寫到這裡……
其實上面過程還有很多細節沒有提及，不過靠譜的產品策劃，基本不用看我的這些文字，這些問題都是新手上路過程中慢慢摸索出來的，另外，這日志要表達的不是什麼文檔寫作流程和規范，我連自己文檔也在沒有規范的環境下慢慢摸索和改進中……