俗話說，不想當將軍的士兵不是好士兵。長時間做測試工作的測試人員，有些有可能會有轉型的打算，不想繼續在測試道路上踟躕前行。當下IT領域大火的產品經理或許是你轉型的不二選擇。那么如何才能順利轉型進階成產品經理呢？我談談我的想法，希望給尋求這部分職業的人以啟迪！
一、產品應該是好的需求
作為產品首先思維要清晰，業務需求明確，一方面可以快速與上級領導、合作人員溝通清晰，將需求達成一致。另一方面可以快速的將需求灌輸給開發人員。所以測試人員要想進階為產品經理，應該具備以下軟實力。
1、良好的溝通能力。話誰都會說，但是說的漂亮、表達准確就非常難了。需要平時多積累、首先要敢於溝通，再次才是善於溝通。
2、良好的撰寫文檔的能力。千萬不要小瞧這個能力，一個優秀的產品畫出來的流程圖思路清晰，一目了然。寫出來的需求文檔業務描述准確，無啰嗦綴語。
當然還應該具備硬實力。對開發框架、存儲過程、SQL語句、以及管理工具的使用有獨到的見解。就我目前接觸到的產品經理大多是具有3年以上開發經驗的人在擔當。
二、產品應該具有優秀的SQL編寫能力
誠然，產品作為一個項目的領頭人，可以事事依賴開發測試，但是如果真的都這樣做了？自己在開發測試中的技術方面的信服力肯定會大大折扣。當然處處都有辯證法，也不需要任何技術都精通。但是基本的SQL能力是一定要具備的。為什么要這樣說呢?我們大家都知道一個項目正式上線運行后，需要進行一段時間試運行，確保項目確實滿足投放條件。對於非web的系統，例如接口類，根本沒有web界面只能通過后台數據庫的存儲數據正確與否來辨別程序功能是否正常。這里我展開說下兩種SQL的書寫。
第1種：優秀的產品經理一定善於創建視圖。因為提數驗證程序功能時，不是每張表的所有數據都需要，我們要從多張表中提取數據進行驗證。創建視圖這里有三個問題需要注意下：
（1）一般能采用左連接 lEFT JOIN ON進行的，不要使用等值連接。左連接如何寫？教程很多。我只強調一點：LEFT JOIN左邊的那個表一定是數據庫中所有表的基准表，這個表的數據在你關聯的其他表中盡量都有對應的值更佳。這樣可以方便ON語句后面的連接。
（2）一般建立視圖時都要進行分組，因此要善於使用group by子句。
（3）盡量使用count(1)來統計列數，而非使用count(*)。
之所以要注意以上三個問題是因為，這樣書寫出來的SQL針對大數據查詢時（一般大於10萬條）查詢效率高，性能優越。對count(1)優於count(*)做下具體實例說明：我本地有一張表auther此表我插進去了大於2萬條數據。執行結果如下：
可見執行select count(1) from auther所消耗時間為24毫秒，執行select count(*) from auther所耗時間為25毫秒，我們有理由相信數據更多時，這個差別會更大。
三、產品要有超抗壓能力
雖然說有壓力才有動力，但是不得不說產品經理要承擔超乎尋常的壓力。領導催催催，業務急急急，開發不作為，更加上需求變更頻繁，所以需要承擔超乎尋常的壓力。必須學會自我調節、自我放松。同時要有良好的修養，更要有良好的定力，不因為外界因素而影響。
四、產品經理一定要有大局觀
這個是日積月累的結果，業務催的急、時間短什么功能要在最短的時間內做完，什么功能可以延誤，為什么可以延誤。還拿保險來說：要對險種A進行開發開發時間為1個月，產品經理就直接將整理好的額需求草草交代給開發，然后就着手做，這樣短的時間肯定是做不完的，最后的程序只能是不倫不類。此時需要產品經理有大局觀的認識，作為保險產品：
，很顯然保險產品的贏利點在於保費收取，所以承保功能應該是放在第一位的，出了保單意味着投保人有可能會提出更改保單信息，或者退保，那么批改操作次之，如果時間緊急，就應該優先將這兩部分功能優先集中資源進行開發。其他3個模塊的功能后續跟進。原則就是：
（1）優先使用的功能集中優勢資源優先開發；
（2）前后模塊功能有聯系的應該善於分支開發，最后進行有效整合。總之大局觀無處不在，體現在關鍵時候的決策。
看到這里，不知道對想轉型做產品經理的測試同學是不是有所幫助，總結下如果你想轉型做產品，就需要衡量下你是不是已經滿足上面我說的四個條件。如果沒有達到，請繼續積累，要相信量的積累終究會產生質的變化！
測試可以進階為產品！