核心行動建議 - 幫助快速鎖定適合的App公司，降低溝通與執行風險
- 列出至少3家有實績的App公司並比較過去12個月內交付時程。
可預先排除專案拖延高風險對象，掌握進度主動權。
- 檢查每階段交付物明細及負責窗口，並要求書面確認。
減少需求誤解，提高專案透明度與溝通效率。
- 預留總預算10%以上作為變更緩衝金，簽約前就議定追加規則。
能應對中途需求調整，不因小變動陷入資金糾紛。
- 將專案拆分至少3個里程碑，每階段驗收7天內完成回饋。
*分批驗收*快速發現問題，也方便雙方即時修正方向。
App專案一拖再拖？先懂時間成本怎麼藏的
根據那個行動應用分析平台——嗯，App Annie吧，他們最近發的產業趨勢報告…我有點忘記他們是不是每年都會出，但總之，今年全球行動軟體服務市場產值，已經跑到歷史新高了。這件事說起來有點誇張，不過好像也不奇怪，畢竟大家手機都快黏在手上了。有時候想一想，中型規模的數位產品專案，其實從需求確認、設計，一路到最後真的擺上Google Play或App Store（啊對，我一直搞混Apple和Android的審查流程），整個開發流程普遍至少半年，有時甚至拖得接近一年。唉，好累人。
而且這種長時間耗費，不只是跨國大公司要煩，本地的新創團隊也是壓力山大，尤其是時間成本壓下來，每次聽到誰又delay我就心裡咯噔一下。欸，差點扯遠了；Gartner前陣子調查顯示，大約有將近一半IT類專案經常遇上進度延遲或預算超支，那數字看到還真讓人冒冷汗。
所以呢，在專案藍圖最前期，你如果只盯著功能清單和財務表格猛看，其實風險很高啦。不如多留點神去思考彈性的資源配置跟萬一事情變調怎麼辦，也就是說，要給自己設個風險緩衝帶。畢竟世界變化太快，有時昨天還沒問題，今天就爆雷了——這話可能老生常談，但我現在寫著寫著又覺得，不提也怪怪的。
而且這種長時間耗費，不只是跨國大公司要煩，本地的新創團隊也是壓力山大，尤其是時間成本壓下來，每次聽到誰又delay我就心裡咯噔一下。欸，差點扯遠了；Gartner前陣子調查顯示，大約有將近一半IT類專案經常遇上進度延遲或預算超支，那數字看到還真讓人冒冷汗。
所以呢，在專案藍圖最前期，你如果只盯著功能清單和財務表格猛看，其實風險很高啦。不如多留點神去思考彈性的資源配置跟萬一事情變調怎麼辦，也就是說，要給自己設個風險緩衝帶。畢竟世界變化太快，有時昨天還沒問題，今天就爆雷了——這話可能老生常談，但我現在寫著寫著又覺得，不提也怪怪的。
引用來源：
- Mobile Application Market Size, Share & Growth Report 2030
Pub.: 2023-01-01 | Upd.: 2025-06-16 - Mobile App Download Statistics & Usage Statistics in 2025
Pub.: 2025-04-15 | Upd.: 2025-06-16 - App Revenue Statistics 2025: Booming Mobile App Economy
Pub.: 2025-05-13 | Upd.: 2025-05-13 - How Big Is The Mobile App Market?
Pub.: 2025-01-05 | Upd.: 2025-01-15 - App - Worldwide | Statista Market Forecast
Pub.: 2024-11-28 | Upd.: 2025-03-11
明細交付物、階段成果，溝通其實沒那麼簡單
「交付成果明細沒寫清楚，後續衝突機率會提高。」這句話啊，我已經聽過不知道多少次了。大多是那些在業界混很久的專案經理掛在嘴邊，不過也不是沒有道理，畢竟現實裡，需求確認完，你以為有一紙合約就可以萬事無憂？唉，哪有那麼簡單。
其實常常，一開始合作的時候，就應該主動找App公司討論——像每個階段到底要交什麼、驗收要怎樣才算數、還有里程碑設計之類的東西。如果只是傻傻列個首頁UI稿，其實遠遠不夠。嗯……等一下，好像差點忘記重點，拉回來說，就是連互動邏輯跟資料串接方式都得講清楚啊。不然，到時候真的出問題，只能怪自己沒先想到。
你看，如果只用一些模糊描述去取代每個階段檢核，那種狀態其實挺危險，很容易雙方認知不一致，結果拖延時間或者乾脆返工重來。好吧，有時候我也懶得細想，但老是發生同樣的坑，其實蠻煩人的。
反而把專案切割成幾個可驗證的小步驟，每完成一步就能早點發現問題——雖然偶爾會卡關，可至少方向錯了能及時微調，也比較安心一點啦。總之，大概就是這樣，每次遇到新案子，都還是忍不住碎念一次。
其實常常，一開始合作的時候，就應該主動找App公司討論——像每個階段到底要交什麼、驗收要怎樣才算數、還有里程碑設計之類的東西。如果只是傻傻列個首頁UI稿，其實遠遠不夠。嗯……等一下，好像差點忘記重點，拉回來說，就是連互動邏輯跟資料串接方式都得講清楚啊。不然，到時候真的出問題，只能怪自己沒先想到。
你看，如果只用一些模糊描述去取代每個階段檢核，那種狀態其實挺危險，很容易雙方認知不一致，結果拖延時間或者乾脆返工重來。好吧，有時候我也懶得細想，但老是發生同樣的坑，其實蠻煩人的。
反而把專案切割成幾個可驗證的小步驟，每完成一步就能早點發現問題——雖然偶爾會卡關，可至少方向錯了能及時微調，也比較安心一點啦。總之，大概就是這樣，每次遇到新案子，都還是忍不住碎念一次。
Comparison Table:
| 結論 | 建議 |
|---|---|
| 後台資料移轉規格應納入正式文件 | 在專案初期要求外包方提供完整技術文件，明確數據主權和匯出範本。 |
| 長期觀察是評估App效益的關鍵 | 不僅依賴短期數據，還需結合中長期監控工具進行綜合分析。 |
| 自建團隊與全委外的選擇要謹慎 | 根據公司現有資源和需求來決定，避免單純追求成本低廉。 |
| 跨部門協作必須強化溝通 | 加強各部門間的合作與資訊共享，以減少潛在風險。 |
| 流程拆解以提高專案管理效率 | 將專案細分為多個里程碑並設置可交付成果，及時驗收進度。 |
需求變動亂流來襲，跨部門協作早點談更好
「需求持續變動」這回事，老實說，在App開發現場大概已經變成日常了吧。唉，有時候想想也覺得荒謬，你計劃排得再怎麼細密——前期流程表啊、會議紀錄什麼的都弄好了，結果市場壓力還是來敲門，用戶反饋也一波接一波，突然就把原本規劃好的功能或整個產品路線攪亂，逼著大家臨時調整。事情往往就這樣失控了。嗯，我上次還遇過類似狀況，不過這裡不是重點，拉回來。
當然啦，進度表看起來很美好，但現實就是容易被打斷無數次，有時還得重工。有些人可能會問：「那企業內部協作夠不夠緊密？」說實在，如果沒有統一的協作標準，每個部門責任邊界模糊，那溝通延遲根本避不掉。有時候資源分配東缺西漏，更慘的是彼此開始推卸責任，好像誰都沒錯但事情卻卡住了。
舉個例子吧，就像設計端信誓旦旦地說介面優化已交付，可後端團隊卻愣在那裡：「欸？資料沒給齊我要怎麼對接？」然後上線時間就只好一拖再拖。欸，其實我有點想吐槽一下，不過先不談我的情緒。
針對這些讓人頭痛的問題，有些企業選擇設立專責跨部門討論例會；另外有人則乾脆用雲端協作工具，把所有需求和驗收標準一條條記下來，希望藉此能提前揪出潛藏風險。話說回來，不知道這種做法是不是萬靈丹，大概只能試了才知道吧。
當然啦，進度表看起來很美好，但現實就是容易被打斷無數次，有時還得重工。有些人可能會問：「那企業內部協作夠不夠緊密？」說實在，如果沒有統一的協作標準，每個部門責任邊界模糊，那溝通延遲根本避不掉。有時候資源分配東缺西漏，更慘的是彼此開始推卸責任，好像誰都沒錯但事情卻卡住了。
舉個例子吧，就像設計端信誓旦旦地說介面優化已交付，可後端團隊卻愣在那裡：「欸？資料沒給齊我要怎麼對接？」然後上線時間就只好一拖再拖。欸，其實我有點想吐槽一下，不過先不談我的情緒。
針對這些讓人頭痛的問題，有些企業選擇設立專責跨部門討論例會；另外有人則乾脆用雲端協作工具，把所有需求和驗收標準一條條記下來，希望藉此能提前揪出潛藏風險。話說回來，不知道這種做法是不是萬靈丹，大概只能試了才知道吧。
專案驗收別一次押寶，拆分里程碑自保也省心
「驗收分段，不要最後才一次對帳。」這句話其實是我在某次部門聚餐的時候，老前輩突然冒出來的。唉，其實當時他講得有點快，我一度沒聽懂——還以為又是哪種無聊流程規定。說穿了，就是你把專案硬生生切成幾個小節點，等於每走到一站就被逼著交出成果來——不管你手裡拿的是原型、半成品、還是那種介面切版，有就得攤給大家看。
但你知道嗎？有些同事會嫌這做法太像拆帳單了，很麻煩欸！我自己有時也覺得，唉，真想直接全部丟到最後再一起算。但如果回頭看看，大多數那些卡死在加班泥沼裡的案子，好像都忘記了這種笨方法。啊，我又扯遠了，總之該怎麼說呢——就是這東西雖然無聊，但還真的能救命。
再說實務上啦，有接觸過跨國合作的朋友大概都會提早把後台權限或資料結構格式細項塞進合約裡。理由齁，很簡單：沒人想最後一天才發現資料規格根本兜不起來，那感覺超級糟。有時候我甚至懷疑，是不是每個人都偷偷做過這種傻事才學乖的？嗯，我也不確定，但八成是吧。
然後啊，那份私下自己整理的小小驗收清單，看起來好像多此一舉，可其實不少人會跟你說它比書面合約靈活太多，只是這東西得靠經驗慢慢磨——哪有人天生就會做得很完美？算了，又講廢話。不過老實講，每次想到這些事，我心裡都七上八下，到底要不要再加一條檢查項目呢…
但你知道嗎？有些同事會嫌這做法太像拆帳單了，很麻煩欸！我自己有時也覺得，唉，真想直接全部丟到最後再一起算。但如果回頭看看，大多數那些卡死在加班泥沼裡的案子，好像都忘記了這種笨方法。啊，我又扯遠了，總之該怎麼說呢——就是這東西雖然無聊，但還真的能救命。
再說實務上啦，有接觸過跨國合作的朋友大概都會提早把後台權限或資料結構格式細項塞進合約裡。理由齁，很簡單：沒人想最後一天才發現資料規格根本兜不起來，那感覺超級糟。有時候我甚至懷疑，是不是每個人都偷偷做過這種傻事才學乖的？嗯，我也不確定，但八成是吧。
然後啊，那份私下自己整理的小小驗收清單，看起來好像多此一舉，可其實不少人會跟你說它比書面合約靈活太多，只是這東西得靠經驗慢慢磨——哪有人天生就會做得很完美？算了，又講廢話。不過老實講，每次想到這些事，我心裡都七上八下，到底要不要再加一條檢查項目呢…
合約簽了但Bug還在？關鍵節點與時限你寫對了嗎
那時候唉，客戶一副信心滿滿的樣子說什麼交付時程沒問題啊，還拍胸脯保證得很大聲。合約裡也真的寫了——嗯，雖然條文明確，但偏偏就沒仔細列出每個階段要怎麼驗收、處理期限到底是哪一天。講白了就是規範空了一截，欸，我有點想知道當初誰先提議這種方案？算了，不重要。
專案才剛上線，不到一週吧，前端忽然快一半的欄位都亂掉不能填；後台數據整批格式也全對不上，那畫面真是慘烈。不過咧，廠商只會一直推說「這個下版優化再修」、或者乾脆把修補周期給無限拉長，你追他他就閃。其實我還在想，是不是大家都有點習慣混水摸魚？但負責人又急瘋，每天催雙方技術加班救火，可惜沒有明訂規範，到底誰該扛、什麼時候改善完，全都模糊成一團。
講起來，其實市面上大型專案遇到這類事情根本不稀奇啦，大概大多都是簽合約只管交付主流程內容，但bug修復或升級範圍完全沒定義，一出事各自用自己的話解釋──然後爭來吵去，好煩──最終只能砸掉數十倍時間資源回頭補破網。我還記得有些同業吃過大虧後開始學聰明，在重要節點硬性約定每項細緻時限，同步設立違約處理機制，也算是被現實打醒磨出來的一種生存小撇步吧。
專案才剛上線，不到一週吧，前端忽然快一半的欄位都亂掉不能填；後台數據整批格式也全對不上，那畫面真是慘烈。不過咧，廠商只會一直推說「這個下版優化再修」、或者乾脆把修補周期給無限拉長，你追他他就閃。其實我還在想，是不是大家都有點習慣混水摸魚？但負責人又急瘋，每天催雙方技術加班救火，可惜沒有明訂規範，到底誰該扛、什麼時候改善完，全都模糊成一團。
講起來，其實市面上大型專案遇到這類事情根本不稀奇啦，大概大多都是簽合約只管交付主流程內容，但bug修復或升級範圍完全沒定義，一出事各自用自己的話解釋──然後爭來吵去，好煩──最終只能砸掉數十倍時間資源回頭補破網。我還記得有些同業吃過大虧後開始學聰明，在重要節點硬性約定每項細緻時限，同步設立違約處理機制，也算是被現實打醒磨出來的一種生存小撇步吧。
資料主權不講清楚，小心日後搬家重來一遍
唉，講到專案裡最常見的那些漏洞，真的是有點煩。像，有一個狀況老是發生，就是大家拼命在那邊討論什麼功能細節、畫面長怎樣啊流程要多順暢之類的，但「後台資料移轉規格」這玩意兒，竟然常常就沒人認真把它寫進正式文件裡，實在匪夷所思。嗯…也許大家都只想著好看吧。其實前端畫面流程那種東西，每個細節都爭得臉紅脖子粗，可等談到資料庫結構、欄位名稱、或各式各樣格式定義時，不知道為什麼現場就突然安靜。不曉得該說是懶惰還是無奈。
欸，我記得有些外包團隊還更誇張，他們最後只給你一份自家系統格式的匯出檔案——別說考慮以後要換廠商，就是連擴充功能有新需求時，也根本不知道怎麼接手。講到這裡，其實我前幾天才遇過，有個負責人當初完全沒注意這些，一搬資料才發現缺東缺西，比如關鍵欄位說明或者對應表格全都不清楚，只能眼睜睜看著團隊花差不多一半時間去慢慢重新比對整份設計文件，那種痛苦真的很難形容（我自己都懶得想像）。
其實講白了，與其後悔補救，不如一開始合作時就直接要求外包方交出完整技術文件，然後用比較明確的條款約定好數據主權和標準匯出範本。啊，我剛剛是不是離題了？拉回來啦。我覺得這樣做雖然麻煩，但至少日後要換供應商或自己獨立維運，都不用再每天焦頭爛額地處理重工風險，也才能真正把資訊資產握在手心裡…大概就是這樣吧。
欸，我記得有些外包團隊還更誇張，他們最後只給你一份自家系統格式的匯出檔案——別說考慮以後要換廠商，就是連擴充功能有新需求時，也根本不知道怎麼接手。講到這裡，其實我前幾天才遇過，有個負責人當初完全沒注意這些，一搬資料才發現缺東缺西，比如關鍵欄位說明或者對應表格全都不清楚，只能眼睜睜看著團隊花差不多一半時間去慢慢重新比對整份設計文件，那種痛苦真的很難形容（我自己都懶得想像）。
其實講白了，與其後悔補救，不如一開始合作時就直接要求外包方交出完整技術文件，然後用比較明確的條款約定好數據主權和標準匯出範本。啊，我剛剛是不是離題了？拉回來啦。我覺得這樣做雖然麻煩，但至少日後要換供應商或自己獨立維運，都不用再每天焦頭爛額地處理重工風險，也才能真正把資訊資產握在手心裡…大概就是這樣吧。
短線數據亮眼也別急著樂觀，長期追蹤才見真章
新創團隊在初期嘛，總是人少錢少，資源也說不上充裕，有時候連開會都嫌人不夠——這樣講好像有點誇張，可是真的大多數團隊遇到的第一個卡關就是這種困境。App產品一旦推出，你說要不要趕快收到用戶回饋？嗯，是很急啊，每天都有人問「怎麼優化？」但其實關鍵還是能不能即時調整策略吧。有趣的是，台灣近幾年行動應用其實蠻紅火的，到處都是新產品，可是現場工作觀察下來，欸，有些公司評估成效的方式讓人忍不住皺眉頭，他們很愛採取那種短時間、規模又小的測試——比如只找七十幾個真實用戶跑兩週日活躍率和錯誤回報率。唉，有時覺得是不是太偷懶了？啊，但好像又有點道理。
當然啦，用這種做法至少可以看見最初吸引力和技術穩定性，好歹不是毫無根據地亂猜。不過喔，要真的判斷一個App到底成熟了沒、可靠度夠不夠，大部分業界習慣還是會把觀察時間拉長至大約三十天，再加上自動化監控工具協助捕捉那些肉眼看不到的小異常。我自己內部測試的經驗，坦白講，只靠表面的指標就想瞭解全貌，真的太單純了點——你得配合後端質量監控、分群分析，還有做長期資料對照，那些潛藏問題才會慢慢浮現出來啊。嗯，不過我剛剛想到什麼？哦對，我前陣子居然夢到在數據中心迷路……呃抱歉又岔題了。
總之，把各種資料來源混搭起來，用中長線追蹤，不只是方便決策變得更全面，也能讓開發團隊真正摸清楚哪些細節才影響了產品穩定性。感覺比盲目樂觀好太多，大概只能說「世界本複雜」吧。
當然啦，用這種做法至少可以看見最初吸引力和技術穩定性，好歹不是毫無根據地亂猜。不過喔，要真的判斷一個App到底成熟了沒、可靠度夠不夠，大部分業界習慣還是會把觀察時間拉長至大約三十天，再加上自動化監控工具協助捕捉那些肉眼看不到的小異常。我自己內部測試的經驗，坦白講，只靠表面的指標就想瞭解全貌，真的太單純了點——你得配合後端質量監控、分群分析，還有做長期資料對照，那些潛藏問題才會慢慢浮現出來啊。嗯，不過我剛剛想到什麼？哦對，我前陣子居然夢到在數據中心迷路……呃抱歉又岔題了。
總之，把各種資料來源混搭起來，用中長線追蹤，不只是方便決策變得更全面，也能讓開發團隊真正摸清楚哪些細節才影響了產品穩定性。感覺比盲目樂觀好太多，大概只能說「世界本複雜」吧。
SaaS低抽成vs.品牌全包，不同規模選擇大不同
欸，你知道嗎，資策會最近的產業報告裡頭，也有提到這事——大品牌好像都傾向找那種一條龍全包式服務。嗯，這其實也不稀奇啦，幾乎到處都能碰到。不過，你要真說小團隊就只能選那種低抽成甚至零抽成的SaaS？唉，好像也沒必要下這麼死的結論。其實我有點猶豫，每次聽人討論這個，都覺得答案很曖昧。
拿91APP來舉例好了，它獲得將近一半中大型組織青睞，但EasyStore那類型的平台在新創圈卻混得還蠻開的。對了，我剛剛差點忘了講重點（欸、回來），你如果以為只是價錢差異，其實還有很多細節。有些人超在意API彈性，有些則比較怕之後遇到技術支援斷層——我真的看過，有公司貪便宜結果客服慢半拍，最後還是自己多花時間去找工程師協助。
所以啊，比起被價格吸引，不如先盤點一下現有技術人手跟維運預算，再決定要挑什麼方案。嗯……台灣App產業生態本來就很分歧，每家公司需求、風險耐受度落差也大，你只盯著成本不放，到頭來反而容易忽略穩定度和長期支援才是關鍵。好吧，我唸叨完了，其實自己偶爾也陷入同樣迷思，只能說現實就是沒那麼簡單啦。
拿91APP來舉例好了，它獲得將近一半中大型組織青睞，但EasyStore那類型的平台在新創圈卻混得還蠻開的。對了，我剛剛差點忘了講重點（欸、回來），你如果以為只是價錢差異，其實還有很多細節。有些人超在意API彈性，有些則比較怕之後遇到技術支援斷層——我真的看過，有公司貪便宜結果客服慢半拍，最後還是自己多花時間去找工程師協助。
所以啊，比起被價格吸引，不如先盤點一下現有技術人手跟維運預算，再決定要挑什麼方案。嗯……台灣App產業生態本來就很分歧，每家公司需求、風險耐受度落差也大，你只盯著成本不放，到頭來反而容易忽略穩定度和長期支援才是關鍵。好吧，我唸叨完了，其實自己偶爾也陷入同樣迷思，只能說現實就是沒那麼簡單啦。
委外、自建都難全贏，人才技術盤點不能少
「自建團隊一定比較省」這種話，還有什麼「全包委外一勞永逸」的傳言，在市面上真的常常聽到。可是，我怎麼覺得大家都忘了執行細節超煩人？嗯，有時候想想，理論很美好啦，但現實裡根本不可能那麼順。舉例好了——台灣近幾年那些新創公司，如果半年內就得產品上架，可偏偏手邊技術人才又稀缺，結果怎樣？自建確實掌控度會高很多，可惜招募加訓練拖著拖著專案進度被拉長，甚至你光維運初期開銷就能衝到十倍二十倍，真的嚇人。
然後說到全委外，好像聽起來很輕鬆對吧？但，一旦全交給外部團隊是沒錯啦，他們速度衝得飛快，不過…冷不防你會發現知識慢慢斷層，一塊一塊拼不起來。尤其遇到需求微調、原廠突然撤回支援這類事情（老天爺總愛挑壞的時候來搞事），技術傳承跟維護難度一下子暴增——唉我之前差點就在這個坑摔倒。
欸，不過專家們倒是一直在碎念叫大家別只靠直覺去賭哪條路最省力。他們說，其實下決策前應該先看清楚組織自己到底有人才優勢嗎、技術積累夠不夠深、還有預算彈性容不容易卡住。啊，有時偷懶直接選好像也沒什麼，但當複雜情況真的發生，你準備不足就只能自己吞後果，那些額外風險，唉…大概就是這樣吧。有些事，就是避不了啦。
然後說到全委外，好像聽起來很輕鬆對吧？但，一旦全交給外部團隊是沒錯啦，他們速度衝得飛快，不過…冷不防你會發現知識慢慢斷層，一塊一塊拼不起來。尤其遇到需求微調、原廠突然撤回支援這類事情（老天爺總愛挑壞的時候來搞事），技術傳承跟維護難度一下子暴增——唉我之前差點就在這個坑摔倒。
欸，不過專家們倒是一直在碎念叫大家別只靠直覺去賭哪條路最省力。他們說，其實下決策前應該先看清楚組織自己到底有人才優勢嗎、技術積累夠不夠深、還有預算彈性容不容易卡住。啊，有時偷懶直接選好像也沒什麼，但當複雜情況真的發生，你準備不足就只能自己吞後果，那些額外風險，唉…大概就是這樣吧。有些事，就是避不了啦。
全生命周期管理上場，用戶停留比KPI漂亮還重要
其實，很多人一提到App開發就直接想著那些炫砲的功能，可是有經驗的專案管理者——嗯，這裡不是在拍馬屁啦，他們真的建議先把流程拆成一堆很明確的小步驟。老實講，這一開始還真有點煩，但不得不說，建立那個涵蓋需求確認、技術文件留底以及維運轉移規格的初期規劃藍圖，就像畫地自限一樣，又安全、又麻煩。然後，有時候我會突然開始想午餐要吃什麼……唉，不對、拉回來！反正下一步，就是把整個專案進度粗暴地斬成數個里程碑，每個階段都得硬性設定一些可交付成果，而且要即時驗收，也不能拖。
你以為這樣就結束了嗎？沒那麼簡單啦。針對那些超級麻煩的後台資料權限還有資料格式轉移細節，在合約初期根本就要講清楚，不然到時候一定吵架。不知道別人怎麼看，我自己遇過幾次沒寫清楚就雞飛狗跳……好吧，再扯遠了。我還沒說完呢，反正評估產品效益的時候，大部分人都只看短線數據，其實應該結合中長期觀察跟一些質量監控工具才行，用短線樣本來下決策真的太草率。
最後啦，也不是推卸責任，只是真的得依照公司現有的人力或技術資源狀況來選擇自建還是委外，不可能每間公司都適合同一套。此外，跨部門協作溝通不能鬆懈喔，要一直強化才比較能減低潛在風險。有時大家嘴上說配合、心裡卻打算放空……嗯，我是不是又岔題了？總之就是這些眉角，小事搞不好變大事，你信不信？
你以為這樣就結束了嗎？沒那麼簡單啦。針對那些超級麻煩的後台資料權限還有資料格式轉移細節，在合約初期根本就要講清楚，不然到時候一定吵架。不知道別人怎麼看，我自己遇過幾次沒寫清楚就雞飛狗跳……好吧，再扯遠了。我還沒說完呢，反正評估產品效益的時候，大部分人都只看短線數據，其實應該結合中長期觀察跟一些質量監控工具才行，用短線樣本來下決策真的太草率。
最後啦，也不是推卸責任，只是真的得依照公司現有的人力或技術資源狀況來選擇自建還是委外，不可能每間公司都適合同一套。此外，跨部門協作溝通不能鬆懈喔，要一直強化才比較能減低潛在風險。有時大家嘴上說配合、心裡卻打算放空……嗯，我是不是又岔題了？總之就是這些眉角，小事搞不好變大事，你信不信？
