Xây dựng đội dữ liệu trong startup

xguru · 2021-07-12T10:34:06+09:00

Câu chuyện của một người gia nhập để xây dựng một đội dữ liệu nhỏ khoảng 4 người tại một startup giai đoạn mid-stage với doanh thu thường niên khoảng 10 tỷ won Đây là bài viết mang tính ẩn dụ dựa trên một vài trải nghiệm, và có thể thiên lệch*, nên hãy cân nhắc khi đọc Ngày 1 tháng 7: Buổi sáng Ngày đầu đi làm với vai trò trưởng nhóm dữ liệu Chào hỏi CMO (CMO rất phấn khích vì tôi đã đến, kể rằng công ty của bạn mình đang dùng AI để phân khúc khách hàng và trông rất ngầu) (Sau vài câu chuyện ngắn, tôi tìm hiểu về thực hành dữ liệu của đội marketing) DATA: "Chi phí thu hút khách hàng (CAC) thế nào rồi?" CMO: "Ừm.. thực ra rất tuyệt. Data scientist của chúng tôi đã đo và chi phí mỗi lượt nhấp đang giảm dần" DATA: (Tôi nghe nói tất cả data scientist đều báo cáo cho đội dữ liệu, vậy mà lại có data scientist ở tổ chức khác sao?) CMO: "Vấn đề thật sự là đội Growth không chuyển đổi được toàn bộ lượng truy cập mà chúng tôi đưa về website" DATA: "Có dashboard nào để xem conversion funnel không?" CMO: "Chuyển đổi lead là việc của đội Growth mà." Trò chuyện với một Product Manager PM vừa thiết kế lại toàn bộ trang khởi đầu đang rất phấn khích vì số người đăng ký tăng tới 14% DATA: "Chênh lệch đó có ý nghĩa thống kê không?" PM: "Đó không phải việc của tôi mà là việc của đội anh chứ" PM: "Lần trước khi chúng tôi hỏi, đội dữ liệu nói là không có dữ liệu, và để lấy được dữ liệu thì phải mất vài tháng" PM: "Điều đáng kinh ngạc là chúng tôi đã không thay đổi theo kiểu incremental. Chúng tôi quyết định không A/B test thay đổi này. Đôi khi phải đặt cược lớn để thoát khỏi cực trị cục bộ (Local Maxima)." PM: "Steve Jobs đã không A/B test khi ra mắt iPhone. Đội chúng tôi launch cái này trước deadline 2 ngày, và đó mới là điều quan trọng!" DATA: (Giả vờ bận rộn rồi ghi nguệch ngoạc vào sổ tay) Trò chuyện với các thành viên mới của đội → Hiện là đội 3 người nhưng đã có ngân sách để tăng lên 10 người vào cuối năm → Có vẻ các thành viên rất hào hứng vì tôi đến → Họ cho tôi xem những gì đã làm. Có khá nhiều thứ, và một vài trong số đó khá ấn tượng ✓ Mạng nơ-ron để dự đoán rời bỏ người dùng (Churn Prediction) ✓ Notebook đã triển khai hệ thống gợi ý sản phẩm liên quan → Nhiều đoạn code bắt đầu bằng bước tiền xử lý rất phức tạp, phải lấy dữ liệu từ nhiều hệ thống khác nhau ✓ Có vẻ để làm một phần việc này thì phải chạy thủ công nhiều script theo đúng thứ tự → Khi tôi hỏi vì sao chưa đưa vào production ✓ Các kỹ sư nói rằng để làm nó đạt cấp độ production thì sẽ là một dự án rất lớn ✓ Product Manager đã đưa vào backlog nhưng liên tục bị đẩy lùi vì các việc khác cứ phát sinh ✓ Họ nói việc này cần có sự hậu thuẫn của ban lãnh đạo Ngày 1 tháng 7: Buổi chiều Trò chuyện với Head of Supply Chain (có vẻ ông ấy không hào hứng như CMO) "Thành thật mà nói tôi không biết mình có cần sự giúp đỡ của đội dữ liệu hay không" "Chúng tôi không có kiểu vấn đề đó. Điều chúng tôi cần là business analyst" "Tôi có cả một đội, và họ dành vài tiếng mỗi ngày để làm những mô hình cực kỳ phức tạp" "Họ thậm chí còn không có thời gian để trả lời những câu hỏi cơ bản của tôi." "Tôi có cả một bảng tính đầy những câu hỏi mà tôi muốn được giải đáp" (Nhìn vào bảng tính thì có những thứ như thế này) "So sánh tỷ lệ chuyển đổi giữa khách hàng được xử lý trong vòng 1 giờ sau khi tạo ticket và khách hàng được xử lý sau 1 giờ, phân loại theo khoảng giá trị đơn hàng 100 USD" (Khi hỏi về mô hình đó) Có vẻ phải sao chép vào đúng tab với đúng định dạng trong một Google Sheet gồm vô số VLOOKUP Dữ liệu được cập nhật hằng ngày, và mức độ ưu tiên trong ngày của đội được quyết định theo đầu ra của mô hình Chi phí chi trả cho các nhà cung cấp (vendor) cũng đang được tính bằng bảng tính (Về nhà và rót đầy một ly whisky.. ) [ Chuyện gì đã xảy ra vậy? ] Về cơ bản đây là mô tả (hơi cay đắng) về những gì xảy ra ở nhiều công ty đang ở giai đoạn đầu của mức độ trưởng thành dữ liệu Thiếu dữ liệu và dữ liệu bị phân mảnh → Sản phẩm không được instrumented đúng cách nên nhiều khi dữ liệu ngay từ đầu đã không tồn tại → Hệ thống dữ liệu bị phân mảnh, dữ liệu nằm rải rác ở nhiều hệ thống → Quy trình kinh doanh vận hành theo kiểu data-driven nhưng rất mong manh, gần như không có hoặc hoàn toàn không có tự động hóa Kỳ vọng không rõ ràng về việc đội dữ liệu phải làm gì → Data scientist được tuyển để làm R&D và triển khai AI - kết quả là không có mục tiêu kinh doanh rõ ràng → Đội dữ liệu phàn nàn rằng rất khó production hóa ML, nhưng bản thân đội sản phẩm lại không mấy quan tâm đến tính năng đó → Những người cần một "trình dịch English-to-SQL" Đội sản phẩm chưa được đào tạo theo hướng data-driven → Product manager không coi dữ liệu là công cụ để xây dựng tính năng tốt hơn → Thiếu sự alignment giữa những gì đội sản phẩm muốn xây và những gì đội dữ liệu đang có Về căn bản là một văn hóa xung đột với văn hóa lấy dữ liệu làm trung tâm → Văn hóa tôn vinh việc shipping chứ không phải tôn vinh tiến bộ có thể đo lường và việc học hỏi → Ngay cả những đội thực sự dùng metric cũng không nhất quán, đo lường không đúng cách, và đôi khi còn xung đột với các đội khác Không có data leadership → Tổ chức dữ liệu bị chia cắt, với nhiều nhân sự dữ liệu khác nhau báo cáo cho nhiều bộ phận/chức năng khác nhau → Các bộ phận khác không nhận được sự hỗ trợ cần thiết nên phải tuyển rất nhiều analyst xoay quanh đội dữ liệu → Thiếu chuẩn hóa về toolchain và các best practice (Ôi, thật u ám. Vậy cần làm gì để giải quyết vấn đề này đây?) Ngày 8 tháng 7 Bắt đầu thiết lập hướng đi mới cho đội dữ liệu từ tuần sau Có vẻ một người có kinh nghiệm về hạ tầng, nên giao cho anh ấy xây dựng data warehouse tập trung Trước mắt chỉ cần con đường nhanh nhất để gom dữ liệu về một chỗ Kế hoạch về cơ bản là dump production DB vào data warehouse mỗi giờ Framework đang dùng ở frontend cho ad tracking cũng có thể gửi lượng lớn event log, nhưng tạm ghi nhận đó là technical debt Cùng đội tuyển dụng xác định vai trò Generalist Data Role → Nhấn mạnh kỹ năng phần mềm cốt lõi, nhưng cũng cần thái độ generalist (làm được mọi thứ) và khả năng đồng cảm sâu sắc với yêu cầu kinh doanh → Tạm thời loại bỏ mọi nhắc đến trí tuệ nhân tạo và machine learning Dành thời gian với những nhân sự dữ liệu khác không báo cáo cho đội dữ liệu → Data scientist ở đội marketing là một người trẻ. "Tôi luôn muốn trở thành data scientist. Tôi muốn học được nhiều điều từ anh" Hỏi một người bạn đang vận hành coding bootcamp xem có khóa "đào tạo SQL" nào tốt không, và vì có nên quyết định triển khai vào cuối tháng này Soạn tài liệu trình bày cho đội sản phẩm để giải thích A/B test là gì và nó hoạt động ra sao → Cho thấy nhiều ví dụ về các thử nghiệm cho ra kết quả bất ngờ, → Và làm theo hướng tương tác để họ có thể đoán thử cái nào đã thắng Gặp trợ lý của CEO để tìm hiểu những "chỉ số mà họ muốn được báo cáo thông qua email tự động gửi hằng tuần" Nói chuyện với các nhà phân tích kinh doanh của đội Supply Chain thì thấy họ là những người rất hợp lý, nhưng trước đây đã bị tổn thương khi làm việc với đội dữ liệu Một trong số họ từng có kinh nghiệm dùng SQL. Thấy anh ấy đặt câu hỏi về tỷ lệ chuyển đổi nên đã cấp quyền truy cập data warehouse Thiết lập các buổi 1:1 hằng tuần với những người trên toàn tổ chức đang cần dữ liệu → Mấu chốt là tìm ra các khoảng trống dữ liệu (gap) và cơ hội rồi chuyển cho các data scientist → Các data scientist có thể thất vọng vì thứ tự ưu tiên cho nghiên cứu bị đẩy xuống → Vừa nói "hãy tập trung cung cấp giá trị kinh doanh càng sớm càng tốt", vừa nói thêm "chúng ta có thể sớm quay lại các công việc liên quan đến machine learning. Cứ xem sao đã" 1 tháng 9: buổi sáng Sau 3 tháng, giờ bắt đầu có cảm giác mọi thứ đang dần thành hình Gặp 1:1 hằng tuần với nhiều bên liên quan khác nhau và tiếp tục tìm các điểm mù lẫn cơ hội nơi dữ liệu có thể tạo ra thay đổi Dùng những gì tìm được để buộc chúng vào các công việc nền tảng cốt lõi của platform Để tạo các tập dữ liệu "phái sinh", cần xây dựng nhiều pipeline. Chi phí ban đầu khá lớn, nhưng khi đã có đúng dataset thì việc phân tích về sau sẽ dễ hơn rất nhiều Bắt đầu mở quyền truy cập data warehouse cho các bộ phận khác Họ bắt đầu tự dùng SQL để làm các phân tích cơ bản → Một việc rất tuyệt: một junior product manager phát hiện tỷ lệ chuyển đổi trên iOS Safari cực kỳ tệ. Đó là lỗi frontend liên quan đến localStorage và đã được sửa chỉ bằng một dòng Trưởng bộ phận supply chain gửi một email tức giận → Cơ sở dữ liệu thay đổi khiến truy vấn dài 500 dòng bị lỗi... → Giao việc sửa cho một data scientist đang càm ràm và treo thêm "củ cà rốt" khác: "Tôi sẽ tìm cho bạn một bài toán machine learning hay ho vào cuối tháng này" 1 tháng 9: buổi chiều Product manager của đội checkout vẫn chưa phân tích metric Data scientist của đội marketing nói chuyện với quản lý và quyết định sẽ trực tiếp báo cáo cho tôi [ Điều gì đang diễn ra? ] Đang xây nền tảng cơ bản cho những thứ cấp bách nhất → Làm cho dữ liệu quan trọng có thể được query tại một nơi → Mở quyền truy cập SQL và để các đội khác sử dụng, từ đó loại bỏ nhiều công việc kiểu "dịch SQL" Mặt khác, các đội khác có thể đi quá xa hơn vì sự tự do này. Có thể ngăn bằng cách đặt quyền hạn cho truy cập dữ liệu, nhưng như vậy lại có nhiều nhược điểm hơn Việc đội checkout không làm được phân tích dữ liệu là vì họ không biết phải hỏi ai Đây chủ yếu là vấn đề tổ chức → Các đội không biết cách cộng tác với đội dữ liệu → Họ không nhận ra nhưng đội dữ liệu có thể đang là nút thắt cổ chai Điều hợp lý nhất là "tập trung hóa việc báo cáo, và phân tán hóa quản lý công việc" → Vì dữ liệu và quyết định sẽ tạo ra một vòng phản hồi chặt chẽ hơn → Để các thành viên đội dữ liệu cộng tác cùng từng đội và chỉ báo cáo về cho tôi (trưởng nhóm dữ liệu) 2 tháng 9 Đội dữ liệu tăng lên 6 người → 1 người phụ trách hạ tầng data warehouse → 5 người được phân cho từng đội: onboarding, supply chain, checkout, marketing, và hỗ trợ CEO kiêm chuẩn bị tài liệu trình bày cho nhà đầu tư/hội đồng quản trị Giải thích sự thay đổi cho toàn công ty và làm rõ cần làm việc với ai cho từng nhu cầu dữ liệu Trong tương lai, dù có tuyển thêm nhân sự dữ liệu thì cũng sẽ phân họ cho các đội khác 3 tháng 1 Một data scientist quyết định rời đi. Vì cũng không có nhiều việc khiến anh ấy thấy hứng thú nên không cố giữ lại Trong đội có nhiều người mới. Những người có một ít kiến thức software engineering, biết SQL, và muốn tìm ra những điều thú vị trong dữ liệu → Vì họ là những người tìm "tin độc quyền" trong dữ liệu, nên nghĩ về họ như những "nhà báo dữ liệu" Với thành viên làm việc cùng đội onboarding → Phát hiện trong flow onboarding đang hỏi địa chỉ khách hàng dù thực ra không cần địa chỉ → Loại bỏ bước này giúp tỷ lệ chuyển đổi tăng 21% trong A/B test → Không hề dễ vì cần làm ETL để việc query dữ liệu trở nên dễ dàng hơn, nhưng Python đã hỗ trợ một chút nên cuối cùng vẫn làm được Báo cáo quý với CEO → PM của sáng kiến tăng trưởng giới thiệu bản thiết kế lại landing page vừa mới ra mắt → PM nhấn mạnh rằng 20 kỹ sư đã làm thêm giờ để kịp deadline → CMO cũng tham gia sâu vì đặt nhiều kỳ vọng vào Direct Mail như một phần của đợt redesign này → Câu hỏi của CEO: "Các chỉ số hiện tại thế nào? Chi phí thu hút khách hàng đã giảm chưa?" (Bạn đã chờ CEO hỏi những câu như vậy, nên khi nó xuất hiện đúng lúc thì mỉm cười) → PM cho thấy các con số trong phần phụ lục vì thực tế đã chạy A/B test → Một số chỉ số tăng, một số giảm, nên không có kết quả đủ ý nghĩa; còn chỉ số chi phí thu hút khách hàng thì trông không ổn lắm → CMO nhấn mạnh rằng các con số vẫn đang được hình thành và những chiến dịch kiểu này có thể mất vài tháng [ Điều gì đang diễn ra? ] Tin tốt là đội sản phẩm đã bắt đầu làm A/B test Tin xấu là phần lớn dự án vẫn được triển khai để khớp với milestone và deadline mang tính áp đặt, bất chấp kết quả Tin tốt nhất là CEO đang thúc đẩy các đội sử dụng dữ liệu như sự thật (truth) Khi tổ chức chịu áp lực để trở nên data-driven hơn, đội dữ liệu phải tăng tốc cách cộng tác với các đội khác Đặc biệt, ban lãnh đạo cấp cao sẽ tập trung hơn vào các chỉ số, và công việc của bạn là khiến đội dữ liệu phục vụ được các chỉ số đó Một trong những cách đơn giản nhất là bảo đảm mỗi đội đều có dashboard cho các chỉ số mà họ coi trọng 1 tháng 4 Những công việc machine learning trước đây mà đội dữ liệu từng thực hiện vẫn còn nguyên đó Data scientist làm việc với đội sản phẩm inventory quan tâm đến hệ thống recommendation đã làm trước đây Một thành viên mới được tuyển là kiểu generalist, nên đã biến notebook của hệ thống recommendation thành một ứng dụng Flask nhỏ và triển khai nội bộ Product manager của đội inventory xem và rất thích: "Làm sao để triển khai cái này?" Một trong những chỉ số chính của đội inventory là "giá trị đơn hàng trung bình", và họ tin recommendation này có thể cải thiện đáng kể chỉ số đó Chỉ cần ước lượng sơ bộ cũng thấy việc triển khai ở quy mô lớn sẽ khó, nhưng đã nêu ý tưởng: "Hay là thử triển khai cho chỉ 1% khách hàng thôi?" "Nghe hơi ngớ ngẩn nhưng chỉ cần tạo sẵn các sản phẩm gợi ý bằng Cron Job là được, chắc có thể làm trong vài ngày" Khi làm việc với đội supply chain, phát hiện thêm nhiều truy vấn SQL khổng lồ Chúng vẫn liên tục bị hỏng, nhưng đội dữ liệu đang chuyển chúng thành các pipeline bài bản Trưởng bộ phận supply chain yêu cầu tuyển thêm data scientist [ OK, rốt cuộc điều gì đang diễn ra? ] Trước hết, đã có hy vọng về những công việc machine learning thú vị Đội sản phẩm cuối cùng cũng hào hứng với việc ra mắt hệ thống recommendation dưới dạng một thử nghiệm nhỏ Trước đây điều này không thể tiến triển vì đội product engineering khó ước lượng công việc, không muốn trực tiếp đóng góp, còn đội dữ liệu thì không có kỹ năng productionize nó Điều giải quyết được vấn đề này là đội dữ liệu thực sự đã xây dựng một bản demo. Cách này không chỉ đưa nó tiến gần hơn tới production mà còn cho thấy rõ khả năng của nó Một chuyện khác là điều đang xảy ra với đội supply chain → Bắt đầu với vai trò "business analyst" nội bộ, nhưng để lấy được dữ liệu thì họ phải nhờ đội dữ liệu chạy query giúp → Các analyst bắt đầu tự chạy query với sự hỗ trợ từ đội dữ liệu → Trước hết, bắt đầu loại bỏ “nợ kỹ thuật trong bóng tối” (các truy vấn SQL khổng lồ như quái vật) từng gây ma sát với đội dữ liệu → Đội dữ liệu bắt đầu gắn với đội chuỗi cung ứng để hỗ trợ → Khi thành viên đội dữ liệu được nhúng vào các nhóm, nhu cầu về nhà phân tích kinh doanh giảm xuống và số lượng nhà khoa học dữ liệu tăng lên Hãy nhớ rằng khi ban đầu bắt đầu dump trực tiếp DB production vào data warehouse, bạn đã chấp nhận gánh lấy “nợ kỹ thuật” Lúc đầu sẽ có rất nhiều thứ hỏng, nhưng cần thêm một lớp để có thể truy vấn ổn định. Đây có thể là một khối lượng công việc rất lớn 1 tháng 7 Cuộc họp lập kế hoạch quý 3 → Trước đây mọi người từng tranh luận công ty sẽ đặt cược vào điều gì trong quý tiếp theo → Lần này, bạn trình bày các chỉ số cấp cao nhất của công ty, và từng nhóm trình bày cách họ phân rã các chỉ số cấp cao đó thông qua các chỉ số phụ của mình Công việc của đội quản lý sản phẩm đã mang lại kết quả → PM biện minh cho việc đầu tư vào dự án bằng cách nói về những gì học được khi chạy thử nghiệm hoặc những gì phát hiện ra từ dữ liệu Thành quả lớn là nhà khoa học dữ liệu làm việc với đội checkout đã phát hiện rằng khi người dùng nhấn nút quay lại ở trang xác nhận, đối tượng giỏ hàng trở nên bất thường → Sau khi sửa vấn đề này, tỷ lệ chuyển đổi đã tăng mạnh Một insight khác là lưu lượng đến từ các chiến dịch quảng cáo khác nhau có hồ sơ chuyển đổi rất khác nhau → Một số chiến dịch có giá mỗi lượt nhấp rẻ nhưng tỷ lệ chuyển đổi rất tệ, còn các chiến dịch khác thì tốn kém nhưng tỷ lệ chuyển đổi lại rất cao Bằng cách theo dõi biến UTM và liên kết chúng với việc tạo tài khoản, giờ đây đã có thể đo tỷ lệ chuyển đổi từ cú nhấp quảng cáo đến mua hàng → Điều này trước đây là không thể cho đến khi toàn bộ dữ liệu được đưa vào cùng một data warehouse và chuẩn hóa để có thể truy vấn dễ dàng → Phối hợp với marketing, KPI chính không phải là chi phí mỗi lượt nhấp mà là chi phí thu hút khách hàng end-to-end Một tin thú vị khác là bài test hệ thống gợi ý 1% đã thành công một cách khác thường → Việc mở rộng lên 100% người dùng là một dự án rất lớn, nhưng CEO đã phê duyệt dự án đó Không phải mọi kết quả đều tích cực, nhiều thử nghiệm đã thất bại. → Một trong các slide là phần giải thích về bài test trong đó phí giao hàng không bị tính riêng mà được gộp vào giá → CEO nói như sau: “Chúng ta đã học được gì từ đây?” → Điều này lại dẫn đến một cuộc trao đổi để lên kế hoạch cho chuỗi thử nghiệm tiếp theo (Về nhà rồi khui champagne) [Chuyện gì đã xảy ra vậy?] Bạn đã làm được. Bạn đã chuyển đổi tổ chức thành một nơi thực sự data-native. Đội dữ liệu làm việc liên chức năng với nhiều bên liên quan khác nhau. Dữ liệu và insight được sử dụng trong việc lập kế hoạch, và dữ liệu được dùng để tạo ra giá trị kinh doanh chứ không phải cho nghiên cứu mơ hồ về mục tiêu. Công ty sử dụng vòng phản hồi nhanh dựa trên dữ liệu để làm việc theo cách lặp thay vì lập kế hoạch kiểu “waterfall” quy mô lớn. Các chỉ số được định nghĩa theo cách có thể tạo ra giá trị kinh doanh và khiến mọi người có trách nhiệm với chúng. Văn hóa dữ liệu được dẫn dắt từ cả trên xuống (CEO thúc đẩy) lẫn từ dưới lên (nhân viên). Nếu ít nhất đã học được điều gì đó thì thất bại cũng không sao. (Chúc mừng. Bạn xứng đáng nâng ly champagne)

(erikbern.com)

39 điểm bởi xguru 2021-07-12 | 7 bình luận | Chia sẻ qua WhatsApp

Câu chuyện của một người gia nhập để xây dựng một đội dữ liệu nhỏ khoảng 4 người tại một startup giai đoạn mid-stage với doanh thu thường niên khoảng 10 tỷ won
Đây là bài viết mang tính ẩn dụ dựa trên một vài trải nghiệm, và có thể thiên lệch*, nên hãy cân nhắc khi đọc

Ngày 1 tháng 7: Buổi sáng

Ngày đầu đi làm với vai trò trưởng nhóm dữ liệu
Chào hỏi CMO

(CMO rất phấn khích vì tôi đã đến, kể rằng công ty của bạn mình đang dùng AI để phân khúc khách hàng và trông rất ngầu)

(Sau vài câu chuyện ngắn, tôi tìm hiểu về thực hành dữ liệu của đội marketing)

DATA: "Chi phí thu hút khách hàng (CAC) thế nào rồi?"

CMO: "Ừm.. thực ra rất tuyệt. Data scientist của chúng tôi đã đo và chi phí mỗi lượt nhấp đang giảm dần"

DATA: (Tôi nghe nói tất cả data scientist đều báo cáo cho đội dữ liệu, vậy mà lại có data scientist ở tổ chức khác sao?)

CMO: "Vấn đề thật sự là đội Growth không chuyển đổi được toàn bộ lượng truy cập mà chúng tôi đưa về website"

DATA: "Có dashboard nào để xem conversion funnel không?"

CMO: "Chuyển đổi lead là việc của đội Growth mà."

Trò chuyện với một Product Manager

PM vừa thiết kế lại toàn bộ trang khởi đầu đang rất phấn khích vì số người đăng ký tăng tới 14%

DATA: "Chênh lệch đó có ý nghĩa thống kê không?"

PM: "Đó không phải việc của tôi mà là việc của đội anh chứ"

PM: "Lần trước khi chúng tôi hỏi, đội dữ liệu nói là không có dữ liệu, và để lấy được dữ liệu thì phải mất vài tháng"

PM: "Điều đáng kinh ngạc là chúng tôi đã không thay đổi theo kiểu incremental. Chúng tôi quyết định không A/B test thay đổi này. Đôi khi phải đặt cược lớn để thoát khỏi cực trị cục bộ (Local Maxima)."

PM: "Steve Jobs đã không A/B test khi ra mắt iPhone. Đội chúng tôi launch cái này trước deadline 2 ngày, và đó mới là điều quan trọng!"

DATA: (Giả vờ bận rộn rồi ghi nguệch ngoạc vào sổ tay)

Trò chuyện với các thành viên mới của đội

→ Hiện là đội 3 người nhưng đã có ngân sách để tăng lên 10 người vào cuối năm

→ Có vẻ các thành viên rất hào hứng vì tôi đến

→ Họ cho tôi xem những gì đã làm. Có khá nhiều thứ, và một vài trong số đó khá ấn tượng

✓ Mạng nơ-ron để dự đoán rời bỏ người dùng (Churn Prediction)

✓ Notebook đã triển khai hệ thống gợi ý sản phẩm liên quan

→ Nhiều đoạn code bắt đầu bằng bước tiền xử lý rất phức tạp, phải lấy dữ liệu từ nhiều hệ thống khác nhau

✓ Có vẻ để làm một phần việc này thì phải chạy thủ công nhiều script theo đúng thứ tự

→ Khi tôi hỏi vì sao chưa đưa vào production

✓ Các kỹ sư nói rằng để làm nó đạt cấp độ production thì sẽ là một dự án rất lớn

✓ Product Manager đã đưa vào backlog nhưng liên tục bị đẩy lùi vì các việc khác cứ phát sinh

✓ Họ nói việc này cần có sự hậu thuẫn của ban lãnh đạo

Ngày 1 tháng 7: Buổi chiều

Trò chuyện với Head of Supply Chain (có vẻ ông ấy không hào hứng như CMO)

"Thành thật mà nói tôi không biết mình có cần sự giúp đỡ của đội dữ liệu hay không"

"Chúng tôi không có kiểu vấn đề đó. Điều chúng tôi cần là business analyst"

"Tôi có cả một đội, và họ dành vài tiếng mỗi ngày để làm những mô hình cực kỳ phức tạp"

"Họ thậm chí còn không có thời gian để trả lời những câu hỏi cơ bản của tôi."

"Tôi có cả một bảng tính đầy những câu hỏi mà tôi muốn được giải đáp"

(Nhìn vào bảng tính thì có những thứ như thế này) "So sánh tỷ lệ chuyển đổi giữa khách hàng được xử lý trong vòng 1 giờ sau khi tạo ticket và khách hàng được xử lý sau 1 giờ, phân loại theo khoảng giá trị đơn hàng 100 USD"

(Khi hỏi về mô hình đó)

Có vẻ phải sao chép vào đúng tab với đúng định dạng trong một Google Sheet gồm vô số VLOOKUP
Dữ liệu được cập nhật hằng ngày, và mức độ ưu tiên trong ngày của đội được quyết định theo đầu ra của mô hình
Chi phí chi trả cho các nhà cung cấp (vendor) cũng đang được tính bằng bảng tính

(Về nhà và rót đầy một ly whisky.. )

[ Chuyện gì đã xảy ra vậy? ]

Về cơ bản đây là mô tả (hơi cay đắng) về những gì xảy ra ở nhiều công ty đang ở giai đoạn đầu của mức độ trưởng thành dữ liệu
Thiếu dữ liệu và dữ liệu bị phân mảnh

→ Sản phẩm không được instrumented đúng cách nên nhiều khi dữ liệu ngay từ đầu đã không tồn tại

→ Hệ thống dữ liệu bị phân mảnh, dữ liệu nằm rải rác ở nhiều hệ thống

→ Quy trình kinh doanh vận hành theo kiểu data-driven nhưng rất mong manh, gần như không có hoặc hoàn toàn không có tự động hóa

Kỳ vọng không rõ ràng về việc đội dữ liệu phải làm gì

→ Data scientist được tuyển để làm R&D và triển khai AI - kết quả là không có mục tiêu kinh doanh rõ ràng

→ Đội dữ liệu phàn nàn rằng rất khó production hóa ML, nhưng bản thân đội sản phẩm lại không mấy quan tâm đến tính năng đó

→ Những người cần một "trình dịch English-to-SQL"

Đội sản phẩm chưa được đào tạo theo hướng data-driven

→ Product manager không coi dữ liệu là công cụ để xây dựng tính năng tốt hơn

→ Thiếu sự alignment giữa những gì đội sản phẩm muốn xây và những gì đội dữ liệu đang có

Về căn bản là một văn hóa xung đột với văn hóa lấy dữ liệu làm trung tâm

→ Văn hóa tôn vinh việc shipping chứ không phải tôn vinh tiến bộ có thể đo lường và việc học hỏi

→ Ngay cả những đội thực sự dùng metric cũng không nhất quán, đo lường không đúng cách, và đôi khi còn xung đột với các đội khác

Không có data leadership

→ Tổ chức dữ liệu bị chia cắt, với nhiều nhân sự dữ liệu khác nhau báo cáo cho nhiều bộ phận/chức năng khác nhau

→ Các bộ phận khác không nhận được sự hỗ trợ cần thiết nên phải tuyển rất nhiều analyst xoay quanh đội dữ liệu

→ Thiếu chuẩn hóa về toolchain và các best practice

(Ôi, thật u ám. Vậy cần làm gì để giải quyết vấn đề này đây?)

Ngày 8 tháng 7

Bắt đầu thiết lập hướng đi mới cho đội dữ liệu từ tuần sau
Có vẻ một người có kinh nghiệm về hạ tầng, nên giao cho anh ấy xây dựng data warehouse tập trung
Trước mắt chỉ cần con đường nhanh nhất để gom dữ liệu về một chỗ
Kế hoạch về cơ bản là dump production DB vào data warehouse mỗi giờ
Framework đang dùng ở frontend cho ad tracking cũng có thể gửi lượng lớn event log, nhưng tạm ghi nhận đó là technical debt
Cùng đội tuyển dụng xác định vai trò Generalist Data Role

→ Nhấn mạnh kỹ năng phần mềm cốt lõi, nhưng cũng cần thái độ generalist (làm được mọi thứ) và khả năng đồng cảm sâu sắc với yêu cầu kinh doanh

→ Tạm thời loại bỏ mọi nhắc đến trí tuệ nhân tạo và machine learning

Dành thời gian với những nhân sự dữ liệu khác không báo cáo cho đội dữ liệu

→ Data scientist ở đội marketing là một người trẻ. "Tôi luôn muốn trở thành data scientist. Tôi muốn học được nhiều điều từ anh"

Hỏi một người bạn đang vận hành coding bootcamp xem có khóa "đào tạo SQL" nào tốt không, và vì có nên quyết định triển khai vào cuối tháng này
Soạn tài liệu trình bày cho đội sản phẩm để giải thích A/B test là gì và nó hoạt động ra sao

→ Cho thấy nhiều ví dụ về các thử nghiệm cho ra kết quả bất ngờ,

→ Và làm theo hướng tương tác để họ có thể đoán thử cái nào đã thắng

Gặp trợ lý của CEO để tìm hiểu những "chỉ số mà họ muốn được báo cáo thông qua email tự động gửi hằng tuần"
Nói chuyện với các nhà phân tích kinh doanh của đội Supply Chain thì thấy họ là những người rất hợp lý, nhưng trước đây đã bị tổn thương khi làm việc với đội dữ liệu
Một trong số họ từng có kinh nghiệm dùng SQL. Thấy anh ấy đặt câu hỏi về tỷ lệ chuyển đổi nên đã cấp quyền truy cập data warehouse
Thiết lập các buổi 1:1 hằng tuần với những người trên toàn tổ chức đang cần dữ liệu

→ Mấu chốt là tìm ra các khoảng trống dữ liệu (gap) và cơ hội rồi chuyển cho các data scientist

→ Các data scientist có thể thất vọng vì thứ tự ưu tiên cho nghiên cứu bị đẩy xuống

→ Vừa nói "hãy tập trung cung cấp giá trị kinh doanh càng sớm càng tốt", vừa nói thêm "chúng ta có thể sớm quay lại các công việc liên quan đến machine learning. Cứ xem sao đã"

1 tháng 9: buổi sáng

Sau 3 tháng, giờ bắt đầu có cảm giác mọi thứ đang dần thành hình
Gặp 1:1 hằng tuần với nhiều bên liên quan khác nhau và tiếp tục tìm các điểm mù lẫn cơ hội nơi dữ liệu có thể tạo ra thay đổi
Dùng những gì tìm được để buộc chúng vào các công việc nền tảng cốt lõi của platform
Để tạo các tập dữ liệu "phái sinh", cần xây dựng nhiều pipeline. Chi phí ban đầu khá lớn, nhưng khi đã có đúng dataset thì việc phân tích về sau sẽ dễ hơn rất nhiều
Bắt đầu mở quyền truy cập data warehouse cho các bộ phận khác
Họ bắt đầu tự dùng SQL để làm các phân tích cơ bản

→ Một việc rất tuyệt: một junior product manager phát hiện tỷ lệ chuyển đổi trên iOS Safari cực kỳ tệ. Đó là lỗi frontend liên quan đến localStorage và đã được sửa chỉ bằng một dòng

Trưởng bộ phận supply chain gửi một email tức giận

→ Cơ sở dữ liệu thay đổi khiến truy vấn dài 500 dòng bị lỗi...

→ Giao việc sửa cho một data scientist đang càm ràm và treo thêm "củ cà rốt" khác: "Tôi sẽ tìm cho bạn một bài toán machine learning hay ho vào cuối tháng này"

1 tháng 9: buổi chiều

Product manager của đội checkout vẫn chưa phân tích metric
Data scientist của đội marketing nói chuyện với quản lý và quyết định sẽ trực tiếp báo cáo cho tôi

[ Điều gì đang diễn ra? ]

Đang xây nền tảng cơ bản cho những thứ cấp bách nhất

→ Làm cho dữ liệu quan trọng có thể được query tại một nơi

→ Mở quyền truy cập SQL và để các đội khác sử dụng, từ đó loại bỏ nhiều công việc kiểu "dịch SQL"

Mặt khác, các đội khác có thể đi quá xa hơn vì sự tự do này. Có thể ngăn bằng cách đặt quyền hạn cho truy cập dữ liệu, nhưng như vậy lại có nhiều nhược điểm hơn
Việc đội checkout không làm được phân tích dữ liệu là vì họ không biết phải hỏi ai
Đây chủ yếu là vấn đề tổ chức

→ Các đội không biết cách cộng tác với đội dữ liệu

→ Họ không nhận ra nhưng đội dữ liệu có thể đang là nút thắt cổ chai

Điều hợp lý nhất là "tập trung hóa việc báo cáo, và phân tán hóa quản lý công việc"

→ Vì dữ liệu và quyết định sẽ tạo ra một vòng phản hồi chặt chẽ hơn

→ Để các thành viên đội dữ liệu cộng tác cùng từng đội và chỉ báo cáo về cho tôi (trưởng nhóm dữ liệu)

2 tháng 9

Đội dữ liệu tăng lên 6 người

→ 1 người phụ trách hạ tầng data warehouse

→ 5 người được phân cho từng đội: onboarding, supply chain, checkout, marketing, và hỗ trợ CEO kiêm chuẩn bị tài liệu trình bày cho nhà đầu tư/hội đồng quản trị

Giải thích sự thay đổi cho toàn công ty và làm rõ cần làm việc với ai cho từng nhu cầu dữ liệu
Trong tương lai, dù có tuyển thêm nhân sự dữ liệu thì cũng sẽ phân họ cho các đội khác

3 tháng 1

Một data scientist quyết định rời đi. Vì cũng không có nhiều việc khiến anh ấy thấy hứng thú nên không cố giữ lại
Trong đội có nhiều người mới. Những người có một ít kiến thức software engineering, biết SQL, và muốn tìm ra những điều thú vị trong dữ liệu

→ Vì họ là những người tìm "tin độc quyền" trong dữ liệu, nên nghĩ về họ như những "nhà báo dữ liệu"

Với thành viên làm việc cùng đội onboarding

→ Phát hiện trong flow onboarding đang hỏi địa chỉ khách hàng dù thực ra không cần địa chỉ

→ Loại bỏ bước này giúp tỷ lệ chuyển đổi tăng 21% trong A/B test

→ Không hề dễ vì cần làm ETL để việc query dữ liệu trở nên dễ dàng hơn, nhưng Python đã hỗ trợ một chút nên cuối cùng vẫn làm được

Báo cáo quý với CEO

→ PM của sáng kiến tăng trưởng giới thiệu bản thiết kế lại landing page vừa mới ra mắt

→ PM nhấn mạnh rằng 20 kỹ sư đã làm thêm giờ để kịp deadline

→ CMO cũng tham gia sâu vì đặt nhiều kỳ vọng vào Direct Mail như một phần của đợt redesign này

→ Câu hỏi của CEO: "Các chỉ số hiện tại thế nào? Chi phí thu hút khách hàng đã giảm chưa?"

(Bạn đã chờ CEO hỏi những câu như vậy, nên khi nó xuất hiện đúng lúc thì mỉm cười)

→ PM cho thấy các con số trong phần phụ lục vì thực tế đã chạy A/B test

→ Một số chỉ số tăng, một số giảm, nên không có kết quả đủ ý nghĩa; còn chỉ số chi phí thu hút khách hàng thì trông không ổn lắm

→ CMO nhấn mạnh rằng các con số vẫn đang được hình thành và những chiến dịch kiểu này có thể mất vài tháng

[ Điều gì đang diễn ra? ]

Tin tốt là đội sản phẩm đã bắt đầu làm A/B test
Tin xấu là phần lớn dự án vẫn được triển khai để khớp với milestone và deadline mang tính áp đặt, bất chấp kết quả
Tin tốt nhất là CEO đang thúc đẩy các đội sử dụng dữ liệu như sự thật (truth)
Khi tổ chức chịu áp lực để trở nên data-driven hơn, đội dữ liệu phải tăng tốc cách cộng tác với các đội khác
Đặc biệt, ban lãnh đạo cấp cao sẽ tập trung hơn vào các chỉ số, và công việc của bạn là khiến đội dữ liệu phục vụ được các chỉ số đó
Một trong những cách đơn giản nhất là bảo đảm mỗi đội đều có dashboard cho các chỉ số mà họ coi trọng

1 tháng 4

Những công việc machine learning trước đây mà đội dữ liệu từng thực hiện vẫn còn nguyên đó
Data scientist làm việc với đội sản phẩm inventory quan tâm đến hệ thống recommendation đã làm trước đây
Một thành viên mới được tuyển là kiểu generalist, nên đã biến notebook của hệ thống recommendation thành một ứng dụng Flask nhỏ và triển khai nội bộ
Product manager của đội inventory xem và rất thích: "Làm sao để triển khai cái này?"
Một trong những chỉ số chính của đội inventory là "giá trị đơn hàng trung bình", và họ tin recommendation này có thể cải thiện đáng kể chỉ số đó
Chỉ cần ước lượng sơ bộ cũng thấy việc triển khai ở quy mô lớn sẽ khó, nhưng đã nêu ý tưởng: "Hay là thử triển khai cho chỉ 1% khách hàng thôi?"
"Nghe hơi ngớ ngẩn nhưng chỉ cần tạo sẵn các sản phẩm gợi ý bằng Cron Job là được, chắc có thể làm trong vài ngày"
Khi làm việc với đội supply chain, phát hiện thêm nhiều truy vấn SQL khổng lồ
Chúng vẫn liên tục bị hỏng, nhưng đội dữ liệu đang chuyển chúng thành các pipeline bài bản
Trưởng bộ phận supply chain yêu cầu tuyển thêm data scientist

[ OK, rốt cuộc điều gì đang diễn ra? ]

Trước hết, đã có hy vọng về những công việc machine learning thú vị
Đội sản phẩm cuối cùng cũng hào hứng với việc ra mắt hệ thống recommendation dưới dạng một thử nghiệm nhỏ
Trước đây điều này không thể tiến triển vì đội product engineering khó ước lượng công việc, không muốn trực tiếp đóng góp, còn đội dữ liệu thì không có kỹ năng productionize nó
Điều giải quyết được vấn đề này là đội dữ liệu thực sự đã xây dựng một bản demo. Cách này không chỉ đưa nó tiến gần hơn tới production mà còn cho thấy rõ khả năng của nó
Một chuyện khác là điều đang xảy ra với đội supply chain

→ Bắt đầu với vai trò "business analyst" nội bộ, nhưng để lấy được dữ liệu thì họ phải nhờ đội dữ liệu chạy query giúp

→ Các analyst bắt đầu tự chạy query với sự hỗ trợ từ đội dữ liệu

→ Trước hết, bắt đầu loại bỏ “nợ kỹ thuật trong bóng tối” (các truy vấn SQL khổng lồ như quái vật) từng gây ma sát với đội dữ liệu

→ Đội dữ liệu bắt đầu gắn với đội chuỗi cung ứng để hỗ trợ

→ Khi thành viên đội dữ liệu được nhúng vào các nhóm, nhu cầu về nhà phân tích kinh doanh giảm xuống và số lượng nhà khoa học dữ liệu tăng lên

Hãy nhớ rằng khi ban đầu bắt đầu dump trực tiếp DB production vào data warehouse, bạn đã chấp nhận gánh lấy “nợ kỹ thuật”
Lúc đầu sẽ có rất nhiều thứ hỏng, nhưng cần thêm một lớp để có thể truy vấn ổn định. Đây có thể là một khối lượng công việc rất lớn

1 tháng 7

Cuộc họp lập kế hoạch quý 3

→ Trước đây mọi người từng tranh luận công ty sẽ đặt cược vào điều gì trong quý tiếp theo

→ Lần này, bạn trình bày các chỉ số cấp cao nhất của công ty, và từng nhóm trình bày cách họ phân rã các chỉ số cấp cao đó thông qua các chỉ số phụ của mình

Công việc của đội quản lý sản phẩm đã mang lại kết quả

→ PM biện minh cho việc đầu tư vào dự án bằng cách nói về những gì học được khi chạy thử nghiệm hoặc những gì phát hiện ra từ dữ liệu

Thành quả lớn là nhà khoa học dữ liệu làm việc với đội checkout đã phát hiện rằng khi người dùng nhấn nút quay lại ở trang xác nhận, đối tượng giỏ hàng trở nên bất thường

→ Sau khi sửa vấn đề này, tỷ lệ chuyển đổi đã tăng mạnh

Một insight khác là lưu lượng đến từ các chiến dịch quảng cáo khác nhau có hồ sơ chuyển đổi rất khác nhau

→ Một số chiến dịch có giá mỗi lượt nhấp rẻ nhưng tỷ lệ chuyển đổi rất tệ, còn các chiến dịch khác thì tốn kém nhưng tỷ lệ chuyển đổi lại rất cao

Bằng cách theo dõi biến UTM và liên kết chúng với việc tạo tài khoản, giờ đây đã có thể đo tỷ lệ chuyển đổi từ cú nhấp quảng cáo đến mua hàng

→ Điều này trước đây là không thể cho đến khi toàn bộ dữ liệu được đưa vào cùng một data warehouse và chuẩn hóa để có thể truy vấn dễ dàng

→ Phối hợp với marketing, KPI chính không phải là chi phí mỗi lượt nhấp mà là chi phí thu hút khách hàng end-to-end

Một tin thú vị khác là bài test hệ thống gợi ý 1% đã thành công một cách khác thường

→ Việc mở rộng lên 100% người dùng là một dự án rất lớn, nhưng CEO đã phê duyệt dự án đó

Không phải mọi kết quả đều tích cực, nhiều thử nghiệm đã thất bại.

→ Một trong các slide là phần giải thích về bài test trong đó phí giao hàng không bị tính riêng mà được gộp vào giá

→ CEO nói như sau: “Chúng ta đã học được gì từ đây?”

→ Điều này lại dẫn đến một cuộc trao đổi để lên kế hoạch cho chuỗi thử nghiệm tiếp theo

(Về nhà rồi khui champagne)

[Chuyện gì đã xảy ra vậy?]

Bạn đã làm được.
Bạn đã chuyển đổi tổ chức thành một nơi thực sự data-native.
Đội dữ liệu làm việc liên chức năng với nhiều bên liên quan khác nhau.
Dữ liệu và insight được sử dụng trong việc lập kế hoạch, và dữ liệu được dùng để tạo ra giá trị kinh doanh chứ không phải cho nghiên cứu mơ hồ về mục tiêu.
Công ty sử dụng vòng phản hồi nhanh dựa trên dữ liệu để làm việc theo cách lặp thay vì lập kế hoạch kiểu “waterfall” quy mô lớn.
Các chỉ số được định nghĩa theo cách có thể tạo ra giá trị kinh doanh và khiến mọi người có trách nhiệm với chúng.
Văn hóa dữ liệu được dẫn dắt từ cả trên xuống (CEO thúc đẩy) lẫn từ dưới lên (nhân viên).
Nếu ít nhất đã học được điều gì đó thì thất bại cũng không sao.

(Chúc mừng. Bạn xứng đáng nâng ly champagne)

7 bình luận

hangnim 2022-08-05

Đọc phần đầu mà tôi cứ tưởng đang nói về công ty mình,,,, hu hu (tất nhiên là bên tôi còn chẳng có cả team dữ liệu nữa haha)

dajoa 2021-07-21

Tôi đã đọc rất thú vị. Cảm ơn bạn~!

shawn 2021-07-13

Có cảm giác như đang xem một tập trong bộ phim về startup công nghệ mà các kỹ sư hẳn sẽ rất thích. Rất thú vị! 👍

hangnim 2022-08-05

22222

laeyoung 2021-07-13

Trông có vẻ là rất đông người, mà mức này đã là mid-stage rồi à

xguru 2021-07-13

Có lẽ quy mô được nhìn nhận sẽ hơi khác so với trong nước.

xguru 2021-07-12

Với từ thiên về quan điểm (Opinionated)* thì khá khó dịch gọn gàng, nhưng tôi thường dùng là "thiên kiến" theo nghĩa "có sự phản ánh ý kiến của bản thân nên mang tính thiên lệch".

Về điểm này, có bài viết của người khác nên bạn có thể tham khảo

Ý nghĩa của opinionated (thiên kiến) như một thuật ngữ máy tính https://www.clien.net/service/board/cm_app/13558026

Ngoài ra, bài gốc vốn được viết theo kiểu diễn giải dài, nên tôi đã cấu trúc lại một chút theo văn nói để dễ đọc hơn.

Xây dựng đội dữ liệu trong startup

Bài viết liên quan

7 bình luận