在這欄目加多一篇專講遊戲製作。方法論上都是和前篇（連結）是一致的；分別是以遊戲業作為場所。

基本方法論的流程是這樣的：

1. 先做 BI (Business Intelligence) 和市場調查
   • 遊戲可以用例如 AppAnnie（Sensor Tower 收購後現在改了名叫 data.ai）之類的服務，去預先知道下市場狀況。例如同類型遊戲一般有多少月用家 MAU、同時在線人數 CCU、營收 revenue；或對象群的 Persona、用戶主要是甚麼國藉、年齡層等等。
2. 然後開始做企劃，包括：
   • 遊戲設計 Game Design；
   • 開始有個項目計劃，例如收入與支出、開發期、開發成本、推廣成本、其他主要成本等等；
   • 遊戲收費方法、並目標下載人數；
   • 企劃其實是個假設 hypothesis。這假設是要去到數據營銷 analytics 的部份才能具體證實。
     • 這點有兩個指標是值得推薦的：Value Hypothesis 和 Growth Hypothesis。前者 (Value) 是指產品具價值，會有用戶使用和喜愛；後者 (Growth) 是指產品具推增長能力，容易增加用戶。
     • 這兩個指標一般用在普通軟件平台或服務。因為遊戲本身有其價值與增長邏輯。但值得參考。
3. 第三步是 MVP
   • 就是有初步企劃、遊戲設計和營運計劃後，就先試試做個很簡單的設計出來，實際測試下受眾反應。
   • MVP 的開發需時，以 1 man day （即八小時）為準，以 1 小時內為佳。做到測試受眾反應就足夠。
   • 記住任何數據、包括藉 MVP 取得的，都是為證實上文、企劃的 hypothesis 為主。
4. MVP 成功後，第四步就是主要開發時期 major development。而且漸漸建立起 agile + lean + devops 的技術管理。
5. major development 正式 release 出街後，第五步就是進入數據營銷廻圈。
   • 就是以數據 analytics 來推動 lean method，並不斷將產品優化、提升營運主要指標（例如用戶數、收入等等）、提升效能等等的流程。
   • 也可以在這裡建立起 Innovation accounting 的系統。
   • 記住任何數據，都是為證實企劃的 hypothesis 為主。以企劃初心為準則，首尾呼應的一致性營運方法。

上面10 篇中，我想抽幾篇出來，講解下企業或創業中數據的本質。

1. (2)：定調與 BI（連結）
2. (6)：MVP Method（連結）
3. (8)：Lean Method（連結）
4. (10)：Pivot or Persevere（連結）

從以上四個關節：整個企業的開創過程，是個完整的數據測試。是個科學實驗。

是這樣看的。

1. 起初的階段、定調的過程，是構成個主要的 hypothesis 的階段。是一個「用這方法就會做到某成果」的科學假說 hypothesis。是用前置的 BI 的研究市場和可行性。（即前篇(2)）
2. 然後做大概的初步設計和想法。
3. 然後有了大約的藍圖後，就另外設計一個 MVP 去做個簡單的初步測試。這個 MVP 是以越簡單越好，例如做半小時或一小時的一個設計。然後將這個 MVP 放出去給普通用戶看看初步數據回饋。這個 MVP 的數據回饋，差不多都可預視到日後的發展的高度。（即前篇(6)）
4. MVP 成功和通過後，就做主要開發和生產。
5. 到產品初步上線，就進入 Lean Method 的流程。是用後置的 Analytics （或俗稱 Big Data 大數據）來繼續做企業學習，和改進產品表現。（即前篇(8)）。
6. Analytics 做得好是會 formulate 做 Innovation Accounting。而且是會與 BI 遙相呼應；而且是會伸延 BI。
7. 若到某些發展樽頸，可能需要做 Pivot or Persevere。（即前篇(10)）

要寫一篇講下 Scrum / Agile 怎樣運作。

本地很常見 Scrum 都運作得不很正規；普遍觀察是少於一半是運作適當的。Scrum 運作不良，不單純是品味或名目上的問題。因為 Scrum 是設計得很精妙的，本身每個設計細節都包含著很多智慧和管理經驗。若違反 Scrum 方法，差不多都保證會有某些已知的管理問題。而這些典型的管理問題都是 Scrum 的設計想針對解決的。

~ Scrum 基本步 ~

最簡單、最普通的 Scrum 是由三方組成：

1. Product Owner (PO)：用前篇（連結）的職位所分類，就是 BA/PM 類型的人。就是負責按企業和商業環境而提出需求和設計的人員。也是項目的 Sponsor，就是取得 Budget 和所需權限的人。
2. Development Team (Team)：就是開發團隊。一般包括 Engineer、Tech Lead、Architects。
3. Scrum Master (SM)：維護這個 Scrum 方法的人員。若 PO 和 Team 之間有不同意見，就需要負責解決。以維護 Scrum 方法的暢順運作。

基本方法或原則：

1. Scrum 一般都有個循環週期長度。例如一週、兩週、一個月，等等。通常是以短為優。
2. PO 有權提出需求。將需要放到 Backlog。但不可以強迫 Team 從 Backlog 中選取甚麼。也不可決定 Schedule（見下面 Team 操作）。
3. Team 有權從 Backlog 中揀選項目作這週期的開發。基本上揀選後就要負責完成。當中可與 PO 協商，但 PO 無權干預。而若 Schedule 上脫期，即是完成不了，那麼作為失敗的項目論，重新排進 Backlog（企業在管理上可以有 Penalty）。
4. 每個週期的末段，即 Team 完成開發後，PO 有權揀選任意項目，作為推出上線。Team 無權過問，而且需要確保項目上線後能暢順運作。這是 Scrum 與 Devops 連接的部份。
5. 項目若有資源不足或缺乏的問題，由 PO 負責解決。因為 PO 是 Project Sponsor。

可以看到這個 Scrum 的設計，本身是兩邊的權力的限制與平衡。若有不同意，由 SM (Scrum Master) 負責調和。

Scrum 的設計是解決一些常見問題。若要窮盡需要很複雜的講解。篇幅到此不贅。

科技行業管理與透析(1)：簡介
科技行業管理與透析(2)：科技部門種類
科技行業管理與透析(3)：公司種類
科技行業管理與透析(4)：人員種類
科技行業管理與透析(5)：工程師工作日常
科技行業管理與透析(6)：架構師工作日常
科技行業管理與透析(7)：CTO/CIO 工作日常
科技行業管理與透析(8)：白帽資安工作日常
科技行業管理與透析(9)：Scrum / Agile

寫了幾篇都是有關職位。也講一個很多人迷思的職位：白帽資安人員 White Hats。

白帽資安人員 White Hat Hackers 很多時是只存在於很多人的傳說和幻想中。但實際上是有這類的正式職位。例如在香港，據我所知有正規白帽資歷、或從事白帽一樣的專業資安工作的，有大約一至二千人。

要講白帽，就必須先講資安團隊的分類。筆者之前寫過，在這裡（連結）。白帽是分類在 Red Teaming 以下。一般白帽也會叫 Penetration Tester 滲透測試人員、Security Specialist 資安專員、Ethical Hacker 道德駭客。

~ 白帽是個怎樣的編制？~

講白帽的來由，先講為甚麼企業會需要白帽資安人員。
編制外、自由工作者的有 Bounty Hunter 賞金獵人，或 Security Researcher 資安研究人貝，這些都不計算。只計企業編制內的。

原由是因為 IT Audit 監管。IT Audit 的需求，是來自有些公司是需要持牌。持牌就需要監管。
持牌的例子，例如 ISO 品質管理、PCIDSS 信用卡監管機制、 SFC 証監會、HKMA 金管局等的監管機構。

而只要 Audit 監管涉及電腦系統，就需要 IT Audit，然後就有 Cybersecurity 部門的工作參與。
Cybersecurity 部門，通常由 Blue Team 去處理 IT Audit 資訊監管；而 Red Team 是負責系統的直接「滲透測試」Penetration Test。或俗稱 Pen-Test。Pen-Test 就是由白帽資安人員 White Hat 執行。

~ 滲透測試包括甚麼工序？~

滲透測試 Penetration Test (Pen-Test) 是很專業的工序。一般都包括 *所有* 的企業技術資產。例如：

1. 公司內電腦
2. 公司內網絡
3. 雲端電腦
4. 雲端網絡
5. 各式系統
6. 各式代碼
7. 各式數據
8. 各式人員
9. 等等

滲透測試若要好好講解，可以寫另一個十多篇的專屬欄目。但很概括的說，一般都是分為幾類：

1. 社交工程 Social Engineering：非技術，純粹針對人員操作的測試。
2. 網絡外到網絡內
3. 電腦群外到群內
4. 企業權限外到權限內（例如 Active Directory 之類的網域目錄權限集）
5. 低階、二元式：Binary / Assembly Level。例如著名的 Stack Overflow，就是屬於 Binary 類。

科技行業管理與透析(1)：簡介
科技行業管理與透析(2)：科技部門種類
科技行業管理與透析(3)：公司種類
科技行業管理與透析(4)：人員種類
科技行業管理與透析(5)：工程師工作日常
科技行業管理與透析(6)：架構師工作日常
科技行業管理與透析(7)：CTO/CIO 工作日常
科技行業管理與透析(8)：白帽資安工作日常
科技行業管理與透析(9)：Scrum / Agile

寫一篇有關 C-level 的員工。

CTO / CIO 是些迷人職位。因為聽落很勁。但技術這回事，行內很多高人。若做了個技術低的 C-level，一樣是得不到其他專家尊重的。

講下啲普遍迷思。

~ CTO/CIO 要是技術專家嗎？ ~

常見迷思之一是：CTO/CIO 要不要技術很好？或純粹是管理，專業工作由下面的人來做？

通常筆者會這樣答：若覺得 CTO/CIO 不用是技術專家的人，請回答我：那麼 CEO 和 CTO/CIO 的分別在哪？或和其他 C-level 員工的分別在哪？

除非回答到這問題；否則 CTO/CIO 與其他 C-level 的員工的分別，就是 CTO/CIO 是企業裡的科技專家，是解決企業決策上需要專業技術的問題。否則，沒有技術的 CTO/CIO，其實不如說是和 CEO 或 COO 的功能重疊。

~ CTO 和 CIO 之間怎樣分？~

CTO 是 Chief Technology Officer 技術總監 / 首席科技官；CIO 是 Chief Information Officer 資訊總監 / 首席資訊官。CTO 是負責 Solution 和 Production 的。一般是以科技為主業、或有科技項目的公司才會有。CIO 是 IT 的運維面和成本面；企業未必是以科技為主的公司也會有。只要公司用到電腦或資訊，也會有 CIO。但未必有 CTO。

還有個是 CISO (Chief Information Security Officer) 資安總監 / 首席資安官。是專管資安事情。一般要持牌或金融機構，都有可能有 CISO。一般都是管理合規 Compliance 、資訊監管 IT Audit、資安 Cybersecurity 的問題。

科技行業管理與透析(1)：簡介
科技行業管理與透析(2)：科技部門種類
科技行業管理與透析(3)：公司種類
科技行業管理與透析(4)：人員種類
科技行業管理與透析(5)：工程師工作日常
科技行業管理與透析(6)：架構師工作日常
科技行業管理與透析(7)：CTO/CIO 工作日常
科技行業管理與透析(8)：白帽資安工作日常
科技行業管理與透析(9)：Scrum / Agile

Engineer、Tech Lead、BA / PM、QA、Sysops、Architect、CTO/CIO。這些職能中，Architect 是個很多人不熟識的工作職能 (Job Function)。寫篇講解一下。

~ 架構師的工作範圍 ~

一般我是這樣講解的：

1. 若是編程或直接開發，就是工程師的工作範圍。
2. 若是有關設計和使用，就是 BA/PM 的工作範圍。
3. 若是有關 Performance 效能的，一般都是架構師的工作範圍。

Performance 是個概括術語。Performance 包括好幾方面的 Performance：

1. 速度 Speed
2. 效率 Efficiency（即性價比問題）
3. 效益 Effectiveness（即達標程度問題）
4. 穩定 Robustness
5. 擴充 / 伸展性 Extensibility / Expandability
6. 備份 Backup & Restore
7. 自動化 Automations
8. 資訊安全 Cybersecurity
9. 治理 Governance / Policy（例如權限問題、誰在系統中做甚麼、怎樣確保不會出錯）

以上這些都是架構師負責設計、管理、執行。
所以一般架構師都要是有很豐富的技術經驗，和管理經驗。要熟悉很多種語言、OS、系統，甚至跨雲、跨系統、跨語言。
通常我會說，訓練一個專業的架構師，一般都很難少於 15 年純技術經驗。

~ 架構師的分類 ~

架構師是掌管 Holistic View，就是系統或企業的整合。一般都不會純粹叫 Architects，而是會連帶職能一起：

1. 功能類
   • Solution Architect 方案架構師：一般就是負責開發項目的架構師。可以說是最典型的架構師。上圖灰色和紫色部份都算是這類開發類架構師。
   • System Architect 系統架構師：一般是運維職位。是在運維角度考慮系統的整合。上圖綠色部份都算是這類運維類架構師。
2. 領導類
   • Entreprise Architect 企業架構師：不是以項目為整合，而是以企業角度作整合。例如是關注企業的商業業務發展的角度，來優化系統的設計或效能。
   • Chief Architect 首席架構師：首席架構師其實很像企業架構師（除了企業架構師有時是會多於一個）；但 Chief Architect 通常是不包含做商業決定的功能。純粹技術人員。少許分別，其實只在名目上，分別不大。

科技行業管理與透析(1)：簡介
科技行業管理與透析(2)：科技部門種類
科技行業管理與透析(3)：公司種類
科技行業管理與透析(4)：人員種類
科技行業管理與透析(5)：工程師工作日常
科技行業管理與透析(6)：架構師工作日常
科技行業管理與透析(7)：CTO/CIO 工作日常
科技行業管理與透析(8)：白帽資安工作日常
科技行業管理與透析(9)：Scrum / Agile

講下正常編制下，工程師是怎樣的生活。都有不少人對於學編程然後入行有興趣。

先從概略講起。一般工程師的主要工作，包括：編程、維護代碼、取項目和交項目、另外一些 ad hoc 需求。可能就是這麼多，因為都算是入行大約頭五年左右、經驗需求不深的工作。

但值得一提的是，學編程和做工程師是有明顯距離的。寫下比較：

內容	編程學生	工程師
代碼行數	一般數百內。很多是數十內。	一般每個項目最少兩萬至五萬行數。 例如若同時做 4-5 個項目，可能會同時處理數十萬行代碼。
能掌握的語言或技術	一般 3-5 種內	大部份有 3-5 年的工程師，都可以掌握 20-30 或以上種技術或語言。十年外的，很多上百。
坐著的時數	一般 1-2 小時已感不適	很容易是 6-8 小時長期坐著。有些通宵的情況是會 18-24 小時或以上。
期望的閱讀量	一般幾千字。一兩篇內。	很容易是會每週閱讀數十萬字。除了文檔、訊息、電郵、代碼；還有搜尋解難。所以一般工程師都能速讀大量文字。
期望做的年數	很多人是期望入行後 3-5 年內就不用編程；轉做管理。	3-5 年才剛開始，有少許火喉。工程是門工藝。越學精湛，含金量和價值都越高。科技專家一般都是實務 20+ 年以上的編程經驗；四十歲後仍有編程習慣；有每天編程習慣。 業界很多人期望將專業技術轉嫁他人，結果很多人是不懂編程、渣流攤的管理人員，敗壞公司和業界。
期望學習	很多是期望學幾年，然後不用再學	科技專家很多都是優良的學習能力，和終生學習。
期待薪金	高薪	這個一樣：高薪。 不過通常是入行 3-5 年後才急速上升。好處是長期有價、很少會失業。

科技行業管理與透析(1)：簡介
科技行業管理與透析(2)：科技部門種類
科技行業管理與透析(3)：公司種類
科技行業管理與透析(4)：人員種類
科技行業管理與透析(5)：工程師工作日常
科技行業管理與透析(6)：架構師工作日常
科技行業管理與透析(7)：CTO/CIO 工作日常
科技行業管理與透析(8)：白帽資安工作日常
科技行業管理與透析(9)：Scrum / Agile