- วิศวกรอาวุโสให้ความสำคัญกับ ‘การลงมือทำที่ได้ผล’ มากกว่าการเป็น ‘ฝ่ายถูก’ และไม่ได้พยายามหยุดทุกโปรเจ็กต์ที่ผิดพลาด
- ‘โปรเจ็กต์แย่’ อาจรวมถึงปัญหาด้านเทคนิค การเมือง หรือ UX และมักเปลี่ยนไปตามดุลยพินิจส่วนบุคคล
- อิทธิพลต้องถูกบริหารเหมือนบัญชีธนาคาร เพราะหากคัดค้านบ่อยเกินไปอาจสูญเสียความน่าเชื่อถือและเข้าสู่ภาวะ ‘ล้มละลายทางการเมือง’
- การตัดสินใจว่าจะเข้าไปแทรกแซงหรือไม่ขึ้นอยู่กับ ความใกล้ตัวของโปรเจ็กต์ ผลกระทบต่อทีม และขนาดความเสียหายต่อทั้งบริษัท
- แทนที่จะพยายามแก้ทุกปัญหา ควร เลือกจังหวะเข้าแทรกแซงอย่างมีกลยุทธ์ และรับมือกับส่วนที่เหลือด้วยการสังเกตและเตรียมพร้อม
ความหมายและตัวอย่างของโปรเจ็กต์แย่
- ‘โปรเจ็กต์แย่’ ปรากฏได้หลายรูปแบบ เช่น การแก้ปัญหาที่ไม่จำเป็น การออกแบบที่ซับซ้อนเกินไป หรือแรงจูงใจทางการเมือง
- ในมุม UX อาจเป็นการแก้ปัญหาที่ไม่มีอยู่จริง หรือทำให้ flow เดิมสะดุด
- ในทางเทคนิค อาจเป็น ความซับซ้อนเกินจำเป็น การเลือกไลบรารีผิด หรือสถาปัตยกรรมที่ไม่มีประสิทธิภาพ
- ในทางการเมือง อาจเป็น โปรเจ็กต์ที่ทำเพื่อการเลื่อนตำแหน่งหรือการตามกระแส
- ความดีหรือความแย่ของโปรเจ็กต์เป็น การตัดสินเชิงอัตวิสัยที่ต้องใช้เวลาให้เห็นผล และในช่วงแรกมักยังไม่ชัดเจน
- มีตัวอย่างจาก Google ที่ ทีมแพลตฟอร์มพยายามส่งต่อ user flow หลักให้ทีมอื่นรับผิดชอบ แต่สุดท้ายล้มเหลวด้วยเหตุผลทางการเมือง
- แม้จะยอดเยี่ยมในเชิงเทคนิค แต่ก็ถูกยกเลิกหลังผ่านไป 2 ปีเพราะ ปัญหาเรื่องอำนาจระหว่างองค์กร
- บทเรียนคือ “การเมืองและความแม่นยำในการนิยามปัญหาสำคัญพอ ๆ กับความสมบูรณ์ทางเทคนิค”
เหตุผลที่ไม่อาจหยุดทุกโปรเจ็กต์แย่ได้
- บริษัทซอฟต์แวร์มักมีอคติไปทาง ‘ลงมือเร็ว’ ทำให้การยกข้อกังวลถูกมองว่าเป็นการถ่วงความเร็ว
- ดังนั้นหากยังไม่ถูกมองว่าเป็นปัญหาใหญ่ ก็มีโอกาสสูงที่จะถูกมองข้าม
- การคัดค้านซ้ำ ๆ อาจทำให้ถูกตีตราเป็น ‘คนมองโลกในแง่ลบ’ ขณะที่ความล้มเหลวที่ป้องกันไว้ล่วงหน้ามักไม่ได้รับการยอมรับ
- การคัดค้านอาจไปกระทบ การเลื่อนตำแหน่งของคนอื่นหรือโปรเจ็กต์ของผู้บริหารระดับสูง จึงมีความเสี่ยงทางการเมือง
- ความใส่ใจที่วิศวกรคนหนึ่งรับมือได้มีจำกัด และหากเข้าไปยุ่งกับทุกปัญหา ก็อาจกลายเป็นคนประชดประชันหรือหมดไฟ
บริหารอิทธิพลเหมือน ‘บัญชีธนาคาร’
- อิทธิพลคือ ทรัพย์สินที่สะสมจากผลงานและการทำงานร่วมกัน และจะถูกถอนออกทุกครั้งที่คัดค้าน
- เช็ค $5: ข้อทักท้วงเล็กน้อยระดับ code review
- เช็ค $500: การโต้แย้งเรื่องการตัดสินใจด้านสถาปัตยกรรมหรือกำหนดการ
- เช็ค $50,000: ความพยายามหยุดโปรเจ็กต์ระดับผู้บริหาร
- หากเข้าแทรกแซงเรื่องเล็กน้อยซ้ำ ๆ ก็จะ ไม่เหลือแรงพอสำหรับเรื่องใหญ่
- เมื่ออิทธิพลหมดลง ก็อาจตกอยู่ในภาวะ ‘ล้มละลายทางการเมือง’ เช่น ไม่ถูกเชิญเข้าประชุมหรือความคิดเห็นถูกเพิกเฉย
เกณฑ์ในการตัดสินว่าจะเข้าแทรกแซงเมื่อไร
- ตรวจสอบความเชี่ยวชาญ: ยืนยันว่าการตัดสินของตนมีหลักฐานรองรับเพียงพอ
- ตระหนักถึงขอบเขตของการแสดงความคิดเห็น: การออกความเห็นไม่ใช่ ‘คำสั่ง’ แต่เป็น ‘การแบ่งปันมุมมอง’
- ปัจจัยตัดสิน 3 ข้อ
- ความใกล้ชิด (Proximity): ยิ่งใกล้กับทีมของตัวเอง ต้นทุนในการเข้าแทรกแซงยิ่งต่ำ
- ผลกระทบต่อทีม (Team Impact): หากความล้มเหลวจะสร้างความเสียหายโดยตรงต่อทีม ก็ยิ่งคุ้มค่าที่จะเข้าแทรกแซง
- ขนาดระดับบริษัท (Company Scale): หากความล้มเหลวส่งผลต่อทั้งองค์กรอย่างมาก ก็ควรเข้าแทรกแซง
วิธีรับมือกับโปรเจ็กต์แย่
- แทรกแซงโดยตรง: เรียกร้องให้หยุดโปรเจ็กต์หรือส่งเอกสารแสดงความกังวลอย่างหนักแน่น
- ต้องอาศัยความมั่นใจและการยอมรับความเสี่ยง
- แทรกแซงบางส่วน: ปรับทิศทางการออกแบบหรือชี้นำไปสู่ทางแก้ที่ดีกว่า
- หากเข้าหาแบบร่วมมือกัน ก็อาจถูกมองว่าเป็น ‘คนที่เข้ามาช่วย’
- ไม่แทรกแซง: เมื่อแรงเฉื่อยทางการเมืองหรือข้อจำกัดด้านอิทธิพลทำให้การเข้าไปยุ่งไม่คุ้มค่า
- หากทีมเกี่ยวข้อง ก็ควร เตรียมแผนรับมือ เช่น ลดการพึ่งพาหรือสร้างทางเลือกสำรอง
- หากไม่เกี่ยวข้อง ก็ เฝ้าดูอย่างเงียบ ๆ และแชร์ความเห็นเฉพาะภายใน
- การดูแลทีม: บอกความจริงกับสมาชิกทีมอย่างตรงไปตรงมา แต่ตัดรายละเอียดทางการเมืองที่ไม่จำเป็นออก
บทสรุป
- หัวใจสำคัญคือการตระหนักว่า “ความถูกต้องกับความมีประสิทธิผลไม่ใช่เรื่องเดียวกัน”
- ในองค์กรขนาดใหญ่ การเมืองและบริบทมักมีบทบาทเหนือเหตุผลล้วน ๆ และไม่สามารถแก้ทุกความผิดพลาดได้
- ต้อง ใช้อิทธิพลและความน่าเชื่อถืออย่างมีกลยุทธ์ เพื่อโฟกัสกับช่วงเวลาที่สามารถสร้างการเปลี่ยนแปลงจริงได้
- ในกรณีอื่น ๆ ให้ แบ่งปันกับเพื่อนร่วมงาน เตรียมพร้อม และเรียนรู้ผ่านการสังเกต
- แม้จะแก้ได้ไม่สมบูรณ์ทั้งหมด แต่ แนวทางนี้คือวิธีที่ยั่งยืนกว่า
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ทำให้นึกถึงผู้จัดการคนหนึ่งที่เคยพูดว่า “บางครั้งก็ต้อง ปล่อยให้คนล้มเหลว”
การคอยประคองบางคนตลอดใช้พลังงานมากเกินไป หวังว่าสักวันพวกเขาจะว่ายน้ำเองได้ แต่บางครั้งความพยายามนั้นก็ควรถูกนำไปใช้ในที่ที่ดีกว่า
เคยมีโปรเจ็กต์หนึ่งที่เดินหน้าต่อโดยไม่มีฉันเข้าร่วม ซึ่งมันไม่มีทางสำเร็จได้เลยหากไม่มีความรู้ของฉัน ทีมนั้นแย่มากจนทำงานแบบเอาคำถามมาปนกับงานราวกับเป็นเรื่องปกติ
ยิ่งไปกว่านั้น ตอนที่รู้ว่าฝ่ายบริหารกำลังกดทีมของฉันลงแล้วกลับชมพวกเขา ฉันรู้สึก ถูกดูหมิ่น มาก การติดตั้งใช้งานของพวกเขาแย่มาก
ผู้จัดการบางคนไม่ชอบให้ใครบอกว่าไอเดียของตัวเองใช้ไม่ได้ ถ้าโต้แย้งก็จะถูกมองว่าเป็นต้นเหตุของความล้มเหลว
เพราะงั้นฉันก็ทำงานต่อไป แต่คอยอัปเดตสถานการณ์ให้พวกเขาบ่อย ๆ เพื่อให้พวกเขาได้เห็นความล้มเหลวที่คาดไว้ด้วยตัวเอง และแยกฉันออกจากความล้มเหลวนั้น
ความล้มเหลวของบุคคลมีต้นทุนต่ำกว่าและให้บทเรียนได้ บางครั้งแนวทางของพวกเขาอาจใช้ได้ผลจริง ทำให้องค์กรได้ สินทรัพย์ความรู้ ใหม่เพิ่มขึ้นด้วย
พวกเขาอาจล้มเหลวแล้วก็ไม่เรียนรู้อะไรเลยก็ได้ แต่ถ้าคุณทำดีที่สุดแล้ว อย่างน้อยก็ยังมี ความสบายใจในมโนธรรม ได้
ความ “แย่” ของโปรเจ็กต์ส่วนใหญ่ตลอดวงจรชีวิตนั้นเป็นเรื่อง อัตวิสัย
เคยมีคนนอกพยายามคัดค้านและหยุดโปรเจ็กต์หนึ่ง แต่สุดท้ายพอมันเปิดตัวแล้วประสบความสำเร็จ ความน่าเชื่อถือของพวกเขาก็พังลง
ต้องระวังให้ดีว่าจะใช้ชื่อเสียงของตัวเองไปกับเรื่องไหน
ฉันรู้ว่าโลกไม่ได้มีแต่แสงแดดกับสายรุ้งเสมอไป แต่ตอนนั้นก็ผิดหวังมากจริง ๆ
เหมือนคำพูดที่ว่า “ไม่ใช่ลิงของฉัน ไม่ใช่คณะละครสัตว์ของฉัน” ถ้าไม่ใช่ความรับผิดชอบของฉัน ฉันก็จะไม่เข้าไปยุ่ง
ตอนทำงานเป็นสถาปนิก ฉันก็ไม่ให้ คำแนะนำที่ไม่จำเป็น เรื่อง UI หรือ business logic ที่ไม่ใช่ขอบเขตของฉัน
ถ้าเป็นเรื่องที่ผู้จัดการระดับบนตัดสินใจไปแล้ว ฉันก็แค่ทำตาม ตอนทำงานเป็นที่ปรึกษาก็ยึดหลักเดียวกัน
ฉันจะเข้าไปมีส่วนร่วมอย่างระมัดระวังเฉพาะในสายความเชี่ยวชาญของตัวเองเท่านั้น และทำก็ต่อเมื่อมี การอนุมัติจาก C-suite เท่านั้น
คำแนะนำนี้เหมาะกับบริษัทขนาดเล็กถึงกลางพอสมควร แต่ในบริษัทใหญ่ การคัดค้านโปรเจ็กต์แทบไม่มีความหมาย
ถ้ามันสำเร็จ คุณจะดูเหมือนคนโง่ และถ้ามันล้มเหลว คนก็ไม่จำด้วยซ้ำ
ROI ที่แท้จริงเกิดตอนเสนอทางแก้หลังความล้มเหลว คนชอบ “นักแก้ปัญหา”
เคยเสนอระบบทดสอบ E2E อัตโนมัติแล้วถูกปฏิเสธ แต่พอภายหลังเกิดปัญหาขึ้น ฉันก็หยิบ framework นั้นออกมาแล้วถูกปฏิบัติราวกับเป็น ฮีโร่
ฉันเลยรู้สึกว่าการอยู่ใน ตำแหน่งล่างกว่า แบบไม่เครียดน่าจะฉลาดกว่า
แต่บริษัทใหญ่กลับเสียเวลาหลายปีและเงินหลายล้านดอลลาร์เพราะ การเมือง
ฉันอยู่ฝั่งที่ว่า “อย่าเพิกเฉยต่อปัญหา”
ถ้าคุณอยู่ในตำแหน่งที่ช่วยได้ ก็ควรเสนอ แนวทางอื่น อย่างเงียบ ๆ ก็ยังดี ไม่จำเป็นต้องตอบโต้ด้วยอารมณ์
ในองค์กรเล็ก ไอเดียดี ๆ มักถูกนำไปใช้ได้ง่าย แต่ในองค์กรใหญ่ ความเสี่ยงทางการเมือง สูงกว่ามาก
โอกาสที่จะเสียชื่อเสียงสูงกว่าโอกาสที่จะช่วยได้จริง เพราะงั้นการเลือกว่าจะสู้เรื่องไหนจึงสำคัญ
แต่ถ้าเป็นองค์กรใหญ่ การจะเปลี่ยนโปรเจ็กต์ที่เดินหน้าไปแล้วต้องใช้ เวลาและพลังงานมหาศาล
ที่จริงแล้วบ่อยครั้งเราควบคุมโปรเจ็กต์นั้นไม่ได้เลย หัวข้อที่แม่นกว่าน่าจะเป็น “เราไม่รู้ว่าทำไมอีกทีมถึงทำแบบนั้น”
ความเป็นมืออาชีพ คือการพูดเมื่อถึงเวลาที่ต้องพูด แต่จากประสบการณ์ แทบไม่มีอะไรเปลี่ยน
ตอนนี้ฉันกำลังเห็นสถานการณ์แบบนี้อยู่จริง ๆ
เจ้าของธุรกิจเลือกใช้ แพลตฟอร์มโลว์โค้ด เพราะเรื่องต้นทุนกับความเร็ว แต่สุดท้ายกลับต้องทำ customization ระดับแฮ็กขนาดมหึมา
ทีมของฉัน deploy ด้วย TypeScript ได้วันละหลายครั้ง แต่ทีมนั้น deploy เดือนละครั้งและกำลังทำอะไรแปลก ๆ ด้วย curl
คำแนะนำนี้ยอดเยี่ยมใน ความจริงทางการเมือง ของบิ๊กเทค แต่สุดท้ายก็คล้ายสันติวิธีแบบองค์กร
ในสภาพแวดล้อมอื่น ๆ ไม่มีเงินและแรงจูงใจมากพอจะเอาไปเผาทิ้งแบบนั้น
(ถึงอย่างนั้น Lalit ก็ถ่ายทอดพลวัตขององค์กรที่ซับซ้อนได้ดีมากในบทความสั้น ๆ)
คนที่คอยจับผิดตลอดสุดท้ายจะถูกตีตราว่าเป็น คนมองโลกในแง่ร้าย
สารสำคัญจริง ๆ คือให้ เก็บพลังไว้ สำหรับช่วงเวลาที่สำคัญ ไม่ใช่ทุกปัญหาจะชี้เป็นชี้ตายต่อความอยู่รอดของบริษัท
วิศวกรไม่มีอำนาจจะ “ปล่อยให้” โปรเจ็กต์ที่แย่ทางการเมืองล้มเหลว
นั่นเป็น ความรับผิดชอบของฝ่ายบริหาร วิศวกรแค่ให้คำแนะนำทางเทคนิคก็พอ
แต่ก็ต้องเข้าใจพลวัตแบบนี้เพื่อไม่ให้กระทบอาชีพของตัวเอง
การ แย่งพื้นที่อำนาจ ระหว่างทีมผลิตภัณฑ์กับทีมแพลตฟอร์มเกิดจากการขาดผู้นำที่ชัดเจน
ถ้าอยากรู้ว่าทำไมเรื่องแบบนี้ถึงเกิดขึ้นบ่อย ลองดู บทความเกี่ยวกับ Google ได้
วิธีคิดแบบนี้พบได้บ่อยในองค์กรขนาดใหญ่ โดยเฉพาะ หน่วยงานภาครัฐ
ต้นทุนตกเป็นภาระของอีกแผนกหนึ่ง ส่วนอำนาจถูกวัดจากจำนวนคนที่อยู่ใต้การดูแล
ถ้าจะหยุด ภาวะเนื้อตายขององค์กร แบบนี้ ผู้นำต้องวางระบบการวัดผลและการป้องกันที่ชัดเจน
การเพิกเฉยต่อ ทุนทางการเมือง ไม่ได้ทำให้มันหายไป
เป็นอุปมาที่ดี
ถ้าคุณสร้างภาวะผู้นำและความไว้วางใจได้ ก็จะเกิด พื้นที่ ที่พูดได้ว่า “คุณคิดผิด”
แต่เหตุผลที่ผู้นำไม่ได้เชื่อวิศวกรเสมอไปก็เพราะ บางครั้ง วิศวกรก็เป็นฝ่ายผิด
วิศวกรเก่งมากในการหาข้อบกพร่อง แต่ไม่เก่งนักในการเข้าใจบริบทธุรกิจ
เพราะงั้นแม้จะเป็น “ไอเดียที่ดูโง่” ก็ต้องเข้าใจบริบทก่อนค่อยตัดสิน
เมื่อคุณแยกออกได้ว่าไอเดียไหนต้องฆ่าทิ้งจริง ๆ กับไอเดียไหนแค่มีข้อบกพร่อง คุณก็จะได้รับ ความไว้วางใจ ภายในองค์กร