Dashboard ที่ทำไว้เพราะคิดว่าจะช่วยทีมได้มากที่สุด
กลับทำให้ทีมรู้สึกโดนจับผิดมากที่สุด
.
มีครั้งนึงพี่กิ่งรู้สึกว่าอยากให้ทีมเขียน unit test มากขึ้น
(unit test คือ test ส่วนย่อยๆ ที่เอาไว้เช็คจุดเล็กๆ แค่จุดเดียวว่ายังทำงานถูกอยู่)
เพราะตอนนั้นยังขาดไปเยอะมาก หลายๆ ส่วนก็ยังไม่มีเลย
และการมี unit test จะช่วยให้เราจับบั๊กในชั้นแรกได้ดีขึ้น
ทีมจะได้มั่นใจกับ quality ของ product มากขึ้น
.
พอคิดได้แบบนั้นก็ลุยเข้าไปเลยค่ะ
เซ็ต process ขึ้นมา ว่า Dev และ QA ต้องทำอะไรบ้าง
สร้าง dashboard มาหนึ่งตัว เพื่อเช็คว่า requirement ไหนยังขาด unit test
ตอนนั้นคิดแค่ว่า จะได้เห็นว่าขาดตรงไหน แล้วมาคุยกันว่าเกิดอะไรขึ้น
ไม่ได้คิดจะว่าใครเลย
.
แต่พอเริ่มใช้ คือพังหมดค่ะ
กลายเป็นว่าไปทำให้ Dev ตั้งการ์ดขึ้นมาทันที
แล้วทีม Dev กับ QA ก็เริ่มมีปัญหากัน
.
พอตอนหลังถึงมาเข้าใจค่ะ
วันนั้นพี่กิ่งคิดว่า dashboard ก็แค่บอกเรื่องงาน ไม่ได้ไปตำหนิใคร
แต่พอเราไม่ได้ทำให้ทีมเชื่อในสิ่งที่กำลังทำก่อน
ตัวเลขบนนั้นมันก็เหมือนเป็นคำตัดสินอยู่ดี
.
แล้วสิ่งที่ dashboard มันบอกไม่ได้เลยคือ “ทำไม” ยังไม่มี
มี dev เคยพูดมาว่า unit test มันเทส business logic ไม่ได้
พี่กิ่งก็คิดแค่ว่า ทำไมมันจะไม่ได้ มันต้องได้สิ
แล้วก็ไม่ได้เข้าไปดูว่ามันติดตรงไหน
.
ในงานด้าน Quality มันจะมีสิ่งนึงที่เรียกว่า Quality Gate
คือด่านตรวจที่คอยเช็คว่างานผ่านก่อน ถึงจะไปต่อได้
ด่านตรวจอันนี้จะเก่งมากเรื่องบอกว่าอะไรขาด
แต่มันไม่เคยบอกว่า ทำไมถึงยังไม่ทำ และ อะไรที่จะทำให้ทีมอยากทำ
.
ตอนหลังพี่กิ่งก็เลยลองเปลี่ยนวิธีค่ะ
เลิกทำแค่ชี้ว่าใครขาดอะไร แล้วลงไปลุยเองเลย!
👉 เข้าไปดูโค้ดว่ามี unit test ตรงไหนบ้าง รันได้มั้ย
👉 ดูว่าจะเพิ่ม unit test ตรงไหนได้บ้าง
👉 ทำยังไงให้ unit test สามารถเทส business logic ได้จริง
แล้วก็ทยอยแชร์ให้หัวหน้าดูบ้าง แชร์ให้ dev คนที่ดูจะสนใจเรื่องนี้บ้าง
แต่ยังไม่ได้บังคับให้เค้าทำอะไรนะคะ dashboard ก็เอาส่วนนั้นออกไปแล้ว
เหลือไว้แค่ส่วนที่ฝั่ง QA ต้องเป็นคนเช็คเอง
.
จนวันนึงมีบั๊กหลุดไปถึงผู้ใช้งานจริงตัวนึงค่ะ
ก็เลยลองเข้าไปดูว่าเราจะเพิ่ม unit test เพื่อดักบั๊กตัวนี้ตั้งแต่ต้นได้ยังไงบ้าง
แล้วมันก็ทำได้จริง!
พี่กิ่งเลยเอาไปแชร์ให้ทีม dev ดูว่าจะเพิ่มเทสเข้าไปตรงไหนได้บ้าง
และที่สำคัญคือ มันจะช่วยจับบั๊กตัวนี้ได้ยังไง
ไม่ได้ว่าอะไรใคร ไม่ได้เถียงว่าทำได้หรือไม่ได้
เพราะเคยพูดไปแล้ว คนอื่นอาจจะยังไม่เห็นภาพ
แต่แค่ทำให้ดูว่า ถ้ารันเทสนี้กับโค้ดเวอร์ชันที่มีบั๊ก มันเฟลนะ
แต่พอรันกับตัวที่แก้บั๊กแล้ว มันผ่าน
.
แล้วหลังจากนั้น dev บางคนก็เริ่มเอาโค้ดมาถามค่ะ ว่าแบบนี้โอเคมั้ย ควรเทสยังไง
บางทีก็แชร์จอ ไล่ดูโค้ด ไล่หาปัญหาไปด้วยกัน
ส่วน dashboard ก็ช่างมันก่อน สุดท้ายก็ไม่ได้เอามันกลับมาค่ะ
แต่สิ่งที่ได้มาคือ ตอนนี้เค้า trust เราแล้ว
และเค้าเห็นแล้วว่า สิ่งที่เคยบอกว่าทำไม่ได้ มันหน้าตาเป็นแบบไหน
.
ไม่ว่าจะทางไหน จะทำ dashboard หรือจะลงไปลุยเอง
ทั้งสองทางมีเป้าหมายเดียวกัน แต่ต่างกันที่วิธีเข้าหาปัญหา
ครั้งแรก เราเดินดุ่มๆ เข้าไป โดยที่ไม่ทันได้ทำความเข้าใจอีกฝั่งให้ดีพอ
เลยกลายเป็นโดนตั้งการ์ดใส่ตั้งแต่แรก
แต่ครั้งที่สอง เราเข้าไปเป็นทีมเดียวกับเค้า แล้วก็ช่วยกันแก้ปัญหาเดียวกัน
.
คนเราไม่ได้ตั้งการ์ดขึ้นมาเพราะโดนคำพูดแรงๆ อย่างเดียว
แต่บางทีมันก็เกิดจากความรู้สึกว่าเรากำลังโดนตัดสิน
จากคนที่ไม่ได้เข้าใจปัญหาของเค้าดีพอ
แล้วเรื่องนี้มันก็ไม่ได้ใช้ได้แค่กับเรื่องระหว่างทีมอย่างเดียว
แต่เรื่องอื่นๆ ในชีวิตของเราก็ด้วย
หัวหน้าที่กำลังอยากให้คนในทีมเปลี่ยน
พ่อแม่ที่อยากให้ลูกตั้งใจทำการบ้าน
หรือคนที่อยากให้แฟนช่วยงานบ้านให้มากขึ้นอีกหน่อย
หลายครั้งเราไปเริ่มจากการตั้งกฎ ตั้งตารางเช็คว่าใครทำ ใครไม่ทำ
แล้วก็มานั่งหงุดหงิดว่าทำไมไม่มีใครร่วมมือเลย
.
📌 ครั้งหน้าลองแบบนี้ดูค่ะ
👉 ลองเช็คดูว่าเรารู้มั้ยว่าทำไมเค้ายังไม่ทำ
ถ้ายังไม่รู้ ให้ลองหาสาเหตุดูก่อน จะถามก่อนก็ได้ หรือลองเข้าไปทำเองก็ได้
👉 ลองดูว่าสิ่งที่เค้ายังไม่ทำ มันทำให้เกิดปัญหาหรือ pain point ตรงไหนมั้ย
แล้วเราค่อยเริ่มจากตรงนั้น ว่าจะช่วยกันแก้ปัญหานี้ได้ยังไง
ไม่ใช่ไปเริ่มจากการตั้งกฎ ว่าต้องทำแบบนี้ 1 2 3 4
.
บางเรื่อง เราแค่บอกก็พอค่ะ
แต่บางเรื่อง เราต้องเข้าไปนั่งข้างเค้าก่อน
เพื่อให้เห็นว่าเค้าติดอะไรอยู่
ก่อนที่จะเริ่มแก้ปัญหาไปด้วยกัน