One Team Mindset ตอนจบ

สวัสดีเช้าวันจันทร์ที่ 21 ตุลาคม พ.ศ. 2556 เข้าสู่ช่วงปลายฝน ต้นหนาว แล้วแม้น้ำจะยังท่วมอยู่ในหลายๆ จังหวัดของประเทศไทยเรา เช้าวันนี้เลยนำตอนจบของ One Team Mindset มาให้เสพกันต่อ

อาจจะลืมไปว่า ตอนที่ 1 เป็นอย่างไรก็

ความเดิมจากตอนที่แล้ว ไปอ่านที่ One Team Mindset ตอนที่ 1

Let’s ดราม่า ดำเนินต่อไป…

ลองจินตนาการตามดูครับถ้า QA ทำยังไงก็ได้ให้ product สามารถ release ออกไปได้เร็วสุดด้วย acceptable quality (ไม่ใช่ว่าเป้าหมายคือแค่ high quality นะ แต่อันนี้มี speed ของการ deliver เข้ามาด้วยและผมใช้คำว่า acceptable quality ไม่ใช่ high quality) ยกตัวอย่างเช่นเข้าไปช่วย Dev คิด Unit test cases เพราะเราอยากเจอบั๊กตอน system หรือ integration test ให้น้อยที่สุด นอกจากนี้ยังทำเทสโดยคำนึงถึง impact กับ customer มากกว่าการทำเทสแบบให้เจอบั๊กให้มากที่สุด (ประมาณว่ายิ่งเจอบั๊กเยอะยิ่ง meet KPI) โดยที่บั๊กเหล่านั้นลูกค้าแทบจะไม่มีโอกาสได้จริงๆบน production เลย เรียกว่าเป็นการใช้ risk management analysis approach มาใช้ในการทำเทสมากขึ้น ส่วนในมุมของ Dev การ implement เร็วก็จะไม่ใช่ goal อีกต่อไป goal จะกลายเป็น implement ยังไงให้ขื้น production ให้เร็ว ที่สุดซึ่งก็คือ implement ให้มี Quality และ implement ให้ test ง่าย โดยถ้า implement เสร็จแล้วก็จะมาช่วย QA develop tool สำหรับการทำเทสหรือแม้แต่มาช่วย implement automation test หรือ execute test ในบางครั้ง พูดง่ายๆ role ของ QA คือ Quality Owner ซึ่งจะเป็นคนกำหนด best practice ในแง่ของ Quality ของทีม เป็นคน define strategy ของการ test ในขณะที่คน implement Quality นั้นคือสมาชิกทั้งทีม (Dev/QA) การ implement quality ตัวอย่างคือการเขียนโค้ดให้มี quality, implement automation test, execute test, etc นอกจากนี้ QA สามารถทำงานแบบเป็น Risk Analysis & Communicator ได้มากขึ้นด้วยครับ อย่างเช่นถ้า requirement คือ A, B, C แล้วถึงวัน release date เรายังมีบั๊กของ function B ที่ยังแก้ไม่หมด แทนที่ QA จะบอกแต่เพียงว่า Quality ยังไม่ผ่านห้าม deploy เพียงอย่างเดียว เราลองเพิ่ม risk analysis เข้าไปอีกหน่อยเช่น bug ตัวนี้เป็นปัญหาเกี่ยวกับ currency conversion ซึ่งทำให้คำนวณราคาผิดไป 0.01 USD ต่อ booking (บริษัทได้เงินน้อยกว่าที่ควรจะได้) คิดเป็นความเสียหายแบบแย่สุดประมาณ 50,000 บาทต่อวัน ทีนี้ Product team (Dev/QA/PM/etc) จะได้มาคิดร่วมกันได้ว่า ถ้า product version นี้ (A + B + C) มี potential ที่จะทำกำไรมากขึ้น 2,000,000 บาทต่อวัน เราอาจจะตัดสินใจ release product ไปก่อนแล้ว patch fix ตามหลังไปก็ได้ เนื่องจากบั๊กตัวนี้ไม่ได้ทำลายความน่าเชื่อถือของบริษัท (ราคาถูกลง ลูกค้าชอบ) upside gain potential คือ ได้กำไรมากขึ้น 1,950,000 บาทต่อวัน หรืออีกกรณีนึงคือ มีเวลาน้อย ยังเทสได้ไม่หมด แต่เราบอกได้ว่าด้วยเวลาที่มี เราเทส cover 100% ของฟังก์ชั่นหลักที่ลูกค้า 90% ใช้ผ่านหมดแล้ว แต่ยังเหลือฟังก์ชั่นที่ไม่ค่อยมีคนใช้อีก 10% ความเสี่ยงคืออะไร ฟังก์ชั่นอะไรอาจจะใช้ไม่ได้บ้างและความเสียหายที่อาจเกิดขึ้นแบบแย่ที่สุดคืออะไร ทีนี้มาเทียบความเสี่ยงของผลเสียที่อาจเกิดขึ้นกับ upside gain จากการ release product นั้น แล้วค่อยตัดสินใจร่วมกันว่า release หรือเทสให้หมดก่อน อะไรแบบนี้ครับ รวมๆไม่อยากให้ say no อย่างเดียว อยากให้มอง business goal กับ upside gain แล้ว trade-off กับ risk ของ Quality มากขึ้นครับ เราจะเป็น QA ที่เข้าใจและช่วย drive business ไปข้างหน้าได้มากขึ้นครับ (ลด conflict และเป็นที่รักของประชาชนด้วย)

นอกจากนี้อย่าลืมว่าถึงแม้ว่า development team จะ implement และ test เสร็จเร็ว อย่าลืมว่านี่ก็ยังไม่ได้ benefit กับ production หรือ business นะครับ ต้องคิดไปถึงการ packaging หรือ deployment ด้วยว่าทำยังไงถึงจะให้ทีม deployment หรือ infrastructure deploy ได้ง่ายและเร็วโดยเกิดปัญหาน้อยที่สุด เป็นไปได้มั๊ยที่จะเตรียม automate deployment ให้เค้าใช้อะไรแบบนี้ สุดท้าย อย่าลืม monitor ผลลัพธ์บน production ด้วยว่า new features หรือ changes ที่เกิดขึ้น deliver business value ได้ตรงตาม KPI ที่ตั้งไว้รึเปล่าหรือมีบั๊กที่ก่อให้เกิดความเสียหายยังไง ต้อง roll back มั๊ยหรือปล่อยไว้ได้เพราะมี upside gain มากกว่า

ทั้งนี้ทั้งนั้นสิ่งเหล่านี้จะเกิดขึ้นได้ ต้องฝึกคิดเสมอว่าเราคือ one team เรามีจุดมุ่งหมายเดียวกันคือ deliver business value (ไม่ใช่ implementationให้เสร็จเร็วๆ ไม่ใช่ test ให้เจอบั๊กเยอะๆ) จากประสบการณ์ที่ทำมา ไม่ง่ายครับ ไม่ง่ายจริงๆ แต่ทำได้แน่นอนครับ แล้วพอทำได้แล้ว โลกเปลี่ยนและ productivity ของทีมเปลี่ยนไปแบบมหาศาลครับ รวมถึง attitude ที่คนในทีมมีให้กันก็เปลี่ยนไปแบบหน้ามือหลังมือ จากที่เคยแง่งใส่กัน ทะเลาะกัน ทำงานแบบโยนบอลให้กัน (อ่ะ ของชั้นเสร็จแล้ว ชั้นโยนให้แกไปทำต่อ โยนกันไปโยนกันมา) ตอนนี้ทุกคนมีเป้าหมายเดียวกันครับ

Technique สำคัญที่ต้องใช้ตลอดสำหรับตัวเองและเวลา Coach คนอื่น สำหรับคนที่อยากจะ drive mindset อันนี้ให้องกรค์ของตัวเองคือ ถามคำถามนี้กับตัวเอง และคนอื่นเสมอว่า “What is business value that you delivered by this?” อย่างเช่นเวลา Dev บอกว่าทำเสร็จแล้วตอนนี้รอเทสอยู่ที่ QA ก็ถามคำถามนี้ครับ เค้าจะได้เริ่มคิดว่าเออ เราทำแค่นี้ก็ยังไม่มีประโยชน์กับ business นะ ต้องไปช่วยกันคิดว่าทำยังไงถึงจะเทสได้เสร็จเร็ว ต้องเข้าไปช่วย implement อะไรเพิ่มให้เทสง่ายมั๊ย

อีกคำถามนึงที่ใช้บ่อยสำหรับตัวเองและเอาไว้ถามเพื่อ coach คนอื่นคือ What would you do if this is your company? อย่างเช่นเวลา QA บอกว่ายังมีบั๊ก 1 2 3 4 อยู่จะให้เอาขึ้นเหรอ ตัดสินใจมาแล้วกัน ชั้นบอกแล้วนะว่ามันยังมีบั๊กอยู่ บลาๆๆ ถามคำถามนี้ไปครับ ให้เค้าฝึกคิดในมุมใหญ่กว่า role ที่ตัวเองทำอยู่ ให้ฝึกคิดว่า trade-off ของแต่ละปัญหาและทางแก้คืออะไร คุ้มมั๊ยอะไรแบบนี้

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