上線郵件能讓關鍵人員知道項目已上線並知道下一步要做什麼，還能幫助產品經理讓覆盤更從容和高效。
以前我所在的公司，當有項目或功能上線後，是不要求寫上線郵件的。因此每次上線後，除了產品經理和運營同學會關注，其他同學都不知道。
產品經理會關注，是因為要跟蹤功能上線後的數據表現。運營同學會關注，是因為上線後，需要進行投放適當的運營活動。
但當我來到目前所在的這家公司後，每次上線都要求寫上線郵件。一開始覺得不以為然，但當寫了一段時間後，逐漸發現了寫上線郵件的好處。於是有了這篇文章。
接下來我就用3w1h的結構，和你分享下為什麼寫上線郵件以及誰在什麼時間，該如何寫上線郵件。
Why：為什麼寫上線郵件？
當這家公司要求寫上線郵件時，我每次寫上線郵件都問自己，到底為什麼寫上線郵件？寫上線郵件是為了解決什麼問題？以下是我的思考：
1. 解決關鍵人員不知道項目已上線的問題
一個項目中，關鍵人員一般有：產品、UE、UI、研發、測試。在這個項目協作的過程中，大家各自的完成時間節點是不一樣的。
如果關鍵人員不知道項目已上線，就會造成他們不知道自己是該繼續等待解決該項目的問題，還是可以接其他項目的工作了
在多個PM共同協作時，如果不知道其他人做的某個功能已經上線了。會導致，有的時候其他PM想做一個功能，設計方案出來後，發現別人居然已經做了，並且已上線，造成整體產出效率低下
還有另外一種情況是，一款產品中，好多功能與功能之間是可以做聯動的，如果沒有上線郵件通知，就會不知道最近有什麼功能上線，沒辦法看看自己負責的功能模塊和別人的功能模塊是否可以形成合作或聯動關係
2. 解決相關人員不知道下一步要做什麼的問題
如果不發上線郵件，同步大家下一步要做什麼。會導致工作有短暫的停滯，造成資源的浪費。而且如果大家知道接下來的一些計劃，會讓大家提前有個心理準備，也好提前做一些準備工作
並且上線郵件中寫下一步計劃，有利於鍛鍊自己的產品規劃能力
3. 解決跨部門需求，其他部門不知道已上線，造成嚴重損失的問題
有些需求是跨部門的，此功能上線後，對應的部門要進行相應的跟進和處理。
例如我們產品，前些日子剛上線了全局資源位的功能，這個是需要不同部門的運營同學一起跟進使用。總共涉及A、B、C共計3個運營部門
如果我不發郵件通知大家，就會造成每個部門的運營同學都在焦急等待功能上線，好投入使用。但殊不知功能已上線，卻沒運營同學配置活動進行投放。這會造成嚴重的損失。具體表現為：
給平臺造成的損失是成本過高，明明已經花費了研發成本進行研發完畢，但運營同學卻沒及時使用，這個時間差，造成了平臺的整體運營成本提升，對利潤有損害
給運營同學造成的損失是，沒及時對用戶進行觸達，無法產生利潤，導致自己KPI有壓力，而且沒有用戶使用，導致沒有數據產生，無法進行數據分析
寫上線郵件，還會有個較大的收穫和感觸
年終或季度述職時，好多人不知道寫什麼，有的是寫了，但感覺寫的不好。不知道寫什麼會造成花費太多時間在寫述職上面，付出回報不成正比。
寫了，但是感覺寫的不好，可能會造成在最終和其他PM進行PK時，很容易被PK掉。
這時如果是對寫上線郵件的同學來說，就沒有這個困擾了。他可以按照時間線去查看自己的上線郵件。是什麼時間上線的這個功能，都有哪些同學參加等等信息都非常清楚。
而寫上線郵件相當於1個小覆盤，能夠解決，當你想輸出，卻回想不起來的問題。用這些日積月累的小覆盤來做大覆盤，會讓你的覆盤更從容，也更高效。
相信同樣寫上線郵件的你，也有同樣的感觸吧？真的是很受益，趕緊寫起來吧。在實踐中，找到它的意義
Who：誰寫上線郵件？
上面說了寫上線郵件的益處，也就是為什麼要寫上線郵件。那接下來我們就說說這個上線郵件到底該由誰來寫呢？
有的人說應該是項目經理，有的人說應該是測試，有的人說應該是產品經理。我個人是贊成產品經理來寫的，為什麼呢？
- 產品經理對這個項目的背景最清楚，知道這個項目為什麼立項，立項是想達到什麼樣的目標？這些信息都非常重要，需要在郵件中給大家闡述出來，大家才能更好的理解該項目
- 多數產品經理是項目進度的把控者，當前項目進展到哪一步了，產品經理瞭解的最清楚。因此產品經理的信息是具有及時性的，那由他來發郵件，信息也會更及時
由此，我個人認為上線郵件由產品經理來寫，更合適
When：什麼時間寫上線郵件？
那到底什麼時間寫上線郵件合適呢？這個和郵件的類型有關係
- 如果是功能上線需要同步關鍵人員，建議是當天就寫，這樣大家好及時瞭解並體驗，有問題的話，也好及時反饋。
- 如果郵件類型是提醒大家關注功能上線後的數據結果，可以等功能上線幾天後，有了一定的用戶數據，在發送郵件
How：如何寫上線郵件？
不同類型的郵件包含內容不同。可根據郵件類型不同，靈活配置不同內容。接下來我以功能上線需關鍵人員知曉的郵件類型，進行草擬郵件，供大家參考~
Dear All：
【上線項目名稱xx】已上線，上線時間：xx-xx-xx，請大家周知~
首先，我會先用這個來直接給出結論。好節省查閱者的時間，讓他能夠第一時間get到我這封郵件想表達的內容，便於他做出是否繼續閱讀的決定。
為查閱者節省時間，這也是在為用戶創造價值吧，哈哈哈，要時刻想著用產品思維吖~
1. 項目價值
可以寫項目價值，也可以寫項目的背景或目標。建議不要寫太長，用簡潔的語言來表述。如果是寫目標的話，建議寫的具體點，不要大空話，給人不真實的感覺
2. 功能簡述
- 項目核心功能list：如果是大的項目或功能，可以寫下項目的核心功能list，方便大家快速get到此項目的一些關鍵點
- 要附上詳細功能說明的文檔鏈接。每家公司都有自己的文檔管理軟件，有的公司用wiki，有的公司用tapd。不用糾結於工具，只要把文檔鏈接附上就好了
這樣當別人看到你的郵件，想了解項目更多信息的時候，就可以點擊鏈接進行查閱了。減少詢問，降低溝通成本
3. 項目部分截圖
1000個字抵不上一張圖，如果是C端項目，那建議一定要附上截圖。有的人可能沒時間去詳細看核心功能list，直接看的圖就能快速get到，這2者獲取信息的效率是不一樣的。
後臺的項目可能放圖的效果不如C端那樣明顯，但確實也還是會比文字獲取信息的速度更高些
4. 項目成員
項目成員包括，負責這次項目的UI、UE、研發、測試同學
5. 下一步的計劃
下一步計劃可以從運營側和產品側這2個方面進行考慮。
- 運營側。需要考慮，如果上線後需要運營同學配置信息，那應該通知到具體的人。
- 產品側。這就是你基於對自己項目的思考，規劃接下來可能要做哪些事情。一方面有利於你鍛鍊自己的產品規劃能力，一方面也有利於大家提前瞭解項目的方向，能夠提前做一些準備
最後寫下感謝致語，自己的聯繫方式，方便大家有問題的話，好聯繫你。
寫在最後
功能上線1-2個月，如果有數據分析結論，可以在當初上線郵件的基礎上，做一次數據分析彙報。讓團隊成員看到自己做的事情的價值。也為接下來的版本迭代提供數據支撐。
本文由 @產品躍遷 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
