ก่อนแก้ ต้องเห็นให้ชัด

ช่วงหลังผมกลับมาคิดเรื่องหนึ่ง

อะไรคือทักษะที่แยกคนที่เพิ่งเริ่มทำงาน กับคนที่ผ่านงานมาพอสมควร

อะไรทำให้ junior dev ค่อยๆ โตขึ้นเป็น senior หรือ team lead ได้

ตอนแรกผมคิดว่าอาจเป็นเรื่องความรู้

เขียน code ได้เร็วขึ้น

รู้ framework เยอะขึ้น

แก้ bug ได้เก่งขึ้น

แต่พอทำงานนานขึ้น ผมเริ่มรู้สึกว่า มีอีกทักษะหนึ่งที่สำคัญมาก

คือการไม่ถูกสิ่งตรงหน้าลากไปทันที

โต๊ะของหัวหน้าทีม

ตอนผมเพิ่งเริ่มทำงานใหม่ๆ ผมเคยคุยกับหัวหน้าทีมคนหนึ่ง

วันหนึ่งเขาเล่าให้ฟังว่า รู้ไหม ทำไมทีมเราถึงจัดห้องแบบนี้

ห้องนั้นจัดให้ทุกคนที่เดินเข้ามาหา dev ในทีม ต้องผ่านโต๊ะหัวหน้าก่อน

ตอนนั้นผมไม่ได้คิดอะไรมาก

แต่เขาบอกว่า หน้าที่หนึ่งของหัวหน้าทีม คือป้องกันไม่ให้เสียงจากข้างนอกเดินเข้าไปกินเวลาของคนที่กำลัง focus อยู่

เขาไม่ได้แค่นั่งบริหารงาน

เขาทำหน้าที่เป็นตัวกรอง

อะไรควรถูกส่งเข้าไปในทีม

อะไรยังไม่ควร

อะไรสำคัญจริง

อะไรแค่เสียงดังในช่วงเวลานั้น

ตอนนั้นผมยังไม่เข้าใจลึกมาก

แต่พอโตขึ้น ผมเริ่มเห็นว่า การกรองแบบนี้ไม่ใช่แค่หน้าที่ของหัวหน้า

มันเป็นทักษะที่ engineer ทุกคนต้องค่อยๆ มีในตัวเอง

ตอนที่ทุกอย่างดูด่วนไปหมด

ผมยังจำบรรยากาศตอน deploy แล้วพังได้

หรือเวลาลูกค้าโทรมา

หรือมีแผนกอื่นทักมาว่ามีปัญหา

ตอนเป็น junior ผม panic ง่ายมาก

พอมีคนบอกว่ามีปัญหา ใจก็รีบวิ่งไปตรงนั้นทันที

เหมือนทุกอย่างกลายเป็นเรื่องด่วน

เหมือนทุกอย่างต้องแก้เดี๋ยวนั้น

บางทีผมลืมด้วยซ้ำว่าก่อนหน้านี้กำลังทำอะไรอยู่

ตอนนั้นผมยังแยกไม่ค่อยออกว่า อะไรคือปัญหาจริง และอะไรคือความกลัวในใจผมเอง

กลัวคนอื่นว่า

กลัวดูไม่เก่ง

กลัวทำให้ทีมเสียหาย

ความกลัวพวกนี้ทำให้เรื่องตรงหน้าดูใหญ่กว่าที่เป็นจริง

หัวหน้าคนนั้นสอนผมว่า เวลามี feedback เข้ามา ไม่ว่าจะจากลูกค้า PM PO หรือใครก็ตาม หน้าที่ของเราไม่ใช่รีบ react ทันที

หน้าที่ของเราคือหยุดคิดก่อน

ก่อนแก้ ต้องเห็นก่อน

สมมุติเรา commit อะไรบางอย่างแล้วพัง

คำถามแรกไม่ควรเป็น

แย่แล้ว ใครจะว่าเราไหม

แต่ควรถามว่า

สิ่งนี้กระทบใครแล้วบ้าง

ขึ้น production แล้วหรือยัง

ลูกค้าเห็นแล้วหรือยัง

กระทบลูกค้าทุกคน หรือแค่บางคน

ระบบหยุดทั้งระบบ หรือเป็น bug เล็กๆ ที่ยังรอได้

ถ้ามันยังอยู่แค่ internal เราอาจไม่ต้อง panic ขนาดนั้น

มันยังต้องแก้

แต่เราไม่จำเป็นต้องแก้จากความตื่นตกใจ

เราควรดูให้ชัดว่าเกิดจากอะไร

ทำไมถึงหลุดมาได้

จะป้องกันไม่ให้เกิดซ้ำได้ยังไง

และตอนนี้มีอะไรที่สำคัญกว่าหรือเปล่า

หลายครั้งปัญหาไม่ได้ใหญ่เท่าความตกใจของเรา

ไฟตรงหน้าอาจเป็นไฟเล็ก

แต่ใจที่ตกใจ ทำให้มันดูเหมือนไฟทั้งบ้าน

เสียงดัง ไม่ได้แปลว่าสำคัญ

หลังๆ พอกลับมาไทย และได้ทำงานกับน้องๆ มากขึ้น ผมเห็นเรื่องนี้ชัดขึ้น

หลายครั้งเราไหลไปตามสิ่งที่เพิ่งเห็น

เห็นคนหนึ่งทำอะไรมา ก็อยากเปลี่ยนตาม

เห็น tool ใหม่ ก็อยากใช้

ลูกค้าทักมาหนึ่งคนว่าอยากได้ feature นี้ เราก็อยากทำ

พรุ่งนี้มีอีกคนทักมาอีกอย่าง เราก็อยากทำอีก

แต่เรายังไม่ได้หยุดถามเลยว่า

เรื่องนี้สำคัญจริงไหม

impact จริงแค่ไหน

มีคนต้องการกี่คน

เป็นลูกค้า 80% หรือ 1%

ทำแล้วได้อะไรกลับมา

เวลาที่ต้องใช้คุ้มไหม

ถ้าทำสิ่งนี้ เราต้องไม่ทำอะไรแทน

คำถามพวกนี้ดูช้า

แต่จริงๆ มันช่วยให้เราไม่เสียเวลาชีวิตไปกับสิ่งที่แค่ผ่านเข้ามาเสียงดัง

สำหรับผม นี่คือทักษะของ engineer

ไม่ใช่แค่เขียน code ให้ได้

แต่คือการเห็น trade-off

ทุกอย่างมีราคา

บางอย่างจ่ายด้วยเวลา

บางอย่างจ่ายด้วย focus

บางอย่างจ่ายด้วยความสงบของทีม

และหลายครั้ง ปัญหาของทีมไม่ได้มาจากการทำช้าอย่างเดียว

แต่มาจากการรีบทำสิ่งที่ยังไม่ควรทำ

ช่องว่างก่อนตอบสนอง

คนมีประสบการณ์ไม่ได้แปลว่าไม่เจอปัญหา

เขายังเจอ bug

ยังเจอ production พัง

ยังเจอลูกค้า complain

ยังเจอ feedback ที่เข้ามาเร็วและแรงเหมือนเดิม

แต่สิ่งที่ต่างออกไปคือ เขามีช่องว่างเล็กๆ ก่อนตอบสนอง

ช่องว่างที่พอจะถามว่า

เรื่องนี้จริงๆ คืออะไร

กระทบใคร

ด่วนจริงไหม

สำคัญจริงไหม

ถ้าไม่ทำตอนนี้ จะเกิดอะไรขึ้น

ถ้าทำตอนนี้ ต้องแลกกับอะไร

ผมคิดว่าการโตขึ้นของ engineer ส่วนหนึ่งคือการมีช่องว่างตรงนี้มากขึ้น

ไม่ panic ง่ายเหมือนเดิม

ไม่ไหลตามเสียงที่ดังที่สุด

ไม่รีบแก้ทุกอย่างเพราะกลัวคนอื่นต่อว่า

แต่ค่อยๆ เห็นภาพรวมมากขึ้น

เห็น impact มากขึ้น

และเลือกทำสิ่งที่ควรทำจริงๆ มากขึ้น

สำหรับผม คนที่มีประสบการณ์อาจไม่ใช่คนที่รู้ทุกอย่าง

แต่เป็นคนที่ไม่ถูกทุกอย่างลากไปง่ายๆ เหมือนเดิม