第二篇。在往下去講之前，再講解一下商業模型。

有些人開展新公司之前，做營運管理已有相當年日和經驗，他們對商模（商業模型 / Business Model / Biz Model）已相當熟悉；亦有對商模不太稔熟的新手。這篇是都適合這兩者；熟悉的人可溫故知新，初學者也可以得到一個好而實用的框架長遠運用。

《Business Model Canvas》

文頂的圖是取材自《Business Model Canvas》，發佈由 Alexander Osterwalder 帶領的學術研究，研究商業模式的藍圖，一本殿堂級商業典藉。（筆者看這書不知不覺已經是十年前，光陰似箭🙈）這個圖也就是以該書命名的一個核心概念：一個設計商模的框架。

這個 Biz Model Canvas，用九個部份分析了不同的商業模型組成方法。而該書的餘下部份，都是將現有世界上成功的商業模型案例，放到這個框架當中作分析比較。

詳細的細節，讀者可以參考《Business Model Canvas》這本書。亦有它的姊妹作《Business Model You》，對個人的事業和人生發展有所分析。

改進與進化

Business Model Canvas 的年代是未有 Lean Startup Model 的年代。而 2011 後 Lean Startup Model 大放異彩，有效地導向產品設計和巿場推廣，並將其放進科學方法和模型裡有效分析。並及後 Lean 與 Agile 和 DevOps，合併運作，筆者常稱之為營運的三大神器。這三者的配合得很好，而優點在非常有效地以科學方法推動執行力和營運，並從頂至底都能一貫統合為一個企業機器。一個非常整合全身協調互動的系統。所以現代的營運管理，基本上筆者都會推薦 Lean Model。

而上述的 Business Model Canvas 與 Lean Model 的配合協作，是不太簡化和具彈性。所以筆者自己設計了一個，較能簡化而具彈性的商業模型框架。並能和 Lean Model 無縫函接。兩者都參考可以互相取長捕短。

筆者的商模框架主要考慮三件事：

1. Value Proposition：你是提供甚麼價值給用戶；廣義來說：你是提供甚麼價值給世界？這亦包括了生產系統 Production Engine。
2. Financing & Sustainability：提供 (1) 的價值的同時，你打算怎樣使這個模式能長夠維持運作下去 (Sustainability)？怎樣賺得這企業機器的運作資金？
3. Engine of Growth：你打算怎樣將你的產品推廣出去？怎樣量度其效率？怎樣支持這個系統？

 

 

網址為 http://bp.xtn.one

這個項目叫 Bible Plan，這個設計是我在 2010-2011 年間寫過的一套 iphone & android app。後來做了其他較賺的項目，沒有推廣就漸積壓倉底了😋 這十年來沒有宣傳也一直有很穩定的用戶量在用。每天都有差不多的固定登入量。不少人寄來電郵都正面回應好用，而且不少固定用戶是海外用家。

最近在整理舊資料，找了這個軟件出來，心血來潮，用 web app 重新翻寫了。

這個軟件的功能是，幫助用戶記錄讀了甚麼經文。有時工作忙碌，讀到哪裡也忘記了。這個工具便可以幫助記錄一下進度。也可以記錄崇拜經文，或不同譯本的進度呢。
這個版本加了些新功能。例如 Google Login 可以將資料同步上雲端。在設計上也有些翻新，做了些比舊版方便用的設計。

這個項目的翻寫用了大約12-14小時左右。至於技術細節，和上一套聖經軟件差不多，都是用了些最前衛的技術。全部雲端和差不多完全零營運成本：aws lambda + dynamodb +s3 + nodejs + reactjs + material + responsive UI。

筆者覺得電腦科學可以歸納為幾個範疇。也是大學對電腦科學的培訓課題的劃分：

1. 入門科、或倫理與專業操守
2. 理論科和核心結構：較主要和基礎的理論科目。
3. 數學與邏輯科：亦是較主要和基礎的科目。電腦科學的基礎是邏輯和數學。
4. 科技應用科：涉獵現有的科技世界的不同應用。例如人工智能、社交媒體，都屬應用類。
5. 編程科目：就是學編程和實習編程語言。
6. 實踐和 FYP 畢業項目：通常電腦科學的畢業論文，是連同一個實踐部署的應用項目一併提交。亦有討論商業或項目管理的科目。

當中，1-3 是「道」科；4-6 是「術」科。

概念是

1. (5)(6) 類是可以在職場中實踐累積日子學習的。
2. (4) 可以用到時才學
3. 若要教授非電腦學位人士，可以從 1-3 中抽出數個題目來教導作為基礎核心。

筆者從業多年電腦領域，常提供培訓給較年輕或初入行幾年的人士。而討論得多，就漸漸對「電腦科學」（Computer Science）這門學系有個概括的印象。印象包括：

1. 電腦科學可以總括為幾個範疇
2. 若跳過部份非必需的課題，「電腦科學」整個學系，是可以簡化為另一套簡化教材。
3. 教材有兩種用法
   1. 例如沒有電腦科學背景的人士，若想了解電腦科學，或接受訓練成為從業員，可以學這套教材，另外加上專科訓練，例如只學編程、只學項目管理、市場推廣等等。例如一些商業部門或產品部的同事。
   2. 例如對於大學畢業於電腦科學的本身已有訓練人士，也是可以作為提綱挈領、溫故知新。是很適合的在職訓練教材。

是以編寫這套教材。

 

有一些技術守則是筆者應用了很多年的，對工程技術團隊適用：

1. 有一些結構寫法，盡量不要用。若用了，請知會你所從屬的主管
   1. SQL joining multiple table。以 Denormalization 為效率優先的設計為主。若有 join table 請提出來登記。
   2. For loop +=2
2. Git
   1. 每天都 pull 一下你的項目。
   2. 由主管管理 release / master branch。
   3. 只提交能運行的代碼。確保提交後代碼是一套能運作和上線的版本。這是 CI / CD 的標準。
3. 協作
   1. 前端同事沒有後收到後端同事的 postman，可以不做。

平常筆者在 Problem Solving 解難方面，會推薦一個叫「火車」的方法。

通常問題的結構就像一個鎖鍊或火車車卡，環環相扣。
所以解決問題時，可以用這個衍生出幾個方法論：

1. 方法論一
   1. 先執住頭同尾，限制範圍 scope。
   2. 然後逐節檢查車卡，找出問題。
   3. 最快的方式之一，是用 Binary Search。就是先檢查中間。
      1. 例如若左為對，右為錯，而中間為錯，那問題在中間偏左的位置
      2. 若左為對，右為錯，而中間為對，那問題在中間偏右的位置
2. 方法論二
   1. 留意一些特別難的問題，往往因為有錯誤的假設。
   2. 例如十節車卡，所有都為真，但其中一節的車架是有 99% 為真，有1% 是建立在不可靠的假設上。就會使到整個列車成為錯誤。
   3. 同上，用方法論一找出錯誤。
3. 方法論三
   1. 以紅綠燈來說，檢查所有車卡的紅綠燈。找出 weakest link。

 

這三個結構概念是筆者經常提及的。

Atomic 是指獨存性。獨存性就是零倚賴 Zero Dependency。Atomic 的好處，就是可以獨立處理，無需前提，在結構是一個可以獨立並先處理的部件。

舉例說。電視壞了，遙控器開不到電視，同時不確定插座有沒有電。
這個處境，測試遙控器要靠電視；測試電視要靠插座。而插座本身是獨立的。這個模型，插座便是一個 Atomic 單位；因為是零倚賴 Zero Dependency。可以由插座開始測試；然後才測試電視，然後才測試遙控器。

Cohesion 和 Coupling 都是討論軟件內的模組之間的關係時應用的字眼。
Cohesion 凝聚度就是一個單位（例如一個類 Class 或方法 method / function）它內部的凝聚性。例如一個類的內部是只做一件事，那就是一個高的 cohesion；若做沒有關聯的十件事，就是低的 cohesion。

Coupling 連結度是指單位與單位之間的互相倚賴程度。高 Coupling 就是部件之間很多互相倚賴，差不多是纏在一塊。低 Coupling 就是指各個部件之間就差不多都是獨立自存的。可想而知，Atomic = 100% 時，Coupling = 0%。

舉例說。十個朋友之間，互相的關係繁複：這人是那人的表親戚，另一人又是這人的同學….之間有數十個朋友以外的個人關係，這便是個 high coupling 高連結度。而若十個朋友之間，各自有獨立家庭，沒有在其他場景認識，十個純粹是朋友關係，這便是 low coupling 低連結度。

舉例說。某人讀了三個博士學位，三個博士學位是完全不同的範疇，例如法律、物理、宗教，這便是 Low Cohesion 低凝聚度。而另一人，三個博士學位是接近或差不多的範疇，例如電腦、電子、數學。這便是有較高凝聚度 High Cohesion。高凝聚度代表著專精、更有效的時間分配。

好的系統設計，是：

1. Atomic 越高越好
2. Coupling 越低越好
3. Cohesion 越高越好

這不單是應用在電腦系統上。也包括應用在日常生活事件的管理上。

工程部門在一間以互聯網科技為主的公司裡的位置，是在生產部門裡面。

筆者平時說三頭馬車，是銷售、市場、和產品（Sales, MKT, PDM）。這三個是帶動業務發展的車頭，亦是能接合上 Lean Method 的方法。
這是以商業來說。產品是生產部門的車頭，之後是：產品 → 工程 → 測試

若以生產來說，一般只分工程師、產品經理、市場經理。這三類人放在一起就可以討論開發工程。

近幾年後流行講 Fullstack，通常是指工程師的職位和技能。就是形容一些前端和後端都能夠做的人。其實筆者是有點覺得奇怪：他們在大學裡都已經學了前端和後端的工程方法，到職場工作有十多二十年的年資，還在以 Fullstack 工程師為自豪，不是太沒有志氣了嗎？

而且大部份人講的 Fullstack 往往都不是那麼 “Full"。寫一篇講下怎樣才是比較全面的圖畫。

例如以下面這個圖為例：

1. http://www.yourApp.com 的前端首先通過 DNS (AWS Route 53 服務）
2. 然後到達負載平衡 ELB (Elastic Load Balancer)
3. 然後到網頁服務器 (Web Servers)，當中有個 ASG (Auto Scaling Group)
4. 然後再從 Javascript 或直接到軟件服務器 (App Servers)，當中亦是包括了另一套 ELB + ASG
5. 然後去到應用 Redis、Memcached 之類的快存服務 Elastic Cache。
6. 然後才去到主資料庫。資料庫亦有 Master and Slave 主次之分，亦有多地區備份 Multi Available Zone Backup。
7. 然後固態檔案從 AWS S3 (Simple Storage Service) 中取得。
8. 亦經過前端快存 AWS CloudFront 來存取。
9. 然後後台還有 AWS CloudWatch 之類的日志服務和服務器監控
10. 有 AWS SNS 的監控訊息服務
11. 有 CloudFormation 配搭 DynamoDB 一起用的自動配置服務。

以上這個才是一個比較齊整的 Fullstack 系統。簡要來說，這包括了很多雲服務的配置知識和技能。而坊間所謂 Fullstack 工程師，往往是沒有雲服務的配置經驗。而他們覺得這是運維的事情。但實際上一套整全、各方面都照顧到的電腦系統，這是個基本的最小配套，所以這是 Fullstack 工程師都應該要知悉的事情。
有些更複雜的系統，是會包括其他例如序列服務 Service Queue；運行 Devops 的 pipeline；自動測試的硬體農場 Device Farm；或需要時才應用的 Spot Instance 之類等等。

而除此之外，工程部門 (Engineering Dept) 位於生產部門 (Production Dept) 的分類之內，生產部門所必需的技能，例如項目管理（e.g. Agile、PMP 等等的方法論）、Devops 運營管理、代碼版本管理（e.g. Git、SVN 等 CVS 系統）、產品管理等等，都是工程人員應付日常工作的必要技能。這些又是否包括進 Fullstack 裡呢？若不，那 Fullstack 的工程師能應付項目管理或代碼管理嗎？

而很多人都忽略了，測試本身也是一套 Fullstack。看一下以下這些只談測試的字眼，我加上了分類：

1. 形式：Exploratory Test, Regression Test, White box Test, Black box Test, Grey box Test, Functional Test, Continuous Test, Destructive Test, Manual Test, Automated Test, Behavior Driven Development, Test Driven Development
2. 場所：Unit Test, Integration Test, User Acceptance Test, Verification Test, Smoke Test, Sanity Test, Security Test, Development Test, Alpha Test, Beta Test
3. 用途：Installation Test, Compatibility Test, Performance Test, UI Test, Usability Test, A/B Test, Grey Test, Load Test, Stress Test, Endurance Test, Vulnerability Assessment, Penetration Test

而在工程和生產以外，例如產品管理、市場推廣、商業發展，仲有行政能力、栽培訓練、投資者管理、商業法律等等，都是一個又一個的大領域，都是互聯網商業所需。那些只望著 Fullstack 的人，實在眼光太短淺了。