其實離開軟體測試工作至少三個多年頭，回到最早的工作範疇擔任產品經理的角色。對於軟體服務而言，產品經理相對技術，通常會是一個更接近市場和客戶的存在。當然，每間公司對於產品經理的定位上頭，其實都有不小的差異。在我的職涯中，大多時候我遇到的產品經理都比較偏技術職，對於業務、行銷或市場，都一竅不通。
我雖然最早的時候也算是技術職出身，但老實說，我的技術力比起大多數埋頭寫Code的人，真的弱很多，要用技術服人，那叫天方夜譚。但想用技術唬我，那也要看你的功力有多強！雖然在台灣中小型軟體公司中，市場行銷型的產品經理並不多見，但說真格的，與其一堆自以為很厲害的技術人員，關起門來寫出來一個程式，然後賣不出去才再怪業務不會賣。不如在開發時，就要弄清楚做出來何種東西就是能賣得東西。
我遇過很多寫code的工程師，見過幾個客戶就認為自己很懂市場。但大多數，我看見他們的時候，我都看到十多年前的自己...那個懂個屁的自己。
反過來，大家也看了一堆所謂的「網路先知」寫得文章，就例如「蘋果帝國的建立」，他們創造了人類的未來....八拉八拉八拉～很多人（包含企業主）還自以為可以複製他們的成功經驗，孰不知這種東西跟期望自己今天晚上去買樂透，隔天變成億萬富翁，有何不同？
現在許多網路新創服務公司的創業者其實都分享到了一個重點，「洞悉市場和使用者需求，然後滿足他....你就有機會成功」，其實身為一個產品經理，何嘗不是這樣看待自己的職掌和工作。但就風險低一些（公司會養），報酬也低一些（公司大賺錢也不會分你）如此而已。
許多傳授如何當一個產品經理的書籍都提到，「溝通」是身為這個職務一個很重要的技能，但事實上也並不是所有人都善於此道，能夠八面玲瓏到男女老幼通殺。但就算如此，你工作還是得要做，目標還是要盡力去完成...。
我自己遇到的開發人員，他們的工作目標就是「如何簡單的把事情快點做完」，而不會去理會「能夠怎樣或這樣做會對使用者（客戶）比較好」，所以當他們依照自己最高指導原則去執行工作，你沒有（或無法）去糾正這樣的狀況產生的時候，這壓根就像是在下水道養鱷魚，你沒事就沒事，你有事遇到你都走無路啊！
但事情該預防的還是要預防的，既然我無法從「開發技術」、「開發程序」、「專案管理職權」去「要求」、「壓榨」，開發部門去「保證」東西會是可以賣的....我只好從我行銷業務端可以下手的地方去下手。今天老實說，客戶才不管你用何種技術、技巧、開發環境和設備，來開發產品。他們只在乎「可不可以用」、「我感覺好不好」、「符不符合需求」、「吸不吸引我」來決定他們訂單的去向。所以我從消費者指標來盯著開發團隊做好測試計畫和工作。一如預期，反彈相當的大...但說真格的，我也沒很認真聽。我把持的原則很簡單，「我需要證明這個東西是可以換訂單的，其他技術議題別跟我談」。
例如技術同仁們跟我大談「測試工作名詞解釋和定義」，但我也很抱歉，我只懂實務，我也只想談實務。依據之前的工作經驗，我知道怎麼規劃、怎麼測可以達到我預期的標的。而技術部門提出的規劃和建議，不過就缺乏經驗的空想，連個可行的架構都沒有。連壓力測試和效能測試該怎麼開始和執行都不知道，只用「理論上是沒問題的」，那有問題發生的時候呢？「再修囉。」我也知道你們會這樣回答。但那是屁話.....
新產品不只有服務和功能需要滿足市場，更要提出效能和品質規格來要求開發單位確實把這些東西驗測完成。一來你能夠了解這產品的直線，就像越野賽車手需要掌握自己車輛的性能一樣，這才有機會在賽道上掌握致勝關鍵。
測試目標其實就應該要貼近客戶使用和需求來進行，你才能找出關鍵的資訊確保測試後資料是可用的。但奢望「測試就可以讓品質變好」的蠢蛋們，請醒一醒！因為就算測完沒人去修，品質也不會變好。而且更常見的狀況都是，修好了A，卻常常壞了B。修車發生這樣的機會有，但真的沒有程式debug時發生的高啊！
沒有留言:
張貼留言