เหตุการณ์โกหก CTO เพื่อพาทีมผ่านวิกฤต
(GrumpyOldDev.com)- โปรเจกต์ลูกค้ารายใหญ่ของบริษัทใน Fortune 500 เริ่มต้นด้วยการพึ่งพาผลิตภัณฑ์จากเวนเดอร์ แต่ในความเป็นจริงเป็น ซอฟต์แวร์ที่ใกล้เคียงสินค้ากึ่งสำเร็จรูป ซึ่งต้องปรับแต่งอย่างหนัก
- การผสานระบบของเวนเดอร์ทำให้เกิดข้อเสียของทั้งแพ็กเกจที่ไม่ยืดหยุ่นและการพัฒนาแบบสั่งทำพร้อมกัน และนำไปสู่ เดธมาร์ชของการผสานระบบ เพื่อให้ทันเปิดตัวในเดือนตุลาคม หลังส่งมอบในเดือนสิงหาคม
- การออกแบบที่เก็บธุรกรรมลูกค้าทั้งหมดไว้ในเอกสาร JSON ขนาดยักษ์เพียงฉบับเดียวก่อปัญหาประสิทธิภาพ และ ข้อจำกัด 16MB ต่อเอกสาร ของ MongoDB ในขณะนั้นก็กลายเป็นข้อจำกัดร้ายแรงเมื่อแปลงข้อมูลจริง
- บริษัทเปิดตัวช้ากว่ากำหนดหนึ่งเดือนโดยปิดบังปัญหาจากลูกค้าและเวนเดอร์ พร้อมเริ่ม การเขียนใหม่แบบ skunkworks เพื่อแทนที่การผสานระบบของเวนเดอร์ ด้วยทีมภายใน 3 คน ในเวลาประมาณ 2 เดือน
- เมื่อ CTO สั่งให้ทำงานช่วงวันหยุดก่อนคริสต์มาส หัวหน้าทีมรายงานงานที่ทำเสร็จไปแล้วให้ดูเหมือนกำลังทำคืบหน้าทุกวัน เพื่อให้เหล่านักพัฒนาได้พัก และทีมก็ทำทันกำหนดการทดสอบและการเปิดตัวในเดือนมกราคม
การออกแบบที่ผิดพลาดซึ่งเริ่มจากผลิตภัณฑ์ของเวนเดอร์
- ในบริษัท Fortune 500 แห่งหนึ่ง CTO ให้คำมั่นว่าจะส่งมอบโปรเจกต์ขนาดใหญ่ให้ลูกค้าสำคัญที่มีสายสัมพันธ์ส่วนตัวกับเขา
- ส่วนหลักถูก เอาต์ซอร์ส ให้บริษัทบริการเทคโนโลยีรายใหญ่ และเวนเดอร์อ้างว่ามีผลิตภัณฑ์ที่จะจัดการงานหนักส่วนใหญ่ได้
- ผลิตภัณฑ์จริงสอดคล้องกับความต้องการแค่คร่าว ๆ ดังนั้นเพื่อให้ทำงานได้ตามที่ต้องการจึงต้องปรับแต่งอย่างหนัก
- ผลลัพธ์คือเกิดข้อเสียของทั้งซอฟต์แวร์เวนเดอร์และซอฟต์แวร์สั่งทำพร้อมกัน
- กลายเป็น แพ็กเกจที่ไม่ยืดหยุ่น ซึ่งต้องฝืนปรับให้ทำสิ่งที่ต่างจากวัตถุประสงค์การออกแบบเดิม
- ถูก fork ออกจาก codebase หลักของเวนเดอร์ ทำให้ต้นทุนการบำรุงรักษาสูงขึ้น และมีความเป็นไปได้ว่าสักวันหนึ่งการสนับสนุนจะสิ้นสุดลง
- ผู้เกี่ยวข้องในโปรเจกต์มองว่าวิธีนี้ไม่ดี แต่ในสถานการณ์ที่สายรายงานตรงต่อ CTO เปลี่ยนแปลงบ่อย การประชุมสถานะจึงดำเนินไปในทำนองว่า “เป็นไอเดียที่ดีครับบอส”
กำหนดการล่าช้าและโครงสร้างข้อมูลที่ร้ายแรง
- ทีมพัฒนาภายในพัฒนาส่วนอื่น ๆ ของโปรเจกต์เอง ขณะที่เวนเดอร์สัญญาตลอดฤดูร้อนว่าผลิตภัณฑ์จะพร้อมผสานระบบในเร็ว ๆ นี้
- เมื่อผลิตภัณฑ์ของเวนเดอร์ถูกส่งมอบในเดือนสิงหาคม เดธมาร์ชของการผสานระบบ เพื่อเปิดตัวในเดือนตุลาคมก็เริ่มขึ้น
- ในเดือนกันยายน บั๊กระดับที่ขวางการเปิดตัวก็ปรากฏขึ้น
- ผลิตภัณฑ์ของเวนเดอร์เก็บธุรกรรมลูกค้าทั้งหมดเป็นเรคคอร์ด JSON ภายในเอกสาร JSON ขนาดยักษ์เพียงฉบับเดียว
- เมื่อข้อมูลทดสอบสะสมมากขึ้น ประสิทธิภาพก็ค่อย ๆ ช้าลง
- ทุกครั้งที่เพิ่มธุรกรรมใหม่ ระบบจะอ่านเอกสาร JSON ทั้งฉบับจากฐานข้อมูล แล้วต่อท้ายเรคคอร์ดใหม่เข้าไป
- เวนเดอร์บอกว่าสามารถแก้ได้ด้วยการเพิ่มดัชนีให้ฟิลด์ธุรกรรม และวิธีนี้ดูเหมือนช่วยได้ชั่วคราว
ข้อจำกัด 16MB ของ MongoDB และการเขียนใหม่ที่ถูกปิดบัง
- ปัญหาที่ใหญ่กว่าคือฐานข้อมูลที่เวนเดอร์เลือกคือ MongoDB และในตอนนั้น MongoDB มี ข้อจำกัด 16MB ต่อเอกสาร
- ในเดือนตุลาคม เมื่อทีมแปลงข้อมูลเริ่มนำข้อมูลลูกค้าจริงเข้าไป ก็เริ่มชนข้อจำกัด 16MB
- บริษัทตัดสินใจเริ่มใช้งานจริงช้ากว่ากำหนดหนึ่งเดือน โดยปิดบังข้อจำกัดนี้จากลูกค้า
- พร้อมกันนั้นก็เริ่ม โปรเจกต์ skunkworks เพื่อแทนที่การผสานระบบของเวนเดอร์
- ไม่แจ้งเรื่องนี้ให้เวนเดอร์ทราบด้วย
- เท่ากับปิดบังสถานการณ์สำคัญจากทั้งลูกค้าและพาร์ตเนอร์ด้านเทคโนโลยี
- เดิมฝั่งเวนเดอร์มีคนเข้าร่วมประมาณ 70 คน แต่การทำงานทดแทนภายในได้รับมอบหมายเพียง 3 คน
- 1 คนออกแบบฐานข้อมูล
- 1 คนสร้างแบ็กเอนด์ที่เชื่อมต่อกับฐานข้อมูล
- 1 คนสร้างตรรกะธุรกิจและเว็บเซอร์วิส
การตัดสินใจก่อนเดธมาร์ชช่วงวันหยุด
- ลูกค้าได้รับแจ้งว่าจะมีเวอร์ชันใหม่ให้ทดสอบในเดือนมกราคม และจะแก้ข้อบกพร่องที่ร้ายแรงที่สุดซึ่งต้องยอมรับไว้ตอนเริ่มใช้งานจริงเดิม
- แต่ลูกค้าไม่ได้รับแจ้งว่าระบบแกนหลักทั้งหมดกำลังถูกเขียนใหม่ภายในเวลาประมาณ 2 เดือน
- โปรเจกต์เดิมใช้เวลากว่าหนึ่งปีกว่าจะเปิดตัว แต่การเขียนใหม่ต้องทำโดยคน 3 คน รวมช่วงวันหยุดด้วย
- ราวกลางเดือนธันวาคม ผู้ร่วมโปรเจกต์ได้รับแจ้งให้ ทำงานช่วงวันหยุด ในรูปแบบคำสั่ง ไม่ใช่คำขอ
- สมาชิกทีมส่วนใหญ่ทำงานสัปดาห์ละ 60–80 ชั่วโมงต่อเนื่องมาแล้ว 6 เดือน จนอยู่ในภาวะหมดไฟ
- การเปิดตัวซอฟต์แวร์ให้แรงกดดันและรางวัลคล้ายการแสดงบนเวที
- ผลลัพธ์ที่เตรียมมาหลายเดือนหรือหลายปีจะไปถึงผู้ใช้จริงในวันเปิดตัว
- นักพัฒนาได้รับความรู้สึกสำเร็จอย่างแรงจากความรู้สึกว่า “ฉันทำได้แล้ว” และปฏิกิริยาของผู้ใช้
- การเปิดตัวซอฟต์แวร์อาจรู้สึกเหมือนการแสดงสดสำหรับคนอินโทรเวิร์ต
หนึ่งสัปดาห์ที่โกหก CTO แล้วให้ทีมได้พัก
- เมื่อใกล้ถึงคริสต์มาส ทีม 3 คนก็ทำซอฟต์แวร์ทดแทนเกือบเสร็จภายในหนึ่งเดือน
- ยังมีฟีเจอร์บางส่วนที่ต้องเก็บรายละเอียด แต่หากทีมไม่หมดไฟก็อยู่ในสถานะที่ทำทันกำหนดการทดสอบเดือนมกราคมได้
- เมื่อ CTO สั่งยกเลิกวันหยุด หัวหน้าทีมตอบภายนอกว่า “OK”
- แต่ในความเป็นจริง เขาบอกนักพัฒนาทั้ง 3 คนว่า “พักไปหนึ่งสัปดาห์ เดี๋ยวผมจัดการเอง”
- หัวหน้าทีมเข้าประชุมสถานะภาคบังคับทุกเช้า และรายงานต่อ CTO ราวกับว่างานที่เสร็จไปตั้งแต่เดือนก่อนยังคงกำลังดำเนินอยู่
- “ทีมกำลังทำงานกันอย่างหนักครับ วันนี้เรามาถึง milestone การผสานระบบ #73 แล้ว”
- “เมื่อวานทีมมีความคืบหน้าดี และทำเว็บเซอร์วิสอีกตัวเสร็จแล้วครับ”
- เหล่านักพัฒนากลับมาอีกหนึ่งสัปดาห์ให้หลังในสภาพที่ชาร์จพลังแล้ว
- ทีมทำทันกำหนดการเดือนมกราคม เปิดตัวได้ดี และอย่างน้อยก็ชั่วครู่หนึ่ง พวกเขารู้สึกเหมือนร็อกสตาร์
- เมื่อมองย้อนกลับไป ความรู้สึกนั้นอาจใกล้เคียงกับ Herman’s Hermits มากกว่า The Beatles แต่ก็ยังรู้สึกดีอยู่ดี
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ถ้าใครเป็นคนที่ยกเลิกวันลาพักร้อนและทำงานต่อเพียงเพราะ “ยึดกำหนดส่งเป็นหลัก” จากประสบการณ์ตรงอยากบอกว่า เลิกทำตัวโง่ได้แล้ว
ยิ่งถ้าความทุ่มเทของคุณได้รับการยอมรับ ก็ยิ่งหยุดได้ยาก แต่สุดท้ายคุณจะเสียใจกับเวลาทั้งหมดนั้น
ถ้าโครงสร้างของบริษัทคือการดึงวันหยุดและวันลาของพนักงานมาใช้เป็นเรื่องปกติเพื่อขายสินค้า บริษัทนั้นก็กำลังมีส่วนสร้างโลกที่มีปัญหาแบบทุกวันนี้
ถ้าคนจำนวนมากทำแบบนั้น คนอื่นก็ต้องทำตามมากขึ้น แต่ถ้าไม่มีใครทำ และทุกคนแสดงให้เห็นว่าคำขอแบบนั้นไร้สาระ บริษัทก็จะต้องประเมินงานให้สมจริงขึ้น แม้กระทั่งถ้าต้องกระทบกระเป๋า CEO ก็ตาม
แค่แจ้งแผนวันลา หาแบ็กอัพ ใส่ไว้ในปฏิทินทีม ส่งต่องาน แล้วก็พักผ่อน
โปรเจกต์มีเข้ามาแล้วก็ผ่านไป ตารางงานก็เลื่อนเองได้อยู่แล้ว
ถ้าคุณเริ่มขยับวันลาให้ตรงกับกำหนดโปรเจกต์ คุณจะไม่ได้หยุดพักตลอดชีวิต
ข้อยกเว้นก็มี เช่น บทบาทที่รู้กันชัดว่าเป็นช่วงงานหนักอย่างปลายปี สิ้นไตรมาส หรือฤดูภาษี ซึ่งการหายไปตอนนั้นอาจไม่เหมาะสม
ลูกพี่ลูกน้องของฉันทำงานเกือบทุกวันถึงตี 1 ตั้งแต่กันยายน 2023 ถึงมกราคม 2024 เพื่อปิดโปรเจกต์ที่บริหารกันห่วยแตก และได้หยุดแค่คริสต์มาส ซึ่งก็เพียงเพราะเป็นวันหยุดทางศาสนาที่กรรมการยอมให้ กลัวพนักงานฟ้อง
เขาพลาดเรื่องสำคัญในชีวิตหลายอย่าง และน้ำหนักลดไปราว 20 ปอนด์เพราะความเครียด
บริษัทมีเดดไลน์กระชั้นชิดในการย้ายไปใช้ระบบใหม่ ทั้งที่รู้อยู่แล้วตั้งแต่ 5 ปีก่อน แต่ก็ไม่เริ่มจนถึงปีก่อนหน้า
ถ้าพลาดเดดไลน์ จะต้องเสียค่าใช้จ่ายนอกสัญญาเป็นเงินหลายล้านดอลลาร์ สุดท้ายทีมก็ทำทัน แต่รางวัลคือไม่กี่สัปดาห์ต่อมาก็ถูกเลิกจ้างด้วยเหตุผลว่าตำแหน่งนั้นไม่มีแล้ว
ตอนนี้เขาอายุเกิน 50 และกำลังหางานในช่วงเวลาที่แย่มากสำหรับการสมัครงาน
พวกเขาเสพติดความรู้สึกว่าตัวเองมีคุณค่าและสำคัญ และพอเลิกงานก็ไม่มีอะไรอย่างอื่นให้ทำ
บางกรณี พนักงานที่ได้รางวัลก็มีส่วนรับผิดชอบต่อความเละเทะนั้นด้วย
กว่าจะถึงครั้งที่สี่ ผู้บริหารระดับสูงในห้องถึงได้ตระหนักว่าบริษัทมี ปัญหาเชิงโครงสร้าง
ถ้ามีคนอายุน้อยกำลังอ่านอยู่ อยากให้รู้ว่าเรื่องแบบนี้จะลงเอยอย่างไรนั้นขึ้นอยู่กับ บริษัทและดวง อย่างมาก
ถ้าเป็นบริษัทที่มีสุขภาพดี วิธีทำงานแบบจ้างคนนอกมาพัฒนาแบบนี้อาจไม่ได้เริ่มต้นตั้งแต่แรก
เพราะมันเป็นรูปแบบความล้มเหลวที่ชัดมากจนคนมีประสบการณ์พอจะเดาผลลัพธ์ได้ก่อนเริ่ม
ในจุดที่เร็วกว่านั้น ผู้คนคงไม่โกหก CTO ว่าทุกอย่างไปได้สวย แต่จะบอกว่ามันไม่เวิร์ก
ถ้าต้องใช้วิธีที่ฉลาดกว่าหรือสร้างสรรค์กว่านี้เพื่อกู้โปรเจกต์ ก็คงมีการปรับร่วมกับ CTO และอาจรวมถึงลูกค้าด้วย
และคงไม่มีการอัดงานยาวในวันหยุดทั้งที่ทีมหมดไฟกันอยู่แล้ว
ผู้จัดการหรือหัวหน้าทีมคงยืนชนกับผู้บริหารเพื่อความสำเร็จของโปรเจกต์และสุขภาพของทีม และหากจำเป็นก็คงยืนยันว่าทีมต้องได้พักในวันหยุด
ในองค์กรที่ “พอจะสุขภาพดีครึ่งหนึ่ง” ผู้จัดการอาจจงใจทำให้คลุมเครือหรือเว้นข้อมูลบางอย่างได้ และจะดีหรือไม่ดีก็ขึ้นกับสถานการณ์
แต่ถ้าเหมือนในเรื่องนี้ที่ผู้จัดการหรือหัวหน้าทีมโกหกแบบโจ่งแจ้งซ้ำ ๆ ต่อผู้บังคับบัญชาเหนือขึ้นไป ตามปกติแล้วไม่ว่าจะเป็นบริษัทสุขภาพดีหรือไม่ ก็มักถูกมองว่าแย่มาก
แน่นอนว่าสถานการณ์แบบนี้ตัดสินย้อนหลังแบบยืนกอดอกดูทีหลังนั้นง่ายกว่ามาก
เวลาอยู่ในจุดลำบากหรือทำงานหนักเกินไป ใครก็พลาดได้ แต่การได้ดูสถานการณ์จำลองแล้วเรียนรู้ไว้ก็มีประโยชน์ เพื่อให้ครั้งหน้าถ้าถูกโยนเข้าไปในสถานการณ์โหดคล้ายกันจะรับมือได้ดีขึ้น
ถ้าคุณอยู่ในบริษัทแบบนี้ ควรเริ่มหางานใหม่ได้แล้ว
ถ้าความเน่าเฟะของผู้บริหารไปถึงระดับนี้ มันแก้ไม่ได้ และพวกเขาก็ไม่ได้จะตั้งคุณเป็น CTO ด้วย
ทำงานมา 25 ปีแล้วยังไม่เคยเห็นเลยสักครั้ง
ใช้เวลาปีครึ่งกว่าจะแก้ได้ และระหว่างนั้นก็ย้อนการขายไม่ได้เพราะมันถูกระบุว่ามีการจัดส่ง “ชุดชั้นใน” ไปแล้ว
ทั้งที่จริงเราไม่ได้ขายชุดชั้นในเลย ขายแต่บริการเครือข่าย แต่ต้องรอให้ระบบปิดขั้นตอนการสั่งซื้อก่อนถึงจะช่วยลูกค้าได้
กรรมการคนนั้นออกไปหลังจากนั้น 1 ปี และคงพอใจไม่น้อยที่หลอก CEO งี่เง่าได้
สุดท้ายฉันก็โดนไล่ออก และไม่เหลือความเห็นใจอะไรให้บริษัทที่ลนลานนั้นเลย
พวกนั้นเป็นพวกโง่ที่พยายามเอา “โซลูชัน” ไปจ้างคนนอกทำ จนเพิ่มความเจ็บปวดให้ทุกคน
บางปัญหาก็ต้องการการแก้จริง ๆ แต่ครึ่งหนึ่งเป็นแค่ขยะที่ทำขึ้นเพื่อให้รู้สึกว่า “ประหยัดเงินเพราะไม่ได้ทำเองในบริษัท”
สุดท้ายก็ต้องจ่ายค่าจ้างตามสัญญาเพื่อดูแลขยะที่ไม่ได้สร้างเองตั้งแต่แรกอยู่ดี
หมายถึงพูดข้อเท็จจริงตรง ๆ โดยไม่ปิดปัญหา ซึ่งเป็นเรื่องที่หายากมาก
แค่ดู security memo ของ Microsoft ก็เห็นแล้ว
เรื่องไม่มีเดธมาร์ชในวันหยุด พอจะจริงอยู่บ้างถ้าคุณทำงานในธนาคารหรือ FAANG
แต่ถ้าเป็นบริษัทที่มี “วัฒนธรรมสตาร์ตอัป” ก็ลืมเรื่องนั้นไปได้เลย
เวลาผลประโยชน์ของตัวเองเข้าไปเกี่ยว ท่าทีต่อการทำงานของคนเราจะเปลี่ยนเร็วมาก แต่ฉันไม่คิดว่ามีบริษัทมากนักที่เปิดโอกาสให้คุณได้เห็นหรือได้รับโอกาสแบบนั้น
ฉันเคยทำสิ่งที่จำเป็นโดยแอบหักกฎเงียบ ๆ กลางดึกมาแล้วหลายครั้ง และคนเก่งหลายคนก็เลือกทางนั้นเหมือนกัน
แม้แต่ในธนาคารก็ยังเคยเห็นเรื่องแบบนี้
ถ้าไม่ได้เดิมพันทางการเงินก้อนใหญ่เกินกว่ามูลค่าของบริษัทหรือทีม หลายเรื่องก็มักปล่อยผ่านได้
ทำสำเร็จแล้วได้เลื่อนตำแหน่ง หรือไม่ก็ลดโอกาสเลื่อนตำแหน่งของตัวเองลง แล้วสุดท้ายก็ต้องไปหางานใหม่
ข้อความที่ว่า “ผลิตภัณฑ์ของ vendor เก็บธุรกรรมลูกค้าทั้งหมดเป็น JSON record ภายในเอกสาร JSON ขนาดยักษ์เพียงก้อนเดียว และทุกครั้งที่จะเพิ่มธุรกรรมใหม่ก็ต้องอ่านเอกสาร JSON ทั้งก้อนออกมาจากฐานข้อมูลก่อน แล้วค่อยเอา record ใหม่ไปต่อท้าย” ฟังแล้วย่อมต้องรู้สึกว่ามันบ้ามาก
คล้ายกันนั้น ผมเคยช่วยทำ technical due diligence ให้กับเป้าหมายการลงทุนที่เป็นไปได้ของกองทุนแห่งหนึ่ง และใน startup นั้น ตารางผู้ใช้ยังเก็บข้อมูลตั๋ว/การจองรวมอยู่ด้วย
เพราะตั๋วหนึ่งใบกินหนึ่งคอลัมน์ ถ้าผู้ใช้ที่ใช้งานหนักที่สุดมีตั๋ว 5 ใบตลอดประวัติทั้งหมด ก็ต้องมี 5 คอลัมน์
ตอนที่เข้าไปตรวจมีคอลัมน์เกิน 500 คอลัมน์ไปแล้ว และพวกเขากำลังหาทุนเพื่อ “ขยายระบบ”
แน่นอนว่าเป็นปัญหาที่แก้ได้ แต่ก็อย่างที่เดา ทุกอย่างถูกออกแบบมาแบบบิดเบี้ยวย้อนศรไปหมด และนั่นคือช่วง “นี่มันอะไรกัน” ที่ชัดที่สุด
สุดท้ายไม่ได้รับเงินลงทุน
ฐานข้อมูลลูกค้าและสินค้าทั้งหมดถูกเก็บไว้ในไฟล์
.jsสาธารณะไฟล์เดียวขนาดหลายเมกะไบต์ พร้อมกับ รหัสผ่านแบบ plain text และบนความเร็วอินเทอร์เน็ตยุคต้นทศวรรษ 2000 แอปต้องโหลดไฟล์นั้นทั้งก้อนก่อนถึงจะทำอะไรได้แถมตัวแอปเองก็เป็นไฟล์ยักษ์ไฟล์เดียว และในไดเรกทอรีก็มีชื่ออย่าง
index.1.js,index.final.js,index.newest.js,index.45.jsเต็มไปหมดตอนนั้นมีประสบการณ์มากพอจะรู้ว่า best practice ควรเป็นอย่างไร เลยไปบอก CEO จน CTO ถูกไล่ออก แล้วก็เริ่มสร้างใหม่โดยใส่
git,mysql, logic ฝั่งเซิร์ฟเวอร์ และโครงสร้างที่ควรจะมีจริง ๆจากนั้น Windows server ที่รันทุกอย่างนี้ก็โดนแฮ็กและกลายเป็นเซิร์ฟเวอร์หนังโป๊ ทั้งที่ผมไม่เคยเห็นเครื่องนั้นด้วยซ้ำและไม่มีสิทธิ์แอดมิน แต่ไม่รู้ทำไมสุดท้ายกลายเป็นความผิดของผม
งานสองสามที่แรกนี่ให้บทเรียนดีจริง ๆ
วิศวกรอาวุโสที่ชอบอวดว่าจบ Stanford เป็นคนออกแบบระบบนั้น
ผมเถียงยาวโดยอ้างอิงข้อมูลการใช้งานจริงว่า ถ้าปล่อยขึ้นระบบจริงมันจะไม่ scale แต่ไม่มีใครฟัง และไม่กี่สัปดาห์หลังเปิดใช้มันก็พัง
ไม่นานผมก็ย้ายทีม และที่แย่ที่สุดคือวิศวกรอาวุโสคนนั้นสุดท้ายได้เลื่อนตำแหน่ง ส่วนระบบนั้นก็ถูกโยนให้ทีมใหม่ทั้งทีมต้องไปรับศึกต่อ
การออกแบบระบบทั้งหมดเลวร้ายมาก และคงพอเดาได้ว่าทำไมถึงเป็นแบบนั้น
เลี้ยงดูปูเสื่อผู้บริหารด้วยดินเนอร์หรูและทริปท่องเที่ยว แล้วส่งมอบผลิตภัณฑ์ห่วย ๆ เพื่อให้ต่อไปยังต้องพึ่งพาพวกตัวเองอยู่
จากเรื่องที่เล่ามา CTO ไม่รู้อะไรเลย
จากมุมมองของเขา สุดท้ายทุกอย่างก็ดูเหมือนออกมาดี
ทุกคนชนะ ยกเว้นนักพัฒนาที่ทำงานสัปดาห์ละ 80 ชั่วโมง
ทุกอย่างในเรื่องนี้พังหมด รวมถึงแนวทางของตัวเอกด้วย
หัวหน้าทีมให้คนลาพักร้อนแล้วปกปิดด้วยการโกหกเป็นสิ่งที่รับไม่ได้อย่างสิ้นเชิง และค่อนข้างเข้าข่ายเรื่องที่บริษัทไล่ออกได้
อันที่จริงดูเหมือนถึงขั้น dismissal for cause ได้เลย
แต่ผู้บริหารระดับบนดูหลุดวงโคจรไปมากจนคงปล่อยผ่าน แถมอาจชมด้วยซ้ำ
มันก็ดูเป็นการกระทำที่สอดคล้องกับสภาพแวดล้อมที่เขาอยู่
ถ้าจะให้คำแนะนำหัวหน้าทีมมือใหม่ เรื่องนี้ไม่มีอะไรให้น่าภูมิใจ และทางเลือกที่ดีกว่าคือยกระดับให้เป็นปัญหาใหญ่ไปเลยว่าคนกำลังทำงานล่วงเวลา พร้อมเรียกร้องให้ใช้มาตรฐานปกติกับ vendor หรือทบทวนขอบเขตโครงการใหม่ให้สอดคล้องกับสัปดาห์ทำงานปกติ
ถ้าพยายามทำให้สถานการณ์แบบนี้ไปต่อได้ สุดท้ายคนก็อาจหมดไฟหรือโดนไล่ออกโดยไม่ได้อะไรตอบแทน
เว้นแต่ว่าคุณจะจนตรอกจริง ๆ เพราะต้องเลี้ยงดูครอบครัว หัวหน้าทีมมีหน้าที่ปกป้องเวลาทำงานที่สมเหตุสมผลของทีมจากความต้องการบ้าคลั่ง
นี่คือเนินที่ควรยอมตายเพราะถูกไล่ออก ไม่ใช่เนินที่ควรยอมตายเพราะการโกหก
เพราะฉะนั้นถ้าไม่ได้กระทบผลงาน การที่หัวหน้าทีมให้คนลาและถึงขั้นโกหกก็ถือว่ารับได้พอสมควร
ถ้าแชร์ ผู้บริหารจะทำอะไร? ก็แค่เลื่อนโครงการให้เร็วขึ้นอีก
คนที่ชอบบีบให้คนอื่นทำงานหนักขึ้นเพื่อเอาหน้าให้ตัวเอง สมควรโดนเอาคืนบ้าง
แล้วนี่ไปช่วยวันของใครกันแน่?
vendor ห่วย ๆ ที่ส่งมอบของขยะงั้นหรือ?
CTO ที่รายล้อมตัวเองด้วยพวก yes-man และเห็นได้ชัดว่าไม่รู้อะไรเลยว่าในบริษัทเกิดอะไรขึ้นงั้นหรือ?
นักพัฒนาที่ทำงานจนแทบแหลก แต่สุดท้ายได้แค่ “ไม่เป็นไร ฉันให้พวกเขาหยุดหนึ่งสัปดาห์แล้ว” งั้นหรือ?
ตัวเอกที่โกหกทุกคนเพื่อให้ทัน deadline ตามอำเภอใจของบริษัทที่ไม่แคร์พนักงานงั้นหรือ?
เรื่องนี้ทำให้ผมขนลุกทุกจังหวะ
ปกติผมก็เป็นคนทำงานหนัก และบางครั้งก็ทำเพิ่มเพื่อให้การปล่อยงานให้ลูกค้าราบรื่น แต่เรื่องนี้มันคือความบ้าล้วน ๆ
การทุ่มเวลาเพิ่มเป็นครั้งคราวทำได้ เพราะมี ความไว้วางใจ กับหัวหน้า และรู้ว่าพูดความจริงได้เสมอ
ที่จริงนั่นคือแนวคิดหลักของวัฒนธรรมไร้การโทษกัน และจะเกิดขึ้นได้ก็ต่อเมื่อทุกคนพูดความจริง
การโกหกอย่างบ้าคลั่งเพื่อให้ทัน deadline ของ CTO โง่ ๆ นี่มันไม่ปกติแบบสุด ๆ
ถ้าคุณอยู่ในสถานการณ์แบบนี้ ควรรีบออกมาแล้วไปหางานที่ดีกว่าเดี๋ยวนี้
“ความภูมิใจและความรู้สึกสำเร็จ” กับภาวะหมดไฟงั้นหรือ?
ตรงที่บอกว่า “เราทำทันกำหนดเดือนมกราคม เปิดตัวได้อย่างยอดเยี่ยม และได้เป็นร็อกสตาร์อยู่พักหนึ่ง” คำว่า “เรา” ตรงนั้นชัด ๆ ว่าหมายถึง ฉัน
อาจเป็นเพราะผมโชคดีด้วยก็ได้ แต่ผมไม่เคยถูกไล่ออกเพราะพูดความจริง และความจริงก็จำง่ายกว่าด้วย
ประมาณว่า “มีบั๊กอยู่ในไลบรารีภายนอกที่อยู่บนเส้นทางหลักของระบบ เราอาจทำให้โดนบั๊กนี้ได้ยากขึ้น แต่จะยังแก้จริง ๆ ไม่ได้จนกว่าผู้ขายจะออกแพตช์” หรือ “จำนวนผู้ใช้เพิ่มขึ้นจนปัญหาด้านประสิทธิภาพโผล่มาเร็วกว่าที่คิด ระหว่างที่ใช้เวลา 2 เดือนแก้ เราจะเลือกทุ่มค่าอินฟราสามเท่าเพื่อบรรเทา หรือจะยอมเสียลูกค้าเพราะปัญหาประสิทธิภาพ” หรือ “ลูกค้ารายใหญ่ที่สุดเพิ่งรู้ว่าตัวเองต้องการอะไรหลังจากได้ต้นแบบรอบแรก สิ่งนั้นต่างจากที่เราคิดว่าจะต้องสร้างโดยสิ้นเชิง เราจะสร้างสิ่งนั้นแล้วทำรายได้ หรือจะวิ่งตามความฝันต่อไปจนตาย”
จะว่าไปก็อาจเป็นเพราะผมโชคดีอีกนั่นแหละ แต่ความซื่อสัตย์ใช้ได้ผลดีกับผมเสมอ
เพราะงั้นอย่างที่คนอื่นบอกไว้ พวกเขาจะพูดว่า “จะเอาไปพิจารณา” แล้วค่อย ๆ กันคุณออกไปช้า ๆ หรือจับไปทำงานจิปาถะ
อีกทางเลือกหนึ่งคือเงียบไว้ แล้วดูพวกเขาดิ้นรนอยู่นานก่อนจะล้มเหลว
ปกติจะกินเวลาราว 1 ปี แต่ผมก็เคยเห็นมันพังภายใน 2–3 เดือน แล้วไตรมาสถัดมาก็มีการโละผู้นำกันแทบยกแผง
ถ้ามีคนถามความเห็น คุณอาจอธิบายข้อกังวลอย่างมีชั้นเชิงได้ แต่ถ้าไม่มีใครถาม คุณก็อาจเลือกเงียบได้เหมือนกัน
ประเด็นสำคัญคือคุณจะลุกขึ้นมาชี้ปัญหาในแผนของคนที่อยู่เหนือคุณ ซึ่งกำลังพยายามจะเอาหน้าเอาผลงานหรือไม่
ทันทีที่พูดออกไป พวกเขาจะรู้สึกว่าการตัดสินใจของตัวเองถูกตั้งข้อสงสัย และรับมันเป็นการโจมตีส่วนตัว
ทำแบบนี้โดยไม่สร้างศัตรูนั้นยากมาก และศัตรูก็อยู่ยาว ขณะที่ความเสียหายจากศัตรูคนเดียวมักชดเชยด้วยมิตรหลายคนก็ยังไม่พอ
เพราะงั้นก็ต้องเล่นเกมนี้
รายละเอียดที่สำคัญมากคือ ตัวเอกกำลังโกหกเรื่องที่เสร็จไปแล้ว
ทุกเช้าเขาเข้าประชุมสถานะเดธมาร์ชที่ต้องมีร่วมกับ CTO แล้วพูดว่า “ทีมกำลังทำงานกันหนักมาก”, “วันนี้เราชนจุดรวมมิลสโตน #73 แล้ว”, “เมื่อวานมีความคืบหน้าดีและปิดเว็บเซอร์วิสได้อีกหนึ่งตัว” ทั้งที่ความจริงทั้งหมดนั้นเป็นงานที่เสร็จไปตั้งแต่เดือนก่อนแล้ว
มองอีกมุมหนึ่ง มันดูคล้ายกับการสัญญาให้น้อย แต่ส่งมอบให้เกิน
ถ้าเขาโกหกว่า งานที่ยังไม่เสร็จเสร็จแล้ว นั่นคงน่ารังเกียจกว่านี้มาก
แน่นอนว่ามันเสี่ยงกว่ามาก และถ้าพอทีมกลับมาแล้วต้องบอกว่า “นี่คือตั๋วงาน พอดีผมบอก CTO ไปแล้วว่ามันเสร็จ งั้นรีบหน่อย” มันก็คงไม่ดีกับทีมเลย
ปฏิสัมพันธ์ระหว่างนักพัฒนากับผู้บริหารมักทุกข์ทรมานอย่างหนักจากความไม่สมมาตรของข้อมูลและการขาดความไว้วางใจ
ตอนนี้ผมกำลังทำโปรเจ็กต์อัปเดตโค้ดเบสที่รันอยู่บนคอมไพเลอร์เก่ามากมานานแล้ว
เราทำกันมา 1 ปีแล้ว และส่วนใหญ่ของระบบก็เสร็จไปมาก แต่ยังเหลือส่วนหนึ่งที่สำคัญพอสมควร
ผู้บริหารไม่เข้าใจกระบวนการ และก็ไม่มั่นใจด้วยว่าโปรเจ็กต์นี้จะสำเร็จในที่สุด
โปรเจ็กต์ซอฟต์แวร์ โดยเฉพาะงานแปลงหรือย้ายระบบ มีประวัติความล้มเหลวยาวนาน ผมเลยไม่โทษที่พวกเขากังวล
เราเคยประชุมติดตามความคืบหน้าทุกสัปดาห์ แต่ตอนนี้เพิ่มเป็นสัปดาห์ละ 2 ครั้ง เหมือนพวกเขาคิดว่ามันจะช่วยให้เร็วขึ้น
ส่วนใหญ่พวกเขาไม่ได้เข้าร่วมเองโดยตรง และให้ผู้จัดการระดับกลางทำหน้าที่ส่งต่อข้อมูล
จากมุมของนักพัฒนา มันชัดเจนอยู่แล้วว่างานนี้ทำสำเร็จได้ และโดยส่วนตัวผมไม่เคยสงสัยในความสำเร็จเลย
แค่ระบบมันใหญ่และเก่า เลยทำให้ระยะเวลาไม่แน่นอน
สิ่งที่เหลืออยู่ไม่ใช่ระดับหลายปี แต่ระดับไม่กี่เดือน และผมก็รู้กฎ 80/20 ดี แต่ตอนนี้เราลงลึกเข้าไปใน 20% สุดท้ายนั้นแล้ว
สำหรับผู้บริหาร มันมีแค่สถานะเสร็จ/ไม่เสร็จแบบทวิภาค จึงประเมินความคืบหน้าได้ยาก และไม่มี “ความเชื่อถือ” ต่อสิ่งที่เราพูด
ซึ่งก็เข้าใจได้
ต่อให้ตลอด 1 ปีที่ผ่านมาเราไม่ทำอะไรเลย เอาแต่นั่งประชุม พวกเขาก็คงไม่รู้
นี่เป็นสัญญาแบบราคาคงที่ เราเลยไม่มีเหตุผลจะยื้อเวลา แต่ความเสี่ยงทั้งหมดอยู่ที่พวกเขา
พวกเขาจ่ายเงินไปมากแล้ว และกำลังกังวล
พวกเขาตัดสินใจทางเทคนิคได้ดีโดยอาศัยคำแนะนำจากผู้เชี่ยวชาญภายนอก แต่ก็ยังไม่อุ่นใจ
ท้ายที่สุด ถ้าโปรเจ็กต์ล้มเหลว คนที่เจ็บหนักคือพวกเขา ไม่ใช่เราอย่างเท่าไร
ไม่มีทางออกง่าย ๆ
จะบอกว่าผู้จัดการทุกคนต้องมีพื้นฐานเทคนิคก็ไม่ได้ และเทคโนโลยีนี้ก็ไม่ใช่ธุรกิจหลักของพวกเขาด้วย
ต่อให้จ้างที่ปรึกษาเพิ่ม ก็คงไม่ได้ทำให้สบายใจขึ้น
สิ่งที่ดีที่สุดที่เราทำได้คือเดินหน้าต่อและส่งมอบงาน
จะเป็นก้อนงานระดับหนึ่งเดือนก็ได้ แยกให้ละเอียด แล้วแตกทุกอย่างออกเป็นงานย่อย
ไม่จำเป็นต้องสมบูรณ์แบบ มีส่วนหยาบ ๆ บ้างก็ได้
ผมแนะนำให้ตั้งชื่อแต่ละก้อนให้น่าจดจำและสนุกหน่อย
เช่นใช้ชื่อการเต้นรำคลาสสิกอย่าง แทงโก้ ชะชะช่า หรือวอลทซ์ ก็เหมาะดี
จากนั้นนัดประชุมกับผู้จัดการ รวมถึงผู้บริหารระดับสูงด้วย และขอให้ผู้จัดการระดับกลางเข้ามาสังเกตการณ์เดลี่สแตนด์อัป
ให้ทุกคนยืนไว้เพื่อให้ประชุมจบเร็ว และติดตามความคืบหน้าเทียบกับรายการงานที่มี
ถ้ามีงานเพิ่มขึ้นหนึ่งชิ้น หรือช้าลงนิดหน่อย คนส่วนใหญ่จะไม่ตกใจ ตราบใดที่ภาพรวมยังขยับเข้าใกล้เป้าหมาย
เราทั้งคู่ต่างรู้ว่าการปล่อยใช้งานจริงคือด่านใหญ่ แต่คุณไม่จำเป็นต้องบอกพวกเขาจนกว่าจะพร้อม
ความล่าช้าทำให้ผู้บริหารกังวล ซึ่งก็เข้าใจได้ แต่การประชุมให้มากขึ้นไม่ได้ทำให้งานเร็วขึ้น
การที่ PM เข้ามาเช็กอินวันละ 30 นาที พร้อมพูดว่า “ผมจะสนับสนุนและจัดหาทุกอย่างที่จำเป็นเพื่อพาโปรเจ็กต์กลับเข้าราง” ไม่ได้ช่วยอะไร
สิ่งที่ต้องการมีแค่อย่างเดียวคือประชุมน้อยลง
อุปสรรคมีเพียงเวลา และที่เวลาเป็นอุปสรรคก็เพราะตั้งแต่แรกผู้บริหารระดับบนยืนกรานกับกำหนดการที่ไม่สมจริง
สุดท้ายแล้ว การที่พวกเขาแสดงออกว่าไม่เชื่อนักพัฒนา ก็เท่ากับไม่เชื่อในความสามารถด้านการบริหารของตัวเองในการคัดเลือกนักพัฒนาที่ถูกต้อง
พวกเขากำลังทำส่วนสำคัญส่วนหนึ่งของงานตัวเองได้แย่มาก
โปรเจ็กต์ระยะ 1 ปีไม่ควรมีแค่สถานะเสร็จ/ไม่เสร็จแบบทวิภาค
ควรมีตัวชี้วัดความคืบหน้าที่จัดการได้
ผู้บริหารสูงสุดไม่จำเป็นต้องมีพื้นฐานเทคนิค แต่ในลำดับชั้นใดชั้นหนึ่งต้องมีคนที่แปลความคืบหน้าให้อยู่ในรูปแบบที่เข้าใจได้เสมอ
มีอยู่สองอย่างที่รู้แน่ ๆ เกี่ยวกับ vendor นี้ซึ่งยากจะให้อภัย
อย่างแรกคือพวกเขาทำให้ logic หลักต้องพึ่งพาการขยายขนาด Mongo record แบบไม่สิ้นสุด และอีกอย่างคือ ถ้ามีคนที่เก่งกว่าค่าเฉลี่ยนิดหน่อยสักสามคนตั้งใจทำจริงจัง ก็น่าจะแทนที่มันได้ภายในราว 3 เดือน
ความจริงที่ว่า vendor นี้ไปถึงจุดที่สามารถทำธุรกิจกับลูกค้า Fortune 500 ได้ แสดงให้เห็นว่าองค์กรที่คล้ายลูกค้ารายนี้รู้สึกหมดหนทางแค่ไหน แม้จะเป็นงานซอฟต์แวร์ที่ไม่ได้ใหญ่มาก
จริง ๆ แล้วขอบเขตของโปรเจ็กต์นี้ดูเป็นอะไรที่บางคนที่นี่ก็น่าจะทำเป็นโปรเจ็กต์งานอดิเรกได้
เลยเข้าใจได้ว่าทำไม Retool ถึงเป็นที่นิยมในหมู่ผู้นำทางเทคนิค แต่ไม่จำเป็นต้องนิยมในหมู่วิศวกร
เลยสงสัยว่าจะมีแนวทางผลิตภัณฑ์แบบอื่นอะไรที่ช่วยปิดช่องว่างเดียวกันนี้ได้บ้าง
ด้วยสเปรดชีต ไม่ว่าใครที่อยู่ตำแหน่งล่างแค่ไหนในองค์กร ก็สามารถสร้างต้นแบบเครื่องมือหยาบ ๆ ที่เกือบใช้งานได้ภายในไม่กี่วัน โดยไม่ต้องไปยุ่งกับคนอื่นในองค์กร
ก่อนยุคสเปรดชีต คุณต้องโน้มน้าวผู้บริหารให้ฝ่าย IT รับคำขอไปทำ ซึ่งแค่กระบวนการนั้นก็ใช้เวลาอย่างน้อย 3 เดือนแล้ว
จากนั้นก็คงต้องรออีกหลายไตรมาสกว่าจะได้ implementation แบบหยาบ ๆ ที่เกือบทำงานได้ เขียนด้วย Cobol หรือ C หรืออะไรทำนองนั้น แต่ก็ไม่ตรงกับความต้องการ
มีนักพัฒนาสองสามคนกับเจ้าหน้าที่ support อีกสองสามคนไปพบผู้ใช้ และนักพัฒนาก็กำลังสร้างเครื่องมือใหม่มา 6 เดือนเพื่อแก้ปัญหาใหญ่
แต่วันนั้นกลับเป็นวันแรกที่ผู้ใช้ปลายทางได้เห็นมัน
ไม่นานหลังจากนั้นพวกเราก็กำลังขับรถกลับข้ามเส้นเขตรัฐ และพวกนักพัฒนาก็หางจุกก้นกันหมด
เท่าที่ฉันรู้ ไม่มีใครพูดถึงโปรเจ็กต์นั้นอีกเลย
ใช้งานพวกพนักงานใหม่ทั้งหมด แล้วคิดเงินในอัตราค่าชั่วโมงของนักพัฒนาระดับ senior
อยากให้คนเลิกใช้ ภาพเฮดเดอร์ที่สร้างโดย AI กันสักที
มันทำให้เสียสมาธิตั้งแต่เริ่มเลย
นั่นคือโค้ดอยู่หลังจอภาพเหรอ?
แล้วที่พนักพิงเก้าอี้ด้านหลังก็มีโค้ดด้วยเหรอ? หรือว่าคนที่นั่งอยู่กำลังนั่งบน iPad ยักษ์?
ถ้าจะใช้ภาพ AI อย่างน้อยก็ควรพยายามไม่ให้มันดูประหลาดและเพี้ยนสุด ๆ ขนาดนี้
ภาพแบบนี้สร้างได้ในเวลาแค่ไม่กี่วินาที ความหมายคือ นี่คือภาพที่ดีที่สุดจากที่เลือกมาแล้วเหรอ?