สร้าง Excel ให้ Uber แต่ก็ถูกทิ้งในเวลาไม่นาน
(basta.substack.com)- ในปี 2016 องค์กร Business Intelligence ของ Uber สร้างเครื่องมือรันโมเดล R และ UI คล้าย Excel เพื่อใช้ข้อมูลที่จำเป็นต่อการแข่งขันของ Uber China ได้อย่างรวดเร็ว แต่ไม่นานฟีเจอร์นี้ก็ถูกถอดออกหลัง Uber China ถูกขายให้ Didi
- R-Crusher เป็นระบบภายในที่พยายามเปลี่ยนเวิร์กโฟลว์ที่ไม่เสถียร ซึ่งนักวิทยาศาสตร์ข้อมูลดาวน์โหลดข้อมูล Vertica ลงโน้ตบุ๊กแล้วปล่อยให้โมเดล R รันข้ามคืน ให้กลายเป็นเครื่องมือรันงานแบบใช้ API
- ทีมเมืองในจีนคุ้นเคยกับไฟล์ Excel สำหรับคำนวณแรงจูงใจให้คนขับ และทีมจึงสร้าง สเปรดชีตเอนจิน ที่รันไฟล์ XLS และสูตรในเบราว์เซอร์ แทนการย้ายสูตรหลายร้อยถึงหลายพันสูตรไปเป็น JavaScript ด้วยมือ
- สาเหตุที่ผลลัพธ์คลาดเคลื่อนจาก Excel เล็กน้อยอยู่ที่นักวิทยาศาสตร์ข้อมูลใช้ การอ้างอิงแบบวนซ้ำ เพื่อทำ linear regression จึงปรับให้คำนวณซ้ำจนกว่าจะลู่เข้าเหมือน Excel
- แม้โค้ดจะเขียนมาดี ก็อาจถูกลบได้หาก ปัญหาทางธุรกิจ ที่มันตั้งใจแก้ไขหายไป คุณค่าของงานวิศวกรรมจึงอยู่ใกล้กับการแก้ปัญหามากกว่าอายุของโค้ด
เครื่องมือข้อมูลภายในที่ค้ำจุน Uber China
- หลังเข้าร่วม Uber ในปี 2016 ก็ได้ทำงานเป็นวิศวกรฟรอนต์เอนด์คนแรกในทีม Crystal Ball
- ทีมมีขนาดราว 4 คน และส่วนใหญ่มีแนวโน้มเป็นแบ็กเอนด์ค่อนข้างมาก
- บทบาทคือทำให้เครื่องมือภายในกลายเป็น UI ที่คนในบริษัทใช้งานได้จริง
- ตอนนั้นนักวิทยาศาสตร์ข้อมูลดาวน์โหลดข้อมูลจาก Vertica แล้วรันโมเดล R ข้ามคืนบนโน้ตบุ๊กหลายเครื่อง
- ตอนเช้าจะมีข้อมูลที่อาจใช้ได้ในวันนั้นออกมาจากเฉพาะโน้ตบุ๊กที่โมเดลไม่ล่ม
- โน้ตบุ๊กที่ล้มเหลวจะสร้างข้อมูลที่จำเป็นไม่ได้ และทำให้บริษัทสูญเสียเงิน
- R-Crusher ที่ทีมกำลังสร้างอยู่มีลักษณะใกล้เคียงระบบ CI ที่ดาวน์โหลดโค้ดผ่านการเรียก API แล้วรันเพื่อสร้างไฟล์ผลลัพธ์
- Wesley ซึ่งเป็นฟรอนต์เอนด์ของ R-Crusher มีเวอร์ชันแรกพร้อมภายในไม่กี่สัปดาห์หลังเข้าร่วม
- หลังจากนั้นอีก 6–7 เดือน มีการเพิ่มฟีเจอร์สำหรับผู้ใช้ เครื่องมือดีบัก และขยายทีมฟรอนต์เอนด์
ตลาดจีนและการคำนวณแรงจูงใจให้คนขับ
- ในปี 2016 แกนใหญ่ภายใน Uber คือการเขียน/ออกแบบแอปใหม่ และ Uber China
- งานของทีม Crystal Ball ท้ายที่สุดแล้วคือการสนับสนุน Uber China
- R-Crusher เป็นเครื่องมือเพื่อให้ได้ข้อมูลที่จำเป็นต่อการแข่งขันกับ Didi
- จีนเป็นโอกาสสำคัญของ Uber และข้อมูลบางส่วนที่จำเป็นมีกำหนดจะมาจาก R-Crusher
- ในช่วงฤดูร้อนมีข้อกำหนดใหม่เข้ามา
- มีโมเดลที่สร้างข้อมูลคาดการณ์ความต้องการเรียกรถในจีนข้ามคืน
- ข้อมูลนี้โดยลำพังไม่ได้มีประโยชน์ แต่ถ้านำไปใส่ในแท็บของสเปรดชีต Excel เฉพาะ จะกลายเป็นเครื่องมือโต้ตอบสำหรับคำนวณแรงจูงใจให้คนขับ
- ผู้รับผิดชอบด้านการเงินขอให้นำสเปรดชีตนั้นเข้าไปไว้ใน Wesley
- ทีมเมืองบอกว่าพวกเขาใช้เป็นแค่ Excel และขอให้ “ทำให้เหมือน Excel”
- แม้จะอธิบายว่าเวลาของทีมวิศวกรรมไม่พอ คำตอบที่ได้รับคือ หากไม่มีเครื่องมือนี้ในแต่ละวัน จะสูญเงินหลายล้านดอลลาร์
เลียนแบบ Excel ในเบราว์เซอร์
- ไม่มีเวลาย้ายสเปรดชีตไปเป็นโค้ด Python หรือ R ฝั่งแบ็กเอนด์ และสถานการณ์กลายเป็นว่าฝั่งฟรอนต์เอนด์ต้องเขียน JavaScript จำนวนมาก
- โปรโตไทป์ Box Sums ที่เคยสร้างไว้ที่ Box กลายเป็นฐานของงานนี้
- มี UI สเปรดชีตแบบง่ายที่ใช้ React และเอนจินสูตรพื้นฐาน
- เมื่อลากไฟล์ XLS/XLSX วางบนหน้าเว็บ จะใช้ไลบรารี Node เพื่อพาร์สเนื้อหา
- การทำสำหรับ Uber มีเป้าหมายไม่ใช่ Excel ตัวจริง แต่เป็นพฤติกรรมที่ใกล้เคียง Excel
- อ่านไฟล์ XLS เป็นอินพุต
- รันสูตร Excel บนข้อมูล
- แบ็กเอนด์ส่งข้อมูลความต้องการเรียกรถมาเป็นอาร์เรย์สองมิติ และฟรอนต์เอนด์ใส่ข้อมูลนั้นเข้าเอนจินสูตรเหมือนเป็นแท็บที่ซ่อนอยู่
- ตั้งค่าให้เป็นอ่านอย่างเดียว ยกเว้นเซลล์ที่ผู้ใช้ต้องปรับ
- หัวใจสำคัญคือการไม่แปลสูตรหนาแน่นหลายร้อยถึงหลายพันสูตรเป็น JavaScript ด้วยมือ
- ระหว่างพัฒนา มีการดึงสูตรจากไฟล์ XLS และเพิ่มฟังก์ชันกับไวยากรณ์ที่จำเป็นเข้าไปในเอนจินสูตร
-
ขยายไวยากรณ์ Excel
- การอ้างอิงเซลล์แบบ absolute
- การอ้างอิงเซลล์ในชีตอื่น
- ไวยากรณ์สเปรดชีตที่ไม่มีในเดโม Box เดิม
-
ตัวเลขที่เกือบถูกแต่ยังผิด และการอ้างอิงแบบวนซ้ำ
- ในการเปรียบเทียบครั้งแรก ผลลัพธ์จาก Excel กับเอนจินที่สร้างเองต่างกันเล็กน้อยมาก
- เมื่อผลลัพธ์จาก Excel เป็น
3.03ผลลัพธ์ของเอนจินเองเป็น3.01 - เมื่อผลลัพธ์จาก Excel เป็น
1.002ผลลัพธ์ของเอนจินเองเป็น1.000
- เมื่อผลลัพธ์จาก Excel เป็น
- ค่าที่เกือบถูก รับมือยากกว่าค่าที่ผิดอย่างชัดเจน
- มีโอกาสสูงว่าเป็นความต่างเชิงการคำนวณที่ละเอียดอ่อน มากกว่าข้อผิดพลาดเชิงลอจิกง่าย ๆ
- unit test ผ่านทั้งหมด และความต่างระหว่าง JavaScript double กับการแทนค่าทศนิยมลอยตัวของ Excel ก็ไม่ใช่สาเหตุ
- หลังจากถามนักวิทยาศาสตร์ข้อมูล สาเหตุก็ปรากฏ
- สเปรดชีตใช้ การอ้างอิงแบบวนซ้ำ เพื่อทำ linear regression
- Excel ไม่ได้ถือว่าการอ้างอิงแบบวนซ้ำเป็นข้อผิดพลาดเสมอไป
- หากค่าที่คำนวณลู่เข้าจนต่างกันน้อยกว่า epsilon ที่กำหนด ก็จะหยุดคำนวณซ้ำและถือว่าสำเร็จ
- การพัฒนาจึงเปลี่ยนไปตรวจจับกราฟ dependency แบบวนซ้ำ และเปรียบเทียบความต่างระหว่างค่าคำนวณเดิมกับค่าคำนวณใหม่
- ถ้าความต่างเล็กพอ ก็ใช้ค่าใหม่
- ถ้าไม่ใช่ ก็เพิ่มจำนวนรอบและคำนวณต่อไป
- กำหนดจำนวนรอบสูงสุดไว้ที่ 1000
- การเปลี่ยนแปลงใช้เวลาประมาณวันครึ่ง และผลลัพธ์ก็ตรงกับ Excel
- เขียนเทสต์และผสานเข้ากับ Wesley
- โปรเจกต์ถูกส่งมอบในสัปดาห์ที่สองของเดือนกรกฎาคม
ข้อกำหนดด้านความปลอดภัยหลังปล่อยใช้งาน และการยกเลิกอย่างกะทันหัน
- เครื่องมือนี้ถูกปล่อยใช้งานจริง และสมาชิกทีมเมืองของ Uber China ก็ล็อกอินเข้ามาใช้
- เข้าใจว่าตัวเลขที่สร้างขึ้นถูกใช้กับแรงจูงใจให้คนขับ
- ช่วงเวลาคือสัปดาห์ที่สามของเดือนกรกฎาคม
- ในสัปดาห์สุดท้ายของเดือนกรกฎาคม ผู้รับผิดชอบด้านการเงินตั้งประเด็นว่าเมื่อคลิกเซลล์แล้วเห็นสูตร
- มีการส่งต่อความกังวลว่าพนักงาน Didi อาจสมัครเป็นอินเทิร์น Uber China เพื่อขโมยข้อมูลออกไป
- threat model นี้ไม่ได้ถูกแชร์กับทีมวิศวกรรมล่วงหน้า
- หากต้องการปกป้องสูตรทั้งหมดจริง ๆ ต้องย้ายการคำนวณไปไว้บนเซิร์ฟเวอร์ แต่นั่นอยู่นอกขอบเขตคำขอ
- การแก้ไขเฉพาะหน้าคือทำให้ UI ไม่แสดงสูตรเมื่อคลิกเซลล์
- ในสัปดาห์แรกของเดือนสิงหาคม 2016 Uber China ถูก ขายให้ Didi
- พนักงานจำนวนมากรู้ข่าวจากการแจ้งเตือนข่าวก่อน
- ไม่กี่ชั่วโมงต่อมาจึงมีอีเมลภายในประกาศดีลนี้
- เมื่อ Uber China หายไป UI ดังกล่าวก็ถูกถอดออกจาก Wesley
- มันเป็น UI เฉพาะกิจสำหรับงานข้อมูลที่จะไม่มีวันถูกรันอีก
- ไม่มีคำขอให้สร้าง Excel ขึ้นมาใหม่ในเบราว์เซอร์อีก
การแก้ปัญหามากกว่าอายุของโค้ด
- ตอนนั้นไม่ได้รู้สึกสูญเสียหรือผิดหวังมากนัก
- สิ่งแรกที่คิดคืออยากเผยแพร่โค้ดบน GitHub จากนั้นก็ย้ายไปทำงานถัดไป
- มีความเสียดายเล็กน้อยที่โค้ดซึ่งทุ่มเททำถูกใช้งานช่วงสั้น ๆ แล้วหายไป
- โค้ดที่วิศวกรเขียนสักวันหนึ่งจะกลายเป็น legacy code
- สักวันหนึ่งอาจมีใครบางคนรู้สึกดีใจที่ได้ลบโค้ดนั้นออก
- แม้โค้ดจะทำมาอย่างดี การคงอยู่ยาวนานเองไม่ใช่เป้าหมาย
- การเติบโตในฐานะวิศวกรเชื่อมโยงกับการใช้เทคโนโลยีเพื่อสร้าง คุณค่าทางธุรกิจ ให้ดียิ่งขึ้น
- คุณค่าทางธุรกิจสร้างได้หลายทาง เช่น ผลงานทางเทคนิค การทำงานร่วมกัน การเมนเทอร์ และการสนับสนุนทีม
- หลัง Uber China หายไป ก็ไม่มีคุณค่าทางธุรกิจเหลือให้สร้างต่อจากโปรเจกต์นี้
- การดันทุรังต่อไปไม่ได้ช่วยทั้งตัวบุคคลหรือบริษัท
- วลี DevOps “Cattle, not pets” ใช้กับโค้ดได้เช่นกัน
- โค้ดเป็นเครื่องมือสำหรับทำงาน และเมื่อสิ่งนั้นไม่เป็นประโยชน์อีกต่อไป ก็พร้อมถูกปลดระวาง
- หากปฏิบัติกับโค้ดเหมือนสัตว์เลี้ยงด้วยอารมณ์ ก็จะเดินสวนทางกับความเข้าใจทางธุรกิจ
คำถามที่โปรเจกต์ซึ่งถูกยกเลิกทิ้งไว้
- ไม่จำเป็นต้องมองว่าโปรเจกต์ที่ถูกถอดออกเป็นความล้มเหลวทันที
- งานที่ถูกยกเลิกทิ้งคำถามไว้ดังนี้
- เราสร้างสิ่งที่ไม่ตอบโจทย์ข้อจำกัดของโปรเจกต์หรือไม่
- เราสร้างสิ่งที่ถูกขอมาแล้ว แต่คำขอนั้นผิดตั้งแต่ต้นหรือไม่
- ปัญหาหลักถูกเข้าใจผิดหรือไม่
- โซลูชันที่ถูกขอมาแก้ความต้องการของผู้ใช้ปลายทางจริงหรือไม่
- มีคำถามใดที่ไม่ได้ถามผู้มีส่วนได้ส่วนเสียหรือไม่
- ความคาดหวังไม่ถูกต้องหรือคลุมเครือหรือไม่
- จำเป็นต้องมีความแข็งแรงทนทานถึงระดับที่ส่งมอบไปหรือไม่
- โซลูชันที่ง่ายกว่าหรือฉลาดน้อยกว่านี้เพียงพอแล้วหรือไม่
- กำหนดเกณฑ์ความสำเร็จผิดหรือไม่
- มีเกณฑ์ความสำเร็จอื่นนอกเหนือจาก “สร้างสิ่งที่ถูกขอมา” หรือไม่
- หากมองการจบโปรเจกต์ว่าเป็นเพียงความล้มเหลว ก็จะเสียโอกาสเรียนรู้ว่าปัญหาที่ไม่ใช่เชิงเทคนิคคลาดเคลื่อนไปตรงไหน
- แม้ชิ้นส่วนที่สร้างขึ้นอย่างประณีต ก็อาจถูกถอดออกได้หากไม่ทำงานอย่างราบรื่นในระบบที่ใหญ่กว่า
1 ความคิดเห็น
ความเห็นจาก Hacker News
คำพูดที่เด็ดที่สุดคืออันนี้: “คนที่ทำงานที่ Didi สมัครมาเป็นอินเทิร์น Uber China แล้วขโมยข้อมูลของเราออกไป เราปล่อยให้พวกเขาเห็นสูตรไม่ได้ ไม่อย่างนั้นพวกเขาจะลอกสิ่งที่เราทำไปทั้งดุ้น!”
คำพูดนี้ถูกจริง ๆ คนอเมริกันไม่ค่อยรู้ระดับของ การจารกรรมทางเศรษฐกิจและอุตสาหกรรม ที่เกิดขึ้นทุกวันในจีน ช่วงราวกลางทศวรรษ 2000 ตอนที่ผมไปตอบสนองเหตุละเมิดความปลอดภัยอีกกรณีหนึ่งของบริษัทเทคโนโลยีที่ขอไม่เอ่ยนาม ผมได้ยินว่า “เราเปิดศูนย์เทคโนโลยีในซินเจียง และช่วงหลัง ๆ มีบัตรผ่านหายบ่อยผิดปกติ” พอผมถามว่า “เคยคิดไหมว่านั่นอาจไม่ใช่การทำหาย แต่อาจเป็นการเอาไปขายแลกเงิน” ก็เกิดความเงียบยาว
ไม่รู้ว่าผู้บริหารรู้แต่ไม่สนใจ หรือแค่ไร้ความสามารถ แต่จีนได้ ทำให้การจารกรรมอุตสาหกรรมกลายเป็นผลิตภัณฑ์ในระดับมหาศาล ไปแล้ว ล่าสุด GE Aviation ก็เป็นเหยื่อด้วย: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
จากนั้นก็ตั้งบริษัทในจีน รับเงินลงทุนจากนักลงทุนจีน และทำผลิตภัณฑ์ที่แทบเหมือนเดิมสำหรับตลาดจีน ตัวอย่างเช่นกรณี Thoratec/Abbot Heartmate III กับ CH Biomedical, และ Auris/Verb/J&J Robotic & Digital Solutions กับ Renovo Surgical
ที่น่าขันคือ บริษัทเหล่านี้บางแห่งหลังจากประสบความสำเร็จในจีนแล้ว ก็พยายามขายและแข่งขันในสหรัฐฯ กับยุโรป ตอนนี้มันไม่ใช่ความลับหรือดีลใต้โต๊ะอีกต่อไปแล้ว ในอุตสาหกรรมของเราเรื่องนี้เกิดขึ้นอย่างเปิดเผย และโดยมากก็ถูกยอมรับว่า “มันก็เป็นแบบนั้น”
อีกเรื่องหนึ่งคือ บริษัทต่างชาติที่ทำธุรกิจในจีนปกป้องทรัพย์สินของตัวเองได้ยากมาก ดังนั้นบริษัทที่ฉลาดจึงมักไม่พยายามทำเองโดยตรง แต่จะให้สิทธิ์การใช้งานแก่บริษัทจีนสำหรับตลาดจีนแทน อย่างน้อยก็ยังมีโอกาสที่จะไม่ถูกขโมยไปทั้งหมด
สมัยก่อนเอเจนซีที่ผมทำงานอยู่เคยจ้างนักออกแบบอุตสาหกรรมมาทำเคสสวย ๆ สำหรับฮาร์ดแวร์ iBeacon ผลงานออกมาดีมาก
เราจ้างบริษัทจีนทำงานฉีดขึ้นรูป และตัวอย่างก็ดูดีทีเดียวจึงตัดสินใจใช้ แต่ไม่กี่สัปดาห์ต่อมาก็เห็น เคสของเรา วางขายอยู่บน Alibaba/AliExpress
ไม่ได้หมายความว่าตะวันตกหรือประเทศอื่น ๆ สมบูรณ์แบบ แต่ประเด็นที่พูดอยู่ตอนนี้ไม่ใช่เรื่องนั้น ทุกคนที่ผมรู้จักซึ่งเคยทำงานกับภาคการผลิต/ธุรกิจของจีน ล้วนเจอเรื่องอย่าง “ถูกลอก”, “เอาความพยายามของเราไปขายให้คนอื่น”, หรือ “ส่งมอบ x เกรดต่ำกว่าที่ตกลงกันไว้”
ข้อโต้แย้งก็มักลงเอยว่า “แต่ตะวันตกก็ทำ X เหมือนกัน” หรือ “นั่นเป็นการเหยียดเชื้อชาติ” เสมอ
บริษัทจีน โดยเฉพาะพวกที่ค้าขายบน Ali-X ชอบโครงสร้างนี้มาก เพราะสามารถเอาทรัพย์สินทางปัญญาไปฟรี ๆ แล้วใช้ราคาบีบผู้ผลิตอุปกรณ์ต้นฉบับออกจากตลาดได้ แบบของเหล่าเมกเกอร์ที่ลงไว้ใน Tindie ฯลฯ ก็มักถูกลอกแล้วไปโผล่บน Ali บ่อย ๆ
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
ตอนอ่านบทความนี้ ผมคาดหวังว่าจะได้เห็นเรื่องราวของโค้ดเฉพาะทางที่ซับซ้อนถูกค่อย ๆ รื้อออกและลบทิ้ง แต่ผู้เขียนกลับเติบโตขึ้นเป็นวิศวกรในแบบที่ต่างจากที่คิดไว้
คำคมสาย DevOps ที่ว่า “Cattle, not pets” เหมาะกับกรณีนี้มาก โค้ดและผลิตภัณฑ์ที่สร้างจากโค้ดนั้นไม่ใช่สัตว์เลี้ยง แต่เป็นปศุสัตว์ มันทำงานให้เรา และเมื่อผลงานนั้นไม่เป็นประโยชน์อีกต่อไป มันก็พร้อมจะเกษียณ ถ้าปฏิบัติกับโค้ดเหมือนสัตว์เลี้ยงด้วยเหตุผลทางอารมณ์ ก็เท่ากับทำสิ่งที่สวนทางกับผลประโยชน์ของธุรกิจโดยตรง
โค้ดหลายอย่างเขียนแล้วสนุก และปัญหาหลายอย่างก็แก้แล้วสนุก แต่ธุรกิจ โดยเฉพาะสตาร์ทอัพ ต้องโฟกัสอย่างยิ่งยวด จริง ๆ แล้วอาชีพของผมแทบจะเป็นการนั่งอยู่ในห้องประชุมแล้วบอกวิศวกรหนุ่มสาวที่มีไฟว่า อย่าสร้างมันขึ้นมา ฟังดูหดหู่นิดหน่อย แต่ก็เป็นเรื่องจำเป็น
วิศวกรที่ดีสามารถแก้ปัญหาอะไรก็ได้ด้วยโค้ดที่ชาญฉลาด วิศวกรที่ยอดเยี่ยมเข้าใจว่าบางปัญหาแท้จริงแล้วไม่ใช่ปัญหา และบางทีแค่ ลิงก์ดาวน์โหลด XLS ที่อัปเดตทุกวันก็อาจเพียงพอแล้ว
ตอนนั้นผมกำลังสร้างระบบมอนิเตอร์สำหรับบริการที่โฮสต์ภายในบริษัท แล้วหัวหน้าต้องการซื้อยูทิลิตีเล็ก ๆ ที่ใช้เฝ้าดูส่วนเล็กน้อยบางอย่างในสภาพแวดล้อมของเรา ผมรู้สึกขัดใจเล็กน้อยที่เขาจะจ่ายเงินซื้อ ทั้งที่ผมก็สร้างเองได้
หัวหน้าถามว่า “ถ้าจะเขียนและทดสอบของนี้ต้องใช้เวลานานเท่าไร?” ผมตอบว่า “น่าจะหนึ่งสัปดาห์ ถ้าเจออะไรยาก ๆ ก็อาจนานกว่านั้นนิดหน่อย” เขาจึงถามว่า “เครื่องมือนั้นราคา 500 ดอลลาร์ แล้วค่าแรง 40 ชั่วโมงของนายเท่าไร?”
ตอนนั้นผมถึงบางอ้อ และหลังจากนั้นก็ไม่เคยสร้างเองในบริษัทอีกเลย ถ้าบริษัทสามารถซื้อได้ถูกกว่า
เช็กลิสต์ท้ายหน้า Substack ก็ยังไม่พอสำหรับ การทำความเข้าใจความต้องการ ในระดับนี้ คำถามเหล่านั้นแค่บรรยายสถานการณ์เท่านั้น และต่อให้ถามไปก็ไม่ได้ทำให้ไปถึงวิธีแก้ที่เรียบง่ายนี้ได้ แนวคิดแบบเช็กลิสต์เป็นเหมือนไม้ค้ำ และทำให้ปัญหาซับซ้อนเกินจำเป็น
สัญญาณสำคัญทั้งหมดในกรณีนี้เป็นเรื่องเชิงองค์กรและสังคม ไม่ใช่ปัญหาที่แก้ได้ด้วยการปรับปรุงกระบวนการ คนที่ไม่ได้เกี่ยวข้องกับรายละเอียดการใช้งานจริงย่อมตอบคำถามเกี่ยวกับรายละเอียดการใช้งานจริงไม่ได้
คำว่า “แค่ทำให้เหมือน Excel ก็พอ” เป็นคำตอบคุณภาพต่ำจากคนที่มีเป้าหมายต่างออกไปโดยสิ้นเชิง ควรไปปรึกษาคนที่ใกล้ชิดกับผู้ใช้จริงมากกว่า แล้วสร้างข้อโต้แย้งจากตรงนั้น สิ่งที่ขาดไปคือความสามารถในการมองเห็นสมมติฐานที่อ่อนแอ และความกล้าที่จะตั้งใจไม่เขียนโค้ดจนกว่ารายละเอียดจะชัดเจนพอให้ทุกฝ่ายเห็นพ้องกันได้ ไม่ควรแค่ตอบตกลงกับ “คนรับผิดชอบ” ไปเฉย ๆ
ในปี 2006 ผมก็เคยคุยยาวเพื่อพยายามโน้มน้าวใครบางคนไม่ให้เดินไปทางนั้น และในปี 2026 ก็ยังจะมีใครบางคนพยายามทำแบบนั้นอีก
ความสามารถในการหยุดคิดว่า “คนอื่นแก้ปัญหาแบบเดียวกันนี้กันอย่างไร?” เป็นส่วนสำคัญมากของการเติบโตเป็นนักพัฒนา เลยอยากให้โรงเรียนให้ความสำคัญกับเรื่องนี้มากกว่านี้
แค่มีคำอธิบายว่าทำเสร็จทันเวลาและสำเร็จภายในเดดไลน์สั้น ๆ ไม่พอจะสรุปได้ว่าการเลือกวิธี implement นั้นแย่ กลับกันคือมันประสบความสำเร็จเกินไปจน implement ฟีเจอร์ของ Excel มากเกินไป และภายหลังก็แก้ด้วยการลบมันออก แล้วถ้าเป็นลิงก์ดาวน์โหลด XLS จะลบสิ่งนั้นออกได้อย่างไร?
ประเด็นหลักคือ อย่ายึดติดกับโค้ดมากเกินไป และในบางสถานการณ์อาจหมายถึง “อย่าสร้างเอง ใช้ลิงก์ดาวน์โหลด XLS ไป” แต่เรื่องไม่ได้มีแค่นั้น
ส่วนที่ว่า “ไม่มีอะไรเกิดขึ้น แต่ผมเก็บโค้ดนั้นไว้เผื่อวันหนึ่งจะได้ใช้ ความคิดของผมคือเอาโค้ดนี้มาปรับแต่งให้เหมาะกับการใช้งานของ Uber” และ “ปฏิกิริยาแรกของผมคือเผยแพร่โค้ดบน GitHub” ทำให้ประหลาดใจมาก
โค้ดนั้นไม่ได้เป็นทรัพย์สินของ Box หรือ Uber หรือ? ผู้เขียนไม่ได้พูดถึงว่าได้รับอนุญาตก่อนเผยแพร่ภายใต้ สัญญาอนุญาต MIT
ถ้า Uber ต้องการ JavaScript หลายพันบรรทัดที่ไม่ได้มาจากพวกเขาเอง ผ่านไปกว่าครึ่งปีแล้ว และถูกใช้ไม่ถึงหนึ่งเดือน ก็ส่งจดหมายมาได้เลย
ประโยคที่ว่า “เขาแทบไม่เชื่อเลยว่าผมเขียนเอนจินสเปรดชีตทั้งตัวที่รันในเบราว์เซอร์ขึ้นมาเอง” ผมก็เชื่อยากเหมือนกัน และไม่ได้หมายในทางที่ดี
ถ้าใช้ Apache POI ก็รัน Excel แบบ headless ได้ สามารถดึงชีตใน Java แล้วโต้ตอบกับมันแบบโปรแกรมได้ ที่ทำงานเก่าผมก็เคยใช้ด้วยเหตุผลเดียวกันเป๊ะ ฟังก์ชัน การอ้างอิงเซลล์ และอื่น ๆ ทำงานได้ดีทั้งหมด
เขาแค่โชคดีที่เจอปัญหา ‘circ’ แล้วความแปลกเล็ก ๆ ที่ซ่อนอยู่ใน Excel ซึ่งจะเจอต่อไปในอนาคตล่ะ จะทำยังไง? จะสร้างและดูแลสำเนา Excel แบบสมบูรณ์ด้วย JS จริง ๆ เหรอ? นั่นใช่เป้าหมายของทีม frontend จริงหรือ?
ถ้าค้นหานิดเดียว ผมว่าคงเลี่ยงงานได้ มากกว่า 90% ตรงนี้ แถมทีม backend อาจรับไปทำได้ด้วย
Uber รันดาต้าเซ็นเตอร์ของตัวเองอยู่ การจะจัดหาเครื่อง Windows หรือ VM เพื่อรัน Excel จริง ๆ คงต้องอาศัยปาฏิหาริย์ ผมสามารถเปิดบริการ frontend ใหม่ได้ในราว 30 นาที และก็มีโค้ดบางส่วนที่รันอยู่แล้วระดับหนึ่ง จึงไม่ได้เริ่มจากศูนย์ทั้งหมด ต้องคำนึงด้วยว่าระบบนี้ต้องให้หลายคนที่มีชุดข้อมูลต่างกันใช้งานพร้อมกัน
ถ้าพวกเขายังขอฟีเจอร์เพิ่มและความเทียบเท่า Excel มากขึ้นเรื่อย ๆ ผมก็คงพิจารณา แต่ไม่ได้เป็นแบบนั้น
ผมไม่ได้คาดหวังว่าหลายคนจะเลือกแบบที่ผมเลือก แต่มันทำงานได้ และทำงานได้ดีอย่างน่าประหลาด ถ้าสิ่งเดียวที่คุณได้จากบทความคือ “มันเป็นโปรเจกต์ใหญ่และซับซ้อน” ก็แปลว่าบทความสื่อสารข้อความที่ผมตั้งใจจะสื่อได้ไม่ดีพอ
ถ้าเป็นผมคงซักไซ้สเปก UI ให้มากขึ้น และผลักดันให้รัน Excel อยู่ด้านหลัง แต่ถ้ามีการป้อนตัวเลขเยอะ ๆ กระจายอยู่หลายจุด มันก็เป็น UI ที่คุ้นเคยจริง ๆ
ผมอ่านบทความนี้เรื่องสร้างสเปรดชีตด้วย F# 100 บรรทัดแล้วสนุกอยู่เสมอ: https://tomasp.net/blog/2018/write-your-own-excel/ การขยายไปยังชุดฟีเจอร์ที่ต้องใช้ตรงนี้ยังอยู่ในระดับที่รับมือได้
สุดท้ายก็สร้างสำเนา “Excel” ทำเองเป็น UI ของโมเดล เหตุผลคือ “ทีมเมืองใช้เป็นแต่ Excel”
ถ้าเป็นผมจะทำกลับกัน ผมจะเชื่อม Excel เข้ากับข้อมูลที่โมเดลส่งออกมา เพื่อให้ทีมเมืองยังใช้ Excel จริงต่อไปได้ ดูเหมือนทีมการเงินส่วนใหญ่ก็ทำกันแบบนี้
เอกสารเรื่อง circular reference ของ Excel สำหรับคนที่สนใจ: https://support.microsoft.com/en-us/office/remove-or-allow-a...
ถ้าคุณไม่คุ้นกับการคำนวณแบบวนซ้ำ ก็มีโอกาสสูงที่คุณจะไม่อยากปล่อย circular reference ไว้แบบนั้น คุณเปิดการคำนวณแบบวนซ้ำได้ แต่ต้องกำหนดว่าจะให้คำนวณสูตรซ้ำกี่ครั้ง ถ้าเปิดการคำนวณแบบวนซ้ำโดยไม่เปลี่ยนจำนวนรอบสูงสุดหรือค่าการเปลี่ยนแปลงสูงสุด Excel จะหยุดคำนวณเมื่อวนครบ 100 ครั้ง หรือเมื่อการเปลี่ยนแปลงของค่าทั้งหมดใน circular reference ระหว่างรอบต่ำกว่า 0.001 แล้วแต่ว่าอย่างไหนจะมาถึงก่อน อย่างไรก็ตาม คุณสามารถควบคุมจำนวนรอบสูงสุดและปริมาณการเปลี่ยนแปลงที่ยอมรับได้
สงสัยว่าผู้เขียนจะมองสถานการณ์นี้ต่างออกไปไหม ถ้า Uber หรือ Box อ้างว่าโค้ดนั้นเป็นของพวกเขาเอง ถึงโค้ดจะไม่ได้แสดงศักยภาพที่แท้จริงออกมา แต่อย่างน้อยการที่คนทั้งโลกได้เห็นและยอมรับก็น่าจะให้ความรู้สึกปลดปล่อยได้ในระดับหนึ่ง
ตอนทำงานเป็นอินเทิร์น ผมเคยสร้าง ภาษาโปรแกรมทั้งภาษา ขึ้นมา มันเป็นแบบ lazy evaluation มี garbage collection และยังมีความประหลาดเฉพาะแอปพลิเคชัน เช่น MAC address ที่ไม่ต้องใส่เครื่องหมายคำพูดก็เป็นไวยากรณ์ที่ถูกต้อง
ไม่มีอะไรอย่าง bytecode หรือ JIT ตัว interpreter แค่เดินผ่าน syntax tree แล้ว push/pop ค่าบน stack แต่สำหรับงานที่เราทำมันเร็วพอแล้ว ตัว interpreter เขียนด้วย ANSI C ล้วน ๆ และ Valgrind ก็พอใจกับมันมาก
มันอาจถูกลืมไปโดยสมบูรณ์แล้วก็ได้ หรืออาจกลายเป็นแกนหลักของโครงสร้างพื้นฐานด้านเทคโนโลยีของบริษัทนั้นก็ได้ โค้ดนั้นไม่เคยออกนอกแล็บแบบ air-gapped ที่ผมเขียนมันขึ้นมา เลยไม่มีทางรู้ ตอนเพิ่งจบมหาวิทยาลัยเมื่อ 3 ปีก่อน มันเป็น “ซอฟต์แวร์ที่มีประโยชน์จริง” ที่เจ๋งที่สุดเท่าที่ผมเคยเขียนมาอย่างไม่ต้องสงสัย และตอนนี้ก็ยังติดอันดับต้น ๆ อยู่ บางครั้งก็สงสัยว่ามันลงเอยอย่างไร
ผู้เขียนดูเหมือนจะเข้าใจผิดว่าการถามผู้จัดการระดับกลาง หรือแม้แต่ผู้จัดการระดับสูงว่า “อยากได้สิ่งนี้ไหม?” แล้วผู้จัดการตอบว่า “ไม่” จะมีผลผูกพันทางกฎหมายต่อบริษัท
ประโยคที่ว่า “มันง่ายที่จะปฏิบัติกับโค้ดที่ฉลาดหรือสง่างามเป็นพิเศษราวกับเป็นผลงานชิ้นเอก จริง ๆ แล้วมันอาจเป็นของประดับที่สวยงามก็ได้ แต่พวกเรา วิศวกร ไม่ได้อยู่ในธุรกิจสร้างของประดับสวยงาม เราอยู่ในธุรกิจสร้าง ผลลัพธ์” โดนใจมาก
แต่ใครก็ตามที่เคยเห็นโค้ดของผมจะรู้ว่า ผมก็อยากให้ทั้งโค้ดและฟังก์ชันของมันดูสวยมากเหมือนกัน โดยทั่วไปเพราะผมเขียนโค้ดที่ตัวเองต้องดูแลต่อ จึงต้องยังเข้าใจได้เมื่อกลับมาดูอีกครั้งในอีก 1 ปีต่อมา
ตอนนี้ผมอยู่ช่วงท้ายของโปรเจกต์หนึ่งที่คงไม่ได้เอามาประกาศที่นี่ และไม่ได้คิดจะเอาหน้าอะไรมาก แต่มันเป็นของที่เจ๋งสุด ๆ เหตุผลที่มันเป็นแบบนั้นก็เพราะไม่มีใครจ่ายเงินให้ และไม่มีใครหาเงินจากมัน
เงินทำให้ทุกอย่างพังได้ และในขณะเดียวกันก็ทำให้ทุกอย่างเป็นไปได้เช่นกัน
เป็นบทความที่ยอดเยี่ยมจริง ๆ จากมุมมองของทีม BI ของ Uber ในอดีต ผมอยู่ในทีม Vertica ช่วงนั้น และปริมาณความพยายามที่ทุ่มลงไปกับ incentives นั้นมากจนชวนมึนหัว ประเด็นที่เงินหลายล้านดอลลาร์ต่อวันหายไปกับ downtime, ฟีเจอร์ของผลิตภัณฑ์ และ bandwidth ด้านวิศวกรรม เป็นเรื่องที่พูดถึงกันบ่อย
โดยเฉพาะในยุค Uber China การที่ director ต้องการ spreadsheet เป็น UI อย่างชัดเจนก็คงเป็นเรื่องธรรมชาติมาก ผมเองก็เคยโหลดราคา FX จาก spreadsheet ที่ส่งอีเมลมาหาทีมทุกเดือนเข้า Vertica เป็นการส่วนตัว เพราะไม่มี bandwidth พอจะกลับทิศทาง control flow ด้วยการเก็บข้อมูลอัตโนมัติ กระบวนการนั้นจึงค้างอยู่นานกว่า 1 ปี
คำพูดที่ว่า “จนถึงตอนนี้ ผมยังไม่เคยเห็นระบบแอปพลิเคชันภายในของบริษัทไหนที่ออกแบบมาดีเท่าของ Uber เลย ตั้งแต่เริ่มต้นจนถึงการรัน Hello World บนซับโดเมน *.uberinternal.com ผ่าน CI/CD เต็มรูปแบบ ใช้เวลาไม่ถึง 30 นาที” ทำให้ใจอุ่นขึ้นเล็กน้อย
ตอนนั้นผมมีส่วนเกี่ยวข้องกับเรื่องทั้งหมดนี้ที่ Uber