2024 年已進入年尾，許多企業開始進行年度績效考核。在上一篇「逐步打造高效開發團隊的經驗談」中，我提到績效考核是提升團隊效能的重要管理工具之一。這篇文章，我將分享對績效考核的看法。

◎績效考核的核心價值
我始終認為，績效考核的核心在於建立公司與員工之間正式的雙向溝通管道，透過考核對齊雙方的目標與期待。然而，實務中卻經常遇到考核流於形式，甚至淪為例行公事，無法真正發揮應有的價值。

舉實際例子某年考核期間，我剛好安排了兩週休假，理應由代理人處理考核文件，但人資部門仍將所有考核文件直接寄給我，並要求在五個工作日內完成。這些文件需要與員工進行面談並親簽，對於部門可能有 20 至 60 名員工的情況來說，根本不可能在期限內完成。這充分反映了發起考核的單位並未考慮執行層面的實際需求，僅是將其視為例行流程。結果各個配合單位也多半選擇敷衍了事快速交差。

這種情況反映出當考核執行的重心偏離其應有的雙向溝通價值，整體流程便容易失焦，進而失去真正的意義。績效考核應該是一個促進目標對齊、交流期望的機會，而非僅僅是打分數或填表完成的形式化任務。

◎導致績效考核淪為形式的幾個常見原因
在實務中，績效考核淪為形式化的情況並不少見，其原因通常來自以下幾個方面：

一、偏重量化數據
績效考核應該兼顧量化與質化，但許多考核文件與執行者過於側重分數評估，例如工作效率、品質、責任感等，往往忽略了質化區塊中像是「工作檢討」與「未來展望」的深度對話設計。這導致了考核過程變成一份簡單的評分表，而非真正的交流機制。

二、時間壓力與工作負載過重
考核時間多選在 6 月或 12 月，而這兩個時間點通常是企業工作量高峰期。人資部門及各單位在時間壓力下，往往僅完成必要的評分作業，無法充分投入面談與溝通。

三、缺乏對考核真正價值的認知
不少人將績效考核簡單視為調薪或發放獎金的工具，忽略了考核本身應該促進企業成長、工作檢討與效能提升的價值。這種認知差距使考核失去了更高層次的意義。

四、主管溝通技巧不足
並非所有主管都具備良好的溝通能力，有些主管甚至覺得與員工討論績效會尷尬而不自在，因此傾向快速完成評分來避免深入交流，導致考核僅流於形式。

五、缺乏後續行動計畫
即使完成考核，量化分數與質化內容如果未被真正利用，例如制定員工能力提升計畫或解決資源不足問題，最終考核結果也只會被束之高閣，失去應有的作用，企業內部也不會有人相信這個機制。

這些原因互相交織，使得績效考核淪為例行公事，無法有效促進員工與企業的共同成長。

=> 深入閱讀...

在我的職業生涯中，曾多次參與並主導資訊與研發團隊的組建和管理工作，這些經驗跨越不同的產業、公司規模和發展階段。第一次是在1998年，當時所在的公司希望擴大資訊部門，將原本僅有 MIS 的單一功能擴展成電子商務開發部門，這對於團隊的技術要求、組織架構以及目標定位都提出了新的挑戰。第二次是在2004年加入了一家照明設計公司，公司以銷售光源和照明設計為主，但引進了德國的照明設計軟體，因此需要組建資訊開發部門，負責內部及外部系統開發。第三次是在2007年，一家上市公司準備啟動 B2B Search Engine 新產品的開發，需要重組開發單位，當時我主導招募了一支跨部門的研發團隊，並帶領這個團隊在之後的兩家公司中共事了長達十年。最近一次是在一家無人智能旅店集團，我負責組建了集團的資訊研發團隊，主要負責開發和維護集團內部的軟體平台，並與這支團隊合作了八年七個月。

當我離開前公司，開始尋找新的職業發展機會時，面試中常被問到有關組建高效開發團隊的策略，尤其在當今少子化背景下，各行各業普遍面臨人才短缺的問題。這樣的情境下，如何建立團隊、並確保開發績效成為各家企業關注的重點。

◎招募合適的人才，建立堅實的團隊基礎
在建立高效能團隊的過程中，招募合適的人才是我們的首要步驟，也是團隊成功的基石。對於合適的人選，我們不僅注重其技術能力是否達標，更看重他們是否理解公司的發展路線，並認同這份工作作為職業生涯重要的一部分。人品和協作能力在我們的選才標準中往往比專業技能更為重要，因為良好的品格和溝通意願是推動團隊長期穩定與高效的核心。

為了找到這樣的人才，我們在選才上堅持高標準。如果一位候選人技術能力出眾但缺乏協作意願，我們會慎重考慮他跟團隊的適合性，因為這類成員往往在管理與溝通上耗費太多成本。我們追求的是技術與人品兼備的求職者，這樣的成員不僅能勝任工作，還能在團隊中積極促進合作與信任。就算是社會新鮮人如果有企圖心與積極的態度，也才值得公司培養。

此外，為了讓新成員更快融入團隊，我們努力營造良好的工作文化，這個文化以責任感、團隊精神、打造好產品為核心。部門主管在這方面要以身作則，同時鼓勵每位成員參與維護和調整文化，共同塑造出持久穩定的工作氛圍。我們的目標是讓團隊中大部分成員往共同的價值觀和習慣靠近（要求所有成員都有一樣理念是不實際的），並圍繞此共識來協同開發，為了個人職涯與公司目標的實現奠定基礎。

◎工作待遇與靈活的福利設計
在吸引並留住優秀人才方面，完善的待遇和靈活的福利設計是我們的重要策略。除了提供具有市場競爭力的基本待遇外，我們也根據員工需求設計出彈性的福利，以提升滿意度和歸屬感。針對資訊開發者的需求，我們增取多項靈活的福利，例如額外的特休假、彈性上下班時間，以及部分時間的遠端工作安排。除此之外也爭取了活動經費的補助，每個月部門同仁皆能聚餐、辦活動以及採購平時的零食。這些選項能在不大幅增加成本的情況下，讓優秀人才享有更有彈性的工作條件，也有更好的工作氛圍。

雖然我們提供了靈活的工作選擇，但對工作常規也有清晰的要求。員工的自律是確保工作高效的關鍵，而這種自律不僅仰賴個人要求，也需要與明確的工作規範和部門管理配合，以支持同事在彈性中保持一致的工作標準。我認為透過適度的規範和監督，不僅能幫助同仁在彈性中達成工作成果，也能提升整體團隊的效能。這樣的安排讓我們在兼顧靈活與紀律的同時，吸引並留住那些認同公司價值、願意長期發展的專業人才。

=> 深入閱讀...

在過去十八年中，我的職涯集中於網路平台的產品開發，涉及 B2B 和 B2C 的市場媒合、基於 AI 的預測分析等多樣化服務。本篇將分享我在網路平台產品的定價及銷售方案包裝中的一些實際經驗，幫助大家了解如何有效地制定具有市場競爭力的產品價格策略。

產品的定價策略不僅僅是為了覆蓋成本跟創造營收，更關鍵的是能持續支持平台的市場競爭力，並兼顧客戶的價值感知與產品接受度。針對不同的網路產品特性、目標客戶需求、及競爭環境，平台的定價與產品包裝可以採取多種模式，以下是我進行價格擬定、銷售方案的思維模式。當然我的本質是產品研發者，我會先以開發者的角度切入，將這些彙整的想法提供給產品或業務單位進行後續的包裝與定案。

◎確立市場定位與客群分析
分析目標市場與客戶需求： 產品的價格不僅反映成本與利潤，更需強化市場競爭力。首先，明確產品的目標客群（如小型企業、中大型企業或個人用戶），並分析他們的需求和價格敏感度。這不僅決定了定價區間，也影響到潛在市場規模。透過問卷調查、訪談等方式收集客戶偏好的價格區間，這些數據將成為定價與功能分層的基礎。

◎成本結構與定價影響
在市場定位與客群分析之後，定價策略的核心在於確保平台的價格結構能夠為企業帶來盈利。合理的定價不僅需覆蓋成本，還應達到盈虧平衡，為長期發展奠定基礎。清晰的成本結構有助於設計靈活的價格機制，既保障平台穩定收入，也提升市場競爭力。

網路平台產品的開發成本主要集中在系統基礎費用與人事支出，這些成本可分為前期開發成本及後續維運與持續開發成本。由於服務推出前的開發投入通常是少數客戶無法單獨負擔的，因此前期的客群分析至關重要。需要首先預估服務的潛在市場範圍，預計可推廣的客群數量，並根據最保守的市場情境及開發時限，對開發成本進行攤提。在此基礎上，加上後續維運成本，再結合市場價格接受度來計算潛在盈利空間，最終制定出合理的價格範圍。

◎商業模式比較與選擇
網路服務的商業模式，我簡單將其歸類於下列幾種：

•賣斷制：賣斷制即為一次性付費購買模式，適合應用於部分硬體或獨立軟體工具中。這也是早期軟體服務銷售採用的方式，但對於需要持續更新的網路平台產品，賣斷制並不理想。網路平台的產品多數需持續更新並保障運行穩定，這使得賣斷制在近年慢慢被租賃式給取代。若採用賣斷方式，企業後續的營收得仰賴維護費用以支持系統維運，但這往往會讓客戶增加成本壓力，並降低平台服務吸引力。

•廣告支持模式：這是許多免費網路平台採用的一種模式，特點是平台不跟使用者收費，而是通過吸引大量用戶流量，再將流量價值轉化為廣告收益，從而獲得盈利。這種模式平台本身需要經營流量，提升使用者黏著度，另外必須根據用戶的數據分析來投放廣告，越精準的受眾越能吸引廣告商的支持，並提升廣告效益與轉換率。不過這個商業模式已經有許多專利，若平台經營的越大，勢必會遇到專利方面的問題。

•租賃制：租賃制是泛指使用期間收費，這可能是單一服務也可能是客製模組化來收費，例如上架費可能是月租固定收費也有可能是單次使用收費。而在網路平台方面，可以透過分層的月租費用向客戶提供平台的持續性服務。這裡的分層包含單次性服務，或是依客群不同等級來收費，以旅宿產業為例，可能會以房間數量規模來區分旅店收費等級，而若以軟體用量來說，一般會以企業規模（員工人數或使用人數）來分級。這個的優勢在於平台能獲取穩定的月度收入，同時客戶無需一次性支付高額成本，適合需要長期服務支持的網路平台服務。目前像 GCP/AWS/Azure 就是屬於 IaaS 與 PaaS 的月租賃收費模式，它將收費方式切細，這類的租賃制對於客戶而言，成本較靈活，且隨著業務增長可逐步升級服務層級。

而租賃服務在收費方式有三種模式，一種是使用後計量計費，屬於先用後付方式，這個適合會產生變動成本的產品，例如網路流量、簡訊用量等。第二種是提供固定服務，採先繳費給予使用期限，屬於先付後用。第三種是預先儲值，當儲值金額不夠時需要再儲值才能使用服務（網路遊戲多採用這種）。不同的收費方式對平台開發商有不同程度的保障，但對客戶來說使用便利性會有差異，然後在產品計費的開發上也會有不同的難易度，主要還是針對客群模式來思考收費方法。

•收益分潤制：收益分潤制主要基於平台產品的價值與客戶營收直接掛鉤。這一模式的主要特色在於「零風險、雙贏收益」，即在客戶營收不足時分潤比例也相應降低，幫助客戶在淡旺季皆能靈活應對支出需求。平台與客戶共擔收益風險，是高度需求彈性的產品應用的理想模式。但分潤的多寡就會是很重要的一環，寡佔市場分潤的比例就會高，而量大的市場則可以將分潤降低。例如 Apple App Store 的分潤是 30%，送餐平台的分潤是 15%-30%之間，旅宿業 OTA 的分潤是 15%-25% 之間，汽車銷售新車與二手車的分潤是 5%-15%之間，房地產銷售分潤是 4%-7%之間，信用卡或金流服務分潤是 1%-3.5% 之間。

這些已知的商業分潤模式，可以作為訂定收益分潤的參考。例如，參考信用卡金流的服務費率，並根據目標市場的不同收益規模，設計合理的比例，確保分潤在客戶的營收範圍內具可接受性。而分潤機制在結算系統的設計上也有一些挑戰，採用這些商業模式時，盡可能簡化計算所需套用的邏輯，不要有太多客製化的比例，而這些定價與產品的銷售方式，也會影響到產品開發的工作。

◎定價策略的數據試算與調整
在確認網路平台要以哪些模式來推出時，也要進行收費結構的模擬跟試算。差異化的銷售策略能夠盡可能的包圍市場，但若是產品結構設計的太複雜，也不利於客戶的理解跟業務上的推動。一般我會先預估市場的份額，然後進行不同產品組合的銷售試算。基礎性的產品跟佔營收比例較高的產品項較為重要，額外因差異化策略而衍生的產品，則可以作為營收估算的輔助。

從營收預估這部份就可以跟成本進行比較，並分析可能帶來的利潤有多少。網路服務的一個特性在於它不受限於產品數量、地域、時間等限制，當然隨著服務的客戶數越多，會提高營運成本，且也有可能遇到系統設計上的瓶頸，但通常它沒有固定的營收天化版限制。這部份的後續推展與發酵就要看業務團隊以及自體銷售的能力了。

在營收預估部分若需要經由業務團隊來銷售，在進行試算時就應該跨單位進行溝通與市場份額討論。若是可藉由網路銷售，並且定位在國際化的市場，那就需要一併預估銷售推展的計畫跟支出。產品再好沒有讓客戶知道，也是推不出去的。反之，產品沒有到 90 分，但有好的銷售模式跟服務，也能帶來不錯的營收。我們內部常開玩笑，很少聽到客人非常滿意的產品，不論是 B 端或 C 端都是如此。只要能夠幫客戶賺錢達到他們使用這個服務的目的，那就是好的服務。

◎定價策略風險評估
風險策略是所有的作業項目都應該評估的重點之一。前面雖然提到網路平台產品沒有明顯的營收天花板，但許多服務會受限於市場份額本身。舉例一個進行 B2B 的商業貿易平台媒合服務，不同的產業分類也都會有服務限額。台灣的精密機械產業是全球知名，但平台幫推 20-30 間同質的製造商已經算是媒合成效的極限，超過這個數量整體感知的成效就會衰退。以 SEO 來說，單一關鍵字或關鍵字詞組，曝光度最高的是前十筆，而超過三十筆的排名成效就大幅衰退，所以這也是限制。以旅宿業來說，全台合法登記的旅宿不超過 4,000 間，要推出旅宿相關的租賃服務，那這就會是一個天花板。可若是改為分潤制，那天花板就會被抬升，甚至它的限制我們的營收根本觸及不到。

因此在產品制定的時候，應該跟隨市場的波動來制定需求變動的風險，進而調整分潤比例或租賃價格，以保持競爭力。除此之外也要注意成本風險，如果平台遭遇有力的競爭對手，或是技術需要大幅的更新，那需要將這部份的成本或是市場競爭力考量在內，調解產品銷售策略的比重，例如從租賃與分潤的比例找出平衡點，避免企業造成虧損。

◎強化客戶價值感知
本篇分享雖然是以產品定價模式為主，但在進行模式的制定時，也要連帶先佈局如何讓客戶願意買單。這些包含產品官方網站的設計、銷售通路的規劃、銷售話術的制定、客戶教育訓練與服務的規劃。這方面可以獨立一篇來分享，這裡可以先專注的區塊在於產品的「價值展示」與「信任建立」。

◎結論
網路平台產品的定價策略應該具備靈活性與適應性，租賃制、收益分潤制、及賣斷制各自適用不同的產品需求。針對市場需求波動較大的平台產品，收益分潤制具備高度的靈活性與風險共擔特點；而租賃制適合多數長期服務類平台，能帶來穩定收入並滿足不同層級客戶需求；賣斷制則適用於需要一次性購買、維護較少的產品。在選擇模式時，需根據產品特性、客戶需求及市場競爭力，設計最佳的定價策略，為平台的持續增長與盈利奠定穩固基礎。

在成功簽約並開始執行補助計畫後，企業通常每年需要通過兩次的計畫審查。本篇將分享在期中與結案審查時需要注意的事項及技巧。

在簽約前，有些計畫的意向調查書會詢問是否披露評審委員的資訊。建議選擇「披露」選項，以便了解委員的背景和專業領域，從而在準備時針對委員專業的重點進行充足準備。

◎瞭解審查委員的關注重點
計畫申請階段，委員主要評估計畫是否符合補助標準，以及其創新性和經濟效益。而在簽約後的執行期中和結案審查，重點則在於計畫是否依照原本的計畫書執行，且政府希望藉此帶動產業發展，因此委員會特別重視項目的商業潛力和後續擴展性。

◎委員溝通技巧
無論是前期審查還是後續執行期中的審查，能清楚辨識並稱呼每位委員的名字是一項基本禮儀。在未披露委員信息時，可使用代稱（如ABCD）稱呼；信息披露後，則以委員的姓氏稱呼，若有重複姓氏則可根據專業背景進行區分。這種對委員的尊重和熟悉，能表現出企業的專業準備態度，對審查過程有積極影響。

◎執行審查的準備工作
每位委員的背景不同，包含學界學者、產業專家、新創投資者、政府專家等，因此除了技術或商業模式的準備外，還應重視細節，特別是行政流程、開發紀錄、工時管控和合作驗收等容易忽略的地方。對於文件不齊或財務數據的偏差等低級失誤，建議在審查過程中直接承認並即刻改正。審查文件的準備需提前至少兩週提交，以讓委員有充分的時間審閱。如資料尚不完整，可提供一個初步版本，並在審查當日補充最新信息。

◎審查後的補正
每次審查後都可能收到委員的建議和文件補正要求。我們通常在一週內完成補充，無論是財務報告、專利送件紀錄還是模型數據，皆完整提交，並在委員後續評語中獲得正面反饋。每次審查時間有限，補正文件需具體清晰，並針對性地回應委員的疑問。同時提供的文件，像是簡報的紙本，也建議能包裝完整，這些細節都會表現出企業是否重視這個計畫案的執行細節。

◎成果驗收的挑戰
計畫書內的成果驗收標準需謹慎設立。傳統開發通常會隨市場或技術挑戰適度調整，但計畫書在簽約時已明確成果，因此不能輕易變更。例如若目標最初設定為服務 5,000 家企業並帶動 200 億年營收，總不能執行到一半隨意調整至 2,000 家或 50 億年營收。因此計畫變更並非所有內容都可以處理，而計畫變更項目也都需委員重新審核同意。這部分我們最常遇到的問題是技術細節的驗收標準設得過於嚴苛，導致無法達標。

◎容易混淆的審查時段
在進行期中審查時，需注意時程與實際開發進度之間的差異。例如，計畫上半年的審查會議可能在七月或八月進行，這可能涵蓋了七、八月才執行的項目（或跨越到七、八月的項目），這很容易引發委員誤會，委員有時會審查到下個階段的內容。因此，報告時需清楚說明範疇，避免委員對進度產生疑問。與同一組委員配合的次數越多，就越能提前預測提問方向，我們通常會在審查前一個月就開始準備所有文件，並進行至少六次的演練。

◎會議中的問答與配合
審查會議中的問答環節是重要的一關。若有多位委員詢問問題，建議可嘗試溝通由兩位委員問完後回答，這樣更有利於組員紀錄並做出全面的回應。有時單一位委員問題較多，也可以建議分段詢問，方便回答，這需要委員的同意。若無法分段，參與審查的同事需具備速記能力，我們在內部演練時會模擬分組速記和答復，確保即時反應。且不同專業項目的問題，也要演練由誰來主責回復，若回復不到位，又由誰來補充。

◎管理委員期望與支持
審查委員的職責是找出問題並確保計畫進行順利，因此我們需調整心態，不被批評影響表現。觀察每位委員的反應是關鍵，有時我們難以獲得所有委員的認同，但可透過表現爭取那些了解和支持我們的委員。這些委員的評價有時決定審查結果和評分高低。此外，與辦公室承辦的溝通也需保持順暢，雖然承辦無法決定計畫通過與否，但在某些場合可以補充背景說明，協助我們更好地表達項目。

對待每一個補助計畫的申請過程，都是秉持著積極準備、認真應對，並且做好各種溝通協調的細節，而從這些經驗中也可以從委員那邊接受到他們的回應跟理解。而要注意的是，委員接觸跟理解我們整個計畫案只有透過我們提供的文件、審查的會議，這些加總起來一個兩年的計畫，接觸到的時間可能都不到一天的工時，所以委員不了解是很正常的一件事，每一次的文件跟審查，都要重新構建委員對這個計畫的理解度，並了解我們執行的細節跟成果，這是面對審查時該有的認知。

◎總結
參與政府補助計畫的審查和執行是一項資源密集的任務，但對於資金不足或缺乏研發支持的企業而言，能有效地幫助推動企業發展。每個補助計畫的審查過程是重新建立委員對計畫理解的過程，因此精心準備每一項文件、充足的審查應對和持續的改進，都是成功的關鍵。以上是個人的一些經驗，提供給大家參考。

延伸閱讀：
政府研發補助計畫申請經驗談-上

政府研發補助計畫申請經驗談-中

成功通過補助計畫的審核後，接下來的步驟是與政府簽約，隨後進入計畫執行階段。不同補助案的執行要求有所差異，部分計畫允許企業在補助通過後才進行開發，而另一部分則是企業先完成開發後再申請經費補助。前者會涉及更多的查核與審查流程，尤其在兩年期以上的開發案中，通常每半年會有一次審查，並且技術審查和財務核銷是分開進行的。因此了解補助案的規範並嚴格遵守非常重要，以免因為疏忽而導致補助款的減扣。

◎簽約與計畫書的最終修訂
在簽約階段，企業需要提交最終版的計畫書，這份文件會進行開發時程、人員配置和經費使用細節的修訂。對於尚未開始執行的計畫，補助案通常要求企業不能提前開發，必須嚴格依照計畫書中的內容與時程推進。因此，如果已經有前期研究，這時候就需要微調計畫書的內容，並且明確記載開發項目、啟動時間和時程。計畫書的啟動日期可以獨立於簽約日期，但需要確保所有合約正本、擔保文件、第三方驗證機構的時程安排等文件齊備。同樣，企業內部的開發人員需要詳細列出各自的開發、測試與驗證時間，以及產品的預計上市時間。

◎經費構成的細節與應變
在執行計畫的過程中，開發經費的組成和分配需格外注意。例如，新冠疫情期間差旅費的需求因遠距工作模式的推行而大幅減少，原本計畫中的差旅費用無法支出，因此需要通過計畫變更，將這部分經費轉移到其他項目中。在設備費用方面，我們也遇到了預算設計上的挑戰。最初我們根據傳統伺服器的估價來設計預算，然而在實際執行中發現，雲端服務商的費用結構較為複雜，與預期不同。審查的會計師根據規範進行財務審查，並不允許與計畫書不同的支出。透過提交詳細的帳單明細和租賃計畫，我們最終經由審查委員的同意才得以核銷，但仍需進行計畫變更，這提醒我們在制定經費預算時需充分考慮靈活性。

◎開發紀錄與工時管理
在企業內部進行開發時，保存完整的開發紀錄是重中之重。我主要開發的是雲端軟體平台，所有開發進度均已電子化處理，包括使用 GitLab 進行代碼審查與部署自動化，而工作分配、註記、時程管理等都是透過 Remind 來作業。儘管如此，補助計畫要求的是紙本的研發記錄簿，每位開發人員都需要簽名確認。這方面可以選擇兩種方式：其一，直接制定紙本格式，要求開發人員每週定期記錄並簽名；其二，將電子紀錄轉為紙本，經過審查委員同意後使用，但開發者一樣要簽名。開發記錄簿不僅是審查的必要材料，也是確保知識產權時的重要佐證。

計畫案的規模有大小之分，我經手過的計畫最少成員有 20 位，最多的有達 40位，我們的經驗是分不同組別來進行管理，包含研發記錄簿、會議記錄，但每個人的工時都要詳細的作業，因工作者的出缺勤會因出差或私人因素有所不同，詳細的工時一定要記載，這也是審核很注重的項目之一。有時候計畫案是跨多個部門一起完成，在簽約之前就需要整合所有的小組成員，告知大家執行的注意項目，確保每個人都可以留下相關紀錄，方便之後的審查作業。這些勢必會帶來額外的工作量並降低開發的效能，因此前面有提到補助金額的高低，是企業評估是否要爭取政府金額補助的考量點。

◎敏捷開發與計畫書的適應性
敏捷開發與計畫書的「瀑布流」要求是否相衝突？實際上，敏捷開發雖強調靈活應變，但也是在固定框架內的靈活。除非遇到重大產品變動，一般變更都可通過計畫變更申請來調整。因此，在每個階段的查核中，我們只需向審查委員解釋清楚，準備好應變資料即可。

◎委外與合作模式的執行
如果計畫中包含產學或企業合作，特別是涉及技術開發的項目，應預先確定合作模式並明確規範。若合作廠商無法按照我方的開發方式進行，則可以通過技術轉移和成果交付來保存相關文件。例如我在某次合作中委外了一部分複雜的演算法設計，因未事先確認系統環境，導致後期功能整合困難，為此我們耗費大量資源重構。此類項目一定要在開發前協調清楚，避免後續的時間與成本增加。

◎第三方驗證與審查報告
第三方驗證單位的主要作用是根據計畫書的規範進行項目查核。以軟體平台服務開發為例，每當一個大項目完成時，我們便會請第三方驗證單位先行測試。建議在準備驗證時，確保第三方驗證機構的測試環境和我方一致，避免測試過程中因環境差異產生誤差。審查委員對此方面有較高要求，有時甚至要求驗證機構派員列席，直接面對質詢並解釋驗證細節，因此必須準備充分，以確保驗證報告的合格性。

◎審查委員的建議與企業營運的平衡
計畫執行過程的多次審核中，審查委員會提出的建議可能會增加開發時間，有時甚至可能影響公司的產品定位。對於補助計畫的部分項目，企業若因市場機密或未公開的策略難以回應，可以委婉地向委員說明限制，避免因透露商業機密而影響公司的其他計畫。例如，有次委員建議我們考慮加入某些功能，但我們有已有計劃直接併購某家廠商的產品而不用自行開發，但受限於保密協定，無法提供具體答復，只能將情況委婉的說明。

◎專利的取得與目標設置
若計畫包含專利申請，需注意補助項目中的專利目標設置。專利審核週期長，發明專利的審查期可能需一年到三年，因此在計畫書中應對專利目標措辭謹慎。政府的專利補助經費也有特定限制，申請時應了解清楚，避免後期因達不到專利申請要求而影響補助款的核銷。

以上是補助計畫在執行過程中的注意事項，重點在於文件紀錄的詳細、變更申請的及時以及與合作單位、審查委員的有效溝通。下一篇將分享在各階段審查和結案審查中的實際經驗，讓整個計畫案順利完成。

延伸閱讀：
政府研發補助計畫申請經驗談-上

政府研發補助計畫申請經驗談-下