Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
BA ở công ty product và BA ở công ty outsourcing khác nhau thế nào trong một tuần làm việc, thị trường Việt Nam còn những chỗ nào nằm giữa hai ô đó, và người mới nên tính ra sao.

Câu hỏi này xuất hiện trong gần như mọi buổi tư vấn nghề BA: nên vào công ty product hay công ty outsourcing?
Và câu trả lời hay gặp nhất cũng là câu vô dụng nhất — "tuỳ bạn thôi".
Bài trước đã nói về các loại dự án IT mà BA hay cầm. Bài này nói về chỗ bạn ngồi khi cầm những dự án đó: hai môi trường phổ biến nhất khác nhau ở đâu, giống nhau ở đâu, và một người mới thì nên tính thế nào.
Nói trước hai chuyện cho khỏi lẫn. Chữ "môi trường" ở đây là môi trường công ty, không phải Dev/Test/Staging/Production — cái đó là một bài khác trong khoá. Và cho gọn, cả bài gọi người làm BA ở công ty product là BA Product, làm ở công ty outsourcing là BA Outsource.
Bỏ qua mọi thứ khác một lát, chỉ nhìn vào một câu: công ty này thu tiền bằng cách nào?
Công ty product bán chính cái phần mềm họ làm ra. Người dùng trả tiền hàng tháng, hoặc trả tiền theo giao dịch, hoặc không trả gì cả và công ty sống bằng quảng cáo. Sản phẩm ế thì công ty chịu.
Công ty outsourcing bán công sức theo hợp đồng. Khách hàng đưa yêu cầu, công ty gom người vào làm, bàn giao, lấy tiền. Sản phẩm sau đó ế hay chạy tốt thì đó là chuyện của khách.
Gần như mọi khác biệt trong công việc hàng ngày của BA đều mọc ra từ hai câu trên.
Ở môi trường product, câu hỏi đeo bám bạn là "làm cái này để làm gì". Ở môi trường outsourcing, có thêm một câu phải trả lời sớm: "cái này có nằm trong phạm vi đã ký không". Việc làm rõ yêu cầu, hiểu nghiệp vụ, nghĩ ra tình huống hỏng thì bên nào cũng phải làm — chỉ là bên outsourcing có thêm một tầng ràng buộc về hợp đồng ở trên.
Để thấy rõ, lấy đúng một yêu cầu và cho nó chạy qua hai nơi. Yêu cầu: cho khách lưu sản phẩm yêu thích, khi sản phẩm giảm giá thì báo cho họ.
Ở một công ty làm sàn thương mại điện tử của chính họ, yêu cầu này thường không đến từ ai cả. Nó đến từ số liệu: có một lượng khách xem sản phẩm rồi thoát, không mua, không quay lại. Ai đó trong đội nghĩ ra giả thuyết là họ đang chờ giảm giá.
Việc của BA bắt đầu bằng câu hỏi ngược: nếu làm cái này thì chỉ số nào phải tốt lên, và tốt lên bao nhiêu thì đáng công? Có người đi đào dữ liệu, ngồi với đội phân tích, dựng ra một con số ước lượng rồi mang vào buổi họp ưu tiên. Ở năm đầu tiên, phần rơi vào tay bạn thường là đi lấy số và chuẩn bị tài liệu cho buổi họp đó, còn người trình bày và người chịu trách nhiệm cho con số là BA lead hoặc Product Owner.
Trong buổi họp ấy có khả năng cao là tính năng bị đẩy sang quý sau, vì quý này đội đang phải lo chuyện thanh toán. Không ai nợ bạn lời giải thích.
Rồi giả sử nó được duyệt và làm xong. Ba tuần sau bạn mở dữ liệu ra xem có bao nhiêu người thật sự bấm vào trái tim đó. Nếu gần như không ai dùng, việc tiếp theo là bàn xem nên bỏ hay sửa. Bạn sống chung với hậu quả của chính tính năng mình viết ra.
Ở một công ty nhận làm website cho chuỗi cửa hàng đồ gia dụng trong ví dụ của bài trước, cùng yêu cầu đó đi một đường hoàn toàn khác.
Nó đến bằng email từ phía khách, thường là chị phụ trách marketing bên đó. Câu hỏi đầu tiên trong đầu bạn không phải "cái này có đáng làm không" — chuyện đáng hay không là khách tự quyết, họ trả tiền mà. Câu hỏi đầu tiên là: cái này có trong phạm vi đã ký không?
Nếu có, bạn làm rõ yêu cầu rồi viết ra cho đủ chi tiết. Nếu không, nó thành một change request: mô tả thay đổi, ước lượng công, gửi sang cho bên khách duyệt, có khi phải phụ lục hợp đồng. Người mới không tự chạy hết quy trình đó — bạn giúp viết phần mô tả và đi hỏi dev con số ước lượng, còn chuyện đàm phán với khách là của PM.
Và phần bạn phải viết kỹ hơn hẳn đồng nghiệp bên product là điều kiện nghiệm thu. Vì đến ngày bàn giao, "báo cho khách khi giảm giá" mà không ghi rõ báo bằng email hay bằng thông báo đẩy, báo ngay hay gom một lần mỗi ngày, thì đó là một buổi họp căng thẳng chứ không phải một dòng ghi chú.
Làm xong, nghiệm thu, hết. Sáu tháng sau có bao nhiêu người dùng cái nút đó, phần lớn trường hợp bạn sẽ không bao giờ biết.
Đây là quan sát chung, không phải luật. Mỗi công ty một kiểu, và phần dưới bảng sẽ nói rõ chỗ nào bảng này hay sai.
Tiêu chí | BA Product | BA Outsource |
|---|---|---|
Việc chính | Tìm ra nên làm gì tiếp, và làm xong thì đo lại | Làm rõ yêu cầu của khách và giữ cho phạm vi không trôi |
Nói chuyện nhiều nhất với | Product Owner, dev, thiết kế, đội dữ liệu | Đại diện phía khách, PM, dev |
Yêu cầu đến từ đâu | Số liệu, phản hồi người dùng, chiến lược công ty | Khách hàng, qua hợp đồng và các buổi họp |
Tài liệu | Vừa đủ để đội hiểu, sửa liên tục | Chi tiết hơn, vì nó là căn cứ nghiệm thu và tính tiền |
Nhịp dự án | Sản phẩm sống lâu, không có ngày kết thúc | Có ngày bàn giao, xong dự án là chuyển sang dự án khác |
Kiến thức tích được | Sâu về một lĩnh vực, một tệp người dùng | Rộng, chạm nhiều ngành — trừ khi bạn vào đội gắn dài hạn với một khách |
Áp lực đặc trưng | Chứng minh việc mình làm có tác dụng | Deadline, và kỳ vọng của khách |
Ba chỗ bảng này hay bị đọc sai:
"Outsourcing thì yêu cầu cố định." Chỉ đúng với hợp đồng trọn gói, tức là chốt trước một phạm vi và một cái giá. Còn kiểu hợp đồng tính theo thời gian và nhân sự, hoặc mô hình đội chuyên trách dài hạn, thì khách đổi ý hàng sprint không khác gì product. Cái được chốt trước ở những hợp đồng đó là đơn giá và số người trong đội, không phải danh sách tính năng.
"Product thì được quyết định." Không. Người quyết sản phẩm là Product Owner hoặc Product Manager, và một BA mới vào thì càng không. Cái bạn có ở product là được ngồi gần chỗ ra quyết định hơn: lý do đằng sau một lựa chọn thường đến tai bạn, và kết quả sau khi lên chạy thì bạn nhìn thấy. Đừng nhầm chuyện đó với quyền quyết.
"Outsourcing thì bàn giao xong là hết." Nhiều hợp đồng có bảo hành, có bảo trì dài hạn, có giai đoạn hai. Có những BA gắn với một khách hàng bốn năm liền và thuộc hệ thống của khách hơn cả nhân viên bên đó.
Bảng trên là bản tóm tắt để nhìn cho nhanh. Còn khi ngồi vào ghế làm việc thật, ba dòng trong bảng đó chạm vào bạn theo kiểu thế này.
Thứ nhất, bạn dành thời gian cho ai. BA Product ngồi nhiều với người trong công ty — dev, thiết kế, đội dữ liệu, đội chăm sóc khách hàng — và tiếp cận người dùng cuối chủ yếu qua số liệu và phản hồi thu được. BA Outsource dành một phần đáng kể thời gian cho người ngoài công ty, và người đó thường bận, thường ở múi giờ khác, và thường không phải người ra quyết định cuối cùng bên phía họ.
Chuyện "người mình đang họp không có quyền chốt" là cái bẫy lớn nhất của môi trường outsourcing. Bạn làm rõ yêu cầu với một bạn chuyên viên trong ba buổi, đến buổi thứ tư sếp của bạn ấy vào họp và lật lại từ đầu.
Có một biến thể nặng hơn của cái bẫy này: hợp đồng đi qua nhiều tầng. Khách cuối thuê một công ty ở nước ngoài, công ty đó thuê lại một công ty Việt Nam, và đôi khi còn thêm một tầng nữa. Mỗi tầng, yêu cầu lại bị diễn giải lại một chút. BA ngồi ở tầng dưới cùng viết tài liệu dựa trên cách hiểu của tầng trên, không có kênh nào để hỏi lại người dùng thật, và đến lúc nghiệm thu mới biết mình hiểu lệch.
Nếu bạn rơi vào tình huống đó, việc làm được không phải là đòi gặp khách cuối — bạn sẽ không được gặp. Việc làm được là viết ra giả định của mình thành câu rõ ràng rồi nhờ BA lead hoặc PM gửi lên tầng trên xin xác nhận. Nghe thủ tục, nhưng nó làm chỗ hiểu lệch lộ ra sớm hơn hẳn so với việc chờ tới vòng nghiệm thu.
Thứ hai, bạn viết cho ai đọc. Tài liệu ở công ty product chủ yếu để đội mình hiểu và làm; nó được sửa liên tục và không ai đem nó ra cãi nhau về tiền. Tài liệu ở công ty outsourcing còn thêm một vai nữa: nó là căn cứ. Đến lúc tranh luận "cái này có trong yêu cầu không", thứ được mở ra là tài liệu bạn viết.
Nên cùng là một người mới, BA Outsource thường bị bắt viết chặt sớm hơn, đơn giản vì viết lỏng là có người phàn nàn ngay trong tháng đó.
Thứ ba, việc của bạn kết thúc ở đâu. Bên product, giao hàng mới là nửa đầu; nửa sau là đo, là sửa, là quyết định gỡ bỏ. Bên outsourcing, nghiệm thu là vạch đích, và thứ được đo là bàn giao có đúng cam kết không.
Ngoài ba chỗ đó ra, danh sách việc nền của hai bên gần như trùng nhau: hỏi cho ra vấn đề thật, phân tích, viết ra cho người khác hiểu đúng ý mình, hỗ trợ kiểm thử và UAT. Cùng những việc ấy, chỉ khác tỉ lệ thời gian bạn bỏ vào từng cái.
Chia đôi product và outsourcing là cách nói cho dễ hiểu. Đi làm rồi bạn sẽ thấy phần lớn chỗ nằm ở giữa.
IT nội bộ của một doanh nghiệp không phải công ty phần mềm. Ngân hàng, chuỗi bán lẻ, hãng vận tải, bệnh viện — họ có đội IT riêng làm hệ thống cho chính họ dùng. Đây là một nguồn việc BA đáng kể ở Việt Nam mà các bài so sánh hay bỏ quên, và nó không nằm gọn trong ô nào: sản phẩm không đem bán, nhưng bạn vẫn sống với hệ thống đó nhiều năm, vẫn phải đo, vẫn phải sửa. Người dùng của bạn là đồng nghiệp ngồi tầng dưới. Đổi lại, tốc độ thường chậm hơn, quy trình duyệt nhiều tầng hơn, và công nghệ ít khi mới. Vài tập đoàn còn tách hẳn đội IT ra thành một công ty công nghệ riêng — bạn ký hợp đồng với công ty đó nhưng làm cho hệ thống của tập đoàn mẹ.
Đội chuyên trách đặt tại công ty gia công, thường gọi là ODC hoặc dedicated team. Khách thuê hẳn một đội cố định trong hai ba năm thay vì thuê theo từng dự án. Về giấy tờ là outsourcing, về cảm giác đi làm thì giống product: cùng một hệ thống, cùng một tệp người dùng, năm này qua năm khác. Nhớ tên gọi này để lúc đọc tin tuyển dụng bạn nhận ra — nếu bạn thích chiều sâu mà cửa vào product đang hẹp, đây là chỗ đáng nhắm.
Cho thuê người theo đầu, tiếng trong nghề hay gọi là staff augmentation hoặc body shopping. Công ty A ký hợp đồng, nhưng bạn sang ngồi làm việc trong đội của khách hàng, theo quy trình và công cụ của họ. Bảng lương ghi tên công ty A, còn hàng ngày bạn nhận việc từ người bên B. Mô hình này khá phổ biến với vị trí đầu đời, và nó có hai mặt: bạn được nhìn thấy bên trong một tổ chức lớn từ sớm, nhưng hết hợp đồng là phải đi, và bạn thường là người ngoài trong mọi cuộc họp quan trọng. Trước khi ký, hỏi cho rõ mình sẽ ngồi ở đâu và nhận việc từ ai.
Công ty tự nhận là product nhưng thật ra làm theo đơn đặt hàng. Cái này gặp nhiều hơn bạn tưởng. Website ghi "chúng tôi xây dựng sản phẩm của riêng mình", vào rồi mới biết doanh thu đến từ vài khách hàng lớn và mọi tính năng đều do họ đề nghị. Không có gì sai trái ở đây cả, chỉ là bạn nên biết trước khi ký.
Văn phòng Việt Nam của một công ty product nước ngoài. Sản phẩm là thật, người dùng là thật, nhưng chuyện quyết định hướng đi sản phẩm nằm ở trụ sở bên kia. Đội ở Việt Nam có khi làm đúng một mảng nhỏ trong đó. Vẫn là môi trường tốt để học, chỉ là đừng kỳ vọng mình sẽ được bàn chuyện chiến lược sản phẩm trong năm đầu.
Studio nhỏ và làm tự do. Vài người làm mọi thứ, hoặc bạn tự nhận việc bên ngoài. Ở đây bạn học rất nhanh vì phải tự bơi, và cũng vì phải tự bơi nên lúc bí không có ai để hỏi — hiếm khi là chỗ tốt cho năm đầu.
Nhãn trên website công ty không nói lên nhiều. Mấy câu dưới đây hỏi được ngay trong buổi phỏng vấn, và câu trả lời cho bạn biết nhiều hơn cả trang tuyển dụng:
Còn một câu nữa nên hỏi mà chẳng liên quan gì tới product hay outsourcing: ở đây một BA thật ra làm những việc gì? Chữ "BA" trong tin tuyển dụng ở Việt Nam co giãn rất rộng — có chỗ là BA kiêm tester, có chỗ nghiêng hẳn sang phiên dịch cho khách Nhật, có chỗ thực chất là hỗ trợ người dùng hoặc đi bán hàng cùng đội kinh doanh. Không có kiểu nào xấu cả, nhưng bạn nên biết mình sắp bỏ ra một năm để giỏi lên ở việc gì.
Có một chuyện cần nói thẳng trước khi bàn chuyện hợp hay không hợp: cửa vào không rộng như nhau.
Bên outsourcing thường mở cửa cho người mới rộng hơn, vì họ nhận nhiều dự án cùng lúc và cần người vào việc theo dự án; có nơi còn tuyển cả lớp rồi đào tạo. Bên product hay có một đội nhỏ và ổn định, mỗi lần tuyển là tuyển người làm được ngay. Còn vào những đoạn thị trường siết lại thì cả hai đầu cùng ít cửa, và tin tuyển fresher ở đâu cũng thưa đi.
Cho nên với phần lớn các bạn mới, câu hỏi thực tế không phải "chọn cái nào", mà là "chỗ nào gọi mình đi phỏng vấn".
Điều đó không có nghĩa là nhắm mắt gật hết. Trước khi nhận, có mấy thứ tự cân nhắc được.
Kiểu áp lực nào bạn chịu được lâu hơn. Bên product, cái mệt là phải chứng minh việc mình làm có tác dụng, và thỉnh thoảng nhìn tính năng mình tâm huyết bị gỡ đi vì không ai dùng. Bên outsourcing, cái mệt là deadline và một người đang chờ ở đầu bên kia — có khi bằng tiếng Anh, có khi vào mười một giờ đêm vì lệch múi giờ. Chuyện làm thêm giờ vào sát ngày bàn giao là có thật, và nên hỏi thẳng trong buổi phỏng vấn thay vì đoán.
Chiều sâu hay chiều rộng trước. Vài năm ở một sản phẩm cho bạn hiểu một lĩnh vực đến mức nói chuyện được với dân trong ngành. Cũng chừng ấy thời gian ở outsourcing, nếu bạn đi theo các dự án ngắn, sẽ cho bạn đi qua bảo hiểm, bán lẻ, logistics và một bộ phản xạ làm việc với khách mà bên product ít khi rèn tới. Nhưng nếu bạn được xếp vào một đội gắn dài hạn với một khách, chiều sâu bạn tích được cũng không kém gì bên product — nên hỏi rõ mình sẽ vào kiểu đội nào chứ đừng suy từ chữ "outsourcing".
Tiếng Anh của bạn tới đâu rồi. Rất nhiều vị trí BA outsourcing ở Việt Nam làm với khách nước ngoài, và tiếng Anh ở đó là điều kiện lọc chứ không phải điểm cộng. Mà khách mỗi nước một tính: làm với khách Nhật thì tài liệu thường phải dày và chi tiết hơn, đổi yêu cầu giữa chừng khó hơn, và giữa hai bên hay có thêm một người phiên dịch kỹ thuật; khách Âu Mỹ thì trao đổi thẳng hơn nhưng lại đòi bạn tự đề xuất phương án chứ không chỉ ghi lại yêu cầu. Bài về tiếng Anh trong khoá này nói kỹ hơn.
Vài năm nữa bạn muốn đi tiếp về đâu. Hai môi trường dẫn ra hai lối khác nhau: từ outsourcing, đường quen thuộc là đi dần sang quản lý dự án và làm việc với khách hàng; từ product, đường quen thuộc là đi sang Product Owner hoặc Product Manager. Bài về lộ trình nghề ở phần đầu khoá nói rõ hơn chuyện này.
Còn chuyện lương thì có bài riêng trong phần đầu khoá, mình không nhắc lại ở đây — chỉ lưu ý một điều: đừng so lương khởi điểm giữa hai môi trường rồi kết luận, vì thứ tự đó hay đảo chiều sau vài năm.
Và một chuyện ít người nói với các bạn từ đầu, dành cho bạn nào đã đi làm chứ không phải người sắp đi phỏng vấn lần đầu: hồ sơ outsourcing hay bị loại sớm khi nộp sang product. Có bạn trong cộng đồng làm BA outsourcing vài năm, muốn chuyển sang ngân hàng hoặc fintech, nộp hồ sơ rồi bị loại từ vòng đọc CV. Không phải vì họ kém. Là vì hồ sơ toàn dự án ngắn, mỗi dự án một ngành, và người tuyển bên product không đọc ra được bạn hiểu sâu cái gì.
Chiều ngược lại cũng có cái giá của nó, chỉ là ít bị nói tới: đi ra từ product mà vào outsourcing thì cái hay hụt là tốc độ và sức chịu đựng khi khách đổi ý.
Nếu bạn đang ở outsourcing và muốn giữ cửa sang product, mấy việc dưới đây làm được mà không cần ai cho phép:
Không có môi trường nào tốt hơn môi trường nào, và cái hợp với bạn hôm nay có thể đổi sau vài năm.
Nhưng riêng năm đầu tiên thì cái nhãn product hay outsourcing gần như không quyết định bạn tiến nhanh hay chậm. Ba thứ này mới quyết: bạn có được ngồi cạnh một người làm nghề tử tế không, bạn có được vào việc từ lúc yêu cầu còn mơ hồ hay chỉ nhận phần đã nhai sẵn, và có ai đọc lại tài liệu bạn viết rồi chỉ cho bạn chỗ chưa ổn không.
Ba câu đó hỏi được ngay trong buổi phỏng vấn. Cái nhãn thì đọc trên website cũng biết, mà lại nói được ít hơn nhiều.
Bài tiếp theo nói về những người bạn sẽ làm việc cùng hàng ngày ở cả hai nơi đó: các vị trí trong một đội phát triển phần mềm, ai làm gì, và BA đứng ở đâu giữa họ.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận