最近app開發已經接近尾聲了，為了趕進度準備開始一邊測試一邊開發，公司沒有專門的測試人員，只好有我這個產品經理來做簡單的黑盒測試，沒有想到測試時發現了很多問題，我一邊做記錄一邊通知開發人員修改，但是，更多的時候我在思考為什么會出現這么多問題。從測試出來的問題來看，大概分為這么幾類：1.自己工作失職在一些功能上沒有考慮周全；2.開發過程中需求文檔更新后開發人員并沒有及時注意到；3.開發人員自己的失誤。關于第三點無需多言，每個人都有失誤犯錯的時候，你發現這樣的BUG，開發人員很樂意去修改的。重點我想講講前兩點問題，由于前兩種情況出現BUG的時候，開發人員修改BUG時內心會出現逆反心理，他們會義不容辭的反駁你為啥一開始都沒有考慮周全，為啥更新了沒有人及時通知我，導致溝通的成本增加從而影響開發進度。就這兩點我想從我自身產品經理的角度談談。

1.需求文檔沒有考慮周全

從本質上來說需求文檔不可能一次性考慮周全，只能做到盡可能周全。這也是我在這次測試中不斷反思自己的地方，這個地方問什么沒有考慮到？這個異常情況為什么沒有考慮進去？等等類似的問題，而且在測試過程中一些相對來說比較復雜的業務邏輯自己在文檔中并沒有表達的很清楚。基于以上這些考慮，我總結出來文檔的兩個問題：“全”和“準”。關于“全”無外乎就是自己不細心和缺乏經驗。后者只能在不斷的工作中去總結吸取教訓，而前者是可以通過結構化的思維和方法來盡量避免的，我想到的方法是通過頁面條件來排除，而另外還需要我自己去總結一套適合自己的結構化的文檔出來，比如：最常見的輸入和顯示，輸入內容的限制，輸入為空時的異常情況，顯示內容的不同狀態等等，我想這些是需要我慢慢去總結的，更重要的是我要在以后的工作的去這樣思考問題，慢慢的建立起自己結構化的思維方式。

2.開發過程中需求文檔更新后開發人員沒有注意。

這個是團隊之間配合的問題，一方面需要更好的工作流程來制約，而另一方面更重要的是團隊溝通的問題。先來說說前者，“工作流程”這樣的制約因團隊而不同，不是所有的團隊都會按照的流程來走的，尤其是對于一些小團隊來說，為了提高工作效率和開發進度，會不自然的省略掉一些流程，我想是不是可以考慮把“工作流程”這樣一條線，改成一個點，團隊中的重要人去控制這樣的點，即使省略了部分流程但是每個“點”還是不能被省略點，但是即使這樣最后還是需要團隊人員的磨合，其實關于這一點歸根到底還是團隊人員相互磨合相互“妥協”的工程，好產品背后都有一個好團隊，但是團隊和產品一樣并不是一開始都很完美的，也是需要不斷的迭代更新才能慢慢趨于完美。第二個就是團隊溝通的問題，測試中我發現一個特別的地方，Android沒有遇到這樣的bug而ios遇到遇到了，仔細回想起來Android的開發人員跟我溝通了這樣的問題而ios沒有，由于是小團隊一般情況下Android開發都會去告訴ios該怎么實現，但是總是有遺漏的地方，所以以后不管是什么問題，我都會記錄下來然后及時更新自己的需求文檔，并通知他們所有人。其實這是自己工作的失職，我要堅持以后遇到什么樣的問題，我都要及時更新自己的文檔，并及時通知所以開發人員。

今天看了一個視頻——三十天堅持做一件事情。我決定堅持寫點東西，讓自己更多的時候去思考，只有思考才能寫出東西。寫東西不重要，重要的是思考的過程。