產品周期01/2期
「產品周期」將是我工作之餘的一點心得分享，主要與產品經理的工作相關，不定期更新，一方面是鍛煉自己的文字表達，另一方面也是督促自己的學習。寫東西的想法由來已久，一直遊離於各個平台，零零散散地寫了一些，但堅持一個系列的並不多，系統的學習與整理，一直是我想做的。
>>>>>>這是分割線
圖-產品項目管理
產品周期系列將圍繞自己的實踐經歷，以上圖總結軸線為例，將產品經理這一塊的整個流程分幾期來闡述。上圖是開發和產品陣營，還有運營陣營，將會在以後補充。順序上，期望是打亂刻板的線性流程，即打亂傳統意義上的產品周期，但最終又巧妙的串起來，沒錯，我崇拜的是昆汀的非線性敘事。
本期想說的是溝通與規範。各行各業，各個職業，需要溝通協調時候，溝通技能是必備的，產品經理角色的溝通技能尤為重要，正常的流程還好，大家都能好好溝通，但當發生甩鍋事件時，如何去溝通就尤為重要了，而為了避免甩鍋事件的發生，前期依靠規範的約束，良好溝通才是關鍵。
關於溝通的一些小建議：
溝通前：針對此次溝通，理清楚核心點是什麼，切入點又是什麼，價值點又是是什麼，即說什麼what（是提需求，改需求，改方案，改排期還是交付）；怎麼說how（老闆提了個需求，因戰略調整需要改動，為了給某個需求擠時間，咋們這個得抓緊等）；為什麼要說why（怕事後改動成本太高、戰略調整後需求加急等）。
溝通中：結論先行。尤其是組織會議的時候，一群人排出時間是來聽你「布置」任務的，並不是來和你討論怎麼做的。所以，上來先說結論，而這個結論是要在溝通前完完全全準備好的，比如：因公司戰略調整，老闆說，咋們這個得抓緊做，先滿足上線需求，某某需求就先不做了，需要開發騰出時間把其他的做出來，我們期望某某時間提前上線，所以今天把大家叫過來，趁架構還沒定下來，在不影響你們架構的情況下，提出需求改動。說完後，詢問大家意見，要確定每一個相關人員對此結論無異議後開始說改動方案。另外，重要的一點，一定要做會議記錄，記錄與會人員，各自觀點、承諾。如果與會人員不能代表相關部門的話，需要拿著會議記錄找負責人確認簽字。
溝通後：實時跟進。產品經理如果只負責某個模塊的話，那麼你就是這個模塊的項目經理，你要對整個流程瞭然於胸，而且要知道各方在相關時間點上需要到什麼進度，所以這就要求你要做好事後的溝通，來確保項目的順利實施，尤其是線性工作中，某個環節的拖期會造成整個項目延期，重則成為受批評的延期事故，輕則造成資源浪費。因此，通過溝通來告知協調各方進度，保證順利如期完成。
關於規範的一些說明：
流程規範：流程就是各方在整個產品周期上橫向的時間和縱向的權責上形成的共識約定，而這個約定對於各方具有強約束性，可讓領導簽字生效。這種約定對於大公司來說可能是部門之間的配合，對於小公司來說可能是項目組各團隊之間的配合。就比如說，小公司項目組中，產品對需求分析篩選形成確定方案後，出原型、PRD，交付開發，通知UI出方案，產品經理對UI有否決權，甚至有UX的角色，也可以參與進來，開發根據PRD,原型，UI進行開發，完成後測試發版，通知上線，而測試對於發版頁有否決權；上線後的培訓、運營。而其中某個環節的變動，必定是牽一髮而動全身的，所以要盡量避免改動，改動時的全員告知反饋約定，就類似於區塊鏈的分散式記賬，原則上都有知情權。其實對於改動也可以出一些約定規範，比如盡量去做減法，類似於可有可無的不要。
文檔規範:可根據自己實際情況，制定相應的文檔規範，比如各方需要產出的文檔是什麼，用來幹什麼，除了用於工作，還會不會涉及考核憑證等。具體到文檔內容，可規定格式、必填項等。甚至是需要制定產品方案的規範，比如視覺規範，布局交互規範等，這些都是必不可少，如阿里內部分明的藍色金融系、橘色電商系；騰訊的綠色微信系。
人員規範：所有的規範都是圍繞人來進行的，目的是提高工作效率，減少誤差。回過頭看，如果溝通好了，還需要這些規範嗎？可以肯定的是，正因為溝通具有太多不確定因素，所以才需要這些規範來補充。人員的規範，這個人可以是部門，可以是團隊，可以是個體。每個「人」都有自己的個性，而如何通過規範來把這些人結合起來協調高效，也是必要的。這個規範，可以是對行為的規範，也可以是對管理的規範，需要領導出馬的就用領導。
從需求到產品，是要依靠規範流程去實施的，而各個環節又有自己的規範，若以單純的文檔來看，有些是強約束，而各個環節口頭上的承諾是依靠溝通爭取來的弱約束。既然規範存在的目的就是為了保證需求到產品的實施，並為整個產品周期保駕護航，那麼各個環節都需要以規範的強約束來認定。現在的問題是，流程中某個環節只過度依靠某個規範，對於一個團隊，這種問題一方面是由於各個環節沒有大局觀，對於對方的工作認識太片面，形成一種刻板印象，另一方面，產品經理得背鍋。所以靠規範，甩鍋的時候你就能有理有據？那也不可以。
TAG:峰光junior |