สรุปสิ่งที่น่าสนใจจากงาน XConf Thailand 2022
เมื่อวันศุกร์ที่แล้วมีงาน XConf Thailand 2022 จัดโดยบริษัท Thoughtworks โดยมีหัวข้อหลากหลาย ตั้งแต่ Development, Testing, Developer Experience, Machine Learning, Data Platform, Accessibility จึงนำมาสรุปไว้สักหน่อย
Table of Contents
Evolutionary Testing in Evolutionary Architecture
Developer Experience (DX) from Code to Platform
Beyond Fitting Models: How to Build Successful AI-driven Products
Building Data Platforms “The Right Way” และ Untangling Data Mesh | A Paradigm Shift in Big Data
High Performing Team Essentials
Accessibility | Building Tech for Everyone
Evolutionary Testing in Evolutionary Architecture
เมื่อไหร่ก็ตามที่การเขียน (unit) test ทำได้ยาก นั่นก็คือสัญญาณที่ดีว่าเราควรถอยมาพิจารณาภาพรวมของ architecture ว่ามีอะไรไม่ชอบมาพากลหรือไม่ แต่ไม่ใช่ทุกคนจะมีสัมผัสที่ดี ที่สามารถอ่านถึงสัญญาณเหล่านี้ได้
ผู้พูดเริ่มจากการตีความ unit test กันก่อน ซึ่งก็มีทั้งสายคลั่งไคล้ (zealot) และสายต่อต้าน (hater) แน่นอนว่ามันก็มีการโต้เถียงกันเกิดขึ้นว่า ขอบเขตของ unit test มันอยู่ที่ตรงไหน เช่น เรามี API สำหรับทำ healthcheck คำถามคือ เราจะเลือกทำบน Controller หรือไปทำในรูปแบบของ API test เลย
จะเห็นว่ามันสามารถทำได้ทั้งคู่เลยนะ ขึ้นกับ unit จึงนำไปสู่คำถามที่ว่า unit ใน unit test คืออะไร ซึ่งมันจะเป็น class, function, method อะไรก็ได้ แล้วอะไรคือสิ่งถูกล่ะ
หากเราต้องการจะตอบคำถามนี้ เราต้องเข้าใจก่อนว่า
Architecture is a bunch of definitions and relationship
ดังนั้นสิ่งที่ทีมควรจะต้องตกลงร่วมกันคือขอบเขตของการทดสอบ (definition) ซึ่งจะต้องชัดเจนและกระชับเฉพาะเจาะจง เช่น
- ✅ เราจะทดสอบใน Repository ซึ่งหมายถึง code ส่วนที่ดึงข้อมูลจาก database
- ❌ เราจะทดสอบใน Utils ซึ่งหมายถึง code ที่ใช้งานทั่ว ๆ ไปใน application
ต่อมาทีมจะต้องตกลงร่วมกันและสามารถอธิบายได้ว่าแต่ละส่วนมันเชื่อมโยงกันอย่างไร (relationship)
การกำหนด definition และ relationship ควรจะไม่ต่างจากมาตรฐานที่หลาย ๆ ที่ใช้มากจนเกินไป เพื่อลดเวลาในการ onboarding คนใหม่ลง ลดการถกเถียงลง เช่น ในบาง framework ก็จะกำหนด definitions มาให้เลยว่า unit คืออะไร เช่น การแบ่งเป็น Controller, Service, Repository เป็นต้น
ในบางครั้งเวลาเขียน unit test แล้วมันยาก หรือ ไม่ได้ ไม่รู้ว่าจะเอาไปไว้ตรงไหน นั่นอาจจะหมายถึงว่าเราอาจจะมี architecture smell ซึ่งสะท้อนให้เห็นถึงปัญหา 2 อย่าง คือ การนำ unit ไปใช้ส่วนอื่นไม่ได้ (reusability) และ ความซับซ้อนในการทดสอบ (testability)
สมมติว่าเราต้องการจะทดสอบ code ในส่วนที่เชื่อมต่อกับ database พบว่า code เริ่มมีความซับซ้อนมากขึ้น เพราะมันไปปนกับส่วนของการปั้น request-response เรามีทางเลือก 2 ทางคือ
- ใช้ test เดิมที่เคยเขียน
- สร้าง test ใหม่สำหรับ repository
ผู้พูดบอกว่าคำตอบคือข้อ 2 เพราะเราสามารถ reuse unit ในที่อื่น ๆ ได้ แต่มีข้อถกเถียงว่า ถ้าไม่เลือกข้อ 1 แล้ว unit test เดิมที่รวบไปกับการปั้น request-response ล่ะ จะเอาไปไว้ไหน ซึ่งเราจะพบว่า
- ตอนแยกออกมาเป็น unit test ใหม่ ก็ยังต้องใช้ unit test เดิมอยู่ เพื่อดูว่าระบบยังคงทำงานได้เหมือนเดิม หลังจากแก้ไข code แล้ว
- Unit test เดิมก็มีแนวโน้มที่จะกลายเป็น integration test เพราะ definition ของ unit ของเราได้เปลี่ยนไป โดยมีการเพิ่ม repository เข้ามานั่นเอง ดังนั้นถ้าเราสร้าง unit test ขึ้นมา ก็ไม่จำเป็นที่จะต้องเป็น unit test ไปตลอดกาล เนื่องจาก architecture (unit) ของเราเปลี่ยนไป
จะเห็นว่าการที่ architecture จะเติบโตขึ้น มีการเปลี่ยนแปลงได้ง่าย แต่ละ unit จะต้องถูกทดสอบอย่างดีเสียก่อน ซึ่งมันก็กลับไปที่ definition ของ unit ตามที่กล่าวมาข้างบน หลายคนเลือกที่จะ test ทุก class ทุก methods เพราะใช้ได้กับทุก use case ทุก architecture แต่มันก็เป็นดาบสองคม เพราะมันไปขัดขวางการ refactor เมื่อมีการเปลี่ยนแปลง unit เราต้องมาแก้ test หลายที่ ส่งผลต่อค่าใช้จ่าย effort ที่ใช้ไปมากมายนั่นเอง
Developer Experience (DX) from Code to Platform
ผู้พูดยกตัวอย่างเหตุการณ์ที่ developer หลาย ๆ คนประสบพบเจอในทุก ๆ วัน จากเรื่องไม่ปกติเป็นเรื่องปกติกันไปซะงั้น ไม่ว่าจะเกี่ยวกับ code หรือไม่เกี่ยวกับ code เลย แต่ที่เหมือนกันคือ กระทบต่อความสุขของ developer ขณะทำงานกับ product แน่ ๆ ตัวอย่างเช่น
เกี่ยวกับ code
- ทำงานกับ code ที่อ่านเข้าใจยาก
- ทำงานกับเอกสารที่ไม่ update
- ทำงานกับระบบที่ไม่มี automated tests
- ทำงานกับ API ที่ไม่เสถียร request ไป 10 รอบ ได้ผลลัพธ์ไม่ค่อยตรงกัน
- ทำงานกับระบบที่ออกแบบมาแล้วซับซ้อนเกินความจำเป็นต่อ requirement ในปัจจุบัน (over-engineering)
ไม่เกี่ยวกับ code
- ไม่มีอุปกรณ์ให้ช่วยทดสอบ เช่น mobile application
- สลับ context ไป ๆ มาๆ ต้องจำอะไรนู่นนี่เยอะไปหมด (cognitive overload)
- การ onboarding ที่ติด ๆ ขัด ๆ
- นั่งรอ ticket ที่ขึ้นกับทีมอื่น เช่น ขอ access เข้าระบบ
- ทำงานกับเวลาที่บีบคั้นตลอดเวลา
การที่เรามี developer experience ที่ดีนั้น จะช่วยให้มีแนวโน้มที่จะ
- ส่งมอบงานได้รวดเร็วขึ้นโดยยังคงคุณภาพที่ดี
- ก่อให้เกิดการสร้างและทดลองสิ่งใหม่ ๆ มากขึ้นโดยไม่ติดขัด
- ดึงดูด และรักษาคนในองค์กรไว้ได้มากขึ้น
ผู้พูดเล่าไปถึงการสร้าง platform เพื่อมาแก้ไขปัญหา developer experience ที่มีร่วมกันข้างต้น พบว่ามีอุปสรรคมากมาย
- มีเครื่องมือผุดขึ้นมาให้เลือกใช้สร้าง platform เยอะแยะไปหมด คำถามคือมีใครรู้วิธีใช้เครื่องมือทุกอย่างบ้างไหม
- จะต้องประสานงานกับคนที่เกี่ยวข้องกับ networking, observability, security & compliance
- Platform จะต้องตอบโจทย์ App team (ต้องการที่จะส่งมอบงานได้ไว เปลี่ยนแปลงได้ง่าย) และ Ops team (ต้องมีความปลอดภัย น่าเชื่อถือ)
- ทำ platform ออกมา ถ้าไม่ตอบโจทย์ developer อาจจะมีค่าใช้จ่ายคือ ไม่มีคนใช้ ดังนั้นเราจะต้องมีขั้นตอนการ Discover → Define → Deliver ที่ดี
- ต้องบีบคอ developer มาใช้ ทั้งที่จริงแล้ว Platform ที่ดีมันจะต้องขายตัวมันเองได้ มีการสนับสนุนให้เกิดการสร้าง community เกิดการแลกเปลี่ยนความรู้ รวมไปถึงการช่วย developer ในกรณีที่ติดปัญหาในการใช้งาน platform
- หลุมพรางอื่น ๆ ที่หลาย ๆ องค์กรพลาด ก็อย่างเช่น platform ไม่มีขอบเขต ทำทุกอย่างได้แต่ใช้ยาก, focus ที่ quality มากจนเกินไป, ไม่มี business value
ปิดท้ายด้วย use case การปรับปรุง developer experience ของ Spotify ด้วยเครื่องมือ Backstage จากปัญหาที่มีร่วมกัน ได้แก่
- มีงานที่ต้องมาทำซ้ำ ๆ กัน เช่น เอกสารอ้างอิงไปถึง source code คู่การ deployment
- การค้นหาระบบที่ซับซ้อน เช่น ในองค์กรมีระบบอะไรบ้าง ใครเป็นเจ้าของ ต้องติดต่อใคร
และสิ่งที่สำคัญมากของการปรับปรุง developer experience คือจะต้องเริ่มจากจุดเล็ก ๆ ก่อน เช่น เริ่มจาก Checklist แล้วค่อยไป Tickets → Collaboration → Self-service จากนั้นเราต้องวัดผลของ developer experience ออกมาได้ เพื่อนำไปปรับปรุงต่อไป ผ่านแนวทางปฏิบัติต่าง ๆ เช่น
- วัดความพึงพอใจในการใช้งานผ่าน developer survey
- วัดจำนวนของ active users รวมถึงเวลาที่ใช้ไปใน platform ภายใน 1 อาทิตย์
- รูปแบบ Four key metrics
Beyond Fitting Models: How to Build Successful AI-driven Products
ผู้พูดเริ่มจากการอธิบายถึงการ fitting models หรือการปรับแต่งให้ model ใน machine learning มีความแม่นยำในการทำนายผล โดยมี 3 ขั้นตอน
- Data preparation + Feature engineering
- Model selection + parameter tuning
- Model evaluation
ซึ่งเราพบว่างานเหล่านี้เราจะต้องมาทำซ้ำ ๆ จึงเกิดแนวคิดของการนำ automation มาช่วย เกิด technique ที่เรียกว่า AutoML คำถามคือ แล้ว data scientist จะทำมาหากินอย่างไรต่อดี
ถ้าหากเราดู use case ที่เคยเกิดขึ้นอย่าง TayTweet, Tesla autopilot แล้วจะพบว่าจะพึ่งพา AutoML อย่างเดียวไม่พอแน่ ๆ ผู้พูดจึงพาเราไปดูว่าการที่สร้าง AI-driven product ให้สำเร็จได้นั้น จะต้องมี 4 อย่าง ได้แก่
1. Right Problem
Data scientist มีหน้าที่ทำการวิเคราะห์ตั้งแต่ต้นว่า
- เราอยากจะแก้ปัญหาอะไร ส่งผลอย่างไรต่อ user และ business
- การนำ machine learning มาใช้ จะทำให้เปอร์ซ็นต์นการทำนายถูกมากน้อยขนาดไหน
2 ข้อนี้เป็นจุดที่ AutoML ไม่สามารถตอบให้ได้ เพราะเครื่องมือแค่พยายามทำนายให้มันถูกมากที่สุดโดยไม่ได้สนใจปัญหาที่เราต้องการแก้เลย โดยจุดเริ่มต้นที่ดีของการวิเคราะห์คือ
เราจำเป็นต้องใช้ machine learning มาแก้ปัญหาไหม
2. Right Data
Data scientist มีหน้าที่เก็บ data ที่จะใช้ในการ train โดยจะต้องเก็บ data ผ่านการพูดคุยกับคน หรือ domain expert เพื่อให้คุณภาพดีที่สุด สาเหตุก็คือการที่เราจัดการ data ให้มีคุณภาพตั้งแต่แรก เพื่อให้ machine learning มันทำนายได้อย่างแม่นยำที่มากกว่าการเปลี่ยน algorithm ตาม data ที่ไม่มีคุณภาพนั่นเอง (แนวคิด Data-centric AI) โดยมีแนวคิดการพิจารณา อย่างเช่น
- Data มันสอดคล้องกับเหตุการณ์ปัจจุบันหรือไม่
- Data มันมี bias หรือไม่
3. Right Model
Data scientist มีหน้าที่นำคน (user) เข้าไปมีส่วนกับ model เพราะ AutoML ไม่สามารถรับรู้ข้อมูลบางอย่างเช่น ข้อมูลวันหยุดของแต่ละประเทศ เป็นต้น
4. Right Decision
Data scientist มีหน้าที่ตรวจสอบผลลัพธ์ด้วยว่ามี case ที่เกิด false positive, false negative บ้างไหม เช่น Fraud payment detection (ลูกค้าไม่โดนโกง แต่เดาผิดว่าโดนโกง, ลูกค้าโดนโกงจริง แต่เดาผิดว่าไม่โดนโกง)
Building data platforms “The Right Way” และ Untangling Data Mesh | A Paradigm Shift in Big Data
สาเหตุที่รวม 2 หัวข้อนี้เข้าด้วยกันเพราะสังเกตว่าเนื้อหามันต่อเนื่องกัน
ผู้พูดเล่าถึงปัญหาของ data platform ที่มีอยู่ในปัจจุบัน เช่น
- ความซับซ้อนของ application team ในการ share data ผ่าน centralised data warehouse/data lake รวมถึงการจัดการขนาดของ data
- ความซับซ้อนในการดูแลรักษา สืบเนื่องจาก data source เป็น legacy system หรือ on-premises ทำให้ deployment ล่าช้าติดขัด
- รูปแบบองค์กรเป็น silo คือจะเอา data ได้ต้องผ่านคนหรือแผนกใดแผนกหนึ่งเท่านั้น มีคนรู้อยู่ไม่กี่คน
- ระบบไม่สามารถเปลี่ยนแปลงได้ตาม requirement
สืบเนื่องจากปัญหาดังกล่าว จึงเกิดแนวคิดของ Data Mesh ขึ้น โดยมีหลักการ 4 ข้อ
1. Domain ownership
ดูแลและเป็นเจ้าของ data เสมือนเป็นเจ้าของแต่ละส่วนของ business ซึ่งจะมีตำแหน่งอย่าง data engineer, data scientist, data product owner (product owner ที่รับผิดชอบเรื่อง data) รวมไปถึง คนที่เชี่ยวชาญด้านการกำกับดูแล data (data governance champion)
2. Data-as-a-Product
เจ้าของแต่ละ domain ดูแล data เสมือนเป็น product ชิ้นนึง ซึ่งมีหน้าที่ในการจัดการ data pipelines (ingest-process-serve), API (กรณีที่อนุญาติให้เข้าถึง data), metadata, infrastructure โดยที่ product ควรจะตอบโจทย์คร่าว ๆ คือ
- Discoverable: สามารถค้นหาได้แล้วรู้ว่าใครเป็นเจ้าของ dataset หน้าตาเป็นอย่างไร
- Addressable: สามารถระบุ data ได้ใน format ที่ต่างกัน เช่น ผ่าน API, file storage URL
- Trustworthy: data มีคุณภาพ ได้ถูก clean มาเป็นอย่างดีก่อนนำมาใช้
- Self-describing: มี dataset พร้อมตัวอย่างที่สามารถเข้าใจได้ง่าย
- Interoperability: มีมาตรฐานในการออกแบบ format และ metadata ในกรณีที่ data ถูก share ข้าม domain หรือ system
- Secure: มีความปลอดภัยในการเข้าถึง data ผ่าน SSO หรือ RBAC หรือ privacy-first
3. Self-serve
มีทีมที่ช่วยดูแลสิ่งของหรือปัญหาที่มีร่วมกันของแต่ละ domain team ผ่านเครื่องมืออย่าง Data infrastructure provisioning plane, Data product developer experience plane, Data mesh supervision plane ผลลัพธ์ที่ได้จาก self-serve data platform คือ
- Scalability: สามารถปรับปรุง เวลาที่ใช้ในการเข้าถึง data, จำนวน data ที่หายไป (data loss), ขนาดของ data, ความสดใหม่ของ data (data freshness)
- Deployability: แต่ละระบบย่อยมีการเปลี่ยนแปลงระบบอย่างรวดเร็วผ่าน CI/CD pipeline และ Infrastructure-as-a-Code
- Observability: มีระบบ monitoring, audit, alert กลาง
- Testability: แต่ละระบบย่อยสามารถทดสอบด้าน data quality, infrastructure, performance, integration tests ระหว่างส่วน ingest-process-serve ได้
- Compliance: มีระบบกลางคอยดูแลเรื่อง data security, RBAC, data governance
นอกจากนั้นยังมีเรื่องของ automation, focus ที่ business value มากกว่า solution, มีระบบดูแล security ในทุก ๆ component ของ data platform
4. Federated computational governance
ต้องมี model ที่ตอบโจทย์ในส่วนของ interoperability ป้องกันการเหลื่อมกันของ context ระหว่าง product หลายๆ ก้อน (polyglot) จึงต้องมีการกำหนด context ที่เป็นมาตรฐาน (standardized) และเป็นภาษาเดียวกัน (ubiquitous) เพื่อให้เป็นมาตรฐานเดียวกันให้แต่ละ domain team
High Performing Team Essentials
ใน session นี้ ผู้พูดได้แบ่งปันประสบการณ์ในการสร้างทีมศักยภาพสูง (high-performing team) โดยเริ่มแนวทางปฏิบัติต่าง ๆ ทีละขั้นตามระยะเวลา
โดยเริ่มแรก ทีมจะต้องละลายพฤติกรรมกันก่อน โดยใช้แนวทาง team building เช่น social contract, team building game, small messages ใน Slack, moments to celebrate, appreciation wall โดยประโยชน์ที่ได้รับคือ
- ลดโอกาสที่จะเกิด toxic culture เมื่อเกิดปัญหา ก็จะไม่โทษที่ตัวบุคคล
- เอื้อให้ทีมเกิดการแบ่งปันประสบการณ์ความรู้
- เอื้อให้ทีมเกิดการลองสิ่งใหม่ ๆ เพื่อนำมาปรับปรุงการทำงานให้ดีขึ้น
- เอื้อให้ทีมมีขอบเขตที่จะกล้าลองผิดลองถูกได้มากขึ้น
หลังจากละลายพฤติกรรมแล้ว ทีมเริ่มทำงานโดยใช้แนวคิด Hypothesis-driven development เนื่องจากงานในช่วงแรก ๆ นั้นมีความไม่แน่นอนเกิดขึ้นมากมาย หรือต้องการจะทำความเข้าใจระบบเดิมก่อนปรับปรุงเสียก่อน โดยวิธีการคือตั้งสมมติฐาน จากนั้นทำการทดลอง และมีการวัดก่อน-หลังการเปลี่ยนแปลง ประโยชน์ที่ได้รับคือ
- มีความกล้าที่จะตั้งคำถาม ขอความช่วยเหลือ เพื่อเรียนรู้ไปด้วยกัน
- มีพื้นที่ฝึกทักษะการพูดคุยกับลูกค้า
เวลาต่อมาทีมได้เปลี่ยนแนวทาง Hypothesis-driven development เป็น Feature development เพื่อเสริม engineering practice จากนั้นพัฒนาทักษะของคนในทีมด้วย Feature lead ประโยชน์ที่ได้รับคือ
- ฝึกทักษะเกี่ยวกับ leadership ซึ่งเป็นก้าวสำคัญไปสู่การสวมบทบาท tech lead ได้ในอนาคต
- ฝึกทักษะในการป้องกันและแก้ปัญหาบน production ผ่านแนวทางปฏิบัติต่าง ๆ เช่น post mortem, support pair
จากแนวทางปฏิบัติดังกล่าวเป็นเพียงแค่ตัวอย่างเท่านั้น การสร้าง high-performing team ก็จะต่างกันไปตามบริบท แต่ทั้งหมดจะต้องคำนึงถึง
- Safety: ทีมสามารถลองที่จะทำสิ่งต่าง ๆ โดยไม่กลัวพลาด แต่ต้องอยู่ในขอบเขตที่ยอมรับได้
- Dependability: ทีมสามารถพึ่งพากันได้โดยอาศัยความเชื่อใจซึ่งกันและกัน
- Competence: ทีมสามารถส่งมอบงานได้ตามเป้าหมายอย่างมีคุณภาพ
- Character: ทีมมีทักษะที่เก่งขึ้นโดยรวม ไม่ใช่เพียงแค่คนใดคนหนึ่ง
Accessibility | Building Tech for Everyone
ผู้พูดเริ่มจากบอกสถิติในประชากรไทย มีคนพิการด้าน การมองเห็น การได้ยิน การพูด การเคลื่อนไหว และ ด้านจิตใจ รวมกัน 2 ล้านคน หมายความว่า product จะมีแนวโน้มที่จะประสบความสำเร็จมากขึ้นถ้าเราสามารถพัฒนา product ของเราให้ตอบโจทย์คนพิการได้
โดยโจทย์หลักที่ product จะต้องตอบได้คือเรื่องของ ความง่าย (ease) ในการใช้งาน ยกตัวอย่างตามรูปด้านล่าง
ผู้พูดได้ยกตัวอย่างสถานการณ์ที่เราพัฒนาระบบ mobile application สำหรับคนพิการทางสายตา โดยจะให้ผู้ใช้เลือก 1 ใน 3 ตัวเลือก (A, B, C) ที่ต้องการ เราก็อาจจะเลือก technology อย่าง screen reader มาช่วยออกเสียง
สมมติว่าผู้ใช้เลือกตัวเลือกที่ B ไปแล้ว แต่อยากเปลี่ยนใจเลือกใหม่อีกรอบ ถ้า product ของเราไม่ได้คำนึงถึง accessibility แบบรอบด้าน screen reader จะทำงานได้การพูดประมาณนี้
“Please select option A, B, C”
ในทางกลับกัน ถ้า product ของเราคำนึงถึง accessibility แบบรอบด้าน screen reader จะทำงานได้การพูดประมาณนี้
“Please select option A, B selected, C”
จะเห็นว่าเพียงแค่ใช้เครื่องมือ screen reader อาจจะไม่เพียงพอ จะต้องคิดเผื่อด้วยว่า คนพิการทางสายตาอาจจะลืมว่า เขาเลือก option ไหนไปก่อนหน้านี้
ดังนั้นการที่เราสามารถพัฒนา product ของเราให้ตอบโจทย์คนพิการได้จะต้องมี mindset ที่คำนึงถึงคนพิการตลอด และแนวทางการทำงานที่รวมการวิเคราะห์เพื่อตอบโจทย์คนพิการ เพียงแค่เกิดจากการจำ หรือเป็นแค่ checklist ตอนพัฒนา product มันไม่เพียงพอในระยะยาว
ในตอนเริ่มต้นเราไม่จำเป็นต้องคิดเองทั้งหมด เราสามารถใช้ guidelines ที่มีอยู่ได้อย่างเช่น
- W3C Accessibility
- Apple Accessibility
- Android Accessibility
- ผู้เชี่ยวชาญด้าน Accessibility โดยเฉพาะ
Building the Best Code Doesn’t Build the Best System
เราพยายามสร้างและปรับปรุง code ที่ดี โดยหวังว่าเราจะได้ระบบที่สมบูรณ์ แต่มันกลับกลายไม่เป็นอย่างที่คิด เราเคยสงสัยไหมว่าทำไหมถึงเป็นอย่างนั้น เป็นที่ความรู้ หรือทักษะของเรายังไม่ดีพออย่างนั้นหรือ
ผู้พูดยกตัวอย่าง Braess’s paradox ซึ่งพูดถึงเหตุการณ์ที่การสร้างเส้นทางพิเศษหรือขยายเส้นทางขึ้นมาใหม่ ไม่สามารถแก้ปัญหารถติดได้เสมอไป ซ้ำร้ายกลับกลายเป็นทำให้รถติดหนักกว่าเดิม
เปรียบเทียบกลับมาที่ระบบงานของเรา ซึ่งมันคือส่วนประกอบที่เชื่อมต่อกันที่ไม่สามารถแบ่งแยกออกจากกันได้ (product + interactions) การที่เราจะปรับปรุงระบบโดยเอาส่วนดีที่สุดมาประกอบกัน มันไม่ได้หมายความว่าจะได้ระบบที่ดีที่สุด โดยยกกรณีศึกษามา 5 อัน
Case 1
ระบบของเรามี bug เยอะ เราเลยตั้ง QA army เพื่อมาดัก bug ที่จะเกิดขึ้นในอนาคต ถึงแม้ว่าจะไม่มี bug เลย แต่ระบบก็ไม่ได้ดีขึ้น เพราะปัญหาหลักมันก็ยังคงอยู่ เช่น ไม่มีการทดสอบอัตโนมัติ เป็นต้น
สิ่งที่น่าสนใจคือทำไมเราไม่ focus ที่สิ่งที่เราต้องการจะปรับปรุงเพื่อป้องกันไม่ให้เกิด bug ตั้งแต่แรก แทนที่การจะต้องมาดักแล้วแก้วนไปเรื่อย ๆ
Case 2
การทำ application ส่วนใหญ่ devloper ไม่ได้ focus ที่ภาพรวม แต่จะเน้นส่วนแยก ๆ กันมากกว่า เพราะเข้าใจภาพรวมมันยาก ลงเอยด้วยการแบ่งงานตามความถนัด (frontend, backend, infrastructure) เพื่อรองรับงานในอนาคต ต่อมาเราพบว่า frontend developer ว่างงานเพราะว่างานที่เข้ามาส่วนใหญ่มีแต่ backend คือไม่ได้เท่ากันตลอด
สิ่งที่น่าสนใจคือทำไม developer ไม่สามารถทำงานทดแทนกันได้ไม่ว่าจะเป็นรูปแบบไหนก็ตาม
สิ่งนี้แสดงให้เห็นถึงความแตกต่างระหว่างคำว่า Efficiency และ Effectiveness โดยที่
- Efficiency หมายถึง ทำงานเสร็จโดยใช้เวลาและแรงน้อย (Do the things right)
- Effectiveness หมายถึง ทำงานเสร็จตามเป้าที่วางไว้ (Do the right things)
Case 3
การทำ code review ทีมตัดสินใจว่าก่อนที่จะทำ code ขึ้นไป build และ deploy ได้ จะต้องให้ senior developer/architect มา review กันก่อน เพราะคนเหล่านี้มีประสบการณ์มากที่สุด
สิ่งที่น่าสนใจคือทำไม senior developer/architect ถึงไม่สามารถทำให้ team member review กันเองได้ เพื่อจะได้ไม่เกิดคอขวด
แสดงให้เห็นถึงความแตกต่างระหว่างคำว่า Management และ Leadership โดยที่
- Management จะให้ความสำคัญกับงานที่ต้องลุล่วงสำเร็จเรียบร้อยตามเป้าหมายเป็นพอ อะไรจะเกิดขึ้นไม่เป็นไร (Do the things right)
- Leadership จะให้ความสำคัญกับการทำงานระหว่างคนในทีม และให้คำแนะนำเพื่อให้คนอื่นเติบโต (Do the right things)
Case 4
ทีมนำแนวปฏิบัติ Pair programming มาใช้งาน แต่เจอปัญหาสุด classic ที่ management ไม่ชอบ ทำไมถึงไม่เอา 2 คนไปทำงานได้ตั้ง 2 งาน จะได้ไม่ต้องเสีย cost 2 เท่า งานวิจัยพบว่า development cost ขึ้นมาไม่ถึง 15% ไม่ใช่ 100% ตามบัญญัติไตรยางค์
Case 5
บริษัทอยากจ้างคนเก่งเข้ามาช่วยทีม เพื่อทำให้คนเดิมเก่งขึ้นเรื่อย ๆ
สิ่งที่น่าสนใจก็คือมันไม่ได้การันตีว่า เอาคนเก่งเข้าทีมแล้วทีมจะเก่งขึ้นนะ มันต้องมีทีมที่มีโครงสร้างที่สร้างทีมที่เก่งมากพอ ถ้าทำให้ทีมเก่งขึ้น → software ดีขึ้น → ได้ feedback รวดเร็วขึ้น → ทีมเก่งขึ้น
จะเห็นว่าตัวอย่างที่ได้ยกมา การที่เราจะปรับปรุงระบบนั้น
- ควรเข้าใจภาพรวมในระบบมันดีขึ้น เข้าใจส่วนประกอบที่เชื่อมกันก่อน
- ปรับปรุงกับปัจจุบัน ไม่ใช่อนาคต เพื่อให้มันดีขึ้นในอนาคต
ปิดท้ายด้วยความแตกต่างระหว่าง programming และ software engineering คือ
- Programming: แก้ปัญหา เขียน code ส่งออก
- Software engineering: การสร้างระบบโดยใช้ programming + การทำงานกับคนอื่น
Panel | Tech Journeys, Challenges and Learnings
เป็นการเล่าประสบการณ์ของ Thoughtworkers 3 คน โดยมีข้อคิดที่อยากจะฝากพวกเราไว้คือ
- จำความรู้สึกว่าตอนนี้ไฟแรงมันเป็นไง 10–20 ปี ถัดไป จะต้องยืนระยะให้ได้เหมือนเดิม
- เรียนรู้ให้ลึกซึ้งถึงแก่น
- วิเคราะห์ว่าเรามีเป้าหมายอะไร แล้วระยะยาวประมาณไหน แล้วทุกวันนี้เราทำให้เราเข้าใกล้เป้าหมายของเราแล้วยัง
- หลังจากที่เราผลักดันด้านงาน (professional life) อย่าลืมสนใจคนรอบข้าง (personal life)
- Work-life balance ไม่ต้องสมดุล 50–50 แต่ให้เข้าใจเป้าหมายของเราว่าทำไม ณ ตอนนั้นมันถึงไม่สมดุล
