สรุปงาน Build for Scale: Lessons from Horizontal Core Banking & Enterprise Systems @ KBTG

“เจาะลึกโปรเจกต์เบื้องหลังแอป KPLUS ทำยังไงให้รองรับการเติบโตของลูกค้าอย่างไม่มีสะดุด”

พอเห็นคำโปรย หลายๆคนก็น่าจะรู้จักแอป KPLUS ที่มีผู้ใช้น่าจะหลักหลายสิบล้าน ดูเป็นหัวข้อที่น่าสนใจ รีบลงแบบไม่ทันได้คิดเลย

ตัวงานแบ่งเป็น 2 หัวข้อหลักๆเลย คือ

1. Architectures & Technical Design
2. Test & Deployment Strategy

ก่อนจะเริ่มก็จะมีการเกริ่นที่มาที่ไปกันก่อน ว่าปัจจุบันจำนวน Transaction ที่เกิดกับ Core Bank (ระบบ Back ของ KPLUS และ แอพอื่นๆ)

ปัจจุบันมียอดสูงขึ้นเรื่อยๆ และคาดคะเนว่าจะสูงขึ้นอีกมาก

Transaction ของ KPLUS ที่มากขึ้น กับ Core Bank ที่รับทั้ง KPLUS และ App อื่นๆ

แน่นอนเพื่อให้รองรับ สิ่งหนึ่งที่ต้องทำก็คือการ Scaling ระบบ

.

สิ่งแรกที่เค้าเลือกทำไปก็คือสิ่งที่ทั่วๆเค้าไปทำกัน ก็คือ เพิ่ม RAM, CPU, Storage ไปสิ ให้รองรับ แน่นอน มันก็พอได้ในช่วงแรกๆ

สุดท้ายแล้วเมื่อถึงจุดๆหนึ่ง วิธีนี้ก็เริ่มตันแล้ว ไม่สามารถเพิ่มไปได้มากกว่านี้

พวกนี้เรียกว่า

“Vertical Scale”

ถ้าดูตามรูปก็จะเห็น ว่าทำให้มันใหญ่ขึ้น ถึงเรียกว่า Scale แนวตั้ง

Vertical Scaling & Horizontal Scaling

เมื่อแนวตั้งไม่ไหวแล้ว ก็ได้เริ่มโปรเจคนี่ขึ้นมา หรือก็คือ

“Horizontal Scale”

ก็เมื่อเรามี Core Bank 1 ตัวแล้ว ทำไม เราไม่มี 2 ตัว แบ่งกันช่วยกันรับโหลดแล้ว ขยายจำนวนไปเรื่อยๆ ในทิศแนวนอนนี้เอง

.

กำเนิดโปรเจคนี้ขึ้นมา ในการทำเป็น

Double Corebank

แน่นอนว่ามันไม่ได้ง่ายๆ เนื่องจากระบบ Core Bank ของเค้ากระทบกว่า 183 Applications และมี Dependencies มากกว่า 200 Projects กว่าเค้าจะทำสำเร็จใช้เวลาไปถึง 22 เดือน ต้องมีคุยกับแผนกต่างๆ มากกว่า 50 แผนก

.

ซึ่งเบ็ดเสร็จแล้วการ Deploy ของโปรเจคนี้

21 รอบในการซ้อมขึ้นระบบ (เยอะมากก)

แบ่งขึ้นจริงๆ 8 รอบ แบบ Phasing ( 1 รอบที่ขึ้น คิดเป็นเฉลี่ยซ้อมไป 3–4 รอบได้ )

เรียกได้ว่า น่าจะผ่านมาเยอะทีเดียว กว่าจะได้ขนาดนี้

ที่ทำขนาดนี้ เพราะโปรเจคนี้ มีตั้งเป้า Mindset ไว้ดังนี้

1. No Customer Impact ลูกค้าต้องไม่รู้สึกถึงผลใดๆ
2. No Downtime
3. Failure is not an Option ก็คือความผิดพลาดจะต้องไม่เกิดขึ้น ทดสอบอย่างดี

อย่างที่เค้าเกริ่นไว้แต่แรก เนื่องจากเป็นโปรเจคที่กินเวลามาก (22 เดือน) และมีผู้เกี่ยวข้องจำนวนมาก (50 แผนก, 183 Apps, และแอพอื่นๆ ที่ใช้ระบบ Corebank ด้วย)

การที่จู่ๆ จะปรับโครงสร้างขนาดนี้ ทั้ง Mandays, การ Freeze Feature ที่อาจจะทำเพิ่มไม่ได้ ที่สำคัญสิ่งนี้เป็น Change ที่ถูกผลักดันมาจากฝั่ง IT ให้รองรับระบบเพิ่มขึ้น การที่จะอธิบายฝั่ง Business ให้เค้ามาร่วมโปรเจคนี้ ซึ่งปัจจุบัน ณ ตอนนี้ก็ตัวระบบ Corebank ก็ยังใช้งานได้อยู่ การทำให้เค้าเข้าใจ และเต็มใจร่วมมือ นี่เป็นสิ่งที่ Challenge มาก

เกริ่นพอแล้ว ก็มาเข้าสู่หัวข้อสำคัญกัน

1. Architectures & Technical Design

Key หลักอย่างแรกก็คือ

การเข้าใจระบบตัวเองว่าทำงานอย่างไร ทำงานได้แค่ไหน

การที่จู่ๆ เราจะมี Change ขนาดนี้ นี่ถือเป็น Prerequisite เลยว่าต้องมี

โดย KBTG มีระบบ Observability ที่เรียกได้ว่าครบทุกมิติ ไม่ว่าจะเป็นแง่

Business — เค้ารู้หมดว่า มีจำนวน Transaction เท่าไหร่แต่ละวัน, มี Transaction Type ไหนบ้าง เพราะแน่นอน แต่ละ Transaction ใช้ทรัพยากร ไม่เท่ากัน ไม่ว่าจะเป็น ถอนเงิน โอนเงิน แน่นอนรวมไปถึง Growth Rate ว่าแนวโน้มต่อไปจะเพิ่มเท่าไหร่

.

IT Perspective — นอกจาก CPU/Mem usage / I/O ที่ใช้ ซึ่งหลายๆที่มักจะมี ที่นี่ Monitor ได้หมด Response Time แต่ละ Execution (อย่างที่บอกแต่ละ Type ไม่เท่ากัน) ทั้งรูปแบบปกติ และ ผิดปกติ จำนวน Stat Error เค้าก็มีทั้งหมด ทั้ง Connection Error รวมไปถึงระดับการเสื่อมสภาพของ Hardware เพราะแน่นอน Hardware พังก็ทำให้ระบบพังได้

เมื่อรู้ตัวเองแล้วก็เริ่มเข้าสู่ Step ถัดไปในการแก้ปัญหา

.

ที่นี่ใช้หลัก Strategic Thinking เพื่อ Design โดยอย่างแรกคือกำหนด Characteristic ของระบบใหม่ที่อยากให้เป็น

.

ก่อนหน้านั้นเราต้องทำการแยกก่อนว่า Characteristic ของระบบนั้นมันมีในแง่อะไรบ้าง

1. Explicit Characteristic ที่เราต้องการ
2. Implicit Characteristic ที่ควรจะมี

แน่นอนว่า การ Horizontal Scale ไม่ใช่มีแต่ข้อดี ก็จะมีข้อเสียตามมา

หลายคนอาจจะนึกตามไม่ทัน ก็ดูเหมือนเพิ่มจำนวน มันก็น่าจะดูดีนี่นา

ในความจริงแล้ว เมื่อมีหลาย Tradeoff ที่จะต้องแลกมา เช่น

Consistency

ข้อมูลแต่ละตัว เราจะมั่นใจได้อย่างไรว่ามันเท่ากัน จากเดิมเรามีตัวเดียว พอมีหลายตัวก็ต้องมีการ Sync ให้เท่ากันเสมอ

Performance

ก็อาจจะดรอปลงเนื่องจากต้องมีการคุยกันระหว่างสองตัว หรือมี Layer ที่คั่นมา

Maintainability

การที่จะมีระบบใหม่มา Plugin ก็อาจจะเริ่มยากขึ้น ซับซ้อนขึ้น

สุดท้ายนี้ก็จะเป็นการ Tradeoff ระหว่าง Explicit Characteristic ที่อยากได้ กับ Implicit Characteristic ที่อาจจะลดลงไป

Trade Off ที่ต้องแลก เพื่อสิ่งที่ต้องการ

พอทุกอย่างเริ่ม Clear แล้วก็มาเริ่ม Draft Architecture ว่าต้องมี Characteristic อย่างไร

ก็ได้ออกมาเป็น High Level คร่าวๆ แล้วมาลง Detail อีกที

อย่างที่เค้าเกริ่นไว้ตอนต้น เนื่องจากเป็นโปรเจคขนาดใหญ่ กระทบทุกส่วน การที่มีการทำให้ชัดเจนทุกรายละเอียด จะช่วยทำให้ Detail ยังคงสื่อสารไปครบทุกส่วนได้โดยไม่ขาดหายไป

.

ถัดมาก็จะเริ่มลง Detail ว่าต้องอย่างไร อย่างที่บอก นี่เป็นสิ่งที่เราคิดว่าเราอยากได้อะไร

แต่ถ้าไม่มีการ Approach ที่ชัดเจน ก็จะสับสนในการ Action สุดท้ายมันก็จะไม่ออกมาแบบที่เราวางไว้

.

ซึ่ง Approach ของเค้าจะมีคลุมไปตั้งแต่ระดับ

Framework / Guideline

Infrastructure Design

Testing Approach

มีการแยก การทดสอบแบบไหนสามารถใช้คนเทสได้ แบบไหน ควรเขียน Script เพิ่มเติมมาเพื่อทดสอบ ทดสอบทั้ง Functional และ Nonfunctional

.

Approach นี้มีความน่าสนใจ เพื่อให้การทดสอบครอบคลุมทุก Scenario แท้จริงมากที่สุด ถึงกับสร้าง Layer เพื่อให้สามารถจำลองเคส Exception ได้

.

เช่น การ Response ช้า, พัง ซึ่งไม่ได้เป็น Layer ที่เอาขึ้นไปใช้จริง แต่มีไว้ทดสอบเท่านั้น

นอกจากนี้ Non functional Test ถ้าหลายคนนึก ก็อาจจะนึกถึง Load Test

แต่ที่นี่มีมากกว่านั้นมีจำลองไปถึงขั้นอุปกรณ์เจ๊ง ต้องทำอย่างไรต่อ เช่นอาจจะมี Auto Rerouting ไปที่ระบบอื่นไปก่อน เพื่อให้ภาพรวมยังคงทำงานต่อไปได้

Deployment Approach

สรุปภาพสุดท้ายออกมาเป็นดังนี้

นอกจากนี้สิ่งที่สำคัญที่เค้าเน้นย้ำเลยก็คือการ Review Code…

จะรู้ได้อย่างไรว่าโค้ดที่ทำออกมา Align กับ Characteristic ที่วางไว้ แน่นอนการที่โปรเจคใหญ่ขนาดนี้ ถ้าจะ Review Code กันขนาดนั้น ก็ไม่น่าจะไหว

ที่นี่มีการ Review Code แบบเป็นสิ่งสำคัญมาก เพื่อให้โค้ดที่ออกไป Align กับ Goal ที่วางไว้

นอกจากนี้เค้าก็มี Approach ที่เตรียมมาคือ

ทำ Interface ให้ Dev ที่อาจจะยังประสบการณ์น้อยกว่าเอาไปใช้ แล้วเบื้องหลังโค้ดนั้นก็อาจจะเป็น Dev ผู้ที่เข้าใจกว่าเป็นคนทำ

อย่างน้อย Code ที่เขียนก็จะถูก Lock ไปกับ Interface ที่วางไว้ ก็จะช่วย Control ระดับหนึ่ง

.

ซึ่งสุดท้ายแล้วสิ่งที่เลือกทั้งหมดนั้น อาจจะไม่ใช่สิ่งที่ดีที่สุด แต่เป็นสิ่งที่เค้าคิดแล้วว่า Work สำหรับเค้าและดีที่สุดในตอนนั้น เวลาผ่านไปอาจจะมี Option อะไรใหม่ๆขึ้นมาก็ได้

.

จบ Session เป็นที่เรียบร้อย เข้าสู่ Session ถัดไป

2. Test & Deployment Strategy

มาดู Timeline ที่เกิดขึ้นก่อน

ใช้เวลากว่า 180 วัน ซ้อม Promote ไป 21 รอบ Deploy จริงไป 8 ครั้งแบบ Phasing

หัวข้อนี้ก็เป็นอีกหัวข้อสำคัญ ถ้าเราออกแบบอย่างดี สุดท้ายไม่สามารถเอาระบบขึ้นได้จริง ก็จะเสียเปล่าทั้งหมดที่ทำมา เพื่อที่จะให้ขึ้นอย่าง Smooth จึงมีการซ้อมหลายครั้งมาก เพราะที่เกริ่นไว้คือ ไม่ Failed

.

การไปแตะ Production แต่ละครั้งย่อมคือความเสี่ยง จะรู้ได้อย่างไรระบบที่วางไว้ ยังทำงานได้แบบเดิม ย่อมต้องมีการ Automated/ Load / Performance Test ดูว่ายังทำงานได้แบบเดิม

.

นี่คือ 5 Principles หลักของการ Deploy ครั้งนี้

1. Reliability ยังคงสภาพเดิม หลังจากขึ้นไป ไม่ใช่จู่ๆ ทำบางอย่างได้น้อยลง
2. Transparency ผู้ใช้ไม่รู้ตัวเลยว่ามีการ Deploy ซึ่งที่นี่ใช้หลัก Blue/Green Deploy (Deploy ไปสองเวอร์ชั่น เมื่อมั่นใจแล้วก็จะ Switch มาให้คนใช้)
3. Reversibility ถอยได้เมื่อมีปัญหา
4. Incremental Change ขึ้นทีละเล็กๆ ไม่ Big Bang คุมปัญหาได้
5. Isolation อะไรที่ขึ้นมาใหม่ ต้องไม่มีผลกับระบบหลักจนกว่าจะ Verify ว่าเรียบร้อยแล้ว

สิ่งที่ Challenge จริงๆก็คือเพราะทำเป็นแบบ Phasing ต้องมีการวางแผนเนิ่นๆว่าใครจะทำอะไรใน Phase ไหน เพราะมีราวๆ 183 App ที่มาเชื่อมต่อ และระบบอื่นๆ

.

การสื่อสารไปยังผู้ที่กระทบว่าต้อง Dev ตอนไหน / QC ตอนไหน จึงเป็นเรื่องสำคัญในการสื่อสารแผนออกไป

.

ใน Approach ที่เค้าใช้ ใช้เป็น Blue-Green, Canary, Rolling, Phasing เพื่อให้ minimize ความเสี่ยงให้มากที่สุด

.

มีการขึ้นระบบไปทั้งหมดก่อน แล้วค่อยๆไปลองทดสอบจริงแบบ Pilot ด้วย Sandbox Account

.

อีกอย่างที่น่าสนใจคือมีการ Replay load ดูว่ายังทำได้พฤติกรรมเดิม เนื่องจากที่อธิบายในตอนต้นว่าเค้ามี Observability ที่ละเอียดมาก สามารถรู้ได้เลย ว่า Response Time แต่ละ Component ยังทำได้ประสิทธิภาพแบบเดิมมั้ย จนไปถึง Exception Case

นอกจากนี้มีสิ่งที่หลีกเลี่ยงไม่ได้เมื่อเลือกท่านี้ก็คือ

.

การอธิบายผู้เกี่ยวข้อง แน่นอนจากที่เกริ่นมา User ยากที่จะเข้าใจว่าทำไมต้องมาทดสอบอะไรขนาดนี้ (ซ้อมกันตั้ง 21 รอบ, Deploy 8 รอบ) ซ้ำยังต้องอธิบายการ Design ว่าต้อง Support เก่าใหม่ เนื่องจากเป็น Phasing ก็ต้องมีการทำความเข้าใจกันเยอะ กว่าจะเลือกทางนี้ได้

.

มาสู่เรื่องที่น่าสนใจทำไมซ้อมกันขนาดนี้ เฉลี่ย 4:1 เลยทีเดียว

ถ้าใครหลายคนเคย Deploy งาน ก็มักจะเจอปัญหาหน้างานที่คาดไม่ถึง

.

อาจจะเช่น OS บน Prod ไม่เท่ากับตอนที่ Dev มา, ลืมทำนู่นนี่ สุดท้ายเราก็จะด้นสดกันหน้างาน ก็อาจจะพลาดได้ การซ้อมเยอะๆ ก็จะเจอปัญหาแต่เนิ่นๆ

.

อีกทั้งเมื่อลองทำจริงแล้ว มันอาจจะสลับ Step กันได้ เพื่อ Optimize ขั้นตอน

.

แล้วเรายังต้องมีการซ้อมการถอย เพราะเมื่อเราเอาขึ้นไปแล้ว ก็จะมีคนที่รอตัดสินใจว่า Go, No Go Decision อยู่ ถ้าต้องถอย จะต้องทำ Step อะไรบ้าง

.

แน่นอนซ้อมขนาดนี้ ผู้เกี่ยวข้องอาจจะท้อแท้ ก็ต้องคุย จัดการดีๆ

Activity ทั้งหมดในการ Deploy ตลอดจนจบ

จบ Session เป็นที่เรียบร้อย เข้าสู่ Session ปิดท้าย ที่เป็นการ Discuss

Panel Discussion

Part นี้เป็นนำคำถามที่ส่งเข้ามา และในห้องมาตอบ หลายๆอันน่าสนใจมาก อาจจะจำคำถามเป๊ะๆไม่ได้ แต่ก็ขอจดที่จำได้ละกัน

Q1 : มีการวางแผน, Priority ได้อย่างไร ไม่ให้ Overbudget และ Timeline ได้ตามที่วางไว้ เพราะการ Delay ก็จะเป็น Cost ที่ระบบต้อง Freeze กับรู้ได้ไงจะต้อง Scale ถึงจุดไหนถึงจะเพียงพอ และการเลือก Tech Stack

A: เราต้องรู้ก่อนว่าระบบที่อยากได้หน้าตาแบบไหน

อะไรคือสิ่งที่ Must Have, Should Have, Optional อะไรไม่จำเป็น แล้วจะตามมาเองว่าทำอะไรก่อนหลัง

Scale ถึงจุดไหนพอ

ถ้าย้อนกลับไปตอนต้นก็จะเห็นอยู่ว่ามีระบบ Observability ที่ละเอียดมาก รู้หมดว่าแต่ละ Component ทำงานอย่างไร เชื่อมต่อกันอย่างไร, ตรงไหนพอไม่พอ มี Data Forecast Transaction แต่ละประเภททั้งหมด

โดยที่นี่มีทีมนั่งดูโดยเฉพาะเลย เพื่อให้ตอบสนองทันท่วงที

.

ส่วนการเลือก Tech Stack จริงๆ ที่จะมาก่อนคือ Characteristic ว่าอยากได้แบบไหน ก็จะ Lead สู่ Tech เอง

เช่น บางระบบ อาจจะไม่ได้ Critical ก็อาจจะไม่ต้องมี Switch เผื่อเจ๊ง ที่อาจจะทำให้ Overbudget ขึ้นเกินจำเป็น

.

ส่วนการเลือกภาษา ก็ดูจากในทีมเขียนอะไรกันเป็นบ้าง ไม่ได้เลือกจากว่ามันดี ตัวอย่างเช่น Rust ที่ได้ยินว่าสุดยอดมาก จัดการ Memory แต่เลือกใช้มา ทีมเขียนไม่เป็นเลย ก็จะทำให้ช้าลง หรือเขียนไปแล้วแย่กว่าเดิม

.

หรือเป็นด้าน Compatibility ที่สมมติเลือกภาษานึงมาแล้ว คนอื่นเอามาเชื่อมต่อไม่ได้ ต้องมาทำ Plugin เชื่อม สุดท้ายก็จะเกิดความเสี่ยง จากโปรแกรมที่ทำเพิ่มมา

.

นอกจากนี้ยังดูไปถึง Maintainability ที่สมมติเลือกภาษาที่ไม่ค่อยมีคนเขียน ก็จะหาคนมาเขียนต่อยาก เพราะส่วนใหญ่เป็นโปรเจคระยะยาว ต้องอยู่กับมันไปนาน

Q2: ได้ยินว่ามีระบบถึง 183 ระบบเชื่อมต่อ Monitor อะไรยังไง ใช้ Tool ตัวไหน

A: มีหมดแบบที่ทั่วๆไปทำ ทั้ง Grafana, Elastic Search, Prometheus

มีเก็บหมดตั้งแต่ Usage, Mem, การเชื่อมต่อ

แต่สิ่งที่สำคัญคือมีข้อมูลเพียบแล้วยังไงต่อ เพราะแต่ละระบบเชื่อมต่อกันยังไง

.

สมมติตรงนี้มีปัญหาต้องอย่างไร ที่นี่มีเหมือน หมอเวร คอย Monitor มานั่งดู สุดท้ายเมื่อเกิดปัญหา ข้อมูลเพียบแบบนี้ เค้า ดูไม่รู้เรื่อง ตัดสินใจต่อไม่ถูก เพราะคนที่ดูไม่ใช่ Developer

สิ่งสำคัญก็เลยคือการทำออกมาให้ดูเข้าใจได้ Grouping เป็นเรื่องๆ ที่จำเป็น ให้เห็นเป็นภาพว่า Component ไหนกำลังมีปัญหาอยู่นะ

.

มีตัว Diagram ที่ดูออกหมดว่า 183 แอพเข้ามาทางไหนบ้าง ไหลไปทางไหน วิ่งยังไง (น่า Visualize จาก Data ออกมาอย่างดี)

มีแม้กระทั่ง Playbook ว่าถ้าระบบมีปัญหาส่วนนี้ ต้องตัดอะไรทิ้ง ต้องทำนู่นนี่ เพื่อให้ระบบไปต่อได้ ซึ่งเค้าบอกว่ามี Playbook ทุกอันเลย ไม่มีด้นสด (อันนี้ส่วนตัวว่าน่าทึ่งมาก)

Q3: Challenge ที่เจอ และรับมือยังไง

A: ด้านการอธิบาย เนื่องจากโปรเจคสเกลใหญ่มาก การที่คนจะเห็นภาพเดียวกันหมด กว่า 50 แผนก และผู้เกี่ยวข้องอื่นๆ ซึ่งนี่เป็น Change ทาง IT

การทำจะทำให้ Business ยอมเข้าใจ ต้องพยายามเล่าให้คนอื่นเข้าใจได้ว่ากำลังจะทำอะไร

ซึ่งการเล่าเรื่องแบบเดียวกัน หลากกลุ่มผู้ฟัง ตั้งแต่ IT -> Non IT เป็นเรื่องที่ Challenge

.

ก็มีคำแนะนำมาว่า พยายามทำเป็น Diagram ไปอธิบาย ช่วยได้ เพราะเราเป็น Dev บางทีอะไรๆ มันจะอยู่ในหัวเต็มไปหมด คำพูดมันออกมาไม่ค่อยเข้าใจในการเรียบเรียง

Q4: คำแนะนำองค์กรอื่นถ้าจะมีทำระบบใหญ่แบบนี้

A: ไม่ว่าแพลนจะดีแค่ไหน ก็ไม่ค่อยจะตามแพลนอยู่แล้ว ต้องตั้งสติ ค่อยๆแก้ปัญหาไป

.

อย่างการทำอันนี้ ทุก Step ก็จะมีความเสี่ยง ก็จะมีพี่ที่คอยขจัด Risk ให้น้องๆที่คุมอีกที ในการไปอธิบายระดับที่สูงๆกว่า เพื่อให้น้องทำงานได้ง่ายขึ้น

.

ซึ่ง Plan ที่วางไว้มีการครอบคลุมหมดว่าสมมติโดนแทรก ต้องทำไง

เพราะเราไม่สามารถ Freeze ทุกอย่างไว้ 1–2 ปีได้ (ระหว่างทำ หลายๆงานจะไม่สามารถแก้อะไรเพิ่มได้ เพื่อให้การทดสอบเป็นไปอย่างราบเรียบ)

แน่นอนว่าอาจจะโดน Regulation บ้าง, หรือ Business มี Change ที่กำไรมาก เราก็ไม่สามารถหยุดได้

.

ถ้าจำเป็นจริงๆ งานก็ต้องมาเข้า Process เพื่อเทียบ Trade Off

เช่น สมมติทำอันนี้กำไร สมมติ พันล้าน แต่โปรเจคช้าลงไป เสียหายอาจจะ หมื่นล้าน ก็ต้องมาดูว่าคุ้มมั้ย

นอกจากนี้เมื่อทำก็มี Protocol ว่าต้องเทสเพิ่มให้ครบ ซึ่งก็จะมีค่าใช้จ่ายที่ตามมาเอามารวมด้วย (อาจจะเคยเทสผ่านบน V1, พอมา V2 อาจจะเจ๊งได้ต้องเทสใหม่ด้วย)

จริงๆยังมีอีกหลายคำถามที่น่าสนใจ แต่จะมีหลายๆคำแนะนำ ที่น่าสนใจ เช่น

.

สุดท้ายแล้ว Project ใหญ่แบบนี้ มันก็โอกาสที่จะไปถึงทางตัน ที่เราไปต่อไม่ได้ เราต้อง Step Back กลับมา ดูว่าปัญหาจริงๆ ที่เราจะแก้อยู่ตรงไหน

กล้าที่จะยอมรับ, กล้าที่จะ Step Back , กล้าที่จะพูดความจริงออกมา เพื่อให้เดินหน้าต่อไปได้

.

การบริหารทีม งานบางอย่างไม่ใช่ Engineer 10 คน ทำบ้านได้ 1 หลัง ถ้า 100 คนได้ บ้าน 10 หลัง งานบางประเภทไม่สามารถยัดคนเพิ่มไปมากๆ เพื่อให้งานเสร็จไวขึ้น ซึ่งใน Project นี้ ไม่ได้ใช้คนมากขนาดนั้น ยิ่งมากคนก็ยิ่งมากความ

.

การจัดทีม ไม่ใช่การรวม Superman 10 คนไปในทีมเดียวกันจะเป็นทีมที่ดี อาจจะต้องมีการกระจาย Superman เหล่านั้นไป ไม่งั้นอาจจะตีกันแทน การดูเคมี Match กันในทีม ก็จะทำให้ทีมมีประสิทธิภาพ

.

ที่นี่ใช้หลัก ทีมไหนเก่งอะไร ก็จะเอาไปให้ทำสิ่งที่ถนัด เพื่อให้ได้ประสิทธิภาพที่สุด

.

จบแล้วยาวมาก เป็น Session ที่ได้อะไรกลับไปเยอะ หลายๆอย่างจะไม่ลง Technical มากเพราะเป็นความลับ ก็เป็นอะไรที่น่าเสียดาย แต่ก็เข้าใจได้

ทั้ง Session กับ คำถาม ก็เลยไม่เจาะลึกมาก หรือ ตอบไม่ได้บ้าง บางคำถาม

แต่สุดท้ายแล้วสิ่งที่สำคัญก็คือหลักวิธีคิดมากกว่า พวก Technical สุดท้ายก็เปลี่ยนไปตามกาลเวลา

ขอบคุณ KBTG ที่จัด Session ดีๆนี้ขึ้นมา และขอขอบคุณผู้อ่านที่ตามอ่านมาจนถึงขนาดนี้ :)