The Software Factory: เมื่อแคลคูลัสและสมการ s=vt ตัดสินความอยู่รอดของโปรเจกต์ซอฟต์แวร์
ในโลกของการบริหารโปรเจกต์ซอฟต์แวร์ เรามักจะหลงรักแผนงานที่สวยงามบนหน้าจอ เราตื่นตาตื่นใจกับ Gantt Chart ที่ลากเส้นต่อกันอย่างเป็นระเบียบ และเรามักจะทึกทักเอาเองว่า ถ้าเรามีจุดเริ่มต้นที่ดี มีทีมงานที่มีความเร็ว (Velocity) และมีระยะเวลาที่กำหนดไว้ ทุกอย่างจะเดินไปถึงเป้าหมายได้อย่างแม่นยำตามสมการฟิสิกส์มัธยมปลายอย่าง s=vt (ระยะทางเท่ากับความเร็วคูณเวลา)
แต่ทำไมโปรเจกต์ซอฟต์แวร์ส่วนใหญ่บนโลกใบนี้ ถึงไปไม่เคยถึงจุดหมายที่คาดหวัง หรือต่อให้สร้างเสร็จตรงตามกำหนดเวลา มันกลับกลายเป็นสิ่งที่ไม่มีใครต้องการอีกต่อไป?
คำตอบของเรื่องนี้ไม่ได้ซ่อนอยู่ในความเก่งกาจของ Engineer และไม่ได้อยู่ที่ว่าทีมเขียนโค้ดได้ตรงตามเอกสารบรีฟหรือไม่ แต่มันซ่อนอยู่ในกฎเหล็กของคณิตศาสตร์เบื้องหลังสมการการเคลื่อนที่ และสิ่งที่เรียกว่า “ช่องว่างของเวลา” (Δt)
โศกนาฏกรรมของ Δt ที่กว้างเกินไป
หากเราลองถอดรหัสสมการฟิสิกส์ในอุดมคติให้ออกมาในรูปของการเปลี่ยนแปลงสถานะ (State Transition) ของกระบวนการผลิตซอฟต์แวร์ (SDLC) เราจะสามารถวางตัวแปรได้ดังนี้:
- sเก่า (สถานะเดิม) = ไอเดีย ความต้องการ หรือ Requirement วันแรกที่คุยกับลูกค้า
- v (Velocity) = ความเร็วในการผลิตของทีมพัฒนา (เขียนโค้ด, ดีไซน์, รีวิว)
- Δt = ระยะเวลาที่ทีมพัฒนาหายตัวไปทำงาน โดยไม่ได้นำผลลัพธ์กลับมาเช็คกับผู้ใช้จริง
ในยุคของการทำงานแบบดั้งเดิมหรือ Waterfall เรามักจะปล่อยให้ตัวแปร Δt นี้มีค่ากว้างมาก กว้างเป็นเดือน หรือบางทีเป็นปี เราคุยบรีฟกันอย่างดิบดีในเดือนมกราคม ทีมพัฒนาเซ็นรับทราบและปิดประตูห้องแล็บหายไป 6 เดือนเพื่อสร้างสถานะใหม่ (sใหม่) ออกมา โดยมีสมมติฐานในใจว่า “ถ้าฉันสร้างได้ตรงตามเอกสาร 200 หน้าในวันแรก เมื่อถึงเวลาส่งมอบ ลูกค้าต้องพอใจแน่นอน”
แต่ความจริงในโลกอันโหดร้ายกลับไม่เป็นเช่นนั้น เพราะในระหว่างเวลา 6 เดือนที่ผ่านไป ตลาดเปลี่ยน พฤติกรรมผู้ใช้เปลี่ยน คู่แข่งขยับ หรือแม้กระทั่งตัวลูกค้าเองเพิ่งมาตระหนักรู้เมื่อเห็นหน้าจอจริงว่าสิ่งที่พวกเขาเขียนลงในเอกสารวันแรกไม่ใช่สิ่งที่พวกเขาต้องการจริงๆ
เมื่อ Δt กว้างเกินไป ความเร่งและแรงเหวี่ยงของโลกความจริงจะดีดให้ “สถานะที่สร้างเสร็จจริง” (sใหม่) กับ “สถานะที่ตลาดคาดหวัง ณ ปัจจุบัน” (sที่คาดหวัง) วิ่งแยกออกจากกันไปคนละทิศละทาง จนกลายเป็นเส้นขนานที่กู้กลับคืนมาไม่ได้อีกต่อไป
บีบ Δt→0 ด้วยสถาปัตยกรรมกระบวนการทำงาน
เพื่อไม่ให้เกิดโศกนาฏกรรมข้างต้น วงการวิศวกรรมซอฟต์แวร์สมัยใหม่จึงจำเป็นต้องเปลี่ยนวิธีคิดเชิงสถาปัตยกรรมกระบวนการ (Process Architecture) โดยนำแนวคิดของแคลคูลัสเข้ามาประยุกต์ใช้ หากเราต้องการรู้ตำแหน่งที่แม่นยำที่สุดในโลกที่ทุกอย่างเปลี่ยนแปลงตลอดเวลา เราจะปล่อยให้เวลาห่างเป็นเดือนไม่ได้ แต่เราต้องบีบช่วงเวลาตรวจสอบให้สั้นที่สุดจนลู่เข้าสู่ศูนย์ (Δt→0) เพื่อเปลี่ยนจากความเร็วเฉลี่ย ให้กลายเป็น “ความเร็ว ณ ขณะนั้น” (Instantaneous Velocity)
ในกระบวนการทำงานจริง เราบีบเวลานี้ผ่านกลไก 3 ระดับ:
1. ระหว่างทีมพัฒนากับลูกค้า: Agile & Continuous Discovery
กรอบการทำงานแบบ Agile หรือ Scrum คือการบีบ Δt จากหลักเดือนให้เหลือเพียง Sprint ละ 1–2 สัปดาห์ ทุกสิ้นสัปดาห์ทีมต้องนำซอฟต์แวร์ที่ทำงานได้จริง (Working Software) ไปให้ลูกค้าดูทันที มันคือ Feedback Loop ที่เหมือนกับการลืมตาขับรถในทางโค้ง ยิ่งเราลืมตาขึ้นมาดูทางถี่เท่าไหร่ แม้จะขับเบี้ยวไปบ้างเราก็ยังหักพวงมาลัยจูนทิศทางกลับมาได้ทันเวลาก่อนจะชนกำแพง
2. ระหว่างซอฟต์แวร์ในเครื่องคอมพิวเตอร์สู่ระบบจริง: CI/CD
ในระดับวิศวกรรม ปัญหาเรื่อง Δt ห่างก็สร้างความพินาศได้เช่นกัน ยุคก่อนที่ Developer แยกย้ายกันไปเขียนโค้ดในเครื่องตัวเองเป็นอาทิตย์แล้วค่อยเอามารวมกัน มักจะจบลงด้วยหายนะที่โค้ดตีกันยับพังพินาศ (Merge Hell) ระบบ CI/CD (Continuous Integration) จึงเข้ามาบีบเวลานี้ให้เหลือระดับนาที ด้วยการบังคับให้ทุกคนดันโค้ดกลับขึ้นส่วนกลางทุกวัน เพื่อให้ระบบอัตโนมัติรันบิวด์และทดสอบทันที ทำให้ช่องว่างเวลาระหว่างโค้ดในเครื่องกับโค้ดส่วนรวมลู่เข้าสู่ศูนย์ตลอดเวลา
3. ห้องจำลองเพื่อ “Test Drive” อินเทอร์เฟซ (ความหมายที่แท้จริงของ TDD)
ไฮไลต์ที่น่าสนใจที่สุดของการบีบ Δt ในระดับวินาทีคือสิ่งที่เรียกว่า TDD (Test-Driven Development) ทว่าคนส่วนใหญ่มักเข้าใจแนวคิดนี้ผิดไป โดยคิดว่ามันคือการเอาคำสั่งทดสอบ (Test) มาเป็นพระเจ้าคอยชี้นำโค้ดเพื่อดักจับ Bug เท่านั้น
แต่ในความเป็นจริง มันไม่ได้เกี่ยวกับการต้องเขียน test ก่อนเลย แต่มันคือเรื่องของ Interface-First Design และการ “Test Drive (ทดลองขับ)”
ลองจินตนาการว่าคุณกำลังจะสร้างฟังก์ชันใหม่ขึ้นมา แทนที่คุณจะก้มหน้าก้มตาเขียนตรรกะภายใน (Function Body) จนเสร็จสิ้น ซึ่งอาจใช้เวลาเป็นชั่วโมงหรือเป็นวัน (Δt กว้าง) แล้วค่อยมาค้นพบทีหลังว่ามันเรียกใช้งานยากชะมัด TDD บังคับให้คุณเขียนฟังก์ชันเปล่าๆ ที่ไม่มีตรรกะอะไรเลยขึ้นมาก่อน แล้วสวมหมวกเป็น “ผู้บริโภคหรือผู้ใช้งานฟังก์ชันนั้น” ในไฟล์ Test
นี่คือการ Test Drive (ทดลองขับ) โค้ดของคุณเองในห้องจำลองสถานการณ์ (Simulator) คุณเปิดไฟล์ Test ขึ้นมาแล้วลองพิมพ์เรียกใช้ดูว่า “ถ้าฉันส่ง Parameter หน้าตาแบบนี้เข้าไป แล้วรับ Output แบบนี้กลับมา มันอ่านง่ายไหม? มันวุ่นวายไปหรือเปล่า? ตัวแปรเข้ามือและขับสนุกไหม?”
คุณทำการวนลูปปรับเปลี่ยนหน้าตาการเรียกใช้ (Signature/Interface) ไปเรื่อยๆ จนกว่าดีไซน์จะลื่นไหลที่สุด ผลลัพธ์คือ Δt ของการรับรู้ความห่วยในการออกแบบซอฟต์แวร์ของคุณจะลดลงเหลือเพียงไม่กี่วินาที เพราะคุณเห็นมันทันทีตั้งแต่บรรทัดแรกที่ลองกดเรียกใช้งาน ก่อนที่จะลงทุนเขียนตรรกะข้างในลงไปซะด้วยซ้ำ
ต้นทุนของการบีบเวลาและสัจธรรมของผู้บริหาร
อย่างไรก็ตาม การบีบ Δt→0 ในโลกความจริงไม่ได้มาฟรีๆ มันมีราคาที่ต้องจ่ายเป็นพลังงานและทรัพยากรมหาศาล การทำระบบ Automation, การเขียน Test ล่วงหน้า, หรือการจัดการประชุมเพื่อซิงค์งาน ล้วนสร้างสิ่งที่เรียกว่า Cognitive Load หรือความเหนื่อยล้าทางสมองให้กับมนุษย์อย่างรุนแรง
มนุษย์ไม่ใช่คอมพิวเตอร์ที่สามารถรันลูปตรวจสอบสถานะได้ล้านครั้งต่อวินาทีโดยไม่รู้สึกอะไร การบีบให้ทีมงานต้องรายงานสถานะตลอดเวลาเพียงเพื่อให้ผู้บริหารรู้สึกมั่นใจว่ารับรู้ทุกอย่างแบบ Real-time มักจะจบลงด้วยอาการ Burnout และความเร็วของทีมที่ดิ่งลงเหว เพราะพลังงานทั้งหมดถูกใช้ไปกับ “กระบวนการตรวจสอบ” จนไม่เหลือพลังงานในการ “เคลื่อนที่ไปข้างหน้า”
หน้าที่ของ Technical Leader หรือผู้บริหารกระบวนการทำงาน จึงไม่ใช่การบังคับให้ทุกจุดในองค์กรมี Δt=0 แบบบ้าคลั่ง แต่คือการหา Sweet Spot หรือจุดสมดุลที่เหมาะสม
ในจุดที่วิกฤตและเปราะบางที่สุด เช่น การออกแบบ Interface ของระบบ หรือการรวมโค้ดส่วนกลาง ตรงนี้เราจำเป็นต้องลงทุนเพื่อบีบช่องว่างเวลาให้สั้นที่สุด… แต่ในจุดที่ต้องการความคิดสร้างสรรค์ การปล่อยให้ทีมมีพื้นที่หายใจ มีช่วงเวลาลืมตาหลับตาตามจังหวะที่มนุษย์ต้องการ ย่อมส่งผลดีต่อโปรเจกต์ในระยะยาวมากกว่า
เพราะซอฟต์แวร์ที่ดีไม่ได้เกิดจากแผนงานที่สมบูรณ์แบบในอดีต แต่เกิดจากกระบวนการทำงานที่พร้อมยอมรับความจริง และปรับตัวตามสถานะปัจจุบันได้อย่างทันท่วงทีต่างหาก
หากบทความนี้มีประโยชน์
คุณสามารถติดตาม Late Night with Uncle Quin ได้ทาง
ที่ที่เราคุยกันเรื่อง software, engineering mindset และอนาคตของ developer
แบบไม่ต้องใส่สูท
แต่ใส่ความจริงของวงการเข้าไปเต็ม ๆ
