怎么評估開發任務的工時更合理

這篇文章主要講解了“怎么評估開發任務的工時更合理”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么評估開發任務的工時更合理”吧！

為什么要評估工時？

在敏捷開發過程中，注重的是快速迭代，通過小步快跑，盡快向用戶交付可用的產品，不斷提升用戶體驗，贏得用戶的認可和滿足業務發展的需求。

當產品經理提出一個需求后，作為需求方，例如市場部、運營部或客戶，都是希望這個需求能盡快上線，并且期望能知道預期可以上線的時間節點，以便安排下一步工作計劃。

而需求的上線時間，往回倒推，需要參與此需求的開發人員進行評估后，才能給出相對準確的時間排期。最后，就是把抽象的需求拆解成每個技術人員可以在指定時間內完成的一個個小任務。當評估好任務工時后，項目經理或技術負責人，才能把整個需求的時間節點和項目里程碑整理出來，再反饋給需求方。

這樣，從需求到任務，從工時評估再回到項目排期，就形成了一個正向良好的反饋機制，不僅能明確職責分工，還能提升團隊的協作效率。敏捷開發起來，更接地氣，更有效率。

開發工時評估為什么那么難？

但關于工時評估，在實際情況中會存在一些矛盾。

一方面是，作為產品人員，通常會覺得這個需求很簡單，不就是改幾行代碼嗎？幾分鐘就能搞定了。另一方面，作為不太懂技術的老板，往往不知道技術人員評估的工作量是不是太高了？

此外，作為技術人員本身而言，評估工時也是一件很有挑戰的事情。

為什么呢？根據多年的項目經驗總結，我覺得主要有兩個因素。不確定性和任務場景。

不確定性，是指需求和未來的不確定性。有可能是需求本身是模糊或不夠完善，沒有很詳細表明或通過文檔形式注明具體需要改動的頁面、功能、邏輯、規則和流程，也有可能是產品人員通過不斷溝通后已非常熟悉需求本身，但對于第一次接觸該需求的技術則會非常陌生。即使需求本身已經非常明確也有詳細需求文檔，出于業務系統的復雜性和關聯性，改了這個流程有可能會影響到其他流程，進而又要修改其他模塊，工作量就多了。簡單來說，技術人員或者其他人員，很難一開始就能判斷改了這個需求，會不會對其他的功能模塊有牽連和影響。就好比如，下象棋，很難一開頭就能預測接下來成千上萬的不同的結局。

任務場景，是指對于同一個需求，上下文場景環境不同，也會有很大的差異。例如開發一個登錄功能，對于實習生和高級開發工程師，或者對于剛入職和已經入職幾年的員工，難度是不同的，評估的工時也不同。同樣還是開發一個登錄功能，做一個全新的登錄功能，和在現有系統修改或升級已有功能，又是不一樣的。因為現有系統的修改，是有歷史包袱的，不僅要非常了解原有的業務邏輯，還有可能需要對歷史的數據進行額外的加工處理。如果是新系統，還要進行基礎架構的搭建。除此之外，還要看是否需要和外部第三方進行對接。如果該登錄功能是需要接入微信登錄，或者LDAP登錄，或SSO登錄，還需要熟悉外部的接入流程，溝通和調試起來也是一件很耗時間成本的事情。最后，還要看當前負責開發的技術人員，還有沒其他需求和任務在身。小結來說，任務場景要考慮需求以外的環境因素，包括但不限于技術人員本身的專業能力和工作年限、已經安排的需求和任務、對外溝通。

怎么評估工時，更合理？

怎么評估工時，取決于我們將怎么做這個需求。

曾經在我的分享PPT中，我建議不要把時間只放成開發和調試上，而是要更合理地安排自己的時間，除了編碼開發，還要針對所負責的需求，積極進行多方溝通和確認，還要學會寫文檔、進行UML建模、做單元測試、順便小步重構。

一般來說，一個需求做下來，需要的工作主要有：編寫代碼、開會、前后端聯調、寫文檔、測試改BUG、技術調研。明確我們將要做哪些事情，結合自己所在的任務場景，那么評估任務工時，就會很清晰。

根據你接收到的需求，結合現有的代碼倉庫和代碼模塊，先熟悉現有的系統、業務邏輯，以及新的需求后，就可以開始梳理本次需求的功能需求矩陣。功能需求矩陣是指，把需求功能點，和對應能看得到的界面鏈接或具體的接口鏈接關聯起來，同時把核心的技術實現方式進行標注，例如后端添加了什么新的數據庫字段。最后，別忘了加多一列備注，再仔細考慮是否還有遺忘的地方以及不確定的因素。你整理得越細致，你的工時評估就越精準，工作效率就越高。

例如：

有了這些分析和前期準備，并且通過功能需求矩陣，如果能再配套提供技術開發文檔、UML，那么你的任務評估就會更有理有據，也能讓大家非常清楚你的工作情況。自然就能讓更多人認可你的工時評估了。

評估、執行、反饋和提升

經過十年的互聯項目開發后，我發現，那些任務拆分越細的程序員，他們的工作效率就越高。因為他們能把抽象的任務評估成一個個容易被執行、可量化和可控制的任務單元，然后執行。

執行過程中，注意是執行過程中，不是執行后，及時給出反饋。當需求不明確時，他們會找需求方進行確認和溝通；當接口或界面做好時，他們會主動找相應的技術人員進行技術聯調；當功能完成開發后，他們會進行自測、code review和代碼重構；當發現問題時，他們及時做出響應；當測試通過后，他們會提前做好上線準備和清單確認；當發布上線后，他們會在上線半小時內對線上進行確認并通知產品經理“此需求已上線，請及時驗收。”

反饋真的很重要。

這樣，經過不斷地迭代，完成一個又一個的開發任務，攻克一個又一個的難題和挑戰，你就會發現，原來前面一直在爬坡，突然間你會發現，原來自己離骨灰級的技術大牛的距離已經不久了。

越努力，越幸運！

團隊如何高效協作開發任務？

前面已經分享了個人如何評估任務工時，以及如何快速開發。接下來，再來探討下團隊如何高效協作開發。作為一個團隊，配合得越緊湊，整體效率會越高，士氣也會更旺盛。

一個項目，做下來，有幾個明顯的特點：時間周期長、參與人員多、信息龐雜。如果安排不當，很難讓參與在其中的每個技術人員發揮更大的價值。

以下實踐值得參考：

周一做計劃、周五做總結；

需求有響應、項目有進度。

1、周一做計劃

每周一，是很多例會召開的一天，也是每周新的一天。在這一天，如果能把上周的工作情況和這周的目標再系統性梳理一番，分配落實到每個人身上，再讓每個技術人員評估好開發任務，做好計劃，就會形成整體團隊這一周的工作排期。

例如，在YesDev的工作排期中，下面是我們團隊這一周的工作計劃。曾經在某企業任職時，每周要匯總團隊的工作情況和任務工時，我都很痛苦，因為要手動匯總團隊近10人的工時，但有了這里的工作排期，可以直接導出Excel，一下子就可以發給老板查看了。你好我好大家好！^_^

YesDev還有個很好的工具，就是當你在指派任務時，可以快速看到他的工作飽和度。

2、周五做總結

周五下班前，通過周報的形式，讓團隊的每個人把這一周的工作情況，完成的任務以及下周的計劃，匯報上來，不僅是對每個人的總結和提升，也是整個團隊向上匯報的重要通道。要讓自己的工作看得見，讓團隊的成就看得見。更重要的是，每周一封郵件，一年下來大概是50多封郵件。這一年是怎么突破的，回顧這些郵件，你會清晰發現我們走過了哪些路，跨越了哪些重要的里程碑。不僅能回顧過去，不能展望未來。認真做事的態度，必然會取得更驕人的成果！

在YesDev中，對于周報，有一個很大的創新功能，就是可以根據每個人的工作情況，自動生成每個人的工作周報，大大節省了編寫郵件的時間。保存后還可以直接發給團隊或你的上級。

3、需求有響應

當產品經理提出需求后，負責需求的技術人員會及時收到郵件通知。當需求被完成后，產品經理也能及時收到相關的郵件通知。如果你既不是產品經理也不是技術人員，若對此需求感興趣，可以關注此需求。那么你也能及時收到需求的最新動態通知。

例如這樣的郵件通知：

4、項目有進度

首先，對項目進行任務評估后，會得到任務列表。這部分，需要技術人員自己進行評估。

評估完成后，將可以自動得到：項目排期表和項目燃盡圖。

項目排期表會把重要的負責人、時間節點和項目里程碑自動生成出來，方便項目經理或技術負責人進行項目管理和團隊協作。

項目排期是靜態的、是理論的。而項目燃盡圖則是實際的執行情況。這就好比如你設置了一個目標，今天下班后要跑5公里，預計30分鐘跑完。可能最終情況是，你只跑了3公里，并且花了1小時。因為實在跑不動了。

感謝各位的閱讀，以上就是“怎么評估開發任務的工時更合理”的內容了，經過本文的學習后，相信大家對怎么評估開發任務的工時更合理這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！