項目開發(fā)管理最佳實踐指南第一章項目啟動與戰(zhàn)略對齊1.1項目目標(biāo)設(shè)定與價值驗證1.1.1目標(biāo)設(shè)定原則項目目標(biāo)需遵循SMART原則：具體（Specific）、可衡量（Measurable）、可實現(xiàn)（Achievable）、相關(guān)性（Relevant）、時限性（Time-bound）。例如某電商平臺改版項目目標(biāo)可設(shè)定為“3個月內(nèi)完成用戶首頁改版，核心路徑率提升15%，新用戶注冊轉(zhuǎn)化率提升10%”，避免“優(yōu)化用戶體驗”等模糊表述。1.1.2價值驗證方法可行性分析：從技術(shù)（現(xiàn)有技術(shù)棧能否支撐）、經(jīng)濟(jì)（投入產(chǎn)出比是否合理）、運營（是否符合業(yè)務(wù)戰(zhàn)略方向）三個維度評估項目價值。干系人共識：通過需求研討會（邀請產(chǎn)品、技術(shù)、市場、客服等角色參與）明確項目核心價值，形成書面化的《項目價值說明書》，作為后續(xù)決策依據(jù)。1.2需求分析與范圍界定1.2.1需求獲取與分層需求來源：通過用戶調(diào)研（問卷、深度訪談）、業(yè)務(wù)部門訪談（銷售、運營）、競品分析（功能對比、用戶反饋日志）收集需求。需求分類：按優(yōu)先級分為“基本需求”（必須實現(xiàn)，如用戶登錄功能）、“期望需求”（可提升體驗，如記住登錄狀態(tài)）、“興奮需求”（差異化競爭點，如智能推薦）。1.2.2范圍邊界定義范圍說明書：明確項目“包含”與“不包含”的內(nèi)容，例如“本次迭代包含購物車功能優(yōu)化，不包含支付接口擴(kuò)展”。WBS（工作分解結(jié)構(gòu)）：將項目拆解為可交付成果的層級結(jié)構(gòu)（如項目→階段→任務(wù)→子任務(wù)），每個任務(wù)需明確責(zé)任人、交付標(biāo)準(zhǔn)及時限。例如“用戶模塊”可分解為“注冊功能”“登錄功能”“個人中心”，其中“注冊功能”進(jìn)一步分解為“手機(jī)號驗證”“短信驗證碼”“密碼設(shè)置”三個子任務(wù)。1.3可行性研究與立項審批1.3.1技術(shù)可行性評估技術(shù)棧選型：根據(jù)項目復(fù)雜度選擇技術(shù)方案，例如高并發(fā)交易系統(tǒng)推薦“微服務(wù)架構(gòu)+容器化部署”，中小型項目可采用“單體架構(gòu)+云服務(wù)器”。技術(shù)風(fēng)險預(yù)判：識別潛在技術(shù)瓶頸（如第三方接口穩(wěn)定性、數(shù)據(jù)遷移風(fēng)險），制定應(yīng)對方案（如接口Mock測試、數(shù)據(jù)備份策略）。1.3.2經(jīng)濟(jì)與運營可行性成本估算：采用類比估算法（參考?xì)v史項目）或參數(shù)估算法（按功能點規(guī)模計算），明確人力、硬件、第三方服務(wù)等成本明細(xì)。立項審批流程：提交《項目立項申請書》（含目標(biāo)、范圍、成本、計劃、風(fēng)險），由項目管理委員會（PMO）組織評審，通過后簽署《項目章程》，明確項目授權(quán)、資源及考核標(biāo)準(zhǔn)。第二章項目規(guī)劃與資源管理2.1進(jìn)度計劃與關(guān)鍵路徑控制2.1.1進(jìn)度計劃編制里程碑計劃：設(shè)定關(guān)鍵節(jié)點（如“需求凍結(jié)完成”“開發(fā)完成”“上線發(fā)布”），作為進(jìn)度監(jiān)控的基準(zhǔn)。甘特圖繪制：基于WBS任務(wù)清單，明確任務(wù)起止時間、依賴關(guān)系（如“支付功能開發(fā)”依賴“訂單功能完成”）、資源分配，使用工具（如MicrosoftProject、Teambition）可視化展示。2.1.2關(guān)鍵路徑法（CPM）應(yīng)用關(guān)鍵路徑識別：通過計算任務(wù)總時差（浮動時間為0的任務(wù)鏈），確定影響項目總工期的核心任務(wù)。例如某項目關(guān)鍵路徑為“需求分析→系統(tǒng)設(shè)計→核心功能開發(fā)→測試→上線”，需優(yōu)先保障這些任務(wù)的資源投入。進(jìn)度壓縮策略：若關(guān)鍵路徑延遲，可采用趕工（增加資源投入，如加班、增加開發(fā)人員）或快速跟進(jìn)（并行處理，如設(shè)計未全部完成即開始部分開發(fā)），需評估成本與風(fēng)險。2.2成本預(yù)算與資源分配2.2.1成本預(yù)算編制成本基線：將總成本分解至各階段（如需求階段10%、開發(fā)階段50%、測試階段20%、上線運維階段20%），形成《項目成本預(yù)算表》，作為成本控制的依據(jù)。應(yīng)急儲備：預(yù)留總預(yù)算的10%-15%用于應(yīng)對未知風(fēng)險（如需求變更、技術(shù)故障），由PMO統(tǒng)一管理，使用需審批。2.2.2資源分配優(yōu)化資源平衡：根據(jù)任務(wù)優(yōu)先級和資源可用性（如開發(fā)人員同時參與2個項目時，需分配工作量占比），避免資源過載或閑置。資源日歷：明確各資源的工作時間、技能要求（如“前端開發(fā)需熟悉React，有3年以上經(jīng)驗”），提前協(xié)調(diào)跨部門資源（如UI設(shè)計師需配合多個項目排期）。2.3質(zhì)量規(guī)劃與標(biāo)準(zhǔn)制定2.3.1質(zhì)量目標(biāo)與標(biāo)準(zhǔn)質(zhì)量目標(biāo)：設(shè)定可量化的質(zhì)量指標(biāo)，如“缺陷密度≤0.5個/千行代碼”“線上故障率≤0.1%”“用戶滿意度≥4.5/5分”。質(zhì)量標(biāo)準(zhǔn)文檔：明確各階段交付物的質(zhì)量要求，如《需求規(guī)格說明書》需通過需求評審（覆蓋率100%），代碼需通過靜態(tài)代碼檢查（SonarQube評分≥90分）。2.3.2質(zhì)量保證活動技術(shù)方案評審：在系統(tǒng)設(shè)計階段組織架構(gòu)師、技術(shù)骨干評審設(shè)計方案，保證技術(shù)可行性、擴(kuò)展性及安全性。代碼規(guī)范執(zhí)行：制定《開發(fā)編碼規(guī)范》（如命名規(guī)則、注釋要求、安全編碼），使用ESLint、PMD等工具強制檢查，未達(dá)標(biāo)代碼不予合并。第三章敏捷與瀑布融合的流程設(shè)計3.1混合式開發(fā)模型選擇3.1.1模型適用場景瀑布+敏捷融合策略：需求明確、變更較少的階段（如系統(tǒng)架構(gòu)設(shè)計、核心模塊開發(fā)）采用瀑布模式（嚴(yán)格按階段推進(jìn)）；需求不穩(wěn)定、需快速迭代的階段（如功能優(yōu)化、用戶體驗改進(jìn)）采用敏捷模式（Scrum或看板）。示例：某金融APP項目，核心交易模塊采用瀑布模式（需求→設(shè)計→開發(fā)→測試→上線），營銷活動模塊采用Scrum模式（2周迭代，每周交付可運行版本）。3.1.2關(guān)鍵實踐結(jié)合需求管理：瀑布階段輸出《需求規(guī)格說明書》（凍結(jié)基線），敏捷階段通過用戶故事（UserStory）細(xì)化需求（“作為用戶，我希望在購物車中批量刪除商品，以提高操作效率”），并維護(hù)需求優(yōu)先級列表（ProductBacklog）。3.2敏捷迭代與瀑布階段銜接3.2.1迭代計劃與規(guī)劃迭代目標(biāo)對齊：每個迭代開始前，召開迭代計劃會（SprintPlanning），根據(jù)產(chǎn)品待辦列表（ProductBacklog）選擇本次迭代需求，明確迭代目標(biāo)（如“完成購物車功能迭代”）及驗收標(biāo)準(zhǔn)（DefinitionofDone,DoD）。DoD制定：明確任務(wù)完成標(biāo)準(zhǔn)，如“代碼通過單元測試覆蓋率≥80%”“無P0/P1級缺陷”“文檔齊全”，避免“開發(fā)完成即結(jié)束”的誤區(qū)。3.2.2階段性交付與評審里程碑評審：在瀑布階段關(guān)鍵節(jié)點（如設(shè)計完成、開發(fā)完成）組織正式評審會，輸出評審報告（通過/不通過及改進(jìn)項），保證交付物符合質(zhì)量標(biāo)準(zhǔn)。敏捷回顧會：每個迭代結(jié)束后召開回顧會（SprintRetrospective），總結(jié)“做得好的”“待改進(jìn)的”“行動項”，持續(xù)優(yōu)化流程（如“減少需求變更頻次”“縮短代碼合并等待時間”）。3.3需求變更控制機(jī)制3.3.1變更影響分析變更申請流程：任何需求變更需提交《變更申請單》（含變更內(nèi)容、原因、預(yù)期收益），由產(chǎn)品、技術(shù)、測試聯(lián)合評估影響（對進(jìn)度、成本、質(zhì)量的影響）。分級審批：根據(jù)變更影響大小分級審批（如影響范圍≤5%、成本增加≤10%由項目經(jīng)理審批；超出權(quán)限上報項目管理委員會）。3.3.2變更實施與跟蹤變更版本管理：批準(zhǔn)的變更納入產(chǎn)品待辦列表，按優(yōu)先級安排后續(xù)迭代開發(fā)，避免在當(dāng)前迭代中隨意插入變更導(dǎo)致進(jìn)度失控。變更記錄：維護(hù)《變更日志》，記錄變更內(nèi)容、審批人、實施狀態(tài)及影響，保證項目可追溯性。第四章跨職能團(tuán)隊協(xié)作機(jī)制4.1角色職責(zé)與能力矩陣4.1.1核心角色定義產(chǎn)品負(fù)責(zé)人（PO）：負(fù)責(zé)需求梳理、優(yōu)先級排序及產(chǎn)品目標(biāo)達(dá)成，需具備用戶洞察力和業(yè)務(wù)理解能力。ScrumMaster（SM）：負(fù)責(zé)敏捷流程落地、團(tuán)隊障礙清除，保證會議高效（如控制每日站會≤15分鐘），充當(dāng)“服務(wù)型領(lǐng)導(dǎo)”。開發(fā)工程師：負(fù)責(zé)功能實現(xiàn)、代碼質(zhì)量，需掌握TDD（測試驅(qū)動開發(fā)）原則，參與技術(shù)方案設(shè)計。測試工程師：負(fù)責(zé)制定測試計劃、執(zhí)行測試用例，需具備自動化測試能力（如Selenium、Appium），推動缺陷修復(fù)。4.1.2能力矩陣構(gòu)建技能清單：梳理團(tuán)隊成員技能（如“Java開發(fā)：SpringCloud、MySQL；前端：Vue、TypeScript”），繪制能力矩陣（技能掌握程度：知曉/掌握/精通），識別技能缺口。技能提升計劃：針對缺口制定培訓(xùn)計劃（如“組織Redis功能調(diào)優(yōu)內(nèi)訓(xùn)”“安排參與開源項目提升架構(gòu)能力”），保證團(tuán)隊具備項目所需核心技能。4.2溝通機(jī)制與信息同步4.2.1會議體系設(shè)計每日站會：聚焦“昨天完成什么、今天計劃什么、遇到什么阻礙”，問題當(dāng)場記錄，會后由SM跟進(jìn)解決，避免冗長討論。迭代評審會：向干系人演示迭代成果（如“本次迭代完成購物車功能，支持批量刪除、優(yōu)惠券疊加使用”），收集反饋并更新需求優(yōu)先級?？绮块T協(xié)調(diào)會：針對涉及多團(tuán)隊的任務(wù)（如支付接口對接），每周召開協(xié)調(diào)會，明確接口人、進(jìn)度節(jié)點及問題解決機(jī)制。4.2.2協(xié)同工具與文檔管理工具選型：根據(jù)團(tuán)隊規(guī)模選擇協(xié)作工具（如小團(tuán)隊用飛書文檔+Jira，大團(tuán)隊用Confluence+AzureDevOps），保證需求、任務(wù)、文檔集中管理。文檔規(guī)范：制定《文檔命名規(guī)范》（如“項目名-階段-文檔類型-版本號”，如“電商APP-需求階段-PRD-v1.2”），明確文檔更新頻率（如需求變更后24小時內(nèi)更新PRD），避免信息滯后。4.3沖突管理與決策機(jī)制4.3.1常見沖突類型與應(yīng)對需求優(yōu)先級沖突：PO與開發(fā)對需求優(yōu)先級有分歧時，通過價值成本矩陣（價值高、成本低優(yōu)先）量化評估，或由項目管理委員會仲裁。資源分配沖突：多個項目爭奪同一資源時，根據(jù)項目戰(zhàn)略重要性（如“戰(zhàn)略級項目>戰(zhàn)術(shù)級項目”）及緊急程度排序，必要時協(xié)調(diào)外部資源（如外包開發(fā)）。4.3.2決策流程與授權(quán)決策權(quán)劃分：明確不同層級的決策權(quán)限（如技術(shù)方案由技術(shù)負(fù)責(zé)人決策，預(yù)算調(diào)整由項目經(jīng)理決策，項目范圍變更由PMO決策）。快速決策機(jī)制：針對緊急問題（如線上故障），授權(quán)一線人員（如運維負(fù)責(zé)人）先處理再上報，避免層層審批延誤時機(jī)。第五章風(fēng)險管理全周期實踐5.1風(fēng)險識別與分類5.1.1風(fēng)險識別方法頭腦風(fēng)暴法：組織團(tuán)隊成員（開發(fā)、測試、運維、產(chǎn)品）從技術(shù)、資源、需求、外部環(huán)境四個維度列舉風(fēng)險，如“第三方支付接口不穩(wěn)定”“核心開發(fā)人員離職”“需求頻繁變更”。檢查表法：參考?xì)v史項目風(fēng)險清單（如“數(shù)據(jù)遷移失敗”“功能不達(dá)標(biāo)”），結(jié)合項目特點補充風(fēng)險項。5.1.2風(fēng)險分類與優(yōu)先級風(fēng)險分類：按來源分為技術(shù)風(fēng)險（如架構(gòu)缺陷）、管理風(fēng)險（如進(jìn)度延遲）、外部風(fēng)險（如政策變化）；按影響程度分為高（項目失?。?、中（部分功能延期）、低（輕微影響體驗）。優(yōu)先級排序：采用概率-影響矩陣（Probability-ImpactMatrix），將風(fēng)險劃分為“紅區(qū)”（高概率高影響，需優(yōu)先處理）、“黃區(qū)”（中概率中影響，需監(jiān)控）、“綠區(qū)”（低概率低影響，可暫緩）。5.2風(fēng)險分析與應(yīng)對策略5.2.1定性與定量分析定性分析：通過風(fēng)險打分（1-5分）評估概率和影響，計算風(fēng)險值（風(fēng)險值=概率×影響），例如“第三方接口故障：概率4分、影響5分，風(fēng)險值20分（紅區(qū)）”。定量分析：對高價值風(fēng)險進(jìn)行量化評估，如“需求變更導(dǎo)致成本增加：預(yù)計每次變更增加5%成本，全年變更頻次10次，總成本增加50%”。5.2.2應(yīng)對策略制定風(fēng)險規(guī)避：改變項目計劃消除風(fēng)險，如“因技術(shù)不成熟放棄采用某改用成熟技術(shù)棧”。風(fēng)險轉(zhuǎn)移：將風(fēng)險后果轉(zhuǎn)移給第三方，如“購買服務(wù)器故障保險，將硬件故障風(fēng)險轉(zhuǎn)移給保險公司”。風(fēng)險減輕：降低風(fēng)險概率或影響，如“核心開發(fā)人員離職風(fēng)險：通過AB崗機(jī)制（每模塊2人開發(fā)）、技術(shù)文檔沉淀減輕影響”。風(fēng)險接受：對低影響風(fēng)險預(yù)留應(yīng)急儲備，如“用戶量低于預(yù)期：預(yù)留市場推廣預(yù)算，通過活動拉新”。5.3風(fēng)險監(jiān)控與預(yù)警5.3.1風(fēng)險登記冊維護(hù)動態(tài)更新：維護(hù)《風(fēng)險登記冊》，包含風(fēng)險描述、類別、概率、影響、應(yīng)對策略、責(zé)任人、狀態(tài)（已識別/處理中/已關(guān)閉）、監(jiān)控頻率。觸發(fā)條件：設(shè)定風(fēng)險預(yù)警閾值，如“需求變更次數(shù)>3次/迭代”“缺陷率>2%”時觸發(fā)預(yù)警機(jī)制，啟動應(yīng)對流程。5.3.2風(fēng)險審計與復(fù)盤定期審計：每月組織風(fēng)險審計，檢查應(yīng)對措施執(zhí)行情況（如“AB崗機(jī)制是否落實”“應(yīng)急儲備是否使用”），更新風(fēng)險狀態(tài)。風(fēng)險復(fù)盤：在項目里程碑或階段結(jié)束時，回顧風(fēng)險處理效果，總結(jié)“未識別的風(fēng)險”“應(yīng)對措施失效的原因”，優(yōu)化風(fēng)險識別清單。第六章質(zhì)量保障與持續(xù)改進(jìn)6.1測試策略與用例設(shè)計6.1.1測試分層與覆蓋測試類型：按階段劃分單元測試（開發(fā)自測，覆蓋率≥80%）、集成測試（模塊間接口測試）、系統(tǒng)測試（功能、功能、安全測試）、驗收測試（用戶/業(yè)務(wù)方驗收）。測試重點：核心功能（如支付流程）、高風(fēng)險模塊（如數(shù)據(jù)遷移）、用戶體驗（如頁面加載速度≤3秒）需重點測試，分配60%以上測試資源。6.1.2用例設(shè)計方法等價類劃分：將輸入數(shù)據(jù)劃分為有效等價類（符合規(guī)則）和無效等價類（不符合規(guī)則），如“手機(jī)號輸入：有效等價類為11位數(shù)字，無效等價類為非數(shù)字、位數(shù)不對”。邊界值分析：測試邊界條件，如“年齡輸入：邊界值為0、18、120，測試0、1、17、18、119、120”。場景法：模擬用戶操作流程，如“電商購物場景：瀏覽商品→加入購物車→登錄→下單→支付→查看訂單”，覆蓋全鏈路邏輯。6.2缺陷管理與閉環(huán)6.2.1缺陷分級與處理流程缺陷分級：按影響程度分為P0級（系統(tǒng)崩潰、核心功能不可用，24小時內(nèi)修復(fù)）、P1級（功能異常、次要流程不可用，48小時內(nèi)修復(fù)）、P2級（UI問題、體驗優(yōu)化，7天內(nèi)修復(fù)）、P3級（建議性優(yōu)化，下個迭代修復(fù)）。處理流程：缺陷發(fā)覺→提交缺陷單（含復(fù)現(xiàn)步驟、環(huán)境、預(yù)期結(jié)果）→分配責(zé)任人→修復(fù)→驗證→關(guān)閉，未在SLA內(nèi)修復(fù)需升級跟蹤。6.2.2缺陷分析與預(yù)防缺陷根因分析：對P0/P1級缺陷采用“5Why分析法”，追溯根本原因（如“支付接口失敗：因第三方接口超時未配置重試機(jī)制”），而非僅修復(fù)表面問題。缺陷預(yù)防機(jī)制：定期統(tǒng)計缺陷分布（按模塊、類型、責(zé)任人），輸出《缺陷分析報告》，針對性改進(jìn)（如“數(shù)據(jù)庫操作類缺陷占比高，組織SQL優(yōu)化培訓(xùn)”）。6.3持續(xù)集成與持續(xù)部署（CI/CD）6.3.1CI/CD流程設(shè)計持續(xù)集成（CI）：代碼提交后自動觸發(fā)構(gòu)建（如Jenkins）、單元測試、靜態(tài)代碼檢查，通過后合并至開發(fā)分支，保證代碼可集成性。持續(xù)部署（CD）：測試通過后自動部署至預(yù)發(fā)布環(huán)境，執(zhí)行自動化測試（接口測試、UI測試），通過后手動/自動部署至生產(chǎn)環(huán)境。6.3.2自動化工具鏈代碼管理：使用Git（分支策略如GitFlow或GitHubFlow），代碼審查（CodeReview）通過后方可合并。測試工具：單元測試（JUnit、Pytest）、接口測試（Postman、RestAssured）、UI測試（Selenium、Cypress）、功能測試（JMeter、LoadRunner）。部署工具：容器化（Docker+Kubernetes），配置管理（Ansible），實現(xiàn)環(huán)境一致性（開發(fā)、測試、生產(chǎn)環(huán)境配置一致）。第七章項目監(jiān)控與變更控制7.1關(guān)鍵績效指標(biāo)（KPI）體系7.1.1進(jìn)度與成本KPI進(jìn)度偏差率（SV）：SV=EV（掙值）-PV（計劃價值），SV>0表示進(jìn)度提前，SV<0表示延遲，偏差率>10%需預(yù)警。成本績效指數(shù)（CPI）：CPI=EV/AC（實際成本），CPI>1表示成本節(jié)約，CPI<1表示超支，CPI<0.9需啟動成本控制措施。7.1.2質(zhì)量與風(fēng)險KPI缺陷密度：每千行代碼缺陷數(shù)，目標(biāo)≤0.5個，超過需分析原因并優(yōu)化開發(fā)流程。風(fēng)險處理及時率：已識別風(fēng)險在規(guī)定時間內(nèi)啟動應(yīng)對措施的比例，目標(biāo)≥95%。需求變更率：需求變更次數(shù)/總需求數(shù)，目標(biāo)≤20%，超過需加強需求管控。7.2監(jiān)控工具與可視化7.2.1監(jiān)控工具應(yīng)用項目管理工具：Jira、Teambition跟蹤任務(wù)進(jìn)度，燃盡圖（BurndownChart）展示剩余工作量趨勢（理想曲線vs實際曲線）。功能監(jiān)控工具：Prometheus+Grafana監(jiān)控系統(tǒng)資源（CPU、內(nèi)存）、應(yīng)用功能（接口響應(yīng)時間、錯誤率），設(shè)置告警閾值（如接口響應(yīng)時間>500ms觸發(fā)告警）。7.2.2可視化看板項目級看板：展示整體進(jìn)度（里程碑達(dá)成率）、風(fēng)險狀態(tài)（紅/黃/綠燈數(shù)量）、質(zhì)量指標(biāo)（缺陷率、測試通過率），供管理層實時查看。團(tuán)隊級看板：采用Scrum看板（ToDo→InProgress→Testing→Done），任務(wù)狀態(tài)實時更新，明確每個任務(wù)的在制品限制（WIPLimit，如開發(fā)人員同時處理≤3個任務(wù)）。7.3變更控制與基線管理7.3.1基線建立與維護(hù)基線類型：范圍基線（WBS+范圍說明書）、進(jìn)度基線（甘特圖）、成本基線（預(yù)算表），基線變更需走正式審批流程?；婵刂疲菏褂门渲霉芾砉ぞ撸ㄈ鏢VN、Git）管理基線版本，變更前備份基線，保證可追溯性。7.3.2變更影響評估三重約束分析：評估變更對范圍、進(jìn)度、成本的影響，如“增加商品推薦功能：范圍擴(kuò)大+10%，進(jìn)度延期+2周，成本增加+8%”。干系人溝通：變更審批前向干系人（客戶、團(tuán)隊、管理層）通報影響，達(dá)成共識后再實施，避免后期爭議。第八章知識管理與經(jīng)驗沉淀8.1文檔體系建設(shè)8.1.1核心文檔分類過程文檔：項目章程、WBS、進(jìn)度計劃、風(fēng)險登記冊，用于項目規(guī)劃與監(jiān)控。成果文檔：需求規(guī)格說明書、設(shè)計文檔（架構(gòu)設(shè)計、數(shù)據(jù)庫設(shè)計）、測試報告、用戶手冊，用于交付與維護(hù)。知識文檔：技術(shù)總結(jié)（如“高并發(fā)場景下的緩存優(yōu)化方案”）、故障處理案例（如“2023年618活動服務(wù)器宕機(jī)事件復(fù)盤”）、最佳實踐（如“需求評審checklist”）。8.1.2文檔標(biāo)準(zhǔn)化模板模板規(guī)范：制定統(tǒng)一模板（如PRD模板包含背景、用戶故事、功