การสร้างทีมข้อมูลในสตาร์ทอัพ

 (erikbern.com)
39 คะแนน โดย xguru 2021-07-12 | 7 ความคิดเห็น | แชร์ทาง WhatsApp

  • เรื่องราวของคนคนหนึ่งที่เข้าร่วมเพื่อสร้างทีมข้อมูลขนาดเล็กราว 4 คนในสตาร์ทอัพระยะ Mid-Stage ที่มีรายได้ต่อปีระดับ 10,000 ล้านวอน

  • เป็นบทความเชิงเปรียบเปรยจากประสบการณ์หลายครั้ง และอาจมีอคติ* ดังนั้นโปรดพิจารณาไว้ขณะอ่าน

1 กรกฎาคม : ช่วงเช้า

  • วันแรกของการทำงานในฐานะหัวหน้าทีมข้อมูล

  • ทักทายกับ CMO

(CMO ตื่นเต้นมากที่ผมมา เขาเล่าว่าบริษัทของเพื่อนเขาใช้ AI ทำ customer segmentation และมันดูเท่มาก)

(หลังจากคุยกันสั้น ๆ ก็เริ่มสำรวจ data practice ของทีมการตลาด)

DATA: "ต้นทุนการได้มาซึ่งลูกค้า (CAC) เป็นอย่างไรบ้างครับ?"

CMO: "อืม...จริง ๆ แล้วดีมากเลยนะ นักวิทยาศาสตร์ข้อมูลของเราวัดตัวเลขแล้วพบว่าค่าใช้จ่ายต่อคลิกลดลงเรื่อย ๆ"

DATA: (ได้ยินมาว่านักวิทยาศาสตร์ข้อมูลทุกคนรายงานตรงต่อทีมข้อมูล แต่มีนักวิทยาศาสตร์ข้อมูลอยู่องค์กรอื่นด้วยเหรอ?)

CMO: "ปัญหาจริง ๆ คือทีม Growth เปลี่ยนทราฟฟิกที่เราพาเข้ามายังเว็บไซต์ได้ไม่หมด"

DATA: "มีแดชบอร์ดที่ดู conversion funnel ได้ไหมครับ?"

CMO: "การเปลี่ยน lead ให้เป็นลูกค้ามันเป็นงานของทีม Growth ไม่ใช่เหรอ"

  • คุยกับหนึ่งใน Product Manager

PM ที่รีดีไซน์หน้าเริ่มต้นทั้งหมดกำลังตื่นเต้นมาก เพราะจำนวนการสมัครของผู้ใช้เพิ่มขึ้นถึง 14%

DATA: "ความต่างของตัวเลขนั้นมีนัยสำคัญทางสถิติไหมครับ?"

PM: "นั่นไม่ใช่งานของฉัน แต่น่าจะเป็นงานของทีมคุณ"

PM: "ก่อนหน้านี้เราเคยถามไปแล้ว แต่ทีมข้อมูลบอกว่าไม่มีข้อมูล และต้องใช้เวลาหลายเดือนกว่าจะได้ข้อมูล"

PM: "ที่น่าทึ่งคือเราไม่ได้เปลี่ยนแบบ incremental เลย เราตัดสินใจว่าจะไม่ทำ A/B test กับการเปลี่ยนแปลงนี้ บางครั้งถ้าอยากหลุดจากค่าที่เหมาะสมเฉพาะจุด (Local Maxima) ก็ต้องกล้าลงเดิมพันก้อนใหญ่"

PM: "ตอน Steve Jobs เปิดตัว iPhone เขาก็ไม่ได้ทำ A/B test ทีมเราเปิดตัวสิ่งนี้ก่อนเดดไลน์ 2 วัน และนั่นแหละคือสิ่งสำคัญ!"

DATA: (แกล้งทำเป็นยุ่งแล้วขีดอะไรลงสมุด)

  • คุยกับสมาชิกทีมใหม่

→ ตอนนี้เป็นทีม 3 คน แต่ได้รับงบให้ขยายเป็น 10 คนได้ภายในสิ้นปี

→ ดูเหมือนสมาชิกทีมจะตื่นเต้นที่ผมมา

→ พวกเขาโชว์สิ่งที่ทำไว้แล้ว มีอยู่ค่อนข้างมาก และบางอย่างก็น่าสนใจทีเดียว

✓ neural network สำหรับทำนายการเลิกใช้งานของผู้ใช้ (Churn Prediction)

✓ โน้ตบุ๊กที่ติดตั้งระบบแนะนำสินค้าที่เกี่ยวข้องไว้แล้ว

→ โค้ดจำนวนมากเริ่มต้นด้วยขั้นตอน preprocessing ที่ซับซ้อนมาก ซึ่งต้องดึงข้อมูลจากหลายระบบ

✓ ดูเหมือนว่าบางส่วนของงานนี้ต้องรันสคริปต์หลายตัวด้วยมือ ตามลำดับที่ถูกต้อง

→ เมื่อถามทีมว่าทำไมยังไม่นำไปใช้ในโปรดักชัน

✓ วิศวกรบอกว่าถ้าจะทำให้ถึงระดับ production-ready นี่เป็นโปรเจกต์ใหญ่มาก

✓ Product Manager ใส่ไว้ใน backlog แล้ว แต่ก็มีงานอื่นแทรกเข้ามาเรื่อย ๆ เลยถูกเลื่อนออกไป

✓ พวกเขาบอกว่าจำเป็นต้องได้รับการสนับสนุนจากผู้บริหารสำหรับเรื่องนี้

1 กรกฎาคม : ช่วงบ่าย

  • คุยกับ Head of Supply Chain (ดูเหมือนเขาจะไม่ได้ตื่นเต้นเท่า CMO )

"พูดตรง ๆ ผมไม่แน่ใจว่าเราจำเป็นต้องได้ความช่วยเหลือจากทีมข้อมูลไหม"

"เราไม่ได้มีปัญหาแบบนั้น สิ่งที่เราต้องการคือ business analyst"

"ผมมีทั้งทีมอยู่แล้ว และพวกเขาใช้เวลาวันละหลายชั่วโมงกับโมเดลที่ซับซ้อนมาก"

"พวกเขาไม่มีเวลาแม้แต่จะตอบคำถามพื้นฐานที่ผมมี"

"ผมมีสเปรดชีตเต็มไปด้วยคำถามที่อยากได้คำตอบ"

(พอดูในสเปรดชีต ก็มีอะไรแบบนี้)

"เปรียบเทียบ conversion rate ของลูกค้าที่ออก ticket แล้วได้รับการแก้ไขภายใน 1 ชั่วโมง กับลูกค้าที่ได้รับการแก้ไขหลัง 1 ชั่วโมง โดยจัดกลุ่มตามช่วงยอดสั่งซื้อทุก ๆ 100 ดอลลาร์"

(พอถามถึงโมเดล)

  • ดูเหมือนว่าจะต้องคัดลอกลงในแท็บที่ถูกต้องของ Google Sheets ในรูปแบบที่ถูกต้อง ซึ่งประกอบด้วย VLOOKUP จำนวนมหาศาล

  • ข้อมูลอัปเดตทุกวัน และลำดับความสำคัญของทีมในวันนั้นจะถูกกำหนดจากผลลัพธ์ของโมเดล

  • ค่าใช้จ่ายที่ต้องจ่ายให้ซัพพลายเออร์ (vendor) ก็ถูกคำนวณอยู่ในสเปรดชีตเช่นกัน

(กลับบ้านแล้วรินวิสกี้แก้วใหญ่... )

[ เกิดอะไรขึ้นกันแน่?]

  • โดยพื้นฐานแล้ว นี่คือภาพบรรยายแบบค่อนข้างประชดประชันของสิ่งที่เกิดขึ้นในหลายบริษัทช่วงต้นของระดับความพร้อมด้านข้อมูล

  • การขาดข้อมูลและข้อมูลที่กระจัดกระจาย

→ หลายครั้งข้อมูลไม่มีอยู่ตั้งแต่แรก เพราะโปรดักต์ไม่ได้ถูก instrumented อย่างเหมาะสม

→ ระบบข้อมูลแตกเป็นเสี่ยง ๆ เพราะข้อมูลกระจายอยู่ในหลายระบบ

→ มีกระบวนการธุรกิจที่ขับเคลื่อนด้วยข้อมูล แต่เปราะบาง และแทบไม่มีหรือไม่มี automation เลย

  • ความคาดหวังที่ไม่ชัดเจนต่อหน้าที่ของทีมข้อมูล

→ จ้าง data scientist มาเพื่อทำ R&D และ deploy AI แต่สุดท้ายกลับไม่มีเป้าหมายทางธุรกิจที่ชัดเจน

→ ทีมข้อมูลบ่นว่าทำให้ ML ขึ้นโปรดักชันได้ยาก แต่ทีมผลิตภัณฑ์กลับไม่ได้ใส่ใจกับฟีเจอร์นั้นมากนัก

→ คนที่ต้องการ "English-to-SQL translator"

  • ทีมผลิตภัณฑ์ที่ไม่ได้รับการฝึกให้ data-driven

→ Product Manager ไม่ได้มองข้อมูลเป็นเครื่องมือสำหรับสร้างฟีเจอร์ที่ดีกว่า

→ ขาด alignment ระหว่างสิ่งที่ทีมผลิตภัณฑ์อยากสร้าง กับสิ่งที่ทีมข้อมูลมี

  • วัฒนธรรมที่ขัดแย้งกับวัฒนธรรมแบบ data-centric ในระดับรากฐาน

→ เป็นวัฒนธรรมที่เฉลิมฉลองการปล่อยงาน (shipping) มากกว่าการเฉลิมฉลองความก้าวหน้าที่วัดผลได้และการเรียนรู้

→ แม้แต่ทีมที่ใช้ metric จริง ๆ ก็ยังใช้อย่างไม่สม่ำเสมอ การวัดผลไม่ถูกต้อง และบางกรณีก็ขัดแย้งกับทีมอื่น

  • ไม่มี data leadership

→ โครงสร้างองค์กรด้านข้อมูลแตกกระจัดกระจาย โดยบุคลากรข้อมูลประเภทต่าง ๆ รายงานตรงต่อหลายฝ่ายงานที่ต่างกัน

→ ฝ่ายอื่น ๆ ไม่ได้รับความช่วยเหลือที่ต้องการ จึงจ้าง analyst จำนวนมากมาล้อมรอบทีมข้อมูล

→ ขาดการทำมาตรฐานของ toolchain และ best practice

(โห อันนี้ชวนหดหู่จริง ๆ แล้วถ้าจะเริ่มแก้ปัญหานี้ ต้องทำอะไรบ้างนะ)

8 กรกฎาคม

  • เริ่มวางทิศทางใหม่ให้ทีมข้อมูลตั้งแต่สัปดาห์หน้า

  • ดูเหมือนมีอยู่คนหนึ่งที่มีประสบการณ์ด้านอินฟราฯ จึงให้เขาสร้าง Centralized data warehouse

  • ตอนนี้ขอแค่มีเส้นทางที่เร็วที่สุดในการรวมข้อมูลไว้ที่เดียวก่อน

  • แผนโดยพื้นฐานคือ dump production DB เข้า data warehouse ทุก ๆ ชั่วโมง

  • แม้จะสามารถส่ง event log จำนวนมหาศาลจากเฟรมเวิร์กที่ใช้ติดตามโฆษณาบนฝั่ง frontend ได้ด้วย แต่เก็บเรื่องนั้นไว้เป็น technical debt ก่อน

  • ร่วมกับทีมสรรหากำหนด Generalist Data Role

→ เน้นทักษะซอฟต์แวร์หลัก แต่ต้องมีทัศนคติแบบ generalist (ทำได้ทุกอย่าง) และเข้าอกเข้าใจความต้องการทางธุรกิจอย่างลึกซึ้ง

→ ตอนนี้ลบทุกถ้อยคำที่กล่าวถึงปัญญาประดิษฐ์และแมชชีนเลิร์นนิงออกไปก่อน

  • ใช้เวลาไปกับบุคลากรข้อมูลคนอื่น ๆ ที่ไม่ได้รายงานตรงต่อทีมข้อมูล

→ data scientist ที่อยู่ในทีมการตลาดเป็นคนหนุ่ม เขาพูดว่า "ผมอยากเป็น data scientist มาตลอดเลยครับ ผมอยากเรียนรู้จากคุณเยอะ ๆ"

  • ไปถามเพื่อนที่ทำ coding bootcamp ว่ามี "คอร์สสอน SQL" ดี ๆ ไหม เขาบอกว่ามี ก็เลยตัดสินใจนำมาใช้ปลายเดือนนี้

  • จัดทำสไลด์สำหรับทีมผลิตภัณฑ์เพื่ออธิบายว่า A/B test คืออะไรและทำงานอย่างไร

→ ยกตัวอย่างการทดสอบหลายกรณีที่ได้ผลลัพธ์แบบคาดไม่ถึง และ

→ ทำให้อินเทอร์แอ็กทีฟเพื่อให้ลองเดากันได้ว่าอะไรเป็นผู้ชนะ

  • ไปพบเลขานุการของ CEO และหาว่า “ตัวชี้วัดที่อยากให้มีการรายงานผ่านอีเมลที่ส่งอัตโนมัติทุกสัปดาห์” มีอะไรบ้าง

  • พอคุยกับนักวิเคราะห์ธุรกิจของทีม Supply Chain ก็พบว่าพวกเขาเป็นคนมีเหตุผล แต่ก่อนหน้านี้เคยเจ็บช้ำจากการคุยกับทีมข้อมูล

  • หนึ่งในนั้นเคยมีประสบการณ์ใช้ SQL มาก่อน พอเห็นว่าเขาถามเรื่อง conversion rate ก็เลยให้สิทธิ์เข้าถึง data warehouse

  • ตั้งประชุม 1:1 รายสัปดาห์กับคนทั่วทั้งองค์กรที่ต้องการใช้ข้อมูล

→ ประเด็นสำคัญคือการหาช่องว่างของข้อมูล (Gap) และโอกาส แล้วส่งต่อให้ data scientist

→ เหล่า data scientist อาจรู้สึกผิดหวังได้ เพราะลำดับความสำคัญของงานวิจัยจะถูกเลื่อนออกไป

→ พูดว่า “ขอเน้นส่งมอบคุณค่าทางธุรกิจให้ได้เร็วที่สุดเท่าที่เป็นไปได้” พร้อมกับบอกว่า “เดี๋ยวอาจได้กลับไปทำงานด้าน machine learning เร็ว ๆ นี้ก็ได้ ลองดูก่อน”

1 กันยายน : ตอนเช้า

  • ผ่านไป 3 เดือน เริ่มรู้สึกว่างานเริ่มเข้าที่เข้าทางทีละน้อย

  • ประชุม 1:1 รายสัปดาห์กับผู้มีส่วนได้ส่วนเสียหลากหลายฝ่าย และคอยหาจุดบอดกับโอกาสที่ข้อมูลสามารถสร้างความเปลี่ยนแปลงได้อย่างต่อเนื่อง

  • ใช้สิ่งที่ค้นพบมาผลักดันให้เกิดงานแพลตฟอร์มหลักที่จำเป็น

  • ถ้าจะสร้างชุดข้อมูลแบบ “derived” ต้องสร้าง pipeline จำนวนมาก แม้ต้นทุนตั้งต้นจะสูง แต่ถ้าได้ dataset ที่ถูกต้องแล้ว การวิเคราะห์ต่อจากนั้นจะง่ายขึ้นมาก

  • เริ่มเปิดให้แผนกอื่นเข้าถึง data warehouse

  • เริ่มใช้ SQL ทำการวิเคราะห์พื้นฐานกันเองโดยตรง

→ เรื่องที่ยอดเยี่ยม: product manager ระดับ junior พบว่า conversion rate ของ iOS Safari แย่มาก สาเหตุคือ frontend bug ที่เกี่ยวกับ local storage และแก้ได้ด้วยโค้ดเพียงบรรทัดเดียว

  • หัวหน้าฝ่ายซัพพลายเชนส่งอีเมลมาอย่างไม่พอใจ

→ บอกว่าฐานข้อมูลมีการเปลี่ยนแปลงจน query ยาว 500 บรรทัดใช้ไม่ได้

→ มอบหมายให้ data scientist ที่กำลังบ่นจัดการแก้ พร้อมแขวนแครอตอันอื่นไว้ว่า “เดี๋ยวสิ้นเดือนนี้จะหาปัญหา machine learning เจ๋ง ๆ ให้”

1 กันยายน : ตอนบ่าย

  • product manager ของทีม checkout ก็ยังไม่ได้ทำการวิเคราะห์ metric อยู่ดี

  • data scientist ของทีมการตลาดไปคุยกับผู้จัดการ แล้วตกลงว่าจะมารายงานตรงกับฉัน

[ กำลังเกิดอะไรขึ้น? ]

  • กำลังวางรากฐานพื้นฐานสำหรับสิ่งที่เร่งด่วนที่สุด

→ ทำให้สามารถ query ข้อมูลสำคัญได้จากที่เดียว

→ เปิดให้เข้าถึง SQL และให้ทีมอื่นใช้งาน เพื่อลดงาน “แปล SQL” จำนวนมาก

  • ในทางกลับกัน ทีมอื่นอาจพยายามไปไกลเกินไปเพราะอิสระแบบนี้ จะป้องกันด้วยการตั้งสิทธิ์การเข้าถึงข้อมูลก็ได้ แต่ข้อเสียมีมากกว่า

  • ที่ทีม checkout ยังวิเคราะห์ข้อมูลไม่ได้ เพราะไม่รู้ว่าต้องไปถามใคร

  • นี่เป็นปัญหาเชิงองค์กรเป็นหลัก

→ ทีมต่าง ๆ ไม่รู้วิธีทำงานร่วมกับทีมข้อมูล

→ และอาจไม่รู้ตัวว่าทีมข้อมูลเองก็อาจเป็นคอขวด

  • สิ่งที่สมเหตุสมผลที่สุดคือ “รวมศูนย์การรายงาน แต่กระจายการบริหารงาน”

→ เพราะข้อมูลและการตัดสินใจจะสร้าง feedback loop ที่ใกล้ชิดกันมากขึ้น

→ เพื่อให้สมาชิกทีมข้อมูลไปทำงานร่วมกับแต่ละทีม และรายงานขึ้นตรงกับฉัน (หัวหน้าทีมข้อมูล) ได้

2 กันยายน

  • ทีมข้อมูลขยายเป็น 6 คน

→ 1 คนดูแลโครงสร้างพื้นฐาน data warehouse

→ อีก 5 คนถูกจัดสรรไปแต่ละทีม: onboarding, supply chain, checkout, marketing และงานสนับสนุน CEO รวมถึงการทำสไลด์นำเสนอสำหรับนักลงทุน/บอร์ด

  • อธิบายการเปลี่ยนแปลงให้ทั้งบริษัทเข้าใจ และทำให้ชัดเจนว่าถ้ามีความต้องการด้านข้อมูลต้องทำงานกับใคร

  • ต่อจากนี้แม้จะจ้างคนด้านข้อมูลเพิ่ม ก็มีแผนจะส่งไปประจำทีมอื่น

3 มกราคม

  • data scientist คนหนึ่งตัดสินใจจะลาออก เพราะไม่ได้มีงานที่เขาจะสนุกมากนัก ก็เลยไม่รั้งไว้

  • ในทีมมีคนใหม่หลายคน เป็นคนที่มีความรู้ด้าน software engineering เล็กน้อย ใช้ SQL ได้ และอยากค้นหาสิ่งน่าสนใจจากข้อมูล

→ เป็นคนที่มองหา “ข่าวเด็ด” จากข้อมูล ก็เลยคิดถึงพวกเขาในฐานะ “data journalist”

  • สำหรับสมาชิกที่ทำงานกับทีม onboarding

→ พบว่าใน flow ของ onboarding มีการถามที่อยู่ลูกค้า ทั้งที่จริง ๆ แล้วไม่จำเป็น

→ พอลบออก A/B test แสดงให้เห็นว่า conversion rate เพิ่มขึ้น 21%

→ ไม่ได้ง่ายนัก เพราะต้องทำงาน ETL เพื่อให้ query ข้อมูลได้สะดวกขึ้น แต่ Python ก็ช่วยได้นิดหน่อยจนทำสำเร็จ

  • รายงานรายไตรมาสกับ CEO

→ PM จาก growth initiative นำเสนอการ redesign หน้า landing page ที่เพิ่งเปิดตัวใหม่

→ PM เน้นว่ามีวิศวกร 20 คนทำงานล่วงเวลาเพื่อให้ทันกำหนด

→ CMO ก็มีส่วนร่วมลึกมาก เพราะคาดหวังกับ Direct Mail สูงในฐานะส่วนหนึ่งของการ redesign นี้

→ CEO ถามว่า “ตอนนี้ metric เป็นอย่างไรบ้าง? ต้นทุนการได้มาซึ่งลูกค้าลดลงไหม?”

(คุณคาดอยู่แล้วว่า CEO จะถามแบบนี้ พอได้ยินเข้าจริงก็ยิ้มออกมา)

→ PM แสดงตัวเลขในภาคผนวก โดยบอกว่าได้ทำ A/B test ไว้จริง

→ บาง metric ดีขึ้น บาง metric แย่ลง จึงยังไม่มีผลลัพธ์ที่มีนัยสำคัญ และตัวเลขต้นทุนการได้มาซึ่งลูกค้าก็ดูไม่ดีนัก

→ CMO เน้นว่าตัวเลขยังอยู่ระหว่างการก่อรูป และแคมเปญแบบนี้อาจต้องใช้เวลาหลายเดือน

[ กำลังเกิดอะไรขึ้น? ]

  • ข่าวดีคือทีมผลิตภัณฑ์เริ่มทำ A/B test แล้ว

  • ข่าวร้ายคือพวกเขามักเมินผลลัพธ์ และยังขับเคลื่อนโครงการตาม milestone กับ deadline ที่ตั้งขึ้นแบบประดิษฐ์เป็นส่วนใหญ่

  • ข่าวดีที่สุดคือ CEO กำลังกดดันให้แต่ละทีมใช้ข้อมูลเป็นความจริง (truth) ในการทำงาน

  • เมื่อองค์กรเริ่มถูกกดดันให้ขับเคลื่อนด้วยข้อมูลมากขึ้น ทีมข้อมูลก็ต้องเร่งวิธีการทำงานร่วมกับทีมอื่นให้เร็วขึ้น

  • โดยเฉพาะผู้บริหารระดับสูงจะยิ่งโฟกัสกับ metric มากขึ้น และงานของคุณคือทำให้ทีมข้อมูลลงมือทำกับ metric เหล่านั้น

  • วิธีที่ง่ายที่สุดอย่างหนึ่งคือทำให้แน่ใจว่าแต่ละทีมมี dashboard สำหรับ metric ที่พวกเขาให้ความสำคัญ

1 เมษายน

  • งาน machine learning เก่า ๆ ที่ทีมข้อมูลเคยทำยังคงอยู่เหมือนเดิม

  • data scientist ที่ทำงานกับทีมผลิตภัณฑ์ inventory สนใจงานระบบแนะนำที่เคยสร้างไว้ก่อนหน้านี้

  • หนึ่งในสมาชิกใหม่ที่เพิ่งจ้างมาเป็นคนสาย generalist จึงนำ recommendation system notebook มาทำเป็นแอป Flask เล็ก ๆ แล้ว deploy ภายในองค์กร

  • product manager ของทีม inventory เห็นแล้วชอบมาก “แล้วจะ deploy อันนี้ยังไงดี?”

  • หนึ่งใน metric หลักของทีม inventory คือ “มูลค่าออร์เดอร์เฉลี่ย” และคาดว่าคำแนะนำนี้จะช่วยปรับปรุงตัวเลขนั้นได้มาก

  • ประเมินคร่าว ๆ แล้ว การ deploy แบบใหญ่ดูจะยาก แต่ก็มีไอเดียว่า “ถ้าลองปล่อยให้ลูกค้าแค่ 1% ก่อนล่ะ?”

  • “อาจจะทื่อ ๆ หน่อย แต่ถ้าใช้ Cron Job สร้างสินค้าแนะนำไว้ล่วงหน้า ก็น่าจะทำได้ และน่าจะเสร็จในไม่กี่วัน”

  • ระหว่างทำงานกับทีมซัพพลายเชน ก็เจอ SQL query ขนาดมหึมาเพิ่มขึ้นอีก

  • มันยังพังอยู่เรื่อย ๆ แต่ทีมข้อมูลกำลังแปลงสิ่งเหล่านี้ให้เป็น pipeline ที่เหมาะสม

  • หัวหน้าทีมซัพพลายเชนขอให้จ้าง data scientist เพิ่ม

[ โอเค แล้วกำลังเกิดอะไรขึ้นกันแน่? ]

  • อย่างแรกเลย ความหวังเรื่องงาน machine learning เจ๋ง ๆ เริ่มกลับมาแล้ว

  • ในที่สุดทีมผลิตภัณฑ์ก็ตื่นเต้นกับการเปิดตัว recommendation system ในรูปแบบการทดสอบเล็ก ๆ

  • ก่อนหน้านี้ทำไม่ได้ เพราะทีม product engineering คาดการณ์งานยาก ไม่อยากมีส่วนร่วมโดยตรง และทีมข้อมูลก็ไม่มีทักษะในการทำให้ขึ้น production

  • สิ่งที่ทำให้ปัญหานี้คลี่คลายคือทีมข้อมูลลงมือสร้างเดโมขึ้นมาจริง ๆ แบบนี้ไม่เพียงทำให้เข้าใกล้ production มากขึ้น แต่ยังแสดงความเป็นไปได้ให้เห็นอย่างชัดเจน

  • อีกเรื่องคือสิ่งที่กำลังเกิดขึ้นกับทีมซัพพลายเชน

→ เดิมเริ่มจากมี “business analyst” ของตัวเอง แต่ถ้าจะดึงข้อมูลก็ต้องให้ทีมข้อมูลรัน query ให้

→ จากนั้นนักวิเคราะห์ก็เริ่มรัน query ได้เอง โดยมีทีมข้อมูลช่วยเหลือ

→ ก่อนอื่นเริ่มกำจัด "หนี้เทคนิคเงา" (SQL query ขนาดมหึมาเหมือนสัตว์ประหลาด) ที่เคยสร้างแรงเสียดทานกับทีมข้อมูล

→ ทีมข้อมูลเริ่มเข้าไปช่วยทีมซัพพลายเชนอย่างใกล้ชิด

→ เมื่อสมาชิกทีมข้อมูลเข้าไปฝังตัวอยู่ในทีมต่าง ๆ ความจำเป็นของนักวิเคราะห์ธุรกิจก็ลดลง และจำนวนนักวิทยาศาสตร์ข้อมูลก็เพิ่มขึ้น

  • จงจำไว้ว่าตอนเริ่ม dump production DB ลง data warehouse โดยตรงในช่วงแรก คุณได้รับ "หนี้เทคนิค" นั้นมาไว้กับตัวแล้ว

  • ช่วงแรกจะมีหลายอย่างพัง แต่ต้องเพิ่มเลเยอร์ที่ทำให้ query ได้อย่างเสถียร ซึ่งอาจเป็นงานที่ใหญ่มาก

1 กรกฎาคม

  • การประชุมวางแผนไตรมาส 3

→ ก่อนหน้านี้เคยถกเถียงกันว่าบริษัทจะเดิมพันกับอะไรในไตรมาสถัดไป

→ แต่ครั้งนี้คุณนำเสนอเมตริกระดับบนสุดของบริษัท และแต่ละทีมก็นำเสนอการแตกย่อยเมตริกระดับบนสุดผ่านเมตริกย่อยของตัวเอง

  • งานของทีมบริหารผลิตภัณฑ์เริ่มออกผล

→ PM อธิบายสิ่งที่เรียนรู้จากการรันทดสอบหรือสิ่งที่ค้นพบจากข้อมูล พร้อมทั้งให้เหตุผลสนับสนุนการลงทุนในโปรเจกต์

  • ผลงานชิ้นใหญ่คือ นักวิทยาศาสตร์ข้อมูลที่ทำงานกับทีมเช็กเอาต์ค้นพบว่าเมื่อผู้ใช้กดปุ่มย้อนกลับในหน้าตรวจสอบคำสั่งซื้อ ออบเจ็กต์รถเข็นจะเกิดความผิดปกติ

→ เมื่อแก้ปัญหานี้แล้ว อัตรา Conversion ก็เพิ่มขึ้นอย่างมาก

  • อีก insight หนึ่งคือ ทราฟฟิกที่มาจากแคมเปญโฆษณาต่างกันมีโปรไฟล์ Conversion ที่แตกต่างกันมาก

→ บางแคมเปญมีค่า cost per click ต่ำ แต่ Conversion แย่มาก ส่วนบางแคมเปญมีค่าใช้จ่ายสูง แต่ Conversion สูงมาก

  • ด้วยการติดตามตัวแปร UTM และเชื่อมโยงกับการสร้างบัญชี จึงสามารถวัดอัตรา Conversion ตั้งแต่การคลิกโฆษณาจนถึงการซื้อได้

→ ก่อนที่จะดึงข้อมูลทั้งหมดมาไว้ใน data warehouse เดียวกันและทำ normalization เพื่อให้ query ได้ง่าย สิ่งนี้เป็นไปไม่ได้

→ เมื่อร่วมมือกับทีมการตลาด KPI สำคัญจึงไม่ใช่ cost per click แต่เป็นต้นทุนการได้มาซึ่งลูกค้าแบบ End-to-End

  • อีกเรื่องน่าสนใจคือการทดสอบระบบแนะนำสินค้า 1% ประสบความสำเร็จอย่างผิดปกติ

→ การขยายไปสู่ผู้ใช้ 100% เป็นโปรเจกต์ใหญ่มาก แต่ CEO ได้อนุมัติโปรเจกต์แล้ว

  • ไม่ใช่ว่าผลลัพธ์ทั้งหมดจะเป็นบวก เพราะการทดสอบจำนวนมากล้มเหลว

→ หนึ่งในสไลด์อธิบายการทดสอบที่ไม่ได้คิดค่าจัดส่งแยกต่างหาก แต่รวมไว้ในราคาแล้ว

→ CEO พูดว่า "เราได้เรียนรู้อะไรจากตรงนี้?"

→ แล้วสิ่งนี้ก็นำไปสู่บทสนทนาเพื่อวางแผนชุดการทดลองติดตามผลต่อไป

(กลับบ้านไปเปิดแชมเปญ)

[ เกิดอะไรขึ้นกันแน่? ]

  • คุณทำสำเร็จแล้ว

  • คุณได้เปลี่ยนองค์กรให้กลายเป็น data native อย่างแท้จริง

  • ทีมข้อมูลทำงานแบบข้ามสายงานร่วมกับผู้มีส่วนได้ส่วนเสียที่หลากหลาย

  • ข้อมูลและ insight ถูกนำไปใช้ในการวางแผน และข้อมูลไม่ได้ถูกใช้เพื่อการวิจัยที่เป้าหมายไม่ชัดเจน แต่ใช้เพื่อสร้างคุณค่าทางธุรกิจ

  • บริษัทใช้วงจร feedback ที่ขับเคลื่อนด้วยข้อมูลอย่างรวดเร็ว เพื่อทำงานแบบ iterative แทนการวางแผนสไตล์ "waterfall" ขนาดใหญ่

  • เมตริกถูกนิยามในแบบที่สามารถสร้างคุณค่าทางธุรกิจและทำให้เกิดความรับผิดชอบต่อสิ่งนั้นได้

  • วัฒนธรรมข้อมูลถูกขับเคลื่อนร่วมกันจากทั้งข้างบน (CEO เป็นผู้ผลักดัน) และข้างล่าง (พนักงาน)

  • หากอย่างน้อยได้เรียนรู้อะไรบางอย่าง ความล้มเหลวก็ไม่เป็นไร

(ยินดีด้วย คุณคู่ควรกับการชูแก้วแชมเปญ)

บทความที่เกี่ยวข้อง

7 ความคิดเห็น

 
hangnim 2022-08-05

อ่านช่วงต้นแล้วนึกว่าเป็นบริษัทของพวกเราเลย,,,, T_T (แน่นอนว่าบริษัทเรายังไม่มีแม้แต่ทีมข้อมูลเลยค่ะ 555)
 
dajoa 2021-07-21

อ่านเพลินมากครับ ขอบคุณครับ~!
 
shawn 2021-07-13

ให้ความรู้สึกเหมือนได้ดูตอนหนึ่งของซีรีส์เกี่ยวกับเทคสตาร์ทอัปที่เหล่าวิศวกรน่าจะชอบดู สนุกดี! 👍
 
hangnim 2022-08-05

22222
 
laeyoung 2021-07-13

คนดูเหมือนจะเยอะ แต่ระดับนี้ถือว่าเป็นแค่ช่วง mid-stage เองสินะ
 
xguru 2021-07-13

ขนาดที่มองกันน่าจะต่างจากในประเทศอยู่พอสมควร
 
xguru 2021-07-12

คำว่า Opinionated* แปลให้เนี้ยบค่อนข้างยาก แต่โดยหลักแล้วผมมักใช้คำว่า "มีอคติ" ในความหมายว่า "เป็นอคติที่สะท้อนความเห็นของตนเอง"

ในประเด็นนี้มีบทความที่คนอื่นเขียนไว้ ลองดูประกอบได้

และบทความต้นฉบับเดิมเขียนอธิบายแบบร้อยเรียงไว้ แต่ผมได้เรียบเรียงใหม่เป็นภาษาพูดเล็กน้อยเพื่อให้อ่านง่ายขึ้น