จะทำยังไง เมื่อสกิลที่แตกต่างของเรา กลายเป็นภาระของเราแทนที่จะเป็นประโยชน์

ระยะหลังมานี้ มีน้องที่รู้จักกันมาปรึกษาครับ ประมาณว่าตัวเองเป็นหนึ่งในคนที่มีสกิลพิเศษในทีม ซึ่งก็มีกันอยู่สองสามคน แต่ต้องมาคอยซัพพอ์ตคนอื่น ๆ ที่เป็นโปรแกรมเมอร์เหมือนกันแต่ดันไม่มีสกิลที่ว่านี่ไม่ได้อีกเป็นสิบ เท่าที่ฟังก็เหมือนกับถูกเอาเปรียบอยู่ประมาณนึง เพราะว่าคนที่มาขอให้ซัพพอร์ตก็ทำเหมือนกับว่ามันเป็นหน้าที่ของคนที่ทำได้ว่าจะต้องช่วยเหลือเขาได้ในทันที เป็น Obligation ของพวกเทพที่จะต้องช่วยเหลือเขาโดยไม่มีข้อแม้

เหมือนขอหวยยังไงชอบกล ว่ามั้ยครับ?

เมื่อไม่นานมานี้ผมเพิ่งอ่านหนังสือชื่อ The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win จบไป (ก็เกือบจบครับ เหลือแต่ส่วน DevOps Handbook ข้างหลัง เพราะว่าซื้อเล่มเต็มมาแล้ว) ในเรื่องพระเอกที่ชื่อ Bill ขึ้นไปรับหน้าที่เป็น VP ที่ดูแลด้าน IT ซึ่งหลัก ๆ ก็จะดูตั้งแต่เรื่อง Infrastructure ยาวไปถึงพวก Facility ด้านไอทีของพนักงาน คือสูงกว่านี้ก็เป็น CIO แล้ว (ได้เป็นมั้ยไม่เล่านะครับ)

ในเรื่องจะพูดถึงโปรเจค Phoenix และความล่าช้าของมัน (ไม่ใช่อันที่อยู่ใน Kickstarter นะครับ อันนั้นล่มไปนานแล้ว) แล้วเรื่องนึงที่พบคือ มันมีคอขวดที่ชื่อว่า Brent อยู่ ซึ่งงานด้านไอทีที่สำคัญ ๆ เนี่ย ตา Brent มักจะมีส่วนร่วมด้วยเสมอ และทุกครั้งที่มีปัญหา ทุกคนจะวิ่งหาหมอนี่ตลอด Brent เป็นคนที่สำคัญมากขนาดที่ว่า ถึงแผนกไอทีจะปิดไปทั้งหมด แต่ตา Brent ยังต้องอยู่ที่บริษัทนี้ เพราะว่ารู้ทุกความเป็นไปของไอที

ความหมายอีกด้านของ Brent คือ ทุกอย่างจะต้องวิ่งผ่าน Brent ไม่ว่าจะเป็นปัญหายิบย่อยแค่ไหน ดังนั้นให้ลองคิดเล่น ๆ ดูว่า หมอนี่จะงานยุ่งระดับไหน แล้วงานที่เขาทำได้จะเป็นแบบไหนนะครับ

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

เมื่อเก่งเกินไป มีสกิลที่คนอื่นไม่มี กลับกลายเป็นปัญหาซะเอง

key takeaway อย่างแรกที่ผมอยากบอกคือ การที่เรามีคนที่มีสกิลเฉพาะทางที่คนอื่นไม่มีนั้น ในแง่มุมหนึ่งก็เป็นปัญหาขององค์กร โดยเฉพาะถ้าเป็นสกิลที่สำคัญและมีคนต้องพึ่งพามันเป็นจำนวนมาก เพราะมันกลายเป็นคอขวดที่ทุกคนต้องวิ่งมาหา ปริมาณงานโดยรวมที่ปิดได้จะกลายเป็นลดลงเพราะต้องวิ่งผ่านคนกลุ่มนี้แหละ

หลาย ๆ คนใช้ประโยชน์จากตรงนี้ในการใช้เป็นตัวประกันว่า ถ้าเกิดว่าไล่เราออกไปล่ะก็ งานคุณจะมีปัญหานะ ตรงนี้เป็นความเชื่อที่ผิด ถึงแม้จะเคยมีบริษัทที่เจ๊งเพราะเหตุการณ์ลักษณะนี้มาก่อนแล้วก็ตาม แต่อันนั้นมักจะเกิดจากการที่บริษัทมีสายป่านยาวไม่พอร่วมด้วยครับ ถ้าเกิดว่ามีเงินหมุนเวียนดีพอล่ะก็ปัญหาอะไรก็แก้ได้ทั้งนั้นแหละ

นี่ยังไม่นับว่า บางครั้งแค่ในช่วงเวลาสั้น ๆ สกิลที่คุณเคยใช้เป็นตัวประกันกลายเป็น obsolete ไป คราวนี้คุณเลยโดนเมินเรียบร้อย โดนจับย้ายไปแผนกอะไรก็ไม่รู้ที่ไม่ได้ใช้สกิลอะไรที่คุณมี กลายเป็นถูกบีบให้ออกไปซะงั้น

เชื่อผมเถอะ มันเคยเกิดมาแล้ว

แก้ปัญหาระยะสั้น

Bill Palmer ผู้ซึ่งมีทั้งชื่อและนามสกุลของผู้ก่อตั้ง Microsoft (ไม่น่าจะบังเอิญนะ) มาพบปัญหานี้เพราะดันเกิด Severity 1 ตั้งแต่วันแรกที่รับตำแหน่ง เขาตัดสินใจที่จะสั่งปิดการเข้าถึงตัว Brent โดยตรงจากทุกทาง ไม่ว่าใครก็ตามที่จะมาขอให้ Brent ช่วย จะต้องวิ่งไปหาเมเนเจอร์ที่อยู่ใต้เขาคนใดคนหนึ่งก่อน ตรงนี้เป็นการคัดกรองปัญหา เพื่อหาว่าจำเป็นจะต้องใช้สกิลลับเฉพาะของ Brent หรือไม่

ถ้าเกิดว่าเป็นปัญหาที่ต้องอาศัย Brent มาช่วยเหลือ เขาจะจัดให้คนที่อยู่ระดับเดียวกับ Brent หรือต่ำกว่าเข้ามาร่วมศึกษาปัญหานี้ และเขาจะไม่ให้ Brent ลงมาแก้ไขปัญหาลักษณะเดียวกันซ้ำกันสองครั้ง ถ้า Brent แก้ในครั้งแรกได้แล้ว ครั้งต่อ ๆ ไปคนอื่นจะต้องลงมาเป็นคนดูแล

ที่สำคัญคือ Brent จะต้องลงบันทึกว่าว่าช่วยเหลืออะไรใคร ใช้เวลาเท่าไหร่ในเรื่องไหน เพื่อที่จะหาว่าใช้เวลาไปกับงานของคนอื่น ไปมากน้อยแค่ไหน

การที่ request ต้องวิ่งผ่าน manager นั้นทำให้ manager รู้ว่า มี request เข้ามามากน้อยแค่ไหน มีงานไหนที่จำเป็นจริง ๆ บ้าง และมีงานไหนที่ปล่อยให้คนอื่นดูได้บ้าง ไม่ใช่ว่า Brent จะต้องแบกไปทุกอย่าง กลายเป็นเดอะแบกของบริษัท

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

ส่วนตัวผมเคยอยู่ในสภาวะที่ถูกสั่งให้ลงเวลาเฉพาะงานตัวเองเท่านั้น งานของคนอื่นเราลงไม่ได้ (ด้วยสภาพการบริหารโปรเจคของบริษัท ทำให้เราไม่สามารถลงเวลาในโปรเจคของคนอื่นได้) ตรงนี้ทำให้เมเนเจอร์มองไม่ออกว่าเราทำงานให้คนอื่นไปมากน้อยแค่ไหน และถึงจุดไหนที่เขาควรลงมาเบรค (ไม่งั้นงานเราก็ไม่เดิน) แล้วพอถึงเวลาประเมินเขาก็จะบอกว่าทำไมเราใช้เวลากับงานตัวเองเยอะมาก ก็กลายเป็นว่าเราโดนประเมินต่ำกว่าความเป็นจริงไปเสียอีก

ตรงนี้… ผมคิดว่าเราก็ต้องปกป้องตัวเองโดยการบันทึกเวลาแยกกับบันทึกเวลาของบริษัท เพราะเราไม่สามารถลงตามความเป็นจริงได้ (เนื่องจากระบบ) แต่ก็ต้องยกเรื่องขึ้นไปด้วยว่าเราไม่สามารถลงตามความจริงได้นะด้วยเหตุผลดังนี้ อะไรแบบนี้ ที่จริงเราควรจะบันทึกตั้งแต่ว่า มีคนมาขอความช่วยเหลือทั้งหมดกี่ครั้งในเรื่องอะไรบ้าง

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

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

แก้ปัญหาในระยะยาว

Bill Palmer และทีมของเขาแก้ปัญหาในระยะยาวโดยการทำให้ทุกอย่างมีระบบ มีโครงสร้าง และสร้างระบบอัตโนมัติเข้ามาแทนคนในกรณีที่ทำได้ครับ และพยายามผันตัวคนทำงานจากคนที่ทำงานจริง ๆ มาเป็นคนที่ช่วยเหลือ ก็คือผมมองว่าเป็นการสนับสนุนให้คนทำงานสามารถทำงานของตัวเองได้โดยพึ่งพาคนอื่นให้น้อยลง หลังจากนั้นก็เปิดประเด็นด้าน DevOps ขึ้นมา

อย่างสมมติถ้า developer ต้องการจะเพิ่ม column ใหม่ใน database ก็สามารถสร้าง request ในระบบอัตโนมัติ ตัวระบบจะทดสอบว่าสร้างแล้วมีปัญหาหรือไม่ แล้วก็ไปสร้างใน production จริง ๆ ให้โดยที่ทีม IT ไม่ต้องลงไปทำเอง คือทีม IT จะเปลี่ยนจากคนที่ทำงานตามใบสั่ง มาเป็นคนที่ออกแบบระบบใบสั่งงาน และแก้ปัญหาเวลาที่ระบบใบสั่งมีปัญหาเท่านั้น ส่วน dev เองก็ต้องรู้วิธีสร้าง request และข้อมูลที่เกี่ยวข้อง จะเดินไปบอก OPS ว่า สร้าง column ชื่อนั้นชื่อนี้ให้หน่อย แบบนี้ไม่ได้

ซึ่งก็ไปเหมือนกับตอนที่ Brent สามารถทำงานเดียวกันได้แค่ครั้งเดียว ครั้งต่อไปต้องให้คนอื่นทำ Brent แนะนำได้เท่านั้น ว่าไหมครับ

ตรงจุดนี้ ผมว่า สิ่งที่สำคัญคือการลดการพึ่งพา (dependency) ระหว่างกันลง แล้วไปเพิ่มการทำงานร่วมกัน (collaboration) ให้มากขึ้น กล่าวคือคนที่ทำงาน เมื่อติดปัญหาก็ควรจะมีทักษะเฉพาะนี่ระดับนึง ควรจะแก้ไขปัญหาเองได้บ้าง และเมื่อแก้ไม่ได้จริง ๆ ก็สามารถมาขอคำปรึกษาจากคนที่เป็นผู้เชี่ยวชาญได้ และเมื่อเคยมาปรึกษาแล้วก็ไม่ควรมาขอปรึกษาปัญหาเดิมอีก

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

สำหรับวิธี ก็ต้องทำตั้งแต่ทำให้งานมันง่ายลง เช่นการสร้างระบบอัตโนมัติให้ใช้ แล้วก็การให้ความรู้กับคนที่มาขอคำปรึกษา ดังนั้นทักษะด้านการแบ่งปันความรู้นั้นจึงสำคัญมาก ๆ สำหรับคนทำงานครับ

ซึ่งปัญหาต่อไปที่จะไปเจอแทนคือ คนทำงานแต่ละคนจะต้องมีความรู้ในวงที่กว้างมาก และลึกมาก ทำให้การปั้นคนาทำงานแต่ละคนก็จะกลายเป็นเรื่องยากไปหน่อย ตรงนี้ผมว่าสิ่งที่ทำได้ก็คือการแบ่งคนในแนวนอน กล่าวคือ ทุกคนจะต้องมีทักษะที่จำเป็นสำหรับงานที่ทำ แต่งานที่ทำควรจะแบ่งสโคปให้เล็กลง ดูและเฉพาะโจทย์ที่ตัวเองสนใจและถูกมอบหมายให้เท่านั้น ตรงนี้ผมจะไม่พูดถึงเพราะว่ามันยากและผมก็ไม่ค่อยรู้เรื่องสักเท่าไหร่ (ฮา)

ใส่ความเห็น

อีเมลของคุณจะไม่แสดงให้คนอื่นเห็น ช่องข้อมูลจำเป็นถูกทำเครื่องหมาย *

This site uses Akismet to reduce spam. Learn how your comment data is processed.