在我心里，寫文檔不只是創(chuàng)作一個作品，更多的是時候，是將我心里的想法，組織成文字，寫下來，讓我可以看得見，也讓別人看得見。協(xié)作中，讓對方看見文檔，便有了更多的「共同語言」去討論同一件事情。而這，在解決復雜問題的時候尤其有用。
這篇文章來自我在公司內(nèi)部的一次分享，關于我自己是如何用「寫文檔」這個方法，去提高解決問題的效率。
作為一名產(chǎn)品經(jīng)理，我們天生的嗅覺就是發(fā)現(xiàn)各種問題，并且解決它。你可能聽說過產(chǎn)品經(jīng)理要寫各種需求文檔，可以說需求文檔本身就是用「寫文檔」提高效率的手段。但解決一個問題的過程往往從收集問題就開始了，我聚焦說明在一個問題從產(chǎn)生到最終落地解決方案的過程之間，我們還能做好哪些工作。而這些工作，我觀察到，很多產(chǎn)品經(jīng)理之前都是忽略的。文章聚焦于方法的共享，因此很多思路不僅僅是關于如何寫，其實更多地是關于如何用更加有效率的方法去做事情。在一個問題從誕生到解決的過程中，我們此刻已經(jīng)在用一些方式去完成每一個環(huán)節(jié)了，但每一個環(huán)節(jié)，其實都有潛在的效率損失。
| | |
| | |
| 1、逐個溝通
2、約大家時間開個會統(tǒng)一了解情況 | |
| | |
| | |
我相信這里有幾個大家常見的痛點：
1、收集到的問題不一定是真問題。這里的「真」包括兩個意思：要么，這不是提問者想要解決的問題，被曲解了；要么，這個問題沒什么意義。
2、想要找一個人明確問題，但他們可能總是不在位置上
3、開會、開會、開完會也沒有解決問題，會議效率太低了。
4、跟老板做階段性匯報，卻發(fā)現(xiàn)效果并不好，每次都不如預期。
5、解決方案總是變，工期一拖再拖。
三
所以，怎么辦。或者說，在每一個解決問題的要命的點，我們還能怎么提高效率呢。
來，我們看看那幾個痛點。
問題不是真問題怎么辦？
那就在收集的時候，回到本質去梳理這個問題。
找一個人，TA總是沒有在？
那就用異步溝通，準備好一切，讓TA在方便的時候處理。不要讓等待成為影響你解決這件事的效率瓶頸。
會議效率太低了？
那就先做好會議準備工作。
我在飛書組織進化論的聽友群，看到過一篇文章，關于如何組織一場高效的會議，我的理解是，你在會議前的準備工作越完善，會議效率就會越高。（點擊最下方的閱讀原文可以看到這篇文章）
解決方案總是一變再變？
首先把為什么要變，當作一個問題處理，走一遍這個流程，然后真的要變了，就做好記錄和同步吧。
千萬不要一部分人以為變了，另一部分人以為沒有變，這種扯皮對于組織的效率是極大的內(nèi)耗。
匯報質量不高？
那就更要往下看，如何做好一場工作的階段性同步了。
總的來說，提高效率的方法如下：
| | | |
| | | 通過結構化的表格，在問題的整理階段就完成部分理解工作 |
| 1、逐個溝通
2、約大家時間開個會統(tǒng)一了解情況 | | |
| | | |
| | | |
而我呢，一般會用「寫文檔」的方式，去將每一步的提高方法落地。
| | |
| 通過結構化的表格，在問題的整理階段就完成部分理解工作 | |
| | |
| | |
| | |
四
先講講，問題匯總文檔怎么寫。
我會總結為如下幾個步驟：
第二，這個問題的最小結構是怎么樣的。所謂最小結構，就是講清楚了這幾個點，這個問題是不是一個真問題，就基本能判斷出來了。第三，將最小結構變成收集問題的表格。為什么一定要用表格，這是為了讓提出問題的人，也能按照表格規(guī)定的結構去將問題描述清楚。如果不做任何限制，相信我，大家對于問題的描述要么很簡短，要么廢話一堆，總之，后續(xù)的理解成本非常高。
對于絕大多數(shù)問題來說，基本都是這三個要素：
最后你會發(fā)現(xiàn)，收集的每個問題，不一定都是有最小結構的，比如why和how，在收集的時候沒有答案，那表格里空缺的，就是待討論的問題。但價值在于，我們知道了對于這個問題來說，還需要討論的地方是什么，很精準。
那問題匯總的文檔該怎么寫？我以自己的實踐來做個說明。
但為了篇幅考慮，后續(xù)的其他文檔我都只說方法，實操經(jīng)驗如果你有興趣，可以添加我的微信跟我交流。
1、說明
我強烈建議為解決問題而產(chǎn)生的文檔最好有說明，讓看這個文檔的人，在最短時間內(nèi)知道這個文檔的作用是什么。
2、找誰收集
退款3.0版本的需求，一方面來自產(chǎn)研在2.0版本中遺留下來的問題，尤其是測試過程中發(fā)現(xiàn)的缺陷，我們放在3.0版本解決。一方面來自客服在實踐中提出的新需求。
3、已收集問題
注意，如果某個模塊你需要用很大的一段篇幅去寫，那我建議單獨成一篇文檔，再去引用就好。上圖中，第一個問題其實我已經(jīng)調(diào)研好了解決方案，所以我就用一篇文檔單獨描述并引用了。
4、不確定信息
第2個需求，是什么和為什么，目前產(chǎn)研側不太理解，需要組會討論，在需求消化階段解決。
問題說明是認領這件事的負責人，對收集來的問題做的二次加工，目的是為下一步的開會討論做準備。如果想要對已收集問題中信息缺失的部分做補充。有兩種方式：2、專門開一次會做討論，也可以跟之后的推動問題的會議一起討論。問題說明文檔的判定標準，是針對每個問題，最后都有一個完整的，且能夠直接拿來討論的結構，而不需要對問題本身再做重定義。
七
如何用「寫文檔」去準備一場會議？
不知道會議目標是什么，不知道我去了該干嘛，不知道自己應該說些什么，不知道開完之后要做些什么。那如果你是會議的組織者，你該如何用「寫文檔」的方式，給會議提效呢？
目標是這個項目的大目標，期望輸出是這次會議應該有的作用。比如我們的目標，可能是實現(xiàn)大促100萬收入，但這次會議的期望輸出，是整理出3個能落地的方案供下一次討論。如果討論的是新問題，那就要說明一些背景知識，確保大家都知道；如果要討論的是老問題，最好寫一下現(xiàn)階段的情況，以及之前討論的核心結論。什么是新問題，什么是老問題，是會議組織者要去評估的。怎么評估？看參加的人，你得去想對這些人來說，即將要討論的是新問題還是老問題。
所以，了解每個人對于這件事的了解程度，是非常重要的。切忌完全以自我為中心去組織一場會議，不要把參與者當成純粹的工具人。
發(fā)散類型的問題，最好設計一個框架表格，做結構化的限制。參考問題收集文檔。
想清楚誰要來參加，不要一下子邀請整個部門或者整個群。
明白誰需要提前看文檔，不管別人看不看，你都要先準備好。盡量不要依賴別人，去養(yǎng)成你自己的好習慣。最后的最后，千萬不要忘記了，提前溝通好，誰來做會議紀要。
關于會議紀要的寫法，其實飛書文檔里已經(jīng)給了非常清楚的結構，所以我在這里只是做一下簡單的說明。
但有一點是很重要的，一定要先確認好，誰來記。哪怕不是按照模版來，哪怕你之后自己去整理，也總比沒人記下任何內(nèi)容要好。
一定要實際參加的，而不是call到的人，沒有來就是沒有來。參會代表了你對會議中發(fā)生了什么是了解的，如果沒有異議，那對會議紀要中的共識就是認可的。更重要的，準確記錄下參會人，對于他們來說是一種尊重和督促。那些沒有來的人，有什么資格共享會議的成果呢。
我一般會在議程部分加上會議準備文檔，說明為這個會議提前準備的內(nèi)容是什么。當然除這個之外，常規(guī)的議程該怎么寫就怎么寫。結論就是共識。包括兩種：確認的和不確定的。注意，「我們在這件事上有分歧」以及「什么事情不確定，下來要確認下」這兩個結論本身也是共識，這是之后要去解決的。很多人都會有意識去寫todo，但很多人也會發(fā)現(xiàn)，todo寫了，后面到底怎么樣了，不知道。我對todo的建議是：1）最好是一周內(nèi)要去做的事情，太久了就不好追蹤了；2）有明確的責任人和時間，這就是一項任務，大家嚴肅一些，也是對會議本身和各自時間的尊重。關于會議紀要，我最大的體會是：如果你不記，往往就會出問題。在這方面，墨菲定律是很準的（墨菲定律：你擔心的事情往往更容易發(fā)生）
九
會開完了，事情也有了進展，那么如何把階段性匯報做得更好呢？
根據(jù)匯報對象組織你的匯報內(nèi)容，我們公司CEO的這個建議應該更清楚。在這里我對于如何組織why what how這三部分的內(nèi)容談談自己的理解：1）不理解why：那就通過數(shù)據(jù)、行業(yè)、用戶反饋、以及向上進一步溝通解決。在文檔里把你可以想到的，可以查到的所有資料，組織起來，最后用一兩句在開頭寫出來，到底是什么問題在困擾你。2）不知道該做什么：重點是把你認為可以解決問題的what，都列舉出來，有沒有想清楚都可以，但一定要寫在文檔里。（落地1個方案，需要先想10個方案）3）不知道該如何落地：實操，不斷地實操和總結。但這個問題對產(chǎn)品經(jīng)理來說一般不是問題。那是不是，根據(jù)不同的對象，只需要準備對應的部分就可以了呢？并不是，你還是要把這三個問題都想一遍，都寫一遍，只是你可以挑重點說而已。
結尾
你可能會覺得，這么麻煩呀，我能寫好么？
我一直認為這是個意識和習慣的問題：
你得首先認可這件事的價值。如果你意識不到低效率的工作方式對你的損耗，可能你就看不見高效率工作帶來的甜頭。更多關于職場進階的思考，歡迎掃碼了解大力哥的知識星球
