ฟีเจอร์แรกที่ผมสร้าง ไม่ได้ทำเพื่อผู้ใช้ทั่วไป — แต่ทำเพื่อลานซากรถ
U-PRO Build Journal — ตอนที่ 3
ตอนที่ 2 จบลงด้วยคำถามที่ผมไม่คิดว่าจะต้องถามตัวเองทันทีหลังทำ multi-tenant database migration เสร็จ: ตอนนี้ฐานรากวางเรียบร้อยแล้ว จริงๆ แล้วผมจะสร้างอะไรทับลงไปเป็นอย่างแรก?
ผมเคยคิดเอาไว้ว่าคำตอบน่าจะเป็นอะไรที่ชัดเจนอยู่แล้ว U-PRO เป็นระบบหน้าร้านสำหรับอู่ซ่อมรถ ก้าวแรกที่ควรจะเป็น เป็นสิ่งที่เครื่องมือจัดการสต็อกทั่วไปทำกันหมดแล้ว น่าจะเป็นอะไรทำนอง "แสดงรายการอะไหล่ ค้นหาอะไหล่ นับว่าเหลือเท่าไหร่" ปลอดภัย เป็นไปตามคาด เป็นฟีเจอร์แบบที่ไม่มีใครถามว่า "เอ๊ะ ทำไมถึงสร้างอันนี้ก่อน"
แต่นั่นไม่ใช่สิ่งที่ผมสร้าง ฟีเจอร์ใหญ่ตัวแรกที่ผมปล่อยออกมาหลังฐาน multi-tenant พร้อมแล้ว กลับเป็นเรื่องของธุรกิจกลุ่มแคบมากๆ กลุ่มหนึ่ง นั่นคือการรับซากรถเข้าระบบ (salvage vehicle intake) พร้อมวิธีคำนวณเฉพาะว่าอะไหล่แต่ละชิ้นที่ถอดออกมาจากรถที่พังยับนั้น จริงๆ แล้วมีมูลค่าเท่าไหร่ ถ้าไม่ได้อยู่ในวงการนี้ ฟังดูอาจเป็นจุดเริ่มต้นที่แคบแปลกๆ ก็จริง แต่เหตุผลที่ผมเริ่มจากตรงนั้น บอกอะไรบางอย่างเกี่ยวกับว่าใครคือคนกลุ่มแรกที่มาลองใช้เครื่องมือใหม่จริงๆ ได้มากกว่าที่งานวิจัยตลาดจะบอกผมได้เองล้วนๆ
ปัญหาที่ไม่มีใครแก้ให้
ลานซากรถ (salvage yard) หรืออู่ซ่อมที่ขายอะไหล่มือสองด้วย ไม่ได้ซื้อสต็อกแบบเดียวกับร้านขายอะไหล่ทั่วไป ร้านขายอะไหล่ซื้อของเป็นชิ้นๆ แยกรายการ — น็อตตัวนี้ราคาเท่านี้ ไส้กรองตัวนี้ราคาเท่านี้ แต่ละการซื้อมีป้ายราคาของตัวเองชัดเจน ส่วนธุรกิจซากรถซื้อรถทั้งคันที่พังยับ ปกติจ่ายเป็นก้อนเดียวเบ็ดเสร็จ แล้วต้องเอาตัวเลขก้อนนั้นมาแยกออกเป็นชิ้นส่วนหลายสิบหรือหลายร้อยชิ้น — ไดชาร์จ ชุดประตู เกียร์ที่ยังใช้งานได้ กระจกหน้ารถ — แต่ละชิ้นสุดท้ายจะถูกขายแยกกัน ในราคาของตัวเอง เมื่อมีคนต้องการอะไหล่ชิ้นนั้นพอดี
ตรงนี้เองที่สร้างปัญหาบัญชีที่อึดอัดจริงๆ ซึ่งซอฟต์แวร์จัดการสต็อกส่วนใหญ่ไม่แตะเลย: ถ้าจ่ายเงินก้อนเดียวซื้อรถทั้งคัน แล้วอะไหล่แต่ละชิ้นข้างในนั้นจริงๆ แล้วมีต้นทุนเท่าไหร่? จะเดาส่งๆ ก็ไม่ได้ จะบันทึกว่า "ฟรี" หรือ "ต้นทุนศูนย์" กับทุกชิ้นยกเว้นชิ้นแรกที่ขายไปก็ไม่ได้ เพราะทางลัดแบบนั้นจะค่อยๆ ทำลายความแม่นยำของกำไรทันทีที่ลองดูกำไรจริงต่อชิ้น ต้องมีวิธีปันส่วนราคาซื้อหนึ่งก้อนไปยังผลผลิตหลายชิ้นที่มีมูลค่าต่างกันลิบลับ อย่างมีเหตุผลรองรับได้จริง — เครื่องยนต์กับกระจกมองข้างที่ร้าว ไม่ได้มีต้นทุนได้มาเท่ากัน ทั้งที่มาจากการซื้อครั้งเดียวกัน
นี่คือปัญหาที่วงการบัญชีแก้ไว้แล้ว — เป็นคำถามประเภทเดียวกับที่บริษัทต้องเจอเวลากระบวนการผลิตหนึ่งกระบวนการ ผลิตสินค้าหลายชนิดออกมาจากวัตถุดิบชุดเดียวกัน แล้วต้องตัดสินใจว่าต้นทุนร่วมนั้นควรแบ่งให้สินค้าแต่ละชนิดเท่าไหร่ แต่มันไม่ใช่ปัญหาที่ซอฟต์แวร์จัดการสต็อกทั่วไปสนใจแก้ เพราะธุรกิจส่วนใหญ่ที่ซื้อซอฟต์แวร์แบบนั้นไม่มีปัญหานี้ ร้านขายอะไหล่รถทั่วไปซื้อของเป็นชิ้นในราคาแยกกัน ไม่มีเหตุผลต้องถามว่า "จะแบ่งการซื้อครั้งเดียวนี้ออกเป็นห้าสิบฐานต้นทุนได้ยังไง" แต่ลานซากรถถามคำถามนี้อยู่ตลอดเวลา และเท่าที่ผมหาดู ไม่มีใครที่ทำซอฟต์แวร์สำหรับวงการนี้ สร้างคำตอบจริงๆ ให้กับมันเลย ช่องว่างตรงนี้แหละที่ฟีเจอร์ใหญ่ตัวแรกของ U-PRO ไปจับ
ฟีเจอร์นี้ทำอะไรจริงๆ
กลไกที่ผมสร้างขึ้นมาในที่สุด เป็นเวอร์ชันหนึ่งของสิ่งที่เรียกกันอย่างเป็นทางการว่า วิธีปันส่วนต้นทุนตามมูลค่าขายสัมพัทธ์ (relative sales value method) — วิธีทางบัญชีสำหรับแบ่งต้นทุนร่วมหนึ่งก้อนไปยังผลผลิตหลายชิ้น โดยอิงจากว่าแต่ละชิ้นมีมูลค่าเทียบกับชิ้นอื่นมากแค่ไหน ไม่ใช่แบ่งเท่าๆ กันแบบสุ่มๆ การปันส่วนเดินตามมูลค่า ไม่ใช่การเดา และไม่ใช่การแบ่งเท่ากันที่จะให้เครื่องยนต์กับกระจกมองข้างมีต้นทุนได้มาเท่ากันอย่างไม่สมเหตุสมผล เพียงเพราะมันมาจากรถคันเดียวกัน
การสร้าง logic นี้ให้ถูกต้อง ไม่ใช่แค่เขียนสูตรคำนวณครั้งเดียวแล้วจบ การรับซากรถของจริงไม่ได้เป็นไปตามตัวอย่างสวยๆ ในตำรา รถที่เข้ามาแล้วถูกลงบัญชีครบทุกชิ้นในคราวเดียว ระบุอะไหล่ที่ขายได้ครบตั้งแต่แรกโดยไม่ต้องจัดหมวดใหม่ทีหลังเลย เป็นข้อยกเว้นมากกว่าจะเป็นเรื่องปกติ ฟีเจอร์นี้ต้องรองรับกระบวนการเวอร์ชันที่ยุ่งเหยิงกว่า สมจริงกว่านั้น ไม่ใช่แค่เวอร์ชันเรียบร้อยที่ดูดีตอน demo
ทำให้การแบ่งสัดส่วนจับต้องได้
ลองไล่ดูตัวเลขจริงสักตัวจะช่วยให้เห็นภาพ เพราะคำว่า "วิธีปันส่วนต้นทุนตามมูลค่าขายสัมพัทธ์" ฟังดูนามธรรมกว่าแนวคิดจริงๆ ของมันมาก สมมติว่าอะไหล่ทั้งหมดจากรถคันที่พังยับ รวมมูลค่าที่ขายได้ 100 หน่วย หลังลงบัญชีและตั้งราคาครบแล้ว เครื่องยนต์ตัวเดียวอาจคิดเป็น 40 จาก 100 หน่วยนั้น เกียร์กับชุดแผงตัวถังรวมกันเป็นส่วนใหญ่ของที่เหลือ ส่วนของกระจุกกระจิกมูลค่าต่ำอีกหลายสิบชิ้น — ชิ้นส่วนตกแต่ง เซนเซอร์เล็กๆ กระจกมองข้างที่ร้าว — รวมกันเป็นส่วนที่เหลือ ชิ้นละเสี้ยวเปอร์เซ็นต์ ไม่ว่าอะไหล่ชิ้นไหนจะมีสัดส่วนเท่าไหร่ในมูลค่ารวมนั้น ก็จะรับต้นทุนซื้อในสัดส่วนเดียวกัน: เครื่องยนต์แบกต้นทุน 40% กระจกมองข้างที่ร้าวแบกแทบจะไม่มีเลย
ส่วนที่ทำให้สร้างยากจริงๆ ไม่ใช่เลขคณิต — การแบ่งตัวเลขหนึ่งก้อนตามสัดส่วนไปหลายชิ้น ไม่ได้ยากอะไรในตัวมันเอง คำถามที่ยากกว่าคือจะจัดการยังไงกับความจริงที่ว่าบันทึกการรับซากรถแทบไม่เคยนิ่งตั้งแต่ตอนสร้างขึ้นมา อะไหล่ชิ้นหนึ่งถูกทำเครื่องหมายว่าขายไม่ได้ หลังมีคนตรวจดูใกล้ๆ แล้วเจอความเสียหายที่มองไม่เห็นตอนรับเข้า อะไหล่อีกชิ้นถูกเพิ่มเข้าบันทึกอีกหลายวันถัดมา หลังมีคนมีเวลากลับไปไล่ดูรถคันนั้นเป็นรอบที่สอง แล้วลงบัญชีสิ่งที่พลาดไปในรอบแรก คำตอบที่ดูตรงไปตรงมาที่สุดคือคำนวณสัดส่วนของอะไหล่ชิ้นอื่นทุกชิ้นใหม่ทุกครั้งที่รายการเปลี่ยน เพราะ "มูลค่าขายรวม" ที่ใช้เป็นฐานแบ่งสัดส่วนเพิ่งขยับไป แต่ผมตั้งใจไม่สร้างมันแบบนั้น มูลค่าประเมินรวมของรถแต่ละคันจะถูกล็อกไว้ทันทีที่เริ่มถอดชิ้นแรกจริง — แก้ย้อนหลังไม่ได้อีกเลย ไม่ว่าจะมีอะไหล่ถูกเพิ่มหรือจัดหมวดใหม่อีกกี่ชิ้นในภายหลัง ต้นทุนของอะไหล่แต่ละชิ้นถูกคำนวณแค่ครั้งเดียว โดยอิงกับมูลค่ารวมที่ล็อกไว้แล้วนั้น ณ ตอนที่ลงบัญชีชิ้นนั้น ส่วนต่างที่เกิดขึ้นระหว่างมูลค่าประเมินที่ล็อกไว้กับความจริงที่ยุ่งเหยิงกว่านั้นของการถอดรถจริง — อะไหล่ที่สุดท้ายกลายเป็นไม่มีค่าเลย ชิ้นที่ไม่มีใครคาดไว้ตอนรับเข้า หรือแค่ความคลาดเคลื่อนจากการปัดเศษธรรมดา — จะไม่มีวันถูกดึงกลับไปกระจายลงอะไหล่ที่ตั้งราคาไปแล้ว (และอาจขายไปแล้วด้วยซ้ำ) ก่อนหน้านั้น มันจะถูกดูดซับไปที่รายการสุดท้ายของคันนั้น คือมูลค่าเศษเหล็ก ตอนที่ปิดคันนั้นในที่สุด นั่นแหละคือจุดที่ความพยายามทางวิศวกรรมจริงๆ ถูกทุ่มลงไป — ไม่ใช่การเขียน loop คำนวณใหม่ แต่คือการออกแบบระบบที่ไม่มีอะไรที่ตั้งราคาไปแล้วต้องถูกเปิดกลับมาแก้อีก ในขณะที่ตัวเลขบัญชีโดยรวมยังลงตัวพอดีกับราคาที่ซื้อมาทั้งคันเสมอในท้ายที่สุด
ทำไมผมถึงสร้างสิ่งนี้ก่อนของที่ชัดเจนกว่า
ผมอยากพูดตรงๆ เรื่องลำดับการทำงานตรงนี้ เพราะบนกระดาษมันดูเหมือนการจัดลำดับความสำคัญที่แปลกๆ การติดตามสต็อกทั่วไป — ค้นหา นับจำนวน แจ้งเตือนของใกล้หมด — คือฟีเจอร์ที่ลูกค้าที่คาดหวังเกือบทุกคนจะรู้จักและคาดหวังทันที ส่วนการปันส่วนต้นทุนซากรถ เป็นฟีเจอร์ที่มีความหมายกับตลาดกลุ่มแคบเฉพาะกลุ่มหนึ่งเท่านั้น และสร้างให้ถูกต้องได้ยากกว่าการติดตามสต็อกพื้นฐานจริงๆ
ผมก็ยังสร้างมันก่อนอยู่ดี ด้วยเหตุผลที่ไม่ค่อยเกี่ยวกับทฤษฎีการวางแผนฟีเจอร์ แต่เกี่ยวกับสิ่งที่ผลิตภัณฑ์ระยะแรกสุด ก่อนเปิดตัวจริงๆ ต้องการมากกว่า นั่นคือ เหตุผลในการมีอยู่ที่คู่แข่งทั่วไปเลียนแบบได้ไม่ง่าย การติดตามสต็อกพื้นฐานคือของที่ต้องมีขั้นต่ำ ซอฟต์แวร์บริหารอู่ทุกตัวทำเวอร์ชันใดเวอร์ชันหนึ่งของมันอยู่แล้ว การสร้างเวอร์ชันที่ดีกว่านิดหน่อยของสิ่งที่มีอยู่แล้ว ไม่ใช่เหตุผลที่หนักแน่นพอให้เจ้าของอู่ที่ยังลังเลตัดสินใจเปลี่ยนเครื่องมือกลางปี ในขณะที่วิธีคิดต้นทุนอะไหล่ซากรถที่ถูกต้องตามหลักบัญชี มีเหตุผลรองรับได้จริง เป็นสิ่งที่ผมหาไม่เจอที่ไหนเลยในตลาดนี้ตอนที่ลองมอง มันเป็นกลุ่มเป้าหมายที่แคบกว่ามาก แต่เป็นกลุ่มที่มีปัญหาจริง เฉพาะเจาะจง และยังไม่มีใครแก้ ณ ตอนนั้น การแก้มันก่อนทำให้ U-PRO มีอะไรชี้ให้เห็นได้ ที่ไม่ใช่แค่ "เราก็ทำสิ่งที่คนอื่นทำเหมือนกัน แค่ดีกว่านิดหน่อย"
มีแนวคิดการทำผลิตภัณฑ์ช่วงต้นแบบหนึ่งที่บอกว่า ควรสร้างเพื่อกลุ่มเป้าหมายที่ใหญ่ที่สุดที่เข้าถึงได้ก่อนเสมอ เพราะนั่นคือที่มาของการเติบโต ผมคิดว่าคำแนะนำนั้นถูกต้องสำหรับผลิตภัณฑ์ที่มีฐานความไว้วางใจและผู้ใช้อยู่แล้วในระดับหนึ่งให้ต่อยอด แต่มันถูกต้องน้อยลงสำหรับผลิตภัณฑ์ที่ไม่มีลูกค้าเลยสักคนและไม่มีชื่อเสียงเลย ซึ่งคำถามที่เร่งด่วนกว่าไม่ใช่ "จะเข้าถึงคนให้ได้มากที่สุดยังไง" แต่เป็น "จะโชว์อะไรให้ลูกค้ารายแรกที่ยังลังเลได้เห็น ที่เขาหาไม่ได้จากที่ไหนอื่นเลย"
ราคาที่ต้องจ่ายจากการทำแบบนี้
ไม่มีอะไรได้มาฟรีๆ และผมไม่อยากเล่าราวกับว่าการจัดลำดับให้ฟีเจอร์ที่ยากกว่าแคบกว่านี้ เป็นการตัดสินใจที่ถูกต้องชัดเจนแบบไม่มีข้อเสียเลย มันใช้เวลาจริงๆ เวลาที่ roadmap แบบทั่วไปกว่านี้จะใช้ไปกับฟีเจอร์ที่ลูกค้าทุกคนจะแตะตั้งแต่วันแรก อย่างการค้นหาพื้นฐานและการนับสต็อก ทุกสัปดาห์ที่ใช้ไปกับ logic บัญชีสำหรับการปันส่วนซากรถ คือสัปดาห์ที่ฟีเจอร์ที่มีประโยชน์กับทุกคนมากกว่ายังไม่ถูกสร้าง
ผมเลือกแลกแบบนี้อย่างรู้ตัว หมายความว่าช่วงหนึ่ง U-PRO เป็นผลิตภัณฑ์ที่ทำเรื่องแคบๆ เรื่องเดียวได้ดีมาก แต่เรื่องธรรมดาทั่วไปอีกมากมายยังไม่ได้ทำเลย เป็นจุดที่แปลกและเอียงข้างในช่วงสัปดาห์แรกๆ หลังฐานสถาปัตยกรรมพร้อมในที่สุด เป็นความไม่สมดุลแบบที่จะสมเหตุสมผลก็ต่อเมื่อมั่นใจว่าเรื่องแคบนั้นมีค่าทางกลยุทธ์มากกว่าความกว้างในช่วงเวลานั้นพอดี ผมมั่นใจ แต่ความมั่นใจไม่ใช่ความแน่นอน สิ่งที่ผมมีคือการพนันว่าลูกค้ากลุ่มแรกจำนวนน้อยที่เรื่องมากและมีปัญหาจริงที่ยังไม่มีใครดูแล จะสำคัญกว่าในช่วงต้นแบบนี้ มากกว่าเวอร์ชันที่ดีกว่านิดหน่อยของฟีเจอร์ที่คู่แข่งทุกรายมีอยู่แล้ว
การแลกแบบเดียวกันนี้ — ลึกแทนกว้าง แคบและยากแทนกว้างและง่าย — เป็นสิ่งที่ผมต้องกลับมาเจออีกมากกว่าหนึ่งครั้งขณะผลิตภัณฑ์เติบโตขึ้น ไม่ได้มั่นใจเท่าครั้งแรกเสมอไป ฟีเจอร์ซากรถคุ้มค่ากับตัวเองในแง่ที่ให้เหตุผลในการมีอยู่จริงกับผลิตภัณฑ์ แต่ก็หมายความว่าทุกอย่างที่เหลือช้ากว่าที่ควรจะเป็น และการแลกนั้นกำลังจะกลายเป็นสิ่งที่เพิกเฉยไม่ได้อีกต่อไป
สิ่งที่ผมจะบอกเจ้าของอู่ที่ถามว่า "เรื่องนี้เกี่ยวอะไรกับผม"
ถ้าไม่ได้ทำธุรกิจซากรถ เรื่องทั้งหมดนี้อาจฟังดูไม่เกี่ยวกับคุณเลย และสำหรับการใช้งาน U-PRO แบบพื้นฐาน มันก็ไม่จำเป็นต้องเกี่ยวจริงๆ แต่ผมคิดว่าเหตุผลที่ฟีเจอร์นี้มาก่อน บอกอะไรบางอย่างที่ควรรู้ไว้ แม้จะไม่เคยแตะหน้าจอปันส่วนซากรถเองเลยก็ตาม มันบอกว่าผลิตภัณฑ์นี้ถูกสร้างมาเพื่อแก้ปัญหาแบบไหนจริงๆ เทียบกับปัญหาแบบที่แค่ทำให้ครบ checklist
เครื่องมือจัดการสต็อกไหนๆ ก็บอกได้ว่าของเหลือน้อย แต่มีน้อยตัวมากที่บอกได้อย่างถูกต้องว่าอะไหล่แต่ละชิ้นที่นอนอยู่ในคลังมีต้นทุนได้มาจริงๆ เท่าไหร่ เมื่อคำตอบที่ตรงไปตรงมาต้องใช้ logic บัญชีจริงๆ แทนที่จะเป็นตัวเลขหลอกๆ ที่ใส่ไว้ชั่วคราว นั่นเป็นรายละเอียดเล็กๆ ที่เจ้าของอู่ส่วนใหญ่จะไม่มองตรงๆ เลย แต่ก็เป็นรายละเอียดแบบเดียวกันเป๊ะที่ตัดสินว่าตัวเลขกำไรต่องานที่ระบบนี้จะโชว์ให้ดูในที่สุด เป็นตัวเลขที่เชื่อได้จริง หรือเป็นตัวเลขที่ดูสมเหตุสมผลแต่แอบสมมติว่าอะไหล่ทุกชิ้นได้มาฟรีจนกว่าจะพิสูจน์เป็นอย่างอื่น ผมยอมสร้างของที่ยากกว่า มองเห็นน้อยกว่า ให้ถูกต้องก่อน แล้วปล่อยให้ฟีเจอร์ที่มองเห็นชัดกว่าตามมาทีหลัง ดีกว่าปล่อยฟีเจอร์ที่มองเห็นชัดออกไปเร็วๆ บนโมเดลต้นทุนที่รู้อยู่แล้วว่าผิด
ฟีเจอร์แคบๆ กับคำถามที่กว้างกว่าซึ่งยังค้างอยู่
การปันส่วนซากรถแก้ปัญหาที่มีจริง เจาะจงจริง ให้ลูกค้ากลุ่มที่มีจริง เจาะจงจริง แต่มันไม่ได้แก้คำถามพื้นฐานกว่านั้นมากที่ทุกอู่ — จะเป็นลานซากรถหรือไม่ก็ตาม — จะถามภายในห้านาทีแรกที่ได้ใช้ผลิตภัณฑ์จริงๆ นั่นคือ จะทำให้เจ้านี่รันได้เร็วพอ และน่าเชื่อถือพอ จนไม่กินเวลามากกว่าที่มันช่วยประหยัดได้ไหม คำถามนั้นไม่มีฟีเจอร์ตัวไหนตอบได้ ไม่ว่าจะสร้างมาดีแค่ไหน มันถูกตอบด้วยความเร็วที่ผลิตภัณฑ์ส่วนที่เหลือจะถูกสร้างขึ้นรอบฐานใหม่นี้ได้ และนั่นคือแรงกดดันที่หล่อหลอมทุกอย่างที่ตามมาทันที
นี่คือตอนที่ 3 ของ U-PRO Build Journal ตอนที่ 2 พูดถึงการตัดสินใจสร้าง U-PRO เป็นระบบ multi-tenant แบบฐานข้อมูลร่วม แทนที่จะให้แต่ละอู่มี infrastructure เฉพาะของตัวเอง ตอนที่ 4 จะรับช่วงต่อจากเส้นเรื่องที่ตอนนี้ทิ้งไว้ นั่นคือการสร้างของเฉพาะทางขนาดนี้ใช้เวลาจริงๆ และแรงกดดันนั้นเองที่ผลักดันให้เกิดการเปลี่ยนแปลงครั้งใหญ่ถัดไปในวิธีสร้างผลิตภัณฑ์นี้ — การมอบงานวิศวกรรมจริงให้ AI ทำเป็นครั้งแรก