程序員如何向項目經理估算工時

① 從程序員到項目經理（12）：如何管理自己的時間（上）

項目經理必須要主動的管理自己的時間，合理安排自己的工作，才能真正「翻身」做自己時間主人。1.誰動了我的時間時間對於每個人而言，都是最稀缺的資源，對於一個管理者更是如此，時間不夠用成為幾乎所有管理者共同的問題。如果要對項目經理常說的話做一個調查的話，想信「我很忙」一定可以名列前茅。以我的經驗，當要求項目經理按時提交項目材料，或者臨時支援某件緊急事務的時候，經常會聽到同樣的回答：「我很忙」。多年以前，我就從經理那裡聽說，厲害的管理者都是很輕松的，因為他的工作全部交出去了，根本不用自己操心，所以他們出去度假十天半個月，一切工作都會如常進行。從那時起，我就充滿了對管理的神往，可是後來我才發現原來這只是個傳說，現實中忙忙碌碌的經理比比皆是，而輕松自如的管理者則是眾里難尋。為什麼管理者都這么忙呢？是誰動了他們的時間？實際上，這是一個綜合性的問題，既有內部原因，也有外部原因，既有主觀原因，也有客觀原因。總的來說，讓經理們不堪重負的因素有三：(1)工作對於一個程序員來說，他的工作是比較單純的，基本上是單線程運作，只需要項目經理交待開發任務即可，可是當上了項目經理就不一樣了。以前好比在游泳池中游泳，現在是在大海里沖浪，各種事情如潮水一般向你涌來，讓你顧此失彼，手足無措。(2)下屬下屬也是一種資源，即人力資源，這種資源與時間一樣，同樣具有稀缺性。其實我們可以設想一下極端情況，如果你的下屬人數足夠，能力也很強的話，你完全可以像我的經理說的一樣，把你的全部工作授權給你的下屬，你自己也就不用整天焦頭爛額了。因為你的下屬不給力，所以你總是要自己來制定計劃、自己來做系統架構、自己來監控進度、自己來檢查質量、自己來寫文檔、自己來匯報工作、自己來解決重要問題、甚至自己來編寫代碼，你整天忙忙碌碌，就是在忙這樣的事情。然而，千萬不要怪你的下屬，因為他們不給力正是老闆僱傭你的原因，況且資源的稀缺性是永遠存在的——從原始社會到將來的共產主義社會。要知道，老闆做項目為了賺錢，而不是讓管理者更輕松，如果每個項目都是精兵強將，你只要一聲令下工作就會自動完成，你倒是輕鬆了，但老闆還要你來做什麼？(3)自己既然資源受限是一定的，項目經理還是應該反求諸己，從自己身上找到解決之道。這就好比天下雨了，你怪老天是沒有用的，只能怪你自己沒有帶雨傘。經常問一問自己，我對工作安排合理嗎？我抓住了主要問題嗎？我在旁枝末節的事情上浪費時間了嗎？我有充分發揮下屬的能力嗎？我自己工作拖拖拉拉嗎？…通過不斷的自省，改善自己的管理方法和行為習慣，我們對時間利用也必然會變得越來越高效。 2.時間管理的本質是對工作的梳理要破解忙的難題，必須要有意識的對時間進行管理。其實時間本身是沒法管理的，因為無論你怎樣管理，時間既不會變多，也不會變少，既不會變快，也不會變慢。所謂的時間管理，其實就是如何更有效的利用時間的問題，更加直白地說，其本質就是工作管理，即通過對工作的梳理，讓我們在有限的時間內，使得工作更有條理、更有成效。必須要主動、有目標地對工作進行梳理，這是對一個管理者的基本要求。工作梳理就好比整理房間，你不去整理它，雜物就會堆積得越來越多，你房子最終會變得不適合人類居住。一個好的家庭主婦，必定善於將各位物品分門別類，並且適時扔掉一些用處不大的物品。一個好的項目經理也一樣，同樣需要對工作進行分類，對不同類型工作採用不同的策略，有些工作要現在就做，有些可以晚點做，或者不做；有些工作一定要自己做，有些工作則可以請其他人來完成。通常對工作梳理，可以採用5W1H法，即： Why——為什麼干這件事？（目的）； What——什麼事情？（對象）； Where——在什麼地方執行？（地點）； When——什麼時間執行？什麼時間完成？（時間）； Who——由誰執行？（人員）； How——怎樣執行？採取哪些有效措施？（方法）。在一般的項目中，Why和where往往不是什麼問題，或者說對項目經理的時間管理影響較小，因此我們不妨將其簡化為3W1H，也就是確定要做什麼，不做什麼；先做什麼，後做什麼；誰來做；怎樣做才更有效。基於此，項目經理可以按以下三個步驟來梳理工作：（1）分析要做什麼、不做什麼，以及先做什麼、後做什麼解決What和When的問題。事有輕重緩急，事情的重要程度和緊急程序直接決定其處理的優先順序。雖然很多事情來勢洶洶，但並不表示一定要當即處理，有些事情只是靜靜的躺在那兒，也並不意味著要「等有了時間再做」。（2）分析由誰來做解決Who的問題。雖然我們提倡項目經理要以身作則、親力親為，但並不是說每件事項目經理要親自去做。對於下屬可以勝任的事情，就把它分配出去。如果出現項目經理很忙、下屬很閑的情況，那就說明項目經理你做得太多了，不要和你的下屬搶事情做。（3） 如何讓工作更有成效做不做、什麼時候做以及誰來做的問題都解決了，剩下就要解決怎麼做才能讓工作更有成效的問題了。在這里我們不是要討論編碼或寫文檔的技巧，而是個人的習慣和認識，這對工作成效的影響更是本質上的。 3.做事要分輕重緩急老外就是善於總結，中國有詞語叫「輕重緩急」，可是到了國外搖身一變，變成了「時間管理四象限法」——自從美國總統艾森豪威爾提出以來，人人將其奉為圭臬，成為時間管理領域最重要的方法論。所謂的「四象限法」，就是將工作按照重要程度和緊急程度兩個維度進行分類。我們找一張白紙，以緊急程度為縱軸，以重要程序為橫軸，在紙上劃上一個十字，將紙面分為四個象限，然後將當前所有要做的工作放到這個四個象限中。一個典型的項目經理四象限圖如下所示： （1） 第一象限：重要緊急這一類往往是火燒眉毛的事情，需要馬上去處理，否則項目會受到重大影響，比如客戶伺服器崩潰。（2） 第二象限：重要不緊急這類事情一般是預防型的工作，例如制定項目計劃、團隊建設等，它們不需要你停下手上的工作馬上去做，但如果沒做好的話，可能就會導致產生項目危機。許多第一象限工作產生的原因，正是因為第二象限的工作沒有去做。（3）第三象限：不緊急也不重要這類事情看上去最不需要做了，例如上網偷菜、看新聞、寫博客等，但如果你在辦公室走上一圈，就會發現很多人正在干著這些不需要乾的事情。 （4） 第四象限：緊急不重要這類事情雖然不重要，卻需要馬上去處理。一個典型的例子就是桌上的電話響了，你接還是不接？當然要接，因為你不知道是誰。接通後，發現是推銷保險的，你又不好意思立即掛掉，只好被對方折磨一番了。 我們到底該怎樣安排四個象限的工作呢？對於一個普通的管理者，其工作的優先順序一般是這樣的：第一象限>第四象限>第二角限>第三象限。可是，等做完了第一、四象限的工作，根本就沒有時間來人做第二象限的工作，於是項目到了後期項目經理只好四處救火。管理大師彼德.德魯克十分推崇「時間管理四象限法」，並將其總結為「要事第一」的原則。根據這個原則，每個象限的工作處理策略是不一樣的。（1）重要緊急優先順序最高，需要盡快處理。很多人都玩過《植物大戰僵屍》的游戲吧，那你一定知道「一大波僵屍正在逼近」的感覺，是的，你必須要馬上打死它們，不然它們就會沖進你的房子，吃掉你的大腦！（2）重要不緊急這類事情看上去可以暫緩，但考慮到其重要性，應當與第一象限的工作並行去做。如果不及時去做，它們就會轉移到讓你頭疼的第一象限中去，或者在第一象限產生更多新的「僵屍」。所以，要在僵屍還沒有逼近的時候，就好防禦工事，並盡快打死它們，如果等到它們沖了過來，你還能不能保住大腦，就要看你的運氣了。（3）緊急不重要它們就像是在你耳邊「嗡嗡嗡」地叫著的蒼蠅，你必須要花時間去趕走它們。這多少讓人有些無奈，但這些事情確實層出不窮。有些公司在實施緊急項目時，經常採用封閉式開發，這樣做的一個重要原因就是要迴避那些緊急不重要的事情。很多管理專家建議我們在必要的時候勇敢說「不」，其實就是針對這類事情。如果實在無法說不，建議安排或委託其他人來做。（4）不緊急也不重要如果不是時間充裕的話，建議不要去做。如果礙於人情的話，建議安排或委託其他人來做。它們就像一群在幾百米遠處飛的蒼蠅而已，你完全不必要放下手中的飯碗，舉起蒼蠅拍跑過去和它們決斗。因此，對於一個卓有成效的管理者，其優先順序應該是這樣的：第一象限=第二象限>>第四角限。第三象限就像數學中的無窮小一樣，被舍棄了。寫到這里，我想起了前不久一位項目經理的故事：項目定於當天上線，項目組決定搬到客戶現場辦公，以應付可能出現在的突發事件。項目成員電腦已經全部打包好，都圍在項目經理周圍等待。原來項目經理正在理一大堆發票准備報銷，於是發生了這下面這樣的對話：我：「大家都在等你，怎麼還在填報銷單呢？」項目經理：「今天是公司的報銷日，不填好單子，又得推後很久。」我：「你的電腦打包了沒有？」項目經理：「沒有」我：「放行條開了沒有？」項目經理：「沒有」我：「申請用車了沒有？」項目經理：「沒有」我不知道說什麼好了。要知道公司的報銷單粘貼和填寫非常嚴格，經常被打回重新弄，那一堆發票，顯然不是十幾分鍾可以搞定的事情。還有公司的用車也比較緊張，不趕緊申請，說不定就沒有了，到時就只能租車或打的，這無疑又會耽誤更多的時間。更何況六七個同事都在等項目經理一個人，耽誤的時間還得要乘以他們的人數。萬一系統上線，狀況頻出，客戶火燒眉毛，項目組卻仍然在路上，這樣的後果是很嚴重的。貼報銷單看上去一件重要緊急的事情，實際上它既不重要也不緊急，因為今天不報銷，以後還是可以報銷，可是因此耽誤的寶貴時間，卻無法再要回來。

② 如何做好項目工作量估算——個人心得

在項目管理過程中，工作量的估算是一個重要的環節，他直接關繫到項目的成功與失敗，下面談談我對工作量估算的心得和體會：
工作量的估算方法有很多，如經驗估演算法，工作分解法，還有就是數學模型法等等，但在我們實際的項目管理過程中，許多著名的估算方法使用起來並不那麼靈活、方便，並不一定適合於我們的實際項目。
我認為最簡單有效的模型估演算法是一元線性關系估算模型，比較適合於一般的小型項目，
工作量=規模 / 生產率+C
生產率借鑒歷史項目的數據，C為一個常量，多數情況下為0。這個模型也有經驗估演算法的影子，他的生產率也需要根據以往的歷史數據得出。
在實際項目中，我們應用最多的還是經驗估演算法。這需要產品經理提供完整詳盡的PRD，項目經理對項目所服務的行業有比較深刻的理解，充分了解需求，分解需求，挖掘潛在的非功能性需求（性能，穩定性、可擴展性等），可以用xmind或者mindmanager列出項目所有的功能點，對每個功能點按照一般技術人員的水平逐一進行估算，一般以人/天為單位，在分配任務的時候，可以根據每個功能點所對應開發人員的技術水平將之前估算的標准工作量除以開發人員的生產率，得出該技術人員開發一個功能點所需要的工作量，這里就結合了前面提到的一元線性關系估算模型，其中的C就是對一些不可預測的工作量，如：項目進展過程中評審會議占據的時間，支付寶測試環境不穩定，第三方合作商配合不及時等等，都會影響我們的項目進度，所有整個項目進展過程中，我們要時刻識別風險，通過C的值來做一個調整，風險識別越明確，工時評估就更准確。
當然，項目經理不能僅僅關注編碼階段的工作量，還要和UED、DBA、測試部門以及合作方的負責人商定他們的工作量，完成整個項目的工作量估算之後，項目經理需要從中找出整個項目的關鍵路徑，時刻關注關鍵路徑的進展情況，因為關鍵路徑會對整個項目的進度造成直接的影響。如果後期關鍵路徑發生變化，要及時對整個項目的工作量做一些調整，並通知項目組的所有成員。
沒有一個公式可以精確的估算工作量，經驗法和模型法在實際中一般混合使用，以互相補充、互相印證。

③ 提高工時估計准確性

「如果一個程序員告訴你他已經完成了 90% 的工作量，那麼他還需要同樣的時間完成剩下的 10%。」
軟體項目容易延期和跳票是屢見不鮮的事情，其中不乏知名項目。

剛畢業的時候，我在一家做系統集成的公司工作，我們定製了一套售票軟體，為景區接入互聯網售票方案。供應該軟體的軟體公司非常自信的說，這東西非常簡單，最多 2 個月就能搞出來。這家公司小有名氣，我老闆對 2 個月交付深信不疑，於是張羅了接入的客戶、市場的物料等。

不難猜到，最終還是沒能逃過 90% 定律，2 個月交付的東西只能算作一個 Demo。於是花了另外一個月測試，修復問題和完善業務邏輯，又花了另外幾個月時間響應對接客戶的要求，才逐漸穩定下來。

行百里者半九十，軟體開發也大體如此。開發者估不準工時常有，估准了才奇怪呢。

後來自己也做了軟體工程師，參與 IT 項目開發，項目延期也是非常常見的事情。

IT 團隊能准時交付是一項非常有價值的能力，哪怕交付時間長一點。計劃兩周交付，最後能准時完成，比承諾 一周時間，但是花了三周才交付重要得多。

越是大項目，越是重要。大項目的各個組件可能會發生相互依賴。如果不能准時交付，就會付出團隊等待的成本，那可是真金白銀。

做過項目管理的都知道甘特圖，甘特圖的每個泳道表達了項目各項資源的進展和計劃。然而，軟體項目不確定性非常多，存在各種突發事件。如果能提高准時按質量交付，各個單位的等待成本會小很多。

關鍵的是，衡量准時交付的關鍵是質量，其次才是交付。先給一個 demo，然後再慢慢改 bug。這種 「准時」 的交付，還不如有一個明確的延期時間，本質上還是 「猛糙快」。

談項目工時估算，應該是在滿足質量要求的前提下，否則估時沒有意義。

那麼能不能提高軟體工程工時的估算的准確性呢？其實是可以的，剛到 ThoughtWorks 的時候，參與了一個交付項目。在一個項目開始前就計劃了項目結束的時間，以及下一個項目的計劃和安排。結果讓我非常吃驚，那個項目的結束時間，和預期相差兩周左右。並且這兩周是逐步減少開發人員，最後只有 1-2 個人負責最後一周的交接期。

這就是專業軟體團隊和小作坊的差別，在專業項目經理帶領下能把 3 個月的項目估算，精確到 20 - 30 個人天。能把項目工時估算到這種程度，體現了 PM 的內功。

在一個敏捷團隊，需要把工時估准，不在於 「估」 ， 而在於團隊執行項目的穩定性。 一般來說，准確估算工時需要考慮需求分析程度、任務拆分的合理性、技術方案的可靠性、團隊成員的能力、外部依賴和環境，如果這個項目不是新項目，還需要考慮遺留系統改造的成本和數據遷移的成本。

只有把需求分析做的非常徹底，才能保證估算的輸入條件。非專業的業務分析師，只能看到需求冰山水面上的部分 —— 軟體的特性、功能的復雜性等。

專業的業務分析師，不僅需要考慮功能需求，並對功能需求的邏輯性考慮完備。比如用戶需要一個 APP，他實際上還需要一個後台，對應這個後台會有不同的用戶、角色等。

根據這些業務輸出、拆分出任務，敏捷開發中我們叫做用戶故事，一個用戶故事代表一個合理拆分的業務邏輯。能被評估工作量，然後根據這個工作量來評估工時。

除了這些功能需求之外，還有非功能需求。客戶不僅僅需要一個 APP，還可能需要的是一個安全的、高性能的、國際化的 APP，而這些往往被客戶當做默認選項。

一些性能優化的指標需要分析，並考慮性能優化的任務工時；安全需求可能有 HTTPS 配置，防病毒掃描等，都需要考慮；國際化也是額外的工作量。

挖掘用戶真實需求的目的是定義怎麼才算完成（Definition of Done），如果沒人說得清楚滿足什麼條件這個項目才算完，那麼估算工時根本無從談起。

徹底挖掘客戶的真實需求是評估項目工時的首要條件。

技術方案、團隊能力和項目時間估算有很大關系。很多項目的時間估算都是由技術經理或者 Tech lead 來完成，往往是他們按照自己的經驗和能力進行計算的。光是這樣，很難算的准。

團隊有多少人？對這套技術方案的熟悉程度如何？方案是否會發生較大的調整。人一多，人員水平差距就為工時估計帶來了不確定性。經驗多的人來做方案，如果是他做過的相似方案，自然會估的稍准一點。但大多數情況下沒有這么理想的場景。

要做好工時估算，需要結合技術方案和團隊成員能力，而不是自己能幹多少活兒，多快幹完來算。

一方面，技術負責人需要安排相應的技術預研，走在實際編碼的開發人員前面，探探路，驗證方案的可行性、實施難度、風險。就像作戰的偵查人員一樣，我們把預研叫做 spike。 spike 需要輸出一些結論、demo，支持項目的時間估算。

另外一方面，考察團隊真實運作效率很好的方式是根據迭代做工時統計。按照兩周為例，10 個人的團隊是 100 個工時。如果按照之前的估算，2 周內需要完成的 100 個工時的任務，實際上只完成了 50 個工時。也就是進度只有 50%。

我這個演算法比較粗糙，敏捷項目管理中還有更准確的速率計算方式。通過速率，就能對下一階段的工時估算做出調整，並在工作量、人員上做出調整。

通過方案預研和速率計算是提高項目工時估算準確率的良好方法。

我常常花了一下午時間完成了某個特性升級的編碼，但是花了一個月的時間才完成了線上平滑升級、數據遷移。

真正有經驗的工程師都知道，方案設計的難點往往不在設計一個新東西，而在於演進一個老系統。遺留系統演進是不可避免的，這種歷史包袱是造成工時估算不準的一個重要因素。

遺留系統演進帶來的估算困難來源下面幾個方面：

不負責的猜想，有一些客戶就是遺留系統演進不下去了，然後招標做新功能，實際意圖是想乙方順便消化重構的成本。總之基於遺留系統的二次開發都是一件困難的事情，能不接就不接吧。

另外，社會分工意味著一個人干不完所有的事情，IT 項目往往一個項目也不是獨立的。大多數情況下需要和外部條件進行集成，這部分時間超出我們的掌控。

集成這件事的成本需要視主動集成還是被動集成來說：

集成充滿了不確定性，估算工時時需要預留足夠的集成空間，才能讓工時估算更准確。

項目工時估算是一個系統性工作，基本上很難有一個萬能的方法。因此大多數情況下都是玄學，但是畢竟是 「估」 ，也不能要求 100% 精確。

軟體工程的估時更具有彈性，相對供應鏈管理的交付時間估算成本更低。做好估時，對減少項目運行成本和風險有巨大意義，工時估算的准確性也往往體現了一個 IT 團隊工程能力。

④ 從程序員到項目經理（13）：如何管理自己的時間（下）麻煩告訴我

項目經理必須要主動的管理自己的時間，合理安排自己的工作，才能真正「翻身」做自己時間主人。4.管理者無需事必躬親有一種類型的管理者，他們不論什麼事一定要親自去做，至少也是親自過問。人們習慣用一個成語來贊美他們，叫「事必躬親」，彷彿諸葛亮再世一般。凡事親自去做未必真的可取，為什麼諸葛亮只活了53歲，恐怕跟他這種事必躬親的精神也有莫大的關系吧——他是把自己累死的。（1）不要和下屬搶事做管理者相對於操作層員工，多了一項法寶，就是授權。理論上，只要員工可以勝任，所有的工作都可以授權。事實上，總經理為什麼能對全公司發號施令、對工作進行變革，那是因為董事會授予了這個許可權。連這么高層的工作都可以授權，一個項目裡面的工作還有什麼不可以授權的呢？因此，當你疲憊不堪的時候，就應該問問自己，我是不是管得太多了？如果一件事情下屬能做，就應該讓下屬去做，不然等於是你搶了下屬的工作。項目經理最可悲的事情就是，自己累得半死，項目組成員卻閑得發慌。管理者必須學會授權。授權不只是為項目經理分擔工作，也是項目培養下屬成長的必要方法。如果項目經理總覺得下屬能力行，不給他分配具的挑戰性的工作，這顯然不利於下屬的能力成長，從長遠看，對項目、對公司也是有百害而無一利。（2）授權絕不是簡單的把工作交出去授權兩個字說起來簡單，但做起來效果卻會因為而異。有效的授權必須把握以下幾個要點：l 目標明確：要做什麼內容、達到什麼質量要求、什麼時候完成等等，必須要清晰具體。管理學家們認為目標必須要SMART（S=Specific、M=Measurable、A=Attainable、R=Realistic、T=Time-based），這是很有道理的。l 跟蹤反饋：項目經理應當經常性對任務完成情況進行檢查，這是很多項目經理非常欠缺的一個重要環節。只授權不檢查，最後的情況可能就是進度大大延遲，或者與你想要的東西大相徑庭，下屬進行種種解釋，但為時已晚。l 能力輔導：項目經理要對下屬的能力有比較准確的把握，安排工作也應該在其力所能及的范圍。如果跳一跳能夠得著，就比較理想，但項目經理仍然需要主動輔導，加強監控，當發現偏差時，應及時採取應對措施。如果工作大大超出其能力范圍，再怎麼跳也夠不著，項目經理就要另想高招了。（3）不做甩手掌櫃是不是任何事情都可以授權呢？理論上是可以，但由於資源的稀缺性，這種條件往往並不具備。至於什麼可以授權，什麼不可以，這要因項目而異，根據項目工作與資源的實際情況，兩廂權衡之後才能決定。不管怎麼說，授權不可過度，否則項目經理就成了甩手掌櫃，實際也等於放棄對項目的控制權。項目經理應該做的工作：l 系統性工作由項目經理做，比如制定計劃、安排任務、鼓舞士氣、項目檢查等，具體事務由下屬去做。l 重要的事情項目經理來做，緊急的事情讓下屬去做。l 決策由項目經理來做，執行由下屬去做。l 下屬能做的事由下屬去做，否則由項目經理自己做或帶著做。 5.好習慣讓工作更有成效高爾基曾這樣來描述時間：「世界上最快而又最慢，最長而又最短，最平凡而又最珍貴，最易被忽視而又最令人後悔的就是時間。」的確，時間是快還是慢，是長還是短，不在於鍾表是的指針轉了多少圈，而是在於在我們如何使用時間。一個人的習慣，對如何利用時間具有至關重要的作用。（1）盡力避免返工項目中最浪費時間的事情是什麼？是返工！一旦發生返工，不但所耗時間將會成倍增加，而且會大大降低員工的成就感，打擊員工士氣，降低員工作效率，使得項目時間進一步滯後。我見過一個城市三維模型製作的項目，經過一年多的辛苦工作，終於提交成果了，但是由於客戶認為模型不夠漂亮，最後幾十平方公里的模型全部重做！項目組員工身心俱疲，公司遭受嚴重損失，客戶也非常不滿，一個三輸的結局。返工並不總是這樣嚴重，其實在一般的軟體項目中，返工現象也是大量存在的，只不過我們借著迭代的名義將其掩蓋了。例如軟體試運行後，客戶要求將某項業務流程中的兩個環節進行整合，或者將某個環節中的輸入信息，轉移下一個環節中。單個修改的工作量也許並不算大，但累積起來就相當可觀了。很多項目在試運行後要修改幾個月，甚至半年以上，這就是返工的代價。迭代設計還是返工之間，並沒有明確的界限。要區分二者，有兩條標准：一是迭代是計劃之中的完善，而返工則是計劃之外、迫不得已而為之的事情；二是在工作量的層面，如果拋棄或被重做的功能工作量很大，那隻能認為是返工，如果你非要認為這是設計就是要這樣乾的，那我只好給它取個新名字：「返工式迭代」。這也這給我們一個啟發，做系統原型的時候，千萬不要寫大量的代碼，否則的話，迭代最後會變成返工。（2）打破帕金森定律的魔咒英國學者帕金森通過多年的調查研究，發現一個規律：「工作會自動地膨脹占滿所有可用的時間。」一個人可以在十分鍾內看完一份報紙，也可以看半天；一個程序員開發一個功能，可以兩小時完成，也可能花上一周的時間；項目經理制定計劃，可以半天完成，也可能一個月還不見影子......總之，只要還有時間，工作就會不停的擴展。帕金森定律就像一個魔咒一個樣，困擾著很多人。它之所以起作用，表面上原因在於時間充裕，外部壓力太小。因賴床而上班遲到的人常有，但因賴床而誤飛機的則很少，因為誤機的後果很嚴重。因此，有必要對每件工作確定一個時間期限——dead line，一過這條線dead！給下屬安排工作時，這的確是一個好辦法，但對於管理者而言，約束別人容易，約束自己則很困難。即使工作到期，還可以告訴自己，再推遲幾天也沒關系，這件事情還可以讓某某來完成，即使到了dead line還可以說這件事其實不重要，少做一點沒關系。圖帕金森定律的魔咒歸根到底，還是在於我們的內心力量不夠強大，面對一點點的外部阻力，就變得消極懶散，不能自我驅動。截止日期是靠不住的，要靠只能靠自己，養成良好的習慣，主動給自己壓力和動力，戰勝心中的「懶惰小人」，才能真正解除這個「帕金森魔咒」。（3）合理利用時間每個人都希望工作不被打擾，但作為一個管理者，你的時間不是自己的，你的上級和你的下屬都有權來隨時打擾你。你坐在那裡，就會有人過來找你簽字，找你談工資，找你討論技術問題，找你支援其他工作……每天的時間就這樣被打成了無數的碎片，所以經理們常不由自主的感慨：「白天真的做不了事，只能晚上和周末才能工作」——加班才能做事，你說經理能不累嗎？的確，項目經理很多工作都需要大塊時間，比如制定計劃、編寫文檔、分析風險、關鍵技術實現等，都需要較長時間的思考。一個人要讓心靜下來，進入工作狀態是時間的，一旦被打斷，再次進入這種狀態會花很多時間。這就好比炒菜，把鍋燒熱是需要時間的，你剛放下油，來了電話，等你接完電話，鍋又冷了。時間碎片的問題對管理者而言是不可避免的，但可以採取方法更加合理的利用時間，將其影響降到最低。l 制定規則例如約定在指定的時間簽單、討論技術問題、反饋進展等，而不是隨時進行。l 瑣碎事情一起做對於工作中的瑣碎問題，不用急著處理，可以啟動「碎片整理程序」，將其記錄下來，在你不需要「炒菜」的時候一起處理。l 利用碎片時間碎片時間並非不可利用，而是要安排合理的工作。幾塊大石頭中間的縫隙，肯定塞不下另一塊大石頭，但放一些小石子或沙子還是沒問題。

⑤ 程序員是做什麼的

程序員一般的工作是從事程序開發、程序維護。

程序員是從事程序開發、程序維護的專業人員。一般將程序員分為程序設計人員和程序編碼人員，軟體從業人員分為初級程序員、中級程序員、高級程序員（現為軟體設計師）、系統分析員，系統架構師，測試工程師六大類。具體工作職責如下：

1、負責軟體項目的詳細設計、編碼和內部測試的組織實施，對小型軟體項目兼任系統分析工作，完成分配項目的實施和技術支持工作。

2、協助項目經理和相關人員同客戶進行溝通，保持良好的客戶關系。

3、參與需求調研、項目可行性分析、技術可行性分析和需求分析。

4、熟悉並熟練掌握交付軟體部開發的軟體項目的相關軟體技術。

5、負責向項目經理及時反饋軟體開發中的情況，並根據實際情況提出改進建議。

6、參與軟體開發和維護過程中重大技術問題的解決，參與軟體首次安裝調試、數據割接、用戶培訓和項目推廣。

7、負責相關技術文檔的擬訂。

8、負責對業務領域內的技術發展動態。

(5)程序員如何向項目經理估算工時擴展閱讀：

職業要求

一般的程序員都有四年的在專業領域的學習，需要一個在程序領域的學士學位獲得者，不論是數學方面的還是工程方面的都是可以的。

大約有20%的人在這一領域的計算機科學和工程學擁有更高的學位。還有很小一部分程序員是自學的，盡管一些專業性的學校或者綜合大學可以提供，但是也需要一些別的途徑來提供相關的人才。

盡管學歷是比較重要的，但是公司經常把重點放在應聘者的工作經驗上，很多剛從大學畢業的大學生雖然有引人注目的學位證書，但是他們找不到工作是因為他們缺乏經驗。

一個程序員雖然沒有正規的學歷，但是如果一個人擁有程序設計的深厚知識背景或者豐富的工作經驗的話，那麼他的機會要比有學歷的應屆畢業生大得多。

對於職業程序員，另外一個重要的方面就是，程序員需要不斷提升自己的業務技術，他的技術必須一直保持在一個較高的水平，並且要不斷發展，程序員也要尋找貿易的機會，要參加研討會，在周刊上發表文章和接受職業教育，這些使程序員在自己的領域中分級或者不斷並排前進。

⑥ 一個軟體項目如何評估工作量和成本

軟體開發成本估算過程可進一步細分為軟體規模估算、工作量估算、成本估算和確定軟體開發成本等四個過程。

其中成本估算需要對直接人力成本、間接人力成本、間接非人力成本及直接非人力成本分別進行估算。

國家標准《GB/T 36964-2018 軟體工程 軟體開發成本度量規范》中建議的軟體開發成本估算基本流程如下圖所示：

國家准中的四個估算過程，層層遞進，逐步細化，最終達到科學、一致的成本估算。

一、軟體規模估算

通常情況下，規模估算是軟體成本估算過程的起點。

估算規模是後續計算軟體項目的工作量、成本和進度的主要輸入，是項目范圍管理的關鍵，因此，在條件允許的情況下，應首先進行規模估算。

在規模估算過程中，需要注意以下情況：

1. 在規模估算開始前，應根據可行性研究報告或類似文檔明確項目需求及系統邊界。項目需求除包含最基本的業務需求外，還應進行初步的子系統/模塊劃分，並對每一子系統或模塊的基本用戶需求進行說明，以保證可以根據項目需求進行規模預估。

2. 依據項目特點和需求詳細程度不同，通常估算人員在選擇估算方法時應採用納入國際標準的功能點方法進行功能規模估算，在適用IFPUG或NESMA方法時，可以根據需求的粒度和管理需要，選擇預估功能點方法、估算功能點方法或者詳細功能點方法。

3. 若當前的項目需求極其模糊或不確定，可不進行規模估算，而直接採用類比法或類推法估算工作量和成本。

二、工作量估算

在完成規模估算後，應當開展工作量估算工作，若當前項目未開展規模估算，也可直接啟動工作量估算工作。

工作量估算時，可採用方程法、類比法、類推法、功能點法：

• 方程法：即基於基準數據建立參數模型，通過輸入各項參數，確定估算值。

• 類比法：即將待估算項目的部分屬性與類似的一組基準數據進行比對，進而確定估算值。

• 類推法：即將待估算項目的部分屬性與高度類似的一個或幾個已完成項目的數據進行比對，並進行適當調整後確定估算值。

• 功能點法：從用戶視角出發，通過量化系統功能來度量軟體的規模，這種度量主要基於系統的邏輯設計。功能點規模度量方法在國際上的應用已經比較廣泛，並且已經取代代碼行成為最主流的軟體規模度量方法。

在開展工作量估算的過程中，需要注意以下情況：

1. 當需求極其模糊或不確定時，如果此時具有高度類似的歷史項目，則可直接採用類推法，充分利用歷史項目數據來粗略估算工作量。

2. 當需求極其模糊或不確定時，如果此時具有與本項目部分屬性類似的一組基準數據，則可直接採用類比法，充分利用基準數據來粗略估算工作量。

3. 對於規模估算已經開展的項目，可採用方程法，通過輸入各項參數，確定待估算項目的工作量。若客戶或高層對項目的工期有明確的要求時，在採用方程法估算工作量時，工期要求有可能是方程的參數之一。

4. 為追求估算的准確性，建議在條件允許的情況下，可採用兩種估算方法，對估算結果進行交叉驗證，若估算結果差別不大，可直接使用兩種估算結果的平均值或以某種估算結果為准，若差別較大，需進行差異分析。

5. 工作量的估算結果宜為一個范圍而不是單一的值。

三、成本估算

在獲得了工作量估算結果後，可採用科學的方法進行成本估算。

在成本估算過程中，應需要注意的情況：

1. 類比法和類推法，同樣適用於需求極其模糊或不確定時的成本估算；

2. 間接成本是否與工作量估算結果相關取決於間接成本分攤計算方式。在絕大多數組織，項目周期越長，項目組成員越多，其分攤的間接成本就越高，此時項目的間接成本與工作量估算結果直接相關；

3. 直接非人力成本通常與工作量估算結果無關，宜單獨分項測算；

4. 成本估算結果，也通常為一個范圍，而不是單一的值。

四、確定軟體開發成本

在《軟體工程 軟體開發成本度量規范》中，將軟體開發成本分為四類，主要是為便於對成本構成（即哪些成本屬於開發成本，哪些不屬於開發成本）進行清晰界定。

而在實際確定軟體開發成本時，通常並不是分別測定四類成本，加和後獲得總成本，而是通常採用以下兩種方式確定總成本：

• 根據人力成本費率及工作量估算直接人力成本和間接成本之和，再加上直接非人力成本，獲得總成本；

• 根據規模綜合單價和軟體規模，測算出直接人力成本和間接成本之和，再加上直接非人力成本，獲得總成本。

在進行軟體的規模、工作量、成本估算時應遵循以下原則：

1. 在規模估算時,應根據項目特點和需求的詳細程度選擇合適的估算方法；

2. 充分利用基準數據,採用方程法、類比法或類推法,對工作量和成本進行估算；

3. 工作量和成本的估算結果宜為一個范圍值；

4. 在進行成本估算時,如有明確的工期要求,應充分考慮工期對項目成本的影響,可以根據項目實際情況以及工期對項目的影響程度,對成本的估算結果進行調整；

5. 成本估算過程中宜採用不同的方法分別估算並進行交叉驗證。如果不同方法的估算結果產生較大差異,可採用專家評審方法確定估算結果,也可使用較簡單的加權平均方法；

6. 在軟體項目的不同場景下(如預算、招投標、項目計劃和變更管理等)採用國家標准時,相關要求見國家標准中附錄A。

除了上述主要原則外，我們還需注意在使用基準數據時：

• 對於委託方和第三方，建議使用或參考軟體行業基準數據進行估算。估算模型的調整因子的增減或取值有可能隨著行業基準數據的變化而變化。

• 對於開發方，在引入行業基準數據的基礎上，可逐步建立組織級基準資料庫，以提高估算精度。組織級基準數據定義應與行業基準數據定義保持一致，以便於與行業基準數據進行比對分析，並持續提升組織能力。

⑦ 作為一個程序員，怎樣處理好和項目經理之間的關系

良好的溝通是最關鍵的，這不僅是程序員和項目經理之間，更適用於所有的關系
他分配任務指標後。
1.首先要明確他的意思，最好和他重復一下，看看你有沒有理解錯，他不會因此煩的，因為如果你的理解偏差了做出來的東西有差距，到時反而更麻煩了。
2.在做的過程中，隨時發現問題難以解決，或難以達到預期的目標要馬上向他反映，讓他明白你的難點幫助你解決或者讓其他人幫助你。
3.明確項目進程，及你的工作完成時間表，隨時反映你的工作進程，如覺得時間有困難，要提前溝通，因為項目經理會有一個整個的統籌安排，你的一個環節的滯後可能會導致整個項目的無法進行，事先通知就可以提前修改安排，不會導致項目的停頓，而且原因可以理解他不會怪你的。
希望可以幫到你，謝謝！

⑧ java程序員如何到項目經理

項目經理的職責

1.確保項目目標實現，保證業主滿意 這一項基本職責是檢查和衡量項目經理管理成敗、水平高低的基本標志。

2.制定項目階段性目標和項目總體控制計劃 項目總目標一經確定，項目經理的職責之一就是將總目標分解，劃分出主要工作內容和工作量，確定項目階段性目標的實現標志如形象進度控制點等。

3.組織精乾的項目管理班子 這是項目經理管好項目的基本條件，也是項目成功的組織保證。

4.及時決策 項目經理需親自決策的問題包括實施方案、人事任免獎懲、重大技術措施、設備采購方案、資源調配、進度計劃安排、合同及設計變更、索賠等。

5.履行合同義務，監督合同執行，處理合同變更 項目經理以合同當事人的身份，運用合同的法律約束手段，把項目各方統一到項目目標和合同條款上來。

作為程序員平時不僅單單只寫程序和文檔，要學管理的經驗，項目的模塊分割與人員分配，調節人員之間的合作里......總之要學的很多，最要的是有項目經驗。

⑨ 如何做好項目成本管理

如何做好項目成本管控
在項目實施的過程中，成本管控起著非常重要的作用。隨著市場競爭越來越激烈，價格逐漸透明，對企業來說要做到有競爭力，成本的管控尤為重要，因為它直接關繫到項目的利潤。成本項有人工費，材料費，一般費用等等，需要有個數字化的管理系統來進行科學的管理。
1. 存在的問題
以軟體項目為例，我國大多數軟體項目的參與人員為技術型人才，近年來隨著大廠的推波助瀾，薪資也是水漲船高。作為項目管理人員，一般也是從技術型轉為管理崗，但是普遍的經濟觀念薄弱，將項目成本的管理歸責於財務部門。財務部門缺少數據支持，無法做出客觀的成本分攤。
另一方面，是缺少過程管理。我們項目開始的時候需要做預算，如果沒有預算就沒有參考的基線，而預估項目預算這個工作本身需要由項目經理來評估，項目經理需要根據參與人員的薪資水平，投入的預估工作日來核算出來預算。評估工時本身也是要有對類似工作量的歷史工時來做參考，如果沒有一個系統，項目經理只能憑借自己的感覺或者開發人員自己的主觀評估，缺少客觀數據支撐的情況下，作為管理層也沒辦法評判這個預算是多是少。預算做好了，項目推進過程中，對於人員工時的實際分配沒有及時追蹤，有的只是用Excel記錄，對數據的真實性難以保證，並且缺少流程化管理。這些在企業想要做融資上市，進行第三方財務審計的時候，都是不符合要求的。

2. 解決方案
我們需要制定完善的成本管理制度，在項目開展前進行預算評估，以筆者參與的一些大中型項目經驗來看，可以採取雙向的評估方案。先由管理者從上往下進行約束性預算評估，即有最高管理者依據以往項目預算的情況來按照最小預算評估，再分配到各個部門或者環節分別給予預算值，再由各個部門或環節的負責人依照給予的預算值進行二次核對評估，如沒有較大出入即可再次向下分配，一直到最小的團隊單元。任何一個環節的評估超出上層分配的預算值，可依據實際情況反饋申請更多的預算。這樣確定下來的才是相對准確合理的預算。對預算也要進行分批下撥，方便分階段管控和調整。比如一個大項目可以拆分為一期二期或者按季度下撥。項目推進過程中，需要記錄實際成本，包括人工成本和費用報銷的成本，有的也需要將水電費房租等分攤到項目上。其中最復雜的是人工成本，它依賴於員工自己在各個項目上的工時投入情況。粗放一點的管理方法是由部門的負責人進行每日/每周統一填報分配，精細切實的管理方法是員工每日填報日報，將自己的一天工時分配到各個項目上，同時匯報相應時間的工作內容。審核的方法也有多種，視團隊規模而定。一般30人以下的公司建議項目經理審核即可，100人左右的團隊可以由部門負責人+項目經理兩層審核，300人及以上的可以由分組負責人+項目經理+部門負責人三層審核，對於特殊部門也可以適當增減審核環節。
再好的管理制度和方法也必須結合軟體來落地執行。我們用的是工時管家管理系統(https://www.ttkuaiban.com)，可以管理項目開展全過程，支持成本預算的管理，分季度/月度下撥預算，並能對人工成本進行實時管控。員工可以每天或者按周填報工時，審批支持多層級，每月可以出具項目成本報表，支持財務上的人員薪資分攤，非常方便，大大提高了管理者的工作效率。

⑩ 如何管理項目成本之－工時管理

工時管理第一步：工時錄入與人工費率確定

首先，如何保證項目成員將工時填入系統中？很多企業，公司對項目成員的考核，往往以工作的努力程度來衡量。因此項目成員不想被把每天工作的時間透明化，否則他們就沒有自由了（比如知道他出差一天就幹了兩小時活，公司經理該怎麼想？）。同時，項目經理也不想填工時，因為不想把項目成本算得那麼清楚，否則就要對成本負責。於是很多企業的項目管理中就沒有成本的概念，只關注進度。這時候，企業如果強制要求項目組填工時，他們往往會多填，以顯得工作努力，你看項目忙多啊。工時系統是管不了數據質量問題的，怎麼辦呢？想想，如果我們不但考核項目進度，還考核項目成本，項目經理就會讓項目成員少填工時，以降低成本。這時候矛盾就產生了，項目經理希望少填工時，項目成員希望多填工時。這就是問題的本質，如何利用好這對矛盾，讓項目經理與項目成員的矛盾達成一定平衡，工時錄入問題就能解決，顯然，學過博弈論或者有生活常識的人都知道，這個平衡的結果就是大家都說真話，填報真工時——問題的解決辦法找到了，但是不是就這樣加上一個成本考核就行了呢？沒有基準的比較，考核是沒有用的，因此還需要一個建立項目成本基準的過程。

變革往往需要和風細雨，企業要做好工時管理，找到了問題的根本點，也不能急於求成，要通過一定的變革，來改變人的習慣，建立項目績效基準。比如應該先要求成員盡量將工時填到系統，並將填報工時的項目組，成立標桿進行一定的獎勵，通過榜樣的力量，使項目成員形成一定的習慣，逐步建立企業項目成本與進度的基準，然後，再請君入瓮，慢慢納入考核，這樣經過1－3年的調整，工時管理就基本上能做起來了。

其次，人員費率如何確定？很多人可能會直接把人員日平均或小時工資作為人工費率，從企業運作的角度而言，這是不正確的。打個比方，你招聘一名員工後，除了發工資外，你要對他進行培訓，要給他配備辦公設備，水電，電話費，辦公場地，衛生費等等，這些都是企業的用人成本，也必須要分攤到人工費率，才是准確的。據調查，一個企業使用一名員工的平均成本是其工資水平的3－6倍，因此很多國際企業做法，就是參照一些行業的標准，把人員的平均工資乘以3－6倍，來作為人工費率。（當然不能行業差異較大，你可以通過參照同行業的水平，或者根據本企業財務來計算。如：人均工資＋公共費用分攤等）工時管理第二步：工時的利用

當一個公司真正把工時管理好以後，除了能比較准確的計算項目成本外，工時還具有其他非常重要的應用：

1、 建立員工能力基線

某一崗位的員工做某一任務花的時間多少，很多情況可以直接反映該崗位員工的能力，經過多個員工多個項目的統計分析後，企業就可以概要的分析出，做某一崗位員工的所需要的平均能力，我們稱為能力基線，將能力基線與目前在崗員工的工作能力對比，如果發現該員工能力低於能力基線，企業就應該去分析，是其工作態度，還是工作安排的問題，就要採取相應的培訓或者激勵方式。如果發現某員工能力高於基線，企業可能需要去獎勵該員工，讓別的員工也產生更高的績效等，因此能力基線是成為企業人力資源政策的重要依據。同時當能力基線建立後，項目計劃的進度就可以比較准確的估算，一個企業當項目成本與進度都可以清楚的計算出來，項目管理與控制就顯得容易，別且可以開展與同行業，甚至跨行業的基準比較。不斷的提升員工能力，進而提升企業整體能力。

2、 建立企業資源管理依據

作為企業的高層經理或者人力資源總監，可能都經歷過這樣的事情：當一個職能經理或者項目經理，提出該部門或項目組人員不夠，需要申請加人或者招聘員工，企業如何來判斷是否真的需要？有什麼依據？如果通過工時計算，我們就非常清楚了。比如一個部門現有員工10人，按照公司上班如每天工作8小時，有效工作時間加入為6個小時，每周上班5填，該部門每周總的有效工作時間至少為300小時.人。如果整個部門的統計工時少於300個小時.人，說明部門工作量還不飽滿，就應該不需要招聘新人，而需要加強有效工作時間，比如減少非正常請假，減少員工閑聊的時間等，如果工時統計已經超過400小時.人了，說明部門為完成工作，已經在努力加班，超負荷運轉了，這時候，企業可能就一定要考慮為該部門增加人員配置了。同時如果，經過統計發現某部門一年的有效工時遠低於其部門的標准工時，說其部門員工工作量可能不飽和，對其部門經理要進行考核，該部門也可能需要裁員以降低成本了。這也避免了，每年職能經理為了爭取多的人員配置，爭得面紅耳赤。

3、 EVM管理方式的實現

EVM在項目管理中是個非常好的概念，可以通過掙值將項目計劃，成本，進度聯系起來，非常直觀的監控與預測項目現有及未來的成本是否超支，進度是否延遲等，但很多企業做不起來，因為沒有其中掙值，計劃值，實際值無法計算。如果，工時管理做好後，員工能力基線制定出來，每個任務的計劃值，掙值，實際值就很容易計算，EVM管理方式就能建立起來。很多時候，企業在評價項目績效，決定給項目經理或團隊進行獎勵時，因為項目的差異，很多指標難以直接比較，而找不到比較的標准。但EVM跟項目類型的關系不大，可以在項目之間進行橫向比較。因此，EVM的建立，使在企業內，甚至行業間的跨項目績效比較機制可以建立起來，項目績效的好外可以直接放映出企業項目管理能力的差異，為公司項目管理能力提升，流程績效改進提供依據，這一切，工時管理公不可沒。

4、 工序管理與BPO成為可能

所謂工序就是為了完成某一工作的一個個步驟或相互關聯的任務，工序連接起來，我們可以稱為流程或者工作流。當我們建立每個員工的工時，並通過任務的對應，我們就知道該任務的工時，將任務整合到一定的維度，就得到工序的工時。有了工序工時，我們就可以通過分析工序的工時，來判斷我們整個流程環節的瓶頸，並通過改善瓶頸而提高流程的效率。對於一個企業而言，其效率的高低，處決於整個流程的系統效率，而不是單個節點的效率。很多企業在面對效率低下的時候，往往無法判斷問題出在哪兒。如果有工序工時管理，問題可能就簡單得多。

另外通過工序管理，我們能發現哪些工序在企業的成本是比較高的，並且是企業的非核心競爭力的流程。而這些流程可以通過外包給擅長於該方面的第三方，通過直接獲取第三方的專業服務，企業不但可以提高效率，降低成本，更可以專注於其核心競爭力的發展。這就是現代流行的業務流程外包BPO（Bvusiness Process Outsourcing）的概念。在《世界是平的》這本書里就介紹到，每個企業都應該利用全球的資源，專注於自己擅長的領域，通過BPO的方式獲得更快速的發展，但問題是：現代很多企業，根本不知道哪些流程是自己不擅長的，而不敢外包，導致企業的高成本運作，如果能將工序管理做好，這個問題就變動容易解決，企業就可以在自己的核心競爭力領域集中精力創造更高的價值。