- เมื่อการ “เคลื่อนไหวให้เร็ว” กลายเป็นมากกว่าความจำเป็นเชิงปฏิบัติการ และถูกมองว่าเป็น หลักฐานของความจริงจังและความทะเยอทะยาน การทบทวนอย่างรอบคอบจึงถูกปฏิบัติราวกับเป็นท่าทีที่ขัดขวางแรงขับเคลื่อน
- ความเร็วที่แท้จริงเกิดขึ้นเมื่อเข้าใจงาน ข้อจำกัด และสิ่งที่ต้องพึ่งพา จากนั้นตัดสินใจให้ชัดเจนแล้วลงมือทำ แต่หลายองค์กรกลับเอา ข้อกำหนดที่คลุมเครือและการตัดสินใจที่ยังไม่เสร็จ มาห่อหุ้มว่าเป็นความเร็ว
- เมื่อเร่งขั้นตอนของการทำความเข้าใจ การทำใหม่จะถูกบันทึกว่าเป็น “การวนซ้ำ” ความสับสนกลายเป็น “การจัดแนว” และความล้มเหลวที่ป้องกันได้กลับถูกเรียกว่า “การเรียนรู้” ขณะที่ระบบที่ไม่มีใครไว้ใจและขั้นตอนเลี่ยงระบบชั่วคราวค่อยๆ แข็งตัวกลายเป็นโครงสร้างหลักของธุรกิจ
- ความเร่งด่วน คือภาวะที่งานสำคัญมีข้อจำกัดด้านเวลาจริงๆ แต่ความลนลานคือภาวะที่พยายามหาความสบายใจทางอารมณ์จากการลงมือทำ โดยไม่ต้องแบกรับภาระในการทำให้เกิดความชัดเจน
- หากจะทำงานให้ถูกต้อง ต้องเข้าใจและตัดสินใจก่อน จากนั้นทบทวนให้เพียงพอแล้วค่อยขยับ และราคาของการข้ามการคิด บริบท และความรับผิดชอบ จะย้อนกลับมาเป็นระบบที่พัง ทีมที่หมดไฟ ลูกค้าที่จากไป และบาดแผลเชิงปฏิบัติการระยะยาว
กระบวนการที่ทำให้ความเร็วถูกเข้าใจผิดว่าเป็นความก้าวหน้า
- การเปิดตัว ตอบสนอง จ้างงาน ขยาย และเปลี่ยนทิศทางอย่างรวดเร็ว มักถูกปฏิบัติราวกับเป็น หลักฐานของความทะเยอทะยานและความจริงจัง ในตัวมันเอง
- คำขอให้ชะลอและคิดก่อน มักถูกมองว่าเป็นการขัดขวางแรงส่ง
- การชี้ให้เห็นแผนที่เปราะบางเชิงโครงสร้าง มักถูกมองว่าเป็นท่าทีด้านลบ
- ความเร็วทำงานเหมือน ยาเสพติดขององค์กร ที่ทำให้รู้สึกว่ากำลังเคลื่อนไหวอยู่ แม้ไม่มีวินัยในการตัดสินใจก็ตาม
- ทุกคนรู้สึกว่ายุ่งและเร่งด่วน และสามารถใช้ตัวกิจกรรมเองเป็นหลักฐานของความคืบหน้าได้
- แต่หลายสิ่งที่ถูกเรียกว่าความเร็ว แท้จริงแล้วคือความใจร้อนที่เปลี่ยนชื่อใหม่
- ความเร็วที่แท้จริง เกิดขึ้นได้เมื่อ งานและข้อจำกัดชัดเจน ผู้รับผิดชอบที่มีความสามารถลงมือทำตามการตัดสินใจที่ปิดจบอย่างสะอาด และไม่ต้องกลับมาเถียงซ้ำเรื่องเดิม
- สถานการณ์ที่มักถูกเรียกว่าความเร็ว กลับยังเต็มไปด้วยข้อกำหนดที่คลุมเครือ การตัดสินใจที่ยังไม่เสร็จ สิ่งที่ต้องพึ่งพาที่ยังไม่ได้ทบทวน และบริบทที่ไม่เพียงพอ
- เป็นโครงสร้างที่คาดหวังให้คนถัดไปมาแก้ปัญหาที่ยังไม่ได้ตัดสินใจ แล้วก็แปลกใจเมื่อผลลัพธ์พัง
- มันล้มเหลวเพราะถูกสร้างขึ้นบนสมมติฐานว่ากระบวนการคิดคือส่วนที่แพงที่สุด
- รูปแบบนี้ไม่ได้เกิดแค่ในซอฟต์แวร์ แต่ยังพบใน ปฏิบัติการ การจัดการ การจ้างงาน โลจิสติกส์ บริการลูกค้า และการพัฒนาผลิตภัณฑ์ เมื่อกิจกรรมถูกเข้าใจผิดว่าเป็นความก้าวหน้า
- เมื่อรีบเร่งขั้นตอนที่ควรใช้เพื่อทำความเข้าใจ แล้วต้องใช้เวลาเป็นสิบเท่าเพื่อเก็บกวาดผลลัพธ์ ความหมายที่บันทึกไว้ก็กลับหัวกลับหางไปด้วย
- งานที่ทำแบบลนลานในตอนแรก กลายเป็น “การลงมืออย่างรวดเร็ว”
- การเก็บกวาดกลายเป็น “เรื่องไม่คาดคิด” การทำใหม่กลายเป็น “การวนซ้ำ” ความสับสนกลายเป็น “การจัดแนว” และความล้มเหลวที่ป้องกันได้กลายเป็น “การเรียนรู้”
- เมื่อทุกการตัดสินใจเล็กๆ เลือกความเร็วเหนือความเข้าใจ ก็จะสะสมเป็นระบบที่ไม่มีใครเชื่อถือ ขั้นตอนที่ไม่มีใครเข้าใจ การประชุมที่ไม่มีใครอยากเข้า และแดชบอร์ดที่ไม่มีใครเชื่อ
- ทางเลี่ยงชั่วคราวท้ายที่สุดจะกลายเป็น โครงสร้างจำเป็น ที่ค้ำธุรกิจเอาไว้
- แม้แต่ “การทำให้ทันสมัย” ในภายหลังก็มักแทนที่แค่ความวุ่นวายที่มองเห็นได้ โดยปล่อยการบูชาความเร็วไว้เหมือนเดิม
วิธีขยับอย่างถูกต้องโดยไม่ลนลาน
- การชะลอความเร็วไม่ได้หมายถึงการทำงานให้ช้า แต่หมายถึงการไม่ข้าม กระบวนการทำให้งานชัดเจน
- ต้องตรวจสอบว่าแท้จริงแล้วเรากำลังพยายามสร้างอะไร และใครบ้างที่ต้องพึ่งพามัน
- ต้องดูว่าถ้าสมมติฐานผิด อะไรจะพัง เรารู้อะไรอยู่แล้ว และกำลังแกล้งทำเป็นไม่รู้อะไรบ้าง
- ต้องตรวจสอบจุดที่เคยล้มเหลวในอดีต และเงื่อนไขที่จำเป็นต่อความสำเร็จด้วย
- คำถามพื้นฐานเหล่านี้ทำให้ความพึงพอใจฉับพลันจากการเคลื่อนไหวหายไป และทำให้ไม่สามารถซ่อนอยู่หลังความเร่งด่วนหรือ PowerPoint ได้
- เพราะต้องเข้าใจงานจริงๆ และรับผิดชอบต่อการตัดสินใจในรายละเอียด จึงมักกลายเป็นสิ่งที่ผู้คนพยายามหลีกเลี่ยง
- ความเร็วเปิดทางให้ปล่อยการตัดสินใจให้คลุมเครือต่อไป และโยนรายละเอียดไปเป็นเหตุฉุกเฉินของคนอื่น
- เมื่อเกิดเหตุฉุกเฉิน ก็กลับใช้การแก้ให้เร็วขึ้น การจ้างให้เร็วขึ้น การเปลี่ยนคนให้เร็วขึ้น หรือการปล่อยให้เร็วขึ้น เป็นทางออกอีกครั้ง ทำให้ปัญหาเดิมถูกทำซ้ำราวกับเป็นวิธีรักษา
- ความเร่งด่วน เหมาะสมเมื่อมีข้อจำกัดด้านเวลาจริงๆ ในงานสำคัญ แต่ความลนลานเกิดขึ้นเมื่อพยายามหาความสบายใจทางอารมณ์จากการลงมือทำ โดยไม่ต้องรับภาระของความชัดเจน
- การวิจารณ์ความเร็วไม่ได้หมายความว่าควรจงใจทำให้ช้าหรือเปลี่ยนทุกการตัดสินใจให้กลายเป็นการประชุม
- และก็ไม่จำเป็นต้องใช้เวลา 6 เดือนสร้างโครงสร้างพื้นฐานสำหรับ deploy เองเพื่อพิสูจน์ว่าตนรอบคอบ
- จุดยืนคือควรให้เกียรติงานมากพอที่จะทำมันให้ถูกต้องตั้งแต่แรก
- ลำดับที่ถูกต้องคือ เข้าใจ → ตัดสินใจ → ทบทวนให้เพียงพอ → ลงมือทำ
- ถ้ากลับลำดับ คุณจะจ่ายราคาเป็นระบบที่พัง ทีมที่หมดแรง และลูกค้าที่ค่อยๆ จากไปอย่างเงียบๆ
- และยังทิ้งบาดแผลด้านปฏิบัติการที่ต้องคอยเลี่ยงอยู่หลายปี เพราะไม่มีความอดทนพอจะกลับไปทำความเข้าใจสาเหตุอีกครั้ง
- การเปลี่ยนแปลงของตลาด การแข่งขัน ลูกค้าที่จู้จี้ ทีมเล็ก งบประมาณตึงตัว และโอกาสที่กำลังจะปิด อาจเป็นข้อจำกัดจริง
- แต่สิ่งเหล่านี้ก็มักถูกใช้เป็นข้ออ้างเพื่อหลีกเลี่ยงงานที่ช้ากว่าและยากกว่า นั่นคือการทำความเข้าใจสถานการณ์ก่อนจะลงมือ
- วิธีที่ดีกว่าคือยังคงตัดสินใจและปล่อยงานต่อไปได้ โดยรักษาความนิ่งไว้
- โดยไม่เข้าใจผิดว่าความตื่นตระหนกคือความจริงจัง ว่าทุกการหยุดคือความอ่อนแอ หรือว่าการเคลื่อนไหวในตัวมันเองคือความก้าวหน้า
- หากข้ามการคิด ความชัดเจน บริบท และความรับผิดชอบไป คุณอาจเร็วขึ้นชั่วคราว แต่ระบบและผู้ดูแลรักษาจะต้องรับภาระผลลัพธ์นั้นต่อไป
- งานบางอย่าง จะเร็วขึ้นได้ ก็ต่อเมื่อเราเลิกรีบก่อนเท่านั้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ต้องทำให้ช้าจึงจะลื่นไหล และต้องลื่นไหลจึงจะเร็ว
สิ่งที่ได้เรียนรู้เกี่ยวกับความเร็วคือ ผู้คนมักไม่วัดผล หรือวัดแต่สิ่งที่สะดวกในตอนนั้นแบบผิดๆ การวัดที่ถูกต้องทำให้เป็นตัวเลขเชิงวัตถุวิสัยได้ แต่ก็มีคนที่วัดผลได้ไม่ดีตั้งแต่ต้น คล้ายคนที่ขาดการใคร่ครวญตนเอง ค่าที่คาดเดามักผิดเกิน 80% และคลาดเคลื่อนเป็นหลักๆ ได้ง่าย การปรับปรุงเล็กๆ ที่ได้จากการวัดผลมักสะสมเป็นผลใหญ่เกินคาด และวิธีที่แน่นอนที่สุดในการทำให้เร็วขึ้นคือเปลี่ยนเทคโนโลยีและเทคนิค การจ้างคนเป็นเรื่องช้า และการเพิ่มคนเข้าไปในโปรเจกต์ที่ล่าช้าจะยิ่งทำให้ช้าลง ยิ่งปรับปรุง ชั้นล่างของเทคโนโลยีสแต็ก มากเท่าไร ก็ยิ่งได้ทั้งความเร็วและความยืดหยุ่น และนำสิ่งนั้นไปใช้ขยายขนาดได้
ต่อให้ไม่ผิดในเชิงเทคนิค แต่ถ้าใช้เวลา 6 เดือนแทนที่จะเป็น 6 สัปดาห์เพื่อหาวิธีแก้ปัญหาเชิงปฏิบัติให้ลูกค้า จนลูกค้าเหนื่อยหน่าย โปรเจกต์ก็อาจล้มเหลวได้ ในมุมของลูกค้า ความเร็วคือฟีเจอร์และคุณค่าทางเศรษฐกิจ
แค่นึกถึงความรู้สึกเวลาต้องเรียกช่างมาซ่อมแอร์เสียในบ่ายเดือนสิงหาคมที่เท็กซัสก็พอ ในงานที่ซับซ้อนและไม่แน่นอน กระบวนการทำซ้ำอย่างรวดเร็วเป็นสิ่งสำคัญ และว่ามันเร็วเกินไปหรือไม่นั้นควรตัดสินจากปฏิกิริยาที่ลูกค้าแสดงออกมา
การซ่อมแอร์ใกล้เคียงกับการแก้ฉุกเฉินมากกว่า และอุปมาเปรียบที่ดีกว่าคือการสร้างบ้านในไม่กี่วันเพื่อหนีความร้อนของเท็กซัส แล้วต้อง ซ่อมฉนวน ผนังที่ยังไม่ยึดแน่น สายไฟภายนอก และท่อที่น้ำพุ่งออกมาใต้บ้านอยู่ 6 ปี
ในเหตุขัดข้องร้ายแรงทางธุรกิจ ผู้คนมักลองทำอะไรก็ได้โดยไม่สนตำแหน่งหน้าที่ จนยิ่งเพิ่มความสับสน และใช้เวลารวมนานขึ้นกับกระทบวงกว้างกว่าตอนที่ร่วมมือกัน ทำความเข้าใจปัญหา แล้วค่อยแก้ การ เข้าหาอย่างสงบและสม่ำเสมอ ที่หยุดหายใจลึกๆ ชั่วครู่เพื่อมองปัญหาทั้งหมดรวมถึงความเร่งด่วน กลับเร็วกว่าท้ายที่สุด และยังไปด้วยกันได้กับการแจ้งความคืบหน้าให้ลูกค้าทราบและลดความกังวลของพวกเขา
การบูชาความเร็วคือผลผลิตของเวลาตามตารางของเงินลงทุนแบบ venture นักลงทุน venture มีเส้นตายในการคืนผลตอบแทนให้ผู้ลงทุนของตน จึงจะสนใจต่อเมื่อทำให้เชื่อได้ว่าจะโต 10 เท่าภายในกรอบเวลานั้น
ถ้ายึดติดกับตารางนั้นอย่างจริงจัง ก็มีแนวโน้มจะกำหนดเส้นตายตามอำเภอใจโดยไม่สนความเป็นจริงทางเทคนิค และกลายเป็นคนที่ล้มโปรเจกต์เพียงเพราะทำไม่ทันเส้นตายนั้น
ถ้าโครงสร้างและเป้าหมายแบบโตบ้าคลั่งไม่งั้นตายไม่ตรงกับคุณ ก็ไม่ควรรับเงินลงทุนแบบ venture หากอยากพัฒนาโดยไม่เร่งรีบ ก็ควรเลือกสตาร์ตอัปที่มี product-market fit (PMF) ที่พิสูจน์แล้ว และมีทีมขายชั้นยอดที่รับผิดชอบเส้นโค้งการเติบโต
สตาร์ตอัปที่ได้ทุน venture กลับลำบากน้อยกว่า เพราะมีเงินสดกันชนหนาพอและยังมีโอกาสได้การสนับสนุนเพิ่ม นักลงทุนต้องการผลตอบแทนสูงกว่าตลาดหุ้น ส่วนผู้ก่อตั้งก็ต้องการความมั่งคั่งมากกว่าการทำงานที่ FAANG ดังนั้น แรงกดดันให้ได้ผลตอบแทนคุ้มความเสี่ยง จึงเกิดขึ้นไม่ว่ารูปแบบการลงทุนจะเป็นแบบใด
พันเอกกองทัพบกผู้มองโลกแบบประชดประชันมักพูดว่า “ถ้าหั่นเวลาให้สั้นพอ แม้แต่การเคลื่อนไหวเป็นคาบก็ดูเหมือนความก้าวหน้า” และ “ต้องทำให้ช้าจึงจะลื่นไหล และต้องลื่นไหลจึงจะเร็ว”
แม้คำนวณตามตัวเลขก็เช่นกัน การเพิ่มความเร็ว 1 ไมล์ต่อชั่วโมงในทางตรงระยะ 1 ใน 4 ไมล์ ให้ผลดีกว่าการเพิ่ม 1 ไมล์ต่อชั่วโมงในโค้งช้าระยะ 100 ฟุต
การที่สามารถระงับแรงกระตุ้นที่จะถอดหน้ากากแล้วขยี้ตาได้ เป็นเพราะ การฝึกช้าๆ ซ้ำๆ นำไปสู่การกระทำที่รวดเร็วแบบอัตโนมัติ การเปลี่ยนแม็กกาซีนและการใช้ forward assist ก็เป็นหลักการเดียวกัน
ในมุมมองของวิศวกรรม การทำอย่างช้าๆ จะทำให้งานลื่นไหลและเร็วขึ้นในภายหลัง แต่ในมุมมองของฝ่ายขาย ความช้าก็คือช้าเฉยๆ หากระหว่างที่สัญญาว่าอีก 6 เดือนคุณภาพจะดีขึ้น คู่แข่งกลับคว้าสัญญาหายากที่กินระยะ 5~10 ปีไปได้ ผลลัพธ์อาจไม่ใช่แค่ต้องไปโฟกัสงานอื่น แต่ถึงขั้นต้องเลิกจ้างทั้งทีมเพราะไม่มีที่ให้ลงงาน
จุดล้มเหลวคือการต้องการผลลัพธ์ตั้งแต่แรก ขณะเดียวกันก็อ้างว่าให้เวลาบริษัททำให้ถูกต้อง หากใช้เวลา 6 เดือนหรือ 1 ปีไปกับ infrastructure, design system, component library, system design แล้วไม่มีผลงานให้เห็น การคิดต้นทุนและติดตามงานจะเริ่มผิดเพี้ยน และคำสัญญาว่า ต่อจากนี้การพัฒนาจะเร็วขึ้นมาก ก็ใช้ไม่ได้กับผู้บริหาร
ต้องแยกให้ออกระหว่างการทำงานช้าอย่างรอบคอบและมีความรับผิดชอบ กับการช้าเพราะไร้ความสามารถ แรงกดดันจากตลาดมีอยู่จริง และทีมที่ช้าอยู่ตลอดย่อมหายไป บางครั้งความช้านำไปสู่ความลื่นไหลและความเร็ว บางครั้งก็แค่ช้าเฉยๆ ดังนั้นสิ่งสำคัญคือ รู้ความต่างของสองแบบนี้
ช่วงต้นอาชีพได้ตระหนักว่าบางครั้งผู้บริหารจะคิดว่าถ้าเราไม่แสดงความเครียดออกมาให้เห็น ก็แปลว่าเราไม่ได้มองเรื่องนั้นอย่างจริงจัง คำพูดอย่าง “ยังไม่รู้สึกถึงความเร่งด่วน” เคยสั่นคลอนสภาพจิตใจของฉันมากในตอนนั้น
“อย่าสับสนระหว่างการเคลื่อนไหวกับความก้าวหน้า เก้าอี้โยกเคลื่อนไหวอยู่ตลอด แต่ไม่ได้พาไปข้างหน้า” — Alfred A. Montapert
ไม่ใช่ว่าจะไม่เห็นด้วยกับบทความนี้ แต่ในการถกเถียงกลับไม่มีเรื่อง กำหนดเส้นตาย เลย ทั้งที่ความต้องการให้เร็วไม่ได้เกิดขึ้นในสุญญากาศเสมอไป ถ้ามันไม่เป็นธรรมก็ควรโต้แย้ง แต่ในโลกจริงเรามีสิทธิเลือกได้เสมอหรือไม่ก็ยังน่าสงสัย
ถ้าเร่งเพียงเพื่อให้ทันเส้นตาย ตอนนั้นอาจดูเหมือนเร็วขึ้น แต่ผลลัพธ์ที่ได้จะด้อยกว่าสิ่งที่ทีมทำได้ดีที่สุด และภายหลังก็ต้องใช้เวลามากขึ้นเพื่อเก็บกวาดสิ่งที่เละเทะ ไม่ได้หมายความว่าทุกสถานการณ์ต้องทำแบบสบายๆ แต่หมายถึงว่าในสภาพแวดล้อมที่ทุกคนรีบอยู่ตลอดแต่ก็ยังแทบไม่เคยทำเป้าหมายได้ ควรพิจารณาว่า ตัวความเร่งรีบนั่นเองคือสาเหตุของความล้มเหลวหรือไม่
หลังจาก FedEx ปล่อย dashboard ใหม่สำหรับพนักงานขนส่ง ระบบค้างระหว่างขั้นตอนรับ MacBook พนักงานจึงดำเนินการด้วยมือแล้วให้ใบเสร็จไป แต่กลับพิมพ์ฉลากผิด ผลคือโน้ตบุ๊กไม่เคยไปถึง Apple ทำให้ต้องอธิบายสถานการณ์ซ้ำกับพนักงานหลายคนอยู่หลายสัปดาห์ และหนึ่งเดือนต่อมา Apple ต้องส่งโน้ตบุ๊กเครื่องใหม่มูลค่า 5,000 ดอลลาร์มาให้ นี่คือตัวอย่างของซอฟต์แวร์ที่ถูกเร่งเพราะเส้นตายตามอำเภอใจจนทำให้เสียเวลาและค่าใช้จ่ายมหาศาล และการบอกให้ชะลอไม่ได้หมายถึงความสบายใจทางจิตวิทยา แต่หมายถึงการป้องกันความวุ่นวายในปัจจุบันและอนาคต
อัตราเร็วกับเวกเตอร์ความเร็วไม่เหมือนกัน คนที่ตกจากตึก 100 ชั้นอาจคิดว่าตัวเองกำลังพุ่งด้วยอัตราเร็วมหาศาล แต่เวกเตอร์ความเร็วที่มุ่งสู่เป้าหมายจะเกิดขึ้นเมื่อเราพิจารณาความพึ่งพาต่างๆ อย่างรอบด้านและนำทางอย่างถูกต้อง
ในบริษัทใหญ่ ส่วนมากแล้วไม่มีอะไรสำคัญทั้งสองอย่าง และผลงานส่วนใหญ่ก็แย่มาก เส้นตายถูกวางให้สอดรับกับการประเมินผลงานประจำปี และคนที่ผู้บริหารชอบก็จะสร้างเรื่องเล่าความสำเร็จว่าตนทำตัวชี้วัดที่ถูกต้องได้ หรือเปลี่ยน milestone เพื่อให้ได้รับรางวัล ขณะที่ผู้บริหารเองก็ได้รางวัลเช่นกันเพราะอ้างว่ากำกับความสำเร็จนั้นได้อย่างยอดเยี่ยม
ยิ่งทำงานมานาน หลักการนี้ก็ยิ่งชัดเจนขึ้น แต่ถ้าเพื่อนร่วมงานอายุน้อยกว่ายังไม่เข้าใจเรื่องนี้แล้วกลับอยู่เหนือชั้นการจัดการของฉัน ก็อาจเป็นปัญหาได้
บางครั้งฉันจะชวนให้คิดด้วยคำพูดอย่าง “ผลงานที่ใหญ่ที่สุดบางชิ้นของฉันคือ โค้ดที่ฉันเลือกจะไม่เขียน”