評估能力

作者：
這是我還在讀研究所時所發生的事。有一個在職的同學突然間常常出現在實驗室，一副很輕鬆的樣子。他的公司在美國算是很大的公司（應該說是非常大的公司），軟體部門也非常大，而且他一向忙得不可開交，很難想像他怎麼有可能這麼輕鬆。原來他們所做的project 竟然提早一個月結束，team leader告訴他們不要讓經理知道他們已經做完，暫時享受一下悠閒的時間，所以他就有時間來學校晃一晃。

這種事當然不可能常發生，可是到底發生什麼？是招標端（客戶端）的評估能力差？cost estimation 的問題？project planning的問題？太高估了？假如兩方老闆發現了，會怎麼樣想？假如你是team leader你會作什麼？more testing? more refactoring?
在台灣的學歷：幼稚園中班肄業 （所受的教育都在國外）

留言

  1. 黃為德2008年9月10日 下午5:20

    可能做project之前沒有做estimation，不過這麼大的公司不知project estimation或prediction的重要，實在不解。

    回覆刪除
  2. 薛念林2008年9月10日 晚上11:23

    因為沒有提到原來的案子有多大。假如原來的案子是五年的案子，那麼誤差 1/60 還屬合理，我個人覺得很難估到非常精準。

    如何避免工程師謊報？如果專案經理有如期在追蹤這個專案的話，謊報的情形應該可以避免。也許這就是CMMI中提及的 PMC（project monitoring and control）的重要性吧。

    回覆刪除
  3. 劉立頌2008年9月10日 晚上11:28

    的確是不解。我相信他們有作estimation，因為他們的公司一項有在做，可是不曉的在哪一環太高估了些時間或人力。更是不解的是，其他競標的對手，難道沒有更好的prediction？再者，委託端難道沒有底標？

    更有趣的，team leader如何影藏他們超前的事實，到現在還是蠻好奇的。

    不知道大家有沒有一些相似的經驗？

    回覆刪除
  4. 劉沅2008年9月11日 清晨7:44

    一般來說，專案經理發現工作超前時會放慢腳步（少給些壓力）或是增加工作（如測試或寫文件），所以提前完成在我三十年的開發與管理經驗中幾乎沒有發生過。這裡有個類似墨菲定律的定律：Work expands to fill the alloted time ─ 工作量會自己膨脹以符合時間表。就像飛機或火車跑得比預期快時，駕駛員會自動放慢速度。
    總之，經理居然會叫組員出去晃，並且不要讓上面知道，的確是不可思議。因為，上面知道的機率是很大的。也有可能經理對組員這麼說，是要向他們邀功，博取「愛戴」，而實際上經理早已取得上面的許可。當然，也不排除那位同學隨口講講，不一定反映事實。

    回覆刪除
  5. 匿名2008年11月15日 晚上11:37

    專案時程估不準是常見的事，所以提前完成的機率應該也不小吧！只不過大部分的人（尤其是programmer)通常喜歡拖時間，時間快到了才發現系統有bug, 所以專案就延遲了。提前完成真的不容易，真的有完整測過了嗎？

    允許出去晃就更糟糕了，這代表沒有其他的專案在跑？那公司怎麼賺錢呢？

    回覆刪除

張貼留言

這個網誌中的熱門文章

從種樹小故事看流程改善

作者：
今天上課前突然想到一個故事，稍作改變後用來跟學生講解流程改善。 某公司聘用一個員工上種樹，他需要鋤頭挖洞，將樹植下，最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹，比老闆預期的進度差太多，於是老闆又聘了兩個人來幫忙，速度提昇了兩倍。 [from work harder to work smarter] 但是這樣的速度還是不夠快，而成本又太高已經沒有經費在聘用員工，只好想辦法進行流程改善。他仔細觀察三個員工的工作方式，發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作：A 只做挖洞的動作，B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間，更棒的是，每個人更能夠把自己的工作做的專精，效率又提高了兩成。 [但，小心成為官僚流程] 這樣的流程跑了很久，員工來來去去換了許多次，但都保持一定的高效率。一天，老闆去看工地，發現A 挖玩洞後，C 緊接著把洞補起來填平，老闆生氣的說：『你們在做什麼？B君呢？』 『喔，他今天請假了』A 說。 最後這個笑點看似誇張，但在企業流程卻常見。許多人習慣了只知道follow 流程去做，卻不之所以然，所以很容易鬧出笑話。另一方面企業也常常不重視流程的教育訓練，所以常常空有好流程卻無法發揮最大的效用。
閱讀完整內容

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法...
閱讀完整內容

手機上的物件導向

作者：
最近 HTC 出了一款 Android 手機， HTC Hero , 相信3C 迷及 Google 的愛好者都相當注意。我雖然也注意了一陣子，但最近才發現它一直很強調它的 People-centric 的特色-- 就是以人為中心，將電子郵件、通話紀錄、簡訊整合在一起的功能。這樣的設計感覺起來很直覺，很好用。 回頭看看過去的設計，是以通話、傳簡訊、查看通話記錄為主的『功能導向』設計，『人』只是這些動作的參數。這才驚覺原來現在的手機介面設計流行（進化到?）『物件導向』。這樣的進化是偶然？還是從物件設計的理論得到靈感？ 如果是後者，也許可以進一步的思考物件設計的技術 -- 例如繼承 -- 如何應用在手機上。 把手機上的聯絡人用繼承樹（a kind of）來模組，如此一來在訊息傳送給父類別的群組時也會送給子類別的聯絡人，或許這樣可以簡化整個手機上的群組關係。當然，物件上的『association』也可以套用在聯絡人的關係的建立。 只是一個突發奇想，可能有點人來瘋。但有興趣的朋友、研究生或許可以試試研究看看。
閱讀完整內容