Nhiều bạn sẽ có suy nghĩ là IT BA là BA có khả năng lập trình hay có bằng đại học về lập trình từ lúc học đại học và ngược lại, Non IT BA là những bạn không biết lập trình.

Rất tiếc, nếu bạn đang có suy nghĩ này thì bạn sai rồi.

 

Dù là IT BA hay Non IT BA thì cả 2 role đều không cần biết lập trình ( Nếu biết thì tốt, không biết cũng chẳng sao nha ).

 

IT BA là những người làm những công việc Business Analysis ( Tạm gọi là kĩ thuật phân tích nghiệp vụ kinh doanh ) nhưng các giải pháp của bạn này thường có màu sắc digital, tức là áp dụng công nghệ vào để giải quyết các business problem của doanh nghiệp. Và bạn IT BA này là người tham gia trực tiếp vào quy trình phát triển sản phẩm số. Là cầu nối giữa team Dev và stakeholders.

 

Còn Non IT BA cũng là những người dùng kỉ thuật phân tích của BA. Giải pháp của bạn này có thể là giải pháp công nghệ số hoặc giải pháp mang tính business. Bạn này cũng không trực tiếp tham gia vào quy trình phát triển sản phẩm số. 

Thường sẽ đóng vai trò là stakeholder nhiều hơn ví dụ như Product Owner, Product Manager. Và chắc chắn một điều, bạn này không phải là cầu nối giữa team Dev với các stakeholders khác. 

Tại sao chúng ta ít thấy người ta tuyển dụng Non IT BA, vì đây chỉ là tên gọi được dung để phân biệt với các bạn IT BA. Còn thực tế, người ta gọi những người này bằng những cái tên như PO, PM ( business) hoặc Domain expert. Vai trò của bạn này thiên về việc quản lý các chỉ số đo lường sức khoẻ của business, thị trường, marketing…

 

Qua định nghĩa vừa rồi, mọi người sẽ nhận ra là, chẳng có anh nào cần “Phải biết code”. 

Tuy nhiên, Không biết code không đồng nghĩa với việc không quan tâm dev đang làm gì hoặc làm nó như thế nào. Vì vậy, cần phải bù lấp những kiến thức tech căn bản nhằm giúp cho các bạn làm việc với dev hiệu quả hơn.

 

Không đi vòng vo nữa, mình sẽ vào vấn đề chính. Đó là làm cách nào để “Điền vào chỗ trống” tech để hiểu được các bạn dev.

 

Dù công ty bạn đang làm việc đang áp dụng mô hình Agile hay Waterfall thì bạn cũng cần nắm vững được các bước để sản xuất được sản phẩm phần mềm cũng như vai trò của từng cá nhân trong vòng xoáy đó. Nếu không biết hoặc lơ mơ kiến thức này, chắc chắn chúng ta sẽ không biết hoặc không hiểu họ đang làm gì, đang ở step nào cũng như giới hạn trách nhiệm của họ. Nếu vậy, chúng ta sẽ không thể trở thành cầu nối liên kết giữa các cá nhân đó.

 

Thứ hai, IT BA cần hiểu được các kiến thức căn bản của dữ liệu gồm mối quan hệ giữa các thực thể,gọi là ERD (Entity relationship diagram) và các kiểu dữ liệu thông dụng. Nếu biết thêm được SQL nữa thì tốt (Không bắt buộc).

 

Thứ ba, đó là cách thức dev làm việc hiệu quả với nhau. Bao gồm việc pull request, merge code và deploy. Cái này chỉ cần hiểu căn bản là người ta làm gì, tại sao phải làm vậy để hiểu được họ đang nói gì.

Ngoài ra, một cái cực kì quan trọng nữa đó là integration. Để hiểu được qui trình integrate giữa các hệ thống và dev work với nhau với nhiều team nội bộ và team bên ngoài như thế nào. 

Nhiều bạn sẽ nói tại sao IT BA lại cần phải hiểu mấy cái này, đây là công việc của dev mà. Xin trả lời là yes, đây chính xác là công việc của dev, nhưng bạn là IT BA bạn cần phải hiểu để hỗ trợ và theo dõi công việc ấy. Nếu không hiểu làm sao bạn theo dõi tiến độ công việc của họ, làm sao bạn biết được cần phải làm gì để đạt được mục tiêu của BA là delivery sản phẩm chất lượng và đúng lúc đến stakeholder. Bạn sẽ là người hỗ trợ tạo task technical và theo dõi tiến độ. Tất nhiên, các task đó bạn chỉ dừng lại ở mức là viết tittle cho các task ấy, còn nội dung bên trong như thế nào là việc của dev. Khi cần, bạn sẽ là cầu nối để kéo các bạn dev khác liên quan vào 1 topic nào đó nhằm giúp việc troubleshoot công việc được dễ dàng hơn. 

Trước đây, mình cũng nghĩ công việc của dev thì để dev tự chịu trách nhiệm. Sau này, khi bản thân mình nhảy sâu vào việc troubleshoot các điểm nghẽn do giao tiếp, chênh lệch trình độ giữa các dev, sai lầm.. thì thấy công việc của mình trở nên trôi chảy hơn, cảm thấy trách nhiệm của mình mang lại nhiều giá trị cho team và phá bỏ rào cản ngăn cách giữa BA và dev.

Một rào cản lớn luôn luôn tồn tại khiến dev luôn nghĩ BA là người tạo ra công việc cho dev, hãy thay đổi nó bằng cách khiến họ nghĩ BA là người hỗ trợ công việc cho dev hoàn thành sứ mệnh phát triển sản phẩm.

 

Thứ tư, một thứ cực căn bản mà không phải IT BA nào cũng làm tốt. Đó là nói chuyện với dev bằng ngôn ngữ “Yêu cầu”. Tức là, dù biết lập trình hay không biết lập trình cũng đừng đưa ra các giải pháp technical để dev thực hiện. IT BA cần biết rõ giới hạn của mình ở đâu, tức là chỉ cần hiểu họ, đừng huớng dẫn họ lập trình dù bản thân là người có kinh nghiệm.

 

Việc chọn giải pháp technical nào 100% là công việc của dev và tech lead. Hãy đưa ra các yêu cầu, giải thích nó một cách dễ hiểu sau đó tiếp tục giải thích lại 1 lần nữa nhằm chắc chắn là họ đã nắm rõ yêu cầu, có thể hỏi dặm thêm vài câu để đảm bảo cả 2 bên đều cùng đang nhìn chung 1 “Bức tranh”.

 

Nhiều bạn IT BA thuờng mắc sai lầm trong việc dành phần lớn thời gian của mình ngồi trước màn hình máy tính để trau chuốt cho tài liệu của mình trở nên đẹp mắt, đầy đủ sau đó quăng lên google drive, jira mà không quan tâm dev có đọc hay không. Chia sẻ một thực tế mà có thể bạn chưa biết hoặc bạn biết nhưng bạn phớt lờ đó, đó là không phải dev nào cũng đọc tài liệu và không phải dev nào cũng có kĩ năng đọc tốt. Nếu bạn nghĩ đó là việc của họ thì bạn lại càng sai và vô trách nhiệm nữa. Vì nếu họ hiểu sai yêu cầu dẫn đến code sai yêu cầu. 

Từ đó sản phẩm của bạn không đạt được yêu cầu. Vậy thì mục tiêu delivery sản phẩm của bạn ngay thời điểm lúc đó đã có vấn đề rồi. Mà nếu không đạt được mục tiêu, vậy rõ ràng là bạn và cả team đều fail. 

Vậy, giờ BA cần làm gì để giảm rủi ro làm sai yêu cầu đó xuống? Đó là nhấc mông lên, tương tác với dev, nói chuyện với họ, giải thích bằng lời nói, giao diện để họ hiểu được requirement. Sau đó mới dùng chiêu cuối là đưa tài liệu, chỉ họ những điểm quan trọng cần lưu ý. Xem dev như đồng đội, không phải người làm công, lúc đó rào cản giữa BA và dev sẽ không còn. Khi cần thiết, bạn hỏi technical họ sẽ là người thầy huớng dẫn kĩ thuật cho bạn để bạn hiểu được họ đang làm gì.

 

Đầu tiên là một trí óc tò mò. Luôn đặt các câu hỏi cho bản thân và người xung quanh là cách nhanh nhất để chinh phục kiến thức mới. Tất nhiên, không phải lúc nào mình hỏi cũng nhận được câu trả lời vì tuỳ thuộc vào mối quan hệ và tương tác hàng ngày giữa bạn và dev. Nếu cả năm trời bạn chỉ nói chuyện với dev lúc họp hành mà bạn lại kì vọng họ trả lời các câu hỏi technical của bạn thì đúng là ảo tưởng. Xây dựng mối quan hệ tốt với họ. 

 

Ngoài ra, cũng cần cân nhắc câu hỏi của mình có đáng để hỏi hay không ( tức là chỉ hỏi những kiến thức nếu như bạn không tự tìm kiếm đuợc. Tôi khuyên bạn hãy tự mình tìm kiếm thông tin, chỉ hỏi khi tìm không thấy. Ví dụ như bạn nghe dev nói chuyện với nhau rất nhiều về các từ khoá như API là gì? Micro service là gì? Vậy trước khi mở miệng hỏi, hãy Google nó. Kiến thức có rất nhiều trên internet. Nếu bạn đọc mà vẫn không hiểu, lúc đó là lúc hỏi dev, nhờ họ giải thích.

Thuờng xuyên đọc các kênh thông tin kiến thức cho ngành lập trình như viblo.asia, itviec, blog của vài bạn dev chia sẻ kinh nghiệm cũng là cách để bổ sung kiến thức về tech cho IT BA.

Ngoài ra, trong quá trình làm việc, mình cũng thuờng nghe lóm những từ khoá họ thuờng sử dụng để giao tiếp với nhau. Nghe được từ nào không hiểu, mình sẽ search để xem người ta đang nói gì.

 

Chúc các bạn phá vỡ rào cản tech để trở thành IT BA.

 

P/s: Đây là kinh nghiệm cá nhân của mình, hi vọng nhận được ý kiến đóng góp xây dựng từ cộng đồng BA.