การทำให้งานเทคนิคเป็นสินค้าโภคภัณฑ์ที่ล้มเหลว

 (ludic.mataroa.blog)
2 คะแนน โดย GN⁺ 2023-11-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้บริหารและผู้ขายโซลูชันคาดหวังอย่างมากว่าจะทำให้งานเทคนิคเป็นมาตรฐานเหมือนโรงงาน เพื่อสร้าง ผลลัพธ์ที่ทำซ้ำได้ แต่ในหลายหน้างานยังไม่สามารถทำให้งานลักษณะนี้กลายเป็นสินค้าโภคภัณฑ์ได้อย่างเสถียร
  • การดำเนินงานแบบ McDonald's ไม่ได้เน้นคุณภาพของผลลัพธ์เองเท่ากับวินัยที่ทำให้สถานที่และคนทำงานที่แตกต่างกันสามารถสร้าง ผลลัพธ์เดียวกัน ได้ และหนังสือบริหารหลายเล่มก็มองการดำเนินงาน IT เป็นเหมือนกระแสการผลิตแบบนี้
  • การขายซอฟต์แวร์องค์กรแทบจะเป็นคำมั่นว่าจะทดแทนงาน SQL, ข้อมูล และงานพัฒนาด้วย drag-and-drop กับอินเทอร์เฟซที่สม่ำเสมอ เพื่อทำให้แรงงานสามารถสับเปลี่ยนแทนกันได้
  • ในองค์กรจริง ไลเซนส์ซอฟต์แวร์ที่แย่และ abstraction ที่ผิดพลาดไม่สามารถแก้ปัญหาเทคนิคได้ และสุดท้ายมักต้องให้ วิศวกรที่ยอดเยี่ยม ลงมือแก้ data model ที่แย่และการตัดสินใจทางเทคนิคโดยตรง
  • งานที่ต้องใช้ความคิดสร้างสรรค์ รสนิยม ความเชี่ยวชาญ และความสัมพันธ์ระหว่างผู้คน ไม่สามารถถูกลดทอนให้เหลือแค่บอร์ด Jira หรือคะแนน Agile ได้ทั้งหมด และแม้อยู่ในโครงสร้างพื้นฐานการผลิตขนาดใหญ่ คนแต่ละคน ก็ยังเป็นผู้ขับเคลื่อนระบบ

ความยากของการทำมาตรฐานที่ McDonald's แสดงให้เห็น

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

หนังสือบริหารมอง IT เหมือนโรงงาน

  • The Phoenix Project วางการดำเนินงาน IT ไว้เป็นปัญหาคล้ายงานในโรงงานผลิต และให้ความสำคัญกับการจัดการกระแสงานและการสื่อสารภายในองค์กร
  • หนังสือที่มีแนวคิดคล้ายกันตามมา ได้แก่ The Unicorn Project, Investments Unlimited, The Goal
    • The Goal เป็นเรื่องราวเกี่ยวกับการเปลี่ยนแปลงการดำเนินงานของโรงงานจริง และถูกกล่าวถึงในฐานะผลงานที่เป็นแรงบันดาลใจให้หนังสือเล่มอื่น ๆ
  • High Output Management ก็ยกตัวอย่างวิธีที่งานไหลในร้านอาหาร โดยอธิบาย กระแสงาน ในทำนองว่า หากต้มไข่ผิดจังหวะ ขนมปังปิ้งก็จะเย็นเมื่อถึงมือลูกค้า
  • แนวคิดสายนี้มีหัวข้ออย่าง economy of scale, throughput และกระแสงานปรากฏซ้ำ ๆ

แก่นของ pitch จากผู้ขายคือความสามารถในการทดแทน ไม่ใช่เทคโนโลยี

  • pitch ผลิตภัณฑ์หลายรายการในงานประชุมของผู้ขายรายหนึ่งมุ่งเน้นคำมั่นว่าจะส่งมอบ ผลลัพธ์งานที่ดีพอ ได้อย่างทำซ้ำได้ มากกว่ารายละเอียดทางเทคนิค
  • ผลิตภัณฑ์หนึ่งโฆษณาว่าสามารถตั้งค่า dependency ด้วยตัวแก้ไขแบบ drag-and-drop โดยไม่ต้องเขียน SQL โดยตรง
    • ในความเป็นจริง แอปพลิเคชันเชื่อมต่อกับ Postgres ดังนั้น SQL ไม่ได้หายไป แต่เป็นโครงสร้างที่มีชั้น abstraction ติดไลเซนส์มาช่วยเขียน SQL แทน
  • pitch แบบนี้อาจฟังดูเหมือนข้อความถึงผู้บริหารว่า สามารถแทนที่ “SQL ที่ช้าและมีปัญหามาก” ด้วยอินเทอร์เฟซที่สม่ำเสมอและผู้เชี่ยวชาญเครื่องมือในตลาด เพื่อทำให้การส่งมอบข้อมูลภายในองค์กรลื่นไหลขึ้น
  • วิธีที่ Agile ถูกนำไปใช้ในองค์กรที่มีความบกพร่องระดับเฉลี่ยก็เผยให้เห็นปัญหาคล้ายกัน
    • เป็นวิธีนับวิศวกรเหมือนเครื่องจักร นับผลลัพธ์เหมือนชิ้นส่วน นับ story point เหมือนหน่วยการผลิต แล้วตรวจสอบอัตราการบรรลุเป้าหมายของสัปดาห์ถัดไป

เหตุผลที่งานเทคนิคจำนวนมากยังไม่กลายเป็นสินค้าโภคภัณฑ์

  • โดยทั่วไป McDonald's เสิร์ฟเฟรนช์ฟรายส์คุณภาพคงที่ได้ภายใน 5 นาที แต่หลายองค์กรเทคนิคกลับซื้อไลเซนส์ซอฟต์แวร์ที่แย่โดยยังไม่สามารถ deploy สิ่งที่มีคุณค่าได้
  • วิธีแก้ปัญหาเทคนิคและ data model ที่แย่ด้วยเงิน ใกล้เคียงกับการหาตัว วิศวกรที่ยอดเยี่ยม ซึ่งมุ่งแก้ปัญหาอย่างเดียว
  • มีหลายด้านที่ดูเหมือนทำให้เป็นสินค้าโภคภัณฑ์ได้ แต่ในความเป็นจริงมักเป็นการผสมกันระหว่างบริษัทที่ขายผลิตภัณฑ์ซึ่งใช้งานไม่ได้ กับผู้ตัดสินใจที่ไม่รู้เรื่องซึ่งซื้อผลิตภัณฑ์นั้น
  • ผู้ตัดสินใจบางรายอาจเลือกใช้บริการซัพพอร์ตทางโทรศัพท์จากพื้นที่ค่าแรงต่ำในนามของการทำตามข้อกำหนดทางกฎหมาย และเลือกวิธีที่ไม่ใส่ใจลูกค้าที่ต้องการยกเลิก
    • ยังมีการเล่าประสบการณ์ว่า เมื่อต้องติดต่อเจ้าหน้าที่ซัพพอร์ต จะลองโทรหาสายขายก่อน เพื่อดูว่าจะถูกโอนไปยังเจ้าหน้าที่ท้องถิ่นที่มีอำนาจได้อย่างรวดเร็วหรือไม่

งานเทคนิคเชิงสร้างสรรค์ยังมีองค์ประกอบของมนุษย์อยู่

  • Hammock Driven Development ของ Rich Hickey กล่าวถึงกระแสงานแบบนำงานวิจัยเข้าสู่จิตใต้สำนึก ทำสมาธิ นอนหลับ แล้วได้คำตอบด้านการออกแบบ
  • โปรแกรมเมอร์มักประสบกับปรากฏการณ์ที่คำตอบผุดขึ้นมาตอนอยู่ห่างจากปัญหา ซึ่งต่างจากงานที่แค่ผลิตวิดเจ็ตให้เร็วขึ้น
  • ในสังคมมีงานประเภทที่เน้นผลิตให้เร็วขึ้นอยู่มาก แต่ผลลัพธ์ที่มีคุณค่าจำนวนมากเกิดขึ้นตรงจุดที่ ความคิดสร้างสรรค์ซึ่งนิยามได้ยาก มาบรรจบกับความเป็นจริงของการผลิต
  • แม้ในกรณีอย่างหนังสือ อาหาร และการดำเนินงานร้านอาหาร จะสามารถปรับระบบการผลิตจำนวนมากหรือระบบส่งมอบให้ประณีตขึ้นได้ แต่ผลลัพธ์ที่งดงามต้องอาศัยรสนิยมและความเอาใจใส่
  • แม้พยายามลดการพัฒนาฟีเจอร์ให้เหลือเพียงบอร์ด Jira และเรื่องราวแบบ Agile หากไม่เชื่อมโยงกับผู้คน ก็ยากที่จะได้ผลลัพธ์ที่มีคุณค่า
  • เช่นเดียวกับกรณีของคนรู้จักที่ออกแบบชิปใน iPhone แม้จะมีโครงสร้างพื้นฐานสำหรับการทดสอบและการผลิตจำนวนมาก แต่ถ้าบุคคลใดบุคคลหนึ่งป่วย รีลีสถัดไปก็อาจล่าช้าได้ สะท้อนว่า คนแต่ละคน มีบทบาทสำคัญอย่างมาก
  • แม้ความจริงคือสังคมขับเคลื่อนอยู่บนการทำให้สิ่งต่าง ๆ เป็นสินค้าโภคภัณฑ์ แต่ไม่สามารถดำเนินงานเทคนิคด้วย การทำให้เป็นสินค้าโภคภัณฑ์ล้วน ๆ ที่ละเลยความเข้าใจในงานฝีมือเฉพาะทาง รวมถึงความซับซ้อน ความต้องการ และความเปราะบางของมนุษย์ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-26
ความคิดเห็นจาก Hacker News

  • ดูเหมือนผู้เขียนจะมองข้ามไปว่า งานจำนวนมากที่เมื่อก่อนเรียกว่าเป็นงานเทคนิค ตอนนี้ได้กลายเป็น สินค้าโภคภัณฑ์ทั่วไป ไปแล้ว
    เมื่อก่อน mail merge คือการพิมพ์ป้ายที่อยู่จำนวนมากออกมาจริง ๆ แล้วเอาไปแปะจดหมายกับซองด้วยมือ, Word 2.0 ราว ๆ ช่วงทศวรรษ 1990 แก้ปัญหานั้นได้ และ MailChimp ก็ทำให้มันเป็นสินค้าในศตวรรษที่ 21
    การทำบัญชีคู่ก็เคยเป็นงานทักษะเฉพาะที่ต้องใช้คนฝึกมาดี แต่ตอนนี้เจ้าของร้านแค่สแกนบาร์โค้ดแล้วลูกค้าก็แตะจ่ายได้
    ยังไม่มีอินเทอร์เฟซแบบ drag-and-drop ที่ใช้กับสิ่งซับซ้อนกว่า Scratch ได้ แต่ส่วนที่ยากไม่ใช่งานเทคนิคในการเอาไลบรารีมาต่อกัน ทว่าเป็นการ เก็บความต้องการ
    การใส่ไลบรารีเข้ารหัสคุณภาพสูง, เอาแผนที่แบบโต้ตอบมาไว้บนเว็บไซต์, หรือแก้ไขเว็บไซต์แบบ WYSIWYG นั้นง่ายกว่าที่เคยมาก
    ผู้เขียนพูดถูกตรงที่คุณคงจับเด็กอายุ 18 ที่กำลังเบื่อมานั่งหน้า IDE แล้วให้สร้าง ERP ไม่ได้ แต่จิปาถะงานจำนวนมากในสาย IT ตอนนี้กลายเป็นสินค้าไปชัดเจนแล้ว

    • ก็จริง แต่ ปริมาณงานจิปาถะ ไม่ได้คงที่ในแต่ละปี
      ผมมองว่างานจิปาถะในอุตสาหกรรมเทคกำลังเพิ่มขึ้น ไม่ใช่ลดลง: ตอนนี้มีงานจิปาถะอยู่ X, แล้วเทคโนโลยีใหม่ Z ก็ออกมาทำให้ X ลดเหลือ 0.1X แต่ในเวลาเดียวกัน Z ก็เปิดทางให้เกิดวิธีทำงานใหม่ ๆ และสร้างงานจิปาถะรูปแบบใหม่เป็นผลพลอยได้ สุดท้ายงานจิปาถะตอนนี้กลายเป็น Y และ Y ก็ยังใกล้เคียงกับ X อยู่ดี
      ถ้าความก้าวหน้าทางเทคโนโลยีหยุดไปตั้งแต่ยุค 2000 งานจิปาถะที่สืบมาจากยุค 90 ก็คงแทบเป็นศูนย์ในวันนี้ แต่เทคโนโลยีใหม่พาทั้งระบบอัตโนมัติและงานจิปาถะใหม่มาพร้อมกัน
      ตัวอย่างล่าสุดคือ เครื่องมือ AI เรามีเครื่องมือสร้างเสียง ภาพ วิดีโอ และข้อความก็จริง แต่ถ้าจะสร้างผลิตภัณฑ์หรือประสบการณ์ที่แตกต่าง ก็ยังต้องมีงานจิปาถะในการประกอบเครื่องมืออย่าง ChatGPT, Stable Diffusion และตัวอื่น ๆ เข้าด้วยกัน
    • หลังผ่านไป 30~40 ปี พื้นที่ที่ ทำให้เป็นสินค้าได้ง่าย อาจแทบไม่เหลือแล้ว
      ยิ่งทำให้เป็นสินค้าได้มากขึ้น ปัญหาก็ยิ่งขยับขึ้นไปอยู่ในระดับที่สูงขึ้น และวิศวกรผู้เชี่ยวชาญที่จ้างมาก็ขยับไปอยู่ชั้นบนของสแตกมากขึ้นเช่นกัน
      ในบรรดาผลิตภัณฑ์สตาร์ตอัปที่เพิ่งถูกทำเป็น SaaS ช่วงหลัง ๆ ดูเหมือนจะมีสัดส่วนสูงทีเดียวที่ยังทำสิ่งที่ลูกค้าต้องการจริง ๆ ไม่ได้ วิธีคือเก็บเงินให้ลูกค้ามาใช้บริการก่อน แล้วค่อยรวบรวม use case ของลูกค้าไว้เป็นงานที่ต้องทำ และหวังจะทำให้มันเป็นสินค้าสำหรับลูกค้ารายอื่นต่อไป ซึ่งทำให้ lead time ยาวขึ้นและทรัพย์สินทางปัญญาก็รั่วไหลออกไป
      การทำ SQL ให้เป็นเทมเพลตเป็นสิ่งที่ผู้บริหารเข้าใจผิดกันอยู่เสมอ SQL อยู่รอดมาในวงการได้นานอย่างน่าทึ่งและจริง ๆ ก็ทำงานได้ดีมาก ส่วน wrapper หรือ DSL ที่เอาไปครอบทับนั้น 99% ทำให้ทุกอย่างแย่ลงกว่าเดิม และงานที่ไม่ธรรมดาเพียงนิดเดียว สุดท้ายก็ต้องลงไปจบที่ SQL อยู่ดี แทนที่จะจ้างผู้เชี่ยวชาญ SQL ก็กลายเป็นว่าต้องไปปั้นผู้เชี่ยวชาญด้าน SaaS-style DSL SQL wrapper X ที่ไม่มีอยู่จริง
    • คิดว่าเป็นคำวิจารณ์ที่มีน้ำหนักและควรเอาไปคิดต่อให้มาก
      ปัญหาพื้นฐานอาจอยู่ที่ผลิตภัณฑ์พวกนี้ถูกออกแบบมาให้ดูเหมือนเป็น เครื่องใช้ไฟฟ้า แบบ “ซื้อมาเสียบแล้วปัญหาหมด” สำหรับคนซื้อที่ไม่ได้ทำงานอยู่ในโดเมนนั้น
      ผลิตภัณฑ์จำนวนมากจริง ๆ แล้วแก้ปัญหาไม่ได้ แค่ทำให้ดูเหมือนแก้ได้เพราะคนอื่นก็ซื้อกัน แล้วคนก็ต้องโกหกว่าการติดตั้งใช้งานประสบความสำเร็จเพื่อจะได้เลื่อนตำแหน่ง เรื่องอย่าง mail merge นั้นเป็นปัญหาที่ถูกแก้ไปแล้วจริง ๆ แบบเดียวกับกาต้มน้ำ และปัญหาแบบนั้นแค่ลองทำเองก็แก้ได้
      ปัญหาใหญ่กว่าคือนายจ้างของผมเชื่อว่า Workday เป็นเหมือนกาต้มน้ำเลยซื้อมา แต่โครงสร้างองค์กรของเรามันแย่เกินกว่าจะเอาไปทำเป็นโมเดลได้อยู่แล้ว ซึ่งไม่มีทางแก้ได้
      ปีนี้เป็นครั้งแรกที่ผมตระหนักว่า โครงสร้างองค์กร ที่แย่พอในบริษัทใหญ่ ๆ ก็เป็นหนี้ทางเทคนิคชนิดหนึ่งได้เหมือนกัน คุณต้องทำเรื่องประหลาดสารพัดเพื่อจะรู้ว่าใครอยู่ใต้ใครบ้าง หรือผู้ใช้คนนี้ควรเห็นอะไรในฐานข้อมูลนี้ได้บ้าง
    • บางด้านก็กลายเป็นสินค้าไปจริง แต่ถ้ามองภาพใหญ่ล่ะ?
      เมื่อเทียบกับปี 1994 หรือ 2004 ตอนนี้การทำธุรกิจ สร้างเว็บไซต์ วางแผนการเดินทาง และจ่ายบิล มันง่ายขึ้นแค่ไหนกันแน่?
      บางครั้งก็รู้สึกว่าคนรุ่นก่อนใช้ชีวิตช้ากว่า และเพราะอย่างนั้นจึงมีชีวิตที่เต็มอิ่มกว่า ตอนนี้เวลาผ่านไปเร็วเกินและความเครียดก็สูงมาก
      ไม่นานมานี้ผมเห็นคนอายุเกิน 60 อย่างน้อยสามคนที่ธนาคาร จัดการเรื่องง่าย ๆ ไม่ได้จนต้องขอให้พนักงานช่วย มันควรเป็นเรื่องที่ทำได้ง่ายผ่าน online banking แต่เพราะเป็นกรณียกเว้น ระบบเลยไม่รองรับ สุดท้ายต้องนัดหมาย และคิวที่เร็วที่สุดก็อีก 3~4 เดือน
      หนึ่งในนั้นต้องถอนเงินจากบัญชีที่ถูกบล็อกเพื่อไปซื้อฟืนมาทำบ้านให้อุ่น แต่พนักงานธนาคารทำได้แค่บอกให้รออีก 3 เดือน
      เมื่อ 2 ปีก่อน พ่อของผมหาวิธีโทรศัพท์กลับบ้านจากซิซิลีแบบง่าย ๆ ไม่ได้เลย ถ้าเป็นยุค 1970 เขาคงแค่เดินเข้าบาร์ใกล้ ๆ แล้วหยอดเหรียญไม่กี่เหรียญก็จบ
      เมื่อก่อนคนทั่วไปมักซ่อมหลอดไฟ รถยนต์ เครื่องทำความร้อน หรือประตูธรรมดาที่ไม่ใช่ประตูอัตโนมัติได้เอง แต่ตอนนี้ต้องเรียกช่างผู้เชี่ยวชาญ
    • สงสัยว่ามีคำศัพท์แบบ กฎของ Amdahl ที่เอามาใช้กับกระบวนการของคนหรือเปล่า ให้ความรู้สึกเหมือนอยู่ฝั่งตรงข้ามของ “กฎผลตอบแทนลดน้อยลง”

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

    • โดยรวมแล้ว The Phoenix Project แทบจะเป็นการลอก The Goal ของ Goldratt แล้วค่อยทำ s/manufacturing/IT/g พร้อมอัปเดตด้วยการอ้างอิงสมัยใหม่
      ไม่ได้หมายความว่าฉันเกลียดหนังสือนะ ฉันอ่านไปครึ่งหนึ่ง และเคยให้แต่ละทีมอ่านเพื่อเปลี่ยนวิธีคิดให้มองแบบเน้นระบบ เพียงแต่คงยังบอกไม่ได้ว่ามันลึกซึ้งหรือมีวิสัยทัศน์มากกว่า The Goal อย่างชัดเจน
    • ฉันเห็นด้วยทั้งหมด และนี่แหละคือด้านบวกที่หยิบจาก The Phoenix Project ได้
      ถึงจะล้อสำนวนการเขียนอยู่บ้าง แต่มันก็ยังคุ้มค่าแก่การอ่านจริง ๆ ความผิดพลาดมากมายที่ผู้คนทำกับงานที่รู้แน่ชัดหรือขั้นตอนที่ทำซ้ำได้ จะไปโทษความคิดแบบ Phoenix Project ไม่ได้
      เพียงแต่ในการเขียนโปรแกรม งานที่เป็นงานรู้แน่ชัดและทำเป็นขั้นตอนซ้ำ ๆ นั้นเกิดไม่บ่อย ถ้าเกิดขึ้น ก็มักเป็นเพราะพลาดเชิงยุทธวิธีในการจัดการผู้มีส่วนได้ส่วนเสีย จนไม่มีเวลาเหลือสำหรับทำระบบอัตโนมัติ
      ถ้าอ่านอย่างใคร่ครวญก็จะพาไปสู่ข้อสรุปแบบย่อหน้าสุดท้าย แต่ฉันก็รู้แน่ชัดว่าผู้จัดการส่วนใหญ่ที่ฉันเจอไม่เข้าใจความต่างระหว่าง การผลิตวิดเจ็ต กับ การออกแบบระบบ
    • ตอนที่กระแส DevOps ถาโถมเข้าบริษัท The Phoenix Project คือสิ่งที่ฉันใช้เรียนรู้ว่า “ทำไม” เบื้องหลัง “อย่างไร” ของ DevOps Handbook ปกสีส้ม
      การเรียนรู้อย่างต่อเนื่อง, ระบบอัตโนมัติ, และการวัดผล เป็นเครื่องมือที่ทำให้ข้อ 1~5 ข้างต้นเกิดขึ้นได้
      ฉันไม่เคยได้รับสารจาก The Phoenix Project ว่า “จงทำงานให้หนักขึ้นเพื่อทำงานให้มากขึ้นและเร็วขึ้น”
    • ถ้ามองที่ Scrum เอง จริง ๆ ก็ไม่ได้มีอะไรให้น่าตำหนิมากนัก
      https://scrumguides.org/scrum-guide.html
      สิ่งที่มักเลวร้ายคือสารพัดสิ่งที่ผู้คนเรียกว่า Scrum แล้วเอาไปพอกทับเพิ่มต่างหาก วิธีที่ดีที่สุดในการต้าน Scrum แบบเพี้ยน ๆ ไม่ใช่การสู้ตรง ๆ แต่คือทำเหมือนภักดีต่อคำสอนดั้งเดิมแบบเคร่งครัด จะดูไม่เป็นพวกหัวขบถเกินไป และมีอิทธิพลได้ง่ายกว่าด้วย

  • ฉันสับสนกับชื่อเรื่อง “commodify” ไม่ได้แปลว่า “ทำให้ขายได้” หรือก็คือทำให้เป็นเชิงพาณิชย์หรอกหรือ? เทคโนโลยีก็ทำเงินระดับหลายพันล้านดอลลาร์อยู่แล้วไม่ใช่หรือ?
    สิ่งที่ผู้เขียนน่าจะหมายถึงคือ commoditization คือการทำให้งานสายเทคโนโลยีกลายเป็นงานทั่วไปที่พนักงานคนไหนมาแทนก็ทำได้
    ตาม https://en.wikipedia.org/wiki/Commoditization commoditization คือการที่สิ่งซึ่งเคยมีลักษณะเฉพาะกลายเป็นสินค้าทั่วไป ส่วน commodification คือการที่สิ่งซึ่งเดิมขายไม่ได้กลายเป็นสิ่งที่ขายได้
    ฉันกำลังจับผิดเกินไปหรือเปล่า? ฉันคิดว่าสองคำนี้ความหมายต่างกัน
    แก้ไข: ไปดู Wiktionary แล้ว https://en.wiktionary.org/wiki/commodification บอกว่าบางทีก็ใช้แทนกันได้ น่าจะเป็นความสับสนที่พบได้บ่อย

    • เท่าที่ฉันเข้าใจ “commodify” ไม่ได้แปลว่า “ทำให้ขายได้”
      https://www.merriam-webster.com/dictionary/commodify
      ความหมายคือ “เปลี่ยนสิ่งอย่างคุณค่าในตัวเองหรือผลงานศิลปะให้กลายเป็นสินค้า” ดังนั้น commodify จึงใกล้กับสิ่งที่ commoditization พูดถึงมากกว่า
    • สำหรับฉัน คำนี้มีความหมายอย่างที่ผู้เขียนใช้มาตลอด
      น้ำมันเป็นสินค้าโภคภัณฑ์เพราะมีผู้ผลิตจำนวนมากและทุกเจ้าทำของแบบเดียวกัน ดังนั้นจะซื้อจากที่ไหนก็ไม่ต่างกัน

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

    • ประเด็นนี้ชี้ให้เห็นสมมติฐานพื้นฐานที่เรียก IT ว่าเป็นโรงงานได้อย่างแม่นยำ และยังเผยด้วยว่าทำไมสมมติฐานนั้นถึงผิด
      IT ไม่ใช่โรงงาน แต่คือ งานสร้างโรงงาน
      ผมคิดว่าความขัดแย้งระหว่างนักพัฒนากับผู้จัดการจำนวนมากเกิดจากคำว่า “ผู้จัดการ” ที่ถูกรวมความไว้กว้างเกินไป ผู้จัดการของ McDonald’s ทำหน้าที่กำกับให้พนักงานทำตามกระบวนการที่ใช้ผลิตสินค้าออกมา การที่พนักงานทำตามหรือไม่ทำตามนั้นชัดเจน กระบวนการก็ถูกสมมติไว้แล้วว่าใช้ได้ และการที่ผลงานออกมาหรือไม่ออกมาก็ชัดเจนเช่นกัน
      แต่โปรแกรมเมอร์ถูกจ้างมาเพื่อพัฒนากระบวนการที่เครื่องจักรจะต้องปฏิบัติตาม สำหรับคนที่มาบริหารพนักงานประเภทนี้ ก็อาจมีกระบวนการที่ต้องให้โปรแกรมเมอร์ปฏิบัติตามเช่นกัน และอาจเห็นได้ชัดว่าเขาทำตามหรือไม่ แต่สิ่งที่ไม่แน่นอนคือกระบวนการนั้นใช้ได้จริงหรือไม่ พฤติกรรมบางอย่างจะนำไปสู่ผลลัพธ์ที่กำหนดไว้หรือไม่ และแม้แต่ตัวผลลัพธ์เองก็อาจไม่ชัดเจน
      ถึงอย่างนั้นทั้งสองบทบาทก็ยังถูกเรียกว่า “ผู้จัดการ” เหมือนกัน
      ในอุปมาเรื่องเครื่องจักรนี้ โปรแกรมเมอร์ไม่ใช่ผู้จัดการคน แต่เป็นผู้จัดการอีกประเภทหนึ่งที่คอยสั่งการเครื่องจักร เพียงแต่เครื่องจักรเหล่านั้นถูกปล่อยออกไปใช้งานในโลก และโปรแกรมเมอร์ก็ไม่ได้เฝ้าดูมันตลอดเวลา
    • คำพูดที่ว่า “การเขียนโปรแกรมไม่ใช่งาน แต่เป็นงานระดับเมตา” นั้น อาจเป็นทั้งข้อสังเกตที่ลึกซึ้งมากหรือไม่ก็เหลวไหลสิ้นดี และคงต้องรอไปอีก 5 ปีข้างหน้าจึงจะรู้ว่าเป็นอย่างไหน
    • ในฐานะผู้เขียน ผมแทบไม่มีอะไรจะเสริม และคิดว่าคำพูดนี้ตรงมาก ผมเองก็ใช้คำว่า งานระดับเมตา มาตลอดเวลาอยากชี้ถึงกรณีที่มันถูกทำอย่างถูกต้อง
      แน่นอนว่าเหมือนที่คอมเมนต์อื่นว่าไว้ แนวคิดนี้อาจเป็นเรื่องเหลวไหลโดยสิ้นเชิงก็ได้ แต่ถึงอีกไม่กี่ปีข้างหน้าจะพบว่านี่เป็นความคิดโง่ ๆ อย่างน้อยการมีใครสักคนที่อาจต้องอายไปด้วยกัน ก็ดีกว่าต้องอายอยู่คนเดียว

  • ราว 10 ปีก่อน เพื่อนไม่กี่คนที่เป็นวิศวกรเครื่องกลรู้ว่าผมกำลังเรียนการพัฒนาซอฟต์แวร์แล้วก็ตกใจ
    พวกเขาพูดประมาณว่า “มันยังมีอะไรให้ทำอีกเยอะเหรอ? สิ่งที่ต้องใช้ไม่ใช่ว่ามีอยู่ในระบบเดิมหมดแล้วหรือ?”
    ความเข้าใจผิดคือคิดว่าการสร้างระบบเพื่อแก้ปัญหาใหม่ ๆ นั้นง่ายและถูก ทำให้เป็นสินค้า ไปหมดแล้ว จนไม่จำเป็นต้องเขียนโค้ดอีก
    แต่ในความเป็นจริง การสร้างซอฟต์แวร์แทบไม่ค่อยง่ายเท่าการตั้งค่า UI เรายังต้องมีข้อความสำหรับแสดงกฎตรรกะและลำดับการไหลของงาน ต้องมี version control เพื่อติดตามและย้อนกลับการเปลี่ยนแปลงของระบบ และสุดท้ายก็ยังต้องมีโปรแกรมเมอร์
    การเขียนโค้ดไม่ได้หายไป มีเพียง ระดับของ abstraction ที่สูงขึ้น

  • อุตสาหกรรมเทคโนโลยีพยายามทำให้นักพัฒนาเป็นสินค้าอยู่มานานแล้ว และผมมองว่า COBOL กับ Java ก็อยู่ในกระแสนั้นเช่นกัน
    แต่ไม่ว่าจะทำ abstraction กับอะไร ก็จะมีคุณสมบัติพื้นฐานบางอย่างที่โผล่กลับมาเสมอ ต่อให้ requirement ดูเรียบง่ายและมีเฟรมเวิร์กระดับสูงให้ใช้ ซอฟต์แวร์จำนวนมากของเราก็ยังทำงานได้ไม่ถูกต้องอยู่ดี
    อย่างที่ผู้เขียนบอก ทางออกจริง ๆ คือมีนักพัฒนาที่มีฝีมือและใส่ใจ และคุณก็สร้างอาชีพจากสิ่งนั้นได้

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

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

  • เมื่อดูบทบาท Business Intelligence/นักวิเคราะห์ อุตสาหกรรมกำลังพยายามแทนที่คนที่ใช้ SQL ด้วยคนที่ใช้เครื่องมืออย่าง Tableau
    แนวคิดคือ “แค่เชื่อมต่อกับแหล่งเก็บข้อมูลอะไรก็ได้ แล้วคนที่ไม่ใช่สายเทคนิคก็ลากวางทำได้”
    ปัญหามีอยู่หลายข้อ ข้อแรกคือพวกเขาลืมไปว่าผลผลิตเพิ่มขึ้นได้แค่แบบเชิงเส้น จึงต้องจ้างแรงงานค่าแรงต่ำเพิ่ม งานทั้งหมดอยู่บน UI เลยต้องให้คนมาหมุนคันโยกด้วยมือ
    ข้อสองคือโค้ดแปลง business logic ที่ซับซ้อนมากและไม่เป็นระเบียบก็ยังคงเกิดขึ้นอยู่ เพียงแต่ตอนนี้มันถูกซ่อนไว้ใน UI และคนที่รู้ว่า logic นั้นคืออะไรกลับมีแค่ PM หรือทีมธุรกิจ
    องค์กรวิศวกรรมจัดเตรียมชุดข้อมูลคุณภาพสูงที่ผ่านการทดสอบแล้วในระดับค่อนข้างพื้นฐาน เพื่อตอบคำถามทางธุรกิจ ส่วนที่ยากจริง ๆ คือการแก้ปัญหาว่าจะดึงผลลัพธ์ทางธุรกิจออกมาจากข้อมูลต้นทางด้วยวิธีประหลาด ๆ อย่างไร
    ตอนนี้วิธีแก้เหล่านั้นถูกเก็บไว้ใน Tableau workbook และไม่สามารถใช้เป็นอินพุตอื่นได้ ต้องคัดลอกวางผ่าน UI ไปยัง Tableau workbook ใหม่
    เมื่อซื้อบริการคลาวด์ของ Tableau แล้ว ทีม BI ก็อาจทำให้ SQL extract เข้มงวดและดูแลรักษาได้มากขึ้น Tableau ดูเหมือนกำลังพยายามแย่งส่วนหนึ่งของธุรกิจ Databricks แต่ตอนนี้งานนั้นกำลังถูกทำโดยทีมที่ไม่ใช่วิศวกรรม ไม่แน่ใจว่าจะไปรอดไหม

    • ขอคัดค้านอย่างสุภาพ ความยากไม่ได้มีแค่การดึงคำตอบที่มีความหมายจากข้อมูลดิบ แต่สิ่งที่ยากที่สุดคือการทำให้คนธุรกิจตั้ง คำถามที่ถูกต้อง
      ตัวอย่างเช่นมีคำถามคลาสสิกว่า “ผู้ใช้ของเรามาจากประเทศไหน?” หมายถึงประเทศที่กรอกในฟอร์มสมัคร ประเทศที่กำลังเชื่อมต่อเข้ามาใช้บริการตอนนี้ ประเทศของวิธีชำระเงิน ประเทศเกิด ประเทศสัญชาติ ประเทศที่พำนักปัจจุบัน ที่อยู่จัดส่ง หรือที่อยู่เรียกเก็บเงิน กันแน่
      ถ้าชุดข้อมูลใหญ่พอ แต่ละแบบจะให้คำตอบต่างกัน ในโลก “global fintech” กรณีประหลาดแบบนี้จะกลายเป็นเรื่องปกติ
      ผู้ใช้ Tableau ค่าแรงต่ำทั่วไปมักจะหาฟิลด์รหัสประเทศที่เห็น แล้วสั่ง count ก่อนประกาศว่านั่นคือความจริง
      ผู้ใช้ Tableau ที่ฉลาดขึ้นมาหน่อยจะไปขอให้วิศวกรเขียน SQL ให้
      ต้องมีคนที่รู้ทั้งชุดข้อมูลและระบบต้นทาง จึงจะย้อนถามธุรกิจและบังคับให้เกิดคำถามกับบริบทที่ถูกต้องได้
      เครื่องมือแนว Tableau เหมาะกับการแทน “งานเทคนิค” แบบเอา SQL เดิมไปวางใน pgAdmin ทุกวันแล้วส่ง CSV ทางอีเมล แต่ไม่ได้ทำให้แรงงานทักษะต่ำที่ยึด UI เป็นศูนย์กลางคิดได้ดีขึ้น
    • สำหรับ “ผู้นำ” ทางธุรกิจ ข้อ 1 ไม่ใช่บั๊ก แต่เป็นฟีเจอร์
      การ ขยายผลผลิตแบบเชิงเส้น ตามต้นทุนสามารถทำแบบจำลองในสเปรดชีตได้ และสามารถผลักภาระหรือคิดค่าบริการกับลูกค้าได้ ทุกคนในชั้นธุรกิจรู้สึกสบายใจกับพลวัตแบบนี้
      ตรงกันข้าม หากมีผู้เชี่ยวชาญเฉพาะทางที่อาจสร้างผลผลิตได้มากกว่า 1000 เท่าด้วยแรงเพียงเล็กน้อย แต่ไม่มีใครมั่นใจได้ว่าจะใช้เวลาหนึ่งวันหรือหนึ่งสัปดาห์ สถานการณ์แบบนั้นทำให้ทุกคนไม่แน่นอนและทำให้ผู้นำกังวล ถ้าทุกคนต้องการความธรรมดาที่คุ้นเคย มันก็ขายยาก
      ส่วนข้อ 2 กลับกลายเป็นว่าต้องการผู้เชี่ยวชาญมากขึ้น เพียงแต่เป็นผู้เชี่ยวชาญคนละแบบ เพราะต้องคอยดูแล logic ทั้งหมดนั้น
      ท้ายที่สุดมันจะทำงานเหมือนโครงการสร้างงานและมีค่าใช้จ่ายแพงขึ้น แต่จะกระจายมูลค่าตามอาณาเขตที่มีอิทธิพลทางการเมือง จึงน่าจะถือว่าประสบความสำเร็จ
    • ฟังดูเหมือน ตัวทำลายธุรกิจ ชั้นดี
      ขั้นแรกก็ไล่คนฝั่งแบ็กเอนด์ออกหมดโดยอ้างว่าพวกเขาไม่เข้าใจธุรกิจ แล้วใช้ Tableau เป็นแบ็กเอนด์ตัวใหม่ โดยมองข้ามความจริงที่ว่าคนแบ็กเอนด์คอยซึมซับและขัดเกลาความต้องการทางธุรกิจมาตลอด
      จากนั้นเมื่อคนธุรกิจติดอยู่ในใยแมงมุมเละเทะที่ตัวเองสร้างขึ้น ก็เรียกที่ปรึกษา Tableau มา และพวกนั้นก็สูบเงินไปเรื่อย ๆ โดยไม่ได้สร้างสิ่งที่มีคุณค่าอะไรเลย

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

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