สมัยที่ผมเรียน ป.โท อาจารย์ที่สอนวิชา Operation Management ให้ทำเคสการผลิตรถยนต์ของโรงงานโตโยต้า ซึ่งมีการใช้ Toyota Production System หรือ TPS ตั้งแต่ต้นทางไปถึงปลายทาง ตั้งแต่ชิ้นส่วนต่างๆ จนกลายเป็นรถยนต์ที่วิ่งได้หนึ่งคัน ผมพบว่าหลักของ TPS บางอย่างสามารถนำมาประยุกต์ใช้กับการพัฒนาเว็บไซต์ขนาดใหญ่ที่มีความซับซ้อนยุ่งเหยิงได้ด้วย
TPS คือปรัชญาในการผลิตที่โตโยต้าคิดค้นขึ้นมาเพื่อให้การผลิตรถยนต์ในยุคปัจจุบันเป็นไปได้อย่างรวดเร็วและราบรื่น ลดปริมาณของเสียให้น้อยลง กล่าวกันว่าทุกหนึ่งนาทีจะมีรถยนต์ออกจากสายการผลิตโตโยต้าหนึ่งคัน ด้วย TPS นี้เองที่ทำให้โตโยต้าขึ้นมาเป็นผู้ผลิตรถยนต์ Top 3 ของโลก ท้าทายผู้นำอย่างฟอร์ดและจีเอ็ม
ถ้าในยุคของ Car Assembly 1.0 ฟอร์ดคือผู้สร้างนวัตกรรมใหม่ในการผลิตรถยนต์ด้วยการใช้สายการผลิตที่เลียนแบบมาจากโรงงานชำแหละเนื้อแทนการประกอบรถยนต์แบบแฮนด์เมดดั้งเดิม ในยุคของ Car Assembly 2.0 ก็ต้องยกให้โตโยต้าเป็นผู้นำ ด้วย TPS ทำให้โตโยต้าไม่ต้องสต็อกชิ้นส่วนประกอบรถยนต์ ไม่ต้องมีลานจอดที่กว้างมหาศาลเพื่อใช้เป็นโกดังเป็นสต็อกรถที่ประกอบเสร็จแล้ว และทำให้สามารถผลิตรถยนต์ที่มีสีสันแตกต่างกัน มี option แตกต่างกันตามคำสั่งซื้อของลูกค้า โดยใช้สายการผลิตเส้นเดียวกันได้
เป้าหมายของ TPS คือการลดของเสีย (Muda ในภาษาญี่ปุ่น หรือ Waste ในภาษาอังกฤษ) ซึ่งของเสียในนิยามของ TPS มี 7 ข้อดังนี้
- การผลิตมากเกินความจำเป็น เช่น ฝ่ายขายประเมินยอดขายวีออสสีเทาเบาะหนังเกียร์ออโต้ไว้ที่ 1,000 คัน แต่เอาเข้าจริงกลับมีลูกค้าซื้อแค่ 800 คัน แล้วจะทำยังไงกับ 200 คันที่เหลือล่ะ?
- มีสต็อกวัตถุดิบมากเกินความจำเป็น สต็อกมากเกินไปทำให้ต้องใช้พื้นที่เก็บมากขึ้น และต้องจ่ายเงินค่าสต็อกมากขึ้นด้วย
- การเคลื่อนไหวที่ไม่จำเป็น ไม่ว่าจะเป็นพนักงานหรือเครื่องจักร เพราะถ้าเคลื่อนไหวมาก ก็ยิ่งเพิ่มโอกาสที่พนักงานจะได้รับบาดเจ็บ หรือเครื่องจักรได้รับความเสียหายมากขึ้น
- การเคลื่อนย้ายที่ไม่จำเป็น ต่างกับข้อ 3 ตรงที่การเคลื่อนย้ายนี้หมายถึงเคลื่อนย้ายส่วนประกอบต่างๆ ของรถ ซึ่งนอกจากจะทำให้ส่วนประกอบมีโอกาสเสียหายสูงขึ้นแล้ว ลูกค้าเองก็ไม่ได้จ่ายเงินให้กับการเคลื่อนย้ายที่เพิ่มมากขึ้นซักหน่อย ลูกค้าไม่ได้สนใจเลยว่าโรงงานผลิตเบาะจะอยู่ห่างจากโรงงานประกอบรถ 2 กิโลเมตรหรือ 200 กิโลเมตร
- การรอคอยที่ไม่จำเป็น เช่น พนักงานที่ทำหน้าที่ประกอบเกียร์แมนนวลต้องอยู่เฉยๆ โดยไม่มีอะไรทำ เพราะว่าในสายการผลิตมีแต่รถเกียร์ออโต้
- ใส่สิ่งที่ไม่จำเป็นให้กับลูกค้า เช่น ถ้าโตโยต้าที่ขายในเมืองไทยติดทั้งแอร์และฮีตเตอร์ เพราะโตโยต้าคิดว่าฮีตเตอร์น่าจะจำเป็นในฤดูหนาว (ที่มีแค่ 1-2 เดือน) แต่คุณที่เป็นผู้ซื้อรถจะรู้สึกยังไงกับฮีตเตอร์ล่ะ?
- มีข้อผิดพลาดเกิดขึ้นมาก ซึ่งทำให้ต้องแก้ไขและสิ้นเปลืองวัตถุดิบ
เพื่อที่จะลด Muda ทั้ง 7 ข้อนี้ TPS จึงมีหลักการที่สรุปออกมาเป็น The Toyota Way หรือวิถีของโตโยต้าดังนี้
- ใช้กระบวนการผลิตอย่างต่อเนื่อง
- ใช้ระบบ “ดึง” เพื่อลดการผลิตที่เกินความจำเป็น ดึงในที่นี้หมายถึงถ้าต้องการใช้ส่วนประกอบใดก็ค่อยไปดึงมาจากผู้ผลิตส่วนประกอบนั้นมาหนึ่งชิ้น เมื่อผู้ผลิตพบว่าส่วนประกอบหายไปหนึ่งชิ้น ก็ค่อยผลิตเพิ่มขึ้นมาใหม่หนึ่งชิ้น เพื่อรอให้ส่วนประกอบถูกดึงไปใช้ เป็นแบบนี้ไปเรื่อยๆ
- ใช้หลัก Heijunka เพื่อกระจายโหลด เช่น ถ้ามีคำสั่งซื้อรถเกียร์ออโต้ 100 คัน เกียร์แมนนวล 50 คัน จะไม่ผลิตเกียร์ออโต้รวดเดียว 100 คัน และเกียร์แมนนวลรวดเดียวอีก 50 คัน แต่จะใช้วิธีผลิตเกียร์ออโต้ 2 คัน สลับกับเกียร์แมนนวล 1 คัน
- ใช้หลัก Jidoka สร้างวัฒนธรรมให้พนักงานทุกคนมีสิทธิ์สั่งหยุดกระบวนการผลิตได้ถ้าพบปัญหาใดๆ เกิดขึ้น ทั้งนี้เพื่อจะได้หยุดแก้ปัญหาก่อน ไม่ปล่อยให้ข้อผิดพลาดผ่านไปเฉยๆ
- ใช้กระบวนการทำงานที่เป็นมาตรฐาน มีการปรับปรุงให้ดีขึ้นอย่างต่อเนื่อง (Kaizen) และให้อำนาจแก่พนักงานในการปรับปรุงกระบวนการทำงาน
- ใช้เครื่องมือที่ทำให้ปัญหาต่างๆ ถูกมองเห็นได้
- ใช้เทคโนโลยีที่ผ่านการทดสอบมาอย่างดีแล้วก่อนนำมาใช้ในกระบวนการผลิต
ลองมาดูการพัฒนาเว็บไซต์ขนาดใหญ่ที่ต้องมีทีมงานหลายคนดูบ้าง มีอะไรบ้างที่ถือว่าเป็น Muda ของการทำเว็บ?
- บั๊ก บั๊ก บั๊ก เป็นส่วนเกินของเว็บไซต์ที่ลูกค้าไม่ปรารถนา คนทำเว็บเองก็ไม่ปรารถนา แต่บ่อยครั้งที่ไม่รู้ว่าบั๊กมันซ่อนอยู่ตรงไหน ที่แย่ไปกว่านั้นก็คือไม่ค่อยมีใครอยากเป็นเจ้าภาพในการแก้บั๊กซะด้วย ถ้ารู้ว่าบั๊กเกิดจากส่วนที่ตัวเองเป็นผู้เขียน แบบนี้ก็น่าแก้หน่อย แต่ถ้าหาไม่ได้ว่าบั๊กเป็นของใคร ก็จะเกิดเหตุการณ์เอาดีใส่ตัวเอาบั๊กใส่คนอื่น
- คนในทีมว่าง ไม่มีงานทำ ปัญหานี้มักจะเกิดขึ้นถ้าวางแผนแบ่งงานกันไม่ดี เช่น โปรแกรมเมอร์ต้องรอคนดีไซน์เว็บเสร็จก่อนถึงจะเริ่มงานของตัวเองได้
- มี function ที่ถูกเขียนขึ้นมาซ้ำซ้อนกัน บางทีโปรแกรมเมอร์คนแรกเขียน function ขึ้นมาแล้วเพื่อใช้งานในโมดูลที่ตัวเองรับผิดชอบ โปรแกรมเมอร์อีกคนต้องใช้ function นี้เหมือนกัน แต่ไม่รู้ว่าคนแรกเขียนเอาไว้แล้ว ตัวเองก็เลยเขียนซ้ำขึ้นมาอีก ทำให้ซอร์สโค้ดใหญ่ขึ้นโดยไม่จำเป็น ภาษาอังกฤษเรียกว่า re-invent the wheel แทนที่จะไปสร้างยางหุ้มล้อ ดันมาเสียเวลาทำล้อที่มีคนอื่นทำออกมาแล้ว
เรื่องบั๊กก็มีทั้งในเว็บไซต์และในโตโยต้า วิธีการที่โตโยต้าใช้รับมือกับบั๊กก็คือการปลูกฝังวัฒนธรรม “เห็นอะไรผิดให้แก้ไขทันที” แก่พนักงาน เช่น ถ้าพนักงานส่วนประกอบเบาะขันน็อตแล้วน็อตปีนเกลียว พนักงานก็ต้องแก้ไขตรงนั้นทันที ไม่ใช่ปล่อยผ่านๆ ไป ถ้าพนักงานหลายคนเจอปัญหาเรื่องน็อตปีนเกลียวบ่อย ตัวพนักงานหรือหัวหน้าก็จะต้องคิดหา Poka-yoke หรือตัวกันโง่ขึ้นมา เช่น อาจจะเปลี่ยนอุปกรณ์ขันน็อตใหม่ที่ช่วยให้น็อตอยู่ในตำแหน่งที่ตรงกันก่อนที่จะสกรูลงไปเพื่อลดปัญหาการปีนเกลียว บางปัญหาที่พนักงานระดับล่างแก้ไขเองไม่ได้ ก็จะมีระบบ Andon โดยที่พนักงานจะดึงสายสัญญาณที่อยู่ในโซนของตัวเอง ที่ป้ายไฟในโรงงานก็จะแสดงตัวเลขของโซนที่เกิดปัญหาขึ้น หัวหน้าเห็นปุ๊บก็จะรีบเข้าไปแก้ปัญหาทันที แต่ถ้าเป็นปัญหาที่แก้ไขทันทีไม่ได้ เช่น ต้องประกอบเบาะสีดำ แต่เบาะที่เข้ามาเป็นสีเทา พนักงานก็จะเอาป้ายมาติดหน้ารถเพื่อบอกว่ารถคันนี้มีปัญหา เมื่อรถเลื่อนไปตามสายพานจนสุดทาง รถจะถูกแยกเข้าไปจอดในจุดซ่อมเพื่อรอเบาะที่ถูกต้องมาเปลี่ยน
มาดูบั๊กในการทำเว็บบ้าง ความแตกต่างอยู่ที่บั๊กในเว็บมันมองเห็นได้ยากกว่าบั๊กในโตโยต้า โปรแกรมเมอร์อาจจะไม่รู้ว่าตัวเองสร้างบั๊กขึ้นมาแล้ว ก็เลยไม่ได้แก้ไขในทันที ปัญหาเลยอยู่ที่จะต้องรู้ว่าในระบบมีบั๊กอะไรอยู่? บั๊กอยู่ในโมดูลไหน? และใครเป็นคนทำให้เกิดบั๊ก? (ซึ่งต้องรับหน้าที่แก้ไข) ก็เลยต้องใช้วิถีของโตโยต้าในข้อ 6 เพื่อทำให้บั๊กต่างๆ ถูกแสดงออกมา โดยมีเครื่องมือ 3 อย่างดังนี้
- ใช้ทีม QA ในการตรวจหาบั๊ก เมื่อพบแล้วก็ใส่ลงไปใน Defect Tracking เพื่อรอให้โปรแกรมเมอร์เข้ามาแก้ไขอีกที
- ใช้ Debugger Tool เพื่อตรวจหาว่าบั๊กว่าอยู่ในโมดูลไหน
- ใช้ CVS เก็บซอร์สโค้ดออกเป็นเวอร์ชั่นต่างๆ สามารถตรวจสอบย้อนหลังได้ว่าโปรแกรมเมอร์คนไหนที่ทำให้เกิดบั๊กขึ้นมา
Muda ตัวที่สองของการพัฒนาเว็บคือเรื่องคนว่างงาน โตโยต้าแก้ปัญหานี้โดยใช้ Heijunka เพื่อกระจายโหลด ภาษาคอมพิวเตอร์ก็คือ load balance แทนที่จะให้ทรัพยากรหนึ่งรับโหลดหนักในช่วงเวลาหนึ่งจากนั้นก็ไม่มีโหลดเลย ก็เปลี่ยนเป็นให้รับโหลดพอประมาณอย่างสม่ำเสมอ ด้วยการกระจายงานแบบเดียวกันออกไม่ให้กระจุกอยู่ในช่วงเวลาเดียวกัน
เราสามารถใช้หลัก Heijunka ในงานพัฒนาเว็บได้เหมือนกัน ด้วยการแบ่งระบบขนาดใหญ่ออกเป็นส่วนย่อยๆ แทนที่จะให้ทีมดีไซน์ทำงานทั้งระบบเสร็จก่อน แล้วค่อยให้ทีมโปรแกรมเมอร์ทำงานต่อ ก็ให้ทีมดีไซน์ทำเสร็จแค่ส่วนหนึ่งแล้วส่งต่อให้โปรแกรมเมอร์ ระหว่างนี้ทีมดีไซน์ก็ทำส่วนต่อไปทันที นอกจากนี้ถ้าจะให้ดียิ่งขึ้นก็คือการแยกส่วน Presentation ออกจากส่วน Business Logic เพื่อให้โค้ดของฝั่ง Presentation (HTML) ไม่ไปปนกับโค้ดของ Business Logic (เช่น PHP) แบบนี้ก็จะทำงานคู่ขนานกันได้ แต่การจะทำแบบนี้ได้ก็ต้องกำหนดจุดเชื่อมต่อระหว่าง Presentation กับ Business Logic ตั้งแต่แรก เช่น จะเอาผลลัพธ์จาก Business Logic มาแสดงใน Presentation อย่างไร หรือจะรับ input จาก Presentation เข้าไปประมวลผลใน Business Logic อย่างไร
Muda ตัวที่สามคือการทำงานซ้ำซ้อนกัน เป็นเรื่องยากอยู่เหมือนกันที่จะลดการทำงานซ้ำซ้อนในระบบขนาดใหญ่ ที่พอทำได้ก็คือต้องวิเคราะห์อย่างละเอียดว่าในระบบมี common function อะไรบ้าง แล้วบอกให้ทุกคนในทีมรู้จะได้ไม่ต้องเขียนซ้ำ แต่บางทีก็วิเคราะห์ออกมาได้ไม่หมด ก็ต้องใช้วิธีสนับสนุนให้คนในทีมสื่อสารกันให้ดี ก่อนจะเขียน function อะไรขึ้นมา ให้ลองถามดูก่อนว่ามีใครเขียนหรือยัง ถ้ายังไม่มีก็ค่อยเขียน เขียนเสร็จแล้วก็ต้องบอกคนอื่นในทีมให้รู้ด้วย
นอกจากนี้ เรื่อง Coding Standard ก็เป็นเรื่องสำคัญ โปรแกรมเมอร์ร้อยพ่อพันแม่ แต่ละคนมีสไตล์การเขียนโปรแกรมไม่เหมือนกัน ถ้าไม่กำหนดมาตรฐานร่วมกันว่าจะตั้งชื่อตัวแปรหรือ function อย่างไร ใช้ตัวอักษรเล็กหรือใหญ่ จะใส่ปีกกาตรงไหน ใช้อะไรเป็น indent ฯลฯ พอเอาโค้ดทั้งหมดมารวมกันแล้วจะเละเทะน่าดู
Muda ในการพัฒนาเว็บส่วนใหญ่เกิดจากการมองไม่เห็นสิ่งที่เกิดขึ้นในกระบวนการพัฒนาเว็บ การจะลด Muda ลงก็ต้องหาวิธีทำให้ปัญหาต่างๆ ถูกมองเห็นได้ก่อน เราถึงจะแก้ปัญหาได้ถูกจุด