[ATH2017] Phoenix: How to come back from the dead by พี่แอมป์ Proteus

โดยพี่แอมป์, Frontend Architecture Team-Lead จาก Proteus Technology มาแชร์ประสบการณ์จากการไปรับงาน project ขององค์กรระดับ Enterprise ที่มี Multi-layer ขนาดใหญ่ ทำให้การทำงานไม่มีความคล่องตัว (Agility) เลยให้กลับมามี ความคล่องตัวอีกครั้ง เหมือน Phoenix ที่เกิดขึ้นใหม่ สำหรับใครที่ยังไม่รู้จักว่า Proteus เค้าเป็นใคร ลองอ่านบทความนี้ดูนะครับ


Ultimate Goal: โปรเจ็คที่ออฟฟิศต้องมี Agility มากพอที่จะ Deliver ของได้

Context & Background

Enterprise” คำนี้ที่ทุกคนหลายคนรู้จักและคุ้นเคยเป็นอย่างดี พอหลับตานึกถึงภาพเราจะเห็นปีระมิดของการแบ่งลำดับชั้นที่ชัดเจน แต่การแบ่งลำดับชั้นหน้าที่ชัดเจนนั้นก่อให้เกิดศัตรูสำคัญของ Agility นั้นก็คือ “Decision Making Hierarchy”

credit: https://www.forbes.com/sites/jacobmorgan/2015/07/06/the-5-types-of-organizational-structures-part-1-the-hierarchy/#2d0b471f5252

Decision Making Hierarchy

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

Development Team: ผมขอเปลี่ยนสีตัวอักษรจากสีขาวเป็นสีดำนะ
Client: รบกวนส่ง mail ให้หน่อยค่ะ เดี๋ยวหนูจะ forward ให้ Boss พิจารณา
Boss: รบกวนพี่ Head of Design ดูเรื่องการปรับสีหน่อยว่า trend สีเป็นยังไงช่วงนี้
Head of Design: เดี๋ยวผมถาม Branding ก่อนว่ามีผลกับ Brand มากน้อยแค่ไหน

นี่ Butterfly Effect หรือ การเปลี่ยนสีตัวอักษรเนี่ย สำหรับ Enterprise การตัดสินใจเป็นเรื่องยาก เพราะหากผู้น้อยตัดสินใจผิดพลาด ก็อาจจะก่อให้เกิดผลเสียต่อหน้าที่การงาน จึงเป็นเหตุให้ต้องให้เบื้องบนตัดสินใจ ก่อให้เกิดการรอคอยเป็นเวลานาน ซึ่งแน่นอน มันไม่คล่องตัว (Agility) ​เอาซะเลย

ทำให้ใน 6 เดือนแรกของโปรเจ็คนี้ เกิดเหตุการณ์สลดนี้ขึ้น

  • มีการ deploy แค่เพียง 9 ครั้ง (1.5 times/month)
  • มี Defect มากกว่า 300+ Issues
  • ต้องทำ OT แบบ Full-team ทั้งบริษัท 5 ครั้ง
  • การประสานงานกับลูกค้าเข้าขั้นแย่ ลูกค้าไม่ค่อยเชื่อใจ

แต่ปัจจุบัน 6 เดือนล่าสุดที่ผ่านมาของโปรเจ็คนี้ (2 ปีผ่านไป)

  • มีการ deploy 45 times/month
  • Defect เพียง 38 Issues
  • และไม่มี OT!
  • ลูกค้าเข้าใจ และรู้ว่าเค้าต้องวางแผนยังไง ถ้าอยากได้ของตามต้องการ

พวกเค้าทำได้อย่างไร เราจะได้รู้คำตอบกัน

Tune Agility — Bring Agility to project

Deployment

การทำงานกับ Enterprise หลายคนๆ มักจะประสบกับการต้อง VPN เข้าไปทำงานใน Server ของลูกค้า ซึ่งก็ Surprise!! ใช้ Docker ไม่ได้จ้าาาา ทำ Microservice ไม่ได้จ้าาาา ทางทีมจึงต้องจำใจกลับมาใช้ Monolith

สิ่งสำคัญที่ต้องคำนึงถึงคือ การ Setup Deploy Pipelines ขึ้นมา 
โดยให้ Step ในการทำงานสั้นที่สุด

ช่วงแรกที่ deploy ได้น้อยเนื่องจาก Pipelines ที่ไม่สมบูรณ์อีกทั้งความต่อเนื่องของ Task ใน Flow ถูกลูกค้าเข้ามา Interrupt ช่วงก่อน deploy มากเกินไป

ในมุมของลูกค้า เค้าก็อยากให้เนี๊ยบที่สุด 
แต่เราควรทำให้เค้าเห็นเร็วที่สุด เพื่อเก็บ feedback มากกว่า
“Deployment ไม่ใช่เรื่องของการใช้ tool แต่เป็นการทำให้ flow ไหลไปให้ไวที่สุด”

Measurement

“การวัดผลสำคัญ”
Q: วัดจากอะไรละว่าเราทำงานได้คล่องตัว 
A:ในแต่ละ Sprint ทำได้กี่ points (Velocity)
  • เราจะสามารถรู้ความสามารถของทีมจริงๆ ได้ก็ต่อเมื่อ Point ที่เห็นนั้นต้องไม่โดน Hack!
     OT, Over-estimate, การยืมตัวทีมอื่นมาช่วย นั่นคือการ Hack
  • นับจากวันที่ Card ใน Todo มาถึง Production ใช้เวลากี่วัน แต่การประเมินเวลาจะทำได้ก็ต่อเมื่อความเร็วของทีมจะต้องนิ่งก่อน และต้องไม่โดน Hack (ทีมพี่แอมป์ใช้เวลาประมาณ 4 วันต่อ Card)

Empowerment

“ถ้าฝั่งลูกค้านั้นซับซ้อน ดังนั้นเราต้องทำให้ทีมเราง่ายที่สุด”

ถ้าการตัดสินใจเป็นลำดับชั้นมันใช้เวลา เราก็แค่เอาลำดับชั้นนั้นออกไปซะ

  • ให้อำนาจ Tester ในการตัดสินใจเลือก Feature ไหนจะได้ขึ้น Production เพราะเรื่องของ Feature นั้นไม่มีใครรู้ไส้รู้พุงดีเท่า Tester
  • ให้โอกาส Developer คุยกับลูกค้า เพื่อให้ Dev เข้าใจงาน เข้าใจลูกค้า ทำให้งานออกมาดีขึ้นเรื่อยๆ อีกทั้ง Dev จะมีความภูมิใจในสิ่งที่ตัวเองทำ มีประโยชน์แก่คนอื่น

เมื่อภายในทีมมีอำนาจในการตัดสินใจเอง (Self-managed Team) จะทำให้ไม่จำเป็นต้องมี Manager มาทำหน้าที่ Management

“Dev ไม่ได้เพียงทำตาม Card แต่อ่านแล้วรู้ว่าทำไมเค้าถึงเขียน Card นี้ขึ้นมา”
หลังจากฟังเสร็จ หลายคนคิดในใจว่าอยากทำแบบนี้บ้าง
แต่การที่คุณจะทำแบบนี้ คุณต้องมีฐานที่แข็งแรง

Strong basements

“รากฐานที่ดีก่อให้เกิดความคล่องตัว”

Contract

มีตั้งสัญญาแบบรองรับการทำงานแบบ Agile หากลูกค้าไม่ชอบก็สามารถยกเลิกได้ทันที (ที่ Proteus มีการจ้างงานเป็นแบบ Sprint ต่อ Sprint และในการทำงาน Req 100 อย่างแรกจะถูกทำเพียง 10 อย่าง จากนั้น 90 อย่างนั้นจะถูกเอาออกแล้ว นำ 90 อันใหม่มาเรียงใหม่)

Focus

มี focus กับงานที่ทำ ไม่รับ 3–4 โปรเจ็คพร้อมกัน หรือ switch โปรเจ็คไปมา

Need

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

เลือกลูกค้าที่เค้าอยากได้จริงๆ เพราะสุดท้ายถ้าลูกค้าชอบก็จะใช้ดีแล้วบอกต่อ

“Tuning, not turning it takes time”

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