Một số các bạn BA thường có thói quen đưa ra ngay giải pháp sau khi vừa nghe các business problem. Việc đưa ra giải pháp nhanh có thể đáp ứng và nắm bắt được cơ hội ngay thời điểm đó tuy nhiên đôi khi lại gây ra các sai lầm vì để có được giải pháp thì phải thông qua các hoạt động elicit, analysis sau đó mới proposal giải pháp. Vì như vậy, giải pháp mới thật sự giải quyết được Root cause của business problem. Vậy nên, lời khuyên cho các bạn là trừ khi là những vấn đề quen thuộc và bản thân đã kinh qua nhiều lần trong đời, còn không IT BA không nên đưa ra ngay giải pháp mà tìm cách thu thập thông tin để có thêm cơ sở cho hoạt động phân tích đánh giá.

 

 

Trong quá trình làm việc với stakeholder, sau khi đã thảo luận về requirement. Các bạn IT BA thường quên mất một bước là xác nhận lại. Việc xác nhận này giúp cho cả stakeholder và IT BA một lần nữa nghe lại requirement để khi có vấn đề như cả 2 bên đang không cùng hiểu chung một vấn đề 1 lần nữa sẽ có cơ hội được review và chỉnh sửa. Ngoài ra, việc xác nhận lại requirement sẽ giúp cho requirement được lưu trữ, tracking cho các trường hợp sau này cần tra cứu. Hoặc 1 trong 2 bên quên requirement thì có thể dùng để gợi nhớ. Cuối cùng, Xác nhận requirement còn giúp cho các stakeholder khác liên quan đến dự án có cơ hội được cùng review. Vì không phải lúc nào requirement từ một stakeholder nói ra cũng đúng mà đó là sự hiểu biết, kinh nghiệm và đồng thuận của nhiều stakeholder.

 

 

Các IT BA thường trao hết việc quản lý chất lượng sản phẩm cho đội ngũ QC trong dự án mà quên mất một điều rằng bản thân mình phải là chốt chặn cuối cùng trước khi sản phẩm được “Delivery” đến tay stakeholder. Ngoài ra, việc tự tay trải nghiệm sản phẩm giúp cho IT BA “hiểu và cảm” được UI/UX, qua đó hiểu được sản phẩm do đội ngũ mình là ra và hiểu được trải nghiệm của End User mà mình đang đại diện. Lúc đó, các ý tưởng và giải pháp sẽ được đưa ra để thay đổi và nâng cấp mang đến trải nghiệm UI/UX tốt nhất đến End User.

 

 

Các IT BA thường được dạy một cách máy móc về vùng an toàn của mình là requirement và chỉ tập trung nguồn lực của bản thân để phát triển và quản lý requirement mà không quan tâm đến các actor khác cũng “vận hành” cỗ máy chung với mình. Bản chất của dự án giống như chiếc đồng hồ cơ. Để chiếc đồng hồ này hoạt động cần rất nhiều bộ phận và bánh răng vận hành đồng bộ và phối hợp chặt chẽ với nhau. Và IT BA cũng là một chiếc bánh răng trong guồng máy đó. Để có thể phối hợp được với các bộ phận khác, IT BA cũng cần hiểu được các actor khác trong guồng máy đang làm gì, output của họ là gì và họ cần input gì ở mình để họ “play” được đúng vai trò của họ tốt nhất có thể. Nếu không hiểu về các Actor khác thì IT BA không thể delivery tốt nhất dịch vụ của mình đến các stakeholder khác như khách hàng, Developer, Tester.

 

 

Nghe có vẻ nghịch lý nhưng chuyện này vẫn đang diễn ra ngoài kia. Nơi mà các IT BA dán cuộc đời mình vào chiếc ghế, màn hình và document. Các bạn ấy cho rằng chỉ cần viết đúng requirement là được, lấy được requirement từ stakeholder về viết thành document là được. Các bạn quên mất một điều rằng các bạn không chỉ là “cấu nối” của stakeholder mà còn của Developer, Tester.. Mà đã là cầu nối thì phải thông qua giao tiếp thường xuyên thì tương tác và tính kết nối mới hình thành và duy trì. Hãy trở thành người mà bất kì ai khi có ý tưởng, họ sẽ contact bạn ngay lập tức mà không ngại hay sợ bạn không trả lời. Chỉ khi đó, bạn mới trở thành “Cầu nối” thật sự. Nếu không làm được, bạn chỉ là người thợ viết không hơn không kém. Lúc đó level của bạn ở tầm Fresher, Junior mà bạn không biết. Đừng nghĩ mình là senior vì số năm làm việc. Mindset và skillset sẽ quyết định bạn là ai, bạn ở đâu trong sự nghiệp của bạn. Kinh nghiệm không phải là số năm làm việc.

 

 

Các IT luôn là 1 Key Person trong team. Tuy nhiên, nếu một Key Person mà không có sự chuẩn bị tốt trước các Event như requirement, Sprint Planning, Demo thì dù bạn giỏi cỡ nào mà không chuẩn bị chu đáo thì vở diễn của bạn cũng trở nên tệ hại. Nên nhớ, Nếu bạn không chuẩn bị tức là bạn đang chuẩn bị cho thất bại.

 

 

Một vấn đề phổ biến ở Việt Nam là BA thường được cho là dưới quyền PM. Vì chính tâm lý này khiến các bạn sợ hãi, thiếu chính kiến và luôn luôn “Ngoan” trong mắt các PM. Các bạn sai từ lúc còn tư duy trứng nước. Và nếu còn mang tư duy này thì sẽ rất lâu các bạn mới lên được level cao. Bạn cần nhìn nhận lại vấn đề, PM là một stakeholder cùng tham gia vào dự án chung với bạn. PM không có quyền sai khiến hay ra lệnh BA phải làm việc gì. BA cần có khả năng làm việc độc lập, tư duy độc lập, là dịch vụ của các stakeholder cùng tham gia vào dự án như các actor khác. Tất cả đều là ngang hàng với nhau. Chẳng ai hơn ai. Khi ai đó sai, kể cả PM hãy thẳng thắn raise vấn đề để mn có cơ hội improve. BA phục vụ tổ chức, không phải phục vụ cá nhân.

 

 

Sai lầm cực phổ biến của BA dù nhiều bạn được cho level Senior vẫn mắc phải. Thay vì trở thành cầu nối giữa 2 bên. IT BA lại chỉ “dạ dạ vâng vâng” của stakeholder cụ thể là khách hàng sau đó về tìm cách ép ngược lại team dev nhà mình dù cho đó là đòi hỏi vô lý của khách hàng. Đây có thể gọi là “Gia môn bất hạnh” khi team đang sở hữu thể loại nịnh thần đó. Loại này sẽ gây an nguy cho dự án, dễ gây mất đoàn kết và cũng như sự tin tưởng từ các teammate Developer.

 

Đừng trở nên như vậy. Hãy có lòng tự trọng, chính kiến và đạo đức nghề nghiệp. Trở thành 1 Cầu Nối đúng nghĩa và thuần khiết. Một người bạn của tất cả các bên liên quan.

 

 

Nếu bạn đang có tư duy này, việc các bạn đang làm sẽ rất khó khăn. Có câu thế này:”Không có nghề nào khó, chỉ là bạn chưa biết cách làm cho nó đơn giản”. Riêng nghề IT BA, kỹ năng mềm và tương tác với con người là Key Point cực kì quan trọng quyết định thành công. Vậy nên, thay vì coi khách hàng là khách hàng, đồng nghiệp là đồng nghiệp. Giờ hãy thay đổi tư duy, coi họ là bạn. Vấn đề của họ chính là vấn đề của bạn. Tìm cách giải quyết để họ đạt được thuận lợi và mong muốn của mình. Trao đổi tương tác với họ không chỉ trong mà ngoài công việc. Khi đó, công việc của bạn sẽ trở nên dễ dàng. Khách hàng coi BA là bạn, họ sẽ dễ dàng chia sẻ thông tin, hỗ trợ bạn hết lòng dù công việc bận, việc booking để trao đổi thông tin trở nên dễ dàng hơn bao giờ hết. Developer coi BA là bạn, họ dễ dàng đặt câu hỏi mà không lăn tăn gì. Họ thẳng thắn chia sẻ vấn đề của họ để được hỗ trợ.

Tất nhiên để đạt được điều này là một thời gian dài và cả 2 bên cùng bật đèn xanh để có một mối quan hệ trên mức bình thường :)) Và tất nhiên, IT BA là sứ giả của sự tương tác sẽ là người bật trước để gây thiện cảm từ đối phương.

 

 

Nhiều bạn IT BA cho rằng nếu mình có chứng chỉ nào đó của một tổ chức bên nước ngoài chứng tỏ mình giỏi hơn người khác và mặc nhiên sẽ up level, lương sẽ tăng. Có bạn còn quyết định đi học Master để đạt được mục đích trên. Đây có thể xem là sai lầm trong những sai lầm. Xin nhấn mạnh 1 lần nữa, nghề IT BA là Mindset và Skillset. Không có yếu tố bằng cấp chứng chỉ nào ở đây cả. Bạn muốn up level, hãy đảm bảo bạn có và đang phấn đấu để có được 2 thứ trên chứ không phải tìm cách để có 1 tờ giấy từ một tổ chức nào đó cách bạn nửa trái đất. Chẳng hiểu sao bạn lại có niềm tin tổ chức đó lại có thể validate bạn trở thành level nào đó dù cách về khoảng cách địa lý, không biết bạn làm gì trong tổ chức. Nếu họ không biết bạn play như thế nào làm sao họ đo lường được Skill Set và MindSet của bạn. Đừng để “tẩy não” bởi những bài viết của các trung tâm luyện thi chứng chỉ, thực sự bạn không cần có tờ giấy nào để chứng minh bản thân. Thay vì dành thời gian và công sức để lấy chứng chỉ, dùng nó để luyện nghề nâng cao Skill set và mindset.

 

 

– – –

 

 

Website: trueskillcenter.com và Businessanalyst.vn

 

Facebook: True Skill Center 

 

Group FB: Chuyện nghề BA/PO/PM

 

Youtube: Quý Nguyễn