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 🙂
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 ?
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 😎
11/03/2019 at 4:35 chiều
chào anh, em cảm ơn về các bài viết rất ý nghĩa của anh, mong anh lúc nào đó có thể viết về toàn bộ công việc của BA cho một dự án nhỏ nào đó. Để những người chập chững theo nghề BA như em có thêm tài liệu để tham khảo!
em cảm ơn a
11/03/2019 at 10:09 chiều
Cảm ơn em nhé, có thời gian anh sẽ viết 🙂
24/03/2019 at 9:23 chiều
Em chào anh ạ. Năm nay em thi Đh, năm nay cũng là năm đầu tiên Đh Bách khoa HN và Đh Kinh tế quốc dân đều tuyển sinh ngành mới là Phân tích kinh doanh (Business Analytics), em thấy khá hứng thú với ngành này, nhưng em là người hướng nội nên hơi trầm tính và không được năng động, hoạt ngôn cho lắm ạ, không biết điều này có phải là trở ngại khi trở thành 1 BA không ạ? À em giao tiêp cũng kém nữa ạ :((
24/03/2019 at 10:49 chiều
Hi Ngọc, anh nghĩ dù hướng nội hay hướng ngoại thì đều có thể làm BA tốt hết. Vả lại giao tiếp CHƯA tốt cũng không hẳn là 1 điểm trừ quá lớn đâu.
Quan trọng là em có tìm hiểu kỹ về nghề, tự nhìn nhận lại bản thân thấy cái gì phù hợp, và quan trọng nhất là nhìn nhận ra điểm yếu của mình như em chia sẻ, thì em sẽ sớm đạt được cái mình muốn thôi. Chứ đâu phải hễ BA là cứ suốt ngày giao tiếp, chém gió là tốt là hay đâu 😀 Mỗi tính tình làm nên mỗi phong cách làm việc riêng của mỗi người mà.
À mà Business Analytics không phải phân tích kinh doanh em nhé, business ở đây hiểu là nghiệp vụ, chứ ko phải kinh doanh.
29/03/2020 at 9:39 sáng
Cảm ơn bạn rất nhiều. Mình đang chập chững vào nghề, chuyển hướng từ giáo viên tiếng Anh sang BA. Được đọc những chia sẽ này thật giúp mình mở rộng tầm mắt.Great work. I really appreciate that!
04/04/2020 at 10:52 sáng
Cảm ơn bạn nhiều! Có gì không rõ cần trao đổi cứ email mình nhé!
23/10/2020 at 10:11 chiều
Anh ơi, em flow tinh thần của anh 😀 mặc dù anh cũng đã nhắc ở trên nhưng em chưa hiểu lắm về Key-user. Thực chất họ là ai? Đến từ đâu, doanh nghiệp hay khách hàng của doanh nghiệp? Và mình có thể coi họ là 1 trong những back up của Contact Point không? Em cảm ơn anh trước ạ!!
27/10/2020 at 7:31 chiều
Hi Tùng Anh, key-users thường là những người master về quy trình/ nghiệp vụ mà họ đang handle, là người trực tiếp đưa ra các yêu cầu và có thể là end-user sử dụng system sau khi hoàn thành. Trong giai đoạn Transition, họ cũng có thể train cho end-users sử dụng dựa trên kinh nghiệm thực tiễn đối với phân hệ họ đang làm.
Thường role này sẽ rất quan trọng trong 1 số typical project như ERP chẳng hạn. Họ có thể backup cho Contact Point 1 thời gian ngắn, nhưng ko nên thay thế hoàn toàn trong dài hạn vì nó sẽ làm prj. chạy lệch về 1 hướng, thay vì balance được nhiều yếu tố bởi người Contact Point, đóng vai trò đứng giữa centralize lại mọi thứ. Em tham khảo thêm nhé!
03/08/2021 at 7:04 sáng
Bài viết hữu ích quá ạ. Em cảm ơn anh đã chia sẻ :'(
17/08/2021 at 9:58 sáng
Cảm ơn Uyên
26/02/2022 at 4:29 chiều
Em chào anh ạ.
Em đang thử việc Fresher BA được 1 tháng. Đọc đến phần cuối “Ngại hỏi” mà thấy nhột ghê. Em có nhiều câu hỏi, mà mỗi tội cứ lẽo đẽo đi hỏi chị BA trong dự án thì thấy mình cứ phiền phức làm sao ấy. Hiu, em nên làm gì ạ?
Với em đang rơi vào tình trạng không có việc làm do trình chưa tới. Bình thường thì sẽ cần bao lâu để có thể vào guồng và làm công việc có giá trị cho dự án thay vì hoang mang dư này ạ?
Em cảm ơn anh nhiều ạ! Các bài viết chia sẻ của anh thú dị lắm ạ ^^
27/02/2022 at 11:06 sáng
Hi Ngọc, “ngại hỏi” thì chỉ còn cách là “mặt dày” lên mà đi hỏi thôi em. Không có lối tắt đâu 🙂
Mình cứ chia nhỏ vấn đề ra. Ngại hỏi là do em tự nghĩ là mình sẽ làm phiền người khác, hay em ngại hỏi “cái người đó” vì họ rất nóng tính, bận rộn, sợ làm phiền… Em cần trò chuyện vs chính bản thân mình để hiểu sâu hơn: vì sao lại có cảm giác “ngại hỏi” này. Từ đó với mỗi lý do mình lại có cách giải quyết phù hợp.
Ví dụ nếu ngại hỏi 1 người nào đó, thì chia nhỏ vấn đề ra rồi hỏi những ai khác mà họ biết. Hoặc tìm hiểu vấn đề thật kỹ, hoặc chuẩn bị trước câu hỏi để hỏi cho rõ ràng, ngọn ngành…
Nhưng chung quy lại, một khi đã ngại hỏi thì khó làm tốt công việc BA lắm. Nên cố gắng cải thiện dần dần em nhé!
05/03/2022 at 8:57 sáng
Hi, em chào anh,
Lại thêm một tuần nữa trôi qua ^^
Tuần vừa rồi em đã bỏ 1 số cái ngại mà ấn enter hỏi các anh Dev về ticket họ đang phát triển. Cảm thấy ổn hơn ạ.
Nhìn chung tuần vừa qua em thấy hỏi xong thật tốt, và cx bớt ngại đi, cái này em nghĩ là kiểu vượt qua lực ma sát nghỉ ấy 😀
Em cảm ơn lời khuyên của anh nha!
Dù là hôm qua mới suýt bị sếp to tiếng vì vẽ hai cái mockup screen đơn giản mãi ko xong. Em thấy em cx hiểu ý sếp nma khi em diễn đạt để xác nhận lại thì sếp hiểu em đã hiểu sai. Mà sau 1 hồi diễn giải thì em thấy cái đầu em hiểu đúng á. Chiện này có cách nào để cải thiện anh chỉ em với nha.
Em cảm ơn anh Thịnh nhìu ạ ^^
19/03/2022 at 11:46 sáng
Từng chút từng chút một sẽ ổn hơn thôi, cứ giữ tinh thần đó mà phát triển nhé em 🙂
26/03/2022 at 10:43 sáng
Vâng, em cảm ơn anh!
23/03/2022 at 11:59 chiều
Hi anh,
Em lại nhảy vào comment ạ ^^
Mặc dù hiện tại chưa chuyển sang làm BA nhưng mẫu người anh đề cập em gặp phải khá nhiều, và em cũng dính kha khá nhưng nay có người hệ thống lại mới thấy, đỡ cái là ăn vả nhiều quá nên đã khắc phục nhiều rồi.
Riêng với bản thân em, cái số 3 và cái số 5 là cái nguy hiểm nhất, thấm sâu nhất và cần thời gian để quay đầu nhất. Không chỉ riêng với nghề BA mà với mọi nghề. Em cũng từ những lần tự giả định, ngại hỏi vì sợ bị nói ngu, mà cuối cùng làm ra một cái dự án nó bị lệch một số tính năng quan trọng, cũng may phát hiện sớm và có chút kỹ năng mè nheo mà được nhà cung cấp châm chước không charge phí.
Nhưng em biết không phải lúc nào cũng may mắn như vậy, và từ khi quan tâm muốn hướng sang BA, em càng biết mình phải lì hơn để hỏi (nhưng mỗi lần hỏi là học – và note lại, đừng hỏi cùng 1 vấn đề nhiều lần), thậm chí khi sếp nhìn bằng ánh mắt kì thị thì vẫn chai mặt hỏi, chứ sợ hỏi r assume xong làm te tua thì lúc đó muốn hỏi cũng k được nữa : )) Thà quê 1 chút còn hơn nát lâu dài ạ ^^
Em vừa viết ra 5 nguyên tắc vàng từ bài của anh trước khi đặt chân sang miền đất BA ^^ Hy vọng trong tương lai sẽ không rớt vào danh sách đen kia : )) Đa tạ anh nhiều nhiều ^^ Dự là em sẽ còn ngâm nhiều cái blog của anh và bình luận nhiều ạ ^^
26/03/2022 at 10:38 sáng
Cứ thế mà phát huy nhé 🙂