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

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

อะไรคือทักษะที่แยกคนทั่วไปกับคนมีประสบการณ์

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

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

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

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

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

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

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

เขาทำหน้าที่กรอง

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

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

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

อะไรแค่เสียงดังในตอนนั้น

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

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

หรือตอนมีลูกค้าโทรมา

หรือแผนกอื่นโทรมาเร่งอะไรบางอย่าง

ตอนนั้นผม panic ง่ายมาก

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

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

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

อาจเพราะตอนนั้นยังเด็ก

ยังไม่มีประสบการณ์

ยังแยกไม่ค่อยออกว่าอะไรคือปัญหาจริง และอะไรคือความกลัวที่เกิดขึ้นในใจเราเอง

หัวหน้าคนนั้นสอนผมเรื่องหนึ่ง

เวลามี feedback เข้ามา ไม่ว่าจะจากลูกค้า PM PO หรือใครก็ตาม

หน้าที่ของเราไม่ใช่รีบ react ทันที

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

คิดก่อนว่า impact แค่ไหน

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

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

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

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

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

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

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

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

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

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

เราควรแก้

แต่ควรแก้ด้วยสติ

ดูว่าเกิดจากอะไร

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

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

ไม่ใช่เห็นอะไรพังนิดหนึ่ง แล้วทิ้งทุกอย่างที่สำคัญกว่า เพื่อวิ่งไปดับไฟทันที

บางครั้งไฟที่เราเห็น อาจไม่ได้ใหญ่เท่าความตกใจของเรา

งาน engineer ไม่ใช่แค่เขียน code

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

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

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

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

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

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

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

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

impact จริงแค่ไหน

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

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

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

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

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

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

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

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

ทุกอย่างมี cost

ทุกอย่างใช้เวลา

ทุกอย่างกิน focus

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

มีสติก่อน react

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

เขายังเจอ bug

ยังเจอ production พัง

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

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

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

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

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

กระทบใคร

ด่วนจริงไหม

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

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

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

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

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

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

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

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

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

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

สำหรับผม นี่อาจเป็นหนึ่งในทักษะที่แยก junior กับคนที่เริ่มมีประสบการณ์

ไม่ใช่รู้ทุกอย่าง

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