วิธีง่าย ๆ ในการลดทอนผลิตภาพซอฟต์แวร์ (2023)

เทคโนโลยี

• บังคับให้มีการเขียนระบบหลักใหม่เป็นเวลา 6-18 เดือน แล้วโทษ CTO คนก่อน
• สนับสนุนให้แต่ละคนใช้ภาษาและเฟรมเวิร์กคนละแบบ
• แบ่งระบบตามขอบเขตแบบตามอำเภอใจ เพื่อให้ฟีเจอร์หนึ่งต้องมีหลายระบบเข้ามาเกี่ยวข้อง
• สร้างสภาพแวดล้อมการพัฒนาที่ซับซ้อน โดยให้ต้องรัน service mesh ที่มีอย่างน้อย 12 บริการ
• ทำให้สภาพแวดล้อม production กับสภาพแวดล้อมของนักพัฒนาแตกต่างกันให้มากที่สุด
• ทำการ deploy ให้น้อยที่สุดเท่าที่จะทำได้ และแนะนำให้ระมัดระวังกับการ deploy แบบสุดโต่ง
• นำกระบวนการที่ซับซ้อนมากมาใช้กับการแก้โค้ดและเวิร์กโฟลว์ทั่วไป โดยอ้างว่าเป็นเพราะ "ความปลอดภัย" หรือ "การปฏิบัติตามข้อกำหนด"
• ให้บันทึกงานทุกอย่างลงในตัวติดตามงาน และให้กลุ่มอย่างน้อย 5 คนตรวจทาน จัดลำดับความสำคัญ และอนุมัติ
• ห้ามทุกอย่างที่อยู่นอกขอบเขตงานเดิม เช่น ห้ามเก็บกวาดโค้ดหรือปรับปรุงอื่น ๆ
• สร้างเกือบทุกอย่างภายในองค์กรแม้จะไม่ใช่ความสามารถหลัก โดยให้เหตุผลว่า "เพื่อหลีกเลี่ยง vendor lock-in"
• ยืนกรานให้เพิ่มชั้น abstraction ให้กับทุกอย่าง ใช้ vendor ที่ถูก abstract ไว้แล้วและยังเพิ่ม abstraction layer เข้าไปอีก
• สนับสนุนการตัดสินใจทางเทคนิคที่มองโลกสวยเกินจริงในเรื่องการรองรับขนาด วางแผนให้รองรับโหลดอย่างน้อย 3 เท่าจากปัจจุบัน
• สนับสนุนการเป็นเจ้าของระบบร่วมกัน เพื่อไม่ให้ใครรู้สึกรับผิดชอบต่อการบำรุงรักษา
• ยืนกรานให้รวมศูนย์เกือบทุกอย่างไว้เป็น "แพลตฟอร์ม" รักษาทีมแพลตฟอร์มให้อยู่ในภาวะคนไม่พอ และห้ามทีมอื่นสร้างสิ่งที่แพลตฟอร์มอาจเป็นเจ้าของได้
• ทำให้ทีมแพลตฟอร์มเปลี่ยน API บ่อย ๆ และบังคับให้ทีมอื่นรีแฟกเตอร์โค้ดตามเวอร์ชันล่าสุด
• จ้าง "สถาปนิก" แล้วบังคับให้มี "การทบทวนสถาปัตยกรรม" แม้กับการเปลี่ยนแปลงเล็กน้อย
• บังคับให้มี "การทบทวนความปลอดภัย" แม้กับการเปลี่ยนแปลงเล็กน้อย

ผลิตภัณฑ์

• เมินตัวชี้วัดที่มีประโยชน์ด้วยเหตุผลเชิงวิชาการ เช่น เรียกว่า "มีอคติ" หรือเป็น "ตัวชี้วัดแบบล่าช้า"
• เลือกตัวชี้วัดแบบ vanity metrics ที่ไม่เกี่ยวกับคุณค่าทางธุรกิจ เลือกตัวชี้วัดที่มีสัญญาณรบกวนสูง
• มองทุกอย่างเป็น "การเดิมพันครั้งใหญ่" และยืนกรานว่าจะไม่ปล่อยออกไปจนกว่าทุกอย่างจะเสร็จสมบูรณ์ทั้งหมด
• ถือว่าทุกฟีเจอร์เป็น "สิ่งจำเป็น" และเป็นส่วนสำคัญของ "version zero" โดยไม่ยอมประนีประนอมเด็ดขาด
• จัดทำแผน "เชิงกลยุทธ์" ที่ละเอียดมาก
• เปลี่ยนทิศทางบ่อย ๆ
• มองข้ามการปรับปรุงที่เห็นได้ชัดว่าเป็น "การเพิ่มประสิทธิภาพเฉพาะจุด"
• ใช้เทรนด์ล่าสุดมาผูกมัดทรัพยากร เริ่ม "กลยุทธ์ AI" ที่ดูสมเหตุสมผลเพียงผิวเผิน และใช้เงินจำนวนมากกับ vendor และที่ปรึกษาเพื่อสิ่งนี้
• สนับสนุนให้ผู้จัดการผลิตภัณฑ์ใช้เวลาส่วนใหญ่ไปกับ "กลยุทธ์" และ "การวางแผน"
• ทำให้วิศวกรและผู้จัดการผลิตภัณฑ์ใช้งานผลิตภัณฑ์ภายในองค์กรได้ยากหรือเป็นไปไม่ได้
• ดูแคลนผู้ใช้ภายในว่าเป็น "คนโง่"

ภาวะผู้นำ

• ผูกผลตอบแทนเข้ากับตำแหน่งและขนาดทีม เพื่อกระตุ้นให้เกิดการขยายตัวเกินจำเป็น
• พูดเสียงดังเรื่องกลยุทธ์ ฟีเจอร์ หรือความซับซ้อนทางเทคนิค
• ทำการเข้าซื้อกิจการราคาแพงเพื่อเข้าสู่พื้นที่ผลิตภัณฑ์ใหม่ ๆ พูดถึง "synergy" แล้วก็ยกเลิกผลิตภัณฑ์ที่ซื้อมา
• ใช้เส้นประในโครงสร้างการรายงานให้มากเข้าไว้
• ทำให้คนจำนวนมากที่สุดเท่าที่จะเป็นไปได้ต้องรายงานต่อผู้จัดการจากทีม สถานที่ หรือหน้าที่งานอื่น เพื่อให้ผู้จัดการไม่สามารถกำกับดูแลผู้ใต้บังคับบัญชาได้
• ย้ายคนที่ผลงานต่ำไปทีมอื่นบ่อย ๆ
• นำคนที่ผลงานสูงไปใส่ในโครงการ R&D ที่คาดเดาสูงและผลลัพธ์ไม่แน่นอน
• เรียกประชุมเสมอแม้กับการตัดสินใจเล็กน้อย
• ยืนกรานให้ "ผู้มีส่วนได้ส่วนเสีย" ทุกคนต้องเข้าร่วมประชุม

การจ้างงาน

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

การจัดการโครงการ

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

ผลลัพธ์

• การทำให้ผลิตภาพลดลงเป็นเรื่องยาก แต่ถ้าคุณกระโดดร่มลงหลังแนวข้าศึกแล้วไปได้งานเป็น CTO ก็ทำให้เกิดขึ้นได้
• สำหรับคนที่ไม่ได้ชอบทำลายล้าง: นี่คือเรื่องของวิธีดึงผลิตภาพของทีมออกมาให้ได้มากที่สุด ผลิตภาพเกิดจากสิ่งเล็ก ๆ ที่สะสมรวมกัน
• ถ้าสิ่งเล็ก ๆ 100 อย่าง แต่ละอย่างเก็บภาษีผลิตภาพ 5% ทุกอย่างจะช้าลง 131 เท่า ถ้าต้องการให้วิศวกรมีความสุข คุณต้องปฏิเสธสิ่งเล็ก ๆ 100 อย่างที่ฟังดูมีเหตุผลและน่าเชื่อเหล่านั้น

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

• บทความนี้อธิบายวิธีการต่าง ๆ ที่บั่นทอนผลิตภาพในการพัฒนาซอฟต์แวร์อย่างมีอารมณ์ขัน ทำให้เห็นชัดว่าพฤติกรรมใดบ้างที่ควรหลีกเลี่ยงจริง ๆ
• การลดหนี้ทางเทคนิคและรักษาวัฒนธรรมการพัฒนาที่มีประสิทธิภาพเป็นสิ่งสำคัญ หัวใจสำคัญคือการหลีกเลี่ยงความซับซ้อนและระบบราชการที่ไม่จำเป็น
• การสร้างสภาพแวดล้อมที่ช่วยยกระดับขวัญกำลังใจของทีมและส่งเสริมการทำงานร่วมกันเป็นสิ่งสำคัญ ซึ่งส่งผลโดยตรงต่อการเพิ่มผลิตภาพ
• บทความนี้ช่วยให้เข้าใจความซับซ้อนของวิศวกรรมซอฟต์แวร์และการจัดการได้ดีขึ้น โดยเฉพาะให้มุมมองที่เป็นประโยชน์กับวิศวกรมือใหม่
• โปรเจ็กต์อื่นที่มีลักษณะคล้ายกันคือหนังสืออย่าง "The Phoenix Project" ซึ่งกล่าวถึงวิธีเพิ่มประสิทธิภาพของ IT และ DevOps

[rockmkd]

มีบริษัทไหนบ้างที่ไม่เป็นแบบนั้น? ฮือๆ
ถึงจะเป็นบริษัทเล็กที่ประสบความสำเร็จ แต่พอโตขึ้นก็ดูเหมือนจะกลายเป็นแบบนั้นกันหมด...

[vvvvvv]

มีเกือบทุกอย่างที่เคยถูกสั่งให้ทำในบริษัทก่อนหน้านี้เลย ทั้งการบังคับใช้แพลตฟอร์มที่เอาไปใช้จริงก็ไม่ได้... เมินตัวชี้วัดประสิทธิภาพมาตรฐาน... สั่งให้ทำงานเดิมซ้ำอีก เป็นต้น

[dkswjdrka]

เอ่อ..?

[whitetor]

นี่มันเหมือนกับ 'วิธีเขียนโค้ดให้บำรุงรักษายาก: คุณก็ใช้ชีวิตสบาย ๆ กินเที่ยวไปตลอดในฐานะนักพัฒนาได้เหมือนกัน'...

[bus710]

ผมขอเลือกตายดีกว่า

[eyelove]

โอ๊ะ..โอ๊ะ!..อ๊าา!!.. อ๊ะ!... อา......

น่าเสียดายที่เราเห็นอยู่หลายอย่างในองค์กรของเราด้วยเหมือนกัน T_T

[wedding]

ทำให้นึกถึงหนังสือระดับตำนานอย่าง "วิธีเขียนโค้ดให้บำรุงรักษายาก" เลยครับ

[laeyoung]

ฉันก็เล่มนี้เหมือนกัน!

[gcback]

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

[GN⁺]

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

• ไม่มั่นใจว่าข้อเสนอของ CIA ได้ผลจริงหรือไม่: ไม่เคยเห็นเหตุผลที่น่าเชื่อถือว่าข้อเสนอของ CIA เดิมนั้นได้ผลจริงหรือไม่ และโดยธรรมชาติแล้วองค์กรก็มักจะเพิกเฉยต่อคนแบบนั้น

• วิธีทำลายบริษัท: การเลื่อนตำแหน่งคนที่ไม่ดีไปเป็นผู้บริหาร และทำให้พวกเขาไปปรับแต่งสิ่งที่ไม่ทำกำไร อาจสร้างความเสียหายอย่างหนักให้บริษัทได้

• วิธีเป็น CTO ที่ทำลายล้าง: ทำแทบไม่ต้องทำอะไรเลย กำจัดคนที่มีความสามารถ และสร้างวัฒนธรรมที่ผลักภาระความรับผิดชอบลงไปข้างล่าง ซึ่งทำได้ง่าย

• การทำงานผ่านช่องทางทางการและการขอคำสั่งเป็นลายลักษณ์อักษร: สำหรับบางคน การทำงานผ่านช่องทางทางการและการขอคำสั่งเป็นลายลักษณ์อักษรอาจมีประสิทธิภาพมากกว่า

• ความแตกต่างระหว่าง OSS กับ CIA: OSS (สำนักงานบริการยุทธศาสตร์) ได้จัดทำหนังสือที่ยอดเยี่ยมในช่วงสงครามโลกครั้งที่ 2 และ CIA ก่อตั้งขึ้นในปี 1947

• ความสำคัญของวิสัยทัศน์: ขั้นตอนที่สำคัญที่สุดคือการกำจัดคนที่มีวิสัยทัศน์อย่างสอดคล้องเกี่ยวกับวิธีการทำงานของผลิตภัณฑ์โดยรวม หรือเกี่ยวกับอนาคตที่ดีกว่า

• ควรอัปเดตส่วนการจ้างงาน: ควรกำหนดให้แก้โจทย์ยากของ Leetcode ให้ได้ภายใน 30 นาที และไม่ยอมรับความไม่แน่นอนหรือความสงสัย

• ความแตกต่างระหว่างสภาพแวดล้อมจริงกับสภาพแวดล้อมนักพัฒนา: ในสถาปัตยกรรมสมัยใหม่มีบริการภายนอกจำนวนมาก จึงหลีกเลี่ยงไม่ได้ที่สภาพแวดล้อมจริงกับสภาพแวดล้อมนักพัฒนาจะแตกต่างกัน และนั่นหมายความว่านักพัฒนาต้องเชื่อมต่ออินเทอร์เน็ตอยู่เสมอ

• การตัดสินใจเพื่อปกป้องตัวเอง: การตัดสินใจหลายอย่างที่เข้าข่าย "การบ่อนทำลาย" เกี่ยวข้องกับการพยายามโน้มน้าวผู้คนว่าเป็นความพยายามปกปิดความผิดพลาดของตนเอง

• "แนวปฏิบัติที่ดีที่สุด" ในบริษัท: กฎแปดข้อที่ยกมาในช่วงต้นบทความ ถูกปฏิบัติอย่างเคร่งครัดในบริษัทในฐานะ "แนวปฏิบัติที่ดีที่สุด"

• พฤติกรรมของที่ปรึกษา: ที่ปรึกษาจำนวนมากทำพฤติกรรมเหล่านี้เกือบทั้งหมด หรือไม่ก็ทั้งหมด

• ปัญหาในอุตสาหกรรมเทคโนโลยี: ในอุตสาหกรรมเทคโนโลยีมีคนจำนวนมากที่ทำพฤติกรรมแบบนี้ และพวกเขาเชื่อว่าตนเองกำลังช่วยอยู่

• ประสบการณ์ในบริษัทขนาดใหญ่: ประสบการณ์อันจำกัดในบริษัทขนาดใหญ่สอดคล้องกับเนื้อหาในบทความนี้อย่างมาก