作為香港的軟體開發商，我們最常被客戶問到的就是：「你和其他開發商有什麼不一樣？」當我們分享了公司的方針和工作流程後，客戶便可以比較不同開發商的特點，從而在眾多開發商中選出最適合自己的代理。
為了幫助客戶在需要外包時挑選出最適合他們的 app 開發商，以下我們會提供 5 個快問快答，讓企業家和產品經理可以快速比較不同的開發商（尤其適用於沒有自己的開發團隊、第一次與外包公司進行面談的客戶）。
你們的原始碼 (Source Code) 經 Unit Test 測試過嗎？如果有的話，你們保證的覆蓋程度是多少？
為什麼這樣問：優秀的開發團隊應該有 unit test 標準作業流程。提問的時候，強調你明白這可能是需要付出額外成本的項目，避免開發商誤以為你有意「壓榨」他們或看輕他們的編碼品質。Unit test 是保證編碼品質的有效方法。以 Oursky 為例，我們在後台都會實踐 Unit Test 和針對 API 的自動化整合測試。
好的答案：
「是的，編碼覆蓋率約為 50% 至 80%。」
請留意，「編碼覆蓋率」是沒有絕對的，會視乎實際情況而變動。一般來說，通常不會低於 50%，而多於 80% 則可能意味著這些測試未必真的有用（譬如以奇怪的方式去測試編碼）。
壞的答案：
「是的，幾乎能覆蓋 100% 的編碼（或 99%）。」
這明顯在吹噓或只是在浪費時間。能擁有百分百的覆蓋率，很大機會只是因為這些測試並不考慮實際用途，而是志在覆蓋所有編碼的方式來進行。
「是的，我們會交由另一組團隊手動進行測試。」
這樣回答的人很可能並不熟悉 unit test，因為 unit test 都是自動化的。
你的開發團隊有例行的 Code Review 嗎？可以分享如何進行嗎？
為什麼這樣問：一個優秀的開發團隊應該定期檢閱自己的編碼。要一次 review 數百行的編碼是很困難的事情，而如果一個團隊有例行 code review 的話，他們的開發工程師就應該有提交短而且清楚的程式碼（譬如 1 到 200 行）給另一位工程師 review 的習慣。這樣的過程稱為提交「pull request」。
好的答案：
「會的，針對每個 pull request，我們都會安排另一位工程師負責 code review。」
舉例說，負責專案的開發工程師應該會使用清楚的 commit comment 來提交 pull request。
如果外包商無法負擔審閱每個 pull request 的成本，答案則可能是：
「是的，針對比較重要的原始碼，會由另一位工程師來進行。」
壞的答案：
「會的，我們會每週 / 每月 / 在專案結束時進行。」
這很可能也是唬爛。雖然劃分時間週期來進行 code review 聽起來很合理，但對程式開發來說卻不是這麼一回事。除非是針對安全性的稽查、知識分享或內部訓練而做的 code review，不然單次審視大量的 code 並不是好的做法。比較理想的做法是在合併編碼前進行 code review，方便在發現問題時能迅速修正。累積了一個星期的編碼才進行回顧，不僅會因為量大而不利進行 review，也難以及早在開發過程中找出問題來修正。
你的設計團隊會閱讀並遵從 iOS 人性化介面指南（Human Interface Guidelines）和 Android Material Design 指南（Material Design Guidelines）嗎？
為什麼這樣問：Mobile app 的設計方式跟平面設計或一般的視覺設計很不一樣，這樣提問能判別設計師是否對移動裝置的 UX / UI 設計具備基本的理解。Apple 和 Google 都會分別定期更新為 iOS 和 Android 制訂的設計指南。
這是一個很簡單的是非題。
想進一步驗證對方是否誠實，讓你的設計師一起參與會議，直接與對方的設計師討論最佳做法。會議結束後，詢問他們的看法。
你的團隊內有多少位初級 / 高級工程師？當每個團隊的結構都不一樣的時候，你如何保持跨團隊的品質？
為什麼這樣問：沒有一個外包商可以負擔得起完全不包含初級工程師（通常指 0 – 5 年經驗）在內的團隊。另一方面，一家公司如果選擇不投資在初級工程師身上，長遠來說對整個軟體開發生態並不健康。所以可以期待的是，一個會投資在訓練初級軟體開發工程師的優良團隊，應該擁有一個健康的成員比例。
一個好的開發團隊應該有不同的措施來保證其產品品質。比方說，每一個 pull request 都會由一位 tech lead 來進行 code review、內部會進行定期的技術交流，或者標準化使用框架、適當的技術規劃、提供 mentorship 或 buddy program 等等。
如果我提供一個完整的 UX / UI 設計給你，你希望我以什麼形式向你的工程師表達設計要求？
為什麼這樣問：這個問題能帶出兩個重點：
- 外包商的設計團隊是否有標準化的輸出規格提供予開發工程師；以及
- 他們的工程師跟設計師溝通合作時，是否有一套標準流程
你可以藉此觀察對方是否設有內部設計流程。或者你也可以換一個問法，詢問對方是否有內部開發團隊，還有你的設計團隊如何移交設計給他們的開發工程師。
好的答案：
「你可以提供原本的設計檔案（例如 Sketch / Adobe XD CC / Figma / Photoshop 等等）還有設計規格和規範給我們（可以參考我們的設計流程）。」
「可以提供 _____ 嗎？ （空白位置可以自行填入任何設計軟件規格，例如 Zeplin）」
一個優秀的設計和開發團隊應該有能力指出設計規格和規範裡未盡說明之處，並且備有一個清單來核對所需的項目。
他們會反問的原因是因為這些設計規格將會成為開發工程師建立產品的藍本，而他們需要確保專案裡的每一位參與者都有相同的基礎。假如在缺乏完整 UX / UI 設計的情況下進行開發，很有可能會觸發問題：像是遺漏一些功能，或者建立不必要的軟體架構。
總括而言，當你向外包開發商提問時，請留意對方回應的內容還有回應的方式。一個優良的設計和開發團隊理應可以針對你的問題提供具體的答案和合理的解釋。
誰能給出最高或最理想的數字並不重要，更重要的是從中深入了解開發商的運作模式，還有他們如何做出各種預測（比如我們會使用 EBS）。儘管外包了你的產品，實際上對方的設計師和工程師是你的緊密合作夥伴。他們應該保持高透明度，讓你能清楚了解他們的工作內容和隨時掌握進度，才能長遠地共同創造出成功的數碼產品。
Oursky 致力幫助品牌與企業家實現他們的點子。如果你正在尋找合作夥伴一起建立下一個自家數碼產品，來跟我們聊聊吧！
原文：5 app vendor screening questions when outsourcing development
作者：Oursky
翻譯者：Queenie So
