2014年10月9日 星期四

X34 開會時的一句話

開部門的PM會議時, 有人提到某同事都以自己的想法開發功能, 不僅進度落後而且產出也不好用, 還堅持自己是來做產品而不是做專案.


大家在討論如何修正他的想法時, 我提出應對他說:” 做產品是做出讓客戶滿意的產品”, 不過當時只被認為是耍嘴皮子的回答. 後來我發了一封信強調這句話並不是玩笑, 而是一種專業的基礎. 全文如下:


“做產品是做出讓客戶滿意的產品”, 這並不是玩笑話.


當然, “依照規格書來產出程式”一定不是錯的選項, 但是我們也明白在台灣專案裡使用的規格書從來沒有完備過, 依照一本不夠完整的規格做出來的產出, 在使用者的眼裡也肯定是不完整的.


我們產出的程式是給人用的, 平台是提供給開發人員設計交易用, 而整個專案所要做出來的產出是要給客戶使用的. 不管對象是誰, 沒讓操作對象感覺功能正常又方便好用, 都不能算是成功的結果.


昨天測試授權時, 有些錯誤(例如授權等級不足)無法用精確的訊息呈現, 原因是規格書裡“沒有提出全部要顯示的錯誤訊息“, 所以現在的作法是先將可授權卡片內容抓出比對而沒有帶其它資訊; 即使在規格書裡的可授權判斷寫著“要同單位且授權等級大於等於授權條件規定的主管”.


三年前在其他客戶那邊討論時, 我也對承辦人說過: ”這幾種方式都可以做, 就看你們想怎麼做”, 承辦人很嚴肅地回答我說: ”什麼都由我們決定怎麼做的話, 那我們找人外包開發就好, 所以這方面的作法請你們依照多年來的經驗, 專業地提出一個最適合我們的方案”.


“要同單位且授權等級大於等於授權條件規定的主管”這條規則我們一定會寫在程式的判斷邏輯裡讓符合的時候可以授權, 但是每一種判斷的失敗不是都應該“明確地”提供錯誤的原因嗎? 尤其與人有關的錯誤, 操作者更需要知道哪裡出問題了, 才會知道如何去解決.

從使用者的角度來看待自己開發的功能, 而不是自己的想法或只做出規格書的範圍, 才是更邁向專業的基礎.