品質管理

專案成果的爛品質到底是怎麼形成的?正本清源的解決之道又是什麼?

我們知道,任何專案,最終都有一定的成果得產出,而這些成果必須符合一定的品質標準。有些成果的品質要求較寬鬆,有些則必須極為嚴苛,沒有一點商量的餘地,像與人身安全相關的品質要求就是一例。照道理,軟體有品質瑕疵是不該被放行出貨的,不論是看得見的使用者介面(User Interface),還是看不見的內部程式碼的瑕疵都一樣。然而,實際的商業運作情況,卻不是這樣。為什麼會這樣呢?

從「阿姆斯壯登月」學專案管理:關於外包和採購管理,PM該知道的3件事情

西元1969年,阿姆斯壯成為首位登陸月球的人類,直到現在已超過50年,然而,1961年甘迺迪總統宣布登月計畫時,美國甚至尚未發射載人太空船進入地球軌道,論經驗、理論都還無法支撐遠大的目標,因此,即便是至關美國與蘇聯之間的太空競賽角力,NASA也不得不將部分技術發包委外,尋求更有效的解決方案。在專案管理學當中,外包屬於採購管理的一環,具有契約、法律效力的存在,PM在面對合約議題時,務必要小心謹慎。本文章想探討的,是這個真實案例裡,有沒有日常專案工作中所能借鏡的地方?

敏捷品質管理:笨蛋!問題不在是否能做到「零瑕疵」,而是在「看待瑕疵的態度」

日前於敏捷課堂上,有學員問到,應不應把瑕疵(以下簡稱 bug )列為用戶故事來處理? 這個問題,其實可以分為好幾個層次來探討,我們就先從根源來談起吧! 瑕疵該發生嗎?是理所當然的嗎?瑕疵可以放任多久再處理?瑕疵該以用戶故事紀錄、跟催嗎?
  • 第一頁
  • 前一頁
  • 1
  • 下一頁
  • 最末頁