ในการเปลี่ยน tester จาก manual testing ไปทำ automation testing นั้น หลายๆ คนคิดว่ามันเป็นเรื่องง่าย ก็แค่เอาสิ่งที่ทำมาไปเขียนเป็น automation ก็จบแล้ว ปัญหาใหญ่ที่สุดก็คงหนีไม่พ้น coding

แต่ๆๆๆๆ มันเป็นวิธีคิดที่ผิดมาก เพราะจริงๆ แล้วการที่ tester จะปรับตัวเองไปเป็น automation นั้น มีสิ่งที่ต้องปรับเยอะมาก

เอาจริงๆ การเอา dev มาเพิ่มทักษะด้าน test น่าจะง่ายกว่าซะด้วยซ้ำ หลังจากนั่งครุ่นคิดเรื่องนี้มาหลายชั่วโมง

ผมได้สรุปสิ่งที่เรา “ควรรู้” ออกเป็น 6 ข้อ ที่ QA/Tester สาย automation ต้องรู้ก่อนที่จะออกแบบชุดการทดสอบ

1. Core business flow

สิ่งที่ tester หลายๆ คนติดกันเลย คือ ไม่สามารถเข้าใจ business flow ได้ ซึ่งในทีนี้เราพูดถึงการเข้าใจสิ่งที่ user ต้องการทำให้เสร็จ (Job to be done ของ user)

หลายๆ ครั้งเราจะพบว่า tester มันจะออกแบบชุดการทดสอบแบบที่อ้างอิงตามหน้าจอซึ่งชุดการทดสอบแบบนั้นมันใช้กับ manual test ไม่เหมาะกับการนำไปใช้กับ automation testing ได้ เพราะรายละเอียดที่จะทดสอบมันไม่เพียงพอ และ ต้องเสียเวลามาแยกส่วนต่างๆ ออก เพื่อเอาไปใช้กับ automation test อีก

เราจึงมักพบว่า developer มักจะคิดชุดการทดสอบสำหรับ automation ใน level unit, component, และ integration เอง ซึ่งเหมือนจะดี แต่ถ้าชุดการทดสอบมันไม่ relate กัน มันก็จะมีปัญหากันอีก และ ตรวจสอบได้ยากขึ้น

สิ่งที่ควรระวังในการออกแบบชุดการทดสอบ หรือ ระบบ โดยอ้างอิงจากหน้าจอ คือ เราอาจจะหลุดพวก business condition ได้ เพราะสิ่งเหล่านั้นจะถูก wrap ไว้บนหน้าจอเดียว มันเลยค่อนข้างเสียเวลาที่ทีมพัฒนาจะต้องมานั่งแกะ business condition ใหม่อีกรอบ

2.System Flow

ในการทำ automation testing เป็นไปไม่ได้เลยที่ tester จะปฏิเสธว่าจะไม่ทำความเข้าใจการทำงานของระบบ (หลีกเลี่ยงเรื่องเทคนิคคอล) เพราะก่อนที่เราจะคิดการทดสอบออกมาได้เราจำเป็นต้องรู้ก่อนว่าระบบของเราทำงานยังไง

• user flow หลัก คือ อะไร
• data วิ่งยังไง
• condition เป็นยังไง
• error อะไรที่เกิดขึ้นได้บ้าง

เช่น:

login → call API → validate → return token → call service อื่น

เราต้องรู้สิ่งเหล่านี้เพราะ เราต้องเอาไปใช้ในการออกแบบ end to end testing และ หา critical path ที่จะเกิดขึ้น

3. System boundary

เราจำเป็นต้องรู้ว่า ส่วนที่เราจะทดสอบนั้น:

• มี service อะไร คือ ของเรา
• ใช้ data storage อะไร (เช่น database เป็น postgresql, และ เก็บข้อมูลแคชบน redis)
• อะไรเป็น 3rd party ทั้งที่เป็นของภายในเองและภายนอก (เช่น payment, API อื่น, pub/sub, file storage)

สิ่งนี้สำคัญมาก เพราะ เรา control ไม่ได้ทุกอย่าง, ต้อง mock / stub ให้ถูกจุด ถ้าหากเราพยายามทำให้ทุกอย่างมันทดสอบได้ automation test ของเรา จะซับซ้อนเกินไปจนยากในการทดสอบ (ถ้าทำ automation testing ไม่ได้ก็ผลักจุดนั้นไปทำ manual testing)

การที่รู้ภาพรวมเหล่านี้จะช่วยให้เรารู้ว่า:

• ต้อง mock ตรงไหน
• เลือกรูปแบบของการ mock
• test แค่ไหนถึงจะพอ

tester ไม่จำเป็นต้องรู้ code แต่ต้องรู้ว่า ในระบบนี้ อะไรคุยกับอะไร และ มี dependency อยู่ตรงไหนบ้าง

4.Data flow

ไม่ว่าจะ Core business flow และ System Flow จะเห็นว่ามีการพูดถึงเรื่อง data flow ด้วยเสมอ เพราะมันเป็นตัวบอกให้เรารู้ว่า:

• data เข้ามาจากไหน → ผ่านอะไร → ส่งต่อไปที่ไหน
• จุดไหน transform / validate
• state เปลี่ยนยังไง

ถ้าไม่เข้าใจตรงนี้ test จะมั่วทันที

เพราะในการทำ automation ที่ดี เราจะต้องจับตรงนี้ให้ได้ เพราะมันจะทำให้เรา scope ได้ว่าชุดการทดสอบของเราจะ cover ถึงไหน และเอาไปใช้กับการทดสอบ level ไหนได้บ้าง

เช่น

• API test
• contract test

5. จุดเสี่ยง (Risk-based thinking)

สิ่งที่ tester แบบ manual test มันจะทำเสมอ คือ การหา bug ให้ได้เยอะที่สุด ไม่ว่า bugs เหล่านั้นจะยิ่งใหญ่หรือเล็กน้อยเพียงใด ซึ่งเป็นแปลก เพราะถ้าเราให้การทดสอบเป็น Quality gate แล้ว + การทดสอบตามหลัง (Defensive) การหา bug ให้เยอะที่สุดจึงเป็นเรื่องที่ make sense (มั่งนะ)

ในทางกลับการ การออกแบบชุดการทดสอบก่อน (Test first) เราจะไม่ได้เน้นที่การออกแบบชุดการทดสอบให้เยอะที่สุด แต่เราจะโฟกัสที่ว่า ชุดการทดสอบของเราเพียงพอหรือเปล่า และไม่ใช่ทุกที่จะสำคัญเท่ากัน

ดังนั้นเราต้องถามตัวเองเสมอว่า:

• ถ้าพัง จุดไหน impact สูงสุด?
• feature ไหนทำเงินจริง?
• flow ไหน user ใช้เยอะ?

เราต้องซึ่งในมุมของการ develop ก็เช่นเดียวกัน เราเรียกสิ่งนี้ว่า design by failure หมายถึง ออกแบบระบบให้พังอย่างตั้งใจ รู้แล้วว่าจุดไหนจะพัง และ เราจะ handle error นั่นยังไง

ในมุมของ tester ก็เหมือนกัน เราต้องรู้เหมือนกันว่า ชุดการทดสอบของเราจะ cover จุดไหนบ้าง และจุดไหนที่เราจงใจปล่อยให้มัน error เพื่อให้ effort ที่ใช้มัน align กับ risk

เราจะชี้ได้ว่า นี่จุดนี้ คือ ที่ “ต้องทำ automate test”

6.จัดกลุ่มการทดสอบ

ถ้าเรารู้ภาพรวมจริงๆ แล้ว เราจะตัดสินใจได้ว่า อะไรควรเป็น automation และ อะไรควรเป็น manual

เพราะในการทดสอบแล้ว การที่จะทำให้ระบบเป็น 100% automation แทบเป็นไปไม่ได้เลย ดังนั้นเราจำเป็นที่จะต้องระบุให้ได้ว่า:

• อะไรควรเป็น Unit test
• อะไรควรเป็น API test
• อะไรควรเป็น E2E
• อะไรควรเป็น Manual test

จาก 6 ข้อที่กล่าวมา จะเห็นได้ว่า เราไม่ได้แค่ออกแบบชุดการทดสอบแล้ว แต่เราต้องเข้าใจ Business, System, และ Test เราถึงจะสามารถออกแบบวิธีการทดสอบออกมาได้มีประสิทธิภาพ ไม่ใช่แค่แปลงจาก manual testing เป็น automation testing

ความล้มเหลว (Failures) ในระบบไม่ใช่เรื่องผิดปกติอะไร มันเป็นสิ่งที่เกิดขึ้นตามธรรมชาติของระบบที่ซับซ้อน

การออกแบบที่ดี คือ การจัดการกับความล้มเหลวให้ปลอดภัย และ จำกัดผลกระทบ (blast radius) มากกว่า การพยายามป้องกันไม่ให้เกิดขึ้นเลย

บทความนี้เรามาดูกันว่า การทำระบบให้ยังอยู่รอดบนระบบที่เป็นแบบ distributed ต้องคำนึงถึงอะไรบ้าง

ตามภาพนี้ Resilience Patterns มีอยู่ด้วยกัน 8 patterns คือ

• Circuit Breaker: ป้องกันการล้มเหลวแบบต่อเนื่อง โดยหยุดการเรียก dependency ที่ล้มเหลวชั่วคราว
• Retry with Backoff: การ retry ต้องมี exponential backoff + jitter เพื่อหลีกเลี่ยง retry storm และต้องออกแบบ API ให้ idempotent
• Timeouts: เป็น safety net ที่มักถูกละเลย ต้องตั้งค่าให้สอดคล้องกับ SLA ไม่ใช่ยืดเวลาจนทำให้ระบบเสียหายหนักขึ้น
• Bulkhead Isolation: แยก resource/thread pool เพื่อไม่ให้ dependency ที่ช้าทำให้ critical path เช่น checkout ล้มไปด้วย
• Rate Limiting: ป้องกัน traffic surge ที่ทำให้ระบบ collapse โดยใช้ token bucket, leaky bucket หรือ fixed/sliding window
• Fallback Mechanisms: ให้ระบบตอบสนองแบบ graceful เช่นใช้ cache หรือ default response แต่ต้องมีการสังเกตและวัดผล ไม่ใช่ fallback ถาวร
• Dead Letter Queues (DLQ): เก็บข้อความที่ process ไม่ได้ เพื่อไม่ให้ pipeline ค้าง และสามารถ replay/monitor ได้
• Graceful Degradation: จัดลำดับความสำคัญของฟีเจอร์ (Tier 1–3) เพื่อให้ core business เช่น checkout ทำงานได้แม้ฟีเจอร์เสริมจะล้ม

เราไปลงรายละเอียดแต่ละตัวกัน

1.Circuit Breaker — การควบคุม/การจำกัดการล้มเหลว

Circuit breaker ปกป้องระบบของเราจากการเรียกใช้งาน dependency ที่ล้มเหลวซ้ำๆ

หากไม่มี circuit breaker จะเกิดเหตุการณ์นี้:

• Service A เรียก Service B
• Service B เริ่มทำงานช้าลง
• Threads ใน A เริ่มรอ
• Thread pool เต็ม
• Requests เริ่มค้างในคิว
• Latency พุ่งสูง
• Service A ใช้งานไม่ได้
• จากนั้น upstream services ก็ล้มเหลวตามไปด้วย
• Dependency ที่ช้าเพียงตัวเดียวกลายเป็นการล่มทั้งระบบ

Circuit breaker จะตรวจสอบอัตราความล้มเหลว และ latency เมื่อเกิน threshold ที่กำหนด มันจะ “เปิด” และหยุดการเรียกใช้งานต่อไปชั่วคราวตามเวลาที่ตั้งไว้

ทำไมสิ่งนี้จึงสำคัญทางเทคนิค

• ป้องกันการใช้ thread pool จนหมด
• ลดแรงกดดันต่อ service ที่ไม่พร้อม (กำลัง down หรือมีปัญหา)
• เปิดโอกาสให้ service ฟื้นตัว
• ทำให้การล้มเหลวเกิดขึ้นเร็วแทนที่จะรอ timeout ช้า ๆ

การล้มเหลวแบบเร็ว (fail fast) มักปลอดภัยกว่าการ timeout ช้า ๆ

Engineering considerations

ข้อควรพิจารณาทางวิศวกรรม เช่น

• กำหนด threshold ของความล้มเหลว (โดยอาจจะกำหนดจาก เปอร์เซ็นต์ หรือ จำนวนจริงก็ได้)
• แยก circuit breaker ของ dependency แต่ละตัว
• ติดตามสถานะ open/half-open เป็น metrics
• ใช้ร่วมกับ timeouts (circuit breaker ที่ไม่มี timeout = ไร้ประโยชน์)

Circuit breaker ไม่ใช่ตัวเลือก แต่เป็น เครื่องมือเอาตัวรอด ในระบบที่เป็น synchronous จะได้ไม่ลากกันช้า หรือ ล่ม

2.Retry with Backoff — Controlled Persistence

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

ลองนึกภาพดูว่า ถ้ามี request ล้มเหลว 1,000 ครั้ง และแต่ละอัน retry ทันที เราจะเพิ่ม traffic ไปยัง service ที่กำลังมีปัญหาเป็น 2 เท่า

ยินดีด้วย เราได้ปลดล็อค Achievement — สร้าง Retry storm สำเร็จแล้ว 😂

พฤติกรรมการ retry ที่ควรจะเป็น

• ใช้ exponential backoff (เพิ่มเวลารอแบบทวีคูณ)
• เพิ่ม jitter เพื่อป้องกันการ retry พร้อมกัน
• ตั้งค่า ขีดจำกัดสูงสุด ที่รับได้
• ใช้ร่วมกับ timeouts
• ทำให้ operation เป็น idempotent (เรียกซ้ำแล้วผลลัพธ์ไม่เปลี่ยน)

ทำไม idempotency ถึงสำคัญ

ลองคิดดูว่า ถ้าเรา retry การเรียกชำระเงินโดยไม่มี idempotency key ที่บอกว่า request นี้เป็นการเรียกซ้ำ เราอาจเรียกเก็บเงินซ้ำ 2 ครั้งก็ได้ (หรือมากกว่านั้น)

การ retry เป็นเหมือนการเปลี่ยนรูปแบบของการเรียก API ดังนั้นเมื่อเรานำเอา retry มาใช้ เราต้องออกแบบ API ให้รองรับมันด้วย

ควรใช้ retry เมื่อไหร่

• ปัญหาเครือข่ายชั่วคราว
• ข้อผิดพลาด 5xx จาก dependency
• กรณี timeout

ไม่ควรใช้ retry

• ข้อผิดพลาดจากการตรวจสอบข้อมูล (validation errors)
• การละเมิด Business rule (Business rule violations)
• ความล้มเหลวที่เป็น deterministic (ความล้มเหลวแบบกำหนดได้ หรือ รู้อยู่แล้วว่ามันจะล้มเหลวแน่นอน)

3.Timeouts — เข็มขัดนิรภัยที่มักถูกละเลย

สิ่งที่ถูกละเลยที่พบมากที่สุดมากที่สุดในการทำระบบ distributed ไม่ใช่เรื่องการ scale

แต่ คือ การไม่มีการตั้งค่า timeout

เมื่อ thread รอการตอบกลับแบบไม่จำกัดเวลา มันจะบล็อก resource
ถ้าเกิดขึ้นพร้อมกันหลายร้อย request จะนำไปสู่ thread starvation

ให้มองว่า Timeouts คือ การกำหนดว่าเรายอมรอได้นานแค่ไหน

Engineering depth

ในทางเทคนิคอลมี timeout อยู่หลายประเภท เช่น

• Connection timeout
• Read timeout
• Write timeout
• Total request timeout

แต่ละประเภทมีหน้าที่ต่างกัน ซึ่งถ้าเราต้องทำในส่วนไหนก็ไปลงรายละเอียดในส่วนนั้นได้

ความผิดพลาดที่พบบ่อย

การตั้งค่า timeout ไว้สูงมาก เพราะ ไม่อยากให้มันล้มเหลว

วิธีนี้เป็นเพียงแค่การ เลื่อนเวลาล้มเหลวออกไป และมันมักเพิ่มความเสียหายมากกว่าเดิมด้วย

โดยทั่วไปแล้ว การกำหนด Timeout จะต้อง น้อยกว่าค่า SLA ของ upstream
ถ้า API ต้องตอบกลับภายใน 300ms การตั้ง timeout ของ dependency ไว้ 5 วินาทีมันไม่สมเหตุสมผล

Timeouts คือ การบังคับให้มีวินัยในการออกแบบระบบ

4.Bulkhead Isolation — การปกป้องเส้นทางที่สำคัญ

บนเรือรบ bulkhead ใช้เพื่อป้องกันไม่ให้น้ำท่วม จนทำให้เรือทั้งลำจมลงได้

ในระบบ distributed การทำ bulkhead ใช้เพื่อป้องกันไม่ให้ component ที่ล้มเหลวเพียงตัวเดียวใช้ resource ร่วมจนหมด

ถ้าไม่มีการแยก (isolation)

• Dependency ที่ทำงานช้าจะใช้ threads ทั้งหมด
• ฟีเจอร์ที่สำคัญจะไม่สามารถใช้งานได้
• Background tasks จะต้องแข่งกับ request ของ user

Implementation techniques

• แยก thread pool ต่อ dependency
• ใช้ connection pool แยกเฉพาะ
• กำหนด resource quota
• แยก compute class ในสภาพแวดล้อม containerized

Real-world scenario

สมมติว่า recommendation engine ของเราทำงานช้า

ถ้ามันใช้ thread pool ร่วมกับ checkout ฝั่งของ user จะไม่สามารถทำการซื้อได้

ซึ่งสิ่งนี้ไม่ใช่ปัญหาด้าน performance แต่มัน คือ ปัญหาด้าน Architecture

ดังนั้น Bulkhead จะเป็นตัวบังคับให้เกิดการจัดลำดับความสำคัญ (prioritization)

5.Rate Limiting — การป้องกันการพุ่งขึ้นของ Traffic

นอกจากปัญหาภายในแล้ว ระบบยังต้องป้องกันปัญหาจากภายนอกได้ด้วย ซึ่งสิ่งที่พวกเรารู้จักกันดี คือ ปัญหาการพุ่งขึ้นของทราฟฟิก (traffic spikes)

ซึ่งปัญหานี้เกิดขึ้นได้หลายสาเหตุ เช่น

• จำนวนผู้ใช้งานเพิ่มขึ้น
• ระบบช้า ทำให้เกิดการเรียกใช้งานซ้ำๆ จากฝั่ง user
• กิจกรรมทางการตลาด เช่น การจำกัดสิทธิ์/เวลา
• โดนโจมดีด้วย DDoS

หากไม่มีการจำกัดอัตราการเรียกใช้งานไว้ (rate limiting)

• CPU พุ่งสูง
• ความกดดันต่อหน่วยความจำเพิ่มขึ้น
• การเชื่อมต่อฐานข้อมูลเต็ม
• Latency ลดลงแบบ exponential

จำไว้ว่า Rate limiting คือ การควบคุมปริมาณการรับเข้าของระบบ

Engineering decisions

• Fixed window vs Sliding window
• Token bucket vs Leaky bucket
• Global vs Per-user limits
• Gateway-level vs Service-level enforcement

Rate limiting ไม่ได้มีไว้แค่ป้องกันการใช้งานที่ผิดวัตถุประสงค์ (abuse prevention)
แต่มัน คือ การปกป้องขีดความสามารถของระบบ (capacity protection)

ให้ระบบเสถียรภายใต้โหลดบางส่วน (ที่จำกัด) ดีกว่าการปล่อยให้ระบบล้มเหลวจากโหลดจนเต็ม

6.Fallback Mechanisms — การออกแบบเพื่อความเป็นจริงที่ไม่สมบูรณ์แบบ

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

Fallbacks ช่วยให้ระบบมีพฤติกรรมทางเลือกเมื่อ dependency เกิดล้มเหลว โดยเราสามารถทำได้หลากหลายวิธี

ตัวอย่าง

• ให้บริการข้อมูลที่ cache ไว้
• ส่งคืนค่า configuration เริ่มต้น
• ซ่อน component ที่ไม่จำเป็น
• ให้ response แบบบางส่วน

คุณสมบัติที่ Fallbacks ควรมี

• Observable (สามารถสังเกตได้)
• Measurable (สามารถวัดได้)
• Temporary (เป็นการชั่วคราว)

Fallbacks คือ การสร้าง ประสบการณ์ที่ราบรื่น (graceful experience) ไม่ใช่การปกปิดความล้มเหลวของระบบแบบถาวร (ซึ่งไม่มีใครทำกัน)

7.Dead Letter Queues (DLQ) — การจัดการข้อความที่ไม่สามารถประมวลผลได้

ในระบบ event-driven จะมีบางข้อความที่เกิดการล้มเหลวในการประมวลผล

ถ้าเรา retry ไปเรื่อยๆ มันจะเกิด

• การบล็อก partitions
• ทำให้ข้อความอื่น ๆ ล่าช้า
• สร้างลูปที่ไม่มีที่สิ้นสุด

ดังนั้นเมื่อเรา retry ไปถึงจุดหนึ่ง เราจำเป็นต้องหยุดการทำงานตัวนี้ ซึ่งเราจำเป็นต้องจัดการกับงานที่หยุดทำตรงนี้ด้วย

ซึ่งเรานำ Dead Letter Queue มาเพื่อใช้ในการเก็บข้อความที่เกินจำนวนครั้ง retry ที่กำหนดไว้

Engineering practices

• เก็บ metadata ของสาเหตุความล้มเหลว
• ทำ replay mechanisms
• ติดตามปริมาณข้อความใน DLQ
• หลีกเลี่ยงการสะสมแบบเงียบๆ (silent accumulation)

DLQ เป็นการป้องกันไม่ให้ pipeline เป็นอัมพาต ซึ่งมันเป็นสิ่งจำเป็นในสถาปัตยกรรมที่ใช้ Distributed Streaming (อย่าง Kafka) หรือ ระบบที่ใช้ queue

8.Graceful Degradation — ปกป้อง Core Business

Graceful degradation คือ การจัดลำดับความสำคัญทางสถาปัตยกรรม ไม่ใช่ว่าฟีเจอร์ทั้งหมดจะมีความสำคัญเท่ากันหมด

ลองนึกดูว่า

• ถ้า recommendation ล้มเหลว checkout ต้องยังทำงานได้
• ถ้า analytics ล้มเหลว การประมวลผลคำสั่งซื้อยังต้องดำเนินต่อไป

เห็นไหมว่าแต่ละตัวความสำคัญไม่เท่ากัน บางอย่างล้มเหลวได้ บางอย่างแทบจะห้ามล้มเหลวเลย

หลักการออกแบบ (Design principle)

เราจะต้องแบ่ง Tier ของแต่ละ service ออกมา:

• Tier 1 (critical path)
• Tier 2 (important but optional)
• Tier 3 (nice-to-have)

เมื่อเกิดเหตุการณ์ resource ถูกจำกัด ให้ลด Tier 3 ก่อน เพื่อให้ resource แก่ Tier 1-2 ยังสามารถทำงานได้

สิ่งที่ต้องใช้

• Feature toggles
• Conditional rendering
• Independent service scaling
• Priority-based routing

จำไว้ว่า Graceful degradation ไม่ใช่การแก้ปัญหา runtime แบบชั่วคราว แต่มัน คือ การตัดสินใจเชิงสถาปัตยกรรม (design decision)

มันทำงานร่วมกันอย่างไร

ทั้ง 8 รูปแบบนี้ มันไม่ใช่เครื่องมือที่แยกออกจากกัน จริงอยู่ว่า มันไม่ได้ผูกกันแบบทั้งทำทั้งหมด เราจะเริ่มทำอันใดอันหนึ่งก่อนก็ได้

แต่จำไว้ว่าทั้งหมดนี้มันส่งเสริมกันทั้งหมด ลองคิดดูว่า ถ้าเกิดสถานการณ์ความล้มเหลวขึ้น ทั้งหมดนี้จะทำงานสอดคล้องกัน เช่น

• ฐานข้อมูลเกิด downstream จนทำงานช้า
• Timeout ทำงาน
• มีการ retry พร้อม backoff
• Circuit breaker เปิด
• Fallback ส่งคืนข้อมูลที่ cache ไว้
• Bulkhead ทำให้ checkout ยังคงใช้งานได้
• Rate limiter ป้องกันระบบจากการ surge
• เหตุการณ์ที่ล้มเหลวถูกส่งไปยัง DLQ เพื่อการวิเคราะห์
• ฟีเจอร์ที่ไม่สำคัญถูก degrade อย่างมีระดับ (gracefully)

เราเรียกสิ่งนี้ว่า Resilience choreography (การคืนชีพระบบ)

The Engineering Reality

ต้องเข้าใจก่อนว่า การสร้างความทนทาน (Resilience) จะทำให้ระบบของเราซับซ้อนมากขึ้น เนื่องจากเราจะต้องเพิ่มส่วนต่างๆ เข้าไป เช่น

• การตั้งค่ามากขึ้น
• Metrics มากขึ้น
• Edge cases มากขึ้น
• การเปลี่ยนสถานะ (state transitions) มากขึ้น

แต่การไม่ทำเลยมันแย่กว่ามาก

การมีกับไม่มีมันแตกต่างกันมาก

ระบบที่ไม่มี resilience patterns

• การล้มเหลวไม่สามารถคาดเดาได้
• สร้างการล้มเหลวต่อเนื่อง (cascading outages)
• ยากต่อการ debug
• ทำลายความเชื่อมั่นของผู้ใช้

ระบบที่มี resilience

• ล้มเหลวอย่างรวดเร็ว (fail fast)
• ฟื้นตัวได้อย่างรวดเร็ว (recover quickly)
• แยกความเสียหายออกจากกัน (isolate damage)
• รักษาความต่อเนื่องทางธุรกิจ (maintain business continuity)

Developer จะเริ่มออกแบบระบบจาก Success case แต่ Engineer ออกแบบระบบโดยเริ่มจาก Failure

ความผิดพลาดที่มักพบเมื่อนำ Resilience ไปใช้

แม้ทีมจะนำรูปแบบเหล่านี้ไปใช้แล้ว บ่อยครั้งพบว่า ทีมมักจะ implement ได้ไม่ดี หรือ ทำไม่ครบ

เช่น

• Circuit breakers ที่ไม่มี metrics ที่เหมาะสม
• Retries ที่ไม่มี jitter
• Timeouts ที่ตั้งค่าสูงเกินไป
• Bulkheads ที่ถูกแชร์โดยไม่ได้ตั้งใจ
• DLQs ที่ไม่มีการ monitoring
• Fallbacks ที่ซ่อน permanent degradation

Resilience patterns ต้องสามารถสังเกตได้ (observable) ถ้าเราไม่สามารถวัดสถานะของ breaker, จำนวนครั้ง retry, อัตรา timeout และขนาดของ DLQ ได้

เรากำลังทำงานแบบ blind (มองไม่เห็น/ตาบอด)

ระบบ distributed จะต้องล้มเหลวอย่างแน่นอน

คำถามไม่ใช่ว่ามันจะล้มเหลวหรือไม่ — แต่คือมันจะล้มเหลวอย่าง ปลอดภัยหรือไม่

Resilience patterns

• ลด blast radius (ขอบเขตความเสียหาย)
• ปกป้อง critical flows (เส้นทางสำคัญ)
• ปรับปรุง mean time to recovery (MTTR)
• รักษา ความเชื่อมั่นของลูกค้า

พวกมันไม่ได้กำจัดความซับซ้อนออกไป แต่พวกมัน จัดการกับมัน

Engineering maturity

สิ่งนี้จะเห็นได้ไม่ใช่จากพฤติกรรมของระบบในช่วงที่ทำงาน success แต่วัดจากพฤติกรรมของมันในช่วงที่เกิด ความล้มเหลวบางส่วน (partial failure)

เราจะต้องออกแบบเพื่อรองรับช่วงเวลานั้น

เพราะในระบบ distributed ช่วงเวลานั้นไม่ใช่เรื่องที่เกิดขึ้นได้ยาก

แต่มัน คือ สิ่งที่ หลีกเลี่ยงไม่ได้

สุดท้าย Resilience มันเป็น การตัดสินใจเชิงธุรกิจ เพราะในทาง technical การไม่มีมันก็ไม่ได้กระทบการทำงานในสถานการณ์ปกติ หรือ แม้แต่ตอนที่เกิดปัญหาขึ้นก็สามารถแก้ปัญหาแบบ manual ได้ในระดับหนึ่ง แต่การทำสิ่งเหล่านี้ มันช่วยรักษาความเชื่อมั่นของลูกค้า และ ลดผลกระทบจากความล้มเหลวที่หลีกเลี่ยงไม่ได้ เพราะฉนั้นมีไว้ดีกว่าไม่มี

เรามอง OpenClaw เป็นเหมือนคน เราสามารถบอกได้ว่า

• LLM เป็นเหมือนสมอง
• Line, Slack เป็นเหมือนปาก
• Skill, Tool เป็นเหมือนแขนขาให้ใช้งาน
• OpenClaw เป็นเหมือน Gateway ตัวที่เชื่อมทุกอย่างเข้าหากัน

การเลือกใช้ LLM (สมอง)

เราสามารถเลือกใช้งาน LLM ได้ตามความเหมาะสม

Cloud Models (ฉลาดมาก)

• Claude Sonnet, GPT-4o, Moonshot
• เหมาะสำหรับทำงานซับซ้อน งานวิเคราะห์ข้อมูล
• มีค่าใช้จ่ายสูง

Local LLM

• Ollama, Qwen
• เหมาะกับงานที่ต้องการความเป็นส่วนตัวของข้อมูล
• ข้อมูลไม่รั่วไหล (ต้องใช้ hardware แรง)
• ค่าใช้จ่ายถูกกว่า สามารถคุมค่าใช้จ่ายได้

วิธีการติดตั้ง

มีการติดตั้งได้หลายวิธี เช่น

• เครื่องส่วนตัว: ทดลองใช้งาน สามารถจัดการไฟล์ในเครื่องได้ แต่ต้องเปิดเครื่องตลอดเวลา
• cloud (vps): ออนไลน์ได้ตลอดเวลา จำกัดการเข้าถึงข้อมูลได้
• local powerhose: (องค์กร) ติดตั้งบน QNAP NAS ข้อมูลอยู่ที่ออฟฟิต

Recommend Spec

สำหรับ openclaw

• 2vCPUs
• 4 GB Ram
• Ubuntu 24.04 / Windown

การเชื่อมต่อกับ line oa จำเป็นต้องวาง vps ไว้ข้างนอก เนืองจาก line ต้องการ https

ความเสี่ยง

เราต้องเข้าใจก่อนว่าโปรเจคนี้มาจากงานอดิเรก เลยไม่ได้ออกแบบ หรือ ใส่ใจเรื่อง security และ bug ต่างๆ ดังนั้นเราจะเจอความเสี่ยงต่างๆ ได้

• การลบไฟล์สำคัญโดยไม่ตั้งใจ
• การส่งข้อมูลความลับออกไปภายนอก (Data Exfiltration)
• การถูกหลอกด้วยคำสั่ง (Prompt Injection)
• ไม่มีความเสถียร
• มีช่องโหว่

มาตรการความปลอดภัย

• Containerization: รันบน docker container เสมอ
• Human-in-the-Loop: ตั้งค่า exec.ask:"on" เสมอ เพื่อให้ขออนุมัติก่อนการรันคำสั่งอันตราย
• Least Privilege: ให้สิทธิ์เฉพาะโฟลเดอร์ที่จำเป็น

เครื่องมือตรวจสอบความปลอดภัย

openclaw doctor ตรวจสอบสถานะการเชื่อมต่อ

openclaw security audit แสกนการช่องโหว่ และ port ที่เปิดทิ้งไว้

วิธีติดตั้ง

เราสามารถดูวิธีการติดตั้งผ่านหน้าเว็บไซต์เขาได้เลย https://docs.openclaw.ai/start/getting-started โดยสามารถติดตั้งได้ทั้ง macOS, Linux และ Windowns

คำสั่ง

เราสามารถพิมพ์ openclaw ได้เลย

เริ่มต้นที่

Setup openclaw

ใช้คำสั่ง openclaw onboard เพื่อ setup openclaw โดยที่จะนำเราไปตั้งค่าการใช้งานเบื้องต้น

openclaw onboard

เลือก

• AI Provider
• Add API Key
• Select Default Model
• Select Channel: Telegram, WhatApp, Discord, Slack, Line etc.
  • จากให้ตั้งค่า chat ตามแต่ละตัวที่เราเลือก
• ติดตั้ง skills: จะแสดงเฉพาะ skills ที่ทาง openclaw approve แล้ว โดยเราสามารถ skip ไปก่อนได้
• การติดตั้ง AI ตัวอื่นๆ
• Enable Hooks: เลือกได้ว่าต้องการที่จะให้ openclaw ติดตั้งหน่วยความจำได้

หลังจากที่ setup เสร็จแล้ว เราสามารถเลือกได้ว่า จะเปิดมันบนไหน CLI, Web, Connect chat app ซึ่งใน workshop ใช้วิธีการ connect กับ Telegram bot

เริ่มบทสนทนากับ AI

เริ่มต้นเราจะต้องแนะนำตัวและสร้าง persona ของตัวเราและ openclaw เมื่อตั้งค่าเสร็จแล้วเราสามารถคุยกับ ai ได้เลย

Built-in Skills ที่น่าสนใจ

• skill-creator: เป็นตัว built-in อยู่แล้ว ไว้สำหรับสร้าง skills สำหรับ openclaw
• clawhub: เป็น registry ที่มีไว้สำหรับค้นหาและติดตั้ง skill
• summarize: สรุปข้อความยาวๆ / url / ไฟล์
• nano-pdf: สำหรับอ่านเอกสาร
• nano-bababa-pro: สร้างหรือแก้ไขรูปภาพ
• openai-image-gen: สร้างรูปภาพ โดยไปต่อกับทาง DALL-E
• openai-whisper (Local) / openai-whisper-api (Cloud): แปลงเสียงพูดเป็นข้อความ
• discord / slack: ส่งข้อความไปยัง channel ของ discord
• code-agent: เขียนโค๊ดได้หลายภาษา dubug refector
• github: สร้างและดู issue, จัดการ pull request
• mcporter: เชื่อมต่อ MCP Server จากภายนอก เรียกใช้ External tools ได้
• canva: แสดง html สดบน Mac/iOS/Android
• video-frames: ตัดเฟรมจาก video โดยใช้ timestamp
• blogwatcher: ติดตามเนื้อหาบล๊อคหรือเว็บไซต์อัตโนมัติ
• peekaboo: ดูหน้าจอ Device/oct ข้อความบนจอได้
• และอื่นๆ (มันมีให้เล่นเยอะเขียนไม่หมด) ดูเพิ่มเติมได้ ที่นี้

ถ้าเราต้องการดู skill ทั้งหมด ให้ใช้คำสั่ง

openclaw skills list

และยังมีคำสั่งอื่นๆ อีก 2 คำสั่ง คือ

• openclaw skills info : ดูรายละเอียดของแต่ละ skill
• openclaw skills check : เช็คสถานะของแต่ละ skill

สร้าง SKILL.md

เราสามารถสร้าง skill สำหรับให้ ai เรียกใช้งานได้เลย ส่วนฟอร์แมทก็จะเป็นการบอกว่าให้ทำอะไรได้บ้าง ไปเรียกจากที่ไหน และเงื่อนไขต่างๆ

---
name: trello
description: Manage Trello boards, lists, and cards via the Trello REST API.
homepage: https://developer.atlassian.com/cloud/trello/rest/
metadata: {"clawdbot":{"emoji":"📋","requires":{"bins":["jq"],"env":["TRELLO_API_KEY","TRELLO_TOKEN"]}}}
---

# Trello Skill

Manage Trello boards, lists, and cards directly from Clawdbot.

## Setup

1. Get your API key: https://trello.com/app-key
2. Generate a token (click "Token" link on that page)
3. Set environment variables:
   ```bash
   export TRELLO_API_KEY="your-api-key"
   export TRELLO_TOKEN="your-token"
   ```

## Usage

All commands use curl to hit the Trello REST API.

### List boards
```bash
curl -s "https://api.trello.com/1/members/me/boards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, id}'
```

### List lists in a board
```bash
curl -s "https://api.trello.com/1/boards/{boardId}/lists?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, id}'
```

### List cards in a list
```bash
curl -s "https://api.trello.com/1/lists/{listId}/cards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, id, desc}'
```

### Create a card
```bash
curl -s -X POST "https://api.trello.com/1/cards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "idList={listId}" \
  -d "name=Card Title" \
  -d "desc=Card description"
```

### Move a card to another list
```bash
curl -s -X PUT "https://api.trello.com/1/cards/{cardId}?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "idList={newListId}"
```

### Add a comment to a card
```bash
curl -s -X POST "https://api.trello.com/1/cards/{cardId}/actions/comments?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "text=Your comment here"
```

### Archive a card
```bash
curl -s -X PUT "https://api.trello.com/1/cards/{cardId}?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" \
  -d "closed=true"
```

## Notes

- Board/List/Card IDs can be found in the Trello URL or via the list commands
- The API key and token provide full access to your Trello account - keep them secret!
- Rate limits: 300 requests per 10 seconds per API key; 100 requests per 10 seconds per token; `/1/members` endpoints are limited to 100 requests per 900 seconds

## Examples

```bash
# Get all boards
curl -s "https://api.trello.com/1/members/me/boards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN&fields=name,id" | jq

# Find a specific board by name
curl -s "https://api.trello.com/1/members/me/boards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | select(.name | contains("Work"))'

# Get all cards on a board
curl -s "https://api.trello.com/1/boards/{boardId}/cards?key=$TRELLO_API_KEY&token=$TRELLO_TOKEN" | jq '.[] | {name, list: .idList}'
```

เห็นได้ว่า มันจะเป็นเหมือนการไปเรียกข้อมูลผ่าน API แล้วส่งให้ ai เอาไปใช้งานต่อ

Use Case

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

ความเร็วในการทำงาน ค่อนข้างใช้เวลาพอสมควร ดังนั้นแนะนำว่าให้ใช้กับงานที่สามารถรอได้ และไม่เหมาะกับการที่ใช้สำหรับการตอบลูกค้า (แต่ถ้าเร็วกว่านี้ก็สามารถนำไปใช้ได้เช่นกัน)

ตัวอย่างการใช้งาน เช่น

1. พนักงานต้อนรับบน Line OA
2. ผู้ช่วยจัดการ Stock
3. การทำงานเชิงรุก เช่น cronjob สรุปอีเมล์, สรุปข่าว เป็นต้น
4. สั่งเปิดเพลงบนเครื่อง personal
5. อ่านอีเมล์และปฏิทิน แล้วส่งสรุปมาให้เรา
6. และอื่นๆ อีกมากหมาย

ใน workshop มีการโชว์ของมากกว่านี้ แต่ไม่ได้เอามาใส่ในบทความนี้

References

• https://openclaw.ai
  
• https://clawhub.ai

เมื่อก่อนเวลาที่เราจะเขียน business plan เราจำเป็นต้องเขียนหลายหน้า ซึ่งจะแบ่งออกเป็นแต่ละบท ซึ่งมีรายละเอียดเยอะ จึงมีการคิด business plan แบบฉบับย่อให้เหลือ 1 หน้า เพื่อให้เราสามารถมองภาพรวมได้ในภาพเดียว สิ่งนี้ คือ Business model canvas นั่นเอง

Business Model Canvas

การทำธุรกิจเราต้องคำนึงถึงองค์ประกอบหลัก 9 หัวข้อ ทั้งหมดรวมกันจะได้ value proposition มันเป็นเครื่องมือที่ทำให้เราเข้าใจว่า ในภาคของธุรกิจที่เราต้องเข้าใจว่า อะไรคือปัจจัยภายในและภายนอกที่เราต้องทำในการดำเนินธุกิจ เป็นเหมือนพิมพ์เขียวให้เราออกแบบให้เรียบร้อยก่อนเริ่มทำธุรกิจ

1.Customer Segments

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

เช่น

ถ้าเราขายที่นั่งรถยนต์ส่วนบุคคล กลุ่มของลูกค้าก็จะเป็นบุคคลที่มีครอบครัว และต้องการรถยนต์สำหรับครอบครัว

ถ้าเราขายรถบรรทุก กลุ่มลูกค้าของเราก็อาจจะเป็บบริษัทที่ทำเกี่ยวกับขนส่งที่ต้องการซื้อรถบรรทุกเพื่อไปใช้ในงานของบริษัท

พยายามเขียนลงรายละเอียดของ customer segments ให้ละเอียด เพราะมันจะช่วยให้เรานำไปใช้ในหัวข้ออื่นๆ ได้ง่ายขึ้น

ซึ่งเราสามารถใช้ Value Propositon ในฝั่งของลูกค้ามาใส่ในนี้ได้เลย

2.Value Propositions

การเขียน Value Propositon ที่เราทำกันมา มันเป็นจุดเริ่มต้นสำหรับนำมาเขียน Business model canvas ตรงนี้แหละ

ต่อจากข้อ 1 ถ้าเรารู้แล้วว่า ลูกค้าของเราคือใคร งั้นเราจะออกแบบสินค้าหรือบริการยังไง ซึ่งตรงนี้เราสามารถนำ Value Propositon ในฝั่งซ้าย มาใส่ได้เลย และ สามารถเขียนต่อให้ละเอียดลงไปได้

3.Channels

ธุรกิจของเราจะไปถึงมือลูกค้าได้อย่างไร เช่น การส่งมอบอาหาร ช่องทางการส่งมอบอาจจะเป็น ผ่านหน้าร้าน, ผ่านร้านขายของ หรือ ผ่าน delivery เป็นต้น

4.Customer Relationships

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

จำไว้ว่า การหาลูกค้าใหม่ๆ นั้นมีต้นทุนที่แพงขึ้นเรื่อยๆ และต้นทุนที่แพงขึ้นเรื่อยๆ ทำให้หลายๆ ธุรกิจอยู่ต่อไม่ได้ อีกทั้งการวิ่งหาแต่ลูกค้าจะยิ่งทำให้คุณเหนื่อยมากขึ้น

ดังนั้น ธุรกิจที่ยั่งยืน คือ ธุรกิจที่รักษา customer relationship ตรงนี้ไว้ได้

5.Revenue Streams

เป็นช่องที่บอกว่า เรามีแผนจะทำเงินในธุรกิจจากอะไรบ้าง เช่น มาจากยอดขาย, subscription เป็นต้น ซึ่งตรงนี้เราสามารถไปหาข้อมูลได้เลยว่า ในโลกธุรกิจมีรูปแบบการทำงานอยู่กี่แบบบ้าง

ตัวอย่าง
long tail เป็นการขายสินค้าชิ้นแรกในราคาที่ต่อ หรือ ฟรี เพื่อที่จะเก็บเงินจากอุปกรณ์หรือบริการที่ต้องใช้ในระยะยาว เช่น เครื่องพิมพ์ ที่เราจะต้องซื้อหมึกยี่ห้อเดียวกันมาใช้

6.Key Partnerships

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

เช่น คนที่เราต้องซื้อวัตถุดิบ คนที่ต้องส่งของเรา

7.Key Resources

เรากำลังพูดถึงสิ่งที่เรามี และเป็นทรัพยากรของเราในการทำธุรกิจนี้ ซึ่งอาจจะเป็นชื่อเสียง brand ของเรา พนักงานในร้าน ช่องทางการขายของเรา

ต้องแยกระหว่าง partner กับ resource ให้ออก เพื่อปิดความเสี่ยงที่เกิดขึ้น

วิธีแยกง่ายๆ เลย คือ

อะไรที่เราสามารถควบคุมได้ คือ resource

อะไรที่เราควบคุมไม่ได้ คือ partner

พยายามแยกให้ออก เพราะความเสี่ยงที่สุด คือ การ supplier ของเรา ไม่ขายให้เราแล้ว (ปิดร้าน, ไม่ยอมขายให้, มีไม่พอ) มันจะทำให้ธุรกิจของเราอาจจะดำเนินไม่ได้เลย

8.Key Activities

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

เช่น ถ้าหากเราเป็นร้านอาหาร

• กิจกรรมหลัก ก็จะเป็นการทำอาหาร
• กิจกรรมอื่นๆ ก็มีเช่น การทำการตลาด การทำระบบสมาชิก

9.Cost Structure

จาก Business model canvas ทั้งหมดในช่องทางซ้ายมือนั้น มีต้นทุนอะไรบ้าง ก็เขียนให้หมดลงไปในช่องนี้

เช่น

• ค่าเงินเดือนพนักงาน
• ค่าเช่าออฟฟิต
• ค่าจ่างโรงงาน
• ค่าขนส่ง
• ค่ากิจกรรมทางการตลาด

ทั้งหมดนี้ ต้องเอาไปใส่ใน cost structure เพื่อให้เราสามารถเอาไปเทียบกับรายได้ที่เราได้มา มันคุ้มกันไหม

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

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

สุดท้ายเอา ตัวอย่าง business model canvas มาให้ดูกัน Link

หลายๆ คนที่อยู่ในวงการ software development คงจะเคยได้ยินคำว่า agile กันแล้ว และหลายๆ คน คงบอกใครๆ แล้วว่า ทีมหรือบริษัทของเราได้ทำงานเป็น agile แล้ว

เวลามีคนมาบอกอย่างนี้ ผมมันจะถามต่อเสมอว่า

Agile ของคุณมีหน้าตาเป็นอย่างไร?

และคำตอบที่ได้ก็มันจะเป็น scrum ซึ่งผมก็มักจะถามคำถามต่อว่า

scrum ของคุณหน้าตาเป็นอย่างไร?

ก่อนอื่นเลย ผมอยากบอกคุณเหมือนกับที่หลายคนอาจจะบอกคุณแล้ว ว่า

Agile ≠ Scrum

ชั่งเรื่อง scrum ไปก่อน ผมมีวิธีเช็คง่ายๆ ว่าทีมหรือบริษัทของคุณเป็น Agile Team หรือยัง นั่น คือ กลับไปหารากของมัน คือ Agile Manifesto และ Agile Principle

Agile Manifesto

เป็นค่านิยม หรือ ผมเรียกมันว่า Goal Setting ของ Agile ซึ่งเราจะมองกัน 4 เรื่อง คือ

1.Individuals and interactions over process and tools

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

2.Working software over comprehensive documentation

ข้อนี้ง่ายๆ software จะต้อง ready to production เท่านั้น ในการทำงานจริงที่เจอมา ส่วนใหญ่ ทำไม่ได้

หนักกว่านั้น คือ ตัดเอกสารที่จำเป็นออกไปด้วย เช่น System Design, Database design API Documents สิ่งเหล่านี้สร้างปัญหาให้ในอนาคตเมื่อต้องเปลี่ยนมือคนทำ

ถ้าหากยังไปถึง production ไม่ได้ ก็ต้องกลับมาวิเคราะห์ดูหน่อยว่าทำไมทีมหรือบริษัทของเรายังทำไม่ได้

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

3.Customer collaboration over contract negotiation

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

บ่อยครั้งที่พบว่า ตัวแทนลูกค้า มักจะให้ requirements ผิดพลาด เพราะฉนั้นข้อนี้ ควรบอกว่า Customer = Stakeholder = ทุกคนที่เกี่ยวข้องกับมัน คนจ้าง, หัวหน้า, และคนที่ต้องใช้งานมัน

4.Responding to change over following a plan

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

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

Health Checks 4 ข้อแรกแล้ว ทีมคุณยังเป็น Agile หรือเปล่า?

บอกไว้ก่อนว่าทั้ง 4 ข้อนี้เป็นเป็น Goal กว้างๆ ที่ให้เราได้ focus ในการทำงานเท่านั้น วิธีการทำจริงๆ มันจะมีรายละเอียดมากกว่านี้

ดังนั้น เราไปต่อกันเลย

Agile Principle

ในเมื่อเรามี goal แล้ว Agile ไม่ได้ใจร้าย ที่จะบอกแค่นั้นแล้วให้เราไปหากันเอง เขาจึงสรุป สิ่งที่เรียกว่า วิธีปฏิบัติ (Principle) ให้พวกเราได้ทำตามกันไว้ด้วย ซึ่งมีทั้งหมด 12 ข้อ

ลองเช็คกันดูหน่อยว่า เรามีกี่ข้อกัน สำหรับผมมีทั้งหมดถือว่า ยอดเยี่ยม แต่ถ้าได้ 8-10 ข้อ ถือว่า โอเคแล้ว เพราะบางอย่างมันปรับทันทีไม่ได้

1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

แปลว่า เราให้ความสำคัญสูงสุดกับการสร้างความพึงพอใจให้กับลูกค้าด้วยการส่งมอบซอฟต์แวร์ที่มีคุณค่าอย่างต่อเนื่องและรวดเร็ว

keyword: ความพึงพอใจ, ต่อเนื่อง, รวดเร็ว

ความพึงพอใจ
มัน คือ ส่งมอบสิ่งที่ตรงกับความต้องการจริงๆ ของลูกค้า ส่วนนี้เราจะมองได้ทั้งภาพระยะสั่นและภายปลายทาง

ภาพระยะสั่น คือ การส่งมอบแต่ละรอบการทำงาน ซึ่งขึ้นอยู่กับแต่ละบริษัท ลักษณะการทำงาน และความสามารถของทีมว่าใช้เวลาส่งมอบได้เร็วที่สุด คือ เท่าไหร่ ในระยะสั้น เราจะโฟกัสที่การหาความต้องการของลูกค้าจริงๆ ไม่ใช่แค่สิ่งที่ลูกค้าบอกในวันแรก

ภาพระยะยาว หรือ ปลายทาง คือ มองที่ปลายทางของโปรเจคนั้นๆ เลยว่า สิ่งที่ลูกค้าจะได้รับคือ software ที่ตรงกับความต้องการของลูกค้าจริงๆ ซึ่งมันอาจจะเป็นคนภาพกับตอนแรกที่ลูกค้าอยากได้เลย

2.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

ยินดีรับการเปลี่ยนแปลงความต้องการ แม้กระทั่งในช่วงท้ายของการพัฒนา ในกระบวนการแบบ Agile ช่วยใช้ประโยชน์จากการเปลี่ยนแปลงเพื่อสร้างความได้เปรียบในการแข่งขันให้กับลูกค้า

keyword: ยอมรับความเปลี่ยนแปลง, สร้างความได้เปรียบ

ข้อนี้ตรงตัวเลย ปัญหาจากการทำงานแบบ waterfall (ที่ถูกทำให้กลายเป็นผู้ร้าย) คือ เราจะยึดตามเอกสาร requirements ตั้งต้น ว่าเราคุยกันแบบไหน โดยที่ปิดไม่ให้สามารถเปลี่ยนแปลงได้ แต่สำหรับ agile แล้ว เราโฟกัสไปที่ high value ได้ประโยชน์ หรือ ได้เปรียบ ที่ลูกค้าจะได้รับ

สิ่งที่ต้อง trade-off กับการยอมรับเปลี่ยนนี้ คือ การที่เราจะไม่สามารถส่งได้ทั้งหมดตามที่ตกลงกันไว้ หรือ อาจจะเป็นเวลาที่เพิ่มขึ้น ซึ่งสิ่งเหล่านี้ต้องสื่อสารให้ลูกค้ารับรู้และรับทราบ เพราะถ้าไม่มีการเทรดออฟเรื่องเหล่านี้แล้ว ทีมจะถูกกดดันให้ทำทั้งหมดให้เสร็จภายใต้กรอบเวลาที่เป็นไปไม่ได้ สุดท้ายก็จะหลุดจากสิ่งที่ agile ต้องเป็นนั้น คือ การส่งมอบ working software (ของที่ใช้งานได้จริงมีประโยชน์จริงๆ ไม่ใช้ส่งได้แต่ใช้ประโยชน์จริงไม่ได้)

3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

ส่งมอบซอฟต์แวร์ที่ใช้งานได้จริงอย่างสม่ำเสมอ โดยมีระยะเวลาตั้งแต่สองสามสัปดาห์ถึงสองสามเดือน โดยควรเลือกช่วงเวลาที่สั้นกว่าเป็นหลัก

keyword คือ working software, บ่อย และ สม่ำเสมอ

ปัญหาใหญ่ที่มันเจอในข้อนี้คือ เรามันเซ็ตกรอบการส่งมอบงานตาม คนอื่น โดยไม่ดีความสามารถของทีมหรือบริษัทตัวเองว่าจริงๆ แล้ว เราใช้เวลาเท่าไหร่ ถึงจะส่งมอบ working software ได้

working software คือ ของที่พร้อมใช้งาน ประเมินง่ายๆ คือ ถ้าทีมบอกว่างานเสร็จแล้ว ให้ลองถามไปเลยว่า จะเอาขึ้นให้ลูกค้าใช้เลยได้ไหม ถ้าคำตอบ ว่า ต้องเตรียมนู่น ต้องทำนี่ก่อน ยังขาดอันนั้นอันนี้ แปลว่า ยังไม่ใช่ working software

เพราะฉนั้น ไม่ต้องกังวัล ถ้าหากการส่งมอบ working software จะใช้เวลา 1 เดือน เพราะนั้นคือ ความเร็วที่ทีมของเราทำได้ และเราค่อยปรับปรุงให้เร็วขึ้นในอนาคต

4.Business people and developers must work together daily throughout the project

ฝ่าย business กับ ทีมพัฒนา จะต้องทำงานร่วมกันทุกวันตลอดโครงการ ข้อนี้เป็นอะไรที่ง่าย แต่หลายๆ บริษัทก็ทำกันไม่ได้ เนื่องจากโครงสร้างองค์กร

keyword: ทำงานร่วมกัน, ทุกวัน

หลายๆ ครั้งที่เรามักจะเจอสถานะการณ์ตีกันระหว่าง business ที่อยากทำอะไรบ้างอย่าง กับ ทีมพัฒนา ที่พยายามบอกว่า มันทำไม่ได้

ปัญหานี้จบลงง่ายๆ ด้วยการมาคุยร่วมกัน และกำหนดเป้าหมายร่วมกัน

ซึ่งเราต้องยอมรับก่อนว่า

• business ไม่ได้เข้าใจ system ดีเท่าทีมพัฒนา
• ทีมพัฒนา ไม่ได้เข้าใจ business ดีเท่าทีม business

ดังนั้นการแชร์มุมมองของแต่ละฝ่ายร่วมกันจะทำให้การทำงานมีประสิทธิภาพมากขี้น

บางช่วงบางเวลา bussiness อาจจะทำ technical บางเวลา technical อาจจะนำ bussiness เราถึงจะได้ทีมและผลิตภัณฑ์ ที่ตรงกับความต้องการและใช้งานได้จริง

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

5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

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

keyword: แรงจูงใจ, สภาพแวดล้อม, เชื่อใจ

ข้อนี้มันเป็นเรื่องของ trust ของทีม โดยทั่วไปแล้ว หากเรามีทีมที่ไว้ใจได้ เรามักจะไม่ค่อยลงไปจัดการอะไรมาก และเรามักจะได้งานที่ดีออกมา

แล้วปัญหาส่วนใหญ่ มักเกิดจากการที่ทีมไม่สามารถสร้าง trust ให้ได้ ซึ่งมักเกิดจากการไม่สื่อสารสิ่งต่างๆ ให้กัน เช่น ปัญหาและอุปสรรคที่เจอ ความเสี่ยง หรือ feedback ต่างๆ

การที่ทีมขาด trust จะทำให้เกิดการ micro manage จากทาง bussiness ขึ้น และเมื่อมันเกิดขึ้นแล้ว มันจะกลายเป็นการตามงานในทันที และมันจะกลายเป็นสภาพแวดล้อมที่กดดัน แล้วแรงจูงใจจะหายไป

6.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

วิธีการถ่ายทอดข้อมูลที่มีประสิทธิภาพและประสิทธิผลมากที่สุดทั้งภายใน และ ภายนอกทีมพัฒนา คือ การสนทนาแบบตัวต่อตัว

keyword: ถ่ายทอดข้อมูล, face-to-face

ยอมรับเถอะว่า หลายๆ บริษัทที่ปรับมาให้พนักงานกลับไปทำงานแบบ on site ส่วนหนึ่งเป็นเพราะการสื่อสารที่ตกหล่น ไม่มีประสิทธิภาพ

การส่งต่อข้อมูลต่างๆ ที่มีประสิทธิภาพที่สุด คือ การคุยกันต่อหน้า เพราะมันสามารถสื่อสารได้ตลอดเวลา และคนอื่นๆ รับรู้ไปพร้อมกัน ต่อให้ไม่ได้เกี่ยวก็ตาม (กด mute ไม่ได้)

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

7.Working software is the primary measure of progress

ซอฟต์แวร์ที่ใช้งานได้จริง คือ ตัวชี้วัดความก้าวหน้าที่สำคัญที่สุด

keyword: ตัวชี้วัดที่สำคัญ, ใช้งานได้จริง

agile ให้ความสำคัญกับข้อนี้มาก สังเหตุได้ว่ามันจะแทรกอยู่ในหลายๆ ข้อเลย

โดยทั่วไปแล้ว เรานิยามคำว่า งานเสร็จ ไว้ยังไง เวลาที่ทีมพัฒนาบอกว่างานเสร็จ มันหมายถึง งานของเขาเสร็จ, งานของทีมเสร็จ หรือ งานขึ้นไปให้ลูกค้าใช้งานแล้ว

ถ้าหากงานเสร็จ หมายถึง การเขียน code เสร็จแล้ว สิ่งนี้ไม่อาจเรียกว่างานเสร็จได้ เพราะเมื่อถึงวันที่ต้องเอาไปให้ลูกค้าใช้งาน ทีมก็จะถูกดึงกลับมาให้เอางานชิ้นนั้นขึ้น production ซึ่งเป็น task สุดท้ายของ features นั้น ดั้งนั้น ไม่จะเรียกว่า งานเสร็จไม่ได้ ในเมื่อเรายังต้องกลับมาทำมันให้เสร็จจริงๆ

8.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

กระบวนการแบบ Agile ส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุน ผู้พัฒนา และผู้ใช้ควรจะสามารถรักษาจังหวะการทำงานที่คงที่ได้ตลอดไป

keyword: ความยั่งยืน, รักษาจังหวะ

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

ซึ่งเมื่อเจอสถานการณ์นี้ ทุกๆ ทีมมักเข้า โหมดเอาตัวรอด (ผมเรียกมันว่าอย่างนั้น) เพราะทุกคนจะละทิ้ง process ละทิ้งความละเอียด ละทิ้งการวางแผน เปลี่ยนเป็นการปั่นให้มันเสร็จ ทั้งๆ ที่เราควรจัดการให้มันอยู่ในจังหวะของเราและบริหาร scope แทน

สิ่งที่ต้องระวัง คือ ทีมมักจะถอดสมองแล้วทำงานตามสัญชาติยาน ซึ่งสิ่งที่นำมาซึ่งความผิดพลาดและผลลัพธ์ที่ส่งผลไม่ดีแก่ลูกค้ารวมถึงคนในทีมได้

9.Continuous attention to technical excellence and good design enhances agility

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

keyword: การให้ความสำคัญกับ technical และ design

ปัญหาใหญ่ๆ ที่หลายๆ ที่เจอคือ เมื่อเราทำงานเป็นรอบสั้นแล้ว เรามักเจอปัญหาเรื่องของการออกแบบไม่ทัน และสิ่งที่หลายๆ ทีมทำ คือ การตัดมันทิ้ง และให้คิดไปทำไป ซึ่งสิ่งที่ได้มา คือ software ที่ใช้งานได้ (มั้ง) และ technical dept

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

"จะเพิ่มอันนี้ ต้องไปแก้ตรงนั้นก่อน "

"จะทำอันนี้ ทำไม่ได้ ระบบไม่ได้ออกแบบมาให้ทำอย่างนั้น"

และ ประโยคอื่นๆ อีกมากมาย ที่ทำให้เราทำงานได้ช้าลง

10.Simplicity–the art of maximizing the amount of work not done–is essential

ความเรียบง่าย เป็น ศิลปะแห่งการลดปริมาณงานที่ไม่ต้องทำ และ เป็นสิ่งสำคัญยิ่ง

keyword: ความเรียบง่าย, ศิลปะ, การลดปริมาณงาน

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

สิ่งเหล่าน้ี แทบจะไม่จำเป็นเลย สำหรับ software ที่เรายังไม่รู้เลยว่าจะมีคนใช้งานจริงหรือเปล่า (ถ้ายังไม่มีคนใช้งาน)

ดังนั้นในช่วงแรกของการพัฒนาเราควรโฟกัสไปที่ working software ก่อน ที่จะไปสนใจ want ต่างๆ ที่อยากจะให้มันมี

แน่นอนว่า สิ่งนี้ไม่สามารถใช่ pattern เดียวกันทั้งหมดได้ มันเลยบอกว่าเป็นศิลปะยังไงละ

11.The best architectures, requirements, and designs emerge from self-organizing teams

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

keyword: ทีมที่จัดการตัวเองได้

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

การที่ต้องมีใครสักคนต้องมาค่อย assign งานให้ ต้องมาลงรายละเอียดงานให้ มันเป็นทีมที่ไม่มีประสิทธิภาพ และโดยทั่วไปเมื่อทีมเป็นแบบนี้ trust ของทีมก็จะน้อยลง

การที่ทีมคิดเองไม่เป็น ไม่พูด ไม่ต่อรอง ไม่สื่อสาร รับงานมาทำอย่างเดียว ไม่ส่งผลดีกับผลิตภัณธ์และบริษัทเลย

เพราะเราจะขาดคนช่วยคิด ช่วยบริหารจัดการงาน และขาดความเชื่อใจกันและกัน

12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

ทีมงานจะทบทวนวิธีการทำงานให้มีประสิทธิภาพมากขึ้นเป็นระยะ จากนั้นจึงปรับปรุงและแก้ไขพฤติกรรมให้เหมาะสม

keyword: ทบทวน, ปรับปรุง

การทบทวนและปรับปรุงการทำงานจะช่วยให้เราลดข้อผิดพลาดของงานและช่วยเพิ่มความสามารถในการทำงานให้ดีขึ้น

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

เพราะเฉพาะลองเช็คทีมของคุณดูว่าเป็นอย่างนั้นหรือเปล่า ถ้าใช่แสดงว่า คุณกำลังทำแค่พิธีกรรม ไม่ได้ปรับปรุงการทำงานจริงๆ

เอาหละจบทั้ง 12 ข้อแล้ว ได้กี่ข้อกัน แล้วแต่ละข้อทำได้ดีที่สุดแล้วหรือยัง หรือแค่มี แต่ยังไม่ได้เท่าที่ควรจะเป็น

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

Agile ไม่ใช่ Process หรือ เครื่องมือ อะไรทำนองนั้น จริงๆ แล้ว Agile เป็นเพียง Badge ที่บอกว่า ทีมของคุณเป็นทีมที่มีประสิทธิภาพที่สุดหรือยัง โดยทีมสามารถทำตาม checklist เหล่านี้ได้

การวิเคราะห์สถานการณ์ธุรกิจ เปรียบเสมือนการตรวจสุขภาพของธุรกิจ  ช่วยให้ผู้ประกอบการเข้าใจภาพรวมของธุรกิจ  จุดแข็ง  จุดอ่อน โอกาส  และอุปสรรค  ที่ธุรกิจกำลังเผชิญอยู่

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

SWOT Analysis

ในบทความนี้เราจะได้เรียนรู้การวิเคราะห์ธุรกิจจากการเขียน SWOT Analysis เราจะได้วิเคราะห์สถานการณ์ธุรกิจ  ทั้งการวิเคราะห์ปัจจัยภายใน (Internal Analysis) และการวิเคราะห์ปัจจัยภายนอก (External Analysis)

การวิเคราะห์ปัจจัยภายใน (Internal Analysis)

จะมุ่งเน้นไปที่การวิเคราะห์จุดแข็ง  จุดอ่อน  ทรัพยากร  และความสามารถของธุรกิจ  ข้อมูลเหล่านี้สามารถวิเคราะห์ได้จากแหล่งข้อมูลภายในองค์กร เช่น  งบการเงิน  รายงานผลประกอบการ  ข้อมูลทรัพยากรบุคคล  ข้อมูลลูกค้า  ข้อมูลคู่แข่ง เป็นต้น

โดยปัจจัยภายในนี้ เราจะวิเคราะห์ 2 มุม คือ Strenghts และ Weaknesses

จุดแข็ง (Strenghts)
เป็นเรื่องของภายในธุรกิจของเราว่า เรามีดีอะไร มีข้อได้เปรียบอะไรที่เหนือกว่าคู่แข็งของเรา เรามีอะไรที่เรามีแต่คู่แข่งไม่มี

จุดอ่อน (Weaknesses)
เป็นเรื่องของภายในธุรกิจของเราว่า เรามีจุดอ่อนอะไร อะไรที่คู่แข่งของเราทำได้ดี อะไรที่เราไม่มีแต่คู่แข่งมี เพื่อนำมาวิเคราะห์ว่า เราจะปรับปรุงอะไร หรือ จะมองข้ามอะไรไป (ไม่ไปแข่งด้วย)

การได้มาาซึ่ง 2 ข้อนี้ จะช่วยให้เราสามารถรู้ได้ว่าเราควรทำอะไร ควรทำการตลาดแบบไหน ควรปรับปรุง หรือ ขยี้เรื่องไหน ซึ่งมันจะเกี่ยวโยงกับเรื่องของ value proposition ที่เราต้องการส่งมอบคุณค่าให้แก่ลูกค้าของเรา เอาสิ่งเหล่านี้มาทำให้ลูกค้าอยากใช้ผลิตภัณฑ์ของเรา ไม่ไปใช้ของคู่แข่ง

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

การวิเคราะห์ปัจจัยภายนอก (External Analysis)

เป็นการมุ่งเน้นไปที่การวิเคราะห์โอกาส  อุปสรรค  เทรนด์  และสภาพแวดล้อมภายนอกที่อาจส่งผลต่อธุรกิจ  ข้อมูลเหล่านี้สามารถวิเคราะห์ได้จากแหล่งข้อมูลภายนอกองค์กร  เช่น  ข่าวสาร  บทความ  รายงานวิจัย  ข้อมูลเศรษฐกิจ ข้อมูลประชากร  ข้อมูลคู่แข่ง  เป็นต้น

โดยปัจจัยภายในนี้ เราจะวิเคราะห์ 2 มุม คือ Opportunities และ Threats

โอกาศ (Opportunities)
มีแนวโน้มหรือการเปลี่ยนแปลงในตลาดอะไรบ้าง ซึ่งเป็นการมองไปภายนอกเพื่อมองหาโอกาศใหม่ๆ ที่กำลังจะเกิดขึ้น ซึ่งโอกาศเหล่านี้จะไม่สามารถหาได้เลย ถ้าเราไม่ออกไปเปิดหูเปิดตา หรือ อ่านข่าว หาความรู้ ซึ่งเราต้องทำ SWOT Analysis บ่อยๆ

อุปสรรค์ (Weaknesses)
เป็นตัวที่ตรงข้ามกับโอกาศ คือ ส่งที่เรากำลังมองหาสิ่งที่ส่งผลร้ายต่อเรา เช่น การเกิดขึ้นมาใหม่ของคู่แข่ง กฏหมายเปลี่ยนไป เทรนผู้บริโภคที่เปลี่ยนไป เรามองว่าเป็นภัยคุกคาม

สิ่งเหล่านี้เป็นปัจจัยภายนอกที่เราไม่สามารถควบคุมได้ หน้าที่ของเราต้องมองหาว่า อะไรบ้างที่เป็นโอกาศที่เราต้องไปคว้า ผลลัพธ์ที่ดีขึ้น และ อะไรบ้างที่เป็นอุปสรรค์จะได้ระวังตัวไว้ก่อน

เรานำ SWOT Analysis มาใช้ยังไงได้บ้าง เช่น

• Strengths: โปรโมตจุดแข็งของเรา จัดกิจกรรมเพื่อดึงลูกค้ากลับมาซื้อซ้ำ
• Weaknesses: เพิ่มบางอย่างเข้าไป เพื่อขยายฐานลูกค้า อาจจะทำเป็นฤดูการก็ได้, เพิ่มการเทรนนิ่ง หามันให้เจอ แต่จะแก้ไขหรือไม่ก็ขึ้นอยู่กับเราเลย
• Opportunities: ขยายเวลาหรือพื้นที่เพื่อให้เข้าถึงลูกค้ามากขึ้น
• Threats: ออกแบบสินค้าหรือบริการที่แยกออกมา

สิ่งสำคัญให้การทำ SWOT Analysis คือ การทำบ่อยๆ โดยเฉพาะปัจจัยภายนอก ที่เราต้องหมั่นเช็คข้อมูล เพื่อให้สามารถปรับเปลี่ยนกลยุทธได้อย่างรวดเร็ว อาจจะเป็นทุกรายไตรมาส หรือ ทุกครึ่งปี หรือ ทุกปี ขึ้นอยู่กับเราเลย

วิธีหาไอเดียใหม่ๆ สำหรับคนที่ไม่รู้ว่าจะเริ่มหายังไง จริงๆ แล้วการหาไอเดียใหม่ๆ มี pattern ของมัน ซึ่งมีทั้งหมด 7 วิธี ซึ่งมาจากงานวิจัยของ McKinsey

1.การขายผลิตภัณฑ์ที่มีอยู่แล้ว ให้ลูกค้าปัจจุบัน

เป็นวิธีที่ง่ายที่สุดในการเริ่มต้นธุรกิจ ตรงไปตรงมาที่สุด และซับซ้อนน้อยที่สุด เพราะมันมี demand และ supply ที่เราเห็นอยู่แล้ว เช่น การขายกาแฟ, การขายเครื่องสำอาง, ร้านอาหาร เป็นต้น

มันเป็นการที่เรากระโดดเข้าไปในตลาดนี้ และเพิ่ม supply การขายมาอีก brand นึง

ซึ่งในตลาดนี้ เราต้องคิด value proposition ดีๆ เพราะตลาดนี้มีความต้องการของการซื้อและขายอยู่แล้ว การที่เราเข้าไปเท่ากับการเข้าไปแย่งลูกค้าจาก brand อื่นมา

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

2.การขายผลิตภัณฑ์ที่มีอยู่แล้ว ให้ลูกค้ากลุ่มใหม่ๆ

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

ตัวอย่าง

Nike ที่เริ่มต้นจากการทำรองเท้าวิ่ง ที่ผ่านมา nike ขายแค่รองเท้าวิ่งเท่านั้น ทีนี้ เมื่อ nike มองมาในตลาดข้างๆ ก็จะเห็นสินค้ากลุ่มอื่นๆ ที่มีความต้องการรองเท้าเหมือนกัน อย่างกลุ่มของคนเล่นสเก็ตบอร์ด ซึ่ง nike ก็มองว่า รองเท้าของเขาบางรุ่นก็ใส่เล่นได้นะ แต่ต้องปรับปรุงนิดหน่อย แต่ยังคงเอกลักษณ์ของ nike อยู่ Nike SB

3.สร้างผลิตภัณฑ์หรือบริการใหม่ กับตลาดที่ยังไม่เคยมีสินค้าเหล่านี้มาก่อน

เป็นการเปิดน่านน้ำใหม่เลย ลองมองมุมกลับ เพื่อมองหากลุ่มลูกค้าใหม่เลย ในข้อนี้ยังรวมไปถึงกลุ่มลูกค้าที่ยังไม่มีใครเข้าไปเป็นเจ้าตลาด

เช่น ในตลาดมีลิปสติกสำหรับผู้หญิงเยอะมากมายแล้ว แต่ถ้ามเรามองไปจริงๆ ผู้ชายก็ใช้ลิปสติกได้ เพื่อเป็นการรักษาริมฝีปากให้สุขภาพดี เราก็สามารถสร้างผลิตภัณฑ์สำหรับกลุ่มผู้ชายได้ เป็นต้น

4.เปลี่ยนวิธีการส่งมอบคุณค่าใหม่ๆ

ผลิตภัณธ์เหมือนเดิม แต่เปลี่ยนวิธีการส่งมอบคุณค่า

ลองนึกดูว่า เมื่อก่อนการจะเปิดร้านอาหารต้องอยู่ที่ location ดีๆ ทำเลดีๆ ยิ่งคนผ่านเยอะยิ่งดี

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

เห็นไหมว่า เราก็ขายผลิตภัณฑ์เดิม คือ อาหาร ลูกค้าก็กลุ่มเดิม แต่วิธีการส่งมอบแตกต่างออกไป

5.ย้ายไปภูมิภาคใหม่

วิธีที่ง่ายที่สุดเลย คือ การมองหาสิ่งที่ผลิตภัณฑ์หรือธุรกิจที่ยังไม่มีอยู่ในจังหวัดหรือประเทศของเรา แต่มีอยู่แล้วในจังหวัดหรือประเทศอื่นที่มีไอเดียธุรกิจที่มีลูกค้าเยอะ demand & supply เยอะเลย แต่ในพื้นที่เรายังไม่มีอะไรแบบนี้

เราก็เอามาเปิดหรือขายที่จังหวัด/ประเทศของเราบ้าง เพราะมันถูกพิสูทธิมาแล้วว่ามีความต้องการซื้อและประสบความสำเร็จได้จริง

6.การพัฒนาโดเดลธุรกิจใหม่

สำรวจว่าธุรกิจในโลกของเรามันมีอะไรประสบความสำเร็จบ้าง เช่น demand & supply มันประสบความสำเร็จยังไง โดยที่เมื่อก่อนมันอาจจะมีการตั้งราคาขายแบบนึงและรูปแบบการขายแบบนึง

เราออาจจะให้คุณค่าแบบเดียวกันเลย แต่เปลี่ยนรูปแบบการขายหรือรายได้ไปเป็นอีกแบบนึงเลยที่น่าจะตอบโจทย์ลูกค้ามากกว่า

เช่น

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

อีกตัวอย่าง คือ มีดโดนหนวดที่เมื่อก่อนต้องซื้อทั้งด้ามซึ่งมีราคาแพง แต่ gillette เห็นว่า demand คือ คนที่ต้องการโกนหนวด กับ supply คือ มีดโกนหนวดคุณภาพดี ที่ออกมาให้โกนง่ายๆ

สิ่งที่ gillette ทำ คือ ออกแบบรูปแบบการขายใหม่ คือ การขายมีดโกนพร้อมด้ามจับในราคาถูกได้ ไปหวังกำไรจากการขายใบมีดโกนหนวดเอา

7.เข้าซื้อธุรกิจหรือร่วมทุน

วิธีนี้เป็นการเพิ่มขีดความสามารถให้แก่กิจการของเรา

ตัวอย่าง

facebook ที่ต้องการขยายฐานลูกค้าของตัวเองให้มากขึ้น โดยการไปซื้อ instragram ที่มีฐานลูกค้าอีกกลุ่มหนึ่งเข้ามา เพื่อเสริมความแข็งแกร่งให้ธุรกิจตัวเอง

ทั้ง 7 รูปแบบนี้ ขึ้นอยู่กับเราเลยว่า ชอบแบบไหน และทำแบบไหนได้ ถ้าอยากทำธุรกิจก็ลองเรา 7 ข้อนี้ไปลองกันดู