Con đường trở thành Business Analyst của Tester

Bài viết được sự cho phép của vntesters.com

Chia sẻ của bạn Nguyễn Dương Hải về quá trình trở thành một BA từ QC.

Trong một năm trở lại đây, nó là câu hỏi mà mình luôn tìm kiếm và khám phá. Mình có background 6 năm là QC, và chuyển từ QC sang BA dường như là một thách thức rất lớn, không chỉ đơn giản vì nó khó khăn cho bạn, mà còn là cách đánh giá của người khác về bạn nữa. QC có những lợi điểm khi chuyển thành BA, nhưng cũng có không ít nhược điểm, đặc biệt là về mặt mindset, thậm chí là so với một fresher. Hôm nay, mình viết bài này để chia sẻ về việc mình đã rèn luyện những skill cần thiết cho một BA khi vẫn còn là một QC như thế nào. Khi đã có được skill và mindset, vấn để chỉ còn là bạn có muốn follow theo con đường đó hay không.

Việc làm tester và tìm việc Business Analyst lương cao

1/ Đừng chỉ làm, hãy tìm hiểu lý do và lợi ích

Như là một QC, mình ngày ngày có nhiệm vụ là dựa vào requirement để viết ra test case bao phủ nó, để đảm bảo sản phẩm làm ra đạt ‘chất lượng’. Như là QC, mình từng coi requirement là tuyệt đối, sản phẩm sẽ hoàn hảo nếu làm giống requirement. Nhưng sự thật là, kể cả mình khi dùng product mình làm ra cũng gặp vấn đề, đừng nói gì end user. Hơn nữa, có những feature mình làm mà chẳng User nào dùng, hoặc được một thời gian thì client nói nên đập đi làm lại!! Mình bắt đầu đặt câu hỏi “Tại sao chúng ta lại làm ra flow này?”, “Nó giúp ích gì cho user?”. Ngắn gọn hơn, mình bắt đầu muốn tham gia vào việc làm ra requirement.

Cách đây hơn 6 năm, ở công ty cũ của mình, khi mình nói là muốn join vào meeting của BA và client, đã có người cười vào mặt mình ^^. Sau đó, mình cứ đợi đến khi BA và team meeting với client là mình mở cửa phòng họp đi vô. Mọi người khá ngạc nhiên nhưng không nói gì vì nói thì client sẽ nghe ^^. Sau đó, mình nhận nhiều feedback về việc tự tiện này và khuyên mình nên quay lại với task của mình. Mình vẫn phải đảm bảo task QC được hoàn thành trong khi spend extra time cho việc này. Ngoài ra, bạn cũng phải vô cùng ý tứ. Thời gian đầu, mình chỉ ngồi im và nghe, rồi dùng kiến thức đó để hỏi BA sau này. Sau này, mình mạnh dạn hơn, khi mình chắc chắn cái mình nói sẽ có value thì hãy nói, và đó là tiền đề để team chấp nhận mình hơn trong những buổi nghe và discuss về requirement.

Những meeting này là kinh nghiệm vô giá. Bạn được nghe ý tưởng từ đầu, cũng giống như bạn là Developer và bạn nhìn thấy những dòng code system đầu tiên vậy. Nó sẽ giúp bạn hiểu về requirement rất nhiều. Không! Không phải là requirement, mà là nhu cầu của khác hàng. Bạn cũng sẽ học được cách nói chuyện và giải thích khách hàng của BA. Tuy nhiên, hãy để ý vị trí của bạn. BA sẽ là người mặc định được nói chuyện với client và đề ra giải pháp. Đừng có thái độ lấn quyền khi bạn chưa chắc bạn đang nói gì. Mình từng NHIỀU lần sai phạm và nó sẽ trả giá đắt đó!

Với khả năng gà vịt của bạn lúc đầu, chắc chắn là sẽ không hiểu hết. Hãy đem thắc mắc của mình, suy nghĩ câu chữ và ý tưởng cho thật kỹ, và đem tới hỏi BA. Lúc đầu, sẽ có rất nhiều câu hỏi stupid và những câu không đáng hỏi ( quá chi tiết, đợi document ra sẽ có). Hãy nhận lỗi và improve. Mình cũng phải cám ơn 2 chị BA ở Pyco Group đã rất kiên nhẫn với mình.

Chưa hết, hãy theo dõi calendar và lịch trình trao đổi với client của BA. Một trong những điều quan trọng nhất của BA là phải biết lấy requirement từ đúng người, đúng thời điểm. Bằng việc tìm hiểu BA lấy được requirement, confirmation này từ ai sẽ là một điều quan trọng sau này cho bạn.

Dần dà, bạn sẽ biết cách nghe và hiểu được cái client muốn là gì. Bạn cũng sẽ biết cách và thời điểm để đặt câu hỏi. Đó sẽ là tiền đề cho những phát triển sau này trong BA skill set.

2/ Nói chuyện với End User

Đây là cái mình học được ở Atlassian Viet Nam. NIHITO – Nothing Important Happen Inside The Office. Mặc dù theo mình thì có rất nhiều cái thú vị ở office, nhưng ngoài kia, khi bạn nói chuyện với end user, sẽ là một trải nghiệm hoàn toàn khác. Chỉ khi bạn thật sự ra ngoài và lắng nghe end user kể về pain point của họ, bạn mới hiểu là product của bạn cần làm gì, để giải quyết điều gì. Việc tìm đúng end user, người sẽ là target của bạn cũng sẽ là một challenge thú vị. Nó sẽ giải quyết rất nhiều yếu điểm trong giải pháp của chúng ta. Có bao giờ bạn ngồi trong phòng họp, bạn, BA, PM,… tranh cãi rất nhiều về việc nên làm feature này thế nào cho tốt, nhưng chưa có ai thực sự có evidence nào để back up cho ý kiến của họ. Đã có ai từng tới để hỏi end user về vấn đề này?

Ở một số công ty lớn, việc làm những buổi UX testing hay UX research/ interview sẽ được handled bởi PO, hoặc 1 role riêng là UX researcher. Tuy nhiên, QC sẽ là một assistant tốt. Lý do là vì:

  • Bạn có good knowledge về product. Bạn có thể giúp cho test user nắm được một số điểm chính trong hệ thống nếu họ bị stuck. Một mình PO sẽ không làm xuể chuyện này
  • Như là QC, bạn có con mắt quan sát tốt. Bạn sẽ dễ nhận ra user nào đang cảm thấy thích feature và user nào đang khó chịu với nó. PO thường mang QC vào phòng quan sát để theo dõi và discuss reason với họ về hành vi của end user.
  • Bạn có những góc nhìn rất thú vị về product. Thường thì PO, hay BA sẽ nhìn product dựa trên happy case là chủ yếu. Còn bạn, với thâm niên của QC, bạn sẽ có khuynh hướng focus vào unhappy case hơn. Tuy nhiên, hãy nhớ chỉ raise lên unhappy case khi mà bạn tin rằng use case này sẽ có ảnh hưởng lớn đến user khi gặp lỗi, làm họ muốn leave. Hãy tập control và loại bỏ những case không quá quan trọng đi

Ở công ty nhỏ, làm product nhỏ, bạn có thể chỉ đơn giản là mang product của bạn, khéo léo hỏi 1 vài đồng nghiệp không làm product này xem họ thấy thế nào về product? Mình từng tổ chức rất nhiều session như vậy, chỉ cần mời được khoảng 5 người là bạn đã có những feedback giá trị về feature của bạn rồi.

Hãy tập lắng nghe complain của mọi người nhiều hơn, và try your best để advice họ ^^, kể cả trong văn phòng và ngoài đời. Bạn sẽ dễ dàng nhận ra là sau này, khi bạn nói chuyện, lời nói của bạn sẽ có xu hướng tập trung để giải quyết vấn đề nhiều hơn là than vãn ^^. Những kinh nghiệm ngoài đời sống cũng sẽ giúp ích rất nhiều. Đừng tự thu mình lại chỉ trong văn phòng làm việc, và cũng đừng suy nghĩ theo hướng ‘mọi việc đã vậy rồi, không sửa dược đâu’

Nói tóm lại, gặp mặt và nói chuyện với end user sẽ giúp bạn có những thông tin và kinh nghiệm vô cùng giá trị để tư vấn, làm cho sản phẩm tốt hơn. Nó cũng sẽ giúp bạn rèn luyện thói quen “speak with evidences”, điều rất quan trọng sau này khi bạn muốn thuyết phục client hay team member của bạn về một feature.

3/ Nâng cao việc communicate với member trong team

Đây là cái mà QC chúng ta thường hay làm, và thường hay làm sai. Mình không biết các bạn thế nào, nhưng có một thời gian mình chỉ đem process, requirement, và rule để đi nói chuyện với bộ phận khác, đặc biệt là với developer. “Bug! Nó sai với requirement!”, “Bản build này fail rồi! Nó có 3 lỗi critical nè!”,…. Như là QC, mình sẽ không bàn đúng sai ở đây. Tuy nhiên, cách tiếp cận đó bạn sẽ không còn dùng được nữa khi là BA. Requirement có thể nói là do bạn tạo ra (hoặc bạn và PO), nhiệm vụ của bạn là thuyết phục client và team member tin rằng đó là approach đúng bằng bằng chứng và lý lẽ. Get được user’s feedback sẽ là một backup quan trọng cho bạn. Chuyển tư duy và cách communicate là một việc quan trọng để trở thành BA.

Hơn thế nữa, dù là QC hay BA, bạn cần phải biết về technical. Đặc biệt là BA, vì giải pháp phải khả thi mới là giải pháp tốt. Giải pháp là vô nghĩa nếu team bạn không thể làm ra nó được, hoặc nó không phù hợp với system hiện tại được. Bạn cần làm việc kỹ hơn với Developer để hiểu rõ system và công nghệ của chúng ta có yếu điểm gì, có thể làm được gì. Hơn thế nữa, sẽ luôn luôn có những thắc mắc từ client về cách làm của Developer và ngược lại. Bạn sẽ là người đứng giữa để giải quyết những khúc mắc đó. Hãy join với Developer khi họ nói về building system, database,… để thu thập thêm kiến thức và học cách chuyển tải nó thành ngôn ngữ cho non-tech member

4/ Quality không phải là quan trọng nhất nữa. Hãy làm quen!

Như mình có đề cập một chút ở phần 2/. Khi là QC, bạn chỉ cần quan tâm về quality. Tuy nhiên, nếu muốn trở thành BA, bạn phải hiểu rằng một product tốt là một product balance được về Cost, Scope và Quality. Đôi khi BA sẽ đi đến quyết định release một feature với những flow chính đảm bảo chỉ để bắt kịp với xu thế thị trường, hoặc bạn chưa biết là User phản ứng thế nào nên bạn chỉ release ra với mục đích lấy thêm feedback. Bạn sẽ phải tập làm quen và chấp nhận với những mindset đó.

  Business Analyst (BA) là gì? Học gì để trở thành một BA
  Con đường trở thành Business Analyst của Tester

5/ Hãy tập handle vài task của BA

Sẽ rất fun, mình hứa với bạn đấy ^^! Đây là những công việc hồi đó mình chịu làm extra cho team:

  • Update requirement: Tới hỏi BA “Cái flow này thì sao chị?”, thì BA nói “Uh, em nghĩ đúng rồi đó. Chị bận quá! Em giúp chị update được không?”. Hãy cố gắng nhận những task nhỏ, đã có ví dụ về structure từ trước để add vào requirement. Thường là requirement cho Edge cases. Nó sẽ giúp bạn hiểu hơn về cách làm ra document.
  • Làm culi hỏi việc cho Developer: Developer hay có suy nghĩ là mình làm gì cũng được, miễn sao thằng QC này cho mình pass là được, nên thay vì là làm đúng theo cái BA muốn, thì chuyển nó thành làm đúng theo cái QC muốn. Điều này dẫn đến việc Dev sẽ hỏi bạn về expect của bạn, thay vì là BA. Đương nhiên, như là QC bạn sẽ cần hỏi BA về những quyết định của mình. Dần dà, thậm chí có một số những quyết định nhỏ bạn có thể tự quyết định, và nói lại với BA update document sau
  • Tập vẽ User flow: Theo mình thấy, User flow là thứ ngôn ngữ đơn giản và chung nhất mà tech và non-tech có thể hiểu được. Mình hay dùng cái này để nói chuyện với mấy anh Dev. Rồi về sau nó có thể được add vào text requirement luôn. Đôi khi chỉ đơn giản là người ta chụp cái hình bạn vẽ nguệch ngoạc trên bảng thôi ^^.
  • Handle một số job về database: Database testing sẽ tốt. Ngoài ra, hồi xưa, client của mình thỉnh thoảng còn có nhu cầu kêu team mình export ra data cho người ta theo kiểu “Trong tuần này có bao nhiêu thằng User tăng 10 fan vậy?” Nếu không quá bận, QC có thể làm nó được. Hiểu về database system sẽ là một điều rất tốt cho vị trí BA sau này.

Sau này, bạn sẽ thấy có những công ty yêu cầu bạn biết vẽ rất nhiều loại diagram, và có hiểu biết về cả database structure nữa. Những công việc kia sẽ là hành trang quý báu cho bạn khi bước tiếp như là BA.

Lời kết

Mình hy vọng qua bài viết này các bạn QC nói riêng cũng như các bạn đang muốn chập chững bắt đầu công việc BA nói chung sẽ có những bước đi đầu tiên hiệu quả cho việc trở thành BA của bạn. Đương nhiên, để trở thành một BA thực thụ và chuyên nghiệp sau này sẽ còn nhiều điều bạn phải học, và tất cả những điều mình nói ở trên bạn sẽ phải làm cho thật nhuần nhuyễn. Chúc bạn thành công trên con đường trở thành BA!

Bài viết gốc được đăng tải tại vntesters.com

Có thể bạn quan tâm:

Xem thêm Việc làm IT hấp dẫn trên TopDev