5 cách nhanh nhất để trở thành một BA tồi
5 cách nhanh nhất để trở thành một BA tồi
Hế lô anh em, câu hỏi ở bài viết lần này: như thế nào là một BA tồi? 
Follow theo 5 cách dưới đây, anh em sẽ nhanh chóng được đồng bọn công nhận là một BA… “tồi có số má”.
Đây cũng là 5 điều mình rút ra từ chính bản thân, và từ những đồng bọn BA xung quanh mình. Cùng đọc tham khảo nhé anh em 
Nội dung [Hide]
- 1. Ẩu, cẩu thả
- 2. Thần thánh hóa document
- 2.1. Document chưa bao giờ là mục đích sau cùng
- 2.2. Document said: “Buông tao ra!”
- 3. Bệnh giả sử
- 4. Bỏ rơi Stakeholders
- 4.1. Mục đích bồ tèo đến trái đất là gì?
- 4.2. Một số đồng chí rất khó tiếp cận
- 5. Ngại hỏi
- 6. Tạm kết
1. Ẩu, cẩu thả
Đây là thứ dễ bắt gặp nhất ở một anh BA tồi.
Điều này thường đến từ những anh em có 4-5 năm kinh nghiệm, khi tâm lý mình đã quen với nghề, và có vẻ… chủ quan ở mọi thứ mình làm, không còn cẩn thận từng li từng tí như khi mới vào nghề nữa.
- Làm tài liệu thì không chịu canh trang, paragraph cũng không chỉnh, header, footer cũng không thèm tạo template.
- Làm wireframe thì toàn đi copy trên mạng, hoặc cop của người khác về, chả buồn sửa lại data để hiển thị cho đúng.
- Vô meeting thì hời hợt, không thèm chuẩn bị trước, hoặc lúc nào cũng ngơ ngơ, chả biết mình vô meeting mục đích để làm gì.
Tất cả hành vi này chỉ đơn giản xuất phát từ việc thiếu TRÁCH NHIỆM.
Người thiếu trách nhiệm nhẹ thì để lại hậu quả vừa phải. Người thiếu trách nhiệm nặng thì để lại hậu quả phải nói là vô phương cứu chữa.
Và như anh em cũng biết, luật nhân quả thần thánh sẽ vô cùng hiệu nghiệm trong những trường hợp như thế này.
169% những anh em làm ăn ẩu, cẩu thả, thiếu trách nhiệm, thì sau này đều sẽ phải lãnh đủ nồi lẩu cẩu thả do mình gây ra.
Còn ở một kịch bản khác: nếu những người đó nghỉ việc, thì mớ cẩu thả của họ sẽ được chuyển hóa thành… VỎ để các anh em còn lại còng lưng đi ĐỔ 
Nhưng với cách làm việc ẩu và cẩu thả như vậy, thì dù có nghỉ việc, qua công ty mới, thì chính người đó cũng sẽ lãnh đủ nếu họ cứ tiếp tục làm việc thiếu trách nhiệm như vậy.
Do it one time, do it right
Nên làm gì, nghề gì đi chăng nữa, thì hãy cố gắng đặt chữ trách nhiệm lên đầu. Mà ranh giới giữa lười với thiếu trách nhiệm nó mong manh lắm 
Nói thì phải nhớ đi đôi với làm nhé anh em (nguồn ảnh: CanStockPhoto.com)
2. Thần thánh hóa document
2.1. Document chưa bao giờ là mục đích sau cùng
Dù thế nào đi nữa thì document chỉ là công cụ để mình lái dự án đến vạch đích thôi.
Nó giúp mình hệ thống hóa lại mọi thứ, giữ cho dự án đi đúng lộ trình, không bị lệch hay đi lạc đường.
Không phải cái gì cũng nhất thiết, cũng phải khư khư document lại. Công việc của mình là tập trung vào con người, không phải tập trung vào document.
Làm ABC, XYZ gì đó không cần biết, nhưng sản phẩm cuối cùng của anh em BA mình là phục vụ con người, phụ vụ khách hàng. Chứ không phải mục đích sau cùng là deliver được một đống tài liệu chả ai thèm đọc.
Thực tế là nhiều lúc viết xong mà chính mình còn chả thèm muốn đọc lại, huống chi người khác :3
2.2. Document said: “Buông tao ra!”
Document sẽ giúp anh em giữ chặt Scope, không bị lan man. Do đó nhiều người hay lợi dụng document để làm việc với khách hàng theo kiểu “không có trong tài liệu, em không làm, lêu lêu”.
Đôi lúc nó sẽ phát huy tác dụng.
Nhưng đôi lúc nó cũng sẽ gây phản cảm, làm cho khách hàng có cảm giác không tốt với mình, dẫn đến khó khăn trong trao đổi công việc.
Giả sử có một change request (CR) nho nhỏ. Khách hàng mới khẽ nói: “Em ơi, giờ nó như thế này, bên chị cần abc, mà hiện tại xyz nó không làm được…”
Mới nghe xong là lập tức bắn liên phanh: “Dạ còn lâu chị eiiii, cái này không có trong tài liệu yêu cầu, nên em không làm nhá, lêu lêuuu”.
Ở trường hợp này, anh em đã thật sự hiểu rõ thay đổi của khách hàng là gì chưa?
- Có biết được là CR đó hợp lý hay không?
- Mong muốn của họ ra sao?
- Nó phát sinh một cách khách quan, hay chủ quan?
- Tác động đến khách hàng ra sao nếu không làm?
- Và một vài thứ nữa cần phân tích.
(Mà có thể xong ngay chỉ trong vòng 5 đến 10 phút).
Mình tin rằng, với cách xử lý như này, khách hàng còn lâu mới support để mọi thứ trong tương lai được trôi chảy. Thành thử ra, mình lại tự làm khó mình.
Mình đã từng gặp trường hợp tương tự rất nhiều lần. Khách hàng cũng giống như baby thôi. Cho họ ăn kẹo lần 1, lần 2, đến lần thứ 3 mà không cho ăn thì sẽ làm mình làm mẩy, khóc lóc um sùm.
Trong trường hợp như vậy, anh em cứ dùng tip say NO by YES huyền thoại. Thay vì cứ cậy vào document và trả lời sỗ sàng như trên, anh em có thể khôn khéo xử lý như:
“Dạ chị ơi, em hiểu bên chị cần cái này cũng đúng thôi.
Mấy anh dev bên em mới vừa họp để estimate thử, thì thấy mất khoảng 3 main days để làm xong abc, xong thì làm tiếp xyz khoảng gần 1 tuần, gắn vô rồi test các kiểu cũng tầm 2-3 tuần nữa….
Nói chung tốn khá nhiều effort chị ạ. Để có gì bên em gửi báo giá change request qua email cho chị nhé chị”.
Đúng như thỏa thuận, anh em cứ đưa vào CR và cố gắng khéo léo từ chối những yêu cầu khó từ khách hàng, nhưng nhớ là không phải lúc nào cũng vịn vào tài liệu yêu cầu để nói chuyện.
Hoặc không hẳn là từ chối hết 100%, mà là từ chối 90%, làm 10%. Và 10% ở đây là cái dễ nhất, ít tốn effort nhất.
“Dạ chị ơi em nhận được mail chị rồi ạ.
Yêu cầu này bên em mới xem xét, thấy nó là yêu cầu mới.
Đúng ra là tụi em không làm, nhưng cũng sắp Go-live rồi, nên tụi em ráng support chị lần này nữa chị nhé.
Mà tụi em không làm hết được, để đảm bảo không ảnh hưởng tiến độ dự án, cũng như không charge thêm phí bên chị, thì tụi em chỉ làm abc thôi.
Phần xyz còn lại tụi em sẽ đưa vô backlog, mình trao đổi sau chị nhé”.
…và sẽ có nhiều lần sau khách hàng cũng vòi như thế nữa.
Nếu khách hàng vòi tiếp, anh em cứ vịn vào lần support này, mà nói rằng mình đã hỗ trợ hết mình. Và cố gắng từ chối khéo: nói sẽ làm, nhưng không phải ở giai đoạn này, mà hãy cố gắng đẩy sang giai đoạn sau của dự án.
Túm cái váy lại, không phải cứ cực đoan dựa vào document là tốt!
Anh em phải lấy khách hàng làm trọng tâm, hiểu họ trước.
Rồi khi xử lý tình huống, hẳn lấy document ra mà dùng, và xem nó như một phương tiện, sau khi đã thật sự phân tích kỹ lưỡng yêu cầu của khách hàng
“Your job is more than just documentation.
It’s designing and facilitating interactions between people in order to reach the goals of the project”.
@spydergrrl/ medium
3. Bệnh giả sử
Make assumption là một thứ vô cùng nguy hiểm với BA. Nó như con dao 2 lưỡi với anh em BA mình.
Rõ ràng khi mới vào dự án, anh em như đang… mò mẫm trên núi zậy đó. Sương mù dày đặc, chả hình dung cái gì ra cái gì. Thì khi đó, “giả sử” có vẻ là một phương án khả dĩ.
Tuy nhiên, nếu anh em làm dụng giả sử từ đầu đến cuối dự án, thì dự án banh là cái chắc.
Vì khi đó anh em đang giả sử, tức là đang nhìn vấn đề theo góc nhìn giả định của mình. Còn các stakeholders khác, mỗi người nhìn mỗi kiểu. Đó là thứ nguy hiểm nhất, và khi đó, hầu như BA chả có tí giá trị gì trong dự án cả.
Vì rõ ràng nhiệm vụ chính của BA là phải làm cho mọi thứ rõ ràng, trong suốt: con mèo thì là màu đen, còn con chó thì là chó đốm.
Chứ không phải con mèo muốn ăn thịt chuột, mà ông A lại nhìn ra con mèo muốn ăn thịt gà, mà ông B nhìn ra con mèo muốn ăn thịt heo là coi như xong.
Bệnh giả sử này còn nguy hiểm hơn ở chỗ: hậu quả của việc lậm giả sử chưa phát sinh ra ngay. Mà nó đang lửng lơ tồn tại ở dạng RISK. Tức là rủi ro tiềm tàng thôi, chứ chưa phát sinh thực tế.
Ví dụ trong master data khách hàng gửi, kênh bán hàng có 4 kênh, trong đó vừa có Horeca, vừa có SỈ, vừa có ĐẠI LÝ, và vừa có LẺ. Lúc lọc dữ liệu thực tế thì không thấy bất kỳ record nào có kênh LẺ hay SỈ hết.
Thế là mới đâm ra nghĩ thầm trong bụng: “Hay là kênh LẺ với SỈ nằm trong kênh ĐẠI LÝ luôn ta???”. Mà mỗi kênh bán hàng đi kèm với một bảng giá. Thế là mới hấp tấp gom chung bảng giá của LẺ với SỈ áp dụng cho kênh ĐẠI LÝ luôn.
3 tuần sau hệ thống đưa vào chạy Pilot, giá cả lỗi chành bành. Nhục một cục với team, với khách hàng, cũng chỉ vì “bản tính Sơ-lốc-hôm” phát huy không đúng chỗ 
GIẢ SỬ là một thứ được khuyến khích để kích thích tự suy luận, và tìm ra giải pháp. Tuy nhiên giải pháp chỉ thật sự đúng đắn, khi những giả sử của mình được XÁC NHẬN bởi đúng người, đúng thời điểm.
Do đó, anh em phải biết control được những giả sử của mình. Cái gì mình nghĩ trong đầu, nhưng chưa chắc. Hãy hỏi khách hàng ngay, không nói nhiều! Không đoán già, đoán non gì ở đây hết.
Làm BA mà vô họp cứ phát biểu:
- “Em nghĩ là…”
- “Em đoán thế…”
- “Em tin rằng…”
Là cuối cùng là em tèo ngay.
Đừng áp suy nghĩ của mình cho người khác. BA làm việc dựa trên thông tin, thông tin sai là ăn cám hết cả máng liền..
Exception:
Riêng khi lấy requirement, anh em hãy cứ thoải mái dùng GIẢ SỬ triệt để để lấy thông tin từ khách hàng. Mục đích là để lấy được các trường hợp có thể xảy ra (business cases).
Khách hàng sẽ luôn trình bày tình huống chung nhất công việc của họ. Ở mỗi nút thắt, anh em hãy giả sử một phát, xem họ sẽ xử lý như thế nào.
Ví dụ sau khi chốt đơn hàng với khách hàng, anh Sales Manager sẽ duyệt đơn hàng trên hệ thống. Ảnh duyệt xong, là bên kho sẽ sắp xếp hàng liền, để kịp tiến độ giao cho khách hàng. Đó là happy case.
Nhưng GIẢ SỬ anh Manager này ảnh bị tiêu chảy nguyên ngày, không duyệt được đơn hàng, quy trình bị khựng lại, nghẽn cổ chai ngay đó thì saoooo? Ai sẽ là người được duyệt dùm, có cho duyệt sau hay không, hay bắt buộc phải ảnh duyệt mới được.
Khi đó anh em sẽ cover được hầu hết các business cases có thể xảy ra. Thông tin này là cực kỳ, cực kỳ, cực kỳ, cực kỳ, cực kỳ quan trọng.
Có thể nó sẽ giúp anh em sáng tỏ ở một số mảng khác trong bức tranh tổng quan, vì các modules đều được gắn chặt với nhau. Và nó sẽ giúp mình thiết kế hệ thống thêm chặt chẽ và logic.
4. Bỏ rơi Stakeholders
4.1. Mục đích bồ tèo đến trái đất là gì?
Có những thanh niên khi làm việc với khách hàng, lúc nào cũng oang oang phương pháp triển khai này, phương pháp triển khai kia, khái niệm này, khái niệm kia.
Đối với khách hàng, ba cái đó chỉ là những thứ nhảm ruồi mà thôi. Cái họ quan tâm là những thứ liên quan trực tiếp tới họ.
Họ có thể cải thiện quy trình ở chỗ nào? Lúc trước cần 2 phút để ra một đơn hàng chỉ với một vài thông tin sơ khởi, thì giờ một đơn hàng đầy đủ thông tin chi tiết thì cần bao lâu để hoàn thành…?
Hãy làm quen các khái niệm của khách hàng, đừng bao giờ bắt khách hàng làm quen với các “khái niệm dễ ẹc” của mình (trừ khi nó thật sự cần cho họ).
Đĩa bay đưa mình đến trái đất là để mình giải quyết vấn đề của họ, business của họ, các khái niệm của họ, cách họ làm việc và mong muốn sau cùng của họ.
Đó mới là nghề của mình.
Chứ hổng phải bắt họ phải hiểu công việc của tui là zầy nè, là phức tạp thế này, thế kia.
Stoppp! They don’t care!
VÀ,
Ngay từ đầu dự án, anh em hãy tạo mối quan hệ thật tốt với key-users, tức là những người-dùng-cuối-quan-trọng. Vì họ sẽ là người trực tiếp sử dụng sản phẩm của mình, kiểm nghiệm và đánh giá sản phẩm có đúng với yêu cầu đề ra hay không.
Do đó, quan tâm sâu sắc và hiểu được mong muốn thật sự của họ là cách nhanh nhất để hoàn thành dự án TỐT ĐẸP
Chứ đừng như mình lúc trước, chỉ chăm chăm lo đóng dự án cho xong, mà đếch cần care tới user nào hết Mỗi lần nhận feedback từ user, từ khách hàng cứ như rằng bị đòi nợ.
Lúc nào cũng khó khăn, cứ nghĩ họ đang khó dễ mình này nọ. Nhưng thực ra cái anh em nên làm là: quan tâm họ thực sự đang gặp problem gì.
Problem đó bị 1 lần, 2 lần, 3 lần thì có nghĩa là anh em chưa giải quyết được triệt để chỗ ngứa của họ. Mà như vậy thì sẽ rất khó để khách hàng chịu sign-off đóng dự án cho mình.
4.2. Một số đồng chí rất khó tiếp cận
Đúng vậy, họ thường là các Manager – Decision Maker, hoặc các nhân viên lâu năm, nhưng có tiếng nói trong dự án.
“Khó tiếp cận” ở đây có thể là họ bận quá, khó mà nói chuyện hay meeting được với họ.
Hoặc cũng có thể họ khó lại gần, không có thiện cảm với mình, hoặc trông họ “dữ dằn” quá, nhìn hơi khớp chẳng hạn…
Có 2 tin: MỘT VUI, MỘT BUỒN cho anh em.
TIN BUỒN là anh em phải chấp nhận sự thật rằng: Dù người ta có khó cỡ nào, mà đã là Decision Maker thì anh em phải tiếp cận cho bằng được.
Thường trong dự án mình sẽ trao đổi theo cấp bậc. PM bên này sẽ trao đổi với PM bên kia, BA bên này trao đổi với contact point bên kia, abc, xyz…
Nhưng đó chỉ là lý thuyết…
Trong dự án, hễ ai mà ít nhiều có quyền quyết định, thì anh em BA mình đều nên tiếp cận hết. Để một lần nữa, thật sự hiểu họ cần gì ở dự án, họ đang gặp vấn đề chỗ nào, hay dự án có đang vướng gì ở họ hay không.
Ngược lại, TIN VUI là: Hầu hết 96,69% những người khó tiếp cận này là do mình-tự-nghĩ họ khó tiếp cận, chứ thật ra họ đều rất cute hột me, chỉ cần biết họ cần gì, gãi đúng chỗ ngứa, thì mọi chuyện sẽ đâu ra đấy.
5. Ngại hỏi
Đây là con đường nhanh và ngắn nhất dẫn anh em tới… ngõ cụt của nghề BA.
Đối với một nghề mà đôi khi phải mò mẫm khá nhiều trong đêm tối, làm sao anh em có thể tự tin hiểu khách hàng nếu không chịu… hỏi họ. Sẽ có rất nhiều thứ lạ lùng trên trời dưới đất mà anh em có google 100 năm cũng không thể nào ra được.
Sẽ có rất nhiều lý do dẫn đến bệnh ngại hỏi, nhưng mình nghĩ đa phần bệnh này đến từ 4 chữ:
HỎI NGU VỜ LỜ!!!
Rõ ràng, có rất nhiều anh em ngại hỏi vì sợ bị nói là hỏi ngu, rồi bị trách là “đã nói rõ ràng ra vậy rồi mà còn không hiểu”…, các kiểu đại loại vậy.
Như mình nói ở trên, BA làm việc dựa trên một thứ nguyên liệu rất quan trọng là thông tin.
Nguyên liệu có ngon, cá có tươi, thịt có săn, bột có đều thì đầu bếp mới có thể chế biến ra món ăn ngon được. BA cũng zậy.
Để dự án được suôn sẻ, công việc được thuận lợi, thông tin mà BA làm cần phải chính xác và có giá trị.
- Chính xác là sao? Là 1 là 1, 2 là 2, không thể nào anh Sales Manager này nói 1, mà chị CSR Manager kia nói 2.
- Giá trị là độ hữu dụng của thông tin cao, cần thiết để trả lời cho nhiều câu hỏi quan trọng.
Và trong một rừng thông tin như thế, sẽ có thông tin người này biết, người kia không. Và ngược lại, thông tin người kia biết, người này không.
Vậy chẳng có gì là HỎI NGU ở đây cả. Anh biết thông tin đó, đơn giản bởi vì anh biết nó, vì anh làm công việc đó, vì anh đã hỏi nó, vì anh nhớ lâu hơn tui, document kỹ hơn tui, zậy thôi. Hãy thẳng thắn nhìn nhận vấn đề.
Công việc của mình thì mình lo mà focus vào làm, ai nói gì thì kệ người ta.
Tao á, còn lâu mới ngại hỏi!!!
Thường thì người mắc bệnh ngại hỏi hiếm khi tự nhận mình mắc bệnh. Vì bản thân họ lúc nào cũng có thể nghĩ ra hàng nghìn lý do bao biện cho việc ngại hỏi này.
Từ lười, cho đến Contact Point không available, cho đến thời gian hỏi chưa hợp lý, hay tệ hơn là không biết hỏi ai cho phù hợp.
Một trong những nguyên nhân phổ biến, khiến cho anh em quen với việc lười hỏi, lâu dần thành ngại hỏi, đó là: Contact Point đang không available để hỏi.
Để giải quyết triệt để vấn đề này, anh em cần phải back up thêm 1 người na ná cái anh Contact Point nữa.
“Na ná” ở đây có nghĩa là họ cũng có thể trả lời các thắc mắc của mình, không ít thì nhiều, hoặc họ có thể connect mình tới đúng người có câu trả lời.
Zậy thôi, backup trước, thì dù Mr. Right của mình có đi Mỹ thì cũng không si nhê.
6. Tạm kết
Ô kê xam bu chê anh emmmm.
Trên là 5 bệnh mà mình vướng phải khá nhiều trong công việc. Ngoài mình ra, thì đây cũng là những vấn đề phổ biến mà mình thấy ở những anh em khác.
Như anh em thấy đó, các con đường để trở thành một BA tồi đa phần đến từ thái độ làm việc. Chung quy lại có thể gói gọn ở những chữ như: lười hỏi, lười suy nghĩ, thiếu trách nhiệm, ngại khó, không cố gắng…
Còn năng lực hay kinh nghiệm có hay không, nhiều hay ít thì anh em cũng đừng quá lo lắng.
Những cái đó sẽ dần được tích lũy theo thời gian nếu anh em cố gắng đừng phạm những sai lầm trên. Thâm niên và kinh nghiệm khác nhau là ở chỗ này.
Nếu có gì cần trao đổi anh em cứ còm men phía dưới cho mình nhé. Bái bai và hẹn gặp anh em ở những bài sau
Nguồn: thinhnotes.com
