Aug 18, 2016

DEVELOPER (DEV) VÀ BUSINESS ANALYST (BA) – “AI SẼ LÀ NGƯỜI CHIẾN THẮNG?”

“Developer (Dev) tin vào công nghệ như một tín đồ.

Tìm kiếm giải pháp tối ưu cho khách hàng là nhiệm vụ của BA (Business Analyst).

Họ làm việc trong cùng một team, chung tay sáng tạo cùng một sản phẩm.

Liệu “chiến tranh” sẽ xảy ra? Nếu có, ai là người chiến thắng?”

Nội dung bài viết là những dòng chia sẻ từ chị LINH NGUYỄN - BC Manager tại PYCO Group, Giảng viên tại BAC và anh DUY LÂM - Software Architect tại KMS Technology.

LINH PYCO DUY KMS

Chị LINH NGUYỄN Anh DUY LÂM

Qua những tình huống trong bài viết, họ sẽ cho bạn thấy được nhận thức, suy nghĩ cũng như cách giải quyết ở 2 góc độ BA & Dev khác nhau như thế nào? Cùng tìm hiểu nhé!

Tình huống 1: DEVELOPER CẢM THẤY CHỨC NĂNG MỚI KHÔNG THUYẾT PHỤC!

DUY: “Thuyết phục” nên hiểu theo nghĩa là “chủ động tìm hiểu”, developer cũng có trách nhiệm phải chủ động hiểu nhu cầu của khách hàng (thông qua trợ giúp của BA), và tư vấn những giải pháp thích hợp nếu cần thiết. Để hiểu được vấn đề và mong muốn của khách hàng, một trong những cách tiếp cận là thu thập phản hồi của khách hàng sớm và thường xuyên về tính năng chúng ta đang xây dựng (thông qua wireframe, mockup, workflow, user stories, v.v..). BA thường đảm nhận vai trò này, và làm việc chung vói nhóm phát triển. Nếu gặp phải chức năng nào đó lớn, với kinh nghiệm của Duy, BA có thể chia nhỏ scope ra, thành từng user stories nhỏ hơn cho nhiều Sprints. Như vậy developer và những bên liên quan có thể có chung cái nhìn về kết quả dễ dàng hơn (giống như làm 1 đại lộ thì sẽ được thi công thành nhiều phân đoạn và được bàn giao khi mỗi phân đoạn hoàn thành)."

LINH: “Có lẽ nhiều BA sẽ chọn cách giải quyết: “Okay, developers thấy không thuyết phục nhưng khách hàng muốn như vậy, và chúng ta phải làm theo” – Tiếp cận này chưa đủ thuyết phục, và đây không hẳn là giải pháp, đây là một sự áp đặt. Với tình huống này, theo Linh, BA nên chủ động tìm hiểu và so sánh các ứng dụng trên thị trường có chức năng tương tự, và sau đó quay lại chia sẻ và thảo luận với development team. Làm như vậy, nghĩa là chúng ta đang tìm kiếm sự đồng thuận và tiếng nói chung giữa 2 bên để có được kết quả tốt hơn. Bên cạnh đó, các bạn BA lại có thêm một kiến thức mới đấy! Một khía cạnh khác, biết đâu trong quá trình tìm hiểu kỹ hơn đó, BA sẽ nhận ra điều mà developer thấy không thuyết phục là chính xác? Cũng từ đó chúng ta sẽ có cách giải quyết khác và cùng tư vấn cho khách hàng.”

Tình huống 2: HIỂU LẦM YÊU CẦU, PHÁT HIỆN VÀO GIAI ĐOẠN CUỐI, NHƯ UAT

LINH:

“Lỗi không thuộc về cá nhân nào cả, lỗi là của cả team. Dự án có vấn đề là do team có vấn đề.

Trong tình huống này, tất cả team member nên ngồi lại với nhau, không phải để quy trách nhiệm cho ai, mà để tìm cách giải quyết. Quan trọng là cùng nhau triển khai dự án thành công và đáp ứng nhu cầu của khách hàng.

Theo kinh nghiệm của mình, nếu đúng là do bên mình hiểu sai vấn đề, chúng ta nên thẳng thắng nhận lỗi, sau đó những người key members của dự án nên làm việc trực tiếp với khách hàng, đưa ra kế hoạch thời gian cụ thể để sửa chữa những lỗi đó.

Trường hợp không may nhất là rơi ngay vào bản release cuối cùng, trước khi bàn giao chính thức toàn bộ cho khách hàng… Lúc này nên nghĩ đến bản vá lỗi, đương nhiên mọi vấn đề cần có sự tham gia và quyết định từ phía khách hang. Triển khai bản vá lỗi cũng là giải pháp mà nhiều tập đoàn lớn vẫn áp dụng. Không có gì là hoàn hảo và trọn vẹn ngay từ đầu được!”

DUY:

“Mình chưa có kinh nghiệm trong tình huống này. Tuy nhiên, trong các dự án Duy đã tham gia, một trong những quy tắc nhóm của Duy luôn làm theo là: các user stories sẽ được bàn giao ngay khi hoàn thành để khách hàng xem ngay, để cho mình có thời gian chỉnh sửa nếu cần.

Duy cũng thấy vấn đề này thường xảy ra ở những dự án dạng phải nâng cấp một hệ thống cũ lên công nghệ mới. Và các nhóm dự án đó vô hình đi vào lối mòn: thời gian cho BA làm việc (phân tích, nghiên cứu, thảo luận, v.v..) khá ngắn trong khi tiến độ thi công tính năng lại cần phải nhanh chóng."

Tình huống 3: LIỆU CHỨC NĂNG NÀY CÓ LÀM ĐƯỢC KHÔNG? KHÁCH HÀNG CÓ CẦN KHÔNG?

DUY:

“Tình huống này làm Duy nhớ đến một sai lầm mà developer hay mắc phải khi làm outsourcing: YAGNI (You aren’t gonna need it) và hiệu ứng quả cầu tuyết. Trong quá trình thi công một tính năng nào đó, để ngăn ngừa những thay đổi không lường trước mà có khả năng ảnh hưởng đến tiến độ: bất kì thay đổi nào cũng phải được thông báo ngay trước khi bắt tay thực hiện.

Chuyện thực tế Duy từng mắc phải: khi làm việc trên một form đăng ký cho một website quản lý hệ thống bệnh viện (khách hàng Mỹ), mình đã thêm trường Year vào phần giao diện nhập ngày tháng. Nhưng cuối cùng khách hàng không muốn có nó vì trường Year làm chậm thời gian nhập dữ liệu của họ.”

LINH: “Có thể có ba trường hợp:

1. Developer nói requirements không khả thi về mặt kỹ thuật. Trong trường hợp này, BA nên chủ động nghiên cứu về hướng tiếp cận kỹ thuật cho yêu cầu đó, không cần quá chi tiết nhưng BA nên biết chắc rằng có phải yêu cầu đó “không thật sự khả thi”. Đây cũng là một cách để BA nâng cao kiến thức của mình.

2. BA đưa requirement nằm trong giới hạn kỹ thuật: BA cùng với developer nên cùng nhau tìm hiểu và đề xuất giải pháp – thoả mãn cả về yêu cầu khách hàng và vấn đề kỹ thuật.

3. Nếu vượt ngoài tầm kiểm soát của BA: Hãy để bên thứ 3 tham gia cùng giải quyết vấn đề. Ví dụ như chia sẻ điều này cho người quản lý dự án chẳng hạn.”

Tình huống 4: BẢN MÔ TẢ YÊU CẦU CỦA BA NHƯ THẾ NÀO ĐƯỢC GỌI LÀ CHI TIẾT?

DUY: “Theo cá nhân mình, bản mô tả tính năng (trên bất kì định dạng nào như word, wireframe, video…) ở mức độ chi tiết và chất lượng tốt khi nhóm phát triển có thể đưa ra ước lượng thời gian hoàn thành (một cách tự tin). Nếu có quá nhiều thắc mắc sau khi developer đọc bản mô tả, thì tức là nó cần chi tiết hơn nữa.”

LINH: “Developer đọc hiểu và code đúng (đương nhiên sẽ có bug, nhưng là bug về technical chứ không phải bug vì hiểu sai yêu cầu khách hàng). QC có thể tạo ra test case bao phủ hết được các phân luồng trong yêu cầu khách hàng. Nếu có tranh cãi về mức độ chi tiết của thông tin, hãy tổ chức một buổi meeting, duyệt qua toàn bộ tài liệu, từ tổng quát đến từng phần chi tiết. Đoạn nào developer còn khúc mắc, BA bổ sung. Qua việc làm đó, team sẽ tránh được những trường hợp phát sinh. Bên cạnh đó, BA sẽ có thêm kinh nghiệm, biết cách tiếp cận và cải thiện sau này.”

Tình huống 5: TẠI SAO YÊU CẦU BỊ THAY ĐỔI (CHANGE REQUEST) QUÁ NHIỀU?

LINH: “Một là do kỹ năng BA chưa đủ cứng. Nếu cách approach và mức độ mô tả của BA đủ bao quát hết trường hợp, sẽ không xảy ra nhiều thay đổi yêu cầu trong quá trình phát triển sản phẩm. Vấn đề này, hãy nói chuyện với leader của bạn và tìm ra cách để hoàn thiện mình hơn. Hai là do từ phía khách hàng, BA có trách nhiệm thống nhất rõ với khách hàng, hiểu rõ lý do thay đổi và cập nhật, sau đó giải thích với development team.

Trong một dự án lớn, thời gian phát triển khoảng 5,6 tháng, mình thấy trên 30% thay đổi sẽ đến từ phía khách hàng, nếu cao hơn thì có lẽ khách hàng cũng đang có vấn đề từ phía họ.”

DUY: “Nếu một chức năng trong quá trính phân tích (chưa thi công), mà không được các bên dành nhiều thời gian để xem xét / kiểm tra kỹ lưỡng, thì những trường hợp phát sinh khi thi công và change request là chuyện đương nhiên. Theo mình, một chức năng nhỏ (khoảng 4 man-day) thường cần khoảng 3 vòng review (một vòng = gửi và nhận feedback)."

VẬY, AI LÀ NGƯỜI CHIẾN THẮNG?

Có thể những kiến thức này bạn đã biết, và cả những tình huống bạn chưa từng trải qua… Bạn có cùng quan điểm với những giải pháp, cách lý luận giống như các speakers ngày hôm nay?

Trong cuộc đối thoại, developer có chính kiến của riêng mình, BA có cách giải quyết theo họ là hợp lý. Làm việc trong cùng một team, chắc chắn không thể tránh khỏi “chiến tranh”.

Kết quả của cuộc chiến, chúng ta sẽ có gì?

>> Một sản phẩm đáp ứng được tất cả yêu cầu và thoả thuận ban đầu với khách hàng.

>> Khi đến tay end-user, họ cảm thấy hài lòng khi sử dụng và đánh giá tốt, cùng những comment tích cực.

Vậy bạn biết ai là người chiến thắng rồi đấy!

BA? Hay Developer? Không, là KHÁCH HÀNG!

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.

Nguồn: http://topit.vietnamworks.com/

Click để đọc tiếp

Lộ trình nghề nghiệp Business Analyst: Từ fresher đến BA Lead - Bạn đang ở đâu trên hành trình này?

BA là nghề hot trong lĩnh vực công nghệ và chuyển đổi số có vai trò cầu nối giữa kỹ thuật và kinh doanh giúp doanh nghiệp nhận diện rõ vấn đề và đề xuất các giải pháp phù hợp
So sánh CBAP với CCBA đâu mới là chứng chỉ dành cho bạn?

Nếu bạn đang phân vân giữa hai chứng chỉ CBAP và CCBA thì bài viết này của BAC chính xác là câu trả lời dành cho bạn. Hãy dành ít phút để tìm hiểu cũng như kiểm tra năng lực hiện tại của bản thân. Và bạn sẽ tìm được đáp án chính xác nhất cho câu hỏi của mình.
7 lợi ích của việc sở hữu chứng chỉ CBAP trong năm 2025

Chứng chỉ CBAP mang đến nhiều lợi ích cho các Business Analyst (nhà phân tích nghiệp vụ). Bên cạnh sự công nhận, thu nhập, những cách cửa cơ hội thì sự tự tin, trình độ và sự kết nối với cộng đồng những người có cùng mục tiêu với bạn cũng rất đáng chú ý.
Roadmap Business Analyst

Business Analyst (BA) là cầu nối quan trọng giữa nhu cầu kinh doanh và giải pháp kỹ thuật, đảm bảo mọi khía cạnh vận hành hiệu quả. Trong bài viết này, hãy cùng BAC khám phá các công việc chính của một BA dựa theo nhiệm vụ cụ thể, con đường thăng tiến lên vị trí BA Manager.

Bình luận

Lê Anh Tuấn

Chuyên viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi là nhân sự thuộc Trung tâm Phát triển CNTT – Khối Ngân hàng số, hiện đang đảm nhiệm vai trò kiểm thử phần mềm (tester). Việc tham gia khóa học Business Analyst đã mang lại cho tôi góc nhìn toàn diện và rõ ràng hơn về vai trò của BA trong lĩnh vực ngân hàng.

Khóa học Fundamental Business Analysis tại BAC không chỉ giúp tôi hiểu đúng bản chất công việc BA mà còn hỗ trợ phát triển tư duy nghiệp vụ – từ tiếp cận giải pháp kỹ thuật sang tập trung vào nhu cầu người dùng. Phương pháp giảng dạy kết hợp lý thuyết và thực hành thực tiễn, cùng các hoạt động mô phỏng, thảo luận nhóm đã giúp tôi nâng cao kỹ năng giao tiếp, phân tích và trình bày yêu cầu – những năng lực thiết yếu để phối hợp hiệu quả giữa các bên trong dự án công nghệ.

Xem chi tiết +
Huỳnh Cao Cường

Nhân viên HO - Kỹ thuật Ngân hàng số Eximbank

Tôi hiện đang công tác tại Trung tâm Phát triển CNTT – Khối CNTT, với vai trò là nhân sự chức năng phụ trách mảng Ngân hàng số, chuyên sâu về kiểm thử phần mềm (Tester). Trước khi tham gia khóa học Fundamental Business Analysis do BAC tổ chức, tôi từng hình dung BA chỉ đơn thuần là cầu nối giữa bộ phận kỹ thuật và nghiệp vụ.

Tuy nhiên, quá trình học đã giúp tôi nhận thức rõ hơn về bản chất và tầm quan trọng của vị trí này. BA không chỉ kết nối các bên liên quan, mà còn giữ vai trò định hình yêu cầu, đảm bảo giải pháp được thiết kế đúng mục tiêu và sát với nhu cầu thực tế. Khóa học đã trang bị cho tôi tư duy phân tích bài bản, khả năng diễn đạt yêu cầu rõ ràng, và kỹ năng phối hợp hiệu quả trong môi trường dự án đa chiều.

Với nền tảng công nghệ thông tin sẵn có, khóa học là bước chuyển hướng quan trọng giúp tôi phát triển tư duy nghiệp vụ vững chắc và sẵn sàng theo đuổi lộ trình nghề nghiệp chuyên sâu trong lĩnh vực Business Analysis tại Eximbank.

Xem chi tiết +
Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +

Professional Transfer Services in Batumi

Luxury Georgian Transfer Services – Tbilisi & Batumi

Airport Transfers in Georgia

Lộ trình nghề nghiệp Business Analyst: Từ fresher đến BA Lead - Bạn đang ở đâu trên hành trình này?

So sánh CBAP với CCBA đâu mới là chứng chỉ dành cho bạn?

7 lợi ích của việc sở hữu chứng chỉ CBAP trong năm 2025

Roadmap Business Analyst

CÔNG TY CỔ PHẦN ĐÀO TẠO VÀ TƯ VẤN BAC