《轉載》時程估了算不算？專案管理人的軟體開發故事
http://rio.im/
http://rio.im/
近看到「為什麼軟體工程無法估算時間？」所提到的情況，也對「生產力」的提昇作了很好的建議。
事實上，這篇原文「Why Can't Developers Estimate
Time?」其實認同專案時程依然可被預估，也提供了抓時程的簡單方式。
時程到底能不能估？估了算不算？
這是我的看法：時程要估也要算。只要有營運壓力，廢話少說、作就是了。
軟體專案比斯斯還要多很多種，從專案範疇、人數、成員的默契以致細化到成員的個人能力、情緒管理跟運氣。
例如開發者A可以在一週內完成同一公司內開發者B＋C 花兩週時間才能完成的功能，這還是開發者 A 利用看漫畫後的剩餘時間完成的，照樣運作無誤。但是 A 養的貓不幸在外出約會回家後時嘔吐休克後一直在出不了動物醫院，對獨居在台北的 A 來說如同家人一般貓咪當然需要得到如同家人一樣的照顧，這不僅影響了A的工時，也影響了A的情緒。時程開始延誤， B 因為有類似開發經驗被抓進來支援，但是跟 A 一向不和的 B 暗第裡並沒有積極處理，C 才來一個月，到底要不要用？
軟體專案比斯斯還要多很多種，從專案範疇、人數、成員的默契以致細化到成員的個人能力、情緒管理跟運氣。
例如開發者A可以在一週內完成同一公司內開發者B＋C 花兩週時間才能完成的功能，這還是開發者 A 利用看漫畫後的剩餘時間完成的，照樣運作無誤。但是 A 養的貓不幸在外出約會回家後時嘔吐休克後一直在出不了動物醫院，對獨居在台北的 A 來說如同家人一般貓咪當然需要得到如同家人一樣的照顧，這不僅影響了A的工時，也影響了A的情緒。時程開始延誤， B 因為有類似開發經驗被抓進來支援，但是跟 A 一向不和的 B 暗第裡並沒有積極處理，C 才來一個月，到底要不要用？
專案管理人（以下稱 "PM" ）解法：在本文最下方。
專案開發絕對不能只用一個角度來分析。至於軟體開發時程的管理，絕不能貪圖速成。
抓buffer天數、站著開會、相互review都是可行的方法，但是軟體開發的核心是「人」，團隊成員必須被尊重與信賴，案子才做的下去。 RD 要尊重
PM，PM 請相信
RD。至於老闆們，請相信你的員工。作不到的人，相信你一想到上班就很鬱卒。
分享幾個軟體開發時程小「故事」及時程預估或管理的建議：（都說了是故事嘛，如有雷同請去買樂透。）
分享幾個軟體開發時程小「故事」及時程預估或管理的建議：（都說了是故事嘛，如有雷同請去買樂透。）
1.外包的活動網站-打死不能延誤
廣告公司承接了某個新上市的休閒食品行銷案，因為整個案子包含電視廣告、店頭活動跟網站，某軟體公司想接網頁製作的部分，要搭配產品上架跟電視廣告一起
launch，好讓消費者有地方登錄序號換獎品。是的，這種專案如果沒有在講好的時間上線是會挫賽的。
PM把大致上的規格跟工程師對了一下，問法有兩種，第一種：大概多久可以做完?
第二種：某月某日要上線，趕的及嗎？我建議是要問天數，也要講上線日。問天數，工程師的腦海裡會把規格跑過一次後再加給你，講明上線日則是讓開發者有覺悟：「剛剛的天數是不能估的太隨便的。」
不管後台流量報告有沒有寫好、要換的廣告主角新圖又遲遲未到，這種加班也要完成的案子大家都要有覺悟，PM 一定要繃緊神經，RD
也請據實回報進度跟問題。
2.「就是大」的大型專案-遵守時程就是贏得更多生意
最常出現在 SI
公司，通常客戶對象是政府單位或大型企業，錢很多、人很多、小問題也很多。依照經驗預估時程通常不會差太多，而且客戶跟你一樣都有的默契是「一定不會完全照著時程走」。專案品質跟完成度通常比準時上線來的更重要。先不要無限上綱成「上線的時程不重要」，也許大家習慣了milestone
的 delay，但是一次次如期正確交付所產生的信賴感絕對用錢也買不到。
對客戶誠實以報、不時跟專案成員確認進度，是控管時程的不二法則。
3.初創公司的服務-上的準不如上得巧
離職寫 app 的一人公司或雙人拍檔可以用「流行」來形容，作網路服務的初創公司也通常是三、五成軍，把 PMP
那一套專案管理方式搬出來用可能反而礙事。「用SCRUM呢
?」大公司待久了，被洗腦也很正常啦。有事討論、沒事埋頭苦幹，有志一同才一起創業不是嗎？（如果不是就可以散了）。有個預估的上線時程很好，但是是情況隨時調整更重要。如果剛好看到某個大日子很適合自己的產品上線，就調整一下吧。例如臨時決定參加
SXSW，或是剛好碰到王子娶公主。目前的使用者多數都能接受 beta
就上線這回事（不收錢的服務適用），只要交頭接耳一下就可以確定的時程，不用長篇大論、一起衝就是了。
4.內部的內管理平台- 沒魚，蝦也好
如果是作管理網站內容或是小活動的內容管理平台，使用對象就是公司內部自己人-通常是產品經理、社群經理、客服人員或是工讀生。平台的規劃通常是因為如文案更新、圖片上架、論壇管理之類的可被模式化的例行性工作需要，把動不動就需要勞動
RD
的庶務做成非程式開發者就可以上手的介面。因為沒有實質收入的產生又耗內部資源，所以通常會被其他專案插隊。很難過嗎？看開一點。這要看內部對這些例行工作消耗內部資源的忍耐程度，真正上線的時程通常是老闆心血來潮（其實是被
PM 煩的）定的日期。
這類專案以實用為主，如果時程喬不攏，建議一點一滴分批上，讓 RD 資源可以慢慢從這類庶務中釋出，PM
也可以有工具可以靈活應用、讓內容或社群管理更有效率。
喔，專案管理人（以下稱 "PM" ）解法：「請老闆去照顧貓，因為此時 C 的工作比老闆重要，並定時追蹤貓況。B 跟 C
專心作自己的事，避免節外生枝。至於A大人，我請朋友從日本買最新的蒼井空的DVD給他，並告訴他老闆答應上線後會放他兩個禮拜的假。」
處理人，就是處理時程阿。
全站熱搜
留言列表
