อะไรคืออุปสรรคในการใช้แนวปฏิบัติที่ดีที่สุด พวกเขาจะเอาชนะได้อย่างไร? [ปิด]

เราทุกคนเห็น (และพวกเราส่วนใหญ่เขียน) รหัสที่เขียนไม่ดีมากมาย ทำไม? อะไรทำให้เรายอมรับการปฏิบัติที่ไม่ดีแทนที่จะดี

คำตอบที่ชัดเจนที่สุด (สำหรับฉัน) คือ "ความไม่รู้" แต่ฉันแน่ใจว่านั่นไม่ใช่เหตุผลเดียว มีคนอื่นอะไรอีกบ้าง? เราจะทำอะไรได้บ้างเพื่อเอาชนะการล่อลวงให้เขียนรหัสที่ไม่ดี?

ความต้านทานต่อการเปลี่ยนแปลง

นั่นคือโปรแกรมควบคุมที่สำคัญที่อยู่เบื้องหลังความไม่รู้การจัดการที่ไม่ดีเป็นต้น

บทที่ 30 ของPeopleware 2nd Editionทุ่มเทให้กับหัวข้อนี้ และมันเสนอราคาจากหนังสือโดยที่ปรึกษาที่รู้จักกันดีคนหนึ่งซึ่งเขียนไว้ก่อนหน้านี้ว่า:

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

Niccolo Machiavelli: เจ้าชาย (1513)

DeMarco และ Lister กล่าวต่อไปถึงการจดจำมนต์ก่อนที่จะขอให้ผู้คนเปลี่ยนแปลง:

การตอบสนองขั้นพื้นฐานต่อการเปลี่ยนแปลงนั้นไม่สมเหตุสมผล แต่เป็นเรื่องของอารมณ์

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

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

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

สำหรับการอ้างอิงขั้นตอนที่อธิบายไว้ข้างต้นถูกกำหนดไว้ในรูปแบบการเปลี่ยนแปลงของ Satir (ชื่อหลังจากSatir Virginia )

PéterTörökถูกต้อง แต่ยังเหลือประเด็นสำคัญและแง่ดีไว้หนึ่งข้อ:

• คนอาจชอบการเปลี่ยนแปลงที่พวกเขามีส่วนร่วม แต่พวกเขาแทบจะไม่เคยชอบการเปลี่ยนแปลงที่เกิดขึ้นกับพวกเขา

ดังนั้นให้พวกเขามีส่วนร่วมให้พวกเขามีส่วนร่วมในความคิดปล่อยให้พวกเขาสร้างสเตคในนั้นและมันจะไม่เจ็บปวดมาก

หมายเหตุ: นี่คือที่เกี่ยวข้องกับการเขียนโปรแกรมในการที่หลายโครงการซอฟแวร์ที่ประสบความสำเร็จในทางเทคนิคล้มเหลวเพราะผู้ใช้พวกเขาปฏิเสธ

เวลาดูเหมือนจะเป็นเรื่องใหญ่ที่ฉันทำงาน

เช่นทำไมจึงนำการทดสอบหน่วยมาใช้เมื่อคุณต้องเขียนโค้ดเพิ่มเติมและใช้เวลานานกว่าจึงจะได้ผลิตภัณฑ์ที่ releasable ได้ ลูกค้า x ต้องการตอนนี้! รหัสเร็วขึ้น!

(เห็นได้ชัดว่านี่ไม่ได้จบลงด้วยดี)

นี่ก็เป็นผลมาจากการจัดการและเศรษฐกิจที่ไม่ดีไม่ได้เรียกเก็บเงินจากลูกค้าเพียงพอที่จะใช้เวลากับการทำสิ่งที่ถูกต้อง

แม้จะมีหลักฐานขนาดใหญ่ที่ตรงกันข้าม แต่คนมักจะเป็นสัตว์ที่มีเหตุผลมาก เหตุผลที่ผู้คนไม่ยอมรับแนวปฏิบัติที่ดีที่สุดเช่น TDD คือพวกเขาไม่คิดว่ามันจะคุ้มค่า พวกเขาคิดว่าการปฏิบัตินั้นไม่ได้ดีที่สุด และจริง ๆ แล้วมันจะเสียค่าใช้จ่ายมากกว่าที่จะช่วยพวกเขา หรือพวกเขาคิดว่าผลประโยชน์นั้นช่างเหลือน้อยการเปลี่ยนแปลงนั้นมีค่ามากกว่าประโยชน์เล็กน้อย บรรทัดล่างคือปัญหาของแนวปฏิบัติที่เหมาะสมที่สุดคือปัญหาของบรรทัดล่าง

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

คุณแสดงสิ่งนี้อย่างไร โดยการใช้แนวปฏิบัติที่ดีที่สุดด้วยตัวคุณเอง! ไม่มีสิ่งใดที่จะโน้มน้าวใจผู้อื่นได้ดีไปกว่าพฤติกรรมของคุณ ถ้าคุณปฏิบัติตามแนวปฏิบัติที่ดีที่สุดและเป็นแกนนำเกี่ยวกับเรื่องนี้ผู้อื่นจะเห็นว่าคุณทำการวิเคราะห์ทางเศรษฐกิจและทำการตัดสินใจตรงกันข้าม นั่นจะทำให้พวกเขาพิจารณาการตัดสินใจของพวกเขาอีกครั้ง พวกเขาจะทำสิ่งนี้เป็นการส่วนตัวและไม่เคยยอมรับในตอนแรก แต่ทุกคนที่เห็นคุณใช้แนวปฏิบัติที่ดีที่สุดนั้นจะตรวจสอบตำแหน่งของพวกเขาอีกครั้ง

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

เพื่อเป็นการพิสูจน์ให้ถามตัวเองเมื่อคุณเห็นคนล่าสุดใช้ goto

มันเป็นผลมาจากการไม่รู้หรือการคิดว่ารู้วิธีอุดมคติ ผู้คนไม่ได้เลือกที่จะเขียนโค้ดไม่ดี มันเป็นกรณีที่ไม่รู้มากขึ้น " ไร้เดียงสา " ซึ่งตรงข้ามกับ " ความไม่รู้ " จะเป็นคำที่ดีกว่า

วิธีที่ง่ายที่สุดในการปฏิบัติตามแนวทางปฏิบัติที่ดีคือการยอมรับว่ามีวิธีที่ดีกว่าในการเขียนโค้ดที่คุณเพิ่งเขียนและต้องการเรียนรู้ว่า 'วิธีที่ดีกว่า' คืออะไร

สาเหตุสองประการ

• ความไม่รู้

• ความหยิ่ง

พวกเขาจะเอาชนะได้อย่างไร?

• แรงจูงใจ

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับฉันคือซอฟต์แวร์ชิ้นหนึ่งที่ทีมงาน 8 คนเขียน เราไม่มีข้อกำหนดที่เป็นลายลักษณ์อักษรบทวิจารณ์โค้ดการทดสอบหน่วยเอกสารการจัดรูปแบบ ไม่มีการทดสอบโดยผู้ใช้ไม่มีหนังสือทุกเล่มที่บอกว่าเราควรทำ รหัสนั้นถูกส่งไปเร่งความเร็วและไม่สามารถรักษาได้ มันถูกทิ้งไป 3 ปีหลังจากที่ปล่อยมันแย่มาก ดังนั้นสิ่งที่ดีเกี่ยวกับมัน สองปีหลังจากการเปิดตัวครั้งแรกเจ้าของ บริษัท (ผู้ให้การสนับสนุนการพัฒนาด้วยการจดจำนองที่บ้านของเขาเอง) เดินออกไปด้วยเงิน $ 30 - $ 40 ล้านในกระเป๋าหลังของเขา

เรามักจะมองข้ามความจริงที่ว่าเราเป็น (มากกว่าบ่อยครั้ง) ที่นี่เพื่อสร้างซอฟต์แวร์ที่สร้างรายได้ให้กับธุรกิจ ธุรกิจไม่มีอยู่เพื่อให้เรามีโอกาสพัฒนาซอฟต์แวร์โดยใช้ "Best Practice" พวกเขามีอยู่เพื่อทำเงิน

"แนวปฏิบัติที่ดีที่สุด" ส่วนใหญ่จะไม่เพิ่มผลกำไร ผู้ที่ทำควรและเป็นที่ยอมรับอย่างกว้างขวาง นั่นเป็นเหตุผลว่าทำไมจึงไม่มีการฝึกฝน "วิธีปฏิบัติที่ดีที่สุด"

ความเสี่ยงที่ยอมรับได้

คุณไม่เคยเสี่ยงและเสี่ยงโชคกับบางสิ่งหรือไม่? มีเวลากระทืบดังนั้นคุณจะได้รับมันเพื่อทำงานด้วยความตั้งใจที่จะ refactoring มันในภายหลัง จริง ๆ แล้วถือว่าเป็นวิธีปฏิบัติที่ดีสำหรับบางคน

ในที่สุดคุณจะได้เผามากพอและเปลี่ยนวิธีการของคุณ คิดถึง 'แนวทางปฏิบัติที่ดีที่สุด' ทั้งหมดที่มี คุณสามารถติดตามพวกเขาทั้งหมดตลอดเวลาได้หรือไม่? มีข้อขัดแย้งกันหรือไม่? คุณไม่ต้องการเสียเวลาจัดการทุกค่าใช้จ่าย

ถ้าฉันเขียนโค้ดไม่ถูกต้องที่ใช้งานได้และไม่มีใครมองมันอีกครั้งมันจะถือว่าแย่หรือเปล่า? (โปรดอย่าทำลายการถกเถียงทางปรัชญาด้วยการพิจารณาว่า 'รหัสไม่ดี' คืออะไร)

IME เป็นการผสมผสานระหว่างสิ่งที่คนอื่นพูด ความไม่รู้ ("ฉันเคยใช้ชุดข้อมูลทำไมต้องรำคาญกับสิ่ง LINQ นี้" ไม่มีเวลา ("หัวหน้าต้องการให้เสร็จเร็วที่สุดเราไม่สามารถใช้เวลากับมันมาก") ขาด ของความเข้าใจ ("มีอะไรผิดปกติกับการเขียนโค้ดของฉันทั้งหมดในโค้ด - หลัง?") ทั้งหมดมีส่วนร่วม

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

บ่อยครั้งที่นักพัฒนาซอฟต์แวร์ไม่ได้แสดงให้เห็นถึงแนวปฏิบัติที่ดีกว่าหรือที่สำคัญกว่านั้นคือข้อดีของการใช้แนวปฏิบัติที่ดีกว่า (ฉันเริ่มหยุดใช้คำว่า

มีทฤษฎีที่นักพัฒนา 'ขี้เกียจจงใจ' กล่าวอีกนัยหนึ่งพวกเขามีแนวโน้มที่จะเลือกเส้นทางที่มีแนวต้านน้อยที่สุด

เมื่อคุณแสดงให้พวกเขาเห็นถึงประโยชน์ของการฝึกฝนที่ดีกว่า (เช่น TDD หรือพูดตามหลักการของ SOLID) และมันช่วยให้พวกเขาเป็นนักพัฒนาที่ดีขึ้น (แต่ยังคง“ ขี้เกียจ”) จากนั้นคุณมักจะพบว่า ไป

มันเป็นเรื่องของการศึกษา :)

(ขาด) ความรู้และทักษะ + เวลาในการลงทุน

ฉันแปลกใจที่ไม่มีใครเอาอันนี้ออกไปได้ แต่บางทีมันอาจจะชัดเจนสำหรับฉันเพราะงานของฉันมากในฐานะโปรแกรมเมอร์เดี่ยวไม่มีใคร (นอกเหนือจากสแต็ค) ที่จะไปเมื่อฉันต่อสู้กับบางสิ่ง ฉันรู้เทคนิคที่ดีกว่าเช่น TDD แต่บ่อยครั้งที่ฉันไม่เข้าใจพวกเขาดีพอที่จะใช้พวกเขาและมีเวลายากในการหาข้อมูลที่ดีเพื่อช่วยฉันเริ่มใช้พวกเขา อีกครั้งการใช้ TDD เป็นตัวอย่างฉันเข้าใจความหมายพื้นฐานของมัน - สร้างการทดสอบที่ยืนยันว่าโค้ดของคุณให้ผลลัพธ์ที่เฉพาะเจาะจง

นอกเหนือจากความจริงที่ว่า XCode มีการทดสอบหน่วยในตัวแล้ววันนี้ฉันไม่มีเงื่อนงำที่จะเริ่ม ฉันยืนยันว่ามุมมองนั้นมีปุ่ม X อยู่หรือไม่หลังจากฉันเรียกใช้รูทีนเพื่อสร้างเป็นประจำ วิธียืนยันว่า UIViews ของฉันถูกจัดเรียงใหม่อย่างเหมาะสมหลังจากที่ฉันเรียกแท็กหมุน?

Heck ฉันจะเขียนการทดสอบหน่วยใน XCode ได้อย่างไร นั่นเป็นอย่างอื่นที่ฉันต้องใช้เวลาในการเรียนรู้

@Zues และ @Joshua Smith

ใช่ฉันเห็นด้วยบางครั้งเวลาและงบประมาณเป็นข้อ จำกัด บางประการที่ไม่อนุญาตให้คุณวางหลักการ "โปรแกรมที่ดีกว่า" ทุกอย่างที่คุณรู้จักในโปรแกรม

คุณรู้ว่างานปัจจุบันสามารถทำได้อย่างแข็งแกร่งยิ่งขึ้นถ้าคุณมีเวลามากขึ้น แต่ลูกค้าน้อยมาก (โดยเฉพาะถ้าพวกเขากำลังทำ iPhone App เครื่องแรกหรือซอฟต์แวร์ระบบธุรกิจอัจฉริยะที่กำหนดเองเป็นครั้งแรก) เข้าใจเมื่อคุณพูดว่าคุณกำลังนำสิ่งที่ทำไปใช้ไปแล้วเพราะคุณพบวิธีที่ดีกว่าในการทำมัน

เหมือนกันสำหรับการทดสอบหน่วย น่าเสียดายที่ฉันยังไม่ได้พบลูกค้าที่พร้อมจะจัดสรรงบประมาณสำหรับสิ่งเหล่านั้น คำตอบทั่วไปเป็นเหมือน“ การทดสอบการถดถอยอัตโนมัติตกลงฉันเข้าใจแล้ว แต่การทดสอบหน่วย? เราไม่มีเวลาสำหรับเรื่องนั้น! เราต้องทำให้มันออกสู่ตลาดอย่างรวดเร็ว!”

สองส่วนในประสบการณ์ส่วนใหญ่ของฉัน:

• เวลา
• รับคนมากพอที่จะเห็นด้วยกับการปฏิบัติที่ดีที่สุดสำหรับสถานการณ์ปัจจุบัน

"แนวปฏิบัติที่ดีที่สุด" เป็นอัตวิสัยในสถานการณ์จริงมากมาย หากครึ่งหนึ่งของทีมพยายามทำ SOLID & TDD ในขณะที่อีกครึ่งหนึ่งทำงาน 60 ชั่วโมงเพื่อโกนหนวดระยะเวลาวินาทีที่นี่และผ่านวิธีการใด ๆ ที่จำเป็นเพราะคุณผ่านจุดที่สายเกินไป ออกแบบบางสิ่งที่ไม่ทำงานภายในเวลาที่กำหนดสำหรับการเปิดตัวครั้งต่อไปคุณจะไม่ไปไกล

แม้ว่าคุณจะไม่ได้เห็นความขัดแย้งกันมากเกินไปในทีมมันเป็นความพยายามอย่างมากที่จะได้รับข้อตกลงอย่างเป็นทางการเอกสารและการฝึกอบรมเกี่ยวกับนโยบายใดก็ตามที่คุณตัดสินใจว่าคุณจะทำตาม นั่นคือบล็อกขนาดใหญ่ของเวลาที่ไม่มีประสิทธิผลจากมุมมองทางธุรกิจที่คุณจะต้องแสดงให้เห็นอย่างรอบคอบ

บางครั้งคุณจะพบว่านิสัยก็เป็นผู้มีส่วนร่วมสำคัญในการเขียนรหัสที่น่ากลัว

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

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

แค่อาหารบางอย่างสำหรับความคิดสำหรับพวกเราที่พบว่ามันง่ายกว่าที่จะกระโดดไปสู่ข้อสรุปเชิงลบ ... แม้ว่าเศร้าคุณจะถูกต้องบ่อยกว่าไม่

ไม่มีใครแสดงความสนใจที่จะจ่ายสำหรับโครงการที่มีชื่อเรื่องพร้อมกับการปรับโครงสร้างใหม่ ต้องมีบางคำที่ดึงดูดความสนใจ 'ธุรกิจ' คำต่าง ๆ เช่น revamping, reinvigorating, remake ทั้งหมด, อัพเกรดวงจรชีวิต ฯลฯ ทำงานที่สถานที่ทำงานของฉัน เกือบทั้งหมดมีการปรับโครงสร้างใหม่เป็นส่วนหลักของโครงการ

น่าเศร้าที่ต้องขอบคุณนักฆ่าเศรษฐกิจการทำงานเกิดขึ้นเฉพาะเมื่อมีการจ่ายเงิน แม้ว่าการทำงานจะเป็นเพียงการบันทึกความมั่งคั่งทางธุรกิจในระยะยาว