這兩天在解決一個問題，在於公司開發的轉檔程式上，由於開發時以64位元為主，在正式環境中此一轉檔程式一直都沒問題，但移植回公司的測試機時，由於測試機的環境是32位元，所以一直無法搞定，即便把程式編譯成32位元時也相同，總有些元件是有問題的，經猜測應該是有些元件已經被包覆成64位元形式，而造成的錯誤，當下只想著要解決這件事情，但是卻失去了PM該有的角度。
問題一、其實由於要符合使用者在成果展示時運作，程式的設計本來就沒有限定必須在部電腦上完成此一工作，加上成果展示的時間不過就1、2個小時，而且正式機的環境是64位元，加上後續所建置的平台也都採取64位元，所以其實沒有必要為了解決這個問題，花功夫在上面，只要找台64位元的電腦部署一下，就可以解決了，如果只是執意要解決這個問題，將會發現產出大於成本，這將會嚴重影響專案的產值，所以應該是選擇用最簡單的方式，來解決問題，而不僅是修改程式。
問題二、有許多時候，在思考的角度如果僅落在某個角度上，就會被該角度給綁死，在遇到這個問題時，直覺就是想要用Developer的角度去解決，開VS啃Code似乎一切都理所當然，就Developer是理當要解決這個問題，並且要調整成多元適應的程式模組，以符合各式環境，但是就PM應該是思考在達成專案目標時，可以採取的所有Solution，而不是用最笨的方法解決，這樣可能導致專案目標無法達成，而產生所謂的事半功倍的問題。
問題三、廣徵意見絕對是需要的，在思考問題時，總是會被自己的盲點給欺騙，三個臭皮匠不見的真的勝過諸葛亮，但是他們所思考的角度與方向可能比自己還多，埋頭不見得苦幹就會汗滴禾下土，有時候只是賠了夫人又折兵，善用社群的力量來協助或者將問題拋出給同事朋友們，由時候會得到一個你意想不到的答案，可以讓問題迎刃而解，不能忘記軟體業是知識產業，不是勞力密集產業。
留言