หลังจากเลิกประชุมกับ Steve ไปได้หนึ่งชั่วโมง ผมยังคงนั่งครุ่นคิดถึงคำพูดที่ฟังดูเป็นปริศนาของ Erik ผมรู้สึกเหมือนเรากำลังเข้าใกล้บางสิ่งที่ยิ่งใหญ่ แต่ผมยังมีคำถามเต็มไปหมด ในที่สุดผมก็ตัดสินใจโทรหาเขา
“ฮัลโหล?” เขาตอบรับ
“Bill เองครับ” ผมพูด “ผมต้องการคำใบ้เพิ่มหน่อยว่าตกลงเราต้องทำอะไรกันแน่...”
“ออกมาเจอฉันข้างนอกตึก” เขากล่าวแล้ววางสายไป
เมื่อผมเดินออกมาข้างนอก ลมพัดแรงจนน่ากลัว ผมมองไปรอบๆ ครู่หนึ่งก็ได้ยินเสียงบีบแตร Erik นั่งอยู่ในรถ BMW เปิดประทุนสีแดงที่ดูราคาแพงลิ่ว และเขายังเปิดประทุนไว้อีกด้วย “ขึ้นมาเร็ว! รีบหน่อย!”
“รถสวยนะครับ” ผมพูดพลางปีนขึ้นไปนั่งเบาะข้างคนขับ
“ขอบใจ” เขาตอบ “เพื่อนของฉันยืนยันว่าต้องให้ฉันยืมรถคันนี้มาใช้ในระหว่างที่ฉันอยู่ในเมือง”
ทันทีที่เขาเหยียบคันเร่งจนมิด ผมรีบคว้าที่วางแขนและคาดเข็มขัดนิรภัยอย่างรวดเร็ว ผมเห็นกระเป๋าถือผู้หญิงวางอยู่ที่พื้น และเริ่มสงสัยทันทีว่า “เพื่อน” คนนี้คือใคร
“เรากำลังมุ่งหน้ากลับไปที่ MRP-8” เขาบอก
เมื่อผมขอให้เขาปิดประทุนรถ เขาเหลือบมองผมแล้วพูดว่า “ฉันนึกว่าไม่มีคำว่า ‘อดีตนาวิกโยธิน’ เสียอีก สงสัยพวกนายสมัยนี้จะใจเสาะกว่ารุ่นฉันนะ”
“คุณเคยอยู่ในกองทัพด้วยเหรอ?” ผมถาม พยายามซ่อนเสียงฟันกระทบกัน
เขาหัวเราะ “ยี่สิบกว่าปีแน่ะ”
“ผมเดาว่าคุณเกษียณมาในยศนายทหารใช่ไหมครับ?” ผมถาม
“พันตรี หน่วยรบพิเศษ กองทัพบกสหรัฐฯ” เขาตอบพร้อมกับมองหน้าผม ผมก็ได้แต่หวังว่าเขาจะมองถนนบ้าง เมื่อพิจารณาจากความเร็วที่เขากำลังซิ่งอยู่ แต่เขายังคงพูดต่อ “หน่วยเดียวกับ Steve นั่นแหละ แต่เขาเข้ามาในฐานะสัญญาบัตร ส่วนฉันไต่เต้ามาจากพลทหาร เหมือนกับนายนั่นแหละ”
เขาไม่ได้เปิดเผยอะไรมากกว่านี้ แต่ที่พูดมาก็เพียงพอให้ผมเข้าใจเส้นทางทหารของเขาแล้ว เห็นได้ชัดว่าเขาเคยเป็นนายทหารประทวนระดับสูง (NCO) เหมือนหลายคนที่ผมต้องติดต่อด้วยเป็นประจำ ผมจำท่าทางและบุคลิกที่คุ้นเคยแบบนี้ได้ทันที เขาคงถูกมองว่าเป็นคนที่มีศักยภาพสูงมากที่หาได้ยาก จนผู้ใหญ่ตัดสินใจลงทุนในอนาคตของเขา ส่งเขาไปเรียนมหาวิทยาลัยและโรงเรียนนายร้อย แล้วกลับเข้ามารับราชการในฐานะร้อยตรีที่แก่ที่สุดในรุ่น คงจะแก่กว่าคนอื่นสักสิบปีได้เลยมั้ง
ต้องเป็นคนพิเศษจริงๆ ถึงจะผ่านจุดนั้นมาได้
เรามาถึงโรงงานด้วยเวลาทำลายสถิติ และตอนนี้เรายืนอยู่บนทางเดินเหนือศีรษะ (catwalk) เขาเริ่มพูดสุนทรพจน์ที่ผมคาดไว้อยู่แล้ว “โรงงานผลิตคือระบบ วัตถุดิบเริ่มต้นที่ฝั่งหนึ่ง และเรื่องนับล้านอย่างต้องผ่านไปได้อย่างถูกต้อง เพื่อให้มันกลายเป็นสินค้าสำเร็จรูปที่ส่งมอบได้ตามกำหนดเวลาที่อีกฝั่ง ทุกอย่างทำงานร่วมกัน หากแผนกงานใดกำลังสู้รบกับแผนกอื่น โดยเฉพาะถ้าฝ่ายผลิต (Manufacturing) กำลังรบกับฝ่ายวิศวกรรม (Engineering) ความก้าวหน้าในทุกก้าวจะเป็นเรื่องยากลำบาก”
Erik หันมาทางผมและชี้ไปข้างหน้า “นายต้องเลิกคิดแบบหัวหน้าแผนก และต้องคิดให้ใหญ่ขึ้น เหมือนผู้จัดการโรงงาน หรือดีกว่านั้นคือคิดเหมือนคนที่ออกแบบโรงงานแห่งนี้และกระบวนการทั้งหมดที่มันต้องพึ่งพา พวกเขามองภาพรวมของ Workflow ทั้งหมด ระบุได้ว่า Constraint อยู่ที่ตรงไหน และใช้เทคโนโลยีรวมถึงองค์ความรู้ในกระบวนการที่มีทั้งหมดเพื่อให้แน่ใจว่างานจะดำเนินไปได้อย่างมีประสิทธิผลและประสิทธิภาพที่สุด พวกเขาต้องดึง ‘Allspaw ในตัว’ ออกมา”
ผมกำลังจะอ้าปากถามว่าเขาหมายความว่าอะไรตอนพูดเรื่อง “Allspaw” แต่เขาก็โบกมือปัดไปเสียก่อน “ในการผลิต เรามีมาตรวัดที่เรียกว่า takt time ซึ่งก็คือ Cycle Time ที่จำเป็นเพื่อให้ผลิตได้ทันความต้องการของลูกค้า หากขั้นตอนใดใน Workflow ใช้เวลานานกว่า takt time นายก็จะไม่สามารถตอบสนองความต้องการของลูกค้าได้”
“ดังนั้นตอนที่นายวิ่งวุ่นไปทั่วแล้วร้องว่า ‘โอ้ ไม่นะ! เราเตรียม Environment สำหรับ Phoenix ไม่ทัน! ช่วยด้วย! โอ้ ไม่นะ! เรา Deploy ไม่ได้ เพราะมีคนทำ Environment ของ Phoenix พังอีกแล้ว!’ ” เขาพูดด้วยเสียงสูงล้อเลียนเหมือนเด็กผู้หญิง “นั่นหมายความว่า Cycle Time ของขั้นตอนสำคัญบางอย่างในขอบเขตความรับผิดชอบของนายมันสูงกว่า takt time นั่นคือเหตุผลที่นายตามความต้องการของลูกค้าไม่ทัน
“ในฐานะส่วนหนึ่งของ The Second Way นายต้องสร้าง Feedback Loop ที่ย้อนกลับไปจนถึงช่วงแรกสุดของการนิยามผลิตภัณฑ์ การออกแบบ และการพัฒนา” เขากล่าว “และจากการที่นายคุยกับ Dick อยู่ นายอาจจะย้อนกลับไปได้ไกลกว่านั้นด้วยซ้ำในกระบวนการ”
เขาชี้ไปที่พื้น “ดูเลนอุปกรณ์ที่อยู่ระหว่างเทปสีส้มยาวๆ นั่นสิ เลนนั้นใช้ผลิตสินค้าที่ทำกำไรสูงสุดให้เรา แต่โชคชะตาเล่นตลก Workflow นั้นมีสองขั้นตอนที่ใช้เวลา Setup และ Process นานที่สุด นั่นคือการพ่นสีฝุ่นและการอบในเตาอบความร้อนสูง”
เขาเงยหน้าขึ้นและกางแขนออก “ในอดีต Cycle Time ของสองขั้นตอนนี้มันสูงกว่า takt time มาก จนเราไม่มีทางผลิตทันความต้องการของลูกค้าได้เลย ทำไมชีวิตมันถึงไม่ยุติธรรมแบบนี้? สินค้าที่ทำกำไรมากที่สุดดันต้องใช้ Constraint ของเรา ทั้งสองอย่าง เลย นั่นคือทั้งเตาอบความร้อนสูงและห้องพ่นสี! แล้วเราทำยังไงล่ะ?
“ลูกค้าถึงกับเสนอเงินเพิ่ม อ้อนวอนขอซื้อสินค้าพวกนี้ แต่เราต้องปฏิเสธพวกเขาไป เพราะเวลา Setup ของแต่ละงานใช้เวลานานหลายชั่วโมงหรือบางทีก็เป็นวันๆ เราต้องผลิตด้วย Batch Size ขนาดมหึมาเพื่อให้ทันความต้องการ เราใช้ถาดขนาดใหญ่ในการพ่นสีและอบชิ้นงานให้ได้คราวละมากๆ เรารู้ว่าเราต้องลด Batch Size ลงเพื่อเพิ่ม Throughput แต่ทุกคนกลับบอกว่ามันทำไม่ได้”
“วิธีที่ Toyota แก้ไขปัญหานี้ได้กลายเป็นตำนานไปแล้ว” เขากล่าว “ในช่วงทศวรรษ 1950 พวกเขามีกระบวนการปั๊มฝากระโปรงรถที่ใช้เวลา Change-over เกือบสามวัน มันต้องย้ายแม่พิมพ์ (Die) ขนาดใหญ่และหนักหลายตัน เวลา Setup ก็นานมากเสียจนต้องใช้ Batch Size ขนาดใหญ่ ซึ่งทำให้พวกเขาไม่สามารถใช้เครื่องปั๊มเครื่องเดียวผลิตชิ้นส่วนรถหลายรุ่นพร้อมกันได้ นายจะปั๊มฝากระโปรง Prius หนึ่งอัน แล้วมาปั๊มของ Camry อีกอันไม่ได้หรอก ถ้ามันต้องใช้เวลาสามวันในการเปลี่ยนเครื่องมือจริงไหม?”
“พวกเขาทำยังไงล่ะ?” เขาถามแบบไม่ต้องตอบ “พวกเขาสังเกตขั้นตอนทั้งหมดที่ต้องทำในการเปลี่ยนเครื่องมืออย่างใกล้ชิด จากนั้นก็ปรับปรุงและเตรียมการต่างๆ จนลดเวลา Change-over ลงมาเหลือไม่ถึงสิบนาที และนั่นก็คือที่มาของคำศัพท์ในตำนานอย่าง ‘Single-Minute Exchange of Die’ (SMED) นั่นเอง
“เราศึกษาผลงานของ Ohno, Spear และ Rother ทั้งหมด เรารู้ว่าเราต้องลด Batch Size ลง แต่เราไม่ได้กำลังจัดการกับแม่พิมพ์ปั๊มฝากระโปรง เรากำลังเผชิญกับการพ่นสีและอบสี” เขาพูดต่อ “หลังจากระดมสมอง ตรวจสอบ และทดลองกับฝ่าย Engineering อยู่นานหลายสัปดาห์ เราก็ได้ไอเดียเพี้ยนๆ มาอย่างหนึ่ง นั่นคือเราอาจจะพ่นสีและอบสีในเครื่องเดียวเลยก็ได้ เราเอาเตาอบมาประกอบเข้ากับการพ่นสีฝุ่นลงบนชิ้นงาน แล้วใช้โซ่และเฟืองที่เอามาจากรถจักรยานมาดึงมันผ่านเครื่อง”
“เรารวมศูนย์ปฏิบัติงานสี่แห่งเข้าเป็นหนึ่งเดียว กำจัดขั้นตอนที่ต้องทำด้วยมือและเสี่ยงต่อความผิดพลาดออกไปกว่าสามสิบขั้นตอน เปลี่ยนมาเป็นกระบวนการทำงานแบบอัตโนมัติทั้งหมด ทำให้เกิด Single-piece Flow และกำจัดเวลา Setup ทั้งหมดออกไปได้ Throughput ของเราพุ่งสูงเป็นประวัติการณ์เลยล่ะ”
“ประโยชน์ที่ได้นั้นมหาศาลมาก” เขาพูดอย่างภาคภูมิใจ “อย่างแรก เมื่อพบตำหนิ (Defect) เราก็แก้ไขได้ทันที โดยไม่ต้องทิ้งชิ้นส่วนอื่นทั้งหมดใน Batch นั้น อย่างที่สอง WIP (Work in Process) ลดลง เพราะแต่ละศูนย์งานไม่มีวันผลิตงานเกินจนต้องไปนั่งรอในคิวของศูนย์งานถัดไป แต่ประโยชน์ที่สำคัญที่สุดคือ Order Lead Time ลดลงจากหนึ่งเดือนเหลือไม่ถึงสัปดาห์ เราสามารถผลิตและส่งมอบสิ่งที่ลูกค้าต้องการได้ไม่ว่าจะมากหรือน้อย และไม่ต้องมีคลังสินค้าที่เต็มไปด้วยของเน่าเสียที่ต้องมาเลขายในราคาถูกๆ อีกเลย”
“คราวนี้ถึงตานายแล้ว” เขาพูดด้วยน้ำเสียงเข้ม พร้อมกับชี้นิ้วมาที่หน้าอกผม “นายต้องหาวิธีลดเวลา Change-over ของนายและเพิ่มความเร็วของ Deployment Cycle Time ให้ได้”
“ฉันคิดว่าเป้าหมายของนายน่าจะเป็น...” เขาพูดพร้อมกับหยุดครู่หนึ่ง “สิบ Deploy ต่อวัน ทำไมล่ะ? มันก็น่าจะทำได้นี่”
ผมถึงกับอ้าปากค้าง “นั่นมันเป็นไปไม่ได้ครับ”
“อ้อ จริงเหรอ?” เขาพูดด้วยใบหน้าตาย “งั้นลองฟังเรื่องนี้ดู ย้อนไปเมื่อปี 2009 ฉันเป็นบอร์ดบริหารของบริษัทเทคโนโลยีแห่งหนึ่ง วิศวกรคนหนึ่งของเราไปงาน Velocity Conference และกลับมาบ่นพร่ำเหมือนคนบ้า เต็มไปด้วยไอเดียอันตรายและเป็นไปไม่ได้ เขาได้ดูการนำเสนอของ John Allspaw และเพื่อนร่วมงานของเขา Paul Hammond ซึ่งเป็นการพลิกโลกจากหน้ามือเป็นหลังมือ Allspaw และ Hammond ดูแลทีม IT Operations และทีมวิศวกรรมที่ Flickr แทนที่จะรบกันเหมือนแมวกับหมา พวกเขาพูดถึงการทำงานร่วมกันเพื่อให้ทำสิบ Deploy ต่อวันเป็นเรื่องปกติ! นี่ในโลกที่องค์กรไอทีส่วนใหญ่ทำ Deploy กันเป็นรายไตรมาสหรือรายปีนะ ลองนึกภาพดูสิ เขาทำ Deploy ได้เร็วกว่าเดิมถึงพันเท่าเลยนะนั่น”
“บอกเลยว่าตอนนั้นเราทุกคนต่างก็คิดว่าวิศวกรคนนั้นเพี้ยนไปแล้ว” เขาพูดต่อ “แต่ฉันก็ได้เรียนรู้ว่าแนวทางที่ Allspaw และ Hammond นำเสนอคือผลลัพธ์ที่ไม่อาจหลีกเลี่ยงได้จากการนำ The Three Ways มาใช้กับไอที Value Stream มันเปลี่ยนวิธีการจัดการไอทีของเราไปอย่างสิ้นเชิง และมันก็ช่วยกอบกู้บริษัทของเราไว้”
“พวกเขาทำได้ยังไงกันครับ?” ผมถามอย่างงงงวย
“คำถามที่ดี” เขาตอบ “Allspaw สอนพวกเราว่าถ้าทีม Dev และ Ops ทำงานร่วมกัน รวมถึงทีม QA และฝ่ายธุรกิจด้วย พวกเขาก็จะเป็นกลุ่มที่มีพลังมหาศาล (Super-tribe) และสามารถทำในสิ่งที่น่าอัศจรรย์ได้ พวกเขายังรู้ดีว่าตราบใดที่โค้ดยังไม่ขึ้น Production มันก็จะไม่มีทางสร้าง Value ได้เลย เพราะมันเป็นแค่ WIP ที่ติดอยู่ในระบบ เขาพยายามลด Batch Size ลงเรื่อยๆ เพื่อให้ Feature Flow เดินหน้าได้อย่างรวดเร็ว ส่วนหนึ่งเขาทำสำเร็จได้ก็เพราะการรับประกันว่าจะมี Environment พร้อมใช้งานเสมอเมื่อต้องการ เขาทำกระบวนการ Build และ Deployment ให้เป็นอัตโนมัติ (Automated) โดยตระหนักว่าเราสามารถจัดการกับ Infrastructure เหมือนมันเป็นโค้ด (Infrastructure as Code) ได้ เช่นเดียวกับ Application ที่ทีม Dev ส่งมอบนั่นแหละ ซึ่งมันช่วยให้เขาสามารถสร้างกระบวนการสร้าง Environment และ Deploy ได้ในขั้นตอนเดียว เหมือนกับที่เราหาวิธีพ่นสีและอบสีได้ในเครื่องเดียวเลยไงล่ะ”
“เอาละ ตอนนี้เรารู้แล้วว่า Allspaw และ Hammond ไม่ได้บ้าไปเสียทีเดียว Jez Humble และ Dave Farley ก็ได้ข้อสรุปแบบเดียวกันนี้อย่างอิสระ จากนั้นพวกเขาก็ได้ประมวลแนวปฏิบัติและหลักการที่ช่วยให้ทำ Deployment ได้หลายครั้งต่อวันลงในหนังสือระดับตำนานอย่าง Continuous Delivery ต่อมา Eric Ries ก็ได้แสดงให้เราเห็นว่าความสามารถนี้ช่วยให้ธุรกิจเรียนรู้และชนะได้อย่างไรในงานเขียนเรื่อง Lean Startup ของเขา”
ขณะที่ Erik พูด เขาดูมีชีวิตชีวามากที่สุดเท่าที่ผมเคยเห็นมา เขาส่ายหัวและมองหน้าผมอย่างจริงจัง
“นายคงจะมองเห็นก้าวต่อไปได้ชัดเจนแล้วนะเจ้าตั๊กแตนน้อย เพื่อที่นายจะตามความต้องการของลูกค้าให้ทัน ซึ่งรวมถึงเพื่อนร่วมงานฝั่งต้นน้ำของนายในทีม Development ด้วย” เขากล่าว “นายจำเป็นต้องสร้างสิ่งที่ Humble และ Farley เรียกว่า deployment pipeline ขึ้นมา นั่นคือ Value Stream ทั้งหมดของนาย ตั้งแต่ตอนที่เช็คอินโค้ด (Code check-in) ไปจนถึง Production มันไม่ใช่ศิลปะ แต่มันคืองานผลิต นายต้องเอาทุกอย่างเข้าไปอยู่ใน Version Control ให้หมด ทุกอย่างจริงๆ ไม่ใช่แค่โค้ด แต่รวมถึงทุกสิ่งที่จำเป็นในการสร้าง Environment จากนั้นนายต้องทำกระบวนการสร้าง Environment ทั้งหมดให้เป็นอัตโนมัติ นายต้องมี deployment pipeline ที่สามารถสร้าง Test และ Production Environment แล้วจากนั้นก็ Deploy โค้ดลงไปได้ทั้งหมดตามต้องการ (On-demand) นั่นแหละคือวิธีที่นายจะลดเวลา Setup และกำจัดข้อผิดพลาดต่างๆ จนสุดท้ายนายก็จะตามทันจังหวะการเปลี่ยนแปลงที่ทีม Development กำหนดไว้”
“เดี๋ยวก่อนครับ” ผมท้วง “ตกลงว่าสิ่งที่ผมต้องทำให้เป็นอัตโนมัติจริงๆ คืออะไรบ้างครับ?”
Erik มองหน้าผมอย่างเข้มงวด “ไปคุยกับ Brent ซะ ดึงตัวเขาเข้ามาร่วมทีมใหม่นี้ แล้วทำให้แน่ใจว่าเขาจะไม่ถูกรบกวน ยิ่งในช่วงนี้ตอนที่นายยังไม่ได้ทำกระบวนการ Build ให้เป็นอัตโนมัติ เขาคือ Bottleneck ของนาย เอาสิ่งที่อยู่ในหัวเขามาเขียนให้อยู่ในรูปแบบขั้นตอนการสร้างกระบวนการ Build ให้ได้ เอาแรงงานคนออกไปจากธุรกิจ Deployment ซะ แล้วหาวิธีทำให้ได้สิบ Deploy ต่อวัน”
ผมยังคงไม่หายสงสัย “สิบ Deploy ต่อวันเหรอครับ? ผมค่อนข้างมั่นใจว่าไม่มีใครเรียกร้องขนาดนั้นหรอก คุณกำลังตั้งเป้าหมายที่สูงเกินความต้องการของธุรกิจไปหรือเปล่าครับ?”
Erik ถอนหายใจและกลอกตา “เลิกจดจ่ออยู่แต่เรื่องความถี่ในการ Deployment ซะ ความคล่องตัวทางธุรกิจ (Business Agility) ไม่ใช่แค่เรื่องความเร็วอย่างเดียว แต่มันเป็นเรื่องความสามารถในการตรวจจับและตอบสนองต่อการเปลี่ยนแปลงของตลาด และการกล้าเสี่ยงมากขึ้นภายใต้การคำนวณที่รอบคอบ มันคือการทดลองอย่างต่อเนื่อง (Continual experimentation) เหมือนที่ Scott Cook เคยทำที่ Intuit ซึ่งพวกเขาทำการทดลองกว่าสี่สิบครั้งในช่วงเวลาที่ยื่นภาษีกันอย่างหนัก เพื่อหาวิธีเพิ่มอัตราการเข้าถึงลูกค้าให้ได้มากที่สุด และนั่นทำในช่วงที่คนยื่นภาษีกันเยอะที่สุดเลยนะ!”
“ถ้านายไม่สามารถทดลองได้มากกว่าและเอาชนะคู่แข่งในเรื่องเวลาที่จะออกสู่ตลาด (Time to market) และความคล่องตัวได้ นายก็แพ้แน่นอน ฟีเจอร์ต่างๆ มันคือการเดิมพัน ถ้าโชคดีก็คงจะมีแค่สิบเปอร์เซ็นต์เท่านั้นที่ได้ผลประโยชน์ตามต้องการ ดังนั้นถ้านายยิ่งเอาฟีเจอร์ออกสู่ตลาดเพื่อทดสอบได้เร็วเท่าไหร่ นายก็ยิ่งได้เปรียบเท่านั้น นอกจากนี้ นายยังช่วยให้ธุรกิจได้ทุนคืนเร็วขึ้น และหมายความว่าธุรกิจก็เริ่มทำเงินได้เร็วขึ้นตามไปด้วย”
“Steve กำลังวางเดิมพันอยู่รอดของเขาไว้กับความสามารถของนายในการรันโปรเจกต์และ Deploy ได้เร็วขึ้น ดังนั้นไปร่วมงานกับ Chris แล้วหาวิธีให้ได้ว่าในทุกขั้นตอนของกระบวนการ Agile Development นายต้องไม่ได้มีแค่โค้ดที่พร้อมส่งมอบเท่านั้น แต่ต้องมี Environment ที่พร้อมใช้งานที่สามารถ Deploy โค้ดลงไปได้ด้วย!”
“โอเคครับ เข้าใจแล้ว” ผมพูด “แต่ทำไมคุณต้องลากผมมาท่ามกลางความหนาวเหน็บแบบนี้ด้วยล่ะครับ? แค่อธิบายหน้ากระดานไวท์บอร์ดก็น่าจะพอแล้วไม่ใช่เหรอ?”
“นายคิดว่า IT Operations มันเป็นเรื่องซับซ้อนระดับส่งยานอวกาศเมื่อเทียบกับการผลิตอย่างนั้นเหรอ เหลวไหลสิ้นดี” เขาพูดอย่างไม่ใส่ใจ “จากที่ฉันเห็น คนที่อยู่ในตึก นี้ มีความคิดสร้างสรรค์และมีความกล้าหาญมากกว่าทุกอย่างที่ฉันเคยเห็นจากพวกนายในทีมไอทีตั้งเยอะ”