เหตุการณ์ที่โกหก CTO เพื่อเอาตัวรอดจากวิกฤต

เรื่องราวที่นักพัฒนาโกหก CTO

• เป็นเรื่องสมัยที่ผู้เขียนทำงานอยู่ในบริษัทระดับ Fortune 500 เมื่อหลายปีก่อน
• ตอนนั้น CTO รับโปรเจกต์ใหญ่จากลูกค้าคนสำคัญที่มีความสัมพันธ์ส่วนตัวกัน และตัดสินใจเอาส่วนสำคัญไปจ้างบริษัทผู้ให้บริการเทคโนโลยีรายใหญ่ทำแบบเอาต์ซอร์ส
• แต่ "ผลิตภัณฑ์" ของเวนเดอร์นั้น แท้จริงแล้วหากจะให้ตรงตามความต้องการจำเป็นต้องปรับแต่งครั้งใหญ่ ซึ่งเป็นตัวเลือกที่แย่ที่สุด
• ในการประชุมอัปเดตสถานะกับ CTO ไม่มีใครคิดว่าไอเดียนี้ดี แต่ทุกคนก็พูดแค่ว่า "เป็นความคิดที่ดีครับ/ค่ะ บอส"
• สุดท้ายพอเวนเดอร์ส่งมอบ "ผลิตภัณฑ์" ก็เข้าสู่เดือนกันยายนไปแล้ว และเริ่มช่วงเดดมาร์ชเพื่อให้ทันเปิดตัวในเดือนตุลาคม
• ระหว่างการทดสอบพบทั้งปัญหาด้านประสิทธิภาพและบั๊กหนัก เช่น ชนข้อจำกัดเอกสาร 16MB ของ MongoDB
• จึงแจ้งลูกค้าว่าจะเลื่อนการเปิดตัวออกไป 1 เดือน พร้อมกับเริ่มโปรเจกต์ลับเพื่อสร้างระบบทดแทนการเชื่อมต่อกับเวนเดอร์ไปพร้อมกัน
• ผู้เขียนซึ่งตอนนั้นเป็นนักพัฒนาหนุ่มไฟแรง ได้รับมอบหมายทีมงาน 3 คนและเริ่มพัฒนาระบบทดแทน
• กลางเดือนธันวาคม ซอฟต์แวร์ทดแทนเกือบเสร็จหลังจากทำงานหนักมาตลอด 1 เดือน แต่ทุกคนก็อยู่ในภาวะหมดไฟ
• ตอนนั้น CTO เดินเข้ามาและบอกว่าจะยกเลิกวันหยุด และผู้เขียนก็ตอบว่า "รับทราบ"
• แต่เมื่อนึกถึงคำแนะนำของพ่อ ผู้เขียนจึงบอกให้ทีมไปพักร้อน แล้วตัวเองไปเข้าประชุมอัปเดตสถานะช่วงเดดมาร์ชกับ CTO เพียงลำพังและโกหก
  • "ทีมกำลังทำงานกันอย่างหนักครับ วันนี้เราไปถึงจุดรวม milestone ครั้งที่ 73 แล้ว"
  • "เมื่อวานทีมคืบหน้าได้ดีมากครับ เราปิดอีกหนึ่ง web service ได้แล้ว"
• หนึ่งสัปดาห์ต่อมา เมื่อทีมที่ได้พักกลับมา ทุกคนก็พร้อมอีกครั้ง และสุดท้ายสามารถเปิดตัวได้สำเร็จทันกำหนดในเดือนมกราคม

ความเห็นของ GN⁺

• นี่เป็นกรณีที่แสดงให้เห็นถึงภาวะผู้นำในการพาโปรเจกต์ไปสู่ความสำเร็จท่ามกลางสภาพแวดล้อมที่ย่ำแย่และความคาดหวังที่เกินจริง โดยเฉพาะการใส่ใจสภาพร่างกายและจิตใจของสมาชิกทีมที่น่าประทับใจ
• อย่างไรก็ตาม การโกหก CTO ไม่ใช่สิ่งที่พึงประสงค์ เพราะในระยะยาวอาจทำให้สูญเสียความไว้วางใจในองค์กรและก่อปัญหาใหญ่กว่าเดิมได้
• แม้ความล้มเหลวในการคัดเลือกเวนเดอร์และการบริหารเอาต์ซอร์สจะเป็นความรับผิดชอบของ CTO อย่างมาก แต่ในกระบวนการแก้ไขก็น่าจะต้องมีการสื่อสารที่โปร่งใสและเชิงรุกมากกว่านี้
• เพื่อป้องกันภาวะหมดไฟของนักพัฒนา ควรวางกำหนดการให้สมจริงตั้งแต่แรกและจัดสรรกำลังคนให้เพียงพอ แนวทางแบบ crunch mode ไม่ควรเป็นเรื่องปกติ
• อีกทางเลือกที่น่าอ้างอิงเมื่อเจอสถานการณ์คล้ายกันคือแนวทาง Agile ซึ่งเน้นการพัฒนาเป็นรอบสั้น ๆ และรับฟีดแบ็กอย่างต่อเนื่อง เพื่อลดความเสี่ยงและควบคุมภาระงานของทีม

[GN⁺]

ความเห็นจาก Hacker News

• การทำงานหนักเกินไปและการยกเลิกวันหยุด:
  • การทำงานหนักเกินไปและยกเลิกวันหยุดเพื่อให้ทันเดดไลน์ที่ไม่สมจริงไม่ใช่เรื่องฉลาด และสุดท้ายจะต้องเสียใจภายหลัง
  • บริษัทที่พึ่งพาการให้พนักงานเสียสละวันหยุดเพื่อส่งมอบผลิตภัณฑ์ กำลังส่งเสริมวัฒนธรรมการทำงานที่มีปัญหา
• บริษัทที่ดีต่อสุขภาพ vs บริษัทที่ไม่ดีต่อสุขภาพ:
  • ในบริษัทที่ดีต่อสุขภาพ คนที่มีประสบการณ์น่าจะคาดการณ์ปัญหาของแนวทางการเอาต์ซอร์สได้ และยกข้อกังวลตั้งแต่เนิ่น ๆ
  • การสื่อสารอย่างเปิดเผย การร่วมกันพยายามหาทางแก้ และการที่ผู้จัดการออกหน้าปกป้องสวัสดิภาพของทีม เป็นสัญญาณของสภาพแวดล้อมที่ดี
  • เรื่องนี้บรรยายถึงสถานการณ์ที่ไม่ดีต่อสุขภาพ ซึ่งผู้จัดการโกหกผู้บังคับบัญชาซ้ำแล้วซ้ำเล่า
• แนวปฏิบัติของเวนเดอร์ที่ชวนอึ้ง:
  • แนวทางของเวนเดอร์ที่เก็บธุรกรรมทั้งหมดไว้ในเอกสาร JSON ขนาดมหึมา และต้องอ่านทั้งก้อนทุกครั้งที่มีการอัปเดตนั้นชวนเหลือเชื่อ
  • อีกตัวอย่างหนึ่งคือสตาร์ตอัปที่เก็บข้อมูลตั๋วของผู้ใช้ไว้เป็นคอลัมน์เพิ่มเติมในตารางผู้ใช้ จนเกิดคอลัมน์นับร้อย
• สถานการณ์ที่ไร้ประสิทธิภาพและภาวะผู้นำ:
  • วิธีที่หัวหน้าทีมโกหกเรื่องวันหยุดเป็นสิ่งที่ยอมรับไม่ได้ และอาจเป็นการกระทำผิดที่ถึงขั้นถูกไล่ออกได้
  • แนวทางที่ดีกว่าคือการคัดค้านการเรียกร้องให้ทำงานล่วงเวลาอย่างไม่สมเหตุสมผล และยืนยันขอบเขตโครงการที่เหมาะสมรวมถึงความรับผิดชอบของเวนเดอร์
  • หัวหน้าทีมมีหน้าที่ปกป้องทีมจากข้อเรียกร้องบ้าคลั่ง แม้จะต้องเสี่ยงกับตำแหน่งงานของตัวเองก็ตาม
• ไม่มีใครได้ประโยชน์:
  • เวนเดอร์ส่งมอบงานคุณภาพต่ำ CTO ไม่รับรู้ความจริง นักพัฒนาทำงานหนักเกินไป และตัวเอกต้องพึ่งพาการโกหก
  • นี่คือสถานการณ์บ้าคลั่งที่ไม่มีใครควรยอมรับ การย้ายไปที่ทำงานที่ดีกว่าเป็นทางเลือกที่พึงประสงค์
• ความซื่อสัตย์และความโปร่งใส:
  • การพูดกับผู้บริหารอย่างตรงไปตรงมาเกี่ยวกับปัญหาทางเทคนิค ปัญหาด้านประสิทธิภาพ การเปลี่ยนแปลงขอบเขตงาน ฯลฯ ได้ผลดีกับบางคน
  • การโกหกเพื่อให้ทันเดดไลน์ที่ตั้งขึ้นแบบตามอำเภอใจโดยผู้นำที่ห่างไกลจากความเป็นจริงไม่ใช่แนวทางที่ดี
• ช่องว่างความไว้วางใจระหว่างนักพัฒนากับผู้บริหาร:
  • มักมีความไม่สมดุลของข้อมูลและการขาดความไว้วางใจระหว่างนักพัฒนากับผู้บริหารที่ไม่ใช่สายเทคนิค
  • ผู้จัดการประเมินความคืบหน้าได้ยาก และรู้สึกไม่แน่ใจเกี่ยวกับความสำเร็จของโครงการ
  • เนื่องจากความเสี่ยงอยู่ฝั่งธุรกิจ นักพัฒนาจึงต้องผลักดันและส่งมอบผลงานเพื่ออุดช่องว่างความไว้วางใจนี้
• รับปากให้น้อยแล้วส่งมอบให้เกินคาด:
  • การที่ตัวเอกโกหกว่าทำงานที่เสร็จไปแล้วว่าเสร็จแล้ว อาจมองได้ในระดับหนึ่งว่าเป็นการ "รับปากให้น้อยแล้วส่งมอบให้เกินคาด"
  • แต่การโกหกเกี่ยวกับงานที่ยังไม่เสร็จนั้นเสี่ยงกว่า และอาจบั่นทอนกำลังใจของเพื่อนร่วมทีมเมื่อต้องกลับมาทำต่อ
• องค์กรที่ไร้ทางออกและเครื่องมือโลว์โค้ด:
  • แนวปฏิบัติที่ย่ำแย่ของเวนเดอร์และขอบเขตโครงการที่ดูธรรมดา แสดงให้เห็นว่าบริษัทขนาดใหญ่บางแห่งรู้สึกหมดหนทางกับโครงการซอฟต์แวร์เพียงใด
  • สิ่งนี้อาจอธิบายความนิยมของเครื่องมือโลว์โค้ดอย่าง Retool ได้ อย่างน้อยในหมู่ผู้นำด้านเทคโนโลยี แม้ไม่ใช่ในหมู่วิศวกรก็ตาม
• ความซื่อตรงและการกล้าปฏิเสธ:
  • "ร็อกสตาร์" ตัวจริงคือคนที่มีความซื่อตรง และมีความกล้าพอจะปฏิเสธความโง่เขลาและข้อเรียกร้องที่ไม่สมเหตุสมผล
  • การชดเชยให้กับความไร้ความสามารถอย่างร้ายแรง หรือการแบกรับภาระแทนทั้งทีม ไม่ใช่ความรับผิดชอบของปัจเจกบุคคล