สรุปสิ่งที่น่าสนใจจากงาน XConf Thailand 2023
เมื่อวันศุกร์ที่แล้วมีงาน XConf Thailand 2023 จัดโดยบริษัท Thoughtworks โดยมีหัวข้อหลากหลาย ตั้งแต่ Development, Testing, Platform Engineering, Machine Learning, FinOps, Legacy Modernization จึงนำมาสรุปไว้สักหน่อย
Table of Contents
เนื่องจากบทความทั้งหมดมันยาวมาก เพื่อความสะดวกเราสามารถกดเพื่อเลือกดูและอ่านหัวข้อที่สนใจได้ตามข้างล่างเลยครับ
Green software: How can tech contribute to worldwide sustainability effort?
Self-service for delivery value with platform engineering
Our adventure in building an internal developer platform
Successful digital transformation: Outcome-driven teams, reward and metrics
FinOps: Principles and cloud cost observability
Democratizing data access through LLM
Legacy modernization made practical: A live coding example of modernization patterns
Why organizations fail in investing in research and design (without Ops)?
Green software: How can tech contribute to worldwide sustainability effort?
ในยุคปัจจุบันที่เทคโนโลยีมีบทบาทสำคัญในสังคมของเรา การพัฒนาและการใช้งาน software มีผลกระทบต่อโลกเราอย่างมหาศาล สิ่งที่เราพบคือการปล่อยก๊าซ CO2 ที่มีส่วนร่วมในการก่อให้เกิดปัญหาโลกร้อน เราจะมาพิจารณาเรื่องปัจจัยการปล่อย CO2 และแนวปฏิบัติที่ช่วยสร้างโลกที่น่าอยู่มากขึ้นได้อย่างไร
Green software เป็นแนวคิดที่จะช่วยลด CO2 emission โดยใช้การออกแบบและพัฒนา software ให้มีผลกระทบน้อยลงต่อสิ่งแวดล้อม โดยเราสามารถวัดได้ผ่าน 2 อย่างคือ
- Carbon equivalence เป็นหน่วยที่ใช้การวัด impact จากการปล่อย CO2 จาก software สามารถวัดได้ผ่านเครื่องมือต่าง ๆ เช่น Cloud Carbon Footprint
- Software carbon intensity (SCI) เป็นตัววัดคุณภาพของ software และ architecture design จากการปล่อยก๊าซ CO2 โดยใช้สูตร
การวัด SCI เหมือนกับการวัด algorithm ใน computer science ด้วย Big O notation ที่ไม่เพียงแต่ดูความเร็วอย่างเดียว แต่ต้องดูว่ามันทำงานใน scale ที่สูงขึ้นไหวด้วยหรือไม่
การประหยัดพลังงานได้สามารถทำได้ 2 ทางคือ
- ลด overhead ที่มาจาก data center และการใช้งาน hardware เราสามารถใช้ metrics ต่าง ๆ เช่น Power Usage Effectiveness (PUE) และลดการใช้งาน CPU และ memory จาก hardware ลง
- การปรับปรุง software เพื่อลดการใช้งานพลังงานสามารถทำได้ผ่านการใช้เทคนิคต่าง ๆ เช่น caching, set storage retention, การใช้ serverless สำหรับ AI/ML, การจัดการ request และการลดขนาดรูปภาพ
อีกสิ่งที่เราต้องเข้าใจด้วยคือพลังงานที่เกิดขึ้นมันแลกมากับค่าใช้จ่ายที่ไม่เท่ากัน เช่น แหล่งผลิตพลังงานไฟฟ้าด้วยกังหันก็จะปล่อยก๊าซ CO2 น้อยกว่าการผลิตด้วยถ่านหิน หรือเวลาที่ผลิตพลังงานตอนกลางวันก็ไม่เท่ากับตอนกลางคืน เป็นต้น มีเครื่องมือและโครงการต่าง ๆ เช่น Carbon-aware SDK และ Carbon Hack 2022 ที่ช่วยในการสร้างความตระหนักในเรื่องนี้
ในฐานะคน IT ก็สามารถเข้าไปช่วยได้เช่นเดียวกัน รวมไปถึงการฝึกพัฒนาทักษะเกี่ยวกับการจัดการ data เนื่องจาก Domain expert คนเดียวแก้ปัญหานี้ไม่ได้ ทุกคนต้องมีส่วนร่วมในการแก้สถานการณ์โลกร้อนให้ดีขึ้น
สามารถเข้าไปเรียนรู้แนวปฏิบัติอื่น ๆ ที่ช่วยออกแบบและพัฒนา software เพื่อลดโลกร้อนเพิ่มเติมได้ที่ https://patterns.greensoftware.foundation/
Self-service for delivery value with platform engineering
การพัฒนา software แบบเดิม ๆ คือทีมพัฒนา (DEV) และทีมดูแลระบบ (OPS) มักทำงานโดยอิสระจากกัน การแยกแยะงานระหว่างทีม DEV และ OPS บางครั้งอาจทำให้เกิดปัญหาเช่น
- Ticket Dancing กว่าจะได้แต่ละอย่างต้องสร้าง ticket ไปขอ approval ทีมนู้นทีมนี้
- Duplicated Tasks ทำงานแบบอัตโนมือส่งผลให้งานออกช้าลง
- Meetings โดยไม่จำเป็นเกิดขึ้นอย่างมากมาย เสียเวลาเสียพลังงาน
- พอ release ระบบเกิดปัญหาขึ้นในระบบต้องพึ่งสิ่งศักดิ์สิทธิ์
การนำเข้าแนวคิด DevOps มีเป้าหมายในการทำให้กระบวนการพัฒนาและการดูแลระบบเร็วขึ้น โดยที่ทีม DEV และ OPS รวมกันเป็นทีมเดียว แต่อาจต้องเผชิญกับ cognitive load ที่เพิ่มขึ้นเนื่องจากต้องเรียนรู้และเข้าใจการใช้เครื่องมือทั้งด้าน DEV และ OPS
Platform engineering เป็นแนวคิดเพื่อลดภาระงานที่ซ้ำซ้อนของทีมพัฒนา ด้วยการสร้าง platform แบบ self-service ร่วมกัน ทำให้นักพัฒนามีเวลาใส่ใจการสร้าง business value มากขึ้น แม้ว่าพวกเขาไม่ได้เป็นผู้เชี่ยวชาญในด้าน infrastructure ของระบบ แต่ยังสามารถทำงานสอดคล้องกับแนวทางปฏิบัติมาตรฐานขององค์กรได้ โดยไม่ต้องรอการสนับสนุนจากทีม OPS ในทุก ๆ ขั้นตอนของกระบวนการพัฒนา
Self-service
เป็นแนวคิดที่สามารถเปลี่ยนแปลงวิธีการทำงานในองค์กร มันเปรียบเสมือนการให้ตู้ขายตั๋วสำหรับทีมพัฒนา โดยแนวคิดนี้จะอยู่ตรงกลางระหว่างการทำงานในรูปแบบ Ticket-based (ต้องรอให้ platform team หยิบขึ้นมาทำแลกกับ cognitive load ที่ต่ำ) และ DIY (ที่ไม่ต้องรอให้ platform team หยิบขึ้นมาทำแลกกับ cognitive load ที่สูง)
Paved road
เป็นแนวคิดที่ให้ขั้นตอนการทำงานและเทคโนโลยีที่ถูกกำหนดเอาไว้สำหรับคนรุ่นหลัง มีความเหมาะสมและให้ความยืดหยุ่นในการใช้งาน โดยมีคุณลักษณะอยู่ 3 ข้อ
- Optional เปรียบเทียบกับการตัดสูทที่เราสามารถเลือกสีกระดุม, เนื้อผ้า, ขนาดได้
- Abstraction but transparent เปรียบเทียบกับรถที่เราสนใจว่าเหยียบคันเร่งมันก็ไปข้างหน้าได้เหมือนกันไม่ว่าจะเป็นรถใช้น้ำมันหรือใช้ไฟฟ้า ทั้งนี้ทั้งนั้นเราก็สามารถเข้าไปดูเครื่องได้ถ้าสนใจ
- Extensible เปรียบเทียบกับมีดถางทางที่สามารถเปิดทางใหม่ได้มากพอเพื่อปรับให้เข้ากับความต้องการของทีมพัฒนา โดยที่ platform ก็จะสร้าง Guardrails ขึ้นมาเป็นกฎข้อบังคับที่จัดทำขึ้นเพื่อลดความเสี่ยงและป้องกันไม่ให้เกิดความเสียหายหากออกนอกลู่นอกทางมากเกินไป
ใน talk นี้ผู้พูดได้มีการยกตัวอย่างการพัฒนา platform จากปัญหาต่าง ๆ ที่เหล่าทีมพัฒนาต้องพบเจออยู่ทุกวัน เช่น
Inconsistency log formats
ปัญหา: ต่างทีมต่างก็มี format ในการ log ต่างกัน เช่น plain text, JSON คนละ schema ส่งผลให้ค้นหา log ที่เกี่ยวข้องกันยาก เมื่อเกิดปัญหาในระบบจะหาสาเหตุจาก log ได้ยากขึ้น
วิธีแก้: Platform team ทำ library ของ logging ขึ้นมาที่มี format มาตรฐานเดียวกัน ทีมพัฒนาเพียงแค่ใช้ library นั้นใน project ของเขา
Lack of policy control
ปัญหา: ต่างทีมต่างก็มีการ configure ให้ใช้ resource อย่าง CPU และ memory ที่จะ deploy ใน platform ต่างกันได้อย่างอิสระ ทำให้ระบบบางตัวกิน resource จนเกิน limit ที่กำหนดไว้ทำให้ระบบอื่นไม่สามารถ deploy ขึ้นได้
วิธีแก้: Platform team กำหนด policy บังคับใช้ทั้งองค์กร ในตัวอย่างของ platform คือ Kubernetes ก็จะใช้ Admission Controller เข้ามาช่วยเพื่อลดความเสี่ยงที่กล่าวไป
Mixing of concerns in delivery setup
ปัญหา: ทุกทีมพัฒนาเข้าไปจัดการกับ infrastructure โดยตรงในด้านต่าง ๆ เช่น สร้าง database, ดูเรื่อง networking, security ทำให้พวกเขาปวดหัวกับเทคโนโลยีและความซับซ้อนที่ต้องพบเจอโดยไม่ได้ focus ไปกับการสร้าง business value นอกจากนั้นก็เกิดอาการที่ทีมจะต้องมาทำงานเดิม ๆ ซ้ำ ๆ กันอีก
วิธีแก้: Platform team สร้าง abstraction ที่อาจจะเป็น user interface, CLI, application file ที่จะแปลงไปเป็นข้อมูลที่จำเป็นต่อการสร้าง infrastructure ที่ถูกกำหนดไว้จำกัด เช่น web service, database เป็นต้น เทคโนโลยีที่เกี่ยวข้องก็อย่างเช่น Open Application Model, KubeVela, Kratix, Crossplane เป็นต้น
Much effort in building observability system
ปัญหา: การสร้างระบบ observability มีความซับซ้อนเนื่องจากการใช้งานที่แตกต่างกันของแต่ละฝ่ายแต่ละคน เช่น ฝั่ง finance ก็อยากดูจะค่าใช้จ่ายที่เกิดขึ้นในระบบ ในขณะเดียวกันฝั่งทีมพัฒนาก็อยากดูว่าระบบมันยังทำงานโอเคอยู่ใช่ไหม
วิธีแก้: Platform team สร้าง dashboard ที่มี feature ในการเชื่อมต่อกับ plugin ต่าง ๆ ตามความต้องการของผู้ใช้ เช่น ดู workload ไปพร้อม ๆ กับดูค่าใช้จ่าย เป็นต้น
Our adventure in building an internal developer platform
ต่อจาก talk ก่อนหน้า นอกเหนือจาก cognitive load ที่เพิ่มขึ้นเนื่องจากต้องเรียนรู้และเข้าใจการใช้เครื่องมือทั้งด้าน DEV และ OPS แล้ว ผู้พูดยังชี้ให้เห็นว่า ยิ่งทีมพัฒนามีตัวเลือกมากเท่าไร ก็มีแนวโน้มที่คนไม่มีความสุขกับ choice ที่ตัวเองได้เลือกมาเพราะว่าตัวเองเสียโอกาสในการที่ไม่ได้เลือกตัวเลือกอื่น ๆ เพราะพวกเขาหลาย ๆ ทีมจะต้องใช้เวลาในการเลือกเครื่องมือที่เหมาะกับงานของตนซ้ำ ๆ กันแล้วก็มานั่งนึกเสียดายว่าทำไมถึงไม่เลือกเครื่องมืออีกตัวหนึ่งแทน ในขณะเดียวกันองค์กรก็ต้องเสียค่าใช้จ่ายในการดูแลรักษาเครื่องมือต่าง ๆ เหล่านั้น แต่การที่เราบอกว่ามันมีตัวเลือกเยอะเกินไปก็ไม่ได้หมายความว่าองค์กรไม่ต้องให้ไม่ต้องมีตัวเลือกเลยเพราะว่าการขาดตัวเลือกนั้นไปก็คือการขาดความยืดหยุ่นขาดความสามารถในการปรับแก้ให้เหมาะสมกับความต้องการของทีมพัฒนา
ดังนั้นมันจึงมีแนวคิดเรื่องของ Internal developer platform ขึ้นโดยมีใจความหลักสำคัญดังนี้
- Foundation: ถึงแม้ว่า platform เหล่านี้จะไม่ได้ออกสู่สายตาลูกค้าปลายทาง แต่มันก็ช่วยให้ Developer ส่งมอบคุณค่าให้ลูกค้าปลายทางได้เร็วขึ้น
- Self-service, reduced coordination: ลูกค้าจะสามารถใช้งาน platform ได้โดยที่ team ที่ดูแล platform ไม่กลายเป็นคอขวดจากการต้องขอ approval ต่าง ๆ นา ๆ
- Knowledge and Support: การที่ platform จะประสบความสำเร็จจะพึ่งเครื่องมืออย่างเดียวไม่ได้ จะต้องมีการแบ่งปันความรู้ที่เกี่ยวข้องว่า platform เหล่านี้มันมาช่วยให้ชีวิตผู้ใช้งาน ในแต่ละวันให้ดีขึ้นได้อย่างไร และมีการช่วยเหลือผู้ใช้งานด้วย
- Compelling: ผู้ใช้งานจะต้องเห็นว่า platform เป็นทางที่ดีที่สุดที่จะช่วยแก้ปัญหาของเขาโดยที่ไม่รู้สึกถูกบังคับขืนใจมาใช้
- Product: เช่นเดียวกับ product อื่น ๆ แนวคิดเรื่องของ product thinking และสำคัญมาก ๆ คือการเชื่อมคุณค่าของ technology กับ business เข้าด้วยกัน
- Reduction in cognitive load: platform จะต้องช่วยลดการปวดหัวกับการตัดสินใจหรือการประสานงานกับคนนู้นคนนั้นเพื่อแก้ปัญหา เอาเวลาและแรงไปส่งมอบคุณค่าให้ลูกค้าปลายทางจะดีกว่า
ผู้พูดได้แบ่งเส้นทางการพัฒนา Internal developer platform เป็น 4 phase
- Assess and Recommend แนะนำลูกค้าว่า จากหลากหลายปัญหาในองค์กร เราควรหยิบออกมา 1 อันที่มันน่าแก้ที่สุด แล้วออกแบบหน้าตา platform ว่ามันควรจะเป็นแบบไหนแล้ว platform นี้จะมาตอบโจทย์องค์กรเขายังไง โดยเราจะต้องทำงานอยู่บนความเสี่ยง
- Baseline and Prove นำ feedback และข้อมูลที่ได้จากใน phase ที่แล้วมาทำการสร้าง minimum viable product เพื่อทำการพิสูจน์ว่าสิ่งที่เราแนะนำให้ลูกค้าใช้ลงทุนไปน่ะมันมีประโยชน์จริง ๆ นะ โดย platform จะต้องใช้งานได้บนองค์กรที่มีการใช้เครื่องมือและ technology แตกต่างกัน และครอบคลุมปัจจัยอื่น ๆ ที่อยู่ในและนอกการควบคุมของทีม
- Seed and Scale พัฒนา platform ตามผู้ใช้งานเพิ่มขึ้นที่มาพร้อมกับ requirement ใหม่ ๆ กับ scale ใหม่ ๆ โดยจะต้องมีการปรับ user experience และ marketing ให้เป็นที่รู้จักในองค์กรมากขึ้น
- Evolve and Support พัฒนา platform ด้วยการเพิ่ม capability ใหม่ ๆ และเปลี่ยนวิธีการทำงานระหว่าง platform team และ developer ไปตาม platform
โดยการผจญภัยในเส้นทางนี้ทางผู้พูดก็มีการให้ technique ต่าง ๆ อย่างเช่น
- Thin slice planning หยิบปัญหาที่ developer ต้องพบเจอทุก ๆ วันที่มีความสิ้นเปลืองมาแบ่งแล้ว focus ที่อันใดอันนึงเพื่อลงมือทำเพื่อเก็บ feedback
- กำหนด measure of success ที่เหมาะสมทั้งด้าน software และความสุขของทีมพัฒนา
- สร้างมาตรฐานด้วยการปูทางในการใช้ platform ด้วย engineering practices, เครื่องมือต่าง ๆ ที่สอดคล้องกับ developer ส่วนใหญ่ในองค์กรโดยไม่ไปเป็นสิ่งกีดขวางให้ developer ส่วนน้อยลงมือทำอะไรที่อยู่นอกมาตรฐานที่ไม่เกิดความเสียหายให้องค์กรทีหลัง
- กำหนด abstraction ที่ซ่อนความซับซ้อนที่ developer ไม่จำเป็นต้องใช้ในการส่งมอบและรักษา business value เช่น developer ไม่ต้องรู้ code เบื้องหลังทั้งหมดในการการันตีว่าทำยังไงให้การ deploy application ใหม่จะไม่มี downtime เกิดขึ้น เป็นต้น
- การทำ release, versioning เพื่อลดโอกาสไม่ให้งานของ platform team ที่ยังไม่เสร็จไปกระทบกับผู้ใช้งานคนอื่น รวมถึงการมี dashboard เพื่อแสดงข้อมูลการใช้งาน
- การเขียนเอกสารที่สอดคล้องกับคนใช้งานเอกสารด้วยแนวปฏิบัติ Diátaxis
ทั้งนี้ทั้งนั้นการพัฒนา platform ก็ไม่ได้ต่างกันกับการพัฒนา software อย่างอื่น มันก็ไม่ได้สามารถแก้ปัญหาได้ทุกอย่าง เช่น
- โครงสร้างขององค์กรที่ไม่เหมาะสม: ต่อให้มี platform ก็ไม่ได้ช่วยให้เป้าหมายของ Dev (ส่งมอบคุณค่าให้เร็วที่สุดเท่าที่จะเป็นไปได้) กับ Ops (ทำให้ระบบเสถียรไม่ล่ม) ตรงกันได้ ซึ่งมันเกิดจากรูปแบบขององค์กรที่ไม่ได้เอื้อต่อการส่งมอบและมีการสื่อสารที่ดีจากกฎ Conway’s law
- การตัดสินทางด้าน architecture และ technology ที่แย่: หนำซ้ำ platform อาจจะทำให้ปัญหานี้แย่ลงเนื่องจากแทนที่ผู้ใช้จะต้องมาเจอปัญหาเหล่านี้ด้วยตัวเอง ตัว platform กลับซ่อนมันไว้ใต้พรม
- การจัดลำดับความสำคัญของงานที่จะต้องส่งมอบได้ไม่ดี: platform มีหน้าที่แค่ช่วยให้การค้นคว้าทดลองเร็วขึ้น ส่งผลทางอ้อมให้เห็นภาพในการจัดลำดับงานจากความเป็นไปได้ที่ชิ้นงานจะเป็นจริง (feasibility)
- Engineering practice ที่ต่ำ: ถึงแม้ว่า platform จะช่วยนำพาไปหา practice ที่ดีได้ในระดับนึง แต่ก็ไม่ได้แก้ปัญหาที่สร้างขึ้นจาก practice ที่แย่อยู่ดี วิธีแก้ที่ถูกคือการสอนและให้ความรู้กับคนในองค์กร
Successful digital transformation: Outcome-driven teams, reward and metrics
การทำ digital transformation ไม่เหมือนกับการเดินเส้นตรง เราพบว่าองค์กรส่วนใหญ่ล้มเหลวในการทำ digital transformation เนื่องจาก
ปัญหา = คน + วัฒนธรรมในองค์กร
ส่วนใหญ่ของปัญหามาจากการจัดการกับคนและวัฒนธรรมในองค์กร การเปลี่ยนแปลงต้องอาศัยการเปลี่ยนแปลงทางวัฒนธรรมเพื่อสร้างความเสถียร โดย
ความสำเร็จในการเปลี่ยนแปลง = mindset ที่ถูกต้อง + อำนาจที่ถูกต้องในมือของคนที่ใช่
การสร้างความสำเร็จไม่ได้ขึ้นอยู่เฉพาะกับเทคโนโลยีอย่างเดียว มันต้องมีการเปลี่ยนแปลงใน mindset ซึ่งแบ่งออกเป็น 3 ส่วนย่อยคือ
- เน้นการ focus ไปที่ value ที่มอบให้กับลูกค้า
- เน้นการเอื้อให้เกิดการทดลองเพื่อสร้าง hypothesis ที่ตอบโจทย์ลูกค้า
- เน้นการตอบสนองต่อความต้องการที่เปลี่ยนไปของลูกค้า
การทำการเปลี่ยนแปลงไม่สามารถทำได้โดยทีมเดียว ต้องมีการทำงานร่วมกันของหลายทีม แต่สำคัญกว่าการรวมกันคือการรวบรวมทุกคนในการทำงานให้เหมาะกับผลลัพธ์ที่ต้องการ ควรเน้นผลลัพธ์ที่เชื่อมโยงกับการเพิ่มรายได้ ซึ่งเป็นเป้าหมายสำคัญของการทำการเปลี่ยนแปลง
ที่สำคัญการให้รางวัลรายคนไม่สามารถใช้เพื่อเสริมสร้างทีมให้ดีได้ ต้องมีการให้ความสำคัญกับความสำเร็จของทั้งทีม
คนที่อยู่ใกล้กับปัญหานั้นมีความรู้และความเข้าใจเกี่ยวกับมันมากที่สุด ดังนั้นการรับฟังและร่วมมือกับพวกเขาจะช่วยให้การเปลี่ยนแปลงมีผลสำเร็จ
การวัดความสำเร็จ = business value + ความพึงพอใจของลูกค้า + ทักษะของคนในทีม + การเรียนรู้และพัฒนาของคนในทีม
การวัดความสำเร็จของการเปลี่ยนแปลงดิจิทัลควรพิจารณามูลค่าของธุรกิจ ความพึงพอใจของลูกค้า ทักษะและบทบาทของบุคคล และการเรียนรู้และพัฒนาในระหว่างการเปลี่ยนแปลง
“What’s in it for me?”
สุดท้ายแล้วเมื่อมีการทำ digital transformation คำถามที่เราต้องตอบลูกค้าให้ได้คือ “What’s in it for me?” แปลว่า “แล้วฉันได้อะไร(จากการเปลี่ยนแปลงนี้)” เพื่อเข้าใจว่าการเปลี่ยนแปลงนี้จะมีผลต่อตัวเขาอย่างไรและเขาสามารถมีส่วนร่วมอย่างไรในกระบวนการนี้
The more we test, the worse?
ผู้พูดเริ่มจากการถามคุณผู้ดูพบว่าครึ่งนึงเชื่อว่าการทดสอบมันมีประโยชน์ แล้วที่เหลืออีกครึ่งนึงล่ะน่าสนใจ โดยมีการยกตัวอย่างกรณีศึกษาว่าไม่ว่าจะทดสอบน้อยหรือมากไป มันก็อาจจะส่งผลแย่ได้หมด
- Therac-25 เครื่องบำบัดด้วยรังสีซึ่งตรวจพบทีหลังว่าคนที่เข้ามาเป็นโรคต่าง ๆ จนถึงตายเนื่องจากได้รับปริมาณรังสีที่มากเกินไป เหตุเพราะว่าไม่ได้ทดสอบมากเพียงพอ
- PonoMusic เครื่องเล่นเพลงโดยได้ไอเดียตอนปี 2012 แต่ใช้เวลา 3 ปีกว่าจะได้ของลงขายเนื่องจากลงแรงและเงินไปกับการทดสอบคุณภาพเสียงมากเกินไป สุดท้ายก็ไปไม่รอดต้องปิดกิจการลงไปในปี 2017
เพื่อที่จะตอบคำถามตามหัวข้อนั้น ก็ลงรายละเอียดปลีกย่อย 3 อย่าง
ทำไมชุดการทดสอบเรามันจับ bug ไม่ได้นะ
“Build quality into the product, rather than trying to inspect it in afterward.” — Dr. W. Edwards Deming
เริ่มจากว่านิยามของคำว่า “คุณภาพ” ของ software มันคืออะไรกันแน่
- User สามารถใช้งาน software ได้ตามที่คาดหวังไว้
- User เข้าใจว่าจะใช้ software ได้อย่างไร
- User สามารถใช้งาน software ได้โดยที่ไม่ล่มหรือล่มน้อยครั้งที่สุด
- องค์กรสามารถพัฒนาต่อยอด software ได้โดยมีค่าใช้จ่ายที่สมเหตุสมผล
จะเห็นว่าส่วนใหญ่แล้วจะมีคำว่า “User” ดังนั้นเวลาเรานึกถึงคุณภาพแล้วก็ควรจะนึกถึงมุมมองของ “User” เสมอ เมื่อมีคำถามดังหัวข้อแล้ว สิ่งที่เราควรคิดต่อก็อย่างเช่น
- แล้วเราสามารถป้องกันไม่ให้ปัญหานี้เกิดขึ้นตั้งแต่แรกได้ไหม
- แล้ว User เขาใช้ software อย่างที่ได้คาดหวังไว้ไหม
- แล้ว codebase ของเรามันยังปรับแก้ต่อยอดง่ายอยู่ไหม
“Quality ≠ no bug”
ทำไมชุดการทดสอบอัตโนมัติมันไม่ช่วยเราเลยนะ
ปัญหาที่พบเจอบ่อย ๆ บนชุดการทดสอบอัตโนมัติได้แก่
- Run ช้า ได้ feedback โคตรช้า
- Run ด้วยระบบเดิม บางครั้งก็ผ่านบางครั้งก็ไม่ผ่าน เชื่อถือไม่ได้เลย
สมมติว่าเรากำลังทำระบบลงทะเบียนโดย password ที่ต้องตั้งนั้นมีข้อกำหนดต่าง ๆ แล้วเมื่อนำ Test pyramid มาเทียบ คำถามคือเราควรจะทดสอบอะไรตรงไหนบ้าง
ถ้าเราบอกว่าก็ทดสอบบน UI ทั้งหมดนั่นหมายความว่า QA ของเราทำงานคนเดียวเป็น silo หรือไม่ ถ้าใช่ก็จะได้หน้าตาแบบ ice cream cone เลย แต่ถ้าเราบอกว่าก็ทดสอบเรื่องเดียวกันบนหลาย ๆ ระดับก็จะมีค่าใช้จ่ายสูงในการสร้างชุดการทดสอบและหากเกิดการเปลี่ยนแปลงค่าใช้จ่ายก็จะเพิ่มตามไปอีก ก็จะได้หน้าตาเป็น cupcake เลย
ดังนั้นสิ่งที่เราควรปฏิบัติคือไม่ควรทำงานกันแบบ silo คนที่มีส่วนเกี่ยวข้องกับระบบมาช่วยกันขบคิดและวางแผนว่าส่วนไหนต้องทดสอบอะไรบ้าง
แล้วเราจะวัดคุณภาพของ software ได้อย่างไร
Testers’ KPI: find 30 bugs in 1 iteration
Developers’ KPI: no more than 3 major bugs are reported in 1 iteration
จากการวัดคุณภาพ software ด้านบน เป็นไปไม่ได้เลยว่า tester และ developer จะไม่สู้กันให้ตายไปข้างนึง จะดีกว่าไหมหากเราร่วมมือกันแทนที่จะให้เป็นหน้าที่ของ QA อย่างเดียว แล้วจากนั้นวัดผลจากตัว software จริง ๆ
ทั้งนี้ทั้งนั้นพอเราเลือก metrics มาแล้วก็ควรระวังด้วยว่าตัวเลขที่ได้มานั้นมันมาจากไหน สมเหตุสมผลไหม ต้องแลกมากับอะไรอย่างอื่นหรือเปล่า
โดยสรุปแล้วถ้าถามว่า “ยิ่งทดสอบเยอะยิ่งแย่จริงหรือ” คำตอบก็คือ “ใช่ มันเกิดขึ้นได้ แต่เราหลีกเลี่ยงได้เช่นเดียวกัน” เพราะมันขึ้นอยู่กับเรื่องต่าง ๆ ดังนี้
- ต่างคนต่างทดสอบแยกกันใช่หรือไม่
- เราเข้าใจ user ดีแล้วใช่หรือไม่
- เราทดสอบเรื่องเดิมซ้ำกับตัวเองหรือคนอื่นหรือไม่
- เราตระหนักรู้ว่าการทดสอบแบบไหนที่จำเป็นใช่หรือไม่
- ทีมของเราวัดคุณภาพของ software ได้อย่างถูกต้องใช่หรือไม่
FinOps: Principles and cloud cost observability
“เวลาออกแบบ software ให้คิดถึงเรื่อง cost ด้วย”
สืบเนื่องจากว่าหลายองค์กรอยากลดค่าใช้จ่ายเพื่อสร้างผลกำไร ก่อให้เกิดการทำงานร่วมกันในหลายฝ่าย เช่น finance, business, development จึงเกิดแนวคิด FinOps (Finance + DevOps) ขึ้นเพื่อเปลี่ยน culture ในการจัดการกับค่าใช้จ่ายในระบบงานประกอบกับข้อมูลช่วยการตัดสินใจเพื่อสร้างสมดุลของ business value ให้เหมาะสมกับค่าใช้จ่ายที่เกิดขึ้น โดยมี principle ด้วยกัน 6 ข้อดังนี้
- ทีมในองค์กร เช่น finance, business, development ต้องทำงานร่วมกันเพื่อบรรลุเป้าหมายเดียวกัน
- ทีมมีสิทธิ์ตัดสินใจในการจัดการค่าใช้จ่ายที่มีผลต่อ business value ด้วยตนเอง
- แต่ละทีมรู้งบที่ตนเองมี ใช้ไปเท่าไร เหลือเท่าไร
- ทีมต้องสามารถเข้าถึงข้อมูลจากที่เดียวกัน
- มีคนหรือทีมที่กำหนดเป้าหมายและทิศทางของ FinOps
- ใช้ประโยชน์จาก pricing model หลากหลายแบบเพื่อประหยัดค่าใช้จ่าย
การปฏิบัติตามแนวทาง FinOps มีด้วยกัน 3 phase
- Inform นำข้อมูลค่าใช้จ่ายมาแสดงให้ทีมดู เช่น ผ่าน dashboard
- Optimize ทำการปรับระบบเพื่อลดค่าใช้จ่าย
- Operate เก็บ feedback ค่าใช้จ่าย ทำวนไป
ผู้พูดย้ำว่าแนวคิด FinOps นั้นมันไม่ได้มีสูตรสำเร็จที่ใช้ได้กับทุกองค์กร และเราสามารถเริ่มลงทำได้ตั้งแต่วันนี้โดยที่ไม่ต้องทำให้ครบ principle ทั้งหมด 6 ข้อ
Democratizing data access through LLM
ผู้พูดเริ่มด้วยการเล่าว่า แท้จริงแล้วประวัติศาสตร์สอนว่ามนุษย์เริ่มบันทึกและแบ่งปันความรู้กันมานานแล้ว ทำให้เกิดการเข้าถึงข้อมูลได้มากและง่ายขึ้น ส่งผลให้คนนำข้อมูลมาเชื่อมเข้ากับข้อมูลอีกอันเกิดเป็นข้อมูลใหม่ เกิดเป็นนวัตกรรมใหม่ ๆ เช่น Chabot เกี่ยวกับสังคมสงเคราะห์ทำให้คนที่ต้องการความช่วยเหลือในประเทศอินเดียสามารถเข้าถึงการช่วยเหลือได้ โดยเราสามารถเข้าถึงข้อมูลได้หลายรูปแบบ เช่น
- ตัวหนังสือ เช่น ChatGPT, OpenThaiGPT เป็นต้น
- เสียง เช่น feature การสรุปการประชุมใน Microsoft Teams เป็นต้น
- รูปภาพ เช่น image recognition เป็นต้น
- Software development เช่น การ generate SQL command จากคำถามภาษาคน เป็นต้น
พอพูดถึง Large Language Model (LLM) แล้วผู้พูดพาเรามาเข้าใจว่าทำไมมันถึงเก่งจัง โดยสิ่งที่มันทำคือ autocomplete ดี ๆ นี่เอง
- อ่าน wiki กับ web มาทั้ง internet แล้วถ้ามีคำเพิ่มขึ้นมาจะให้เพิ่มคำเข้าไ
- พอได้คำตอบมาเยอะมาก ให้แรงงานคนมาช่วยเลือกว่าคำตอบไหนดีที่สุด
ข้อจำกัดคือมันสามารถตอบได้แค่เฉพาะอันที่มัน train เท่านั้น
การที่ทุกคนสามารถเข้าถึงข้อมูลได้อย่างเท่าเทียมกัน (democratize) และ user สามารถเข้าถึงข้อมูลที่ผิดและอันตรายได้ ก่อให้เกิดความเสี่ยงต่าง ๆ สิ่งที่เราต้องมีด้วยคือ Guradrails ซึ่งมาในรูปแบบของ rule หรือ policy เพื่อเพิ่ม layer ขึ้นมาลดความเสี่ยง
LLM ของเรามันจะเก่งไม่เก่งก็ขึ้นอยู่กับ data ที่เอาไป train ด้วย ดังนั้นองค์กรควรจะมี platform ที่เอื้อให้คนค้นหาและเข้าถึง data ได้ง่ายขึ้น จึงเกิดเป็นแนวคิด Data Mesh ขึ้นมานั่นเอง
Legacy modernization made practical: A live coding example of modernization patterns
การบูรณะปฏิสังขร (modernize) ของเก่า โบราณ ได้รับตกทอดมาจากคนรุ่นก่อน (legacy) มีความยากเนื่องจากหลายสาเหตุด้วยกัน
- Business จะลงเรือไปกับเราไหม
- ทำแล้วจะรู้ได้ไงว่าระบบมันจะยังคง work ในอีก 2 ปีข้างหน้า
- ผลกระทบกับ user ล่ะ เรารู้มากพอไหม
มันจึงเปรียบเสมือนกับการผ่าตัดคนไข้ที่มันมีความเสี่ยงสูงต่อองค์กร หากทำผิดพลาดไปมากแล้วมีโอกาสที่จะไม่สามารถกลับมาอยู่ในจุดเดิมได้อีก ดังนั้นเราจึงต้องมีการวางแผนที่ดีก่อน
ระบุให้ได้ว่าอะไรที่(ไม่)คุ้มค่าแก่การบูรณะ
ในระบบ e-commerce legacy เราจะเห็นว่าแต่ละส่วนงานมันเหลื่อมทับกันไปหมด เนื่องจากว่ามีการแบ่ง domain ที่ไม่ชัดเจน อย่างเช่น
- Product ใน Inventory สนใจ SKU number, จำนวนคงเหลือ, เก็บไว้อยู่ที่ไหน
- Product ใน Storefront สนใจ ชื่อ, คำอธิบายประกอบ, รูปภาพประกอบ
การนำแนวคิด Domain-driven design มาช่วยจะทำให้เราเห็นรอยต่อและดึง domain ที่เหลื่อมกันแยกออกจากกัน
จากนั้นเราสามารถนำแนวคิด 7Rs เพื่อใช้ในการ migrate ระบบ legacy ได้ เพื่อระบุ domain ไหนที่เราอยากจะไปต่อ อยากจะซื้อสำเร็จรูปมาใช้แทน อยากจะออกแบบใหม่ หรือแม้กระทั่งอยากพอแค่นี้ ผลลัพธ์คือเราจะได้ลำดับความสำคัญและคุ้มค่าต่อการ modernize ของแต่ละ domain มานั่นเอง
แล้วจะเริ่มที่อันไหนก่อนดีล่ะ
ผู้พูดแนะนำให้ตั้งต้นจาก feature ใหม่ ๆ แล้วใช้โอกาสนี้ในการ modernize ไปด้วยเลย ถ้ามันกระทบส่วนไหน ก็ modernize ส่วนนั้นไปเลย เพื่อลดความเสี่ยงเราสามารถนำแนวคิดของ Thin slice planning โดยการ release ทีละส่วนเล็ก ๆ โดยที่ไม่ต้องทำให้ทุกอย่างเสร็จ เมื่อเราแบ่งออกมาได้หลาย ๆ มันก็จะได้เป็น roadmap คร่าว ๆ ให้เห็น ไม่ต้องแปลกใจหาก slice แรกจะยากและนาน เพราะต้องปูทางให้กับ slice ถัดไป ๆ ที่จะตามมาจะสามารถ reuse ของเดิมส่งผลให้มันไปได้เร็วขึ้นเรื่อย ๆ
เตรียมตัวก่อนผ่าตัด
ขั้นตอนการเตรียมตัวมีดังนี้
- Backup data และ version control ไว้ก่อน โดยมีด้วยกันหลายรูปแบบ เช่น One-off, On-demand, Initial with deltas, Change Data Capture (CDC)
- มีชุดการทดสอบอัตโนมัติเพื่อดักไม่ให้ระบบทำงานเปลี่ยนไปโดยได้คาดฝันไว้
- ตรวจสอบ code และ dependencies ด้วยเครื่องมือ code analysis และ static analysis ต่าง ๆ
- กินคำเล็ก ๆ ไปช้า ๆ อย่างปลอดภัยและแนะนำว่าอย่าทำคนเดียว อย่างน้อยควรมีคู่
ลงมือทำ
ใน talk นี้ผู้พูดได้มีการ demo วิธีการทำ modernization ด้วย technique CDC และ Strangulation pattern ทุกขั้นตอนจะมีการ deploy ขึ้น production ทุกครั้ง โดยรวมมีขั้นตอนคร่าว ๆ ดังนี้
- เพิ่ม proxy layer เพื่อเตรียมที่จะ configure ในการจัดการ request ที่ UI ส่งมาให้ค่อย ๆ โยกจาก legacy ไปหาระบบใหม่ แต่ตอนนี้ให้ชี้ request ทั้งการดึงข้อมูล (read operation) และการ update ข้อมูล (write operation) ไปที่ระบบ legacy ก่อน
- สร้าง Kafka และ CDC ด้วยเครื่องมือ Debezium (ตรงนี้มันจะมีรายละเอียดปลีกย่อยเรื่อง data schema ขอไม่พูดถึงในบทความนี้)
- พัฒนาระบบใหม่โดยมี application, database, และส่วน Kafka consumer ที่รับข้อมูลที่มีการ update ใน database เดิม
- สลับ request ที่เกี่ยวกับการดึงข้อมูล (read operation) ไปที่ระบบใหม่
- เมื่อทุกอย่างดูดีก็สลับ request ที่เกี่ยวกับการ update ข้อมูล (write operation) ไปที่ระบบใหม่ ตรงนี้มันจะมีประเด็นคือเราจะรู้ได้ไงว่าผลลัพธ์ของระบบใหม่มันจะเหมือนเดิมกับระบบเก่าหรือไม่ คำตอบคือไม่มีใครรู้ ดังนั้นเราสามารถนำ Scientist pattern มาใช้ในการทดสอบบน production ได้เลยเพื่อดูว่าข้อมูลที่ return ออกไปในระบบเก่าและใหม่มันเท่ากันหรือไม่
สิ่งสำคัญอีกอย่างคือการกลับไปสู่จุดเริ่มต้นว่าสุดท้ายแล้วมันคุ้มไหมนะ โดยเราสามารถนำ metrics ต่าง ๆ มาวัดผลและตั้งสมมติฐานกันตั้งแต่ก่อนเริ่มได้เลย โดยผู้พูดแนะนำให้ลองใช้ Modernization scorecard เป็นจุดเริ่มต้น
โดยสรุปแล้วการบูรณะปฏิสังขรมันยาก ใช้เวลานานและมีความเสี่ยงตลอดเวลา ดังนั้นเราควรจะต้องค่อย ๆ ไปอย่างช้า ๆ อย่างปลอดภัยโดยนำแนวคิดและแนวปฏิบัติที่กล่าวมาเพื่อถ้าเราพลาดแล้วก็ยังล้มบนฟูกโดยที่ไม่มีผลกระทบกับ business value และทำให้ IT และ business มาร่วมมือก้าวไปด้วยกันข้างหน้าอย่างมั่นคง
You should stop writing code
ผู้พูดเล่าให้ฟังว่าคุณภาพของ software เกิดจากการรวมกันของ 3 ส่วน
Software quality = Strategy + Design + Tech
ซึ่งพอพูดถึงเรื่อง tech เหล่า developer ก็จะดำดิ่งสู่ code กันทันที พร้อมกับหยิบทุก engineering practices มาประดับ แต่เมื่อเวลาผ่านไป
- อ่านและทำความเข้าใจ code ก่อน refactoring ก็แล้ว
- มีการ review code ทุกวันก็แล้ว
- มีการเขียนชุดการทดสอบก่อนเขียน code ก็แล้ว
- มีการนำ principle ทุกขนานมาใช้ใน code ก็แล้ว
ก็กลับมาตั้งคำถามกันว่า “ทำไมมันไม่เห็นจะดีขึ้นเลย นี่ขนาด code quality ดีเยี่ยมแล้วนะ” มันก็เริ่มตั้งแต่ก้าวแรกแล้วที่เราต้องหัดเขียน code ก่อน พอทำงานก็ต้องทำงานกับ code ตามพิธีกรรมที่กล่าวไปข้างบน
ผู้พูดเลยชวนมองว่า “แทนที่จะ focus ทั้งหมดไปที่ code ทำไมเราไม่ถอยออกมาดูภาพใหญ่บ้างล่ะ” เช่น
- เวลาที่เราบอกว่า code อ่านง่าย มันหมายถึงว่าเราสามารถสื่อสารให้คนเข้าใจได้อย่างดีโดยใช้ code เป็นสื่อกลางเท่านั้น
- การเขียน code เป็นเพียงจุดเล็ก ๆ ของการพัฒนา software และการจัดการ project เท่านั้น
ภาพใหญ่อีกอันนึงคือ engineering practices ต่าง ๆ ที่กล่าวมานั้นแท้จริงแล้วมันถูกออกแบบมาเพื่อแก้ปัญหาที่คน ไม่ใช่ปัญหาที่ code เช่น
- Domain Driven Design คือการเข้าใจคน (context) ให้มากขึ้น เพื่อออกแบบระบบให้ตรงกับปัญหา
- Test Driven Development คือการพัฒนาการทดสอบที่เริ่มจากเข้าใจการใช้งานของคน (user)
- Extreme Programming คือแนวปฏิบัติที่เน้นการทำงานร่วมกันของคน (ทีมพัฒนา)
- Agile คือแนวคิดที่เกิดมาเพื่อตอบสนองความต้องการของคน (customer)
- Design Thinking คือแนวคิดในการออกแบบที่เอาใจคนอื่นมาใส่ใจเรา
- Lean Startup คือแนวคิดที่ใช้ resource ให้เกิดประสิทธิภาพในการสร้าง business value ให้คน (customer) ให้เร็วที่สุด
แปลว่าแท้จริงแล้ว developer ก็คือคนในทีมที่มีความรู้ด้าน technical เท่านั้น สิ่งที่เราสามารถลงมือทำได้ตั้งแต่วันนี้เลยคือ
- มีส่วนร่วมในการพูดคุยแลกเปลี่ยนกับทีมและลูกค้าเพื่อสร้างความเข้าใจร่วมกัน
- เปลี่ยนวิธีการเรียนรู้จากเน้นที่ทำความเข้าใจ code เป็นเน้นที่ทำความเข้าใจคน
- มีความรับผิดชอบและรักษาความเป็นมืออาชีพ
ในขณะเดียวกันเราเปลี่ยนคนเดียวไม่ได้ องค์กรต้องเปลี่ยนไปกับเราด้วยโดยสามารถลงมือทำได้ตั้งแต่วันนี้เลยคือ
- ลดจำนวนการส่งสาส์นต่อไปเป็นทอด ๆ ด้วยการทำงานร่วมกันทั้งทีมและลูกค้าเพื่อบรรลุเป้าหมายเดียวกัน ซึ่งต้องปรับทั้งวิธีการสื่อสารและโครงสร้างขององค์กร
- สร้างสภาพแวดล้อมที่เอื้อให้เกิดความเชื่อใจกัน พนักงานเคารพซึ่งกันและกันไม่ขัดผลประโยชน์กันเอง
“Stop coding, Start communicating.”
Why organizations fail in investing in research and design (without Ops)?
จาก Adobe 2023 State of Work report ระบุว่าปัญหาหลักที่พวกเราคนทำงาน เจอกันมากที่สุดได้แก่
- ทำงานโดยสวมหลายบทบาทในคนเดียวกัน ทำให้ทำงานได้ไม่มีประสิทธิภาพ ขาด focus
- การทำงานร่วมกับผู้อื่นในรูปแบบ cross-functional เป็นเรื่องยาก
นอกจากนั้นแล้วเวลาที่ผู้พูดจัดงาน Design community meetup ขึ้นมาก็จะพบว่า 40–50% ของคนเข้าร่วมเป็น software engineer เนื่องจากพวกเขาก็อยากจะเข้าใจและค้นหาวิธีแก้ปัญหาเหล่านี้ ซึ่งพอเจาะลึกปัญหาเข้าไปดูก็พบว่าส่วนนึงคือ
Designer และ Researcher เจอปัญหามากมายที่ต้องลงมือแก้แทนที่จะเอาเวลาไปสร้าง business value
- งานเยอะ เวลาน้อย คนน้อย
- ต้องทำงานที่ไม่เกี่ยวกับงาน design ส่งผลให้ focus ไม่ได้ เลยผลิตงานที่ quality ต่ำลง
- Designer กับคนในทีมไม่คุยกัน หรือคุยก็คุยไม่รู้เรื่อง เช่น เวลา developer ต้องพัฒนาหน้า web application ไปถาม designer คนนึงบอกอย่างนึง อีกคนบอกอีกอย่างนึง!
- Developer ไม่ใช้สิ่งที่ออกแบบและพัฒนาไว้ใน design system ของเดิมอยู่แล้ว ทำให้ต้องลงมือทำใหม่เหมือนเดิมซ้ำ ๆ ซาก ๆ
- Designer ทำตามใบสั่งฟ้าประทานเลยได้งานที่ขัดกับ design ที่คนส่วนใหญ่คุ้นชิน
- Designer ไม่มีมาตรฐานให้ยึด ทำให้ต่างคนต่างออกแบบตาม style ตัวเอง ทำให้งานออกมาไม่ consistent กัน
เลยนำมาสู่แนวคิดและแนวปฏิบัติ DesignOps โดยมีนิยามว่า
“DesignOps is a set of practices, tools, and a cultural philosophy aiming to design efficient operational workflows from idea to customer’s hand by optimizing and amplifying interaction across the organization”
โดยที่ DesignOps นั้นมีใจความสำคัญเพื่อพัฒนาและปรับปรุง 5 สิ่งด้วยกัน
- Principle การปรับแนวคิดให้ทีมสามารถตัดสินใจได้เองโดยไม่ต้องพึ่งหัวหน้าหรือฟ้าประทาน
- People การฝึกฝนทักษะของคนให้เก่งขึ้น รวมถึงการ onboard คนเข้าสู่ทีม
- Process ที่มีมาตรฐาน มีแนวทางการตรวจสอบคุณภาพของ design ตลอดเวลา
- Tools ที่ดีมีมาตรฐานเดียวกัน ลด cognitive load ของคนใช้งานลง
- Performance วัดผลของทีมเราเพื่อนำ feedback มาปรับปรุงพัฒนาให้ดีขึ้นไป
สามารถเข้าไปอ่านเนื้อหาเพิ่มเติมได้ที่ blog นี้เลยครับ
Panel discussion: Agile in the modern age
ใน session สุดท้ายนี้ก็จะเป็นการพูดคุยกันโดยมีคำถาม-คำตอบที่น่าสนใจดังนี้
Q: ผู้นำในองค์กรต้องมีคุณสมบัติยังไง
- ควรจะรู้จัก Conway’s Law ว่าโครงสร้างขององค์กรมันสอดคล้องกับ software architecture ปัจจุบันที่มีอยู่ไหม
- ควรเปลี่ยนคำถามว่า “ทำได้หรือไม่ได้” ให้เป็น “ทีมต้องการ support อะไรไหม” แล้วมาทำงานด้วยกันเพื่อดูทีมเรื่อย ๆ บ่อย ๆ
- ควรจะกล้าที่จะ “ล้มเหลว” ในมุมมองของ software ว่าความผิดพลาดมันเกิดขึ้นได้และใช้เป็นบทเรียนในการปรับปรุงพัฒนาต่อไป
Q: มีวิธีการทำงานร่วมกันกับ vendor หลาย ๆ เจ้าโดยที่ยังยึดกับแนวคิด Agile ของเราได้ยังไง
- ผู้บริหารต้องเข้าใจ principle ของแต่ละ vendor ก่อนแล้วก็จัดกลุ่มตามความใกล้เคียงของ principle
- ทำให้ vendor มุ่งไปที่เป้าหมายเดียวกัน ไม่มีการแบ่งฝักแบ่งฝ่าย
- สร้างความเชื่อใจซึ่งกันและกันเพื่อสร้าง teamwork ไม่ใช่ว่าทุกคนทำงานด้วยกันได้ เป็น professional กันอยู่แล้วนิ!
Q: มีการเปลี่ยนวิธีการทำงาน remote working ยังไง
- Co-locate ให้ดีก่อนแล้วค่อย remote เพื่อจินตนาการให้ออกถึงอารมณ์ที่คนอื่นสื่อออกมา
- มี ceremonies ที่ทำให้คนเข้าหาเพื่อสร้างความเชื่อใจกัน เช่น retrospective, team bonding หรือแม้กระทั่งนัดกินข้าวด้วยกัน เป็นต้น
- สร้าง structure ให้ทุกคนในทีมใช้ channel เดียวกัน เช่น single team remote wall
- กำหนด roles & responsibilities ร่วมกันเพื่อทุกคนมีภาพตรงกันว่าใครทำอะไรเมื่อไร
นอกจากเรื่องเกี่ยวกับ XConf แล้ว ขอฝากบทความอื่น ๆ ให้ติดตามกันได้ทั้งภาษาไทยและอังกฤษด้วยนะ ขอบคุณที่เข้ามาอ่านกันนะครับ
