從資料科學人力配置，看公司的資料工程複雜度
康威定律告訴我們：設計系統的架構受制於產生這些設計的組織的溝通結構。
對於求職者來說，要了解一間公司，有很多面向可以評估。對於資料科學領域，常用的一個方法就是評估它的資料工程複雜度，更簡化來說，就是科學家跟工程師的比例。
資料科學的職缺實在太模糊了，光看職稱很難知道在作什麼，仔細檢視 JD 是一個方法，但只能幫助你看到「這個職缺本身」，若要看「這間公司」，參考他們不同職缺的比例，會是一個不錯的想法。
評估出不同公司之間人力配置的差異，也可以某種程度反映出這個職缺的工作內容，這是另一種由上而下的觀點。
再進一步來說，可以反映出公司目前產品建構策略，是著重在哪一部分。比如是一間資料科學非常吃重，但是科學家也得負責很多工程活的公司？還是工程師為主，需要 AI 的時候只要用現成的套件兜出機器學習模型？又或是定位非常清楚的大企業：系統穩定、制度完善，不會有太多突發狀況，但卻相對犧牲彈性與效率？
一間公司的資料工程複雜度（Big O）
念資訊工程的很常會用 Big O 來估算複雜度；它能簡單地給出一個概念：如果我們最在意的某項指標（流量、用戶）增加了，會需要相對多少的成本（運算時間、機器花費、頻寬等等）複雜度。
比方說有兩個設計，在流量增加為 10 倍的時候，A 設計需要 100 倍 (n^2) 的計算時間、B 設計只需要 log10 倍 (logn)，那單看這個指標的話，後者可能是比較優的選擇。
現在來把這個概念套用在資料科學產品上，考慮人力問題，我們把「流量」替換成「資料科學產品」，看重的指標從「時間/空間複雜度」改為「工程成本」，為了簡單起見，單位都改成人力（人*工作天）
這裡我做了一個假設：資料科學家比工程師還要接近業務端、甚至本身就對應到產品。這件事情在多數情況下是對的，少數情況下（Google Brain 等核心研究單位）則是錯的，但我認為世界上沒有太多人的工作屬於這種，就先不討論。
於是我們會得到一個 Big O 的估計，意義接近於「每增加一個科學家的工作，需要增加多少工程師人力？」
工程師數量少，不等於工程活就少
注意這裡講的不是表面上的職缺數量，而是真正需要的工作量，所以即使擁有再多的科學家，如果他們必須要做一堆工程，那我們還是算它為工程活；反之再多的工程師，如果做的大部分是機器學習，那我們一樣算它是科學家（這比較難發生...）。
變動的複雜度，以及影響的因素
這個「Big O」的答案，每個組織不同，同一個組織的不同時間也會不同，比如有公司是三倍（線性關係），代表一個科學家的業務，需要三個工程師來實作、將服務泛用化、擴展服務可用性、營運維護等等。
以下舉兩個比較極端的例子，實務上多半是介於兩者之間。
混亂一點的初期新創可能是平方（n^2）好比說 5 個科學家需要 25 個工程師的工作量來輔助。但現實中你不常看到新創有這麼多的工程師資源，因為在那個階段，很多產品根本無法存活多久就消失了，所以服務穩不穩定、能不能擴展，都不是那麼重要，公司存活才是首要考慮。
而相對穩定的大公司，或許有能力可以做到對數等級（log n）、更理想的情況是將工程複雜度的人力維持在常數項：也就是即使增加了一百個科學家，也不太需要增加對應的工程師人力，因為很多技術都已經模組化、平台化，並且工程師的規模已經大到能夠有效的分工，當然這件事情非常困難。
既然各種情況下的答案都未必一樣，那是什麼因素會影響複雜度？
業務穩定度
業務越穩定的公司，越有辦法將資料需求收斂起來，成為一個通用的介面或是平台，讓機器與流程去處理，進而降低工程上的業務複雜度，以及工程師的人力需求。
資料來源複雜度
資料科學吃的就是資料，如果資料來源非常單純，或是只有公司內部結構化的來源，那需要擔心的事情也就少很多；反之若有大量不受控的外部資料來源（比如爬蟲、合作夥伴對接），公司業務便直接受到外部影響，工程複雜度就更高。
目前的職缺比，與能聘僱到的職缺比
這兩項控制的是未來趨勢，在同一個時間點，若工程師足夠多，接下來的一段時間內便有較多能力去將可預見的需求統一規劃，進而降低工程複雜度。這是雞與蛋問題，控制不好的話會出現惡性循環。
而市場上能聘僱到的人也並非無限，以台灣來說，想做資料科學的人遠多過資料工程、並且工程經驗比起資料科學更難在學生時代培養。這也會影響企業徵才走向：如果一間公司需要工程人才，但市面上只找得到想做模型的人，他會放棄不做產品嗎？還是用比較廣泛的職缺先招募進來，一邊做模型、一邊做工程呢？
管理階層與高階技術主管的規劃
即使有一大堆資料工程師，如果沒辦法預見需求、也沒有能理解資料工程複雜度重要性的管理階層，那資料工程師只會是不斷地打雜、清理資料、處理營運問題，複雜度就降不下來。
甚至可能會因為高層看到火都被工程師處理掉了，暫時乍看沒問題，就繼續擴張業務；高層可能很難知道的是，現在增加一項資料科學業務，已經需要五個工程師在幕後扛了，再繼續增加業務下去，複雜度不減反增，變成一比六、一比七，但工程師不會跟著找這麼多，整體效率自然開始下降，進入惡性循環。
「一開始你跟我說一個資料科學家只要一個工程師幫忙就好，怎麼現在要三個？是不是這三個能力太差？」這可能就是沒有考慮到工程複雜度帶來的影響。
人力配置的重要性
通常大家都會好奇一間公司的工程師佔比多少，某種程度代表研發能量；不過我在了解一個資料科學職缺的時候，則會特別去注意他們的科學家與工程師比例，就像這段文章說的：
擁有比資料工程師還要多的資料科學家，通常來說是個問題。一般來說這代表的是這個組織得讓他們的資料科學家作資料工程。
一個常見的起點是每一個科學家對應到兩到三個工程師的比例，對於那些更複雜資料工程需求的組織來說，可能會上升到每個科學家對應四到五個工程師。
你需要更多的工程師是因為：創造資料流比起機器學習或 AI，需要更多時間與精力。原文：Having more data scientists than data engineers is generally an issue. It typically means that an organization is having their data scientists do data engineering. As I’ve shown, this leads to all sorts of problems.
A common starting point is 2-3 data engineers for every data scientist. For some organizations with more complex data engineering requirements, this can be 4-5 data engineers per data scientist. You need more data engineers because more time and effort is needed to create data pipelines than to create the ML/AI portion. - Data engineers vs. data scientists – O’Reilly
如果要精確地得到這個數字，你可能必須在面試當面請教主管，但也不一定每次都能得到答案；也有一些方法能夠間接推估，最簡單的就是看招募頁面的職缺，是否在數量上或是工作內容上有明顯偏向哪一方？（其他的管道像是獵頭跟自己的人脈也會很有效，但這些資源並非每個人都能取得。）
有時候我會看到一字排開都是資料科學家，沒有工程師，但一間公司已經有足夠工程師、只缺科學家的機率並不高，通常是代表科學家做了很多工程活。
也有時候某些公司寫著機器學習，但職缺都以 full stack 或是前後端工程師為主，那很可能是公司認為實作出產品比較重要，工程師可以某種程度做一些簡單的機器學習工作來補足。
工程師多就一定好？
要注意的是，雖然通常的情況是工程師不足，但也並非代表工程師越多就越好。
資料工程師未必都懂機器學習，這會引入溝通成本；而且純粹的資料工程師專注在資料平台的穩定性與擴展性，可能比科學家更不願意作繁雜的維運工作（多數科學家還比較接近業務端）。
再來，若要培養機器學習工程師，甚至作 MLOps，也都是一條漫長的路，這也就是為什麼大家都知道缺工程師，但卻還是有很多小公司仍然以科學家為主的原因。
了解一間公司對資料科學的「想像」
有時候我們會看到「企業文化」或是「組織經營策略」這些名詞，要在求職階段就深入了解到一間公司文化與高層策略，毫無疑問是很困難的，畢竟美好的發大財願景人人都會講，公關也一定會做好做滿。
但身為一個工程單位的員工，我們至少可以透過資料科學與工程的人力配置、以及資料工程複雜度的評估，去看這間公司對於資料科學的「想像」是什麼。畢竟，要了解一個人的方法不是看他說了什麼，而是看他做了什麼事。