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

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.
Data analyst là gì? Mô tả công việc, kỹ năng và nhiều hơn thế nữa

Dữ liệu thô sẽ không có giá trị nếu thiếu đi việc trực quan hóa dữ liệu. Đây là lý do mà Data Analyst (các nhà phân tích dữ liệu) ra đời và chuyển thể hàng trăm nghìn dữ liệu thô thành những thông tin có giá trị, giúp cho các tổ chức ra quyết định một cách sáng suốt.
Từ phân tích đến hành động: Nhà phân tích kinh doanh và giải pháp bền vững

Khi người tiêu dùng ngày càng nhận thức rõ hơn về tác động môi trường mà các doanh nghiệp để lại, chúng ta cũng bắt đầu đòi hỏi sự minh bạch và hành động có trách nhiệm từ họ.
Bí quyết thúc đẩy đổi mới: Phân tích kinh doanh và vai trò phát triển sản phẩm mới

Để có một sản phẩm thành công trước khi ra mắt cần có kế hoạch tỉ mỉ, có sự thấu hiểu sâu sắc về thị trường và quy trình thực thi hiệu quả. Khi đó, phân tích nghiệp vụ chính là điểm giao thoa của tất cả những yếu tố này.

Bình luận

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 +
Phạm Quế

Business Analyst

Khoá học Product Design của BAC đã cung cấp cho tôi nhiều kiến thức và nền tảng vô cùng hữu ích. Giảng viên giảng dạy rất nhiệt tình, truyền cho chúng tôi ngọn lửa đam mê và nhiệt huyết trong ngành. Đồng thời chia sẻ các kiến thức và kỹ năng cần thiết trong bài giảng một cách dễ hiểu hơn. Số lượng học viên không quá nhiều nên chất lượng giảng giạy vô cùng tốt. Giảng viên sửa bài tập 1-1 nên bài giảng sẽ chuyên sâu hơn.
Xem chi tiết +
Nguyễn Văn Long

Chuyên viên về chế độ kế toán & Giải pháp nghiệp vụ Tài chính kế toán trong ứng dụng CNTT - Tập đoàn Điện lực Việt Nam (EVN)

Tôi đã tham gia khóa Phân tích nghiệp vụ phần mềm cơ bản 3.0 tại BAC. Ở đây, tài liệu đào tạo cung cấp nhiều nội dung bổ ích và trình bày dễ hiểu. Giảng viên rất nhiệt tình, ngoài nội dung giảng dạy theo giáo trình còn chia sẻ nhiều kinh nghiệm thực tiễn, các câu hỏi của học viên đều được giải đáp ngay trên lớp và có minh họa từ các dự án trong thực tế. Sau tất cả, tôi cảm ơn BAC và Thầy giáo Thái Sơn.
Xem chi tiết +