Hai Lúa học Business Analysis

25/07/2025

☎️BA Essentials T9/25 Hai Lúa mở 𝗗𝗲𝗮𝗹 𝟯.𝗫𝘅𝘅𝗸 đợt cuối ạ
Chỉ trong 2 ngày cuối tuần này 🥰🥰

19/07/2025

🔥 BA Essentials hân hạnh góp mặt trong sự nghiệp BA của các bạn 🥰🥰🥰

Nhà em chỉ còn khoá T9/25. Hai Lúa xin mời 🥰

09/07/2025

Nhà Hai Lúa share lại chuỗi bài viết cho các bạn cần tìm hiểu mảng Product 🥰🥰🥰

Nhà không mở lại khoá, kiến thức các bạn tìm đọc thêm nhé 🥰

🌻 Chào các bạn 🌻

Sau khoảng thời gian làm IT BA, các bạn chắc sẽ bắt đầu tò mò hơn về các hướng phát triển career path như thế nào, nâng cao ra sao. Nói tới nâng cao - Advanced về IT BA có khá nhiều kiểu nâng cao, ví dụ như nâng cao bằng chuyên sâu về doc tool, nâng cao bằng kiến thức & kinh nghiệm nghiệp vụ v.v; và một trong các hướng nâng cao của IT BA có thể kể đến đó là hướng phát triển theo mảng Phát triển sản phẩm. Hôm nay, Hai Lúa bắt đầu chia sẻ một Series mới, mang tính nâng cao hơn, đó là về mảng phát triển và quản lý sản phẩm dành cho các bạn IT BA.


🏓 𝗧𝗔̣̂𝗣 𝟭 – 𝗚𝗜𝗢̛́𝗜 𝗧𝗛𝗜𝗘̣̂𝗨 𝗩𝗘̂̀ 𝗣𝗥𝗢𝗗𝗨𝗖𝗧 𝗗𝗘𝗩𝗘𝗟𝗢𝗣𝗠𝗘𝗡𝗧 𝗔𝗡𝗗 𝗠𝗔𝗡𝗔𝗚𝗘𝗠𝗘𝗡𝗧 🏓


Nói về sản phẩm số, công nghệ số thì sẽ có hai mảng chính, thứ nhất là phát triển & quản lý sản phẩm, mảng thứ hai đó là gia công sản phẩm. Phần lớn mọi người bắt đầu IT BA, cũng như phần lớn IT BA nhìn thấy trên thị trường, nằm ở mảng Gia công sản phẩm. Bản thân mình cũng bắt đầu career path bằng mảng gia công, lấy yêu cầu rồi phát triển phần mềm/ hệ thống.
Sau khoảng thời gian dài trau dồi kiến thức, kinh nghiệm và nghiệp vụ thì mình mới được chuyển sang mảng phát triển & quản lý sản phẩm. Và mảng này mới thực sự cho các bạn bắt đầu vào Business Analysis đúng nghĩa, theo đúng định nghĩa của IIBA về Business Analysis.

Trên thị trường nói về mảng phát triển & quản lý sản phẩm, chúng ta vẫn sẽ thấy có những nhập nhằng về mặt title, cách gọi mảng này. Một trong những tình huống nhập nhằng là có những nơi gọi là product manager, có những nơi gọi là product owner, như vậy cách gọi nào đúng. Quan điểm cá nhân, cách gọi Product Manager mới chính xác nói về những người làm ở mảng phát triển & quản lý sản phẩm. Thế còn Product Owner (PO) thì sao? Các bạn nên hiểu PO là tên gọi của một vai trò khi áp dụng mô hình quản lý dự án Agile – Scrum.

Để nói đúng về PO ở tình huống này, chúng ta phải xét 02 bước.

- Bước 1: là xét mô hình quản lý dự án, nếu như dự án phát triển sản phẩm theo mô hình Agile – Scrum thì mới có PO, còn không thì không nên gọi là PO.

- Bước 2: là phải xét phạm vi công việc, nếu như cả sản phẩm là một dự án thì PO khi đó tương đương Product Manager, còn nếu như chỉ đơn giản là nhận gia công thì khi đó PO chỉ đóng vai trò delivery chứ không phải Product Manager. Đôi khi chúng ta có những ngộ nhận chỉ vì Title và ở VN, title dùng khá lung tung.


Trong series này, mình sẽ nói về Product Development and Management (gọi tắt trong cả series là PDM) và sẽ không đề cập tới title Product Manager hay Product Owner.

🥊 Để làm công việc PDM, đòi hỏi các bạn sẽ kết hợp giữa phát triển và gia công. Một sản phẩm ra đời xuất phát từ ý tưởng/nhu cầu/ chiến lược. Sau đó, sản phẩm sẽ được kiểm chứng để đảm bảo sự hiệu quả của sản phẩm rồi từ đó mới bắt đầu mô tả sản phẩm rồi chuyển giao để gia công sản xuất. Sản xuất xong sẽ đưa ra thị trường để bán, và cái đích đến cuối cùng của một sản phẩm nó nằm ở lợi nhuận mà nó mang lại cho công ty, cho tổ chức.

Theo kinh nghiệm làm PDM bản thân, muốn làm được công việc PDM cần một số điều như sau:

- Đầu tiên bạn cần có “Business development acumen” - tức là sự nhạy bén về mặt kinh doanh, kinh tế thị trường. Gia công thì chỉ sản xuất theo yêu cầu, đúng số lượng đúng đơn đặt hàng còn phát triển đòi hỏi các bạn phải làm chủ được sản phẩm và phải bán được nó. Vì vậy, trước tiên bạn phải xem bạn có khiếu kinh doanh hay không, có nhạy bén về thị trường, về nhu cầu thị trường hay không.

- Điều thứ hai cần có đó là tư duy tổng quan. Làm sản phẩm đòi hỏi bạn khá ba đầu sáu tay vì phải xử lý rất nhiều khía cạnh, mà không có sự tổng quan trong tư duy, trong nhận định, trong cách sắp xếp, trong xử lý công việc v.v thì rất khó để làm việc từ lớn tới nhỏ.

- Điều thứ ba là sự thấu hiểu. Thấu hiểu ở đây là cảm được, thấu hiểu được thị trường, được khách hàng/ người dùng, được xu hướng.

- Điều thứ tư là sự điềm tĩnh, suy xét vấn đề một cách thấu đáo, không bị cuốn theo thị trường, xu hướng, không bị cuốn theo những trào lưu


🛷 Có khá nhiều bạn hỏi mình là em làm IT BA, làm PO được vài năm rồi, em muốn làm Product Manager, làm công việc PDM. Cụ thể hơn là đôi khi mình hay nghe các bạn phát biểu là 03 năm e lên PO, 5 năm em sẽ lên Product Manager. Tuy nhiên khi mình test thì thực sự không đủ sức làm PDM vì thiếu một số phẩm chất ở trên. IT BA đã khó, PDM còn khó hơn do khi làm PDM là bạn đang nắm sự sống còn của một doanh nghiệp chứ không phải kiểu như gia công nữa. PDM từ thấp như Association Product Manager, Product Manager cho tới những vị trí quản lý Mid-Senior như Head of Product, Product Director và cao nhất có thể nói là Chief Product Officer đều là những người gánh trên vai trách nhiệm kiếm tiền cho công ty, tổ chức, doanh nghiệp.

🌼🌼 Tóm lại, hãy chuẩn bị cho bản thân thật tốt trước khi gánh lấy trách nhiệm nhé. Trong các tập tiếp theo, mình sẽ chia sẻ cho các bạn từng yếu tố, từng bước, từng cách làm v.v cả khâu PDM và khâu gia công để mọi người hiểu rõ hơn và có cái nhìn tốt hơn về Product Development and Management nhé.

🌸🌸 Chúc các bạn thành công nếu lựa chọn phát triển nâng cao theo hướng PDM 🌸🌸

29/06/2025

⭕️Thông tin Khoá học 𝗕𝗨𝗦𝗜𝗡𝗘𝗦𝗦 𝗔𝗡𝗔𝗟𝗬𝗦𝗜𝗦 𝗘𝗦𝗦𝗘𝗡𝗧𝗜𝗔𝗟𝗦 Tháng 9/25⭕️
--------------------------------------
🔥 phiên bản thay thế BA FOUNDATION giúp bạn xây dựng hành trang vững chắc trở thành BA 🌸

➖ Khai giảng: 19:15 ngày 10/9/2025.
➖ Thời gian: 𝟭𝟴 𝗯𝘂𝗼̂̉𝗶 ++, từ 19:15-21:45 Thứ 2 và Thứ 4 hằng tuần.
➖ Hình thức: Online qua Zoom (có video record mỗi buổi học để xem lại, link truy cập vĩnh viễn)

𝗡𝗼̣̂𝗶 𝗱𝘂𝗻𝗴 khoá học trang bị đầy đủ kiến thức, kỹ năng căn bản cho bạn trở thành BA trong thời điểm hiện tại, phù hợp cho cả IT hay Non-IT bao gồm: Tư duy BA và áp dụng phương pháp tư duy trong công việc, thực hành sử dụng công cụ của BA, thiết kế hệ thống, CSDL, UI/UX, viết tài liệu ITBA, ... và các nội dung khác có liên quan mà 1 BA cần phải biết ❤️ (𝒔𝒚𝒍𝒍𝒂𝒃𝒖𝒔_𝒉𝒂𝒊𝒍𝒖𝒂_𝒔𝒆̃_đ𝒆̂̉_𝒐̛̉_𝒄𝒎𝒕)

𝗧𝗵𝗼̂𝗻𝗴 𝘁𝗶𝗻 𝗧𝗿𝗮𝗶𝗻𝗲𝗿𝘀:
- Mr. Thanh Trần, Deputy Head of Corporate Banking Product - OCB, Cựu PM - BStar Solution, Cựu AVP - Timo (https://www.linkedin.com/in/thanhtran3007/)
- Ms. Thanh Tâm, BA Lead -ACB, Cựu BA Expert - FE(https://www.linkedin.com/in/tammy-bui-thi-thanh-tam-0a7b6113a/)

💌 Hai Lúa chỉ nhận dky duy nhất qua ib ở page này thôi nhé mọi người.♨️

- Suốt quá trình học và sau khi kết thúc, các bạn sẽ luôn nhận được sự hỗ trợ chuyên môn từ trainers của Hai Lúa.

🌻Hai Lúa cảm ơn🌻

26/06/2025

Ba Essentials T9/2025 sẽ có deal đậm sâu vài ngày tới 🥰🥰🥰

07/06/2025

Chào các bạn,

Trong bài trước, mình đã đề cập đến việc UC/UCD rất ổn trong việc triển khai dự án hơn các bạn nghĩ và bản thân mình cũng dùng cách appraoch bằng UC như 1 chân ái trong quá trình phát triển. Bài viết này chúng ta cùng tìm hiểu và Tổng kết lại Series này nhé

🔥𝗧𝗔̣̂𝗣 𝟲 (𝗘𝗡𝗗) - 𝗧𝗥𝗜Ể𝗡 𝗞𝗛𝗔𝗜 𝗗𝗨̛̣ 𝗔́𝗡 𝗕Ằ𝗡𝗚 𝗨𝗦𝗘 𝗖𝗔𝗦𝗘 𝗔𝗣𝗣𝗥𝗢𝗔𝗖𝗛🌻


Trong triển khai dự án (Project implementation), một trong các mô hình chúng ta hay dùng tất nhiên là Agile – Scrum. Trong mô hình, theo lý thuyết thì user story là công cụ chính để mô tả yêu cầu người dùng. Tuy nhiên, user story thường khá ngắn gọn, chỉ mô tả một khía cạnh nhỏ hoặc một chức năng đơn lẻ.

Đối với các hệ thống lớn, phức tạp như Mobile Banking chẳng hạn, việc chỉ dùng user story có thể khiến nhóm phát triển bỏ sót khá nhiều logic nghiệp vụ, business rule, luồng ngoại lệ hoặc chi tiết về tương tác giữa các thành phần hệ thống.

𝐔𝐬𝐞 𝐜𝐚𝐬𝐞 𝐚𝐩𝐩𝐫𝐨𝐚𝐜𝐡 khắc phục nhược điểm này, lý do đơn giản, ví dụ như UCD thể hiện rõ chi tiết hệ thống sẽ ra sao, các component xong quanh liên kết thế nào, đầy đủ luồng chính luồng phụ, rule v.v từ Use case specification. Chưa kể, các bạn thấy User story phản ánh nhu cầu nghiệp vụ, còn use case approach phản ánh hệ thống. Hệ quy chiếu của User Story khác với hệ quy chiếu của việc triển khai hệ thống, độ lệch này làm cho User Story trong thực tế không hiệu quả như Use case approach.


🔵Vậy chúng ta triển khai với UC Approach ra sao ?
➖🔺mình lấy 𝐯𝐢́ 𝐝𝐮̣ 𝐯𝐞̂̀ 𝐭𝐫𝐢𝐞̂̉𝐧 𝐤𝐡𝐚𝐢 𝐂𝐡𝐮̛́𝐜 𝐧𝐚̆𝐧𝐠 𝐁𝐢𝐥𝐥 𝐏𝐚𝐲𝐦𝐞𝐧𝐭 𝐜𝐡𝐨 𝐮̛́𝐧𝐠 𝐝𝐮̣𝐧𝐠 𝐌𝐨𝐛𝐢𝐥𝐞 𝐁𝐚𝐧𝐤𝐢𝐧𝐠.

Chúng ta có 1 UCD theo hình đính kèm.
Từ đây, chúng ta sẽ thực hiện các công việc:

✔️ Từ UCD, chúng ta thấy cần xử lý các hạng mục như Quản lý hóa đơn, Thêm hóa đơn, Thanh toán... Chưa kể các UC này cần phải kết nối và tích hợp với các nhà cung cấp dịch vụ như EVN, nước, internet v.v. Những nội dung này giúp cho bạn Product Owner (PO) rất dễ dàng xử lý các công việc như Grooming, ý thức được trao đổi với các nhà cung cấp để lấy thông tin kết nối... Chi tiết về công việc rất rõ ràng để PO làm việc chứ không chung chung như User Story.

✔️ Khi triển khai, chúng ta cũng nhìn rõ thứ tự ưu tiên của từng hạng mục, cái nào trước, cái nào sau. Bên cạnh ưu tiên, vì chúng ta nắm rõ specification của từng UC, PO hoàn toàn chủ động trong việc đánh giá thời gian, nguồn lực để thực hiện, tránh những trường hợp over hay đặc biệt là underestimate.


Không chỉ hỗ trợ các vai trò như PO, SM trong công việc, UC Approach cũng hỗ trợ các công cụ khác của BA như Class Diagram, ERD để phát triển kiến trúc hệ thống. Use case approach giúp xác định các chức năng nghiệp vụ, là bước đầu tiên để xác định các thực thể (entity) và mối quan hệ giữa các actor với hệ thống. Khi xây dựng mô hình đối tượng thông qua class diagram, BA có thể dựa vào Trigger, Path, Pre/post-condition của UC để xác định các class, method, thuộc tính cần thiết. Những nội dung trên cũng là cơ sở để xác định bảng dữ liệu (entity), trường dữ liệu (attribute) và relationship.


Các bạn thấy đấy, 𝐔𝐬𝐞 𝐜𝐚𝐬𝐞 𝐚𝐩𝐩𝐫𝐨𝐚𝐜𝐡 𝐭𝐡𝐨̂𝐧𝐠 𝐪𝐮𝐚 𝐜𝐚́𝐜 𝐜𝐨̂𝐧𝐠 𝐜𝐮̣ 𝐔𝐬𝐞 𝐜𝐚𝐬𝐞 𝐯𝐚̀ 𝐔𝐬𝐞 𝐜𝐚𝐬𝐞 𝐝𝐢𝐚𝐠𝐫𝐚𝐦 𝐥𝐚̀ 𝐩𝐡𝐮̛𝐨̛𝐧𝐠 𝐭𝐡𝐮̛́𝐜 𝐦𝐚̣𝐧𝐡 𝐦𝐞̃ 𝐠𝐢𝐮́𝐩 𝐁𝐀 𝐤𝐢𝐞̂̉𝐦 𝐬𝐨𝐚́𝐭 𝐩𝐡𝐚̣𝐦 𝐯𝐢, 𝐩𝐡𝐚̂𝐧 𝐭𝐢́𝐜𝐡 𝐧𝐠𝐡𝐢𝐞̣̂𝐩 𝐯𝐮̣ 𝐤𝐲̃ 𝐥𝐮̛𝐨̛̃𝐧𝐠, đ𝐚̣̆𝐜 𝐛𝐢𝐞̣̂𝐭 𝐡𝐮̛̃𝐮 𝐢́𝐜𝐡 𝐤𝐡𝐢 𝐭𝐫𝐢𝐞̂̉𝐧 𝐤𝐡𝐚𝐢 𝐜𝐚́𝐜 𝐝𝐮̛̣ 𝐚́𝐧 𝐥𝐨̛́𝐧, 𝐩𝐡𝐮̛́𝐜 𝐭𝐚̣𝐩 𝐭𝐡𝐞𝐨 𝐀𝐠𝐢𝐥𝐞 𝐒𝐜𝐫𝐮𝐦. Việc kết hợp use case với user story sẽ giúp quá trình phát triển vừa linh hoạt vừa chặt chẽ, rõ ràng. Use case là cầu nối hiệu quả giữa business, developer và tester, giúp mọi bên hiểu rõ hệ thống cần xây dựng.


🔥Thông qua 6 bài viết về USE CASE, hy vọng giúp các bạn có 1 cái nhìn khác và sử dụng các công cụ xoay quanh Use case như một công cụ chính trong quá trình xây dựng mô hình và kiến trúc của giải pháp, của hệ thống. Bên cạnh tính hiệu quả của nó thì các bạn cũng lưu ý những vấn đề hiểu chưa đúng, hiểu theo dạng Dịch nghĩa với các khái niệm, ký hiệu của Use case, Use case diagram để giúp cho việc phân tích được chuẩn xác, người xem hiểu chuẩn hiểu đúng các nội dung mà bạn muốn trình bày, nhất là khi các bạn muốn làm việc với đối tác nước ngoài, remote/ freelance cho dự án ở nước ngoài.


Chúc các bạn thành công với BA ❤️

Xin chào các bạn😁

31/05/2025

#5 - Series về Database và SQL dành cho IT BA

SQL có lẽ là một trong những nội dung mà các bạn khá hứng thú khi học IT cho IT BA. Lý do có thể là vì các bạn thấy JD nhiều công ty đòi hỏi SQL.

Tuy nhiên, SQL không phải khó học, cũng không phải là ưu tiên đầu tiên của các bạn khi học về IT, về lập trình. Nói về Database thì các bạn nên học MS Access trước để định hình tư duy vì khi các bạn không có tư duy thì có biết coding SQL cũng không biết hình thành nên bảng biểu như thế nào cả.

Thank you 🥰

28/05/2025

🟢🟢🟢Hai Lúa đang có DeaI 🔻2️⃣5️⃣% cho BA in Practice with Banking Domain
-----
Trainer nhà mình cũng đang tuyển 1 bạn cho vị trí BA trong Bank 🔵

26/05/2025

🟢Đỉnh nóc kịch trần bay phấp phới 🌼
❤️Chúc bạn ấy ngày càng thành công🌻

26/05/2025

🌻 BA Essentials với Hai Lúa hôm nay còn 3️⃣X9️⃣9️⃣k – đỡ hại ví, chất như nước cất!🤣🤣

25/05/2025

Chào các bạn🌻,

Chúng ta đã đi qua các kiến thức cơ bản của Use case diagram, về một số ký hiệu nâng cao và các vấn đề lỗi khi sử dụng UCD.

Ở bài viết này, chúng ta cùng nói về ứng dụng của UCD trong quá trình phát triển phần mềm. Trong IT BA, có rất nhiều mô hình, diagram, nhưng chúng ta thường sa lầy vào trong chi tiết kỹ thuật ngay từ đầu, làm cho ranh giới hệ thống mờ nhạt. UCD sẽ giúp chúng ta khắc phục những giới hạn đó.


🔥𝐓𝐀̣̂𝐏 𝟓: 𝐗𝐀̂𝐘 𝐃𝐔̛̣𝐍𝐆 𝐌𝐎̂ 𝐇𝐈̀𝐍𝐇 𝐇𝐄̣̂ 𝐓𝐇𝐎̂́𝐍𝐆 𝐁𝐀̆̀𝐍𝐆 𝐔𝐒𝐄 𝐂𝐀𝐒𝐄 𝐃𝐈𝐀𝐆𝐑𝐀𝐌

Quan điểm cá nhân của mình UCD vẫn là một chân ái sau bao nhiêu mô hình mình đã nghiên cứu đã sử dụng qua nhiều dự án lớn nhỏ khác nhau.
Với mình, 𝐔𝐂𝐃 𝐦𝐚̣𝐧𝐡 𝐦𝐞̃ 𝐡𝐨̛𝐧 𝐜𝐚́𝐜 𝐦𝐨̂ 𝐡𝐢̀𝐧𝐡 𝐤𝐡𝐚́𝐜 𝐯𝐢̀ 𝐧𝐡𝐢𝐞̂̀𝐮 𝐮̛𝐮 đ𝐢𝐞̂̉𝐦

- 𝐆𝐨́𝐜 đ𝐨̣̂ 𝐭𝐨̂̉𝐧𝐠 𝐪𝐮𝐚𝐧, khác với nhiều mô hình khác khá tập trung vào chi tiết hoặc xử lý mô tả đơn lẻ, UCD cho chúng ta một “big picture” khá rõ về hệ thống đang xây dựng và các hệ sinh thái, thành phần kết nối xung quanh.

- 𝐆𝐨́𝐜 đ𝐨̣̂ 𝐜𝐡𝐢 𝐭𝐢𝐞̂́𝐭, UCD giúp xác định phạm vi của hệ thống rất rõ ràng, UC nào thuộc hệ thống nào, liên kết với nhau ra sao. Với system boundary của UCD, chúng ta nhìn rất rõ hệ thống nào đang làm, đang xây, hệ thống nào bên ngoài cần tích hợp, kết nối. Ngay từ những giai đoạn đầu của dự án đã đòi hỏi phải hoàn thiện mô hình rất rõ, không đợi cho tới khúc cuối rồi mới phát hiện thiếu này thiếu kia.

- 𝐆𝐨́𝐜 đ𝐨̣̂ 𝐡𝐨̂̃ 𝐭𝐫𝐨̛̣ 𝐜𝐨̂𝐧𝐠 𝐯𝐢𝐞̣̂𝐜 𝐪𝐮𝐚̉𝐧 𝐥𝐲́ 𝐝𝐮̛̣ 𝐚́𝐧: UCD phản ánh hệ thống, giúp xử lý dự án cực kỳ chuẩn xác chứ không kiểu chung chung như User Story. Nội dung này mình sẽ nói ở tập tiếp theo của chuỗi bài viết.

- 𝐆𝐨́𝐜 đ𝐨̣̂ 𝐡𝐨̂̃ 𝐭𝐫𝐨̛̣ 𝐊𝐢𝐞̂̉𝐦 𝐭𝐡𝐮̛̉: UCD hỗ trợ rất tốt cho quá trình kiểm thử khi có một “big picture”, giúp chúng ta lên testcase hiệu quả, kiểm thử được full luồng dễ dàng, hạn chế thiếu case, hạn chế thiếu luồng. UCD đặc biệt hiệu quả trong quá trình test UAT – Kiểm thử chấp nhận người dùng. Bản thân mình qua nhiều dự án, UCD đã giúp cho mình hạn chế nhiều lỗi, thiếu case, thiếu luồng, giúp cho phần mềm đạt chất lượng cao.

🟡Chúng ta xem 1 ví dụ ngắn gọn để dễ hình dung nhé. 𝑯𝒊̀𝒏𝒉 𝒎𝒊𝒏𝒉 𝒉𝒐𝒂̣ 𝒅𝒖̛𝒐̛́𝒊 đ𝒂̂𝒚 𝒍𝒂̀ 𝒎𝒐̣̂𝒕 𝑼𝑪𝑫 𝒎𝒐̂ 𝒉𝒊̀𝒏𝒉 𝒉𝒐́𝒂 𝒑𝒉𝒂̂̀𝒏 𝒎𝒆̂̀𝒎 “𝑸𝒖𝒂̉𝒏 𝒍𝒚́ 𝒕𝒉𝒖̛ 𝒗𝒊𝒆̣̂𝒏”, bao gồm các mảng miếng chính:
✔️ 1 system boundary thể hiện các UC của phần mềm
✔️ Các system boundary thể hiện các hệ thống cần liên kết như payment gateway, ERP của thư viện…

🟡Từ đây, chúng ta làm được gì?

- Chúng ta có thể hình dung được toàn bộ bức tranh hệ thống có gì, ra sao, để rồi từ đó có thể phát triển hơn giải pháp như là xây dựng web hay mobile app, rồi cần các function/ feature ra sao để hoàn thiện.
- Chúng ta nhìn vào cũng sẽ biết được là: cần liên kết với các hệ thống nào xung quanh, liên kết cái gì, để làm gì.
- QC cũng dễ dàng nhìn vào để xây dựng testcase hiệu quả, đảm bảo test đầy đủ trường hợp, đặc biệt là các mối liên kết, quan hệ xung quanh, ví dụ như liên kết API với payment gateway hay ERP chẳng hạn.

Theo quan sát, mình thấy khi làm phần mềm, các bạn khá tập trung vào kiến trúc hệ thống, API, Backend/ Front-end, microservices, kết cấu hạ tầng kỹ thuật nói chung. Diagram mình thấy các bạn cũng tập trung khá nhiều vào chi tiết đơn lẻ từng đối tượng, view không rộng như UCD. Điều này dẫn đến các bạn lại thiếu đi cái nhìn bao quát về sản phẩm đầu ra của các bạn ra sao, mô hình thế nào để xử lý trước mắt là việc đưa ra sản phẩm chất lượng, đồng thời tương lai phát triển, mở rộng ra sao.

𝐔𝐂𝐃 𝐥𝐚̀ 𝐦𝐨̣̂𝐭 𝐜𝐨̂𝐧𝐠 𝐜𝐮̣ đ𝐨̛𝐧 𝐠𝐢𝐚̉𝐧 𝐭𝐫𝐨𝐧𝐠 𝐡𝐞̣̂ 𝐭𝐡𝐨̂́𝐧𝐠 𝐔𝐌𝐋, 𝐧𝐡𝐮̛𝐧𝐠 𝐫𝐚̂́𝐭 𝐦𝐚̣𝐧𝐡. Hy vọng qua bài viết này, các bạn có 1 cái nhìn khác về UCD, cũng như tầm quan trọng của việc tổng quát hóa mô hình hệ thống.

Good luck to you all !

23/05/2025

#3 - Series viết tài liệu IT BA cùng Hai Lúa

Viết Biên bản cuộc họp (𝐌𝐎𝐌 - 𝐌𝐢𝐧𝐮𝐭𝐞𝐬 𝐨𝐟 𝐌𝐞𝐞𝐭𝐢𝐧𝐠 𝐡𝐚𝐲 𝐌𝐞𝐞𝐭𝐢𝐧𝐠 𝐦𝐢𝐧𝐮𝐭𝐞𝐬) luôn là thử thách của các bạn trẻ, và đôi khi là cả những bạn có kinh nghiệm nhiều năm.

Viết MOM là một task khá nhàm chán cũng như gây khó khăn cho những bạn trẻ vì không biết sẽ viết gì, ra sao.

Trong video này, chúng ta cùng nói tới về MOM là gì, như thế nào cũng như phương pháp trình bày MOM, phương pháp viết MOM trong cuộc họp sao cho hiệu quả.

Hy vọng có thể giúp cho các bạn nhìn task viết MOM là một cái gì đó đơn giản và dễ dàng hơn,
Good luck,