Công việc không giống nhau
Có những công việc, tên thì giống nhau, nhưng mà lại có nhiều sự khác biệt.
Lời khuyên của người đi trước
Với một chút lăn lộn trong ngành công nghệ cũng được một thời gian, mình cũng tự cho bản thân là mình cũng có một chút hiểu biết về các công việc, các chức danh khác nhau ở trong ngành. Mình cũng có hứng thú chia sẻ và dạy đời nữa, nên cũng thường xuyên cũng để ý theo dõi các chia sẻ cũng như content trên mạng.
Có lẽ các bạn trẻ cũng đều có một chút hoang mang khi mới tham gia môi trường làm việc, thế nên mình có thể thấy một chủ đề vô cùng thu hút người theo dõi, đó là những chia sẻ về nghề nghiệp, về công việc, về kinh nghiệm của những người trong ngành đi trước (và đương nhiên, cũng có cả ngàn khoá học khác nhau được bán nữa). Các lời khuyên chắc cũng không có quá ý nghĩa đối với mình, nhưng mà mình thì thường để ý xem là những lời khuyên này được đưa ra có hợp lý hay không, phù hợp với ngữ cảnh như thế nào.
Một thứ hay ho mà mình có thể để ý, đó là cùng một chức danh, cùng một nghề nghiệp, nhưng mà có một số title thì sẽ có những trải nghiệm vô cùng khác biệt. Hai thứ mà mình hay để ý nhất, đó là về Data, cũng như là Products — nghe như câu chuyện của mọi người, mỗi người đều có những trải nghiệm và cuộc sống khác biệt. Đem so sánh với Backend Engineer, khi tất cả mọi người đều trải nghiệm gần với việc viết code cho server-side, thiết lập API; hay là Frontend Engineer khi mọi người làm việc đều thiên hướng rõ ràng về việc xây dựng giao diện — khi bạn nói về Data và Products, trải nghiệm của mọi người sẽ không được thống nhất. Data thì có thể làm từ xây dựng hệ thống dữ liệu đến viết script vẽ charts làm BI; products thì từ việc quản lý sprints đến viết PRD, đến cả đi nói chuyện với stakeholders hàng ngày, mỗi công ty lại có một hình dạng, một job scope khác nhau.
Đây không phải là một kết luận, là công việc A sẽ đơn điệu và dễ đoán hơn công việc B. Nó như một cảm nhận của bản thân mình, về sự khác biệt về chia sẻ cho từng công việc nhất định.
Làm Data là sao?
Cảm nhận chung của mình về Data, đó là công việc của bạn sẽ đi theo ngành nghề, theo business domain của công ty đang theo đuổi, và nó sẽ set the tone cho những công việc bạn phải làm.
Điều mà mọi công ty đều (bảo rằng họ đang) theo đuổi, đó là data-driven. Thế nhưng data-driven có những mặt khác nhau của nó, đó là sử dụng dữ liệu vào mục đích gì. Một cách hiểu nôm na, doanh nghiệp sẽ dùng dữ liệu cho hai hướng: tối ưu (optimize) những quy trình, những nghiệp vụ họ đang có; hoặc là phát triển thêm những nghiệp vụ mới, sản phẩm mới (r&d) để họ có thể mở rộng kinh doanh. Hai chiều hướng khác nhau, nhưng đều mang trên mình ý nghĩa của data-driven decision.
Một góc cạnh khác để xem xét về cách sử dụng dữ liệu, đó là analysis (backward-looking) và predictive (forward-looking). Nghiệp vụ dữ liệu khi bạn làm nhiều về mặt báo cáo, reporting, đánh giá lại những gì đã xảy ra trong quá khứ, đòi hỏi sự chính xác cao độ. Còn khi bạn muốn dự đoán được tương lai, thì sẽ có nhiều chiều hướng để tối ưu: bạn có thể ưu tiên về độ chính xác, mức độ rủi ro, hoặc là cân bằng hiệu quả và ngân sách để vạch ra kế hoạch trước mắt.
Nhưng, thứ quan trọng nhất sẽ quyết định bạn làm gì trong công việc hàng ngày, thì đó lại là doanh nghiệp của bạn thuộc về chuyên ngành gì, và họ có những bài toán nào. Nếu bạn làm trong ngân hàng hoặc tài chính, bạn sẽ phải làm nhiều về báo cáo để phục vụ compliance, cũng như bài toán tối quan trọng sẽ thuộc về credit scoring model. Nhưng nếu bạn làm trong ecommerce hay adtech, thì lại có rất nhiều bài toán về realtime recommendation/ad-serving, xử lý tối ưu hoá thời gian thực. Một doanh nghiệp sản xuất và kinh doanh FMCG, bài toán sẽ nằm rất nhiều về Demand Forecast and Planning, vì tối ưu chuỗi cung ứng sẽ quyết định cho độ hiệu quả của doanh nghiệp. Rồi những bài toán IoT, hoặc Customer Segmentation, tối ưu logistics, vân vân và mây mây. Sự khác biệt về bài toán của doanh nghiệp, cũng sẽ là gốc rễ để vẽ ra các mảnh đời khác nhau cho “dân Data”. Bạn có thể phải xử lý hàng tỷ record mỗi lần, nhưng cũng có thể là chỉ cần vẽ charts và send reports hàng ngày, mọi thứ đều có thể xảy ra cho cuộc đời Data.
Còn Products thì sao?
Một điều mình nhận thấy về mặt Data, đó là nếu bạn hiểu về những thứ công ty đang làm, thì bạn có thể hơi mường tượng về cuộc sống Data ở đó một chút. Nhưng điều đó thì lại không áp dụng được với Products, vì Products thì nó lại không phụ thuộc theo ngành.
Products, về bản chất, là một role thường được tính là “glue work”, là mảnh ghép để kết nối được các bộ phận khác nhau hoạt động một cách trơn tru. Điều tạo nên sự khác biệt cho công việc của Products, thực ra về sự khác nhau cũng như tương tác giữa các mảnh ghép đó. Thế nên, công việc Products nó sẽ thể hiện ra dynamics của các team trong cùng 1 doanh nghiệp, và nó sẽ rất khác biệt, mỗi nơi một khác.
Nếu công ty của bạn hoạt động theo kiểu chỉ đạo từ trên xuống dưới, đôi khi Products sẽ phải làm những việc như là biến lời nói của CEO thành thời gian, hành động và timeline; nhưng nếu Product có ownership thì họ có thể là người đưa ra những quy chuẩn để CEO tham gia vào việc đánh giá. Nếu Engineering team của bạn có product sense tốt, họ có thể hình thành 70-80% giải pháp, và Product Manager sẽ không cần viết PRD sát sao đến từng centimet — tuy nhiên nếu team Engineering chỉ là những người nhận requirement và làm, thì PM sẽ cần vẽ từng diagram, chú thích từng dòng trong design doc để đảm bảo là các yêu cầu được liệt kê đầy đủ. Nếu UI/UX design hiểu được sự khó khăn của Engineering cũng như thiết kế chuẩn mực, PM có thể được quản trị theo những simplified metrics, chứ không phải đi check và align từng pixel một trong Figma.
Điều này cũng rất khác biệt cho những công ty có Product orgs phát triển mạnh mẽ và chuyên nghiệp, so với những công ty mới còn đang chập chững để theo đuổi tư duy Products. Bạn có thể nghe những chia sẻ hào nhoáng từ các PM các công ty top trên thế giới như Google, Meta — nhưng mà những thứ các PM được làm ở những công ty đó sẽ hoàn toàn khác biệt với trải nghiệm thực tế của bạn. Khi bạn là keo dán, phải dán ở đúng chỗ, ở những nơi cần được kết nối và giải quyết, chứ không thể cứng nhắc và tư duy về công việc như một thứ cố định được.
Lắng nghe với ngữ cảnh
Để quay lại câu chuyện ban đầu, đó là về việc lắng nghe và học theo những lời chỉ dẫn trên mạng xã hội. Cùng một title, nhưng nội dung và trách nhiệm của công việc có thể có sự khác biệt rất xa xôi. Lắng nghe, nhưng cũng stay critical, để bản thân có một cái nhìn khách quan hơn, và không chỉ đi theo các lời khuyên bảo một cách mù mờ :).
🎉