Cảm ơn em nhé. Your comment made my day 🙂

Dạo gần đây em đang muốn chuyển ngành từ Customer Service sang BA. May mắn được bạn em gửi cho blog của anh. Sau vài ngày ngồi cày blog anh thì từ một đứa không biết tẹo gì về BA hay thế giới IT thì giờ em đã biết tổng quan các khái niệm và công việc của BA, hơi chút tự tin để có thể apply vài job BA chém gió rồi :)))

Đọc blog của anh rất thú vị. Anh có năng khiếu biến những kiến thức khô khan trở nên rất “hài” và dễ nuốt.

Cám ơn anh rất nhiều đã bỏ nhiều công sức để viết những bài viết rất chất lượng trên blog, thật sự kiến thức trên blog và những trải nghiệm của anh giúp ích cho em rất nhiều!

Chúc anh mạnh khoẻ và luôn thành công trong công việc anh nhé!

Good question em, nên mình mới có QC để đảm bảo quality của software đó em. Tất cả cũng sẽ quay ngược lại BA, như thế nào là “good quality”? Good quality trong ngữ cảnh này là như thế nào.

Tính năng “lướt tin tức” của software A vào thời điểm X nó sẽ có 1 cái “tiêu chuẩn good”, khác với cái “tiêu chuẩn good” nếu so với cùng tính năng “lướt tin tức” nhưng của software B vào 1 thời điểm Y khác nữa.
Nghĩa là việc good như thế nào nó rất muôn hình vạn trạng, tùy vào effort của team lúc đó, mức độ urgent cần release như thế nào, hay quality của team lúc đó đáp ứng được ở mức nào,… mọi thứ đều phải được canh chỉnh theo đúng thực tế và CẦN ĐƯỢC DEFINE RÕ BỞI BA hoặc người làm Product.

Nên ở câu chuyện này nói thì dễ, nhưng để set một cái expectation bar chuẩn cho cả team là cả 1 quá trình em nhé. Và hoàn toàn linh hoạt ở mỗi thời điểm, mỗi tính năng, mỗi dự án, mỗi sản phẩm khác nhau.

Nếu mọi thứ được define rõ, và có thể đo lường thì dev team cứ thế mà chạy thôi. Không còn những cái mơ hồ như “thế này mới đẹp, mới ổn, mà trong khi mỗi ông lại có định nghĩa cái đẹp khác nhau” nữa. Cứ release rồi QC verify, mọi thứ minh bạch hoàn toàn.

Trong công nghệ thì đúng là ko có sự khác biệt rõ ràng, vì SW là Product nếu công ty đó sở hữu SW đó. giống như người ta hỏi Product cúa cty bạn là gì, thì trả lời ngày đó là phần mềm A,B,C….

Mọi người cho ý kiến nhé.

Cảm ơn Linh, good luck em nhé

Cảm ơn câu hỏi của em. Thật ra CHUẨN hay không thì mình lại quay về “definition of done” (DoD) của feature, hay user story đó. Rõ ràng mỗi người có một góc nhìn “chuẩn” riêng, nhưng nếu quy về DoD thì cả team đều “on the same page” và mỗi người đều biết được mình cần phải deliver feature đó ra hình ra dáng như thế nào.

Các cách em nói là các phương pháp mình có thể dùng để moi móc thông tin >> từ đó định nghĩa được thứ mình cần deliver cho khách hàng. Ví dụ: Benchmarking như em nói cũng hay được dùng để định nghĩa những tính năng mới cần làm, mà đối thủ người ta đã làm trước đó rồi.
Và dĩ nhiên “chuẩn” có thể được nâng dần lên hoặc giảm dần theo thời gian. Ví dụ như trước chuẩn load dữ liệu là như này (là ABC), nhưng về sau network ngày càng phát triển, thì ngta lại có một số các “chuẩn” cho tốc độ load dữ liệu khác (như XYZ)…

Đó là “chuẩn” theo task công việc. Còn “chuẩn” trong bài thì anh nói đến thái độ làm việc nhiều hơn. Tức anh em cần đặt mình vào tâm thế của người dùng feature đó. Xem thử trong bối cảnh sử dụng thực tế, thì cái mình deliver có “chấp nhận được” hay không. Ở một góc độ nào đó, thì “có thể chấp nhận được” cũng được xem như chuẩn. Từ đó, tùy thuộc vào nhiều yếu tố để mình có thể tiếp tục lắng nghe người dùng và enhance các features lên dần to get it better 🙂