เรื่องมันเศร้าขอเหล้าเข้ม ๆ ตอนที่ 2 อิฐ (IT)
เรื่องนี้เป็นเรื่องที่ถูกแต่งขึ้น ทั้งชื่อและเนื้อหาล้วนเป็นเรื่องที่ผมแต่งอุปโลกน์ขึ้นมาเองเพื่อสร้างความบันเทิงและอาจจะนำเสนอมุมมองใหม่ ๆ เท่านั้น ไม่มีเค้าความจริงแต่อย่างใด
Continuous attention to technical excellence and good design enhances agility.
อิฐเป็นสกรัมมาสเตอร์ที่เติบโตมาจาก technical lead อิฐรักการเขียนโค้ด หมั่นหาความรู้ ฝึกฝนและพัฒนาฝีมือตัวเองให้เก่งยิ่ง ๆ ขึ้นไป ในบรรดา Agile principle ทั้ง 12 ข้อ ข้อที่โดนใจอิฐเป็นที่สุดก็คือข้อด้านบน
ตั้งแต่อิฐเรียนจบมาทำงานเป็นโปรแกรมเมอร์ อิฐก็เชื่อว่าการเขียนโค้ดเป็นงานฝืมือ ซึ่งก็เหมือนกับงานฝืมือ (craftmanship) อื่น ๆ คือ ช่างฝีมือใช้เวลาส่วนใหญ่กับการฝึกฝนและพัฒนาฝีมือ และชื่อเสียงของช่างฝีมือจะถูกกำหนดโดยผลงานที่ออกมาจากช่างฝีมือนั้น
พอเวลาผ่านไป อิฐก็พบว่าในวงการซอฟต์แวร์ มีหลายคนที่ไม่ได้มองการเขียนโค้ดเป็นงานฝีมือ อย่าว่าแต่ฝึกฝนเลย แค่เก็บประสบการณ์ในแต่ละวันที่ผ่านไปยังทำไม่ได้ด้วยซ้ำ พวกเขาทำงานด้วยความหวาดระแวง ไม่รู้ว่าไฟจะลุกบน production ขึ้นมาเมื่อไหร่ ต้องทำงานไปพะวงหลังไป พอเสียเวลาไปดับไฟมากขึ้น งานที่ทำก็ยิ่งเสร็จไม่ทัน ยิ่งต้องเผา ต้องลวกให้มันผ่านไป แล้วไฟก็ไปลุกบน production อีกเป็นวัฏจักรเรื่อยไป
อิฐไม่อยากเห็นงานเขียนโค้ดที่เค้ารักเป็นวัฏจักรที่ดูดพลังชีวิตคนแบบนี้ อยากส่งต่อมุมมองที่สวยงามของการเขียนโค้ดให้กับคนอื่น ๆ เลยเกิดแรงบันดาลใจที่จะสร้างสิ่งแวดล้อมที่คนทำงานจะเข้าถึงความสนุกของการเขียนโค้ดได้มากขึ้น และเริ่มเรียนรู้และฝึกฝนเพื่อผันตัวเองมาเป็นสกรัมมาสเตอร์
ในงานโค้ชของอิฐ อิฐให้ความสำคัญกับ technical excellence อิฐใช้การ pair กับสมาชิกในทีมเพื่อสร้างความสัมพันธ์ และถ่ายทอดความรู้และเพื่อพูนทักษะให้กับสมาชิกในทีม ช่วยให้สมาชิกได้เรียนรู้มากที่สุดในแต่ละวันที่ผ่านไป
อิฐบอกทีมที่เค้าโค้ชเสมอ ว่าสมัยนี้ zero defects ไม่ใช่เรื่องในฝัน สมัยนี้เทคโนโลยีและ engineering practice ทั้งหลายมันเอื้อให้เราทำแบบนั้นได้อยู่แล้ว ทั้ง Specification by Example, Test Driven Development ถ้าเราเขียน automate test ในทุก ๆ คุณค่าที่เราจะส่งมอบให้กับลูกค้า และเรา ship product ที่ผ่าน automate test ทั้งหมดมาแล้วเท่านั้น defect จะเกิดขึ้นได้อย่างไร?
วันหนึ่ง ขณะที่อิฐกำลัง pair กับน้องปอสมาชิกคนหนึ่งในทีมจนหมดเวลางาน
อิฐ: วันนี้หมดเวลางานแล้ว เราค่อยมาต่อกันพรุ่งนี้ดีไหม? เขียน failing test ค้างไว้หนึ่งอัน พรุ่งนี้จะได้มาต่อง่าย ๆ
น้องปอ: พี่ พี่รีบกลับไหม ผมขอปรึกษาอะไรพี่หน่อยได้ไหม?
อิฐ: ได้สิ มีอะไรเหรอ?
น้องปอ: มันยากมากไหมพี่ กว่าจะเก่งได้อย่างพี่ ผมอ่ะท้อมากเลย มันมีทั้งเฟรมเวิร์ค ทั้งภาษาใหม่ ๆ ออกมาเต็มไปหมด ผมอ่านอันเก่ายังไม่ทันหมด อันใหม่ก็ออกมาแล้ว ยิ่งพยายามอ่าน พยายามฝึก ก็รู้สึกว่ากำแพงที่จะปีนมันยิ่งสูงขึ้น ๆ จนไม่รู้ว่าวันไหนจะได้เห็นขอบกำแพง หรือว่าผมจะไม่เหมาะกับงานสายนี้อ่ะพี่?
อิฐเงียบไปพักใหญ่ ๆ ก่อนจะบอกน้องว่า “เรื่องที่ปอเล่ามา พาพี่ย้อนกลับไปตอนที่พี่จบออกมาใหม่ ๆ พี่ก็ท้อแบบนี้เหมือนกัน”
“อย่างพี่เคยเป็นแบบผมด้วยเหรอ?” ปออดไม่ได้ที่จะถามแทรกออกมา
อิฐเล่าต่อว่า “เป็นเยอะเลยแหละ สมัยก่อน ยังไม่มี stack overflow ไม่ใช่ว่าจะติดอะไรก็จะค้นหาคำตอบได้ง่ายแบบทุกวันนี้ สมัยนี้การเข้าถึงข้อมูลเนื้อหาต่าง ๆ มันง่ายขึ้นมาก สมัยก่อนพี่ลำบากกว่านี้อีก แล้วพี่ก็ท้อแบบที่น้องท้อนี่แหละ จนกระทั่งไปเจอบทความหนึ่ง ชื่อว่า bad know-how, good practice อยากฟังรายละเอียดไหม?”
ปอพยักหน้าหงึก ๆ
“เค้าเล่าว่า การฝึก know-how หรือ framework ซักตัว แล้วสุดท้ายเทคโนโลยีนั้นก็ตายไป ทำให้ความรู้เกี่ยวกับเทคโนโยนีนั้นไม่มีประโยชน์อีกเลย นับเป็น bad know-how ก็ได้ เพราะความรู้นั้นเอาไปใช้ประโยชน์ต่อไม่ได้แล้ว อย่างไรก็ดี ขั้นตอนที่เราทำความเข้าใจ และเรียนรู้เทคโนโลยีนั้น ถือเป็น good practice นั่นคือในอนาคต ถ้าเราเจอเทคโนโลยีที่คล้าย ๆ กัน กล่าวคือกลไกภายในทำงานเหมือน ๆ กันกับเทคโนโลยีนี้ เราจะเรียนรู้มันได้ง่ายขึ้นมาก เราจะรู้ทั้งจุดแข็ง จุดอ่อน ข้อจำกัดทั้งหลายได้ในเวลาอันสั้น เพราะในหัวเราก็จะคิดว่า อ๋อ คล้าย ๆ กับตัวนี้เลย
สาเหตุวันแรกที่พี่พาเรา refactor โค้ด dart ได้ ทั้ง ๆ ที่พี่บอกว่าพี่ไม่เคยเขียนมาก่อน ก็เพราะแบบนี้แหละ มันคล้าย ๆ กับภาษาที่พี่รู้จักมาก่อน” อิฐกล่าว
แล้วอิฐก็เติมกำลังใจให้ปอต่อว่า “อดทนฝึกต่อไปนะ วันนี้ที่เราอ่านช้า เพราะ good practice เรายังไม่มากพอ ฝึกฝนต่อไป แล้วเราจะอ่านและเรียนรู้ได้เร็วขึ้น ๆ จนวันหนึ่งก็จะทันเทคโนโลยีที่ออกมาใหม่ และในอนาคต เราอาจจะแต่มองปราดเดียวก็เข้าใจแล้ว แทบไม่ต้องเสียเวลาศึกษาด้วยซ้ำ
เวลาที่เราทุ่มเทลงไปกับการฝึกฝน มันจะไม่ศูนย์เปล่าหรอก และรู้อะไรไหม ตัวปอตอนนี้ เก่งกว่าพี่ตอนอายุเท่าปอหลายเท่าเลยนะ พี่นี่นึกภาพไม่ออกเลยว่าตอนปออายุเท่าพี่จะเก่งขนาดไหน”
ปอ: โหย พี่ก็ยอเกินไป ผมคงไม่มีวันเก่งเท่าพี่หรอก
อิฐ: พี่เจอสมาชิกของทีมที่พูดกับพี่แบบนี้มาหลายคนละ พอผ่านไปอีกไม่ถึง 2 ปี พอพี่ไปขอ pair ด้วย เค้าก็บอกพี่ว่า ตอนนี้ผมรีบครับพี่ พี่ไปเล่นกับคนอื่นก่อนนะ ไว้ผมว่างเดี๋ยวผมจะกลับมา pair ด้วยทุกคนไป
ทั้งคู่หัวเราะแล้วก็แยกย้ายกันไป
สองปีผ่านไป รูปแบบเหตุการณ์ที่อิฐเจอมาซ้ำแล้วซ้ำเล่าก็เกิดขึ้นอีก ปอที่ได้เขียนโค้ด ใช้เวลากับการฝึกฝน ทำมันทุก ๆ วัน ก็ชำนาญจนวันนี้การ pair กับอิฐ ไม่ได้ทำให้ปอทำงานเร็วขึ้นอีกต่อไปแล้ว อาจจะได้เพิ่มพูนความรู้จากการแบ่งปันประสบการณ์ของอิฐมา แต่ไม่ได้ช่วยให้ทำงานเสร็จเร็วขึ้นเลย ฉะนั้น ปอก็จะเลือก pair กับอิฐใน sprint ที่งานไม่เดือดมากเท่านั้น
product ที่ทีมปอทำ เป็น product ที่ได้รับรางวัล ว่ามี defect น้อยที่สุดในองค์กร แม้จะไม่ถึงกับเป็น 0 defects เพราะ automate performance test ก็ยังไม่นับอยู่ใน definition of done ของทีมปอ แต่ก็มี defects เป็นหลักหน่วย ซึ่งทิ้งห่าง product ที่มีคุณภาพดีอันดับ 2 เป็นหลักพัน
ทีมของปอเป็นทีมที่ไม่ต้องทำงานไป พะวงหลังไปว่าจะมี defect จาก production มาขัดจังหวะการทำงานไหม เรียกว่าการได้โค้ชทีมนี้ถือเป็นการเติมเต็มความฝันของอิฐเลยก็ว่าได้
คุณค่าสูงสุดที่อิฐคิดว่าได้ส่งมอบให้กับองค์กร ไม่ใช่ product ที่แทบจะไม่มี defect แต่เป็นสิ่งแวดล้อมแห่งการเรียนรู้ สมาชิกทุกคนในทีมล้วนได้ feedback จากของที่ตัวเองทำอย่างรวดเร็ว ซึ่งเอื้อต่อการเรียนรู้อย่างก้าวกระโดด เหตุการณ์ที่ทำให้คุณค่าของสิ่งแวดล้อมนี้สะดุดตาอิฐก็เมื่อน้องเอกซึ่งเป็นเด็กจบใหม่เข้ามาร่วมทีม น้องเอกใช้เวลาใน 2 sprint แรก pair กับอิฐบ้าง กับพี่ ๆ คนอื่น ๆ ในทีมบ้าง แต่พอเข้า sprint ที่ 3 เอกก็เริ่มทำงานง่าย ๆ เสร็จได้ตามลำพัง อย่างมากก็แค่หันไปถามพี่ ๆ บ้างเมื่อเจอของใหม่ที่ตัวเองไม่รู้จักมาก่อนเท่านั้น
นอกจากนี้ turn over rate ของทีมนี้ต่ำมาก แม้ความเก่งกาจของพวกเค้าจะทำให้พวกเค้ามีชื่อเสียง และเนื้อหอมมากในตลาดเป็นธรรมดา แต่ไม่มีใครย้ายทีมไป แม้ว่าอิฐจะได้รู้ว่าสมาชิกบางคนได้รับ offer ที่ดีกว่าที่ตัวเองได้อยู่ก็ตาม
อิฐลองถามสมาชิกเหล่านั้นว่าอะไรที่ดึงดูดเค้าไว้ให้เค้าอยู่ในทีมนี้ต่อ และคำตอบส่วนใหญ่ก็จะเป็นบรรยากาศการทำงาน กับการได้เรียนรู้จากโค้ดของพี่ ๆ เพื่อน ๆ ในทีม
สิ่งนี้ตอกย้ำความเชื่อหนึ่งของอิฐก็คือ โค้ดสวย ๆ และเพื่อนร่วมงานเก่ง ๆ นั้น เป็นสวัสดิการที่ล้ำค่ากว่าสิ่งไหน ๆ สำหรับช่างฝีมือ
แม้ทีมนี้จะไม่มีปัญหาเรื่องคุณภาพการทำงานเลย แต่สิ่งที่ทำร้ายจิตใจทีมนี้ที่สุดคือการได้เห็นว่าของที่ตัวเองบรรจงสร้างไปนั้นถูกทิ้ง เพราะ direction ของ business เปลี่ยนแปลง
“ทำไมเค้าไม่ตกลงกันมาให้เสร็จก่อนนะ ว่าจะไปทางไหนกันแน่”
“ตอนจะเอาก็บอกว่ารีบ พวกเราเร่งทำให้แทบตาย สุดท้ายทิ้งซะงั้น”
“ในขณะที่พวกเราพัฒนาและปรับปรุงตัวเองอยู่เสมอ ทำไมพวก business ถึงไม่ทำบ้าง?”
เป็นเสียงบ่นที่อิฐได้ยินจากทีมบ่อย ๆ จากทีม อิฐสังเกตเห็นถึงกำแพงที่แบ่งพวกฉันพวกเธอ ซึ่งอิฐรู้ดีกว่า การแบ่งพรรแบ่งพวกแบบนี้ ไม่ช่วยให้ทีมสามารถแก้ปัญหานี้ได้อย่างสร้างสรรค์
อิฐกลับมาย้อนมองดูว่าเส้นแบ่งนี้เกิดจากอะไร
Product owner ไม่ได้มีอำนาจตัดสินใจ
เนื่องจาก product owner ของทีมที่อิฐดูแลมีตำแหน่งเป็น sytem analyst ภายในองค์กร ฉะนั้นงานที่เข้ามาก็จะมาแบบ fixed time fixed scope แล้ว หน้าที่ของทีมจึงมีแค่ deliver product ออกไปให้เร็วที่สุด ด้วยคุณภาพที่สูงที่สุดเท่านั้น
focus ของทั้งทีมก็จะสะท้อนไปกับ focus ของ หัวหน้าของฝ่ายไอทีนั่นคือ ผลิตของออกไปให้เร็วที่สุด และระบบที่เสถียรที่สุด และเมื่อไหร่ที่ทีมมีความเห็นเรื่องของที่ถูกเลือกเข้ามาใน sprint จะคุ้มที่จะทำไหม หรือมีวิธีการที่ดีกว่าที่จะแก้ปัญหาเดียวกันให้กับลูกค้า ก็จะรู้สึกได้ถึงกำแพงที่ปิดกั้นความคิดเห็นไม่ให้ไปถึงคนตัดสินใจ
ทั้ง ๆ ที่ product owner รู้อยู่แล้วว่าฝ่าย business มักจะร้องขอซ้ำ ๆ ว่าอยากให้ฝ่ายไอทีแนะนำ solution ที่ดีกว่าในฐานะผู้เชี่ยวชาญ แต่ในบริบทที่ deadline มักถูกปักมาแล้วอย่างกระชั้นชิดเหลือเกิน ครั้นจะไปเรียกฝ่าย business และฝ่ายไอทีอื่น ๆ ที่เกี่ยวข้องมาประชุม solution ใหม่นั้น เป็นทางเลือกที่กลืนยากจริง ๆ
และด้วย product owner ไม่ได้มีอำนาจในการตัดสินใจจริง ๆ พอ direction เปลี่ยน product owner ก็ต้องบากหน้าไปบอกทีมว่าของที่ขอร้องให้ทีมรีบทำก่อนหน้านี้ ไม่ต้องทำต่อแล้ว ซึ่งเป็นงานที่ยากจริง ๆ
Component ทีม
โครงสร้างของทีมที่อิฐดูแล เป็นเหมือนทีมทั่ว ๆ ไปในแผนกไอที นั่นคือโครงสร้างของทีมจะสะท้อนโครงสร้างของระบบ ซึ่งทีมที่อิฐดูแลก็นับเป็น component หนึ่งของระบบที่ต้องติดต่อกับระบบอื่น ๆ
เพื่อลด overhead ในการ synchronize แผน ทุกคนจึงต้องทำตาม commitment ที่ได้รับมาในส่วนงานของตัวเอง เพราะการส่งมอบคุณค่าให้กับลูกค้านั้น จะเกิดขึ้นไม่ได้ถ้าขาดงานส่วนใดส่วนหนึ่งไป ทุก ๆ ทีมเลยอยู่กับ deadline ของ output มากมาย และมันยากมากเลยที่จะมองเห็นว่างานชิ้นไหน กำลังแก้ปัญหาอะไรให้กับลูกค้า การสลับลำดับความสำคัญตามสถานการณ์ที่เปลี่ยนไปเลยเกิดขึ้นยากมาก
พอเห็นดังนี้ อิฐก็พยายามอย่างมาก ที่ร่วมมือกันกับ product owner ที่จะเปิดโอกาสให้ทีมเข้าไปมีส่วนร่วมคิดแก้ปัญหาก่อนที่จะมาเป็น system requirement เข้ามาให้ทีมทำ อย่างไรก็ดี ความพยายามของอิฐก็ไม่ประสบผลดังหวัง จนทำให้อิฐนึกถึงบทเรียนที่ตัวเองเคยเห็นผ่านตาตอนเรียนรู้ที่จะเป็นสกรัมมาสเตอร์ขึ้นมา
Structure precedes culture.
อาจารย์ของอิฐเคยสอนไว้ว่า ให้มองวัฒนธรรมเป็นเหมือนต้นไม้ ถ้าอยากให้วัฒนธรรมอะไรเบ่งบาน ก็ต้องปรับกระถางหรือโครงสร้างให้เหมาะสมกับการให้วัฒนธรรมเหล่านั้นเบ่งบานก่อน ค่อยไปออกแรงพรวนดิน รดน้ำ การพยายามสร้างวัฒนธรรมก่อนปรับโครงสร้าง เหมือนตำน้ำพริกละลายแม่น้ำ ทำเท่าไหร่ก็ไม่มีวันเสร็จ
ถึงตรงนี้ อิฐก็นึกถึงเพื่อนสกรัมมาสเตอร์ร่วมอาชีพของตนเองคนหนึ่งชื่อนนท์ นนท์บอกอิฐเสมอ กว่าก่อนจะเข้าไปโค้ชที่ไหน สิ่งสำคัญที่สุดคือจับคนที่รู้ business กับคนรู้ไอทีมานั่งทำงานข้าง ๆ กันทุก ๆ วัน
ขณะที่อิฐกำลังจะนึกจะโทรหานนท์นั้น ก็ได้ยินเสียงมือถือก็ดังขึ้นมา แล้วเห็นว่านนท์กำลังโทรมาหาพอดี
