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

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 的人，實在眼光太短淺了。

DevOps 的意思就是 Development & Operation 開發與運營的無縫銜接。

聽起來頗抽象。DevOps 這名詞第一次出現約為 2009 年。它是包含著技術開發一路下來發展出來的工具群，和它們所解決的問題。包括：

1. Integration Hell 代碼整合地獄：例如未有 git / svn 之前，同一項目的多位工程師的代碼，到整合的時候，會構成嚴重的整合難題；整合也花上很長時間。
2. Pending Code：累積大量沒有實際上線運行的代碼。沒有上線，就沒有在生產環境上驗證。
3. Uptime 上線維護成本極高：以前的標準是 99.9%。現在一般都是六式碼 (6 sigma) 99.99966%。要保證有此水準的在線服務率，要有非常好的回復和後備計劃，甚至自動化。
4. 設施管理或部署成本極高
5. 服務器監察成本極高
6. 系統和產品診斷極難

而在 DevOps 裡，這些都被一些工具群所解決了。例如參考 AWS 和坊間的一些服務：

Integration Hell Pending Code	CI / CD
Uptime維護 自動設施管理或部署	Multi-AZ CloudFormation / Infrastructure As Code IaC Docker / Containerization
服務器監察成本極高	CloudWatch CloudTrail
系統和產品診斷極難	Crashlytics Analytics / Firebase Feedback Systems

CI / CD 是 DevOps 群裡的其中一個重要概念。全寫是 Continuous Integration & Continous Delivery & Deployment 持續性整合與持續性部署。

Continuous Integration	1. 漸進式加入代碼 2. 自動化測試 / Regression Test
Continuous Delivery	CI → 一鍵部署到生產環境
Continuous Deployment	CI → 自動部署到生產環境

 

Lean Startup 或 Lean Method 是 2011 年由 Eric Ries 參考上世紀不少用於其他領域的管理方法論中，整合出一套適合科創公司運用的產品管理方法論。因其大獲好評，他本人因此離開了運營管理的工作，進入全職的這方法論的傳播者，到處講學、教授其他人應用這方法論。並以 Lean Startup 一書為標準教材。

Lean Startup 的厲害之處，是它能將開發達到 Product – Market Fit（產品與巿場契合）的時間大大縮短。有不少專業示範是以小時或日為單位。筆者亦是常用 Lean Method 的運營者，有幾個達到小規模盈利的產品，都是只涉及數小時的開發時間。

和另一神器 Agile 很像，都是很多人運用得半䶢不淡，畫虎不像。而不能將其強處發揮出來。

Lean Startup 因篇幅所限，未能在此篇中詳談。筆者有另一專欄企業啟導，是專寫探討從零創業 From Zero to Hero 的方法論。這篇只略談 Lean 的重點。

Lean Startup 有幾個重點：

1. *LEARN*。很重要所打星號。很多坊間講這事的人，都是以 MVP (Minimum Viable Product) 來開始講的。然後就說建立一個怎樣的產品….然後就是死在起跑線。教的人教不好，所以做的人會做錯。Lean Startup 的第一個重點，不是建立一個 MVP 或產品。重點不是產品，而是研究個學習流程。盡快啟動學習廻圈。
   1. Learn 的精粹，在於問問題。有基本建設方向後（例如是做一個 B2C 網站或手機軟件產品），就要開始建立個列表「這產品要成功所需要的因素」。例如：有實用價值嗎？有人會用嗎？有人會付錢嗎？這些問題之類。
   2. 然後，就思考如何找出那些問題的答案。這些問題稱為「商業的主要假設 」(major hypotheses)。而找出那些答案的方法之一，才是 MVP 的切入點(Minimum Viable Product 最小可行產品）。
   3. 非常多人犯的錯是：MVP 不一定要開發項目或軟件。可以是一個 excel 檔，一段影片，甚至是一個面書或推特 (twitter) 的發佈文。我常說，例如手游的開發，可以是不需碰到手機的程式碼；例如先以 excel 的表設計個遊戲出來，或用紙筆或道具，和朋友和夥伴之間先玩玩個效果如何。
   4. 重點是學習。就是證實那些主要假設。而不是開發和 MVP。要用最大的能量去學習，和證實假設。這個效率越高，整個 Lean Startup 方法論的實踐的成功機會越高。
2. 第二重點是 Measure 測量。Lean Startup 的第二個核心，是要有一個很有效的測量方法。
   1. 這個測量方法越明顯，對整個團隊越透明，內容越豐富，那麼團隊管理以至學習流程和產品調整會越有效。亦大大增加成功和生存率。
   2. 其中一個最好的方法，是有專做測量和內在發佈的團隊。這團隊將所有對學習有益的數據，全盤整理下來。並以白紙黑字的文檔，發佈在公司內公眾場合，供人隨時看到。並放在流通的內聯網上，可以隨時在內部文件引用，在會議中按數據討論。
3. 另一個是 Pivot 轉變方向。Lean Startup 必須有足夠的靈活性和機動力，以確保最大的成功機會。Lean 的產品開發過程，有小調節和大調節。大調節就是一些基本方向的轉變。這就是 Pivot 的意思。
   1. 而 Pivot 就好比一個飛機起飛跑道：起飛前，剩下的跑道距離，就是一個創業公司的生存時間。這個跑道的距離，就是以轉變方向 (pivot) 的次數所計算。
   2. 可以說：若團隊機動性非常高，可以增加轉變方向的嘗試次數，那麼跑道的距離延長了，成功的機會亦會大大增加。這是技術部的總結構師那邊作為技術人員可以影響成功和生存率的其中一個顯著方法。

熟悉 Agile 的人可以看得出：Lean Startup 產品管理方法論和 Agile 項目管理方法論有非常高的契合度：基本上每個 Lean 的學習廻圈的測試，都是一個 Agile 的 Sprint 循環。這便能將兩者無縫連接，完美契合。

似乎這個方法百利而無一害。是不然。順便亦談談 Lean Startup 一些曾被人疚病之處。

1. Lean Startup 著重市場。容易因為面前巿場的一隅，因以徧蓋全而錯過好的概念。
2. 有人質疑大概有些產品是不可能以 MVP 測試。
3. 商業向導，容易破壞好的產品。

不過對筆者而言，商業就是這樣一回事喔。是巿場優先而不是產品優先的。

Lean Startup 先談到這裡。Lean Startup 是以實作為主的方法論。好比打網球，需要對「球感」有足夠的掌握。需要好的教練教導和引導。

Agile / Scrum 是個項目管理方法 (Project Management Method)。而它在互聯網商業或科創公司差不多是不可或缺，而且是很常見。不過，不是每個實行者都能實在運作出來。很多都是半䶢不淡的畫虎不像。

說之前要先說明：未必一定要 100% 是 Agile 才是好的項目方法。盡信書不如無書。這好比用筷子吃飯不一定是最好的，要懂得用其優點才是好。若不懂用而勉強用，那不如用匙羹吃好了。

Agile 主要分為幾個部份：

1. 定義一個 Sprint（週期）：必須為一個固定的週期，例如一週、雙週、一個月等
2. Product Backlog：待辦工作列表。
3. Sprint 之初的 Sprint Meeting：一起討論這個週期開發甚麼，從待辦中揀選。
4. Sprint 之末的 Sprint Review：檢查成果
5. Sprint 之末的 Sprint Retrospective：檢查 workflow

包括這些人：

1. Product Owner (PO)：產品負責者
2. The Team：開發團隊
3. Scrum Master (SM)：項目管理流程的調控者，作為 PO 與 Team之間的協調角色。

常見的錯誤運作 Agile 的方法

1. 沒有固定時期的週期。將 Agile 矮化為純粹的 prototyping。
2. Sprint 週期以版本為標準，不是以時期為標準。這一樣是矮化為 prototyping，不是 Agile。
3. Sprint Meeting 沒有 PO 與 Team 的協商。只有單向指示。這一樣是 prototyping。
4. 沒有實際的 backlog。只有排著隊已編好版本號的開發流程。
5. 沒有 Retrospective。

例如講一個真正運作過的 Agile 真人真事案例：

1. 每星期一，團隊內（例如 iOS app team）的幾個人，包括幾個前端工程師、後端工程師、平面設計師、總結構師 (Chief Architect)，加上 Product Manager (就是 Product Owner PO)、Marketing Manager、Sales、CS，早上九時半坐在一起開會。討論這週工作有甚麼目標。只討論這週工作內容和大約計劃，十時前開完。
2. 當中 Team 和 PO 一起共識這個 Sprint 週期的內容和目標是甚麼。從 Backlog 中提取。而 PO 事先負責將需求填入 Backlog，進行排隊。
3. 然後星期一餘下的時間，到星期三的黃昏前，都是整個團隊各自忙碌，主力輸出的時間。
4. 到星期三黃昏，開始進入整合測試 Integration Test。並開始全團隊進入測試流程，例如手動化測試、自動化測試，部署到 STAGING 平台 Testflight 的測試等等。
5. 到星期四完結前，正式總結這週的工作。只有兩個結論中的一個：部署上線，或不部署等下一週。
6. 若部署，在週四晚部署。週四的好處，是
   1. 在一週完結前完成這週的工作，不要帶到下週
   2. 若週五部署，一旦出現問題就會穿越週末，或需要用週末來除錯
   3. 可以在週五六日的用戶黃金時間（大部份行業，金融除外），善用用戶人流
   4. 可以空出週五來做進一步的小改進、完善化，觀看數據、檢討。
7. 部署後，若有問題就週五修補。若無問題，團隊可以善用時間作
   1. 小改進、完善化
   2. 觀看數據
   3. 檢討
   4. 整理、改善：工具、流程
   5. 慶祝
8. 下週一再來循環

 

項目管理是管理學中的其中一個學科。並不是全部。

現代市面上普遍流通的項目管理方法論有三套

1. 以 PMP 為標準的傳統項目管理。在 Jobsdb 上仍然是其中一個最常見的技能或需求證書的關鍵字之一。合格率一般約一半。
2. 以 Prince 2 為標準的英式項目管理。它在香港流通因為英殖時代遺留，現在政府工作仍然是以此為項目管理的標準。
3. Agile / Scrum。科技或互聯網商業的公司一般以 Agile 為標準，配合 Lean 與 Devops 成為三大神器。

筆者以上三套都有在工作中頻密使用。但漸漸發覺三套都各有缺點，而且解構能力、應用於溝通、解難等能力都不甚有效率。於是大約在十年前自己開發了一套項目管理方法論。

筆者的方法論分類：

1. Purpose
2. Scope
3. Methodology
4. WBS
5. ETA

和筆者自己開發的項目金三角

1. Scope
2. Time
3. Budget
4. Quality
5. Risk

適用於筆者培訓的團隊。

以前研讀管理模式時，常喜愛討論有機性管理和無機性管理 Organic and Inorganic。

Inorganic 無機性，就即是人為的 Artificial。經濟學上有市場調控，管理形態上也有重視計算、計劃等的無機性管理。人類的現代管理學大都是二十世紀的產物，很多都是百多年內誕生的，而很多都是因為應付工業革命後的社會狀況，經濟問題、生產問題、資源問題等等應運而生的。而人類在這些計算和計劃的管理方法論中，解決了相當多和重要的問題，因此現代管理學亦相當信任人為操控。

Organic 有機性，就是自然化 Natural。到二十世紀後半，當世界普遍經濟已取得相當多的重大突破，經濟活動繁盛起來後，開始有一些更複雜，和以前的管理學解決不到的問題。於是就誕生了很多有機性的管理學理論。例如蝴蝶效應、混沌理論 Chaos Theory、搏奕理論 Game Theory；亦漸漸轉向重視古典管理學例如易經、老子、儒家等等。

有機型管理，可以用一個故事解釋其好處的：

真人真事。曾經有個主題樂園，想重新設計它的入場路線、建設草地和鋪小石路等。管理機構公開有獎徵稿，要找出一個最好的設計，以最優化入場路線，在人流、效率、營運、等等各方面，都做到力求完美的方法。

機構收到很多來稿。很多專業的設計師和建築師，但都不甚滿足。去到最後，終於收到一個來信，給了一個最完美的設計。這個設計壓倒群雄，得到了冠軍的寶座。這個設計是怎樣的呢？

那個設計 — 甚至不可以算是設計，因為沒有藍圖，只有一句話：

「將園內都鋪上草地，任入場者來行出路徑。然後順著那些路徑，鋪上小石便可。」

這個概念，便是所謂有機型管理。

有機型管理的原理，是因為無機型人為的模式，往往只能觀察和量度比較主要和明顯的因素，而忽略次要和繁瑣的其他因素。而有機型則可以因為退開一步，任由事情發展，然後在適當情況下才干預，導致事情比較能順著它們的本來的性質適當地自動調節，而那些繁瑣但亦相當影響結果的次要因素，得到適當的顧全。

而無機型管理 Inorganic management 也不是完全棄掉不用的。在明顯的需求、明顯的問題解決方法，先應先應用無機型管理。解決了明顯的問題，然後才運用無機型去做長期演化和仔細契合。例如上面的主題樂園例子，入場位置、機動遊戲位置、水電管道、保安系統等，都應先以無機型管理解決。然後人流的安排才用有機型管理。

以下引用一些古代的智慧之言。不妨參詳有機性管理當中蘊含的智慧。

《論語.陽貨》裡是有句話這樣說的：

子曰：「予欲無言。」子貢曰：「子如不言，則小子何述焉？」子曰：「天何言哉？四時行焉，百物生焉，天何言哉？」

譯出來就是：孔子說我沒有教導。子貢問：若你不教，我們又傳講甚麼呢？孔子說：你看上天，它幾時會講學？四季萬物一樣發生，上天又講了甚麼呢？

無為，而無不為。老子有幾段話談 Organic Management 有機管理學是很精采的。順便貼在這裡看看。如想找翻譯請找筆者或自行 google。

是以聖人處無為之事，行不言之教；萬物作而弗始，生而弗有，為而弗恃，功成而不居。夫唯弗居，是以不去。~ 老子2

是以聖人之治，虛其心，實其腹，弱其志，強其骨。常使民無知無欲。使夫智者不敢為也。為無為，則無不治。~ 老子3

天下神器，不可為也，不可執也。為者敗之，執者失之。是以聖人無為，故無敗；無執，故無失。~ 老子29

道常無為而無不為。侯王若能守之，萬物將自化。化而欲作，吾將鎮之以無名之朴。鎮之以無名之朴，夫將不欲。不欲以靜，天下將自正。~ 老子37

為學日益，為道日損。損之又損，以至於無為。無為而無不為。取天下常以無事，及其有事，不足以取天下。~ 老子48

故聖人云：「我無為，而民自化；我好靜，而民自正；我無事，而民自富；我無欲，而民自朴。」~ 老子57

為無為，事無事，味無味。大小多少，抱怨以德。圖難於其易，為大於其細。天下難事，必作於易，天下大事，必作於細。是以聖人終不為大，故能成其大。夫輕諾必寡信，多易必多難。是以聖人猶難之，故終無難矣。~ 老子63

為者敗之，執者失之。是以聖人無為故無敗，無執故無失。~ 老子64

團隊是共生的。

團隊共同分享一套資源。
分工形成一個機器，處理工作。
各自有其角色，各自專長。

而這些當中，以一個共識連結大家，就是效率來說的重中之重。

而我通常會推薦一個「共識」的模式：

1. 大家在討論階段，可以任意討論意見。以邏輯、客觀對話為主。
2. 在得出結論之後，留給大家一個最後的審察機會。安靜、冷靜、獨立思考為主。
3. 一旦大家在一個安靜之後都決定以此為共識，就確立共識。
4. 然後，各人出發去執行共識。
5. 要彼此信任，並專注於自己的部份。
6. 而重點在：一旦有確立的共識，就不要改。無論如何，都要忠於執行。若不同意，就應該在安靜期之前提出否決。沒有否決，確立了，就必須委身完成任務。

筆者做培訓做了很多年。有個教誨是差不多每次都會講的：

「你知否怎樣可以用最短時間，從 mentor 身上學到最多？」

Mentor 是很難得的。很多人一生都沒有遇著幾個好 mentor。而若你遇到一個好 mentor：(1) 他本身是個有方法的人；(2) 他願意分享 (3) 他懂怎樣有效分享。若你遇到一個這些都整全的，那恭喜你了。而你知道怎樣在有限的時間內獲益最多嗎？尤其好的 mentor 往往都是很忙的。

先留意 mentor（師傅 / 指導師）和老師不同。可以說，類似的角色還有這些：

1. Mentor 師傅 / 指導師
2. Teacher 老師
3. Coach 教練
4. Leader 領袖
5. Counselor 輔導者
6. Supervisor / Boss 上司 / 老闆
7. Manager 管理者
8. Senior 前輩

這些之間是有分別。

而能傳授的知識，是可以有這些分類：

1. Knowledge 知識
2. Skill 技能
3. Methods / Know how 方法
4. Mindset 思維
5. Values 價值觀

怎樣可以用最短時間，從 mentor 上學到最多？
我常說，知識是不用從人身上學的。現代知識爆炸，面書和搜尋器都方便，差不多找任何知識都可以。學知識的最快途徑應該是看書：速讀那種，半小時至一小時內看完那種。若找到個好 mentor，只能學知識，是很大的浪費。

技能和方法，也是不用從 mentor 身上學的。技能和方法應該去聽講座、找老師、問人。

所以，剩下的就是思維和價值觀囉。這兩個是特別寶貴，而且是若你找到個好 mentor，是非常值得從他身上學的。

「思維」往往是一個人成功的主要原因。很多人以為「贏在起跑線」就是成功的關鍵，事實不然：每個人都有某種程度的優勢，或多或少、不同角度；而「思維」怎樣操作那個優勢才是優勝原因。而優秀的思維往往能逆轉劣勢。
而一個成功的人之所以成功，他的思維一定有過人之處。而失敗的人也是一樣，也是因為思維。所以若遇上成功的人，很值得多去觀察他的思維是怎麼樣，他有甚麼過人之處，使得他得到成功。

「價值觀」是一件比思維更高的事情。「思維」能帶你找到某個定義下的成功，例如社會所定義的成功。但優秀的「價值觀」能將你完全從所有的定義中解放出來，達到真正的自由。兩者加起來就是自由與成功。
越優秀的價值觀，在社會中是越難履行出來的。但若有人可以實踐到高尚的價值觀，同時又能在社會中找到幸福與安身立命和他的成功的方法，他的價值觀和執行方式，便是很有價值去學傚的，以他本人以身作則的示範。

而剩下的，就是多聽、多問、多做、多想。