Hế lôôôô anh em,
Từ lúc lập blog đến giờ mình có viết 2 bài về Business Analyst, đó là: concept tổng quan và những công việc cụ thể hằng ngày. Đợt rồi mình có ngồi dòm lại những bài này thì hình như thấy nó thiếu thiếu gì đó.
Với những người mới, thì bài tổng quan có thể dễ hiểu, nhưng chưa cụ thể lắm. Còn bài công việc hằng ngày thì lại… quá cụ thể, đến mức hơi lộn xộn, khó để anh em hình dung 1 cách tổng thể.
Do đó mình nghĩ phải có 1 bài ở giữa 2 bài này, để hệ thống lại rõ hơn công việc của BA theo trình tự thời gian làm dự án. Từ đó anh em sẽ có cái nhìn rõ ràng hơn về công việc của BA.
Quy trình làm dự án
Đầu tiên sẽ là quy trình tổng quan như sau.

Quy trình dự án
Như anh em thấy quy trình làm phần mềm nó gồm 6 bước:
- Analysis: phân tích xem mình sẽ làm những gì
- Design: mình sẽ thiết kế phần mềm như thế nào
- Develop: mình sẽ code ra sao
- Test: phần mềm được đem đi test
- Deploy: phần mềm được đưa vào sử dụng
- Maintain: giai đoạn bảo trì, hỗ trợ khách hàng sử dụng phần mềm.
Quy trình dự án về cơ bản gồm 6 bước trên, nhưng thực tế nó sẽ linh hoạt theo từng phương pháp quản lý dự án (project management methodology).
Phương pháp quản lý dự án là những thứ như: Scrum/Agile, Waterfall, Kanban, Lean…
Ví dụ đối với Waterfall thì quy trình sẽ đi theo trình tự từ trái qua phải (không đi ngược lại), mỗi bước chỉ đi qua 1 lần.
Cụ thể như analysis xong rồi, thì mới tới giai đoạn design, rồi xong design thì mới tới develop, tương tự là test >> deploy >> maintain.
Tức mình phải đợi dự án chạy từ đầu tới cuối thì mới dòm được thành phẩm cuối cùng hình dạng nó ra sao.
Còn đối với Scrum thì anh em sẽ chia nhỏ requirements ra thành các User Story, gom vào từng Sprint Backlog để làm dần dần. Tức mình chia nhỏ ra thành từng cục để làm.
Vậy thì quy trình trên sẽ không đi từ đầu tới cuối 1 lần duy nhất, mà đi nhiều lần từ analysis -> deploy, tạo thành nhiều sprint, nhiều vòng lặp. Mỗi vòng lặp sẽ làm một số tính năng nhất định, nên thời gian sẽ được rút ngắn còn khoảng từ 2-4 tuần/ sprint.
Do đó, khách hàng sẽ thấy ngay được sản phẩm của mình thành hình dần dần, từ đó góp ý để cải thiện sản phẩm ngày một phù hợp hơn với họ.

Mình nói đoạn này để anh em hiểu bản chất làm dự án phần mềm nó cũng chỉ gồm 6 bước thôi, dù cho có làm Scrum hay Waterfall, hay bất cứ phương pháp nào.
(mặc dù ở mỗi phương pháp nó có 1 tí râu ria liên quan khác nhau, cái này mình sẽ nói sau nhé anh em…)
Một điểm nữa là requirement sẽ đi xuyên suốt từ đầu đến cuối dự án thông qua 6 bước này. Là BA, chúng ta cũng sẽ phải đi xuyên suốt từ đầu đến cuối dự án qua 6 bước này luôn.

Requirement xuyên suốt từ đầu đến cuối dự án
Giờ mình sẽ nói chi tiết về từng bước có trong dự án, và BA làm gì ở trỏng nhé anh em 😎
1. Analysis
Analysis là giai đoạn team dự án sẽ phân tích để hiểu được vấn đề của khách hàng và những gì mà họ đang mong đợi.
Đối với BA, đây chính là giai đoạn lấy yêu cầu.
Anh em sẽ làm rất nhiều bước nhỏ trong bước Analysis này để lấy yêu cầu một cách bài bản nhất (chứ không phải nói “lấy yêu cầu” là bay zô làm cái một, hỏi tùm lum tùm la là được)
Cụ thể Analysis gồm 6 bước nhỏ sau.

Thực chất mình chỉ cần focus vào 2 bước Elicitation và Analysis, vì các bước còn lại khá đơn giản, đều là những bước hiển nhiên mình phải làm.
1.1. Project Definition
Mục đích của bước này là để anh em BA chúng ta hiểu được project. Hiểu được project này làm gì, khách hàng là ai, lĩnh vực gì, vấn đề của họ ra sao, mục tiêu của họ là gì, scope dự án như thế nào…

Problem to be solved
Ví dụ như khách hàng đang dùng hệ thống SAP gặp lỗi nhiều quá, họ muốn build mới một hệ thống khác chạy ngon hơn.
Hoặc họ đang không có hệ thống quản lý kho bãi, vẫn đang tốn tiền nhân công, hiệu suất thấp, và sai sót vẫn còn xảy ra; thì đây chính là vấn đề họ cần giải quyết
Business Goal
Ví dụ họ muốn quản lý quan hệ khách hàng bằng một phần mềm nào đó. Hoặc triển khai thành công hạ tầng IoT cho 5,000 hecta cà phê đang trồng chẳng hạn.
Business Case
Là những hiện trạng cụ thể của khách hàng. Ví dụ công ty con này mới thành lập được 5 năm, hoặc công ty mới vừa bán hàng cho thị trường Châu Mỹ được gần 1 năm.
Project Scope
Phạm vi của dự án. Là BA, anh em cần phải hiểu rõ khoản này. Thường anh em sẽ chú ý tới:
- Organization Scope: ví dụ dự án được thực hiện tại Head Office ở Hồ Chí Minh, địa chỉ bao nhiêu đó. Công ty con ở Đà Nẵng hay Hà Nội không được áp dụng.
- Users Scope: hệ thống có bao nhiêu người dùng, thuộc những bộ phận nào.
- Functional Scope: cái này quan trọng nhất – mô tả những chức năng của hệ thống mà khách hàng mong muốn.
- Integration Scope: thực chất nó là 1 Non-Functional Requirement, nhưng được tách ra phần riêng, mô tả phạm vi tích hợp: hiện tại khách hàng đang dùng những hệ thống gì, cần tích hợp những components nào, tần suất ra sao, vâng vâng…
- Và cuối cùng là OUT OF SCOPE: anh em xác định trước những thứ sẽ nằm ngoài phạm vi dự án, kiểu như rào trước vậy đó.
Project Plan
Anh em đã nắm được lịch dự án của PM hay chưa, có khó khăn về thời gian không, theo lịch thì có đoạn nào cần gấp, dồn sức nhiều hay không… Và cuối cùng là.
Success Criteria
Cái này anh em có thể trao đổi với PM để hiểu hơn về dự án, về khách hàng: đâu là điểm họ kỳ vọng nhất, làm họ happy nhất. Focus vào điểm đó, anh em sẽ dễ đóng dự án hơn rất nhiều!
…
Sau khi hiểu được tổng quan dự án, anh em sẽ bắt đầu vô bước MOI MÓC YÊU CẦU – Elicitation 😎
1.2. Elicitation
Elicitation tức là moi móc thông tin, moi móc yêu cầu từ phía khách hàng. Moi móc nghĩa là nó không có sẵn để anh em lấy, mà phải làm tùm lum tùm la mới ra được.

Sự khác biệt giữa Collect và Elicit.(Nguồn ảnh: ModernAnalyst.com)
Ở bước Elicitation, anh em cần nắm được các phương pháp moi móc thông tin. Phổ biến nhất có 11 phương pháp sau:
- Meeting
- Data Analysis
- Interface Analysis
- Prototyping
- Business Rules Analysis
- Observation
- Bench Marking
- Mind Mapping
- Process Analysis and Modeling
- Survey
- Document Analysis
Sau khi nắm được 11 phương pháp, anh em sẽ đi vào quy trình Elicitation, gồm 4 bước nhỏ sau.

Mình có 2 bài note nói về nội dung này, anh em bấm vào link dưới tham khảo thêm nhé:
- 11 phương pháp moi móc yêu cầu
- 4 bước moi móc yêu cầu (như link trên)
- Những lưu ý khi lấy yêu cầu
Sau bước này anh em sẽ có output là thông tin, rất nhiều thông tin.
Trong mớ thông tin này, anh em có thể có luôn yêu cầu cụ thể, yêu cầu mơ hồ, câu trả lời từ phía khách hàng; hoặc đơn giản chỉ là những thứ mà khách hàng nói với mình vì họ nghĩ những thông tin đó là cần thiết.
1.3. Analysis
Sau khi anh em đã hiểu dự án (project definition) và moi móc được một mớ thông tin (elictation), giờ anh em sẽ lấy mớ thông tin đó ra, và bắt đầu phân tích nó.
Thường thì mọi người không hiểu “phân tích” cụ thể sẽ làm những gì. Mình cũng vậy, cho đến khi mình gặp 1 anh Manager đẹp chai mà mình rất hâm mộ. Ảnh nói rằng:
Phân tích đơn giản chỉ là sắp xếp & phân loại mọi thứ lại cho đẹp đẽ, sạch sẽ mà thôi 🙂
Hay Sandhya Jane (tác giả cuốn Business Analysis: The question and answer book) cũng có nói rằng:
“Analysis means simply breaking down the information of an object, entity, process, or anything else to understand its functioning“
Sandhya Jane
Ngẫm đi ngẫm lại thì đúng là vậy anh em ạ.
Giám đốc ngân hàng yêu cầu phân tích xem: vì sao quý này nợ xấu lại tăng cao đến như vậy?
Lúc này bộ phận kinh doanh sẽ làm gì? Chẳng phải anh sếp kinh doanh ảnh sẽ yêu cầu đổ toàn bộ dữ liệu các giao dịch cho vay trong khoảng thời gian phù hợp. Rồi phân loại rõ ràng theo các tham số: đối tượng khách hàng, phân khúc sản phẩm, hạn mức, kỳ hạn trả, vâng vâng và vâng vâng…
Anh em có nhận ra anh sếp kinh doanh này đang làm gì không? Chính xác là ảnh đang sắp xếp & phân loại mọi thứ cho ra ngô ra khoai 🙂
Để từ đó ảnh mới có thể làm tiếp công việc mà ảnh được trả hàng nghìn đô một tháng để làm, đó là: nhìn số liệu >> tìm ra vấn đề >> và giải quyết.
…
Phân tích với BA cũng tương tự như vậy.
Khi khách hàng có vấn đề trong bộ máy hoạt động, họ sẽ tìm đến mình. Và sau một loạt các buổi elicit requirement, chúng ta sẽ lấy được rất rất nhiều thông tin từ khách hàng (hoặc không).
Nhiệm vụ của anh em là phải xác định được: Đâu mới là vấn đề thực sự của khách hàng, và đâu mới là cái họ cần nhất ngay lúc này.
Hãy tưởng tưởng từ một mớ hỗn độn thông tin lấy được, chúng ta sẽ rất khó để biết được:
- Đâu mới là vấn đề thực sự của họ
- Đâu là những yêu cầu thực tế
- Đâu là những yêu cầu tầm bậy tầm bạ
- Và đâu là những thứ khách hàng thực sự nên ưu tiên vào lúc này…
Bước Analysis sẽ giúp anh em làm rõ những điều trên. Cụ thể ở bước này anh em sẽ làm những thao tác sau.

Theo trình tự, anh em sẽ:
(1) Organize
Tức là sắp xếp, tổ chức lại các requirement.
Ví dụ: tệp ảnh ra tệp ảnh, tệp ghi âm ra tệp ghi âm, thông tin về nhóm nghiệp vụ quản lý khách hàng gom chung lại 1 chỗ, nghiệp vụ quản lý chất lượng gom chung lại 1 chỗ khác, ví dụ vậy. Để mình có cái nhìn tổng quan nhất.
(2) Functional Decompose
Bước này anh em sẽ phân rã các yêu cầu thành các yêu cầu nhỏ hơn, cụ thể hơn. Mục đích là để có cái nhìn thực tế nhất về tính khả thi của các yêu cầu này.
Ví dụ họ muốn hệ thống có khả năng nhắc nhở các buổi họp định kỳ với đối tác của khách hàng (*).
Vậy thì anh em sẽ phân rã ra, để làm được yêu cầu trên thì hệ thống phải có chỗ ghi nhận được các buổi họp định kỳ đúng không anh em? Sau đó phải có một cái job nó chạy định kỳ, cứ trước 3 ngày diễn ra cuộc họp là gửi email nhắc nhở.
Vậy thì sau khi phân rã (*), anh em sẽ có như sau:
- Tính năng lưu trữ thông tin cuộc họp
- Tính năng gửi email nhắc nhở dựa trên thời gian cuộc họp.
Để sau này khi ngồi lại với dev, anh em sẽ dễ dàng giải thích và cũng dễ để xác nhận với khách hàng hơn, là: “à tụi em sẽ làm như vầy, như vầy nha chị…”. Kiểu vậy.
(3) Prioritize
Bước này là bước đánh số thứ tự ưu tiên cho từng yêu cầu cụ thể của khách hàng.
Ví dụ có 3 yêu cầu sau:
- Hệ thống phải lưu trữ được thông tin khách hàng (a)
- Hệ thống phải tự động thông báo những khách hàng đã mua hàng trên 5,000,000đ trong tháng (b)
- Hệ thống phải tạo được đơn hàng với thông tin bảng giá lấy từ hệ thống quản lý bán lẻ A Á Ớ Bờ Cờ (c)
Thì mình sẽ đánh giá mức độ ưu tiên của yêu cầu (b) thấp hơn yêu cầu (a) và (c). Vì phải có dữ liệu khách hàng và đơn hàng thì mới có thể lọc được thông tin khách mua hàng trên 5 triệu trong tháng.
Anh em có thể tham khảo một vài tiêu chí phân loại Requirements dưới đây.

Tiếp theo là 2 bước Validate và Verify. 2 bước này đều là 2 bước xác nhận, nhưng nó khác nhau ở chỗ:
(4) Validate
Do the thing right
(5) Verify
Do the right thing
…
Nói về bước Analysis, anh em tham khảo thêm bài note này nhé, mình có nói chi tiết kèm ví dụ ở note này: Hiểu về Requirement như thế lào cho đúng???
Sau 3 bước quan trọng đầu tiên: Project Definition >> Elicitation >> Analysis, anh em sẽ đi tiếp tới 3 bước cuối cùng.

Nãy giờ chúng ta đã đi được 3 bước này.
1.4. Documentation
Bước documentation nôm na nghĩa là anh em sẽ tài liệu hóa, tức là đem toàn bộ những thứ làm được nãy giờ bỏ vô tài liệu.
Tài liệu đó chính là SRS, hoặc FRD, tùy loại dự án mà mình có những loại tài liệu khác nhau nhé anh em. Nhưng mục đích chung thì vẫn là để mô tả chi tiết yêu cầu của khách hàng.
Để document thì anh em sẽ áp dụng 2 thứ sau:
- Tận dụng các template có sẵn
- Dùng ngôn ngữ mô hình hóa để document.
Ngôn ngữ mô hình hóa có khoảng 20 loại. Trong đó có 2 loại phổ biến nhất là BPMN và UML.
Template thì tùy công ty. Công ty của anh em dùng template gì thì anh em cứ dùng template đó thôi. Có thời gian mình sẽ share về các template này sau nhé.
1.5. Verification
Sau khi document xong, anh em sẽ chuyển cho team verify lại một lần nữa. Cụ thể là QA hoặc PM.
Họ sẽ kiểm tra lại xem thử anh em đã document đúng chưa, đủ các phần yêu cầu chưa. Đặc biệt là PM sẽ kiểm tra lại các yêu cầu của khách hàng đã được document chính xác và hợp lý hay chưa.
1.6. Management
Bước cuối cùng là management, tức là anh em sẽ quản lý các document sau khi đã xong xuôi. Quản lý ở đây là quản lý gì?
Ví dụ nếu requirement thay đổi, tức nội dung của tài liệu SRS hoặc FRD thay đổi, thì anh em phải đánh dấu version như thế nào, duyệt nội bộ rồi gửi cho khách hàng duyệt như thế nào.
Quản lý requirement sao cho dễ keep track cũng là một vấn đề khá nhức nhối :)) anh em nào có kinh nghiệm share bên dưới cho mình nhé.
Stop station…
Dừng chân recall một chút về 6 bước nãy giờ nhé anh em. Mục đích mình làm bài bản 6 bước này là để ra được 1 loại document mô tả chi tiết yêu cầu của khách hàng.
Như mình nói ở trên nó là SRS (Software Requirement Specification) hoặc FRD (Functional Requirement Document). Và có thể là 1 số loại template khác nữa, tùy công ty.

Trong 6 bước này, anh em lấy bước Elicitation và Analysis làm trọng tâm. Vì hầu như các bộ kỹ năng cứng của BA đều nằm ở đây hết.
Cái BA mình cần deliver được sau 2 bước này chính là REQUIREMENT. Nếu nhìn xuyên suốt qua cả 2 bước, anh em sẽ thấy requirement nó đi như sau:

Vậy là anh em đã đi xong giai đoạn Analysis trong quy trình làm dự án.
…
Bài này dài quá nên mình sẽ cắt ra. Anh em xem tiếp tập 2 ở đây nhé: Quy trình dự án, BA làm gì ở trỏng? (P2).
15/09/2019 at 1:07 sáng
e đang hơi phân vân vụ chỗ làm anh ạ. Chả là chỗ e start up xong đang thiếu người nên e hay dc quăng 1 mình 1 dự án, ko ai review. mà e lo lắng vch ko biết nên làm tiếp ko vì thấy ko học dc gì mới + trách nhiệm hơi nặng ( BA 1 mình, sai tự chịu =))))
15/09/2019 at 11:53 sáng
Nếu em cảm thấy đủ strong thì đây là cơ hội cho mình tác chiến độc lập, high risk high return :3
Còn nếu trong suốt dự án có những chỗ còn chưa tự tin, cảm thấy chưa đủ để đứng 1 mình 1 ngựa thì nên tìm chỗ nào nhiều mentor giỏi mà nhảy vào học em à. Những cái này quan trọng vì nó ảnh hưởng cách làm của mình, lâu dần dễ thành quen đó. Em cân nhắc nhé!
15/09/2019 at 11:11 sáng
(y) Hay quá anh Thịnh, cho em kết bạn làm quen nhé. Em cũng mới bắt đầu làm BA trong thời gian hơn nữa năm nay. Cần học hỏi thêm từ anh
11/08/2020 at 11:24 sáng
khúc OUT OF SCOPE, nếu không rào trước được mấy cái ngoại lệ, khi UAT khách hàng muốn thêm này thêm lọ thêm chai, thì mình làm sao để ép họ nhận đó là ngoài công việc định sẵn vậy bro?
09/09/2020 at 9:32 chiều
Cái này thì tùy nhé Châu. Tùy khách hàng và tình huống mà mình sẽ có cách deal khác nhau: feature đó làm có nhanh hay ko, impact đến system như thế nào, khách hàng này còn có deals trong tương lai nữa ko, họ có quan trọng, có tiếng nói trong lĩnh vực mình đang làm hay không, mức độ ràng buộc hợp đồng, hay agreement giữa 2 bên,….
Nói chung có rất nhiều trường hợp, nên việc có nên “ép họ nhận đó là ngoài scope” hay không cũng tùy, mà nếu có thì ép được hay không cũng tùy, phải linh hoạt.
Nhưng bản chất sau cùng vẫn là dựa trên thế win – win giữa 2 bên. Nếu mình thuyết phục được họ đây là out of scope, mà họ vẫn feeling được win-win cho cả 2 bên thì cứ vậy là triển. Khó là khó chỗ này.
Vả lại, win-win là nhìn rộng ra tổng thể cả quá trình làm dự án giữa 2 bên, chứ đừng nhìn cục bộ vào 1 situation cụ thể. Ví dụ xuyên suốt từ đầu dự án đến giờ họ support mình rất nhiệt, thì khi UAT mà có đòi thêm tính năng (và dĩ nhiên hợp lý về biz value) mà nếu ko vướng bất cứ gì thì vẫn nên support lại cho KH.
20/07/2021 at 9:10 sáng
Chi tiết quá trời, thật là mới mẻ. Cảm ơn anh nha.
31/08/2021 at 6:14 chiều
Cảm ơn e nhé
23/07/2021 at 10:18 sáng
Em thấy phần này ghi
(4) Validate Do the thing right
(5) Verify Do the right thing
còn phần trong bài requirement thì ghi
Verify = do the thing right (làm mọi việc đúng, một cách chính xác đi cái đã)
Validate = do the right thing (làm đúng việc mà khách hàng yêu cầu, đúng chức năng mà họ mong muốn)
Lúc làm quy trình BA thì nó ngược lại với requirement phải không anh, Em cảm ơn ạ
10/03/2023 at 10:52 chiều
Verified: Do the thing right
Validate: Do the right thing
Và đúng quy trình thì sẽ là Verified > Validate: Làm mọi thứ đúng và sau đó mới xác nhận lại xem mình làm đúng thứ khách hàng cần chưa.
31/05/2023 at 4:35 chiều
Cho em hỏi chị là tại sao mình không Validate trước đâu là cái khách hàng cần rồi ta Verified nó sẽ giúp đỡ tốn thời gian Verified toàn bộ, nếu mà Verified mọi thứ đúng trước nhưng chưa chắc mấy cái Verified là thứ khách hàng cần.
22/09/2023 at 3:54 chiều
“Tại sao mình không Validate trước đâu là cái khách hàng cần trước?” – Cái em nói tới là Elicatation: Khơi gợi và làm rõ yêu cầu của khách hàng.
Mình đi xác minh lại các thông tin, dữ liệu, tài liệu, yêu cầu của mình chính xác chưa, sắp xếp logic chưa, dễ hiểu chưa, đúng kỹ thuật chưa, đúng với định hướng chưa?
Sau đó, mới xác nhận cùng team và khách hàng rằng “Tôi mô tả lại yêu cầu của anh đúng chưa?”
Em hiểu theo hai nghĩa này sẽ dễ nhớ và dễ hiểu hơn nhé.
– Verify: Xác minh
– Velidate: Xác nhận
Verify > Velidate: Nó giống việc double check.
24/09/2023 at 11:43 sáng
Chị bị miss thông báo này, giờ đọc lại bài mới thấy câu hỏi của em. Cũng trả lời một lần rồi mà chưa thấy hiển thị cmt. Tầm này cũng có thể em đã rõ nhưng chắc ai đó sẽ cần nên chị vẫn trả lời, có gì mình cũng trao đổi nhé.
“Tại sao mình không Validate trước đâu là cái khách hàng cần rồi ta Verified?”
Mình vẫn hỏi khách hàng trước là khách hàng cần gì chứ, nhưng bước này không gọi là Validated mà gọi là ELICIATATION
Sau khi thấy tạm đủ thông tin thì mình làm tài liệu, mô hình, giải pháp, sơ đồ … Sau khi làm xong mình phải check lại đúng không? Xem mình đã làm đầy đủ chưa, logic chưa, tận dụng hết thông tin chưa, còn thiếu dữ liệu gì không, đã đáp ứng yêu cầu của khách hàng (theo mình nghĩ) chưa ? Bước này gọi là VERIFIED.
Rồi thì mình mới xác nhận lại với khách hàng là “Anh ơi, anh em mình trao đổi xong em đã tổng hợp nên đống này nè, anh xem em hiểu đúng ý anh chưa?”. Lúc này mới gọi là VALIDATED.
Em cứ hiểu với 2 nghĩa này sẽ dễ hơn:
Verified: Xác minh
Validate: Xác nhận
Xác minh mình làm đúng cách chưa, rồi mới xác nhận mình làm đúng ý khách hàng chưa.
27/07/2021 at 8:05 chiều
Em đang là một kẻ ngoại bang không biết tý gì về IT mà đang có dự định muốn học và làm BA đây ạ. Từ khi nhen nhóm ý định em đã tình cờ tìm được blog này và đã cũng như đang đọc các bài của anh. Rất thú vị, hy vọng anh ra thêm bài và cũng hy vọng em học hỏi và hiểu thêm được từ những bài của anh ạ. Cảm ơn anh nhiều.
03/08/2021 at 7:27 sáng
Bài viết hay quá ạ. Anh cho em hỏi phần Usecase thì mình để trong BRD hay FRD ạ?
31/08/2021 at 9:58 chiều
Để đâu cũng được nhé Phú, tùy docs em viết, tùy công ty, tùy dự án, nói chung là tùy vào mục đích của mình chứ cũng không có chuẩn nào: cho hay không cho việc để Usecase ở docs nào hết. Sắp tới anh có ra bài viết mới về FS, có gì em tham khảo thêm nhé 🙂
14/09/2021 at 2:28 sáng
bài viết ok mà có mấy chỗ vâng vâng và vâng vâng anh ạ
21/11/2021 at 4:58 sáng
Anh cho em hỏi thêm là dự phần mềm phát triển theo yêu cầu của khách hàng thì có nên áp dụng Srum không ạ? Và loại dự án nào thì không nên áp dụng Scrum ạ?
21/11/2021 at 8:32 chiều
Cảm ơn anh Thịnh. Anh cho em hỏi:
1. trong mô hình Srum, thì có cần tài liệu SRS không ạ? Tài liệu cần chi tiết ở mức độ nào ạ.
2. Trong mô hình Srum, thì phần việc của BA không nằm trong Product Backlog đúng không anh? Phần nào lập trình trong Sprint thì tài liệu của BA cần phải hoàn thành trước đó rồi đúng không ạ?
01/08/2022 at 9:46 chiều
Trong bài tìm hiểu về requirement bạn có ghi phần analysis chia làm 4 bước: Organized -> Specified -> Verified -> Validated
Nguồn: https://thinhnotes.com/chuyen-nghe-ba/requirement-trong-business-analyst-duoc-xu-ly-the-nao/
Tuy nhiên trong bài BA làm gì trong dự án, bạn lại ghi analysis gồm 5 bước: Organize -> Functional Decompose -> Prioritize -> Validate -> Verify
Nguồn: https://thinhnotes.com/chuyen-nghe-ba/quy-trinh-du-an-ba-lam-gi-o-trong-p1/
Vậy 4 và 5 bước này giống nhau không, sao thứ tự Verified và Validated lại khác nhau
12/03/2023 at 8:20 chiều
Em chào anh ạ . Hiện em đang là sv năm 2 ngành hệ thống thông tin quản lí tại Đại Học Ngân Hàng Tp.HCM ( HUB).
Em đang rất phân vân không biết em có thể theo BA được hay không .Em thực sự không hiểu về code ( các môn liên quan đến lập trình ) . Mà bản thân của em cũng thực sự không biết mình muốn gì và làm gì( vô tình hồi đăng kí thi đại học đọc được bài post của anh về ngành này tại Đại học Ngân Hàng nên là em đăng kí)
.Em cũng muốn bản thân mình thử sức sang BA ( nhưng mấy môn code trên trường làm em rất mệt mỏi ) GPA của e cx tạm ổn trên 3.2 ( tính đến thời điểm hiện tại ) .A có thể cho em lời khuyên được không ạ. Em cảm ơn anh rất nhiều và hi vọng a có thể rep lai comment của em ạ.
18/03/2023 at 3:28 chiều
Hi em, thường thì em sẽ không biết mình thích gì và hứng thú cái gì, nếu chưa thực sự bỏ công sức tìm hiểu về bất kỳ một cái gì đó.
Nên lời khuyên của anh là: nếu em đã vô tình xem được blog này, thì có thể em đã “bén duyên” đến mảng công việc Business Analysis này nói chung rồi. Nên nếu chưa biết thích gì, muốn gì và làm gì thì hãy dành thật nhiều thời gian tìm hiểu topic Business Analysis này thử xem có phù hợp không nhé.
Càng tìm hiểu, em sẽ càng TÒ MÒ. Tò mò sẽ khiến e tìm hiểu tiếp >> càng phát hiện ra cái mới, nó sẽ khiến em càng HỨNG THÚ. Từ hứng thú em cứ tiếp tục vòng lặp này, thì càng ngày em sẽ có nhiều kinh nghiệm & kiến thức hơn, dần dà nó sẽ tích tụ thành PASSION của em >> nếu tiếp tục qua nhiều tháng nhiều năm thì nó sẽ trở thành nghề, career của em. Nhớ nhé, phải bỏ công bỏ sức ra tìm hiểu cho thật tới 1 lĩnh vực thì mới biết mình có phù hợp hay không: Curiosity >> Interest >> Passion => thì khi đó mới biết được mình thích gì & muốn làm gì nhé em.
08/06/2023 at 9:05 sáng
Hi anh, e đã luôn ghim trang web này trên thanh tìm kiếm của mình từ khoảng hơn 2 năm nay. Ngoài mặt nó cung cấp những kiến thức rất bổ ích về BA, nhưng nó cũng tạo cho em động lực và hứng khởi, bởi cách trình bày, diễn giải, tưởng văn nói nhưng không hề, content vô cùng sinh động ạ.
Nhưng từ rất lâu rồi, em không thấy anh ra thêm post mới, em đã đọc hết tất cả các post của anh rồi, đọc nhiều lần luôn ấy a. 2023 này anh lên post đi anh ơiiiiiiiiiiii
19/06/2023 at 10:31 sáng
Cảm ơn em, anh sẽ sớm viết lại em nhé. Stay tuned 🙂
28/10/2023 at 10:35 sáng
Em có đọc nhiều bài của anh, cách anh truyền đạt rất hay và dễ hiểu. Đọc cái này xong thì khó mà quên vào đâu được.
Em hiện tại vừa tốt nghiệp Đại học Khoa Học Tự Nhiên nghành Kỹ thuật phần mềm (GPA: 8.14). Trong quá trình học thì em chưa đi thực tập hay đảm nhiệm bất kỳ công việc gì liên quan tới BA. Nhưng em rất hứng thú vì có tìm hiểu BA được 1 thời gian, và muốn theo con đường này lâu dài. Tuy nhiên không biết phải là do chưa có kinh nghiệm hay không, em có xin việc được gần 1 tháng nhưng chưa thấy tiến triển hay phản hồi. Em phân vân là có nên đi thực tập hay tập trung tìm luôn 1 vị trí Fresher (vì bạn em khuyên là nên tìm luôn công việc Fresher). Mong là người đi trước, anh và các anh chị cho em lời khuyên. Em cảm ơn rất nhiều ạ!
19/05/2024 at 10:21 chiều
Dear anh Thịnh,
Em có thắc mắc ở bài làm rõ về Requirement thì bước Verified được thực hiện trước bước Validate, còn ở bài này thì ngược lại,
Vậy sắp xếp 2 bước này khi lấy yêu cầu như nào là đúng theo hướng anh đang mô tả, hay em có hiểu nhầm gì ạ,
Em sẽ rất vui lòng khi nhận được phản hồi từ anh,
23/09/2024 at 11:49 chiều
Dạ cho em hỏi quy trình này anh có dùng nguồn từ sách hay trang web nào không ạ? Nếu có thì anh cho em xin thông tin nguồn với nhé ạ, em cần nguồn để làm bài báo cáo ạ. Em cảm ơn anh nhé
27/12/2024 at 6:00 chiều
anh lên nhiều post mới đi anh , tạo khoá học đi anh .Hay quá ạ !!!!!!!