[Book Review] The Phoenix Project เพราะ IT Operation ก็ไม่ต่างกับ Production Plant

ผมรู้จัก The Phoenix Project มานานมากและมันวนเวียนมาเกือบจะได้อ่านหลายรอบ จนกระทั่งเมื่อประมาณกลางเดือนที่แล้ว ผมเพิ่งได้มีโอกาสจะหยิบมันขึ้นมาอ่าน และตั้งแต่ตอนนั้นผมแทบจะวางไม่ลงเลยตลอดระยะเวลาเกือบหนึ่งเดือนที่ผ่านมา และผมแนะนำให้กับทุกคนที่ทำงานใน IT ทั้ง Business และ Engineering ควรอ่านเลยครับ

The Phoenix Project เล่าเรื่องผ่านสายตาของ Bill Palmer - Manager ระดับกลางๆ ที่จับพลัดจับพลูถูกเลื่อนตำแหน่งขึ้นมาเป็น VP of IT Operations ใน Part Unlimited บริษัทขายชิ้นส่วนประกอบต่างๆ ของรถยนต์ที่กำลังเดิมพันกับ Phoenix Project ซอฟท์แวร์ตัวใหม่ที่จะช่วยกระตุ้นยอดขายและยกระดับบริการให้ล้ำหน้าคู่แข่งไปได้

ผมพยายามจะสปอยเนื้อหาให้น้อยที่สุดแต่ผมบอกได้ว่า เนื้อเรื่องในหนังสือเล่มนี้มันเข้มข้นมากทุกๆ อย่างมันถาโถมมาอย่างหนักหน่วงและ หลายๆ ครั้งมันตรงกับชีวิตจริง (ถ้าคุณทำงานใน Software Industry มานานพอ) ทุกๆ หน้าที่เรามองผ่านสายตา Bill และพยายามแก้ปัญหาที่เข้ามามันเหมือนกับว่าเราได้ไปนั่งอยู่ตรงนั้น ในห้องประชุม NOC หรือแม้แต่ที่ Production Plant จริงๆ และหลายครั้งตัวผมเองก็คิดไม่ออกว่าจะแก้ปัญหาที่เข้ามาในเรื่องยังไง

แต่สิ่งที่ผมนับถือที่สุดกับ Bill เลยคือความที่ Bill เป็นคนที่ Humble และ Empowered มาก ซึ่งเราจะเห็นได้จากหลายๆ ครั้งที่เวลาเจอปัญหาแล้ว Bill คิดไม่ออกแต่ทีมช่วยกันคิดออก Bill จะเปลี่ยนโหมดเป็น supporter ไอเดียนั้นทันทีและหลายครั้งก็ช่วย Facilitate ให้ไอเดียนั้นต่อยอดขึ้นไปอีก ในขณะเดียวกันหลายครั้งเราก็จะเห็น Bill จมไปกับความคิด กับไอเดียที่เกิดขึ้นจากเหตุการณ์ต่างๆ ที่ผ่านมาแล้วเกิด Aha! Moment ขึ้นด้วย ซึ่งนอกจาก Bill มีอีก 2 ตัวละครที่ผมอยากพูดถึงคือ Erik (Board Candidate), Brent (Lead Engineer)

Erik

ถ้าใครเคยดู Star Wars น่าจะคุ้นเคยกับคำว่า Master Jedi / Padawan ใช่มั้ยครับ ความสัมพันธ์แบบ Mentorship ระหว่างศิษย์กับครูนี่เป็นอะไรที่มีค่ามากๆ ซึ่งผมบอกได้เลยว่า เราจะโชคดีมากๆ ถ้าเรามี Mentor ในช่วงเวลาที่เรากำลังเริ่มอะไรใหม่บางอย่าง

ในเรื่องนี้ Erik นี่เป็น Mentor ที่ผมโคตรจะรักเลย วิธีการที่ Erik พยายามสอนให้ Bill เห็นว่า IT Operation มันไม่ต่างกับ Production Plant นั้นสำหรับผมคือมัน Care Personally เลย ซึ่ง Erik หลายครั้งมากที่จะไม่ให้คำตอบตรงๆ กับ Bill แต่จะให้คำใบ้ไว้ว่ามันจะเกิดอะไรขึ้นต่อไป

สำหรับผมนี่คือวิธีการสอนที่ดีมาก เพราะมันทำให้เราต้องคิดเยอะมากและพอมันเกิด Aha! Moment ที่เราคิดออก เรื่องนี้มันจะติดอยู่ในหัวเราไปอีกนานเลย และผมเชื่อว่าถ้าใครเคยมี Mentor ลักษณะนี้ในชีวิตหน้าเค้าต้องลอยขึ้นมาหลังจากคุณได้อ่านสิ่งที่ Erik คุยกับ Bill ครับ

Brent

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

ซึ่งมันทำให้ผมรู้จักคนประเภทนี้ดีมาก เพราะคนประเภทนี้จะงานยุ่งทุกอย่างตลอดเวลา แก้ปัญหาได้ทุกอย่าง (หลายๆ ครั้งก็สร้างปัญหาใหม่ตามมาด้วย) ที่ผมไม่ชอบคือ คนประเภทนี้จะลืมสิ่งที่สำคัญมากๆ ในการทำงานเป็นทีมไปคือการสร้าง Tribe Knowledge กับ Delegate ครับ และสุดท้ายก็จะเป็นคอขวดจนหลายๆ อย่างเดินต่อไปไม่ได้ เพราะต้องรอคนๆ นี้

ท่ามกลางความเข้มข้นของเนื้อเรื่องใน The Phoenix Project จะมี Core Idea อยู่ 2 เรื่องหลักๆ คือ 4 Types of Works และ The Three ways ครับ

src: https://hennyportman.wordpress.com/2016/03/20/book-review-the-phoenix-project-a-novel-about-it-devops-and-helping-your-business-win/

4 Types of Works

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

• Business Project — เป็นงานประเภทที่เราได้ requirement มาจาก Business Unit เพื่อตอบโจทย์บางอย่างของบริษัทซึ่งนี่คืองานหลักที่ Business ต้องการจากทีม IT
• Internal Project — งานประเภทนี้ไม่ได้ Drive มาจาก Business แต่เป็นความรับผิดชอบของทีม IT เองและทีม IT ต้องต่อสู้เพื่อให้ได้ Priority มา ซึ่งถ้าไม่ทำเราก็จะทำงานกันเองลำบากขึ้นเรื่อยๆ งานประเภทนี้เป็นจำพวกเช่น Patch Security, Upgrade Server, Storage, Network ฯลฯ
• Change — งานอย่างจาก Business Project, Internal Project หลายครั้งมันไม่ได้ทำรอบเดียวจบ เพราะอาจจะทำไปแล้วรู้ว่ามันไม่เวิร์คหรือมีการเปลี่ยน Requirement งานประเภทนี้จะไม่ยิ่งใหญ่เท่า Business Project หรือ Internal Project แต่ก็ต้องทำ เพราะไม่งั้น Business ก็ไปต่อไม่ได้
• Unplanned Work — งานข้างบนทั้ง 3 ประเภทที่พูดมา มักจะมี Timeline ที่ Business อยากได้หรือเราไปต่อรองมาครับ แต่เหตุผลหลักที่ทำให้งาน 3 ประเภทข้างบนมัน Delay หรือไม่ได้ทำซักที เพราะงานประเภทที่ 4 นี้ซึ่งก็คืองานที่อยู่ดีๆ ก็โผล่มาครับ อาจจะเป็น Server ระเบิด, ต้องแก้ Security patch ด่วนๆ (อารมณ์เหมือน log4j ล่าสุด) หรือต้องทำ Report ส่ง Audit อะไรแบบนี้เป็นต้นครับ

ซึ่งในแต่ละโปรเจ็ค เราก็จะมี Constraint หลักๆ อยู่เช่นเรามีคนที่ทำเรื่องนี้ได้แค่คนนี้จริงๆ และคนนี้ติด Business/Internal Project อยู่ ซึ่งหน้าที่ของ IT Manager เลยคือ พยายามลด Unplanned Work ให้ไปกระทบกับ Constraint ให้น้อยที่สุดเพราะมันไม่ได้สร้าง Business Value เลยโดย Practice ที่ผมเห็นใช้ในหนังสือคือ พยายามจะ Visualize งานต่างๆ ออกมาให้หมด (เพราะก่อนหน้านี้แทบไม่รู้เลยว่าต้องทำอะไรบ้าง รู้แต่ว่าทุกคนยุ่งมากๆ) แล้วจัดการ flow ของมัน ทีมของ Bill เลยเริ่มที่จะเอาอยู่ครับ

ซึ่งเรื่อง Constraint ในหนังสือเรื่องนี้ Refer กลับไปหา Theory of Constraints ของ Dr.Goldratt ในหนังสือ The Goal โดยแบ่งเป็น 5 ขั้นคือ

1. หา Constraint ใน Flow ให้เจอก่อน
2. พยายามทำความเข้าใจ Constraint นั้น
3. กันกิจกรรมอื่นๆ ไม่ให้ไปกระทบ Constraint
4. พยายามปรับปรุง Constraint นั้นให้ดีขึ้น
5. หา Constraint ใหม่ต่อไป

The Three Ways

ส่วนของ The Three Ways ผมขอยก Quote จากหนังสือตอน Erik อธิบาย Bill ถึง The Three Ways มาทั้งก้อนเลยละกันครับ ตรงไปตรงมาดี

“The First Way helps us understand how to create fast flow of work as it moves from Development into it Operations, because that’s what’s between the business and the customer.

The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework.

And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery.”

Erik

ซึ่งก็จะพาเรามาหาไอเดียหลักในเรื่องอีกอย่างนึงคือ IT Operation เนี่ยมันคล้ายกับการจัดการสายการผลิตมาก ลองนึกภาพดูนะครับ สายการผลิตเริ่มจากมี Raw material วิ่งเข้ามาในสายพาน เสร็จแล้วแต่ละส่วนก็ Transform มันให้เป็นชิ้นส่วนบางอย่างเฉพาะทาง แล้วก็จะมีอีกส่วนที่รวมชิ้นส่วนต่างๆ เข้าด้วยกันเพื่อเป็นผลผลิตที่ซับซ้อนกว่า ไปจนจบแล้วได้ชิ้นงานไปขายได้

งานของ IT Operation อย่างที่เราเห็นข้างบนมีงาน 4 ประเภทวิ่งเข้ามา แล้วเราต้องกระจายไปในทีมต่างๆ ที่ดูแลอยู่ เช่น จะสร้าง Production Server ใหม่ให้กับ Business Project ก็เริ่มจากต้อง Estimate load ขึ้นมา บอกจัดซื้อให้หาของมาให้ (ยังไม่ Cloud) เสร็จแล้ว Engineer ก็ประกอบ Hardware เข้าด้วยกันทั้ง Compute, Network, Storage พอชั้น Hardware เรียบร้อยก็ต้องติดตั้ง Software dependency อย่าง OS, Database, Runtime เรื่อยไปจนถึงติดตั้ง Application แล้วแมพ Network ทำ Smoke tests ก่อนที่จะ Release ให้ลูกค้าใช้งานได้

ภาพจากเกม Assembly Line บน Android

ซึ่งการทำความเข้าใจว่า Operation เราทำงานยังไงนี่เป็นแค่ The First way เท่านั้นครับ ในส่วนของ The Second way จะเป็นเรื่องการ Optimize flow ของเราให้มันมีประสิทธิภาพที่สุดซึ่งก็จะอาศัย Practice หลายๆ อย่างเช่น Theory of Constraint, Managing WIP หรือ Automation มาช่วย เพื่อลด Feedback loop ให้ได้มากที่สุดและ Improve มันจาก Feedback นั้น

ผมเคยมีคำถามนะ ถ้าทุกๆ อย่างมันดีขึ้นแล้ว เอาอยู่แล้ว เราจะทำอะไรได้อีก คำตอบอยู่ใน The Third way ครับ ซึ่งผมพูดเลยว่า “ในช่วงเวลาที่เราคิดว่าทุกอย่างมันดีอยู่ อาจจะมีอะไรบางอย่างมาทำลายสิ่งนั้นได้เสมอ ถ้าเราไม่เตรียมพร้อมตลอดเวลา”

สิ่งที่จะช่วยลดความเสี่ยงในอนาคตรวมถึงเป็นหลักประกันว่าเราจะเอาอยู่ในอนาคตคือ การที่เราเตรียมพร้อมตลอดเวลาโดยใช้ Practice อย่าง Chaos Engineering, Hackathon, Community of Practice ฯลฯ มาช่วยเพื่อที่จะรับมือการดับไฟในอนาคตครับ

Conclusion

ถ้าคุณชอบ The Five Dysfunctions of a Team ของ Patrick Lencioni คุณจะชอบหนังสือเล่มนี้ เพราะนอกจากวิธีการเล่าเรื่องที่ทำให้เราติดได้แบบ Cover to Cover ต้องยอมรับว่า Outcome ที่ได้จากการอ่านหนังสือเล่มนี้มันเยอะมากจริงๆ

สิ่งที่ผมอยากจะย้ำอีกครั้งคือ หนังสือเล่มนี้ออกมาตอนปี 2013 ในโลกที่ Business เริ่มจะคิดได้ว่า IT สำคัญแค่ไหนกับองค์กร แต่ยังไม่รู้จะทำยังไงและการคิดว่าจะถ่ายทอดมันยังไงยิ่งยากไปใหญ่ และหนังสือเล่มนี้มันทำได้ครับ

อย่างไรก็ตามถึงแม้ว่าปีนี้จะปี 2021 แล้ว แต่จากประสบการณ์ผมหลายๆ องค์กรยังไม่สามารถที่จะทำให้เกิด The Three Way ได้ครับ แต่ก็ง่ายขึ้นกว่าตอนหนังสือออกมาตอนปี 2013 มาก แต่อุปสรรคในเรื่องนี้จริงๆ ไม่ใช่ Tech ครับ แต่มันอยู่ที่ Culture ซึ่งหลังจากอ่านจบผมเชื่อว่า หนังสือเล่มนี้ทำให้คนเห็นภาพได้ คนที่มีอำนาจตัดสินใจได้เข้าใจภาพได้มากขึ้นว่า IT Operation มันสำคัญกับ Business แค่ไหน

และสุดท้ายในหนังสือจะมีการพูดถึง Talk ของ John Allspaw กับ Paul Hammond เรื่อง 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr ส่วนตัวผมมีโอกาสไปดูมาแล้วแล้วมันเป็น talk ที่ดีมากๆ อันนึงเลยครับ อยากให้มีโอกาสได้ฟังกัน