?本文接《這些年做產(chǎn)品踩到的坑，和犯過的錯（一）》，作者分享了自己在做產(chǎn)品過程中遇到問題后總結(jié)出的幾點經(jīng)驗，希望對大家有所幫助。

四、盡量保證所有事情都有記錄可尋

這個標題本身就很嚇人，所有的事情都有記錄可尋，人又不是機器，怎么能保證任何事情都會留痕呢？但實際工作當中，做到記錄留痕真的非常重要。通常有以下6種常見情況，你會發(fā)現(xiàn)有跡可循、有文可查是非常有意義的：

1. 當你迭代產(chǎn)品需要對原來的功能、內(nèi)容進行調(diào)整時；
2. 當你對你的工作進行總結(jié)、回顧以及輸出方法論時；
3. 當你的交接者需要進行工作交接時；
4. 當你的合作者需要介入產(chǎn)品/項目的設計與研發(fā)時；
5. 當你與需求方進行溝通，構(gòu)思業(yè)務邏輯與產(chǎn)品邏輯時；
6. 當團隊協(xié)作時遇到某些問題或出現(xiàn)事故時；

我們對上述6種情況逐一簡要的分析一下。

（1）我們設計產(chǎn)品，難免會對原來設計的功能進行調(diào)整或優(yōu)化。很多新手產(chǎn)品經(jīng)理在做這項工作時想當然的認為新的設計一定會比舊的設計更好，因此會大刀闊斧的直接對功能下手。我們在論語中學過一種學習方法叫做“溫故而知新”，說的就是通過溫習舊的知識來參悟新的知識。那么對于產(chǎn)品設計而言，這種溫故知新法同樣是有必要的。有一些舊的設計，雖然在現(xiàn)在的眼光里看來很low，但是當初這樣設計很可能是有意而為之。比如受到了公司資源、研發(fā)實力、技術框架、運營手段等等各個方面的限制。如果這時，我們沒有好好的記錄下當初的設計為什么要這樣做、為什么不那樣做、受到了哪些限制、希望達到什么樣的目的，那么在功能優(yōu)化時，就會漏掉這些問題。導致無法進行研發(fā)或者上線后出現(xiàn)很多其他問題。

（2）有時我們會抱怨公司要求的日報、周報、季度總結(jié)、年度總結(jié)等等，但實際上這些匯報往往是你在年中或年底總結(jié)時的重要參考數(shù)據(jù)，也是和我們的獎金直接掛鉤的內(nèi)容。我嘗嘗因為懶而不去認真的記錄日報，或是干脆忘記。直到當我要進行總結(jié)、為未來做計劃時，才發(fā)現(xiàn)無從參考。

（3）工作交接是每一個人在工作中都會遇到的問題。無論是公司內(nèi)部交接還是員工離職交接，每一個交接的人都希望擁有之前產(chǎn)品所記錄的所有內(nèi)容，以便于更好的了解產(chǎn)品、了解歷史。無論是從交接者還是被交接者的角度思考，我們都應該負責任的去記錄好應該記錄的內(nèi)容。

（4）與工作交接相類似，合作者的介入，也非常仰賴舊的文檔以及溝通記錄。因為我們不可能每次都要言傳身教的去幫助別人更好的理解產(chǎn)品和項目，也不能玩完完整整的在腦海中記錄每一個細節(jié)問題。

（5）與需求方溝通，通常需要我們提出自己的產(chǎn)品角度的建議與想法。這些建議和想法都是跟據(jù)歷史經(jīng)驗得來的。你有沒有遇到過一種情況：需求方提出一個你認為不可行的方案，但你又回想不起來當初到底為什么不這樣做? 這時，如果你有據(jù)可查，那么就能夠輕松的應對。

（6）團隊協(xié)作，必然可能出現(xiàn)相互扯皮、出現(xiàn)事故的情況。大家站在各自的角度和利益面前，不可能非常理性的去分析和思考一些問題。那么這時，如果你需要有證據(jù)來盡可能證明問題不是出現(xiàn)在自己身上，那么一個好的記錄會讓你能夠捍衛(wèi)自己的權(quán)益。這并不是說讓我們利用這些證據(jù)成為團隊中甩鍋的利器，而是為了團隊更好的了解問題的根源，避免無休止的爭論。

五、再小的設計也值得認真思考

在做產(chǎn)品設計時，尤其是一些有一定經(jīng)驗的產(chǎn)品經(jīng)理，對于細節(jié)的處理和小的功能點會帶有一種迷之自信。我曾經(jīng)也看到過一些文章，探討過產(chǎn)品經(jīng)理是否需要過多的去關注細節(jié)問題。在這里我只談我個人的感受，那就是：再小的設計，也值得認真的思考。

認真思考并不是我們要陷入某些產(chǎn)品細節(jié)之中，更何況真正工作的時候往往沒有那么多時間去處理一些細節(jié)。認真思考的意思是說對于一些常見的功能，我們是否有認真的態(tài)度去思考過它該如何設計、為什么這樣設計。

工作中，我發(fā)現(xiàn)很多人包括我自己，在設計一些常見功能（比如頁面跳轉(zhuǎn)、空值顯示、篩選排序等）時，選擇直接copy，或者不去過多地描述功能邏輯和異常處理邏輯。我們理所當然的認為說，研發(fā)和測試已經(jīng)做過很多這樣的東西，并不需要過多地去思考和描述這個需求。就是因為我們在思考上的懶惰，導致產(chǎn)品在研發(fā)時，我們會發(fā)現(xiàn)研發(fā)人員會提出各種各樣的問題，甚至直到看到測試用例的時候，才發(fā)現(xiàn)自己當初的設計有多么愚蠢。

其實只要我們在設計的時候，多花點時間來思考，動手去描述，就能夠避免大部分這類問題。我們常常會夸贊某個產(chǎn)品對于細節(jié)的把控非常到位，然而自己卻對于小設計嗤之以鼻。

六、雙人或多人合作時千萬不要替對方做決定

在工作中，我們經(jīng)常會遇到與其他產(chǎn)品同事進行合作來設計產(chǎn)品。比如一個網(wǎng)站，大家各自負責獨立的版塊，彼此的業(yè)務又常常會有交集。這個時候，我們也難免會碰到需求重疊、互斥、耦合等等情況。這個時候，我建議雙方在合作時一定要明確分工、及時溝通、共同負責，于此之外，更重要的一點就是不要提對方做決定。

我曾遇到過兩件事：

一件事是在某個產(chǎn)品設計中，我設計的某個功能與其他同事的設計有交集。當研發(fā)和測試人員咨詢同事的設計時，問到了我的設計。由于同事并不了解我設計的初衷，但又礙于面子，強行按照自己的想法給研發(fā)和測試人員進行解釋。就導致他的解釋與我的設計初衷幾乎違背。直到事后我發(fā)現(xiàn)問題，才避免了研發(fā)與測試人員的理解錯誤。

另一件事，是研發(fā)和測試咨詢我某個其他產(chǎn)品經(jīng)理設計的功能點的某個字段是否不合理需要去掉的時候，我并沒有仔細核對，直接通過自己的判斷告知其刪掉。導致事后才了解到如果沒有這個字段，會影響產(chǎn)品合規(guī)性要求。

因此我們在與他人進行合作設計時，千萬不要憑自己的感覺去提對方做決定。即使在小的點，也要經(jīng)過溝通確認再共同去對其他部門的同事進行宣導。

本次的分享就到這啦，如果您有什么建議或想法歡迎留言，我會繼續(xù)梳理這個系列。

#相關閱讀#

這些年做產(chǎn)品踩到的坑，和犯過的錯（一）

本文由 @黑眼圈233 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議