Subscribe now

Mình tưởng tượng quy trình này là một cái phễu. Mọi thứ mớ hỗn độn từ nhiều bên đổ về Product Owner thường "less clarity": business nói về outcome nhưng không nói rõ constraint, C-level nói về direction nhưng không nói rõ ưu tiên cụ thể, partner nói theo góc nhìn của họ, market research có nhiều insight nhưng chưa chắc đã actionable. Và từ PO, hi vọng output ra một thứ với enough clarity để team phát triển có thể cùng hiểu, làm, và cùng chịu trách nhiệm.

Nếu không > Design / Dev / QA hiểu một kiểu, design / build / test theo assumption của họ. Sản phẩm ra sai là PO ăn gõ.
Mình assume phần rất lớn công việc của PO thực ra là 'dịch'. Dịch từ business requirement thành logic hệ thống, từ idea mơ hồ thành requirement có thể build được, từ "mong muốn" thành "kỳ vọng rõ ràng". Rồi 'align và set kỳ vọng thực tế' đó với các bên trước khi bất cứ thứ gì được deliver.

Clarity không phải tự nhiên mà có. Nó là kết quả của việc chấp nhận hỏi đủ nhiều câu hỏi "ngu ngốc", không ngại đào sâu những chỗ còn mơ hồ (nhiều khi cũng sợ mn nghĩ thằng PO này hỏi ngố quá nhưng thôi kệ 😅)

Vẫn là những thứ khá "cơ bản" mình vẫn đang luyện tập thành thói quen:
+ Ghi rõ expected behavior: user bấm A thì chuyện gì xảy ra, có edge case không?
+ Viết lại alignment sau mỗi buổi discuss để mọi người có cùng một version of truth
+ Luôn hỏi 'Chỗ này mọi người đang hiểu giống nhau chưa?' để chắc mn đều on the same page.
+ Definition of Done ngay từ đầu... dù thành thật mà nói, cái này mình cũng chưa hẳn làm được full ngay từ đầu mỗi lần 😅

Nghe thì đơn giản: đảm bảo các câu hỏi quan trọng đều đã được trả lời đủ rõ --> làm thì tốn năng lượng thật sự. Bạn nào từng làm rồi chắc hiểu cảm giác đó. Clarity không sexy. Nhưng thiếu nó thì ai toang biết liền. Is that you bro?👇

Đặt 3 màn hình cạnh nhau: Bank, Ví hồng, Ví xanh.

My observation:

• Bank thì đơn giản đến mức lạ. Default sẵn số điện thoại của chính chủ, cũng không biết chọn đúng mạng chưa. Không default mệnh giá. Người dùng tự chọn. Done. Tiền nạp vào điện thoại. Không cashback, không upsell, không gợi ý thêm gì cả.

• Ví điện tử thì ngược lại. Cũng default sẵn số điện thoại của chính chủ, thể hiện thêm nhà mạng của số đth. Default mệnh giá cũng khác nhau. Người dùng tự chọn lại mệnh giá. Done. Cashback hiện ngay dưới mỗi mệnh giá. Gói data gợi ý kèm theo…

• Cùng một hành động “nạp tiền đth”, nhưng một bên thì tối giản đến mức trống, một bên thì tận dụng gần như mọi pixel trên màn hình.

Share

Tiếp tục là câu hỏi cũ xuất hiện trong đầu: một conscious choice?

• Bank bỏ qua khá nhiều “best practice”: không có incentive để user chọn mệnh giá cao hơn, không cross-sell. Nhưng nếu nhìn từ góc độ khác, có thể họ đang tối ưu cho một thứ khác: hoàn thành giao dịch nhanh nhất, ít suy nghĩ nhất.

• Còn ví điện tử thì rõ ràng đang chơi một game khác. Mỗi transaction không chỉ là một giao dịch, mà còn là cơ hội để tăng giá trị: cashback để kích thích chọn mệnh giá cao hơn, gợi ý data để cross-sell, auto top-up để tạo thói quen quay lại.

Tuy nhiên.. các khuyến mãi trên ví có thực sự khiến bạn nạp nhiều hơn không? Thành thật mà nói, khi mình nạp cho người khác trong nhà, thứ duy nhất mình quan tâm là: đúng số, đúng mệnh giá, nạp xong trong vài giây. Cashback hay gợi ý data hầu như mình không để ý. (ý kiến cá nhân)

UX (User Experience) vừa phục vụ User, nhưng đồng thời cũng phải đang phục vụ một mục tiêu khác (I assume). Mình không có dữ liệu để xem rằng chủ ý đó có hiệu quả hay không. Nhưng nếu một ngày data cho thấy user convert tốt hơn với màn hình đơn giản (giảm cognitive load cho user), liệu ví có dám bỏ bớt những thứ đó đi không? (Cũng bớt kha khá việc cho Product =)))

Không có đúng sai ở đây. Cùng một feature, nhưng mỗi bên đang chơi một game khác. Cuối tuần ngẫm 1 tí. Bạn thích UX nào.

How are you doing !!!! Lại 1 tuần nữa trôi qua thật nhanh và chúng ta đếm ngược còn 343 ngày nữa là tới Tết Đinh Mùi 2027, rơi vào Thứ 7-ngày 6/2/2027 (Dương lịch).

Subscribe now

Luân hồi_Sinh-Lão-Bệnh Tử

Đầu năm nói chuyện ‘mất mát’ chắc không hay. Nhưng nếu ‘mất mát’ đó đã khởi sinh ra động lực để người ở lại đạt được nhiều thành tựu thì sao.

• Người thứ nhất: Một người anh đồng nghiệp 8x ở công ty đầu tiên trong sự nghiệp của mình. Người anh luôn sẵn sàng chỉ dẫn, chia sẻ không tiếc lời từ hard skills đến soft skills cho thằng sinh viên vừa bước ra đường đời. Người anh chia sẻ ủng hộ bài viết đầu tiên của thằng em. Đến một ngày, 2 anh em ngồi uống trà tâm sự trước khi anh nghỉ phép và đó là lần cuối, anh ra đi và không bao giờ trở lại. Mình cũng không dự được đám tang của anh. Mình có tự hứa với lòng tri ân anh bằng cách cố gắng finish giải trail 42km ở Mộc Châu. Trong khi chạy mình cũng có nghĩ về anh để cố gắng về đích mặc dù có mệt mỏi tới đâu. Và mình làm được, sau khi về đích mình cầm huy chương ngẩng mặt lên trời và thầm nghĩ “This is for you bro”

• Người thứ 2: Một người rất thân ruột thịt. Một người đã chở mình đi khám, đi chích từng mũi tiêm chủng, một người đã chở mình đi học trong những năm đầu đời. Một người đã chỉ mình làm một người đàn ông có thể tự sửa chữa mọi thứ trong nhà từ điện, nước, đồ gia dụng, khoan, đục, sơn... everything. Một buổi sáng, mình đi ngang phòng. Người ấy giơ tay gọi mình vào. Mình vào nắm tay, xoa và bóp tay, hỏi thăm và đó là lần cuối...Mình tri ân ‘người rất thân’ bằng cách cố gắng, sẽ cố trong mọi việc cho tới hơi thở cuối cùng. Mỗi khi cảm thấy khó khăn muốn bỏ cuộc, mình sẽ ngẩng đầu lên trời, nhắm mắt, thở và nghĩ đến người ấy.

Gửi bạn lời bái hát “Hãy yêu tôi bây giờ” của HURRYKNG để luôn trân trọng người ở lại:
“Nếu có yêu tôi thì hãy yêu tôi bây giờ
Đừng đợi ngày mai đến lúc tôi qua đời
Đừng đợi ngày mai đến khi tôi thành mây khói
Cát bụi làm sao mà biết mỉm cười..
....
Nếu có bao dung
Thì hãy bao dung bây giờ (xin hãy thứ tha)
Đừng đợi ngày mai
Đến lúc tôi xa đời
Đừng đợi ngày mai biết đâu tôi nằm im hơi
Tôi chẳng làm sao
Tạ lỗi cùng người”

Random thought AI PM

Có người hỏi mình đang dùng AI như thế nào trong công việc thực tế. Thật ra không phức tạp, nhưng cũng không phải “dùng ChatGPT hỏi vài câu rồi thôi.”

Mình cũng đang cố gắng học hỏi để xây dựng một hệ thống riêng của bản thân trên nhiều best practice của mọi người. Trong đó

• Claude là nền tảng chính (Claude Project / Claude Code / Cowork / Subagent) liên kết đến các ứng dụng khác như Notion / Figma / … , mình dùng nó mỗi ngày cho mọi thứ từ phân tích, viết PRD, đến tự động hóa workflow PM.

• ChatGPT: xưa mình cũng xài tool này chính, nhưng từ khi xài Claude thì mình cancel GPT Pro rồi chuyển qua Claude Pro luôn. GPT giờ cho các tác vụ linh tinh khác như viết hoặc dùng để phản biện với Claude. Hoặc thỉnh thoảng cho những tác vụ Claude không chịu làm như coi thần số học, chiêm tinh =)))

• Antigravity: dành cho một số dự án vibe coding cá nhân (build để vừa chơi và học để hiểu AI đang đi đến đâu thôi chớ chưa có public cái nào hết). Xưa mình xài Cursor, nhưng lúc sau mình chuyển qua Antigravity vì cái tên của nó. Nghe lạ hen mà haha who knows, Antigravity được nhắc trong phim Interstellar (one of my favorite films also)

• NotebookLM khi cần nghiên cứu một số chủ đề, có trích dẫn rõ ràng,.. Mình chưa đào sâu sử dụng NotebookLM lắm. Nhưng theo nhiều video mình coi thì đây cũng là một công cụ siêu mạnh.

Một số tài liệu mình đọc và xem trong tuần này mà mình thấy hay để chia sẻ cho cả nhà (Mỗi tuần mình cũng sẽ cố gắng chia sẻ những tài liệu trong tuần mình đọc và học gì)

• Cách sử dụng Cowork. Cowork hơi bị xịn, khi nó làm việc trực tiếp với các nội dung file/folder trên máy của mình luôn

The Product Compass

Claude Cowork: The Ultimate Guide for PMs

Hey, Pawel here. Welcome to the free edition of The Product Compass - the #1 hands-on AI PM newsletter. Every week I share actionable articles, playbooks, and resources for PMs…

Read more

a month ago · 107 likes · 6 comments · Paweł Huryn

• Cách team Design của Notion áp dụng Claude Code. Trong bài này mình thấy có 2 lệnh cũng thú vị để học hỏi để thử áp dụng trong công việc Product

  • /create-prototype {name-of-directory} —> create prototype from directory

  • /figma {figma-url} —> Create a prototype from design

Lenny's Newsletter

🎙️ This week on How I AI: How Notion’s design team uses Claude Code to design

“I haven’t written a single line of front-end code in 3 months”: How Notion’s design team uses Claude Code to design…

Read more

a month ago · 280 likes · Lenny Rachitsky

Đại hội đổi việc trong năm mới - New year new job

Chắc hẳn sau tết, nhiều bạn cũng bắt đầu cân nhắc đến việc tìm kiếm một nơi thử thách mới. Mình cũng đã từng ở vị trí đó. Dưới đây là một số góc nhìn cá nhân mình muốn chia sẻ.

Mình hay liệt kê 3-5 điều quan trọng nhất với bản thân khi lựa chọn một cơ hội mới:

• Lương & phúc lợi

• Domain

• Cơ hội phát triển

• Văn hóa công ty

• Quản lý & phong cách lãnh đạo

• Ý nghĩa công việc

• Work-life balance

• …. cho bạn tự liệt kê các đầu tiêu chí khác

Với mỗi cơ hội, mình sẽ đánh giá từng tiêu chí rồi tính tổng điểm, xem cơ hội đó có đạt ngưỡng tối thiểu để mình cân nhắc nộp CV hay không. Quyết định đưa ra trên dữ liệu nên có niềm tin hơn là cảm nhận cảm tính. Tuỳ theo từng giai đoạn mà bạn sẽ ưu tiên yếu tố này hơn yếu tố kia. Và gần như chắc chắn sẽ luôn có sự đánh đổi.

Không có công ty nào là hoàn hảo. Mình đã thấy đủ kiểu công ty để biết rằng mỗi lựa chọn đều đi kèm cái giá của nó.

• Startup nhỏ, lương thấp nhưng học nhanh. Bạn vào đây và làm đủ thứ, đôi khi vượt ra ngoài cả mô tả công việc ban đầu. Không có budget training, không có quy trình rõ ràng. Nhưng sau 1 năm, bạn tích lũy được kinh nghiệm thực chiến mà nhiều người đi 3 năm ở môi trường khác chưa chắc có. Câu hỏi là: bạn có chịu được áp lực và mức lương đó trong giai đoạn đó không?

• Công ty lớn, lương tốt, nhưng scope hẹp. Title đẹp, process rõ ràng, lương ổn định. Nhưng bạn chỉ là một mắt xích nhỏ trong một guồng máy khổng lồ. Hai năm sau nhìn lại, bạn cảm thấy quá ổn định, phát triển quá chậm so với những gì bạn kỳ vọng. Và bạn thấy mình đang bị bỏ lại phía sau. Và thị trường cũng biết điều đó. (Mình từng ở trong hoàn cảnh này)

• Công ty đang tăng trưởng nóng. Exciting, nhiều cơ hội thăng tiến, leadership trẻ đầy tham vọng. Nhưng định hướng thay đổi liên tục, sếp của bạn cũng đang tìm đường cho chính họ. Work-life balance trở thành khái niệm xa xỉ mà ai cũng nhắc nhưng không ai thực sự có.

• Công ty “ổn định”. Không ai bị sa thải. Không ai bị thách thức. Bạn học được sự an toàn, nhưng vài năm sau thị trường nhìn vào CV và hỏi: “Bạn đã thực sự làm gì ở đây?. ..Buồn chán nhiều khi đến mức sinh bệnh

• Công ty brand name to nhưng lương thấp. Tên công ty trên CV đủ để người ta dừng lại đọc. Bạn học được cách làm việc chuyên nghiệp, tiếp xúc với những dự án tầm cỡ, và network của bạn mở rộng theo cách khó tìm được ở nơi khác. Sẽ có thể là một khởi đầu tốt cho nhiều bạn. Nhưng càng đi lâu, rồi cuối tháng nhìn vào tài khoản, bạn tự hỏi liệu "thương hiệu" đó có đủ để bù đắp cho những gì bạn đang hy sinh không

• ….

Không có đúng có sai…Quan trọng là bạn biết rõ ưu tiên của bản thân là gì, và chuẩn bị sẵn sàng tâm lý cho sự đánh đổi mà bạn có thể chấp nhận. Mình cũng đang ‘đánh đổi’ vì một tương lai tốt đẹp hơn (hi vọng, crossed finger) . Hi vọng mọi người cũng thế.

Peace out!!!

Thien Nguyen

Ngày Tết của cả nhà thế nào rồi. Mọi thứ vẫn ổn chứ.

Tết năm nay với mình...cũng gần giống như mọi năm, không có gì to lớn xảy ra. Có mấy khoảnh khắc nhỏ cứ đọng lại mãi không chịu đi mà mình muốn chia sẻ với mọi người dưới đây

1. Những ngày tết

26 tết

Ngày nghỉ Tết đầu tiên mình đi cafe, thoải mái ngồi trầm ngâm im lặng thẫn thờ nhìn trời, nhìn đất, nhìn mây, nhìn dòng người qua lại thật lâu mà không phải lo deadline dí. Cố gắng tìm được khoảng nghỉ ngơi trong ngày tết âm lịch để tự chữa lành sau những ngày tháng thật bộn bề (hi vọng bạn đọc tới đây, cũng đã có những khoảng nghỉ ngơi trong tết thật tuyệt vời). Đọc sách vào buổi sớm, đi quẩy vào buổi đêm, có thể bước ra phố bất kể lúc nào mình muốn

27 tết (Valentine 14/2)

Những ngày cận tết âm lịch là những ngày mình thích nhất, thích hơn cả những ngày sau khi tiếng pháo giao thừa nổ ra. Ngày đại hội lau chùi của quốc gia, ngày mọi người hối hả wrap up, mua sắm mọi thứ, ngày gặp gỡ…ngày [mời bạn điền vào chỗ trống]

Ngày Valentine là một ngày bình thường đẹp trời khi mình được ngủ đủ, sáng dậy sung sức, đi bộ ăn sáng thư thả rồi về dọn dẹp nhà. Chiều chạy 14.2km, giãn cơ.

28 tết

Ngày mình tổng clean up cho bản thân. Tắm rửa sạch sẽ, thay đồ đẹp, đi cắt tóc mát mẻ. Ra cafe một mình, ngồi máy tính bật nhạc Tây tạng không lời (nhạc có tần số rung cảm cao lắm, mình để link bên dưới cho bạn nào muốn nghe). Ngồi clean up đống mạng xã hội (xoá/ẩn hết bài viết trên Facebook, unfollow hết các trang linh tinh, xoá network đã lâu hoặc chắc chắn trong tương lai không contact trong friend list. Lặp lại với Instagram,....). Làm xong cái đống trên mà người nhẹ hẫng đi vài ký (kg).

29 tết

Mình để ý mọi năm cứ sau 12h trưa ngày 29 Tết (hoặc 30 Tết nếu có), chợ-đường xá đều bắt đầu vắng lặng. Mọi người trở về nhà, sắp xếp dọn dẹp lần cuối để đón giao thừa. Mặc dù mình đã trải qua cảm giác này rất nhiều lần nhưng lần nào nó cũng có chút thật bồi hồi.

Đến chiều 5h cảm thấy trống trải quá, mình có ý tưởng tại sao không làm một city tour quanh Saigon cũng như để hoàn thành cho xong cái challenge 20.26km mà các đồng run hay làm mỗi khi năm mới.

Nghĩ là làm, thay đồ mang giày khởi động gấp rút bay ra khỏi nhà ngay lập tức. Đồng hồ vừa điểm gần 5h30 chiều, dự kiến chạy 3 tiếng, đến 8h30 xong là vừa đẹp. Trộm vía là kế hoạch diễn ra tốt đẹp như dự kiến. Tiêu tốn hết 1 lon bia Strongbow (chạy giữa chừng tự nhiên hứng uống bia quá, quất luôn), 1 chai Pocari, 1 Revive chanh muối. Kịp giờ về giãn cơ, tắm rửa, thay đồ, soạn bàn cúng giao thừa.

Subscribe now

Mồng 1,2,3 tết Bính Ngọ

Đều đặn: Thắp nhang bàn thờ. Khai bút, ăn, ngủ, đọc sách, xem youtube, chạy ít nhất 6km, đi chùa.

Mồng 4

Learning something. Tranh thủ học xí để an tâm tối đi nhậu. Trong Podcast gần nhất của Lenny với Boris Cherny (Head of Claude Code). Mình có note một số ý mình thấy thú vị:

1. Thay vì để mọi thứ quá tự do thì constraint (giới hạn) giúp tạo ra sự sáng tạo.
Ví dụ của Boris đưa ra: Khi chỉ cho phép chỉ định 1 người vào giải quyết vấn đề thì buộc người đó phải tìm mọi cách dùng AI sao cho hiệu quả tối đa để thực thi được nhiệm vụ thay vì cần bổ sung nguồn lực vào vấn đề đó.

Đối với mình cũng thấy, việc có constraint như một boundary nhân tạo để biết mình có thể vùng vẫy tới đâu. Nếu không có ranh giới đó, sự tự do vô hạn lại trở thành gánh nặng. Bạn không biết bắt đầu từ đâu, không biết dừng lại ở đâu, và dễ bị mất phương hướng trong vô số lựa chọn. Constraint, ngược lại, thu hẹp không gian vấn đề lại, buộc bạn phải đào sâu thay vì trải rộng. Khi không thể thêm nguồn lực, bạn buộc phải sáng tạo hơn với những gì đang có.

Deadline gấp, budget ít, team nhỏ → những thứ tưởng như là rào cản lại thường là lý do tại sao một số sản phẩm ra đời gọn ghẽ và sắc bén hơn. Bạn không có đủ thời gian để làm mọi thứ, nên bạn buộc phải chọn điều quan trọng nhất. Bạn không có đủ người, nên bạn buộc phải tự động hóa, đơn giản hóa, hoặc cắt bỏ những gì không thực sự cần thiết.

2.Mission công ty vô cùng quan trọng đối với nhân viên. Boris từng chuyển qua Cursor. Tuy nhiên chỉ sau 2 tuần ở Cursor, Boris ngay lập tức quay lại Anthropic vì thiếu cảm giác mission như thời ở Anthropic (Điều mà thôi thúc Boris thức dậy và làm việc vào mỗi sáng, mặc dù công việc ở Cursor cũng thú vị không kém).

3.Cowork ra đời vì Boris thấy người dùng đang hack Claude Code để làm những việc như phân tích MRI, khôi phục ảnh cưới, trồng cà chua..

When you see people abusing the product in this way, using it in a way that it wasn’t designed in order to do something that is useful for them, it’s just such a strong indicator that you should just build a product.

Câu này khá inspire cho dân làm sản phẩm. Để cho các bạn reflect lại trong quá trình làm hoặc tiếp xúc với người dùng, xem có gì thấy cần build mới chưa

4.Boris sống ở một ngôi làng nhỏ ở Nhật Bản, là người nói tiếng Anh duy nhất, không có gì nhiều để làm ngoài đọc sci-fi và làm miso. Chính khoảng lặng đó, cùng với việc suy nghĩ theo “long time scales” như một mẻ miso đỏ ủ 3-4 năm, đã dẫn Boris đến Anthropic.

--> Boris nhận ra AI đang đi theo một hướng có thể rất tốt hoặc rất tệ cho nhân loại, và anh muốn góp phần định hướng vision cho đúng. Không hẳn vì nó thú vị, mà còn vì là cảm giác trách nhiệm của chính Boris.

Subscribe now

Mồng 5

Mình trở lại với núi Dinh vào một ngày nắng banh đầu.

• Đi “xả đồ” xả bánh chưng bánh tét xả bia xả rượu.

• Đi “tắm nắng” cho dư Vitamin D.

• Đi “nạp đường” nước mía và coca.

• Đi ngang chùa nhớ giữ “chánh niệm”.

Và đi này mệt hơn nè: Sắp đi làm trở lại.

2.Your network is your net worth

Năm 2025 là năm mình cảm nhận được sức nặng của câu nói:

Nhờ các mối quan hệ chất lượng mà mình may mắn có được, đã giúp mình rất nhiều trong khoảng thời gian thất việc.

• 1 network chuyên môn: Nhóm các Product / BA / Designer từ nhiều công ty khác nhau, cùng học hỏi lẫn nhau. Group này đã refer mình đến rất nhiều cơ hội làm việc khác nhau. Những buổi coffee để chia sẻ về những khó khăn trong công việc, về career path ... và giúp bớt cô đơn trong giai đoạn khó khăn

• 1 network về sức khỏe: Nhóm bạn có tinh thần sống khỏe, thể dục thể thao, cùng động viên nhau tập hằng ngày.

  • Cách động viên? Gây FOMO bằng số km / buổi tập cho nhau: "Hôm nay tao đã chạy 10km rồi / Tuần này tao đã tập 4 buổi rồi"

  • Những ngày mình không muốn ra khỏi giường, thấy bạn bè post story xong 1 buổi tập làm mình cũng phải... lết dậy đi tập. Và rồi mình nhận ra trong chuỗi ngày thất việc, những ngày tập đều đặn chính là những ngày mình vượt qua được stress tốt nhất.

Tạm kết

Một vài quote hay, mình gửi tặng bạn nhân những ngày đầu năm âm lịch Bính Ngọ 2026:

• “Do not pray for easy lives. Pray to be stronger men” - John Kennedy

• Sau cơn bĩ cực đến ngày thái lai

Chúc các bạn năm 2026 mã đáo thành công nhen. See you soon!!

Trân trọng,

Thien Nguyen.

.

Nếu ai làm Product theo mô hình Scrum chắc sẽ quen với những event lặp lại mỗi sprint: Sprint Planning để lên kế hoạch, Daily Standup để sync tiến độ, Sprint Review để demo sản phẩm, và Sprint Retrospective để nhìn lại.
.
Trong số đó, event Sprint Retro chưa chắc là mọi team sẽ làm. Mặc dù nó cho cả team cơ hội dừng lại, nhìn lại những gì vừa qua: Cái gì đã tốt? Cái gì chưa ổn? Sprint tới sẽ cải thiện thế nào?
Một nghi thức nhỏ, nhưng có sức mạnh lớn, giúp team không lặp lại sai lầm, và tiến về phía trước rõ ràng hơn.
.
Và cái hay của Sprint Retro là..nó không chỉ dừng lại ở công việc.
Cả năm vừa qua sprint retro của team có thể không làm nhưng sprint retro của bản thân thì nhất định phải làm nhá, một buổi ngồi lại chân thật với chính mình. Điểm qua những gì đã trải qua, học được gì để đóng những 'feedback loop' và chuẩn bị cho "sprint" tiếp theo của cuộc đời.

Subscribe now

[Personal]
Năm nay, mình cũng có những "sprint tốt". Những lúc deliver kế hoạch đúng hạn. Mặc dù có mệt nhưng mình vẫn cảm thấy đã làm được điều gì đó có ý nghĩa.
Tuy nhiên, cũng có những "sprint chưa tốt". Những lúc alignment với external stakeholder trật bánh khiến thất việc. Những lần phải quay đầu làm đi làm lại (phỏng vấn tới lui) hay đơn giản là vì mình nghĩ mình hiểu 'nghề' rồi... nhưng thực ra chưa.
.
Giống như Sprint Retro, điểm mấu chốt không phải là đếm xem mình pass bao nhiêu sprint, fail bao nhiêu sprint. Mà là: mình họ được gì từ đó. Năm nay, mình cũng có rất nhiều 'bài học / trải nghiệm / sự phát triển':
+ Những bài học cá nhân (thất bại) về tài chính chưa sẵn sàng chia sẻ public.
+ Hay là những bài học trong công việc nghề làm sản phẩm, mình đã được viết xuống và chia sẻ, để ai cũng có thể quay lại đọc khi cần.
+ Những bài học về sức khoẻ, về tình cảm, về cuộc sống, về AI, .... ôi nhiều lắm!! Học nữa, học mãi, học lắm...Life-long learning.

Quéo quèo..
+ What went well?
+ What didn't go well?
+ What will we improve?
Mỗi sprint mới, mình hi vọng bước vào với đầu óc sáng hơn một chút, với backlog rõ ràng hơn một chút, và với quyết tâm cải tiến..từng chút một.
.
That's all. A good quote for you: "Do not pray for easy lives. Pray to be stronger men" - John Kennedy
--> Chúc cho mỗi người đọc bài viết này đều là stronger 'Product Owner', own 'sản phẩm bản thân' mình thật vững vàng để có những Sprint Retrospective trong năm và cuối năm sau thật tuyệt vời. Peace out and Happy Lunar new year my fren!!

.
Product phải là người chủ động xung phong làm việc đó.
+ Viết lại alignment sau mỗi buổi trao đổi.
+ Viết rõ logic vì sao chọn hướng này mà không chọn hướng kia.
+ Viết meeting minutes, tổng hợp lại những gì đã thống nhất, ai làm gì, khi nào xong
--> Không phải để “giành việc", mà là phải chủ động để giảm hiểu lầm, giảm tranh cãi về sau và giúp cả team đi nhanh hơn.
.
Mình để ý, rất nhiều vấn đề trong công việc không đến từ việc mọi người không giỏi, mà đến từ việc mỗi người đang hiểu..hơi khác nhau một chút. Và Product là người đứng ở giữa, nên nếu không viết (hoặc mô hình hoá), không chốt lại, thì khoảng trống đó sẽ tự động được lấp bằng giả định của từng người.

Subscribe now

.
Well, không chỉ trong công việc. Ngoài đời, việc viết xuống bằng written form đôi khi còn cứu được kha khá tình huống khác mà mình không ngờ tới. Ghi lại một ý nghĩ chợt đến để khỏi quên. Ghi lại một quyết định đã từng đưa ra để sau này không tự nghi ngờ chính mình. Hay đơn giản là có cái để search lại trong cuộc trò chuyện, thay vì phải ngồi cãi nhau xem lúc đó ai nói gì, nói khi nào.
.
Có những thứ nếu chỉ để trong đầu thì rất dễ trôi. Nhưng một khi đã được viết xuống, nó trở thành một dạng “external memory” không hoàn hảo, nhưng đủ tin cậy để mình bớt phụ thuộc vào trí nhớ vốn rất hay phản bội.
.
Mình nhận ra càng lớn, càng nhiều thứ phải xử lý, thì viết không còn là thói quen cho người thích chữ nghĩa nữa, mà là một cách tự cứu mình khỏi quên, khỏi hiểu sai, và khỏi những hiểu lầm không đáng có. Và bài viết này là một trong các lý do đó 'Viết để lưu trữ những trải nghiệm / bài học tôi đang học cho tôi và cho cả bạn'. Peace out!!

.
Làm Product, mình mới nhận ra chữ Owner không phải là chức danh cho vui. Nó không chỉ là người viết PRD, không chỉ là người kéo backlog, cũng không chỉ là người đứng giữa điều phối các bên.
Owner nghĩa là: sản phẩm đó có chuyện gì, người ta sẽ quay sang nhìn bạn đầu tiên, mỗi khi ai đó nhắc tới sản phẩm hay tính năng này, cái tên họ nhớ tới… là bạn. Và bạn phải có thể bật tanh tách tanh tách mỗi khi:
+ Hỏi logic? Bạn phải trả lời được.
+ Hỏi vì sao team chọn giải pháp A thay vì B. Bạn phải giải thích được.
+ Hỏi trade-off, phần nào là constraint kỹ thuật, phần nào là compromise vì business? Bạn phải biết.
+ Hỏi rủi ro, phần nào là chấp nhận chưa tối ưu để đi tiếp? Bạn phải đã nghĩ tới rồi.
.
Bạn hiểu nó từ trong ra ngoài. Maybe bạn 'cần' biết hết mọi thứ vì bạn là người chịu trách nhiệm kết nối tất cả mọi thứ lại với nhau. Áp lực x3000.

Subscribe now

Big boss bồi thêm một câu mà mình thấy rất thật:
“Owner không phải là người làm hết, mà là người không được phép nói ‘cái này không phải của em’.”
Nghe xong là thấy..nặng vai liền.
Nhưng cũng từ đó, mình hiểu ra một thứ: làm Owner đúng nghĩa không chỉ là áp lực, mà còn là một dạng đặc quyền.. Đặc quyền được tham gia vào những quyết định khó. Và đặc quyền được học rất nhanh, vì bạn không có đường lùi.
.
Có những lúc, mình cũng mệt vỡi. Mệt vì phải nhớ quá nhiều thứ. Mệt vì bị hỏi dồn dập. Mệt vì có những thứ không nằm trong tay mình nhưng vẫn phải đứng ra giải thích.
Nhưng cũng chính những lúc đó, mình thấy mình lớn lên rất nhanh trong nghề.
.
Làm Product Owner, suy cho cùng, là chấp nhận một vai rất rõ: thành công thì chia đều, thất bại thì đứng mũi chịu sào. Áp lực thì luôn có. Nhưng nếu làm được, nó rất truyền cảm hứng.
Vì khi bạn thật sự own một sản phẩm, bạn không chỉ build feature, bạn build luôn uy tín nghề nghiệp của chính mình.
.
Viết để lưu trữ những trải nghiệm / bài học tôi đang học cho tôi và cho cả bạn

Gần đây, mình có dịp gặp vài người cực kỳ giỏi trong việc quản lý stakeholder, tạm gọi là Big boss. Một câu nói của họ làm mình nhớ hoài: stakeholder management là phần vừa thú vị, vừa thử thách của Product.

.
THỬ THÁCH: Mệt vì phải nói nhiều. Mệt vì phải thương thảo. Mệt vì phải đặt mình vào vị trí của người khác để lựa lời mà nói. Không phải ai cũng nói cùng một ngôn ngữ. Engineer nói bằng logic hệ thống, edge case và constraint kỹ thuật. Business nói bằng doanh thu, timeline. Ops nói bằng quy trình, khả năng vận hành. Leadership nói bằng bức tranh lớn và trade-off. Còn Product thì đứng giữa, nghe hết, (cố gắng) hiểu hết, rồi phải “dịch” lại sao cho mỗi bên đều thấy mình được lắng nghe.
.
Có những lúc, cùng một vấn đề, mình phải nói ra thành ba bốn phiên bản khác nhau. Không phải vì mình thích vòng vo, mà vì nếu nói sai ngữ cảnh, lệch ngôn ngữ một chút thôi là coi như trật sóng. Và trật sóng trong Product thì cái giá phải trả thường là thời gian, bị bác bỏ ý kiến, niềm tin, ..vv..
.
Nhưng cũng chính vì vậy mà nó lại THÚ VỊ. Làm Product buộc mình phải học rộng, để nói chuyện được với người khác. Mình bắt đầu hiểu vì sao Dev khó chịu khi requirement mơ hồ, vì sao Business sốt ruột khi product đi chậm, vì sao Ops sợ những thứ nghe thì hay nhưng đưa vào vận hành là toang. Dần dần, mình xây được một kỹ năng rất đặc biệt: kết nối những mảnh ghép rời rạc lại với nhau, bằng ngôn ngữ mà mỗi bên có thể hiểu.
.
Và cái hay là, khi đã quen rồi, bị “thả” đi đâu bên ngoài công việc, mình cũng không quá sợ. Gặp người ngành nào, vai trò nào, bạn cũng có thể bắt chuyện, hỏi đúng câu hỏi, và tìm được điểm chung để tiếp tục làm việc. Với một người hướng nội như mình, đó là một sự thay đổi không nhỏ.
.
Làm Product, suy cho cùng, là chấp nhận đứng ở giữa. Cũng siêu mệt mệt đó nhưng có đáng ???? --> Your turn 👇

Subscribe now

Đầu năm mới, cả nhà có thảnh thơi chưa? Chớ mình vẫn còn còn bộn bề nhiều thứ quá, nhưng mình vẫn quyết định sẽ dành viết cho cả nhà một tí.

Subscribe now

Năm còn là sinh viên mài mông trên ghế nhà trường thay vì ghế công ty hiện tại, mình cũng có may mắn đạt được vài học bổng. Các học bổng mình đạt được đa số đều có ít nhất 1 vòng phỏng vấn trong đó (còn mấy học bổng đạt được vì điểm cao thì mình thường rớt hết vì điểm của mình thấp lắm, không cạnh tranh được với chúng bạn cùng khối)

Do đó đối với mình, mỗi lần phỏng vấn học bổng, mình đều gom nhặt được ít nhất một câu chuyện hay bài học ở sau đấy. Trong đó, lần phỏng vấn học bổng công ty Cargill của mình vẫn đọng lại 1 bài học kim chỉ nam, một bài học mà mình nhắc nhẹ bản thân mỗi năm mới.

Bác Mười-giám đốc nhà máy (chắc bác giờ cũng chả nhớ mình là ai đâu) người phỏng vấn học bổng năm đấy có hỏi mình 1 câu: “3 sự ưu tiên hiện tại của mình là gì". --> mình cũng không nhớ là mình thật sự đã trả lời gì (maybe tiền, luận văn,...). Sau đó, bác Mười đưa ra ý kiến góc nhìn của bác về 2 khía cạnh quan trọng nhất của bác bên cạnh công việc (nghĩ lại lúc ấy mình trả lời còn ngây thơ, ngô nghê quá)

Straight to the point: 2 khía cạnh đó chính là SỨC KHOẺ và GIA ĐÌNH.

Cá nhân mình, sau nhiều năm tới hiện tại, cũng đã trải nghiệm thất 'việc', có việc và làm việc, mình nhận ra đúng là 2 khía cạnh đấy, mình sẽ luôn đặt sự ưu tiên nhất khi viết xuống làm target cho mỗi năm
+ SỨC KHOẺ: một nền tảng physical health tốt để sống làm mọi thứ khác
+ GIA ĐÌNH: một nền tảng điểm tựa mental vững chãi để có động lực làm mọi thứ khác (người thân yêu còn khoẻ mạnh và sống bên cạnh).

Còn 2 thứ này là còn tất, mất 2 thứ này là mất hết. Vậy thôi. Còn lại tất cả là hữu duyên lúc còn lúc mất, lúc lên lúc xuống: công việc, mối quan hệ, tiền tài, danh vọng,....everything.

Bài viết đầu năm không liên quan đến ngành nghề hay chuyên môn. Chỉ muốn trở lại những điều cơ bản nhất của một con người. Happy new year and chúc mọi người nhận nhiều 'học bổng tài năng' trong năm nay. Peace out !

Subscribe now

Có một chi tiết UX nhỏ trong ví điện tử này làm mình phải dừng lại suy nghĩ: Đây là một thiết kế chưa "đúng, hay là một quyết định product có chủ đích phía sau?

Theo nguyên lý UX cơ bản, button fill đậm + nằm bên phải thường là hành động được khuyến khích (primary action)

Nhưng khi nhìn vào màn Kết quả giao dịch thì thấy hơi lạ:

• Với màn hình số 1: Nạp tiền vào ví (inflow) → primary action lại là Màn hình chính

• Với màn hình số 2: Rút tiền về ngân hàng (outflow) → primary action lại là Tạo giao dịch

UI thì mình không có ý kiến. Nhưng nếu đặt trong bối cảnh sản phẩm ví điện tử, câu hỏi bắt đầu xuất hiện.

Một ví điện tử thông thường sẽ muốn:

• Giữ tiền ở lại trong hệ sinh thái

• Khuyến khích inflow nhiều hơn outflow

Vậy tại sao ở luồng rút tiền, hệ thống lại “đẩy” người dùng tiếp tục hành động mạnh mẽ hơn? Đây là một UX oversight? Hay là một chủ đích product nào đó mà mình chưa nhìn ra, một vài assumption vu vơ

• Giảm friction cho outflow để tránh khiếu nại?

• Đáp ứng yêu cầu compliance?

• Hay data cho thấy user sau khi rút vẫn có xu hướng quay lại nạp?

Mình không có câu trả lời chắc chắn. Nhưng chi tiết nhỏ này nhắc mình rằng: UX không bao giờ đứng một mình. Mỗi button được highlight đều đang “nói hộ” một quyết định product phía sau.

Nếu anh chị em có insight cho chỗ này, mình rất muốn nghe thêm. Vì mình thấy nó cấn cấn, ngược ngược thế nào ấy.

“Khi xu hướng vibe coding bùng nổ, ai cũng có thể tự tạo ra sản phẩm web hoặc mobile, bất kể có nền tảng kỹ thuật hay không. Nhưng chính vì rào cản công nghệ giảm xuống, vấn đề bảo mật lại càng trở nên quan trọng.

Đặc biệt, nhóm non-tech thường ưu tiên tốc độ ra sản phẩm, mà chưa chú trọng đến các rủi ro bảo mật nền tảng. Điều này khiến ứng dụng dù trông đẹp và chạy được, nhưng lại tiềm ẩn nhiều lỗ hổng nghiêm trọng từ dữ liệu người dùng bị lộ, cho đến nguy cơ bị chiếm quyền hoặc gian lận giao dịch”

Keyword “Vấn đề bảo mật” trong đoạn văn trên chỉ là dẫn đề cho bài viết liên quan đến một domain mới trong career path mà mình có may mắn được trải nghiệm - Cybersecurity (chi tiết hơn Cybersecurity B2B trong BFSI-Banking, Financial Service, and Insurance, gọi là cũng có tí liên quan domain Fintech trước đó)

Một domain khá là nặng về tech, có rất nhiều thuật ngữ mới. Trải nghiệm này khá giống với trước đó (khi mới chuyển ngành từ Engineer sang Product hay chi tiết từ domain ERP sang Fintech) cũng cơ số thuật ngữ mới làm mình gặp nhiều khó khăn trong công việc khi trao đổi với team engineer internal và external. Nhưng vui vì có nhiều thứ để học

Nói thêm, domain mới - technical stakeholders của mình được mở rộng thêm nên thuật ngữ được nghe cũng nhiều cái lạ hơn:

• Fintech

  • Tech lead / FrontEnd Dev / Backend Dev / QA / DevOps (internal)

  • Tech lead / Backend Dev / QA (đối tác bank)

  • …

• Cybersecurity

  • Tech lead / Security Engineer (internal)

  • Tech lead / Backend Dev / Application Dev (đối tác BFSI)

  • Security Engineer / DevSecOps (đối tác BFSI)

  • Solution Architect (đối tác BFSI)

  • SRE / DevOps (đối tác BFSI)

  • Infra / Cloud Engineer (đối tác BFSI)

  • Compliance & Risk (đối tác BFSI)

  • …

Lần này mình cũng áp dụng cùng công thức, cố gắng “đắm chìm” nhất có thể để có thể hiểu hết tất cả các khái niệm, thuật ngữ mà đội ngũ tech đang trao đổi với nhau. Một số thuật ngữ đã nghe khi làm Fintech thì lần này được hiểu sâu hơn, một số thuật ngữ thì “chân trời mới lạ”. Và như mọi lần, sau khi tìm hiểu, mình phải viết xuống các ghi chú / trải nghiệm cá nhân do mình tích cốp được trong quá trình này để lưu trữ kiến thức liền (cũng như sharing cho mọi người), kẻo kiến thức nó trôi đi nhanh lắm, quên ngay.

Disclaimer:
+ Mình xin phép tạm gọi bài viết dưới là Cybersecurity 101.
+ Mình sẽ sử dụng xen lẫn giữa tiếng Anh và tiếng Việt vì nhiều từ để bản tiếng Anh gốc sẽ dễ hiểu hơn và mình cũng không biết dịch ra sát nghĩa thế nào cho chuẩn. Mọi người hỏi thêm chatGPT nha.
+ Nếu trong bài viết có điều chi chưa chính xác, nhờ mọi người góp ý để mình sửa và học hỏi thêm nhé. Thanks! 

Cybersecurity 101

A.Những mindset mới

1. Focus hơn vào Client - 2 - Server

Khi mình còn làm Fintech (ví trả sau), đa số mình làm nhiều với mô hình Server-2-Server qua API (tích hợp hệ thống - hệ thống), còn domain mới này sẽ cần mở rộng thêm phía Client-2-Server

Server-2-Server: an toàn vì có các phương thức xác thực giữa 2 hệ thống. Nên khó bị tấn công, giả mạo

Client-2-Server: kém an toàn hơn khi dễ bị tấn công bằng nhiều phương pháp khác nhau như MITM (Man-in-the-Middle), Proxy…

Khi đi sâu hơn vào mobile security (Client-2-Server). Có một giả định quan trọng mà hầu hết các giải pháp nghiêm túc đều phải chấp nhận: kẻ tấn công có thể kiểm soát hoàn toàn thiết bị phía client. Thiết bị đó có thể đã bị root hoặc jailbreak, đang chạy trên emulator, bị bật USB debugging, developer mode, thậm chí sử dụng custom ROM hoặc môi trường ảo như Parallel Space, Dual Space, Virtual App…

Một trong những rủi ro lớn nhất ở client-side là kỹ thuật dịch ngược (reverse engineering). Khi hacker decompile được app và có thể:

• Hiểu logic nghiệp vụ

• Tìm API endpoint, secret key

• Viết script brute-force, automation hoặc replay request

→ Đây là lý do Whitebox Cryptography xuất hiện như một lớp bảo vệ sâu. Khác với mã hóa truyền thống (vốn giả định môi trường tin cậy), whitebox được thiết kế để hoạt động trong môi trường không tin cậy, ngay cả khi hacker kiểm soát thiết bị. Whitebox Cryptography thường đi kèm với:

• Obfuscation (xáo trộn mã nguồn)

• Mã hóa string, constant

• Anti-tampering (phát hiện app bị resign, debug, hook)

Mục tiêu không phải là “không ai phá được”, mà là khiến việc phá không còn hiệu quả về mặt chi phí và thời gian. Không chỉ phân tích tĩnh, hacker còn dùng hooking, debug, dynamic instrumentation để can thiệp trực tiếp khi app đang chạy (debug, USB debugging, developer mode, hooking, injection, thiết bị đang chạy proxy hệ thống, screen mirroring, virtual display)

Nếu mà các ứng dụng mobile (client-2-server) mà có luồng eKYC (Xác thực danh tính người dùng), rủi ro không chỉ là bypass logic, mà là giả mạo con người để mở tài khoản ảo, reset mật khẩu, thực hiện giao dịch tài chính. Hacker có thể thực hiện qua:

• Dùng ảnh có sẵn, video deepfake, virtual camera

• Stream khuôn mặt qua video call hoặc screen sharing

• Gọi API trực tiếp để bỏ qua app

Nói chung, nhìn tổng thể, khi lượng người dùng sử dụng các ứng dụng BFSI ngày càng nhiều, đặc biệt trên Android, thì xác suất người dùng rơi vào một môi trường “không còn sạch” là rất cao.

Không phải vì người dùng cố tình làm sai, mà vì:

• Android là hệ sinh thái mở

• Người dùng dễ root máy, cài app ngoài store, bật developer mode mà không ý thức rủi ro

• Điện thoại cũ, không được update OS

• Thiết bị bị nhiễm malware từ app thứ ba

• Dùng song song nhiều app clone / virtual app để “tiện việc cá nhân”

Và từ góc nhìn của hệ thống, chỉ cần một tỷ lệ rất nhỏ thiết bị bị kiểm soát, là đã đủ để tạo ra rủi ro lớn ở quy mô toàn hệ thống: gian lận tài khoản, lạm dụng ưu đãi, chiếm đoạt tài sản, hay thậm chí là làm suy giảm niềm tin vào nền tảng. Client-side security không phải để bảo vệ app, mà để bảo vệ con người phía sau app đó (vì với các luồng nhạy cảm như eKYC, reset credential hay giao dịch tài chính, chỉ cần một lỗ hổng nhỏ ở client-side, thì thứ bị đánh cắp không còn là “logic kỹ thuật”, mà là niềm tin của người dùng vào hệ thống)

2. Mô hình CIA triad (Confidentiality-Integrity-Availability)

Lần đầu tiên nghe đến khái niệm CIA triad này, tưởng là cảnh sát CIA hay thấy trên phim. Tuy nhiên, mô hình CIA triad được xây dựng để giải quyết những vấn đề cốt lõi nhất của an ninh mạng: bảo mật dữ liệu, quyền riêng tư và tuân thủ pháp luật. Ở tầng ý nghĩa sâu hơn, cybersecurity không chỉ nhằm bảo vệ hệ thống hay hạ tầng kỹ thuật, mà là bảo vệ con người phía sau dữ liệu đó.

• Confidentiality nhấn mạnh rằng chỉ những người được ủy quyền mới có quyền truy cập vào dữ liệu và tài sản cụ thể (như dữ liệu cá nhân)

• Privacy protection, với trọng tâm là bảo vệ thông tin cá nhân khỏi việc sử dụng trái phép. Các loại dữ liệu như PII (personally identifiable information) hay SPII (sensitive personal information) nếu bị lộ không chỉ là sự cố kỹ thuật, mà có thể gây ra những hậu quả nghiêm trọng cho người dùng, từ mất an toàn cá nhân đến thiệt hại tài chính → Thật ra ở VN mình cũng lộ quá trời mà, bị gọi điện thoại tín dụng hay mời chào chứng khoán, bất động sản đấy.

• Law yếu tố đặt ra ranh giới rõ ràng cho mọi hành động trong không gian số. Với vai trò là người làm cybersecurity, tuân thủ pháp luật không phải là một lựa chọn mang tính tình huống, mà là nghĩa vụ bắt buộc.

Nhìn từ góc độ Product, đây là một lời nhắc nhở rất rõ ràng xây dựng những sản phẩm xử lý dữ liệu người dùng không chỉ là bài toán kỹ thuật hay tuân thủ quy định, mà là một cam kết dài hạn về niềm tin giữa sản phẩm và người dùng (nếu dữ liệu người dùng bị lọt ra ngoài)

B.Những khái niệm mới

Thuật ngữ mới trong Cybersecurity nhiều như lá mùa thu. Mình tích góp trong quá trình làm việc, khi đọc tài liệu, khi ngồi nghe các anh tech trao đổi, khi học khoá học online về cybersecurity,…lụm được gì lụm:

1.Phishing (lừa đảo)

Là việc sử dụng các phương tiện truyền thông thông thuộc số để lừa mọi người tiết lộ dữ liệu nhạy cảm hoặc triển khai phần mềm độc hại gì đấy

• Business Email (Cái này hay được mấy anh ANBM (An ninh bảo mật) trong công ty thử lòng mình lắm nà): Đại khái hacker gửi một tin nhắn email có vẻ như đến từ một nguồn đã biết để đưa ra một yêu cầu nào đó

• Spear phishing: tấn công email độc hại nhắm vào 1 nhóm người dùng

  • Whaling: Một dạng của spear phishing, nhưng nhắm vào các vị trí cao như giám đốc điều hành công ty

• Vishing: khai thác thông tin liên lạc bằng giọng nói điện tử để thu thập thông tin nhạy cảm

• Smishing: sử dụng tin nhắn văn bản để lừa người dùng

2.Malware

Là phần mềm được thiết kế để gây hại cho các thiết bị hoặc mạng. Mục đích đa số là xấu như lấy thông tin, tống tiền. Có nhiều loại malware (giờ mình mới phân biệt là nó khác nhau như nào)

• Viruses: Mã độc hại can thiệp vào hoạt động của máy tính và gây thiệt hại cho dữ liệu và phần mềm.

  • Virus cần được khởi động bởi hacker, truyền virus qua một tệp đính kèm độc hại hoặc tải xuống tệp.

  • Khi ai đó mở tệp đính kèm độc hại hoặc tải xuống, virus sẽ ẩn mình trong các tệp khác trong hệ thống hiện đã bị nhiễm.

  • Khi các tệp bị nhiễm được mở, nó cho phép virus chèn mã riêng của nó để làm hỏng và/hoặc phá hủy dữ liệu trong hệ thống.

• Worms: Malware có thể tự nhân bản và tự lan truyền qua các hệ thống. Trái ngược với virus, worm không cần được tải xuống bởi người dùng. Thay vào đó, nó tự sao chép và lan truyền từ một máy tính đã bị nhiễm sang các thiết bị khác trên cùng một mạng.

• Ransomware: hacker mã hóa dữ liệu của một tổ chức và tống tiền để khôi phục quyền truy cập vào dữ liệu đó

• Spyware: Malware được sử dụng để thu thập và bán thông tin mà không có sự đồng ý. hacker thu thập dữ liệu cá nhân, chẳng hạn như email riêng tư, tin nhắn văn bản, bản ghi âm giọng nói và hình ảnh, và vị trí.

3.Social engineering

Là một kỹ thuật thao túng cực kỳ hiệu quả, khai thác sự thiếu cảnh giác của con người để có được thông tin cá nhân, quyền truy cập, hoặc các thứ có giá trị. Nhìn vào các lý do khiến social engineering trở nên hiệu quả, có thể thấy hacker dẫn dắt hành vi người dùng cực kỳ bài bản. Hacker hiểu mental model của người dùng rất rõ, thậm chí rõ hơn nhiều đội Product.

• Social media phishing: Hacker thu thập thông tin (digital footprint) của người dùng từ các trang mạng xã hội. Sau đó sẽ tìm cách tấn công dựa trên các thông tin đó.

• USB baiting: hacker chiến lược để lại một USB malware cho một nhân viên tìm thấy và cài đặt, để vô tình làm nhiễm một mạng.

• Physical social engineering: hacker mạo danh 1 người nào đó như nhân viên, khách hàng, hoặc nhà cung cấp để có được quyền truy cập trái phép vào đâu đó.

Ví dụ vài cách Hacker hiểu mental model

> Con người hiểu nỗi sợ hãi và áp lực tâm lý. Khi bị đe dọa, thúc ép hoặc tạo cảm giác “nếu không làm ngay sẽ có hậu quả”, người dùng dễ bỏ qua các bước kiểm tra logic vốn dĩ họ vẫn làm trong trạng thái bình thường.

> Con người còn có xu hướng tin vào bằng chứng xã hội. Khi nghe rằng “những người khác đã làm rồi”, “cả phòng ban đều đã cung cấp thông tin”, người dùng sẽ mặc định đó là hành vi an toàn và hợp lệ. Hacker tận dụng chính cơ chế này để hợp thức hóa yêu cầu của mình.

> Yếu tố khan hiếm và khẩn cấp tiếp tục đẩy người dùng vào trạng thái ra quyết định nhanh. Khi cơ hội có vẻ sắp biến mất, hoặc thời gian bị giới hạn, não bộ ưu tiên hành động hơn là phân tích. Đây là lúc lý trí thường thua cảm xúc....

4.Cái loại tấn công khác

• Password attack: hành vi cố gắng truy cập trái phép vào các thiết bị, hệ thống, mạng hoặc dữ liệu được bảo vệ bằng mật khẩu.

  • Brute force: thử tất cả các khả năng mật khẩu cho đến khi tìm ra mật khẩu đúng

  • Rainbow table: sử dụng các bảng băm được tính toán sẵn để dò ngược mật khẩu

• Physical attack: tác động trực tiếp đến môi trường thật, nơi hệ thống được triển khai như:

  • Cáp USB chứa mã độc

  • USB / ổ flash chứa mã độc

  • Sao chép thẻ và đánh cắp dữ liệu thẻ

• Supply-chain attack: tấn công nhắm vào các hệ thống, ứng dụng, phần cứng và/hoặc phần mềm để tìm ra điểm yếu nơi mã độc có thể được cài cắm. Do hầu hết các sản phẩm đều phải trải qua nhiều 3rd party trong quá trình phát triển. Càng nhiều layer thì càng dễ có lỗ hổng bảo mật có thể xuất hiện

• …

5. Hacker (người tấn công)

Nãy giờ mình dùng khá nhiều từ “hacker”, nghe thì có vẻ như đang gom tất cả vào một nhóm “kẻ tấn công”. Nhưng thực tế, hacker không phải lúc nào cũng là người xấu, và cũng không phải ai có kỹ năng hack đều có cùng động cơ.

Trong cybersecurity, “hacker” chỉ đơn giản là những người có khả năng hiểu sâu và thao tác được với hệ thống, từ mạng, ứng dụng cho đến dữ liệu. Điều tạo ra sự khác biệt không nằm ở kỹ năng, mà nằm ở mục đích và giới hạn họ tự đặt ra.

• Có những hacker được tổ chức thuê hoặc làm việc nội bộ (internal) để tìm ra lỗ hổng trước khi kẻ xấu kịp phát hiện. Những hoạt động này thường được gọi là penetration testing (pentest) mô phỏng các kịch bản tấn công có kiểm soát nhằm đánh giá mức độ an toàn của hệ thống.

• Các hacker tham gia vào những hoạt động này tuân thủ pháp luật và chuẩn mực đạo đức, thường được gọi là white hat hacker hoặc ethical hacker.

• Trong nhiều tổ chức, hoạt động này được tổ chức thành hai vai trò rõ ràng: Red team và Blue team.

  • Red team đóng vai trò như kẻ tấn công, liên tục tìm cách khai thác điểm yếu trong hệ thống, quy trình và thậm chí cả con người.

  • Ngược lại, Blue team là đội phòng thủ, chịu trách nhiệm giám sát, phát hiện và phản ứng trước các hành vi bất thường. Việc để hai đội này “đối đầu” nhau trong phạm vi kiểm soát giúp tổ chức hiểu rõ hơn hệ thống của mình đang yếu ở đâu, và cần cải thiện điều gì.

• Bên cạnh đó là các security researcher: những người nghiên cứu bảo mật, chủ động phát hiện vấn đề chỉ để cảnh báo và cải thiện an toàn hệ thống, chứ không khai thác lỗ hổng để trục lợi.

• Có những hacker sẵn sàng vượt qua mọi ranh giới để trục lợi, phá hoại hoặc đánh cắp dữ liệu. Nhưng cũng có những hacker không đứng hẳn về một phía nào. Họ làm việc theo hợp đồng, có thể là hợp pháp hoặc phi pháp, tùy vào người thuê và bối cảnh.

Vì vậy, trong phần còn lại của bài viết, khi mình nhắc đến hacker, mọi người có thể hiểu đó là một tập hợp rất đa dạng các vai trò và động cơ, chứ không đơn thuần là “kẻ tấn công” như cách chúng ta thường nghe trên báo chí. Hiểu đúng điều này cũng là bước đầu để hiểu vì sao cybersecurity không chỉ là câu chuyện công nghệ, mà là câu chuyện về con người, động cơ và niềm tin.

6.Hiểu đúng Threat, Risk, Vulnerability

Trong cybersecurity, việc nói đến “rủi ro” sẽ rất mơ hồ nếu không phân biệt rõ ba khái niệm nền tảng: threat (mối đe dọa), risk (rủi ro) và vulnerability (lỗ hổng).

• Threat (mối đe dọa) là bất kỳ sự kiện, hoàn cảnh hay tác nhân nào có khả năng gây tác động tiêu cực đến tài sản của tổ chức. Hiểu rõ các loại threat phổ biến là điều bắt buộc, bởi threat chính là nguồn gốc của rủi ro.

  • Insider threats: nhân viên, đối tác hoặc vendor lạm dụng quyền truy cập hợp pháp để thu thập hoặc làm rò rỉ dữ liệu, gây tổn hại cho tổ chức

  • Advanced Persistent Threats (APT): các tác nhân đe dọa có chủ đích và trình độ cao, duy trì quyền truy cập trái phép trong hệ thống suốt thời gian dài mà không bị phát hiện

  • Tuy nhiên, sự tồn tại của threat chưa đồng nghĩa với rủi ro ngay lập tức. Rủi ro chỉ xuất hiện khi mối đe dọa đó có khả năng ảnh hưởng đến tài sản cụ thể.

• Risk (rủi ro) là khả năng một mối đe dọa có thể làm tổn hại đến CIA triad (confidentiality, integrity hoặc availability) của một “tài sản”. Nói cách khác, rủi ro không đơn thuần là “có bị tấn công hay không”, mà là xác suất xảy ra và mức độ thiệt hại nếu điều đó xảy ra. Một cách hình dung dễ hiểu: đi trễ giờ làm là rủi ro (risk), còn kẹt xe, tai nạn là các mối đe dọa (threat) dẫn đến rủi ro đó. Các loại rủi ro:

  • External risk: các mối đe dọa từ bên ngoài, như hacker tìm cách truy cập dữ liệu

  • Internal risk: rủi ro đến từ nhân sự nội bộ

  • Legacy systems: các hệ thống cũ không còn được cập nhật nhưng vẫn kết nối và ảnh hưởng đến tài sản

  • Multiparty risk: rủi ro phát sinh khi chia sẻ dữ liệu hoặc hệ thống với bên thứ ba

  • Software compliance và licensing: phần mềm không được cập nhật, vá lỗi chậm

• Vulnerability (lỗ hổng) Yếu tố còn lại giúp threat biến thành risk. Lỗ hổng có thể đến từ cấu hình sai, phần mềm lỗi thời, hoặc quy trình vận hành thiếu chặt chẽ.

Ở góc nhìn Product, đây là một điểm cực kỳ quan trọng: mọi quyết định về tính năng, kiến trúc hay tích hợp bên thứ ba đều đang tạo ra hoặc làm giảm rủi ro, dù chúng ta có chủ động gọi tên nó hay không.

Subscribe now

7.Kiến thức Network

Khi làm Fintech, mình từng gặp một issue liên quan đến network khiến mình vật vã vì không nắm kiến thức network nên không đặt ra các câu hỏi đúng, chỉ là forwarder thông tin giữa team network nội bộ và đối tác.

Thời điểm đó mình cũng chưa nghiêm túc nghiên cứu. Còn trong domain mới này, một số cuộc họp có sự tham gia của anh em bên Network và Security, mình buộc phải nghiêm túc tự học thêm các khái niệm network nền tảng. Không phải để trở thành network engineer, mà để hiểu hệ thống đang được bảo vệ như thế nào, các lớp phòng thủ nằm ở đâu, và mình đang đứng ở vị trí nào trong bức tranh tổng thể đó.

Mình bắt đầu từ những khái niệm tưởng chừng rất cơ bản như firewall. Trước đây, mình chỉ xem firewall như một “cái cổng chặn” traffic. Nhưng khi đào sâu hơn, mình hiểu rằng firewall chính là tuyến phòng thủ đầu tiên giữa mạng nội bộ và thế giới bên ngoài. Toàn bộ traffic ra vào đều đi qua đây và được kiểm soát bằng các rule do tổ chức cấu hình. Việc mở hay đóng một rule không chỉ ảnh hưởng đến khả năng kết nối, mà còn trực tiếp làm tăng hoặc giảm attack surface của hệ thống. Và cũng cần nhớ rằng firewall chỉ là một lớp phòng thủ, không phải “lá chắn toàn năng”.

Tiếp theo là server và mô hình client-server. Khi hiểu rằng mọi request từ client - web browser, mobile app đều phải đi qua server để được xử lý, mình bắt đầu hình dung rõ hơn dòng chảy dữ liệu: request đi đâu, được xử lý ở đâu, và response quay lại như thế nào. DNS server, file server, mail server hay application server đều có vai trò riêng, và mỗi server nếu bị cấu hình sai hoặc bảo vệ không đủ chặt đều có thể trở thành mục tiêu tấn công.

Ở tầng kết nối ra internet, mình hiểu thêm về modem và wireless access point cách hệ thống nội bộ kết nối với ISP, cách tín hiệu được chuyển đổi, và vì sao trong enterprise environment người ta thường dùng các công nghệ băng thông cao khác thay vì modem truyền thống

Song song với hạ tầng vật lý và thiết bị mạng, mình buộc phải hiểu cách dữ liệu thực sự “di chuyển” thông qua các mô hình TCP/IP và OSI. Việc chia network thành nhiều layer không phải để học thuộc lòng, mà để xác định chính xác sự cố hoặc tấn công đang xảy ra ở đâu. Một vấn đề có thể nằm ở ARP (network access layer), ở IP routing (internet/network layer), ở TCP retransmission (transport layer), hoặc ở HTTP/DNS (application layer). Khi hiểu được điều này, việc trao đổi với network và security team trở nên rõ ràng hơn rất nhiều: không còn nói chung chung “mạng có vấn đề”, mà là “issue đang nằm ở layer nào”.

Ở transport layer, việc phân biệt TCP và UDP cũng rất quan trọng. TCP đảm bảo dữ liệu được truyền đầy đủ, đúng thứ tự phù hợp với các giao dịch cần độ tin cậy cao như login hay payment. UDP thì ưu tiên tốc độ, chấp nhận mất gói thường dùng cho các ứng dụng real-time như streaming. Hiểu điều này giúp mình đánh giá đúng impact khi gặp timeout, packet loss, thay vì quy hết trách nhiệm cho application.

Khi nhìn lên các layer cao hơn của OSI model, mình bắt đầu thấy rõ mối liên hệ giữa network và trải nghiệm người dùng. HTTP/HTTPS, DNS, SMTP ở application layer; SSL/TLS ở presentation layer; session management ở session layer , tất cả đều là những thứ người dùng không nhìn thấy.

Sau tất cả, mình nhận ra việc học network không phải để “lấn sân” kỹ thuật, mà để đứng đúng vai trò của một PM trong domain cybersecurity: hiểu ngôn ngữ của hệ thống, đặt câu hỏi đúng với đúng team. Và việc biết thêm network nó cũng khá là thú vị nữa :D

8.Kiến trúc Microservices

Các hệ thống backend trong domain BFSI mà mình gặp tới hiện tại, thì đa số theo Microservices Architecture (lúc còn ở Fintech gặp, qua Cybersecurity trong BFSI chắc chắn sẽ gặp tiếp for sure)

Thay vì một hệ thống monolith lớn, microservices chia ứng dụng thành nhiều service độc lập, mỗi service đảm nhiệm một phần logic nghiệp vụ riêng và chỉ service đó mới được quyền truy cập vào database của mình. Các service kết nối với nhau để tạo thành một hệ thống hoàn chỉnh. Cách tiếp cận này giúp hệ thống lớn, phức tạp có thể triển khai nhanh hơn, linh hoạt hơn và ít rủi ro hơn khi thay đổi.

Ở điểm vào của toàn bộ hệ thống là API Gateway. Đây không đơn thuần chỉ là một lớp “forward request”, mà là cửa ngõ kiểm soát truy cập: mọi request từ client, ứng dụng bên thứ ba, hoặc các hệ thống tích hợp đều phải đi qua đây. API Gateway chịu trách nhiệm routing, load balancing, xác thực (ví dụ JWT), rate limiting… Nói cách khác, đây là nơi đầu tiên có thể giảm thiểu rủi ro trước khi request chạm vào logic nghiệp vụ.

Mỗi service trong kiến trúc này thường chịu trách nhiệm xử lý logic nghiệp vụ và kết nối với database. Một nguyên tắc quan trọng là service nào chỉ được truy cập database của service đó, nhằm giới hạn blast radius nếu có sự cố xảy ra.

Đối với giao tiếp giữa các service, không phải lúc nào cũng là syncAPI call. Trong nhiều trường hợp, hệ thống sử dụng Message Broker như ActiveMQ hoặc Kafka để xử lý giao tiếp không đồng bộ. Cách này giúp tăng độ ổn định và khả năng mở rộng, nhưng cũng mở ra thêm bề mặt tấn công nếu hàng đợi hoặc message không được bảo vệ đúng cách.

Ở tầng dữ liệu, một điểm mình thấy rất quan trọng là cách hệ thống tách read và write. Với các use case chỉ đọc dữ liệu, hệ thống có thể sử dụng Replica Database thay vì Primary Database. Replica được đồng bộ gần như real-time từ Primary thông qua cơ chế replication, giúp giảm tải cho database chính, cải thiện hiệu năng đọc, và quan trọng hơn là giới hạn rủi ro truy cập dữ liệu nhạy cảm. Customer Portal khi thực hiện các tác vụ read sẽ truy vấn Replica, sau đó kết quả được trả ngược lại qua API Gateway để hiển thị cho người dùng.

Vì sản phẩm của mình có một phần gắn trực tiếp với API Gateway, nên việc hiểu rõ vai trò của lớp này trở nên đặc biệt quan trọng, bản đồ giúp nhìn thấy dữ liệu đi qua đâu, rủi ro phát sinh ở lớp nào, và đâu là vị trí hợp lý để đặt thêm các lớp bảo vệ.

C.Những công cụ mới

1.SIEM tools (Security Information and Event Management)

Trong thực tế vận hành an ninh mạng, việc “nhìn thấy” chuyện gì đang xảy ra trong hệ thống quan trọng không kém việc có công cụ phòng thủ. Đây là lúc các SIEM tools (Security Information and Event Management) phát huy vai trò.

• SIEM là các hệ thống thu thập và phân tích log data tức là toàn bộ dấu vết sự kiện diễn ra trong hệ thống của tổ chức. Với quy mô dữ liệu lớn, việc tự lọc log bằng tay có thể mất hàng giờ, thậm chí hàng ngày. SIEM giúp giảm tải đáng kể cho đội ngũ security bằng cách tự động phát hiện các mẫu hành vi bất thường và đưa ra cảnh báo cho những mối đe dọa, rủi ro hoặc lỗ hổng cụ thể.

• Các SIEM tool thường cung cấp nhiều dashboard trực quan, gom dữ liệu thành từng nhóm để người dùng dễ theo dõi và phân tích theo nhu cầu. Tùy từng công cụ, dashboard và mức độ chi tiết sẽ khác nhau. Về mặt triển khai, SIEM có thể được cài đặt on-premise hoặc cloud. Nhiều tổ chức lựa chọn bản cloud vì dễ setup, vận hành và bảo trì hơn, đặc biệt với những đội security chưa quá dày dạn kinh nghiệm.

Mình được tuyển vô làm Product trong team này, một phần task là để build cái dashboard cho sản phẩm của công ty. Make it useful / insightful / user-friendly / better UI hơn cho end users.

• Ví dụ 1 SIEM tool phổ biến mà anh tech lead của mình có nhắc mình vô nghía để học hỏi coi người ta build dashboard thế nào

  • Splunk

    • Security posture dashboard (Dashboard này thường được sử dụng trong SOC). Nó hiển thị các sự kiện bảo mật nổi bật trong 24 giờ gần nhất, giúp đội ngũ security đánh giá nhanh xem hệ thống và các chính sách bảo mật có đang hoạt động đúng như thiết kế hay không. Đây là nơi analyst theo dõi các tín hiệu bất thường theo thời gian thực, ví dụ như traffic đáng ngờ từ một IP cụ thể.

    • Executive summary dashboard: giúp tổng hợp xu hướng sự cố, mức độ rủi ro theo thời gian, để security team có thể báo cáo ở mức high-level cho stakeholder hoặc leadership, thay vì đi vào chi tiết kỹ thuật.

    • Incident review dashboard: Dashboard này hỗ trợ phân tích khi một sự cố đã hoặc đang xảy ra, nhìn thấy timeline các sự kiện dẫn đến incident, từ đó hiểu được chuỗi nguyên nhân và xác định điểm cần can thiệp.

    • Risk analysis dashboard: Đây là nơi rủi ro được gán cho từng đối tượng cụ thể như user, máy tính hay IP address. Những hành vi bất thường ví dụ đăng nhập ngoài giờ làm việc hoặc lưu lượng mạng tăng đột biến. Dashboard này giúp security ưu tiên xử lý đúng chỗ, thay vì dàn trải nguồn lực.

À nói thêm, mấy anh ANBM 1 tay công cụ rồi, còn 1 tay khác là các tài liệu hướng dẫn chi tiết cách hành động trong từng tình huống cụ thể, kiểu như “kịch bản ứng phó”, mô tả từng bước cần làm khi xảy ra một sự cố an ninh. Mỗi tổ chức thường có kịch bản khác nhau, nhưng chung mục tiêu xử lý sự cố một cách nhất quán, đúng quy trình và có thể audit lại được.

2.Open-source/Operating systems/Automation

Mình quan sát thấy mấy anh tech sử dụng các Open-source tools vì 1 nó miễn phí và 2 là triết lý phát triển mở (phần mềm được xây dựng cộng tác bởi cộng đồng, với mã nguồn được công khai). Nhờ đó, mà dễ tùy biến linh hoạt theo nhu cầu, đồng thời các vấn đề bảo mật thường được phát hiện và vá nhanh hơn do có nhiều người cùng kiểm tra và đóng góp.

Linux là một ví dụ điển hình, một hệ điều hành mã nguồn mở rất phổ biến, cho phép cộng đồng đóng góp và cải tiến liên tục. Linux cho phép người dùng tùy biến hệ thống sâu thông qua command-line interface. Thông qua các command, analyst có thể kiểm tra trạng thái hệ thống, theo dõi tiến trình, phân tích log và xử lý sự cố nhanh chóng..

Mình thấy việc các anh trong cybersecurity dùng command line rất thành thạo, nhiều khi chả cần dùng chuột, cứ bấm bàn phím rồi mọi thứ chạy ầm ầm.

Bên cạnh đó, các security analyst thường sử dụng những ngôn ngữ như Python để viết script xử lý các tác vụ lặp đi lặp lại automation (tự động hóa): phân tích log, rà soát dữ liệu, phát hiện hành vi bất thường. Automation giúp tiết kiệm thời gian, tăng tốc phản ứng và giảm rủi ro do lỗi con người.

3.Network protocol analyzer

Song song với việc phân tích log ở tầng ứng dụng và hệ thống, đội ngũ security còn cần quan sát những gì đang diễn ra ở tầng mạng. Đây là nơi các hành vi tấn công thường để lại dấu vết sớm nhất.

Một nhóm công cụ tiêu biểu là network protocol analyzer, hay còn gọi là packet sniffer. Những công cụ này ghi lại và phân tích dữ liệu truyền qua mạng, giúp đội ngũ security thấy được các máy trong hệ thống đang “giao tiếp” với ai, trao đổi dữ liệu theo cách nào, và có điều gì bất thường trong luồng kết nối hay không. Packet sniffer thường được sử dụng nhiều trong điều tra sự cố hoặc phân tích chuyên sâu khi cần hiểu rõ bối cảnh của một hành vi đáng ngờ.

Bên cạnh đó là Intrusion Detection System (IDS): hệ thống giám sát hoạt động của mạng và hệ thống nhằm phát hiện các dấu hiệu xâm nhập. IDS liên tục phân tích các network packet, tìm kiếm các mẫu hành vi có thể cho thấy truy cập trái phép, đánh cắp dữ liệu hoặc các hoạt động bất thường khác.

Điểm mạnh của IDS nằm ở khả năng phát hiện sớm và cảnh báo kịp thời, giúp đội ngũ security có cơ hội phản ứng trước khi sự cố leo thang. Tuy nhiên, cần lưu ý rằng IDS chủ yếu đóng vai trò “phát hiện và cảnh báo”, chứ không trực tiếp ngăn chặn hành vi tấn công. Việc phản ứng và xử lý vẫn cần đến con người và các quy trình đi kèm.

Subscribe now

4.Encryption

Encryption là nền tảng để đảm bảo tính bảo mật của dữ liệu. Thay vì lưu trữ dữ liệu ở dạng có thể đọc được (plaintext), encryption chuyển dữ liệu sang dạng mã hóa (ciphertext), khiến người không được phép gần như không thể hiểu hoặc sử dụng được dữ liệu đó. Phần mã hoá này xưa mình cũng có đề cập ở bài APIs

5.Penetration testing

Ở khúc hacker phía trên, mình có nhắc trước về Penetration testing (pentest), nói lại lần nữa nó là hoạt động mô phỏng các cuộc tấn công vào hệ thống để tìm ra lỗ hổng trước khi kẻ xấu kịp khai thác. Đây là một hình thức đánh giá rủi ro rất toàn diện, có thể xem xét cả mối đe dọa từ bên ngoài lẫn bên trong tổ chức.

Pentest không chỉ kiểm tra công nghệ, mà còn kiểm tra quy trình và con người. Kết quả pen test thường là đầu vào quan trọng để cải thiện security posture của tổ chức.

6. Các công cụ can thiệp, giả lập và phân tích động

Bên mình triển khai POC (Proof of Concept) cho khách hàng khối BFSI, , một phần rất quan trọng là làm rõ năng lực bảo vệ của sản phẩm thông qua báo cáo thực tế. Để làm được điều đó, đội ngũ kỹ thuật không chỉ ngồi đọc tài liệu hay mô phỏng lý thuyết, mà phải chủ động sử dụng các công cụ tấn công để can thiệp, phân tích và thao túng ứng dụng để thử khai thác chính mobile app của khách hàng trong môi trường kiểm soát. Những công cụ này có thể được sử dụng cho nhiều mục đích khác nhau, từ phân tích bảo mật, reverse engineering, cho đến gian lận hay kiểm thử hệ thống

Các bài test này mô phỏng những kịch bản mà ứng dụng có thể gặp ngoài đời thực: từ việc chạy app trên thiết bị đã root hoặc jailbreak, can thiệp bằng các công cụ hooking, phân tích động hành vi ứng dụng, cho đến bắt gói tin và thao túng lưu lượng mạng. Mục tiêu không phải là “phá” ứng dụng, mà là chứng minh rõ ràng sản phẩm đang chặn được gì, phát hiện được gì và còn thiếu ở đâu.

Kết quả của quá trình này được tổng hợp thành các POC report, trong đó thể hiện rất cụ thể: với từng kỹ thuật tấn công, sản phẩm có phát hiện hay không, phát hiện ở tầng nào, phản ứng ra sao, và mức độ rủi ro được giảm thiểu như thế nào. Với khách hàng BFSI, những báo cáo này không chỉ phục vụ việc đánh giá giải pháp, mà còn là đầu vào quan trọng cho các quyết định liên quan đến risk management, compliance và audit nội bộ.

• Công cụ hooking cho phép can thiệp trực tiếp vào hành vi chạy của ứng dụng. Trên Android, những cái tên quen thuộc bao gồm Xposed, EdXposed, LSPosed, Frida, Riru, Zygote injected, Zygisk và Zygisk trên KernelSU. Phần lớn các công cụ này hoạt động bằng cách can thiệp vào Android Runtime (ART) hoặc quá trình khởi tạo của hệ thống (Zygote), từ đó cho phép chỉnh sửa logic ứng dụng khi đang chạy. Đáng chú ý là nhiều cờ phát hiện liên quan đến các công cụ này không thể tắt, do mức độ can thiệp quá sâu vào hệ thống. Một số công cụ cũ như TaiChi hay VirtualXposed hiện không còn được sử dụng rộng rãi, và đã được thay thế bằng Xposed kết hợp repackage hoặc chạy trong môi trường ảo.

• Công cụ root và jailbreak, vốn mở rộng quyền truy cập hệ thống vượt ra ngoài giới hạn mặc định của hệ điều hành.

  • Trên Android, Magisk là công cụ phổ biến nhất, cho phép tuỳ chỉnh hệ điều hành trên thiết bị đã root, đồng thời hỗ trợ nhiều module can thiệp sâu vào hệ thống.

  • Trên iOS, các công cụ jailbreak như Dopamine, checkra1n hoặc mô hình Rootless cho phép vượt qua cơ chế bảo vệ của Apple để phân tích và chỉnh sửa hành vi ứng dụng.

• Công cụ phân tích động và gỡ lỗi (debugger), bao gồm GDB, LLDB và Java Debug Wire Protocol (JDWP). Những công cụ này cho phép theo dõi luồng thực thi, bộ nhớ và hành vi của ứng dụng trong thời gian thực, thường được sử dụng kết hợp với các công cụ hooking như Frida. Với Frida, một frida server sẽ chạy nền trên thiết bị (thường là thiết bị đã root hoặc jailbreak), và khi ứng dụng khởi chạy, Frida có thể can thiệp trực tiếp để phân tích hoặc thay đổi hành vi của ứng dụng.

• Công cụ bắt gói tin (proxy) như Mitmproxy và Burp Suite, dùng để chặn và phân tích lưu lượng mạng giữa ứng dụng và server. Để hỗ trợ chống lại các kỹ thuật này, hệ thống có thể sử dụng cơ chế Proxy CA, nhằm ngăn việc cài đặt chứng chỉ CA giả của proxy và chặn các module như Magisk Trust User Certs, từ đó tăng hiệu quả của cơ chế chống Man-in-the-Middle.

• Môi trường ảo và giả lập (virtual environment / emulator). Android cho phép một ứng dụng chạy trong môi trường của ứng dụng khác, nhằm mục đích chạy nhiều bản ứng dụng với dữ liệu khác nhau. Các công cụ như Genymotion tạo ra môi trường giả lập gần giống thiết bị thật, thường được dùng cho kiểm thử, nhưng cũng có thể bị lợi dụng cho gian lận hoặc reverse engineering.

• Nhìn tổng thể, các công cụ trên không tồn tại riêng lẻ mà thường được kết hợp với nhau: giả lập + root/jailbreak + hooking + proxy + debugger. Chính vì vậy, trong mobile security, bài toán không chỉ là phát hiện một công cụ cụ thể, mà là nhận diện cả một tập hợp hành vi và môi trường bất thường.

Kết

Đây là những gì mình lụm nhặt (liệt kê) được sau 2 tháng probation với domain Cybersecurity. Cybersecurity là câu chuyện về con người, rủi ro và niềm tin rằng hệ thống đang bảo vệ đúng thứ cần bảo vệ, và người dùng phía sau dữ liệu đó được an toàn.

Hai thứ mình dùng nhiều nhất trong quá trình học domain này vẫn là những thứ rất “cũ”: system thinking và viết lại mọi thứ mình vừa hiểu (cùng với hỗ trợ của chatGPT for sure)

• System thinking giúp mình không bị ngợp trước một rừng khái niệm: từ network, microservices, log, SIEM cho tới các kịch bản tấn công. Còn việc viết lại (note, diagram, blog) buộc mình phải trả lời câu hỏi khó nhất: “Mình có thật sự hiểu chưa?”

• Một Product giỏi không phải là người biết nhiều thuật ngữ nhất, mà là người kết nối được các mảnh rời rạc thành một bức tranh có ý nghĩa cho team và cho người dùng.

👉 Nếu bạn cũng đang bước vào một domain mới, đặc biệt là những domain nặng tech như Cybersecurity, vùng vẫy giữa biển kiến thức, nếu hoảng thì kệ nó, hãy cho nó chìm luôn.. “Đắm chìm” học chậm lại một chút, viết lại những gì mình học được rồi từng chút một, mọi thứ sẽ vào form. Và biết đâu, vài tháng sau, khi quay lại đọc những dòng note đầu tiên này, bạn sẽ mỉm cười và nhận ra: “À, mình cũng đã đi được khá xa rồi đó.”

Subscribe now

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

Subscribe now

Trong vật lý, vectơ là một đại lượng có gốc, phương, chiều và độ lớn.
Nghe tưởng chỉ dành cho bài kiểm tra Vật Lý, nhưng thật ra áp vào cuộc sống thấy cũng hợp hợp.

Khía cạnh cá nhân

Vectơ lớn = Con người

Vectơ nhỏ = Những gì chúng ta đang làm mỗi ngày

Nếu xem mỗi người chúng ta như một vectơ lớn, thì mọi hành động (việc học, thói quen, lựa chọn, sở thích, công việc) đều là những vectơ nhỏ góp lực vào tổng hợp đó.

Vậy vectơ-con-người sẽ có:

Gốc = nền tảng, giá trị sống, xuất phát điểm.

Phương = hướng đi, nơi mình chọn đầu tư thời gian & năng lượng.

Chiều = cách mình di chuyển: tiến, lùi, vòng vèo, zig-zag, hay cắm đầu lao thẳng.

Độ lớn = mức độ nỗ lực, cường độ sống,..mà mình tạo ra.

Vectơ-con-người là những vectơ đang chuyển động. Tuy nhiên, có sự khác biệt rất lớn giữa đang chuyển động và đang đi tới (Tương tự như không phải ai bận rộn cũng… tiến bộ)

• Khi các vectơ nhỏ “lạc hướng”: Làm nhiều thứ, rất bận, nhưng hướng thì loạn.→ Tổng hợp lực cuối cùng gần như… không đi đâu cả. Ví dụ quen thuộc: Vectơ lớn = muốn giảm cân, khoẻ hơn. Nhưng vectơ nhỏ = có tập thể dục, nhưng tập 1 lần / tuần, lười biếng, ăn uống vô độ→ Lực triệt tiêu nhau, đứng yên tại chỗ.

• Khi các vectơ nhỏ cùng phương, cùng chiều: Làm ít việc, nhưng có chiến lược.→ Tạo “hợp lực” rất lớn.

Nếu bạn thấy mình bận rộn nhưng không tiến xa, có thể bạn đang “cộng các vectơ” sai hướng.

P/s: Hình ảnh minh hoạ được tạo thử bởi Gemini (hình cũng chưa chuẩn lắm)

Khía cạnh tập thể

Teamwork = Tổng hợp nhiều vectơ con người.

• Nếu mỗi người một hướng, một chiều → năng lượng triệt tiêu nhau.

• Team không cùng hướng: Mỗi người nghĩ một kiểu/ Mỗi bộ phận chạy một nơi → Sản phẩm đứng yên hoặc… đi lùi

• Team cùng phương, cùng chiều → Sức bật cộng hưởng, kết quả lớn hơn tổng từng cá nhân cộng lại

Trong một team sản phẩm, Product Manager, Designer, Dev, QA…Ai cũng có “gốc” riêng, nhưng để sản phẩm đi tới thì cần cùng phương-cùng chiều trong mục tiêu.. Product Manager là người nhìn vectơ tổng hợp, để “hợp lực” của team đi đúng hướng, không bị triệt tiêu bởi misalignment.

Nếu làm sản phẩm có product backlog, thì đi tìm việc cũng có job backlog: Thông tin job, độ ưu tiên, status, link apply, note, cảm nhận cá nhân từ lúc tiếp xúc với HR cho tới Line Manager, rồi level cao hơn như Head of Product hay CEO. Công ty phỏng vấn mình, thực ra mình cũng đang “phỏng vấn” lại công ty.

Tản mạn note ra vài điều mình rút ra được trong hành trình này

1️⃣ Tin nhiều hơn vào gut feeling (trực giác)

• Ở job mà mình off sau pass probation, thật ra ngay từ buổi phỏng vấn đầu tiên đã có chút gì đó “cấn cấn”. Nhưng lúc đó mình lại bỏ qua.

• Nên lần này, mình để ý hơn vào trực giác: Nếu có gì đó không ổn như kiểu không khí căng căng, phỏng vấn như đang “ru ngủ” (năng lượng thấp), hoặc bản thân chỉ mong buổi phỏng vấn mau kết thúc, cảm thấy bị rút cạn năng lượng thì mình sẽ “lắng nghe” cảm giác đó.
  Ngược lại, nếu buổi nói chuyện thoải mái, cả hai bắt nhịp được với nhau, cảm giác hứng khởi và được truyền cảm hứng thì gần như mình biết đây là nơi đáng để đi tiếp vòng sau.

2️⃣ Thành thật trong buổi phỏng vấn

• Mình chọn cách thành thật nhất có thể trong mỗi buổi phỏng vấn. Thành thật cho dễ nói chuyện, đỡ mệt vì không cần phải “diễn” quá nhiều. Nói thật mình từng làm gì, cái gì làm tốt, cái gì chưa tốt cần cải thiện vì cuối cùng, công việc nào cũng sẽ bóc ra hết mà.

• Có thể vì vậy mà đôi khi mình… rớt. Nhưng nếu phải chọn giữa rớt vì thật và đậu vì nói quá, thì mình chọn cái đầu tiên. Vì “nói thật” giúp mình thu hút đúng team, đúng người, và đúng môi trường. Còn “nói cho qua vòng” thì chỉ giúp mình đi nhanh hơn… đến chỗ không phù hợp. Với mình, phỏng vấn không phải là một màn đóng vai phiên bản tốt nhất của bản thân mà là một cuộc đối thoại để xem mình và họ có hợp nhau không.

3️⃣ HR là contact đầu tiên và để lại ấn tượng lâu

• Một số HR mà mình gặp để lại ấn tượng tốt. Từ khâu đầu liên hệ, mô tả chi tiết JD, trả lời kỹ nếu ứng viên cần thêm thông tin, và đặc biệt là luôn cập nhật final status dù ứng viên có rớt.(Nếu có feedback thì quá tuyệt vời như mơ).

• Nhưng cũng có những trường hợp HR tiếp cận hơi vội, hoặc ghost ứng viên dù họ đã follow up rất lịch sự. (Dưới góc nhìn của ứng viên) Đôi khi chỉ cần một dòng tin nhắn, ứng viên cũng sẽ hiểu và vẫn giữ thiện cảm. Xin đừng ghost nhau

• And to be fair, mình cũng chưa phải là ứng viên hoàn hảo. Cũng có lần mình “ghost ngược” lại HR vì miss tin nhắn (mấy công ty có độ ưu tiên nằm P2, P3 chứ không phải P0, P1). Thành thật xin lỗi, và mình đang cố catch-up lại từng cái một.

Peace out!

Subscribe now

Mình lôi cái “Product Management Resource Hub” cá nhân này vừa re-learn, vừa tranh thủ sắp xếp gọn gàng với mong muốn tiện thể share lại cho mọi người luôn (link dưới cuối bài). Note nhẹ: mình tin rằng vẫn còn rất nhiều nguồn tài liệu giá trị khác mà mình chưa tiếp cận (vì thời gian có hạn). Những gì bạn thấy ở đây đơn giản chỉ là các tài liệu mình đã từng hoặc đang đọc, tìm hiểu, sử dụng từ trước đến giờ.

Mình hy vọng product hub này có thể trở thành nguồn tài liệu hữu ích cho các bạn làm sản phẩm, designer, marketer hoặc bất kỳ ai tò mò về thế giới Product. Mình sẽ tiếp tục cập nhật danh sách này theo thời gian nếu mình có cơ hội tiếp cận và đọc thêm các tài liệu khác (nếu ai thấy tài liệu nào hay có thể comment, hoặc nhắn riêng, để mình nghía nhẹ vài bài rồi mới dám bổ sung)

Mình sẽ để link nguồn tổng. Mỗi người tự tham khảo và chọn ra cái nào phù hợp với mình mà follow thôi. Còn các bài hay trong mỗi nguồn, mình sẽ không share. Vì mỗi người một gu đọc, mình thấy hay, bạn có thể thấy bình thường, nên để mọi người tự khám phá & cảm nhận để tìm ra “chân kinh” cho bản thân.

P/s: có 1 nguồn khiến mình vừa thấy thú vị vừa… căng thẳng là YouTube channel “BoringPPL - Xây dựng portfolio Data và Product” của Breaking into Product Management để xem các showcase, portfolio được build bởi những tài năng trẻ. Xem xong chỉ biết thốt lên: “Ôi các bạn vừa trẻ, vừa giỏi, vừa đi đúng ngành sớm thế này. Thật khủng khiếp. Mình phải làm và học tiếp thôi, chứ không thì… ra chuồng gà là có thật”

LINK: https://thiennguyen8.notion.site/product-hub-tn

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

"Chời má ơi, chúa tể document là Thiện rồi đó!". Một anh đồng nghiệp thốt lên như vậy khi thấy mình liên tục gửi các tài liệu chi tiết cho từng chủ đề mỗi khi anh hỏi đến. Mình cười xỉu khi đọc câu đó, không dám nhận cũng không dám phủ nhận..

Personal thought

Documentation là cách để mình “làm Product một cách có trách nhiệm”. Có giai đoạn điểm “chạy” feature nhiều và nhanh chóng mặt, mình gần như là người giữ kiến thức chính. Nếu không viết lại ngay những gì đang biết, thì team Ops, team Dev, cả chính mình đều dễ bị "tẩu hỏa nhập ma".

Trong khả năng, mình cố gắng ghi tất cả đầy đủ lại cho team (ví dụ: API, rule xử lý lỗi, process flow, luồng giao tiếp, thông số giữa các hệ thống..). Không phải vì mình rảnh, mà vì mình biết 2 tuần sau mình có thể sẽ… quên. Trí nhớ là thứ dễ phản bội → Bớt tin nó, vì mình đã gặp rồi:

• Một quyết định quan trọng đã được chốt từ lâu, nhưng không được note lý do kỹ. Sau đó team debate lại y như chưa từng thảo luận.

• Không tìm được latest logic trong doc tính năng.→ Dev đã nghỉ, dev mới phải lôi code ra mò lại.

• Một câu hỏi bị hỏi lại… lần thứ 7, vì không ai nhớ là đã có câu trả lời rồi (nhưng ở đâu thì không rõ).

• Phụ thuộc quá nhiều vào trí nhớ của một cá nhân nào đó đặc biệt trong các môi trường nhịp độ cao, nhiều dự án và thông tin thay đổi liên tục. Nếu người đó mà off thì coi như thông tin bị gián đoạn. Công việc bị kẹt.

Càng đi làm, càng thấy rõ:

Dù bạn làm ngành gì Tài chính, marketing, vận hành, thiết kế, giáo dục, logistics... thì "documentation" cũng là một phần không thể thiếu. Bởi vì rồi sẽ đến lúc các tài liệu chi tiết và đầy đủ sẽ giúp bạn:

• Muốn dễ bàn giao lại công việc cho người mới join vào team. Tăng tốc độ onboarding & scale team.

• Muốn đồng đội hiểu đúng và đủ một quy trình bạn đang làm. Giúp các team của bên bạn lẫn đối tác hoạt động một cách hiệu quả, bớt “anh/chị/em tưởng”, “anh/chị/em nhầm”

• Khi kiến thức được ghi lại rõ ràng và dễ tìm, team và sếp của bạn vẫn có thể vận hành ổn định, không cần nhắn tin hỏi liên tục khi bạn đang vắng mặt.

• Tự cứu chính mình, ghi lại những gì bạn từng mày mò ra

• Muốn chia sẻ một kiến thức với người khác mà không cần phải nhắc đi nhắc lại 1 thứ 10 lần (Bạn sẽ chán). Nhưng bạn có thể viết 1 lần, để 10 người khác hiểu.

Lời kết

Dù bạn làm trong ngành nào, viết một cái SOP, một hướng dẫn ngắn, một bản checklist, hay thậm chí chỉ là note lại 3 dòng sau một cuộc họp tất cả đều đáng giá. Project chạy dồn dập, người này nghỉ, người kia chuyển team, thì thứ duy nhất ở lại là… tài liệu → trao lại ngọn đuốc cho team ra quyết định, làm việc hiệu quả, và… không cãi nhau lung tung vì không nhớ ai nói gì, khi nào.

P/s: Viết blog cũng là một cách mình document lại dành riêng cho bản thân khi trí nhớ không còn là “đồng minh” trong tương lai.

Thông tin thêm

Khi viết tài liệu, mình tự hỏi:

• Người đọc là ai? Họ cần biết điều gì từ đây.

• Mục đích của tài liệu là gì? Đọc để hiểu? Đọc để làm? Đọc để ra quyết định? Nếu họ gặp vấn đề, biết liên hệ ai?

• Nếu mình vắng mặt, người khác có thể dựa vào tài liệu này để tiếp tục công việc không?

• Tài liệu có dễ đọc không

  • Có tiêu đề cụ thể, rõ ràng, đúng trọng tâm?

  • Có link tới tài liệu liên quan không?

  • Có ghi rõ thời điểm cập nhật, người cập nhật?

• Tài liệu có dễ tìm không? Đặt ở đâu, Folder, cấu trúc file thế nào.

• Tài liệu này có thể tái sử dụng / cập nhật được không? Hay phải làm lại từ đầu mỗi lần?

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

Technostress = Technology + Stress

Ra đời từ năm 1984, nghe có vẻ “cũ” nhưng mà độ “càng quét” của nó vẫn còn hết nấc, nhất là thời đại chuyển đổi số (Digital Transformation) đang len lỏi khắp mọi nơi. Để xem, bạn có "trúng đạn" không nhé:

• Lúng túng khi học một công nghệ hoặc phần mềm mới . VD: chuyển từ Excel sang phần mềm quản lý doanh nghiệp ERP

• Bối rối, khó hiểu khi thao tác trên một số ứng dụng công nào đó (và stuck. I feel you bro)

• Quá tải khi cùng lúc phải xử lý 5 cái app chat, 3 phần mềm quản lý công việc, 100 email mỗi ngày

• Ngộp khi đổi job, bước sang một domain hoàn toàn mới, phải học lại từ đầu tất cả mọi thứ: quy trình, công cụ, công nghệ, thuật ngữ,... —> Và bạn cảm thấy stress, hoang mang, thậm chí mất phương hướng…

Đùng đùng…chúc mừng, bạn “trúng đạn” technostress rồi đấy (welcome to the “kiệt sức aka burnout” club). Đặc biệt là nếu bạn thuộc nhóm non-tech, tech-savvy chưa cao, khả năng học cái mới còn chậm, thì cảm giác này càng “đau” hơn gấp bội. Công nghệ không phải lúc nào cũng thân thiện. Và con người thì không phải ai cũng có tốc độ học như nhau, tiếp thu như nhau.

Subscribe now

Hồi đó làm BA triển khai ERP, đi đào tạo cho khách hàng. Cái cảnh lúc bắt đầu hướng dẫn, phải gọi là “cầm tay chỉ việc”, từng bước thao tác phần mềm, từng nút bấm trên UI, từng flow nghiệp vụ... Mình nhớ có một chị kế toán, đang quen làm Excel, giờ phải thao tác phần mềm. Mình vừa show, chị ấy vừa ghi chép, vừa nói (lần thứ 3):

“Em ơi, chị quên rồi. Mình làm lại đoạn này nha.”

Lúc đó mới thấy đuối thiệt sự. Mồ hôi mồ kê tuôn ra không phải vì deadline, mà là vì công nghệ. Với mỗi stakeholder, mình luôn cố gắng đặt mình vào vị trí của họ, hiểu đâu là pain point trong công việc hàng ngày, để giúp họ vượt qua được ngưỡng khó khăn ban đầu. Chứ nếu không có sự đồng cảm, không khéo là chưa kịp thấy “lợi ích số hóa” thì đã bỏ cuộc vì stress.

Plot twist: Biến nỗi đau thành … đề tài luận văn Master luôn (lol).

My Master Thesis = (Tech + Stress) x Level of Painful. Trích 1 đoạn trong luận văn:

Yah, Technostress là chuyện ai cũng có thể gặp, nhất là trong môi trường làm việc ngày nay, nơi công nghệ hiện diện ở khắp mọi ngóc ngách. Và càng ngày, thứ chúng ta cần không chỉ là kỹ năng kỹ thuật, mà còn là kỹ năng đồng cảm với những người đang vật lộn với công nghệ.

Đặc biệt là với những người làm Product như mình, đồng cảm để hiểu đâu là nỗi đau thực sự. Từ đấy, cố gắng thiết kế giải pháp càng đơn giản, càng dễ dùng, càng tốt. Vì đôi khi, điều người dùng cần không phải là thêm tính năng mà là bớt stress.

P/s:

Dạo gần đây mình cũng đang bị “technostress_1” vì tiếp nhận quá nhiều kiến thức mới (mà toàn kiến thức kỹ thuật kiểu khó nuốt).
“technostress_2” khi đang cố song song sử dụng thêm Obsidian (trong khi Notion vẫn là second brain gắn bó lâu năm).
Và “technostress_3” khi thực hiện online một dịch vụ công (aka renew passport) mà gặp lỗi tùm lum. Tự hỏi các chú các cô các bác có tuổi sẽ làm như thế nào khi mà hướng dẫn rối ren.

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

Vì sao mình học Thạc sĩ Kinh tế (trong nước)?

Có nhiều lý do khách quan rất đời thường khiến mình chọn học chương trình Thạc sỹ kinh tế chính quy bình thường trong nước và tại UEH:

• Vì mình có chút tò mò về kinh tế.

• Vì muốn mở rộng thế giới quan thử nhìn một số chuyện qua lăng kính của dân kinh doanh thì nó như thế nào.

• Vì tài chính lúc đó không cho phép mình bung tiền (hoặc mượn nợ) để học Thạc sĩ nước ngoài, hay các chương trình MBA "xịn sò" như CFVG, Western Sydney, EMBA toàn đâu đó 250–300 triệu.

• Và quan trọng: mình biết bản thân lúc đó… chưa đủ “độ chín” để học MBA chung với những bạn toàn là Lead, Manager, Head, Director hay C-level. Nên để dành cho sau này, mình sẽ trở lại với MBA ở một thời điểm phù hợp hơn trong tương lai.

Giải thích kỹ hơn: Không chỉ thế, sau khi xem kỹ syllabus thì lại thấy MBA ở UEH thì thiên về lý thuyết nhiều, hơi hàn lâm (theo đánh giá cá nhân). Mình nghĩ ngành Kinh doanh thương mại (Commercial Business) lại có những môn học thực tiễn hơn cho vị trí Product (mà mình đang theo đuổi) như Digital Marketing, Branding, Supply Chain, E-commerce.. Thêm vào đó, mình cũng bị (bias) ảnh hưởng kha khá bởi một người bạn đã học ngành này trước, tư vấn rất nhiệt tình rằng: “Ngành này sẽ giúp mày build nền tảng nếu sau này muốn làm business riêng”. Và thế là mình đăng ký.

Và rồi... vỡ mộng..

Nói nghe thì hoa mỹ (miều) vậy thôi, chứ thực tế thì… vừa làm vừa học chật vật và sml dữ lắm.

Mỗi tuần, mình học full 2 ngày cuối tuần. Trong tuần sáng thì làm việc công ty, tối về đọc tài liệu, làm bài nhóm, viết essay. Không có thời gian thở. Và càng học càng thấy “hơi trật nhịp” với kỳ vọng ban đầu. Có thời điểm mình gần như mất động lực, muốn bỏ ngang vì cảm thấy không còn kết nối được với ngành học nữa. Mặc dù (trộm zía) điểm số của mình vẫn khá cao, nhưng cảm giác hoang mang tồn tại và có xu hướng tăng.

Ý kiến cá nhân thiệt lòng nha, mình thấy chương trình học và thi của kinh tế chưa nặng bằng chương trình bên kỹ thuật (for sure). Và thiệt lòng lần nữa là mình cũng không biết tại sao mình lại đạt điểm cũng cao như vậy đâu. Mình cũng đọc giáo trình và nghe giảng như mọi người thôi, nhiều chủ đề lạ so với công việc và chuyên môn của mình. Có cái phải mất thời gian tìm tòi và đọc hơn các bạn đang làm trong ngành đó vì kiểu dân kỹ thuật lần đầu nghe về khái niệm đó. Nhưng từ từ cũng quen.

Điểm gỡ: tìm thấy “mối duyên” với Management Information System (MIS)

Mọi chuyện bắt đầu thay đổi khi mình tình cờ phát hiện ngành khác MIS – Management Information System trong chương trình (mình thấy ngành đó hay hơn Kinh doanh thương mại). Cảm giác lần đầu là: “Ủa sao giờ mình mới biết ngành này hay vậy?”. MIS là cái tên nghe rất “mê” với dân Product, BA, PM như mình.Ngay lúc đó, mình biết là phải tìm cách gì đấy để giải quyết, bẻ về hướng MIS trước khi nghỉ tới việc từ bỏ ngành này là và học lại ngành kia. Nếu không tìm được cách phù hợp, thì 1 năm vừa làm vừa học cực nhọc của mình sẽ trôi vào hư vô, uổng phí công sức và tiền bạc.

Trộm vía 1: Gặp được “người thầy xuất hiện khi học trò sẵn sàng”

Khoa của mình là khoa Kinh doanh Quốc tế - Marketing. Nhưng tình cờ mình may mắn tìm được 1 giảng viên trẻ học Tiến sĩ ở Đài Loan, và có nghiên cứu chuyên sâu về thiên hướng về chủ đề công nghệ (Technology), MIS ( Management Information System), tech adoption, hành vi người dùng trong khoa kinh tế (nghe hơi lạ) nhưng lại đúng hướng mình muốn theo đuổi luôn nên mình chốt ngay và luôn. Mình cảm thấy quá là may mắn luôn vì tìm được cô qua môn Digital Marketing và khi cô share về các chủ đề cô đang nghiên cứu.

Nói thêm: Trong ngành mình có 2 hướng - hướng nghiên cứu hoặc hướng ứng dụng. Hướng ứng dụng thì bây giờ làm luận dễ hơn nhưng sau này muốn học lên PhD phải học thêm vài môn và có khi phải làm lại bài nghiên cứu mới. Còn hướng nghiên cứu thì bây giờ làm luận khó. Tuy nhiên sau này muốn học lên PhD cũng dễ và có thể đăng bài tạp chí nghiên cứu khoa học quốc tế (có tí tiền). Mọi người có thể đoán, với tính cách mình thì mình chấp nhận chọn lựa chọn khó bây giờ nhưng open direction hơn về sau. Hiển nhiên mình chọn theo hướng nghiên cứu.

Không nhiều người chọn cô làm giảng viên hướng dẫn luận văn (năm đó, mình là người duy nhất chọn cô làm giảng viên hướng dẫn). Và đúng như câu trong sách “Nhà giả kim”: Khi người học trò sẵn sàng, người thầy sẽ xuất hiện.

Một số đề tài cô từng làm khiến mình thấy quan tâm khi cô chia sẻ, đại đại cũng có tí sát với Product / Research (POV) 

+ Understanding the discontinuance behavior of mobile shoppers as a consequence of technostress: An application of the stress-coping theory

+ Appropriation of accounting information system use under the new IFRS: Impacts on accounting process performance

+ WHAT DRIVES USER ENGAGEMENT BEHAVIOR IN A CORPORATE SNS ACCOUNT: THE ROLE OF INSTAGRAM FEATURES

+ Understanding continuance intention in traffic-related social media: Comparing a multi-channel information community and a community-based application.

+ Understanding Shadow IT usage intention: a view of the dual-factor model

+ Exploring users’ trust transfer mechanism in food delivery app

+ A study of the factors affecting the slow development in using e-wallets of Generation Z in Ho Chi Minh City

+ Inhibitors and Enablers of Peer-To-Peer Mobile Payment Usage Intention

+ Understanding users’ trust transfer mechanism in food delivery apps

Share

Trộm vía 2: Làm luận văn đúng gu, đúng nghề

Ở thời điểm đó, mình đang làm công việc Business Analyst kiêm Project Management tại công ty ERP (có nhắc đến trong bài probation tuần trước). Nên mình cố gắng tìm đề tài nào vừa đúng hướng nghiên cứu của cô và vừa phải gần với cái mình đang làm. Trong quá trình chuyển đổi số cho doanh nghiệp của Khách hàng, mình thấy có sự khó khăn nhất định đối với các end-users khi phải thay đổi công cụ và vài thao tác trong công việc hằng ngày. Mình nhận ra điều này khiến hiệu suất làm việc của họ bị ảnh hưởng (nhiều), đặc biệt trong giai đoạn triển khai phần mềm.

Ví dụ như thay vì hành động mua hàng, nhập kho, ghi chú dữ liệu sẽ vào file Excel sẽ thay đổi → lên phần mềm ERP với các ứng dụng Purchase / Inventory / Accounting. Học phải học cách thao tác trên đấy (đôi chút khó khăn cho các non-tech users hoặc các cô chú 4x, 5x không quá quen với các phần mềm). Vì thấy sự nhức nhối đó, mình có tham vấn với cô, sense check với các nghiên cứu, thực hiện phỏng vấn nhanh với một người dùng trong quá trình chuyển đổi số và sau đó chốt lại được đề tài:
“An investigation on the impact of technostress on employee performance in the context of ERP system adoption.” (kiểu trong quá trình chuyển đổi số như mình nhắc bên trên, thì những yếu tố stress liên quan đến việc đổi công nghệ ảnh hưởng thế nào đến hiệu suất làm việc của nhân viên. Một số khái niệm trong bài luận văn này khá thú vị, chắc mình sẽ viết thêm trong bài khác)

Khi trình bày trước hội đồng, một số thầy cô còn… hơi bất ngờ vì đề tài lạ vì nó xuất hiện trong khoa Kinh doanh Quốc tế - Marketing, chứ không phải khoa Hệ thống Thông tin. (À bổ sung một điểm nữa là đề tài này mình viết và thuyết trình hoàn toàn bằng Tiếng Anh thay vì như tiếng Việt như đa số các bạn khác). Có lẽ nhờ 2 điểm ấy mà trộm vía mình đạt điểm cao nhất hội đồng hôm đó 🎓 (đang flex đó haha)

Rốt cuộc, mình học được gì?

• Trở lại đúng hướng đi mình mong muốn. Luận văn nghiên cứu này có trải nghiệm khá giống với việc làm Product Discovery / UX research trong Product Management. Quá trình làm bài nghiên cứu giúp mình rèn cách “Tìm research gap, đặt đầu bài (problem statement), đặt giả thuyết (hypothesis), phát triển giả thuyết, tìm khái niệm liên quan, đặt câu hỏi khảo sát, phân tích hành vi, đánh giá kết quả, đưa insight, đề xuất hướng giải pháp…”

• Không những thế, thời gian học Thạc sỹ mình đang làm ở công ty ERP nên mấy thuật ngữ trong quá trình học cũng có phần nào giúp mình trong việc phân tích nghiệp vụ kinh doanh của khách hàng về các domain kinh tế như supply chain, purchasing, logistics, retail.. Từ đó mình dễ kết nối và làm việc với stakeholder thuộc các phòng ban này trong công ty Khách hàng.

• Networking? Ngoài ra thì mình cảm thấy có cơ hội networking với các bạn ngành khác, mindset khác. Tuy nhiên thú thật là network bạn bè ở đây không quá mạnh. Nhưng network với cô giảng viên thì cực kỳ đáng giá. Vì cô làm đúng mảng mà mình quan tâm nên mình trao đổi và học hỏi được nhiều thứ từ cô (Và cô siêu support trong quá trình làm luận văn). (Trộm zía,ước) Hi vọng sắp tới hợp tác ra được bài báo quốc tế nào thì số dzách nữa :))))

Lời kết

Nếu mình không “quay đầu là bờ” kịp, chắc giờ mình vẫn đang vật vã trong mớ lý thuyết mà chẳng biết nó có áp dụng gì được không. Nhưng nhờ một lần dừng lại, đánh giá và chọn lại, mình đã học xong Master sao cho đi đúng hướng với career mình đang theo đuổi…..

Thế còn mọi người thì sao? Hiện tại, có việc nào chưa "ưng" ? Đã tới lúc chậm lại một nhịp. Để đánh giá, suy nghĩ, và tìm cách giải quyết mới. Cứ thử bẻ lái 1 tí… twist hay đang chờ phía trước.

Ngoài lề, nếu bạn đang cân nhắc học Thạc sĩ?

Một vài gợi ý thật lòng (từ góc nhìn của mình, không có đúng sai, không áp dụng được cho tất cả mọi người):

• Nghiên cứu kỹ ngành học trước khi đăng ký cho đáng thời gian, tiền bạc, công sức. Đừng chọn theo trend hay lời rủ rê (như mình).

• Đặt những câu hỏi như tại sao mình học ngành này là gì. Động lực là gì ? (VD: Tại sao học Master kinh tế mà không học Master kỹ thuật?). Điều này có giúp ích gì cho sự nghiệp không (học nếu bạn học vì tò mò giống ý định ban đầu của mình. That’s still OK, học không phí, không “bổ” ngang thì “bổ” dọc)

• Hãy chọn chương trình phù hợp với mục tiêu, ngân sách, giai đoạn sự nghiệp của bạn.

• Học trong nước hay nước ngoài? MBA hay Chuyên sâu vô ngành nào đấy?

• Nếu học trong nước, chọn chương trình MBA ở VN thì chọn chương trình bình thường hay xịn (nếu bạn có điều kiện, hãy cân nhắc các chương trình MBA chất lượng cao như CFVG, Western Sydney, EMBA. Network alumni xịn, chương trình mạnh)

• Nếu học để hiểu thêm về business / build nền tảng để làm product, BA, PM,... thì có thể chọn chương trình “vừa đủ” để học đỡ ngợp, và sát thực tiễn công việc.

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

Mình xin dành bài viết tổng hợp cho các bạn đang muốn tối đa phát triển bản thân (Self-development) để trở thành một phiên bản tốt hơn của mình mỗi ngày.

1. Phát triển bản thân (self-development or personal development) chắc hẳn không là một khái niệm xa lạ trong những năm gần đây. Trên thị trường, mình thấy ngập tràn vô số các sách self-help với các mớ lý thuyết và khái niệm về các cách phát triển bản thân, thế nhưng lại có rất ít sách lại đề cập đến cách xây dựng cũng như các công cụ để hỗ trợ trong quá trình xây dựng đó.

2. Thêm vào đó ngày nay, hầu hết bất cứ ai đều có bên mình một chiếc smartphone - một vật bất ly thân theo sát bên mình trong suốt một ngày. Thế nhưng có bao nhiêu người đã thật sự biết cách sử dụng chiếc PHONE đó theo cách SMART nhất để đem lợi ích tối đa cho cuộc sống của mình?

→ Tổng kết lại dựa vào 2 điểm trên (Self-development + Smartphone) ở bài viết này, mình muốn nhắc lại một số thói quen tốt mà mình nghĩ mọi người nên theo đuổi, cũng như các ứng dụng trên điện thoại sẽ hỗ trợ bạn trong quá trình build điều ấy. Bài viết dưới đây được viết dựa trên trải nghiệm cá nhân của mình trong quá trình hơn 1 năm xây dựng các thói quen bằng việc sử dụng smartphone 1 cách thông minh và hiệu quả hơn. Bài viết sẽ vừa kết hợp chia sẻ suy nghĩ của mình về mục đích, lợi ích, cũng như cách đơn giản (không quá chi tiết) để sử dụng từng app. Nói thêm, điều mình thích ở các app tracking dưới đây là nó luôn có tab để giúp mình review toàn bộ lại cả quá trình, điều đó cho mình cảm thấy sự tiến bộ từng ngày.

1. HabitBull (Ứng dụng để xây dựng một thói quen mới)

“Hành động tạo ra thói quen. Thói quen tạo ra giá trị và giá trị tạo nên vận mệnh”, Mahatma Ghandi

Luyện tập những thói quen như thể dục, đọc sách hằng ngày, quản lý chi tiêu...chắc hẳn chúng ta đã nghe ra rả rất nhiều lợi ích nếu ta sỡ hữu các thói quen như thế. Đây là ứng dụng đầu tiên mình muốn nhắc tới, nhớ như xương sống cho các app phía sau. Đây là một dạng app Habit Tracker, ở đây mình sử dụng ứng dụng HabitBull để build và tracking toàn bộ thói quen mới mà mình hình thành trong suốt hơn 1 năm. Và nhờ hỗ trợ của app, cho đến hiện tại mình cam kết rằng hầu hết những thói quen mình build đều gần như đã trở thành các hoạt động bình thường hằng ngày cũng như hàng tuần của mình mà không cần tốn quá nhiều nỗ lực.

HabitBull sẽ không áp dụng qui luật 21 ngày để hình thành một thói quen mới, qui luật mà mọi người vẫn thường nghe, mà nó sẽ áp dụng qui luật 66 ngày. Cá nhân mình trải nghiệm thì thật sự sau qui luật 21 ngày thì thói quen mới đó vẫn chưa hoàn toàn hòa nhập tự nhiên vào cuộc sống của chính mình. Mình cảm nhận phải ít nhất sau hơn 2 tháng (66 ngày) các thói quen đó trở nên hành động tự nhiên cũng giống như việc mình đánh răng hằng ngày vậy.

Cách sử dụng: đơn giản bạn download Habitbull, set target chi tiết với tần suất cụ thể.

• Ví dụ 1: mình set up thói quen đọc sách 30p-1 tiếng sau khi ngủ dậy, tần suất hằng ngày. Ngày nào mình làm thì làm điều đó thì mình sẽ tick vào app, các ngày sẽ nối liên tiếp nhau cho đến khi nào đủ 66 ngày thì mình thành công. Với bất cứ một ngày mình quên thì liên kết đó mất đi và sẽ reset đếm lại từ đầu.

• Ví dụ 2: mình set up thói quen chạy bộ, tần suất 3 ngày/ tuần. Trường hợp xảy ra nếu từ thứ 2-thứ 5 mình quá bận ko chạy được thì mình vẫn tick vào app ok, nhưng mình sẽ có được cái nhìn tổng quan là bắt buộc ba ngày còn lại trong tuần (T6-T7-CN) mình phải xách giày lên giày, nếu không thì kẻo dữ liệu lại bị reset về 0.
  Đặc biệt, HabitBull có tab để mình có cái nhìn tổng quan toàn bộ quá trình và chi tiết các thói quen mà mình đang xây dựng

• Link research build habit trong 66 days

2. Money Manager (Ứng dụng quản lý tài chính cá nhân)

Tầm quan trọng của việc phát triển tư duy trong quản lý tài chính cá nhân thì hoàn toàn cần thiết, không thể chối cãi. Không quan trọng bạn được bao nhiêu, quan trọng cách bạn tiết kiệm và đồng tiền đó thông minh như thế nào. Như tên gọi của nó, "Money Manager" giúp mình quản lý dòng tiền ra/vào các tài khoản của mình. Nhờ ứng dụng này mà sau tháng 4 vừa rồi mà sau 1,5 năm đi làm mình đã trở gần như xong toàn bộ nợ (tiền ăn, tiền học, tiền học AV, tiền đi du lịch...) trong suốt quãng đường sinh viên 4,5 năm của mình (vì gia đình không đủ khả năng chi trả, nên tất cả số tiền trong 4,5 năm ấy mình đều mượn khắp nơi dưới sự bảo lãnh của gia đình). Nói thêm cho các bạn không phải để khoe khoang hay gì, mà ý mình ở đây là các bạn biết được nợ lớn thế nào và mình vô cùng cảm ơn ứng dụng này mình giúp nghiêm túc kỷ luật trong quản lý chi tiêu để mình trả được cái cục nợ to tướng ấy đó :D

Cách sử dụng: Mình thiết lập các tài khoản trong app y như các tài khoản mình đang có ngoài đời thực tế như thẻ Debit/Credit, tài khoản tiết kiệm, số tiền cash trong ví, tài khoản đầu tư.... Tất cả đồng tiền ra vào, bao nhiêu, lý do là gì đều được mình ghi lại liền ngay lập tức mỗi khi có giao dịch và mình sẽ kiểm tra vào cuối ngày, cuối mỗi tuần, cuối mỗi tháng.

Money Manager có tab để tổng kết dữ liệu chi phí cho từng khoản trong suốt cả tháng. Sau đó, mình chỉ cần 3 tháng bạn sử dụng một cách cẩn thận thì những tháng sau thì mình có ước tính được chi phí cho từng mục vào tháng sau của bạn là bao nhiêu ( có tab để tổng kết dữ liệu chi phí cho từng khoản trong suốt cả tháng. Sau đó, mình chỉ cần 3 tháng bạn sử dụng một cách cẩn thận thì những tháng sau thì mình có ước tính được chi phí cho từng mục vào tháng sau của bạn là bao nhiêu ( ví dụ bao nhiêu tiền cho ăn uống, coffee, nhà trọ, đi lại..) Đối với mình, nhờ những thông tin đó, mình có thể lên kế hoạch tài chính cả tháng sau hoặc cả năm sau, mình biết mình đang tiêu vào những chỗ nào là đúng, những chỗ nào ko cần thiết nên cắt giảm, cũng như là mình sẽ tiết kiệm được bao nhiêu. Nếu đồng tiền bạn đem đi đầu tư thì lời/lỗ như thế nào. Nói chung bạn sẽ có cả 1 lịch sử giao dịch tiền tệ của chính bạn được lưu lại và bạn có thể review vào bất cứ lúc nào....

3. Five minutes journal app (Ứng dụng cải thiện tư duy tích cực)

Tư duy tích cực (positive thinking) đã được chứng minh là phương pháp hiệu quả cho mental health như làm giảm căng thẳng, lo lắng, áp lực cuộc sống (tiền bạc, sự nghiệp, gia đình, peer pressure..) và trầm cảm của con người. Mình cảm thấy càng trưởng thành hơn con người lại càng cảm thấy khó hơn để duy trì tư duy tích cực. Nếu như trước đây khi còn nhỏ, “thất bại” chỉ là bị điểm kém, bị trượt học bổng, bị người lớn chê trách, thì bây giờ “thất bại” đồng nghĩa với thụt lùi về sự nghiệp, khó khăn về tài chính, và thất vọng với gia đình, áp lực thua kém bạn bè. Nó sẽ khiến mình stress, mất ngủ và đôi khi cả suy nhược cơ thể.. Lúc ấy mới nhận thấy ngoài tầm quan trọng của physical health ra, thì mental health cũng quan trọng không kém.

Điều cốt lõi, việc xây dựng và duy trì tư duy tích cực là việc cần làm đều đặn hằng ngày. Có rất nhiều phương pháp , nhưng hiện tại mình áp dụng phương pháp ghi chép cá nhân (Journaling) để giải quyết vấn đề này. Journaling - lối viết tự do, khai phóng của những suy nghĩ của mình hằng ngày để giải tỏa cảm xúc cá nhân.

Cách sử dụng: Hằng ngày, app bắt đầu bằng một châm ngôn cuộc sống, sau đó theo bởi 2 phần: Sáng và Tối. Câu hỏi gợi ý hướng đến nhiều mục đích: vừa luyện tập lòng biết ơn, vừa chuẩn bị các target trọng tâm cho ngày mới, lời khẳng định (confirmation) cho bản thân và vừa rút được kinh nghiệm cho ngày tiếp theo

• Phần Sáng bao gồm: (1) Tôi cảm thấy biết ơn về … , (2) Tôi sẽ làm gì để ngày hôm nay trở nên tuyệt vời?, (3) Quyết tâm trong ngày: Tôi là …

• Phần Tối bao gồm: (1) 3 điều tuyệt vời nhất xảy ra trong ngày…, (2) Tôi đáng lẽ có thể làm gì để hôm nay tốt hơn?

• Mỗi sáng, mình sẽ dành 5-10p để viết Phần Sáng, mình viết những gì ập vào đầu mình dựa trên các câu hỏi gợi ý, và đôi khi nó có thể giống nhau mỗi ngày (, mình viết những gì ập vào đầu mình dựa trên các câu hỏi gợi ý, và đôi khi nó có thể giống nhau mỗi ngày (, mình viết những gì ập vào đầu mình dựa trên các câu hỏi gợi ý, và đôi khi nó có thể giống nhau mỗi ngày (ví dụ trong phần sáng có phần "Tôi cảm thấy biết ơn về...", mình có thể viết là "Tôi cảm thấy biết ơn vì mình được sinh ra với đầy đủ tay chân lành lặn, hạnh phúc hơn nhiều so với các bạn bị tật nguyền hoặc Tôi cảm thấy biết ơn vì mình được sống thêm một ngày mới, có một công việc tốt để chăm lo cho gia đình..)

• Cuối ngày, trước khi đi ngủ, mình dành 5p hoàn thành phần Tối: để kể về những gì hấp dẫn hoặc ấn tượng xảy ra trong ngày. : để kể về những gì hấp dẫn hoặc ấn tượng xảy ra trong ngày. : để kể về những gì hấp dẫn hoặc ấn tượng xảy ra trong ngày. Ví dụ: mình ghi là 1 trong những điều tuyệt vời ngày hôm nay là mình làm việc tốt được sếp khen or được nhận lương thưởng.... Bạn viết bất cứ gì bạn thấy vui là được, vừa tổng kết một ngày dài và giúp bạn giải tỏa để có giấc ngủ tốt hơn.

4. Notion (Ứng dụng ghi chú)

Mình rất thích ghi chép lại mọi thứ bằng notebook và bằng điện thoại. Nhưng mình thường thích xài digital note-taking app vì lúc nào mình cũng luôn mang điện thoại bên mình. Mình đã xài qua rất nhiều app ví dụ như Note của Iphone hoặc Evernote, nhưng app mình sử dụng và rất tâm đắc muốn giới thiệu đến mọi người. Đó là NOTION.

Notion cho phép mình xây dựng phần note của mình theo cách sáng tạo nhất mà mình có thể nghĩ tới. Và hầu như mình ghi chú toàn bộ khía cạnh của cuộc sống từ mục tiêu, ước mơ, lý tượng, ý tưởng kinh doanh, học tập, sức khỏe, hệ thống tài chính cá nhân-đầu tư... gần như tất cả mọi thứ, tất cả sẽ được ghi chú và có thể review ở bất cứ đâu. Lúc đầu bạn có thể mất một chút thời gian để làm quen, nhưng sau đó thì mọi thứ sẽ tiện dụng hết sức có thể cho bạn. Vì ứng dụng này có nhiều tính năng nên mình ko thể đi quá sâu vào chi tiết, mình sẽ có một bài viết riêng khác cho app này

• Một số ví dụ Notion bạn có thể click vào xem:Đây là mẫu template mình build kế hoạch hàng tuần: https://bit.ly/weeklyagenda-tyler

• Hoặc có thể là mục lục lưu giữ các cuốn sách mà mình có thể xem 1 cách trực quan và rõ ràng nhất: Hoặc có thể là mục lục lưu giữ các cuốn sách mà mình có thể xem 1 cách trực quan và rõ ràng nhất: https://bit.ly/books-projects

• P/s: Tất cả các link mình kèm trong bài viết này đều sử dụng phần mềm Notion.

5. Drink water (Ứng dụng theo dõi lượng nước tiêu thụ hằng ngày)

Việc uống đủ nước mang lại nhiều lợi ích quan trọng nhằm đảm bảo cho cơ thể hoạt động hiệu quả và khỏe mạnh. Ứng dụng "Drink Water" sẽ là công cụ tuyệt vời để đưa ra con số tối ưu dựa trên khối lượng của bạn, cũng như nhắc nhở mình bổ sung nước đầy đủ hơn.

Do đó trong suốt hơn 1 năm qua, mình cũng build một thói quen uống đủ lượng nước cho cơ thể trong 1 ngày. Không những thế, app "Drink water" cũng có thể có các lựa chọn nước khác như coffee, nước chanh, sữa ..vv... Điều đó sẽ giúp mình xem lại coi lượng tiêu thụ của từng loại đó trong tuần trong tháng như thế nào. Bạn có thể check xem là tháng trước bạn có uống quá nhiều cafe hoặc bia hay không để giúp bạn có cái nhìn tổng quát và cẩn thận hơn cho sức khỏe của mình.

6. Todolist (Ứng dụng lên task chi tiết)

Việc lên kê hoạch chi tiết sẽ giúp bạn không bị thiếu sót hoặc quên mất nhiệm vụ cho công việc

Mình sử dụng Todolist để lên kế hoạch chi tiết cho các task cụ thể mình cần làm trong ngày. Như vậy mình sẽ có cái nhìn tổng quát là ngày hôm đó có bao nhiêu task, tốn bao nhiêu thời gian và mức độ ưu tiên cho từng task. Cũng như bạn biết được các task vào ngày mai, ngày mốt, cũng như tuần sau, tháng tới tùy thuộc vào deadline của bạn.

Mình chia nhỏ ra các dự án và chia task khác nhau cho các dự án. Ngoài thị trường, có rất nhiều các app todolist khác nhưng mình đề xuất các bạn app này vì giao diện của nó đẹp, trực quan cũng như rất dễ xài .

7. Forest (Ứng dụng tăng cường độ tập trung khi làm việc)

Phần mềm Forest giúp mình nâng cao khả năng tập trung khi làm việc, để tránh sự sao nhãng từ các việc khác, đặc biệt từ chính chiếc điện thoại của mình. Ứng dụng này đã giúp mình tập trung và hoàn thành tốt hơn khi làm bất cứ việc gì đã được plan trong app Todolist phía trên

Cách sử dụng: ứng dụng này cho phép mình gieo các hạt giống và hạt giống này sẽ nở thành cây trong khoảng thời gian do mình thiết lập (tối thiểu 10 phút và tối đa 120 phút). Trong thời gian đó, mình không thể thoát khỏi ứng dụng để chạy các ứng dụng khác (như lướt facebook hoặc instagram), nếu không cây sẽ chết và không thể tiếp tục phát triển.

Mình có thể để xem thành quả là rừng cây mà mình đã gieo trồng được, cũng chính là thời gian mà mình đã tập trung vào công việc mà không bị sao nhãng bởi smartphone. Tại đây mình có thể xem được mình đã trồng được bao nhiêu cây trong ngày cũng như đã làm chết bao nhiêu cây. Điều này cho mình thấy rằng mình có thực sự tập trung vào công việc hay chưa, hay vẫn thường xuyên sử dụng smartphone trong thời gian làm việc.

8. Strava (Ứng dụng tracking chạy bộ)

Sức khỏe là tài sản vô giá nhất của mỗi người trong cuộc sống. Do đó việc build 1 thói quen tập thể dục thường xuyên là điều vô cùng quan trọng. Trước đây mình cũng có đã có thói quen tập gym, gần đây mình bổ sung thêm việc chạy bộ. Sức khỏe là tài sản vô giá nhất của mỗi người trong cuộc sống. Do đó việc build 1 thói quen tập thể dục thường xuyên là điều vô cùng quan trọng. Trước đây mình cũng có đã có thói quen tập gym, gần đây mình bổ sung thêm việc chạy bộ (mình copy thói quen của các nhân vật thành công vì nghe nói họ cũng hay chạy bộ lắm) vào quá trình tập luyện của mình, trước đó mình vô cùng ghét và cũng không thể chạy quá 2km/lần mặc dù mình có thể hít đất 50 lần liên tiếp.

Ứng dụng Strava và HabitBull phía trên là 2 ứng dụng đã giúp mình build được thói quen chạy bộ và kết quả bất ngờ hơn cả mong đợi nhờ nó mình giảm được 7kg trong năm 2019 vừa qua-điều mà gym mình chưa làm được

Strava sẽ ghi nhận lại quãng đường, tốc độ khi bạn chạy, nó có ghi nhận lại biểu đồ luyện tập, quá trình tiến bộ của bạn sau nhiều tháng sẽ có thay đổi như thế nào (bạn chạy nhanh hơn, bền hơn..). Strava cũng có các thử thách, cột mốc thành tích hàng tuần để giúp bạn có động lực chạy hơn. cũng có các thử thách, cột mốc thành tích hàng tuần để giúp bạn có động lực chạy hơn. cũng có các thử thách, cột mốc thành tích hàng tuần để giúp bạn có động lực chạy hơn. Note: Các nhân mình đề xuất bạn cũng nên kiếm cho mình những người bạn có cùng sở thích chạy hoặc CLB chạy bộ để bạn càng có thêm niềm vui lẫn động lực để theo đuổi bộ môn chạy bộ này.

9. Google Calendar - 10. Gmail (Ứng dụng lên kế hoạch, thời gian)

Lost time is never found again. – Benjamin Franklin.

• Đây là 2 phần mềm khá quen thuộc đến từ Google mình sử dụng để lên kế hoạch tổng quát và kiểm soát thời gian của mình. Mình áp dụng phương Block Calendar và ghi chép toàn bộ lại hoạt động trong ngày của mình lên Calendar. Điều này mang lại lợi ích là bạn có thể quan sát và review lại trong tuấn trước hoặc tháng trước bạn đã dành thời gian vào những việc gì, việc đó có ích hay vô ích, việc đó đã tốn bao nhiêu

• Ví dụ cách sử dụng của mình: vào tối CN, mình thường plan cho cả tuần của mình trên phần mềm NOTION, sau đó dựa theo các thói quen trong app HABITBULL của mình để sắp xếp các việc block thời gian và sắp xếp công việc này lên bảng Google Calendar. Cụ thể hơn như thói quen đọc sách mình muốn duy trì hằng ngày thì mình sẽ fit lên giờ cụ thể cho từng ngày trong tuần hoặc là thói quen chạy bộ 3 ngày/tuần, mình cũng sẽ fit lên ngày cụ thể như Mon-Wed-Fri. Hầu như mình sẽ sắp xếp lên toàn bộ Calendar như vậy mình sẽ có cái nhìn bao quát, để biết được là ngày nào mình sẽ free, có thể dành cho các hoạt động khác. Và mình plan cho từng tuần vì nó giúp cho mình có được sự linh hoạt mà vẫn giữ kỹ luật của HABITBULL

Subscribe now

11. Flipboard (Ứng dụng xem tin tức tiếng Anh)

Đây là phần mềm mình được giới thiệu từ một anh thầy dạy tiếng Anh. Thay tốn thời gian để đọc các thông tin từ kênh lá cải như Zing, Kenh14, mình sử dụng Flipboard này để đọc các tin tức tiếng Anh vừa tăng thời gian tiếp xúc với văn phong tiếng Anh, cải thiện kỹ năng đọc, viết vừa nắm bắt các vấn đề xã hội đang xảy ra hiện nay. Flipboard bao gồm rất nhiều chủ đề mà mình hoặc các bạn có thể quan tâm như: News, Business, Technology, Sports, Travel, Politics, Sciences, Politics.......

Cách sử dụng: Vì mỗi ngày bài viết của Flipboard đối với một người có trình độ tiếng Anh vừa thì mất khoảng 5p nếu không cần tra từ điển. Mình sử dụng app này khoảng 15p buổi sáng và 15p buổi chiều khi trên xe bus của công ty, trong cùng lúc đó mình sẽ nghe podcast từ Spotify.

Sau một thời gian sử dụng, thì thật sự khả năng đọc và vốn từ vựng của mình tăng lên rất nhiều. Điều này giúp cho các bạn muốn thi IELTS như mình có cơ hội rèn luyện khả năng Reading tốt hơn nữa

12. Spotify (Ứng dụng nghe nhạc, podcast..)

Spotify là phần mềm âm nhạc kỹ thuật số cũng như các app nghe nhạc zingmp3, nhaccuatui.. Vậy điều gì khác biệt mà mình lại khuyến khích các bạn nên sử dụng. Vì dưới trải nghiệm của mình, đầu tư 59k/tháng cho Spotify là một trong những đầu tư xứng đáng hơn cả giá trị của nó

Cách sử dụng: Mình tự tạo nhiều playlist từ kho cả triệu bài hát dữ liệu của Spotify, ví dụ có thể kể đến như mình tạo playlist nhạc Lofi để nghe khi đọc sách và học tập, nhạc để thiền, nhạc để dành cho tập thể dục và đặc biệt ở đây chính mình còn có một kho các kênh Podcast đểmình nghe trong các khoảng thời gian chết, vừa multi-task để nâng cao kiến thức, ngoại ngữ, vừa tối ưu hóa thời gian (ví dụ khi di chuyển bằng xe bus-xe máy, làm việc nhà, chạy bộ...).

Các nguồn Podcast hiện tại mình follow trên Spotify dành cho các bạn tham khảo (copy link) https://bit.ly/mypodcast-tyler

13. Youtube (Ứng dụng giải trí và học tập điều mới)

Vì sao mình đưa Youtube vào các app phát triển bản thân??? Mình đã từng thấy bài viết của một số bạn trên đây có nói chọn lọc trong việc giải trí không những giúp bạn giải tỏa stress còn có thể nâng cao kiến thức cho bạn. Mình hoàn toàn đồng ý và ủng hộ ý tưởng đó. Thú thật với mọi người, trong thời còn học sinh viên, mặc dù có nhận thức về việc quản lý thời gian, nhưng đôi khi mình cũng mắc sai lầm và từng đốt rất rất nhiều thời gian để xem các chương trình giải trí không mang lại giá trị nhừ hài hoặc gameshow, lúc đó vì ghiề nên mình quên mất khái niệm thời gian và khi nhìn lại thời gian thì thấy đã trôi qua rất xa rồi. Lúc đó mình càng cảm thấy nuối tiếc và đôi khi stress hơn nữa

Từ sự kiện đó, mindset mình về youtube mình hoàn toàn thay đổi. Mình đã unsubscribe toàn bộ các kênh giải trí, ko xem hài hay gameshow (đỡ tốn thời gian vô ích) và unsubscibe hầu hết các kênh nói tiếng Việt và mình chuyển sang channel nước ngoài, vừa xem Youtube vừa luyện ngoại ngữ và học thêm các khía cạnh mới.

Cách sử dụng cá nhân: Tiêu chí kênh khi đó của mình vừa xem vừa học. Vì mình học engineering, nên mình chỉ follow các kênh có khía cạnh mới so với mình như tài chính, kinh tế, đầu tư, kinh doanh, phát triển bản thân, workout, dinh dưỡng từ các Youtuber nước ngoài, chỉ vài kênh người Việt.

• Cá nhân, mình highly recommend các bạn nên ngay lập tức subscribe các channel siêu hay về self-development (5sao): Cá nhân, mình highly recommend các bạn nên ngay lập tức subscribe các channel siêu hay về self-development (5sao): Ali Abdaal, Matt D'Avella, Thomas Frank, Mitch Manly, Lavendaire, Better Ideas..... Các kênh khác mọi người có thể xem trong database phía dưới

• Dưới đây là database toàn bộ các kênh mình đang follow (có phân chia theo category lẫn link cụ thể) dành cho mọi người tham khảo nghen: https://bit.ly/myyoutube-tyler

14. Lumosity (Game giải trí và tăng trí tuệ)

Đây là game duy nhất trên điện thoại của mình. Mình đã hoàn toàn bỏ game từ cuối năm lớp 11 cho tới hiện tại, game trên máy tính lẫn game trên điện thoại. Cá nhân mình nghĩ nếu có tốn thời gian chơi game thì ít nhất nó cũng phải mang một giá trị gì đó cho mình.

Vì thế mình lựa chọn Lumosity - app bao gồm các trò chơi tuyên bố cải thiện trí nhớ, sự chú ý, tính linh hoạt, tốc độ xử lý và giải quyết vấn đề. Ít nhất một mũi tên trúng được 2 con nhạn, vừa giải trí xả stress vừa luyện thêm 1 skill gì đó. Các trò chơi ở đây kiểu như là để hack não, để nâng cấp level của não bộ cũng như các giác quan khác như mắt và tay. Các bạn down về chơi thử, vì mình không mua gói premium (hơi mắc so với mình) nên một ngày mình chỉ chơi được vài game để giải trí và hơn thế nữa đó là không sợ nghiện.

Tổng kết

Phía trên là toàn bộ sharing của mình trong quá trình xây dựng hệ thống phát triển bản thân cá nhân. Nếu các bạn chịu khó đọc đến cuối bài viết của mình, chứng tỏ các bạn đang có khát khao tối ưu hoá bản thân của bạn mạnh mẽ và nồng cháy. Mình hi vọng có thể giúp ích một chút gì đó cho con đường thành công của các bạn. Mình xin vô cùng cám ơn và chúc các bạn thành công trên con đường của mình. phía trên là toàn bộ sharing của mình trong quá trình xây dựng hệ thống phát triển bản thân cá nhân. Nếu các bạn chịu khó đọc đến cuối bài viết của mình, chứng tỏ các bạn đang có khát khao tối ưu hoác bản thân của bạn mạnh mẽ và nồng cháy. Mình hi vọng có thể giúp ích một chút gì đó cho con đường thành công của các bạn. Mình xin vô cùng cám ơn và chúc các bạn thành công trên con đường của mình.

RẤT QUAN TRỌNG: Và hơn thế nữa, các bạn hãy thử một trong các ứng dụng để xây dựng cho mình các thói quen và lối sống tốt mà mình đã đề cập phía trên, lặp lại hàng ngày trong vòng ít nhất 1 tháng và chia sẻ với mình cuộc sống của bạn đã thay đổi như thế nào. Mình rất nóng lòng muốn nghe trải nghiệm của bạn! Peace :)

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

Công ty “6 tháng” là nơi đầu tiên mình làm trong lĩnh vực IT sau khi chuyển ngành. Mình vào vai Business Analyst (BA) kiêm Project Management cho một công ty domain ERP.

Domain siêu khó. Lúc đó, mình vừa phải học mọi thứ về ERP từ số 0, vừa phải tự rèn các kỹ năng liên quan đến BA. Từ học tính năng trong phần mềm ERP, phân tích nghiệp vụ, vẽ flow, tới hỏi khách hàng sao cho đúng, triển khai hệ thống… Kết quả là mình "ngụp lặn" toàn tập. Mỗi ngày đều giống như đang bơi mà không biết bờ ở đâu. Tối về stress, cuối tuần cũng stress. Pass probation, nhưng là kiểu “đã cố gồng hết sức chớ không dễ dàng gì”. → Cảm giác này kéo dài thì chắc mình dễ burnout từ bị thương tới c.h.ế.t.

Công ty “1 tháng” là một fintech, nơi mình làm Product.

Domain cũng khó, đều là những khái niệm mới, hệ thống to, dính tới dữ liệu người dùng, API, đối tác… Nhưng không hiểu sao mình thấy hợp vibe.

Cảm giác vẫn “bơi”, nhưng là bơi trong ý thức. Biết mình đang học gì, thấy được logic đằng sau các flow. Có “chút” hoảng loạn trong tầm kiểm soát, không overthinking. Và chỉ sau 4-5 tuần, mình và team đều ngầm hiểu: “mình sẽ ổn thôi”. → Cảm giác này giúp mình đi xa hơn và tự tin hơn rất nhiều.

Mình nhận ra không phải cứ domain khó là sẽ “đuối”. Có những lĩnh vực dù khó nhưng mình thấy… thích. Tò mò. Hợp cách suy nghĩ. Vào là “bắt sóng” được liền (trộm zía). Cho nên chọn domain lúc chọn job rất quan trọng (hiuhiu). Và probation không chỉ là lúc công ty đánh giá mình. Mà còn là lúc mình tự nghiệm rất nhiều về chính mình luôn.

Yeah anyway, nếu bạn đang probation (khi đọc bài này)

• Reflect xem bạn đang “bơi” kiểu gì?

• Môi trường xung quanh có giúp bạn “bơi” không?

• Bạn có thấy bản thân đang tiến bộ mỗi ngày không?

Bạn có trải nghiệm probation nào ấn tượng không, thử chia sẻ bên dưới. Vì biết đâu, trải nghiệm của bạn sẽ là động lực cho một ai đó đang vật lộn những tuần đầu đi làm.

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

Có nhiều lý do để mình ngồi xuống và viết lại thành bài hoàn chỉnh:

1.Lý do đầu tiên là để lưu trữ. Mình viết lại bài này, một phần là cho người khác, nhưng phần lớn là cho chính mình. Làm product có quá nhiều thứ vụt qua mỗi tuần, nào là backlog, bug, tradeoff, meeting,..mà nếu không ghi lại thì sau vài tháng hay thậm chí vài tuần, vài ngày là sẽ quên sạch. Đây là cách mình giữ lại trải nghiệm, giữ lại những gì đã từng làm. Biết đâu vài năm nữa, lúc ngồi cà phê đọc lại, mình sẽ thấy: “À hồi đó mình cũng làm được kha khá thứ ghê đó chứ!”

2.Lý do thứ hai là… thói quen “làm product”. Cuối buổi thuyết trình, mình có hỏi người nghe một câu rất PM:

“If this presentation were a product, how would you rate it?”

Kết quả khảo sát như sau:

• 10% chấm 7/10

• 15% chấm 8/10

• 50% chấm 9/10

• 25% chấm 10/10

Trước buổi guest lecture, mình có hơi tham vọng đặt kỳ vọng là không có điểm 7. Nhưng nhìn vào thực tế thì.. Điều này nghĩa là vẫn còn người dùng “chưa hiểu rõ” hoặc chưa hài lòng hoàn toàn. Mà nếu sản phẩm chưa tốt thì… iterate lại thôi. Bản viết này là bản cải tiến. Dành cho bạn nào muốn đọc kỹ lại, hoặc hôm đó chưa nghe trọn vẹn.

3.Lý do thứ ba là để chia sẻ cho cộng đồng những người chuyển ngành (như mình ngày xưa) hoặc là những người tò mò về Fintech.
Mình còn nhớ hồi đầu đang chập chững bước chân vào ngành product, mình rất thích những bài viết kiểu case study: làm tính năng gì, gặp vấn đề gì, giải quyết ra sao, học được gì. Vì lý thuyết thì dễ quên, còn chuyện thật việc thật thì đọng lại lâu hơn nhiều. Vậy nên, trong đây là một câu chuyện thật, từ một tính năng thật, với đủ thứ thật: Onboarding flow, eKYC, Credit scoring, API integration, Golive, Pilot test, Edge case handling,.. và những câu hỏi không có câu trả lời đúng tuyệt đối. Let’s dive in.

Lưu ý nhẹ trước khi đọc: 
>> Nếu chia làm sản phẩm thành hai phần lớn là Discovery và Delivery, thì bài viết này sẽ tập trung chủ yếu vào phần Delivery, tức là giai đoạn triển khai tính năng, làm việc với stakeholder như FrontEnd, Back end dev, xử lý edge case... 
>> Ngoài ra, một số chi tiết đã được điều chỉnh hoặc viết lại theo hướng tổng quát để tránh tiết lộ thông tin quá nhạy cảm hoặc vi phạm NDA. Mong bạn thông cảm nếu đôi chỗ nghe hơi “trừu tượng”. Nhưng về bản chất thì flow, cách làm và bài học rút ra đều là thật.

1.Bối cảnh & Bài toán kinh doanh

Giả sử có một cửa hàng số (Digital Store) - kiểu như một sàn thương mại điện tử - muốn triển khai thêm một dịch vụ tài chính cho phép khách hàng mua hàng trước, trả tiền sau bên cạnh hình thức mua hàng thông thường. Để sử dụng dịch vụ này, khách hàng sẽ cần đi qua một quy trình gọi là Onboarding flow, nơi cửa hàng đánh giá sơ bộ về "nhân thân" và khả năng tín dụng (Credit Scoring-mô hình chấm điểm tín dụng gồm nhiều biến) của người đó, trước khi quyết định có cấp quyền sử dụng hay không

Một cửa hàng số có thể nhìn vào hành vi tiêu dùng của người dùng: họ mua gì, bao lâu mua một lần, mua vào dịp nào, mua bao nhiêu lần, mỗi lần mua với hoá đơn bao nhiêu tiền và từ đó xây dựng một mô hình đánh giá tín dụng “cây nhà lá vườn”. Mô hình này sẽ giúp cửa hàng tự chấm điểm người dùng theo mức độ rủi ro (điểm tín dụng nội bộ của Hệ thống quản lý rủi ro nội bộ - Risk Management Systems). Và tất nhiên, điểm tín dụng nội bộ càng cao thì khả năng được duyệt dùng dịch vụ tài chính càng lớn. Quay lại câu chuyện này, để đánh giá rủi ro tín dụng trong quy trình xét duyệt, cửa hàng có thể tạm phân nhóm người dùng hiện có thành 3 nhóm chính:

1. Low-risk users: Thường xuyên mua hàng (>5 lần) → có lịch sử tiêu dùng tốt → được xem là đáng tin cậy.

1. Medium-risk users: Mua hàng ở mức độ trung bình (>3 lần) → có tín hiệu nhưng chưa đủ rõ ràng.

2. High-risk users: Chưa mua hàng hoặc mới chỉ mua 1–2 lần → thiếu dữ liệu lịch sử → được xem là nhóm rủi ro cao.

Việc phân nhóm này không chỉ phục vụ mục đích phân tích, mà còn ảnh hưởng trực tiếp đến quyết định có duyệt cho khách hàng sử dụng dịch vụ tài chính hay không.

→ Vấn đề: Tỉ lệ được duyệt rất thấp ( ví dụ ~50%) trong Onboarding Flow. Nguyên nhân chính là thiếu thông tin về khách hàng, đặc biệt với nhóm Medium-risk users và High-risk users.

2.Onboarding Flow

Tương ứng với với các màn hình, mình visualization (mô hình hoá)

Thien Nguyen Produck

Technical Foundations for PMs: [TechPM#2] System Thinking, Visualization & Diagrams 101

(Nếu bạn lần đầu đến với blog mình…

Read more

9 months ago · 8 likes · Thien Nguyen

Trước khi đi sâu vào phần giải pháp cải thiện tỉ lệ duyệt thì chúng mình cùng đi lướt qua một vòng toàn cảnh về luồng Onboarding. Đây vẫn là nơi bắt đầu tất cả mọi thứ. Nếu người dùng không đi qua được bước này, họ không thể sử dụng dịch vụ tài chính. Và nếu luồng này không đủ tốt, thì tỉ lệ duyệt sẽ mãi ở mức thấp.

Đây một ví dụ minh hoạ cho một onboarding flow điển hình trong Fintech (hoặc kể cả Banking) từ lúc người dùng bắt đầu đến lúc hoàn tất định danh khách hàng (eKYC). Lưu ý: Thứ tự và công nghệ ở từng bước có thể khác nhau tùy từng công ty/tổ chức tài chính. Nhưng đa phần đều đi qua những bước chính như: xác minh danh tính, xác thực thông tin, bổ sung dữ liệu, xác nhận đồng ý.

pic0: Bất cứ điểm chạm nào để vào được luồng Onboarding.

pic1: Landing Page: Trang giới thiệu tính năng & xác nhận bắt đầu

pic2: Trang hướng dẫn thực hiện xác minh khuôn mặt

pic3: Bật camera để Liveness check. Đưa mặt vào khung để hệ thống chụp và nhận diện

Liveness check: một bước trong quy trình eKYC, công nghệ giúp hệ thống xác định xem người đang thực hiện định danh có thực sự “sống” và có mặt tại thời điểm đó hay không (nó giúp ngăn người dùng dùng ảnh in, video quay lại khuôn mặt, hoặc mặt nạ 3D để đánh lừa hệ thống). Cấm khuôn mặt bị che khuất hoặc nhắm mắt hoặc deepfake.. Liveness check level cao cấp có thể yêu cầu một số hành động như chuyển động mắt, chớp mắt, nghiêng trái, nghiêng phải, gật đầu,…

eKYC (Electronic Know Your Customer): quy trình số hóa (digital) xác minh danh tính khách hàng nhằm phòng chống rửa tiền, tài trợ khủng bố và bất kỳ hành vi gian lận tài chính. Bây giờ, eKYC cho phép người dùng thực hiện toàn bộ quy trình định danh ngay trên điện thoại hoặc máy tính, thay vì cách truyền thống là đến bất kỳ văn phòng offline nào.

pic4: Chụp mặt trước & sau Căn cước công dân (CCCD) / Quét ảnh QR Code (mặt trước nếu CCCD trước 1/7/2024 hoặc mặt sau nếu CCCD sau 1/7/2024) / Chụp đoạn mã MRZ (mặt sau CCCD). Một trong 3 cách trên sẽ khác nhau theo từng tổ chức tài chính. Nhưng mục đích chung là có thể lấy được những thông tin cơ bản của khách hàng trước khi thực hiện đến bước xác thực danh tính phía sau:

Chụp mặt trước & sau CCCD: Khách hàng thực hiện 2 bước. Sau đó hệ thống dùng công nghệ OCR (Optical Character Recognition) tự động đọc và trích xuất thông tin (số định danh, họ tên, ngày sinh, địa chỉ,…) từ 2 hình ảnh mặt trước / sau CCCD đó. Giúp tăng tốc độ xử lý và hạn chế sai sót khi nhập liệu thủ công.

Quét ảnh QR Code (mặt trước nếu CCCD trước 1/7/2024 hoặc mặt sau nếu CCCD sau 1/7/2024) → bạn có thử dùng phần mềm QR Creator: Scan and Make QRCode thử quét QR code trên CCCD của bạn. Nó sẽ ra một dãy text có dạng: Số CCCD|Số CMND|Tên|Ngày sinh|Giới tính|Địa chỉ thường trú|Ngày phát hành CCCD

Chụp đoạn mã MRZ (mặt sau CCCD) → tương tự sau khi quét ta cũng cũng thu đượccác thông tin cơ bản

pic5: Xác thực thông tin sinh trắc học bằng hardware (chạm mặt chip trên CCCD vào thiết bị di động) hoặc bằng software (jump sang ứng dụng VNeID). Cả 2 cách, thông tin sinh trắc học (Biometrics) của khách hàng đều sẽ đi đối chiếu trực tiếp với dữ liệu của Nhà nước / Bộ Công An.

NFC (Near Field Communication) là công nghệ kết nối không dây tầm ngắn, cho phép giao tiếp giữa hai thiết bị đặt gần nhau, thường là dưới 4cm.

VNeID: Hệ thống định danh điện tử của Việt Nam.

Ở bước này, đôi khi hệ thống đã dùng Face Matching: công nghệ so sánh khuôn mặt của người dùng trong video/selfie với ảnh chân dung trên giấy tờ tùy thân. Đây là một bước không thể thiếu trong eKYC, góp phần tăng độ chính xác và giảm rủi ro gian lận danh tính.

pic6: Hiển thị thông tin cá nhân từ chip NFC CCCD để khách hàng xác nhận

pic7: Khách hàng điền thêm thông tin liên hệ (tên người thân, số điện thoại …) trong trường hợp các tổ chức tài chính cần liên hệ (hay nói dân dã hơn là trong trường hợp thu hồi nợ - debt collection)

pic8: Nhập mã OTP để e-Signature (chữ ký điện tử). Hoàn tất quy trình Onboarding

e-Signature (chữ ký điện tử): cho phép khách hàng ký online vào các hợp đồng, cam kết hoặc giấy tờ pháp lý khi mở tài khoản hoặc sử dụng dịch vụ tài chính, mà không cần in ra hay gặp mặt trực tiếp. Có giá trị tương đương với chữ ký tay, nếu được xác thực và lưu trữ đúng chuẩn

OTP có thể gửi qua tin nhắn SMS (SMS OTP) hoặc qua cuộc gọi thoại (Voice OTP)

pic9: Trang hiển thị kết quả xét duyệt quyền sử dụng dịch vụ (Approve, Reject, Pending)

3. Mục tiêu & Chiến lược giải quyết

Quay trở lại về mục tiêu và giải pháp cho bài toán tăng tỉ lệ duyệt dịch vụ tài chính

Ví dụ: Mục tiêu của dự án rất cụ thể: nâng tỷ lệ duyệt dịch vụ tài chính trong luồng onboarding từ 50% lên 70%.

Để đạt được điều đó, chúng mình đặt câu hỏi ngược lại:

• Làm thế nào (How)? → Cần thu thập thêm thông tin về khách hàng.

• Thông tin gì (What)? → Những dữ liệu có thể giúp đánh giá rủi ro tín dụng chính xác hơn.

• Lấy từ đâu (Where)? → Có hai nguồn khả dĩ:

  1. Từ bên thứ ba, ví dụ như tích hợp với các tổ chức chấm điểm tín dụng

  2. Từ chính khách hàng, thông qua việc upload thêm giấy tờ như sao kê lương, chứng minh thu nhập,…

Từ đó, chúng mình đưa ra hai hướng giải pháp chính:

• Option 1: Tích hợp với bên thứ ba để lấy thông tin tín dụng một cách tự động và thuận tiện.

• Option 2: Yêu cầu người dùng cung cấp thêm tài liệu chứng minh năng lực tài chính.

Cả hai hướng đều khả thi, nhưng mỗi bên có trade-off riêng về trải nghiệm người dùng, effort kỹ thuật và độ tin cậy của dữ liệu. Khi cân nhắc giữa hai phương án, thì team mình buộc phải đặt ra câu hỏi: hướng nào khả thi hơn, ít friction hơn cho người dùng?

Phương án yêu cầu người dùng upload giấy tờ (như sao kê lương, hợp đồng lao động…) nghe có vẻ đơn giản, nhưng thực tế lại gây ra nhiều rào cản:

• Người dùng có thể không đủ tin tưởng để chia sẻ thông tin tài chính cá nhân với một cửa hàng số.

• Việc phải đi tìm file, chụp ảnh, upload… cũng tăng nguy cơ bỏ cuộc giữa chừng (drop off luồng) .

Trong khi đó, nếu chọn tích hợp với bên thứ ba:

• Người dùng không cần thao tác thêm, hệ thống sẽ tự động lấy dữ liệu sau khi được họ đồng ý.

• Trải nghiệm người dùng liền mạch hơn, vẫn đảm bảo bảo mật và minh bạch.

→ Sau khi trao đổi và đánh giá cùng team, tụi mình quyết định chọn phương án tích hợp với bên thứ ba là hướng triển khai chính – vừa khả thi, vừa tối ưu trải nghiệm.

4.Một số tổ chức chấm điểm tín dụng

Khi đã quyết định chọn phương án tích hợp bên thứ ba để thu thập thêm thông tin tín dụng, bước tiếp theo là đánh giá xem nên kết nối với đơn vị nào. Vì mỗi tổ chức sẽ có nguồn dữ liệu, cách truy cập và điều kiện pháp lý khác nhau. Dưới đây là một số tổ chức cung cấp dữ liệu tín dụng phổ biến:

1. CIC (Credit Information Center): là Trung tâm Thông tin Tín dụng Quốc gia trực thuộc Ngân hàng Nhà nước. CIC tổng hợp dữ liệu tín dụng của gần như tất cả các ngân hàng và tổ chức tài chính tại Việt Nam. Muốn truy cập dữ liệu CIC, thường phải đi thông qua ngân hàng.

2. PCB (Private Credit Bureau): là công ty cổ phần cung cấp thông tin tín dụng, được liên danh giữa nhiều ngân hàng lớn như Vietcombank, VietinBank,… Dữ liệu từ PCB chủ yếu cũng lấy từ hệ thống của các ngân hàng thành viên, và tương tự như CIC, cần tích hợp gián tiếp thông qua ngân hàng.

3. Trusting Social: Một công ty chuyên cung cấp các giải pháp chấm điểm tín dụng, định danh và hỗ trợ mở rộng khách hàng dựa trên trí tuệ nhân tạo (AI). Tạo ra mô hình đánh giá tín dụng cho nhóm người chưa từng vay vốn trước đây (underbanked or unbanked)

4. DataNest: Cung cấp thông tin tín dụng dựa trên dữ liệu viễn thông

5. KCI (Red Information): Là một tổ chức mới trong lĩnh vực đánh giá tín dụng cá nhân, tập trung vào phân tích dữ liệu thay thế (alternative data).

Sau khi phân tích các lựa chọn, team mình sẽ chọn một trong các bên này để tích hợp vào luồng Onboarding, với mục tiêu bổ sung dữ liệu tín dụng cho những user có rủi ro cao từ đó nâng cao khả năng xét duyệt, mà không làm gián đoạn trải nghiệm người dùng (vì lý do bảo mật nên mình sẽ không thể nói rõ là sẽ tích hợp với tổ chức cụ thể nào)

5. Chi tiết tính năng

5.1 High level design-Logic hoạt động (for all stakeholders)

Sau khi thiết kế lại luồng onboarding và xác định sẽ tích hợp thêm dữ liệu tín dụng từ bên thứ ba, bước tiếp theo là xác định logic hoạt động của hệ thống đánh giá. Kết hợp dữ liệu nội bộ và bên ngoài để ra quyết định duyệt

Cách làm của tụi mình là kết hợp giữa hai nguồn dữ liệu:

1. Dữ liệu hành vi mua sắm (có sẵn): Lịch sử mua hàng, tần suất giao dịch, loại sản phẩm đã mua…→ Từ đó hệ thống tự tính ra một điểm tín dụng nội bộ (internal credit score).

2. Dữ liệu tín dụng bên ngoài → Đây là điểm bổ sung cho các trường hợp mà dữ liệu nội bộ chưa đủ (cảm thấy "chưa đủ tin"), thêm dữ liệu từ bên ngoài để “tăng sáng” cho bức tranh đánh giá rủi ro.Và việc này giúp giảm thiểu từ chối sai (false negative), tránh trường hợp người có khả năng chi trả tốt lại bị từ chối chỉ vì thiếu lịch sử tiêu dùng nội bộ.

Ví dụ: Một khách hàng chỉ mới mua hàng 1–2 lần trên nền tảng (thuộc nhóm high-risk theo dữ liệu nội bộ), nhưng khi truy vấn thông tin từ bên thứ ba, hệ thống phát hiện người này có lịch sử tín dụng tốt tại ngân hàng A, trả nợ đúng hạn, không có nợ xấu.
→ Trong trường hợp này, tổng điểm tín dụng sau khi kết hợp lại đủ để chấp nhận người này vào sử dụng dịch vụ tài chính của Cửa hàng số.

Sau khi xác định sẽ kết hợp dữ liệu tín dụng từ bên thứ ba, câu hỏi tiếp theo là:
Tích hợp ở đâu trong luồng? Và người dùng sẽ trải nghiệm như thế nào?

Ở góc độ high-level, nếu đứng từ trên nhìn toàn bộ luồng Onboarding, bạn sẽ thấy rất nhiều điểm có thể “chen” vào. Nhưng với team mình, sau khi cân nhắc về mặt logic và trải nghiệm người dùng, tụi mình quyết định đặt bước tích hợp bên thứ ba vào giữa hai bước sau:

• Bước khách hàng điền thêm thông tin liên hệ (tên người thân, số điện thoại …)

• Bước khách hàng nhập mã OTP để e-Signature (chữ ký điện tử)

Lý do là vì:

• Đây là thời điểm người dùng đã cung cấp đủ thông tin nội bộ,

• Và Risk Management Systems (Risk engine) với thông tin người dùng đã nhập + lịch sử tiêu dùng sẵn có có thể đánh giá sơ bộ để quyết định có cần lấy thêm dữ liệu từ bên ngoài hay không. Kết quả chia làm 2 nhánh:

  • Người dùng đủ điều kiện (ví dụ đạt điểm A hoặc B) → Không cần làm gì thêm → Đi thẳng tới bước ký xác nhận và hoàn tất luồng.

  • Người dùng chưa đủ điểm (ví dụ điểm C) → Hệ thống quyết định gọi thêm thông tin từ bên thứ ba→ Nhưng trước khi gọi, phải có sự đồng ý từ người dùng.

Để tuân thủ pháp lý và đảm bảo minh bạch, tụi mình chèn thêm một bước hiển thị rõ ràng (tách riêng một màn hình) thông báo cho người dùng biết. Cũng như rất nhiều người dùng không đọc kỹ điều khoản, nên tụi mình thiết kế một màn hình riêng cho bước consent, thay vì nhồi chung vào bước “Điền thêm thông tin liên hệ”. Làm vậy vừa minh bạch, vừa tránh bị khiếu nại về sau.

“Để hoàn tất xét duyệt, chúng tôi cần thêm thông tin tín dụng của bạn từ một đơn vị đối tác đáng tin cậy. Bạn có đồng ý chia sẻ không?”

Người dùng có hai lựa chọn:

• Đồng ý (Yes) → Hệ thống gửi mã OTP để xác nhận việc chia sẻ dữ liệu → Sau khi xác thực xong, sẽ truy vấn điểm tín dụng từ bên thứ ba → Quay lại hệ thống của Cửa hàng số → Ra quyết định cuối cùng.

• Từ chối (No) → Người dùng quay lại flow chính, nhưng rất có thể sẽ bị từ chối dịch vụ do thiếu thông tin để đánh giá.

Subscribe now

5.2 FrontEnd / UI (for FE dev / designer)

Sau khi logic đã rõ, (bước xuống một bậc thang) tiếp theo là mapping thành các màn hình UI cụ thể, dành cho các bạn FE dev và designer:

1. Màn hình lấy consent người dùng
   Hiển thị thông báo: “Để hoàn tất xét duyệt, chúng tôi cần xin phép truy vấn điểm tín dụng của bạn từ đối tác. Bạn có đồng ý không?”

2. Nếu đồng ý → chuyển qua bước nhập OTP để xác nhận

3. Sau khi xác thực thành công → hệ thống tự động gọi API, lấy điểm tín dụng từ bên thứ ba

4. Nếu từ chối → bỏ qua, quay lại luồng chính (và khả năng bị từ chối cao)

5.3 BackEnd (for FE dev / BE dev)

Khi đã có luồng logic rõ ràng và thiết kế UI cụ thể, bước tiếp theo là làm sao để frontend giao tiếp được với backend, và hệ thống của mình giao tiếp được với bên thứ ba → Trước khi đi sâu mình xin nói sơ về API (cho những ai chưa biết)

API-Service-Database: Để một hệ thống backend hoạt động mượt mà và có thể giao tiếp được với frontend hay các hệ thống bên ngoài, cần hiểu ba thành phần chính sau:

• API là cầu nối trung gian giữa các phần mềm, hệ thống hoặc thiết bị, cho phép chúng giao tiếp với nhau một cách. Nói nôm na, API giống như “menu trong nhà hàng” – bạn không cần vào bếp, chỉ cần gọi đúng món → bếp (backend) sẽ nấu → mang ra cho bạn.

• Service là nơi chứa các đoạn logic xử lý chính trong backend. Mỗi API khi được gọi sẽ đi qua các service này để tính toán, kiểm tra, xử lý dữ liệu,.. trước khi trả về kết quả. Với những hệ thống lớn, các service thường được tách nhỏ thành microservice-là các module độc lập, có thể chạy riêng, deploy riêng, scale riêng.

• Cuối cùng, dữ liệu cần được lưu lại ở đâu đó → Database. Service sẽ truy vấn database để: Lấy dữ liệu (read), Cập nhật / thêm mới (write), Xoá hoặc xử lý dữ liệu (delete, archive,…)

Client side - Server side. Góc nhìn hệ thống đơn giản:

• Client (ứng dụng trên điện thoại, laptop, browser…) sẽ gửi yêu cầu (request),

• Server sẽ xử lý và trả về kết quả (response).

→ Hoặc sau bài Fintech101, bạn có thể đọc thêm về bài viết APIs101 của mình tại đây:

Thien Nguyen Produck

Technical Foundations for PMs: [TechPM#1] API Basics

Hey everyone !! Mình là Thiện, làm product ở một công ty fintech, sản phẩm mình đang phụ trách là ví trả sau của một sàn thương mại điện tử (mọi người có thể hình dung đơn giản mô hình ví trả sau này là sản phẩm B2B2C với phần B2B ở đây là với các đối tác ngân hàng, B2C là đối với người dùng cuối của sàn). Với vị trí product ở công ty này, mình đang phả…

Read more

a year ago · 26 likes · 3 comments · Thien Nguyen

Luồng của mình sẽ cần nhiều API, chia làm 2 nhóm:

1. API nội bộ (của Digital Store) kết nối giữa frontend và backend hệ thống của chính mình. Ví dụ: gọi API để gửi OTP, xác nhận số điện thoại, hiển thị kết quả xét duyệt...

2. API tích hợp bên thứ ba: nơi backend của mình gọi tới hệ thống của đối tác (ví dụ CIC, Trusting Social, ngân hàng..)

Khi luồng logic đã rõ và API đã được xác định, bước tiếp theo là diễn tả chi tiết các bước giao tiếp giữa hệ thống của mình và đối tác thứ ba. Đây là lúc mình cần đến mô hình hoá Sequence Diagram. Sequence diagram là một loại sơ đồ mô tả chuỗi tương tác giữa các hệ thống (hoặc thành phần trong hệ thống) theo trật tự thời gian. Đây là công cụ cực kỳ hữu ích, đặc biệt trong những domain có nhiều hệ thống giao tiếp phức tạp như Fintech.

Trong thực tế, mỗi lần bạn làm việc với backend dev, hoặc phải explain cho một tech stakeholder, bạn sẽ rất dễ “lost in translation” nếu chỉ nói miệng hoặc viết bằng word. Sequence Diagram giúp:

• Biết ai gọi ai, ai gửi ai nhận, API này trigger khi nào

• Phản hồi về ra sao?

• Cần chờ, xác nhận, hay xử lý gì?

• Dễ visualize các bước và xử lý các edge case sau này

Sơ đồ vẽ đúng còn có thể tiết kiệm hàng giờ thảo luận và hàng tuần debugging.

Tùy vào công ty, ai phụ trách vẽ những sơ đồ này:

• BA (Business Analyst): nếu có team rõ ràng và tách biệt vai trò.

• PM/Product: nếu làm ở công ty thiên lean/agile hoặc team nhỏ

• Với team mình thì: Mình, với vai trò là Product phụ trách luôn phần này, từ high-level flow đến sequence diagram kỹ thuật.

Luồng cụ thể. Giả sử người dùng đã bấm “Đồng ý chia sẻ dữ liệu”, thì backend của hệ thống của Digital Store sẽ thực hiện luồng API step-by-step như sau:

1. API Authentication→ Gửi yêu cầu lấy token truy cập tới hệ thống bên thứ ba → Nhận về access token

2. API Send OTP → Dùng token vừa lấy được để gọi API gửi OTP → Bên thứ ba gửi tin nhắn OTP đến điện thoại người dùng

3. API Verify OTP → Người dùng nhập mã OTP → Backend gọi API verify để xác nhận mã chính xác → Nếu thành công → bước tiếp theo

4. API Get Credit Info → Sau khi OTP được xác thực, hệ thống của mình gọi API để lấy dữ liệu tín dụng từ bên thứ ba → Kết quả sẽ được backend xử lý và đưa ra quyết định duyệt hay không

5.4 BackEnd - Integrate (for BE dev)

Sau khi đã có:

• Bức tranh tổng thể (onboarding flow + integration point)

• Sequence Diagram (thể hiện từng bước giao tiếp)

• Các API dự kiến sẽ gọi

→ Bước tiếp theo là đào sâu hơn vào phần tích hợp thực tế giữa hệ thống của mình và hệ thống bên thứ ba.

Ở phần này, mình sẽ:

• Làm rõ từng API request: gửi gì, nhận gì, định dạng ra sao

• Định nghĩa timeout, retry, error-handling logic

• Document chi tiết các field, validation, mã hóa, chữ ký số nếu có

• Đảm bảo các ràng buộc bảo mật, đặc biệt với dữ liệu người dùng

Đây là phần mà giao tiếp giữa PM/BA với backend dev cần càng rõ ràng càng tốt, vì nếu mơ hồ bước nào là rất dễ sai bước đó.

Mình thường highlight một số phần quan trọng như sau để tránh dev dễ làm sai, tốn thời gian test & debug, chậm tích hợp:

Documentation kỹ thuật: Càng rõ càng tốt

1. API Endpoint
+ Ghi rõ URL của API (có thể là bản staging và production).
+ Phải phân biệt non-live (môi trường test) và live (môi trường thật) để tránh việc test sai môi trường gây sự cố sản phẩm.

2. API Description
+ Mô tả chức năng của từng API.Ví dụ: POST /send-otp dùng để yêu cầu đối tác gửi mã OTP đến số điện thoại người dùng.

3. HTTP Method. Ghi rõ phương thức: POST, GET, PUT, DELETE
Hầu hết các API tương tác với bên thứ ba (gửi OTP, xác thực, lấy thông tin...) đều là POST.

4. Request / Response Structure
+ Phần này rất quan trọng, đặc biệt khi có validate format hoặc yêu cầu mã hóa. 

+ Ví dụ với field phone_number:
> Format bắt buộc: Phải đủ 10 chữ số, bắt đầu bằng 84 (thay vì 0)
> Yêu cầu: Nếu phía frontend trả về 0901234567, backend phải convert thành 84901234567 trước khi gửi qua partner.

+ Dữ liệu cần được encode/mã hóa theo định dạng nào (nếu có)

5. Encryption & Signature
+ Encryption: Trường nào cần mã hóa? Dùng phương pháp gì? (RSA, AES, base64…)

+ Signature: Có yêu cầu ký request không? Nếu có:
> Chuỗi để ký gồm những phần nào?
> Cách tạo hash/signature?
> Đây là lớp bảo vệ quan trọng đảm bảo dữ liệu người dùng không bị giả mạo hoặc đánh cắp khi gửi qua bên thứ ba.

Subscribe now

5.5 BackEnd - Error Code Handling (for BE dev)

→ Happy Case thì dễ, Edge case mới là bài “kiểm tra” thật

Vì khi hệ thống chạy “happy case”. Mọi thứ đều đúng, server trả về httpStatus 200 OK, dữ liệu hợp lệ, thì quá trình gần như “trơn tru và dễ chịu”. Nhưng khi mọi thứ không như kỳ vọng, mạng chập chờn, dữ liệu sai định dạng, OTP nhập sai, timeout, app crash, user thoát giữa chừng.. thì mới thấy được hệ thống thật sự có ổn hay không. Xử lý lỗi (error code handling) luôn là phần "nặng đô", phải chuẩn bị trước từng API của đối tác trả mã lỗi thế này thì hệ thống mình xử lý như thế nào. Team mình thường làm bảng tổng hợp theo từng API (như hình).

Ví dụ team mình cũng cần set các SLA cụ thể cho từng API. Nếu tổng thời gian cho cả flow chỉ khoảng 5–6s (theo SLA định sẵn), thì ví dụ Auth Token mất 4s → toàn bộ flow phải skip luôn, không được tiếp tục gọi API khác nữa. Tránh làm người dùng chờ đợi không lý do.

Không chỉ các lỗi từ hệ thống, mà còn những tình huống từ người dùng ("khó đỡ" nhưng cũng cần cover)

• Đang nhập OTP thì điện thoại hết pin

• App bị force quit hoặc crash giữa chừng

• Người dùng thoát app rồi quay lại

Với những case này, mình phải xác định:

• Trạng thái luồng có được lưu lại không?

• Khi quay lại, người dùng bắt đầu từ đâu? Có cần consent lại không? Có phải gửi lại OTP không?

Một PM giỏi không chỉ viết flow đẹp, mà còn phải lường trước điều xấu (edge case) có thể xảy ra ở thời điểm ban đầu (giúp cho Dev & QA hạn chế tốn kém thời gian fix lỗi về sau)

5.6 Golive / Pilot / Greyscale (for Business, Risk, BE dev)

Sau khi hoàn tất thiết kế, dev, test và review tất cả flow từ UI đến API, từ logic đến error handling tính năng đã sẵn sàng được đưa ra thực tế. Nhưng triển khai ngay 100% cho toàn bộ người dùng thì quá mạo hiểm.

Thay vào đó, mình tiến hành theo đúng tinh thần "test-and-learn"→ Go live theo mô hình pilot, chạy thử với một nhóm nhỏ người dùng. Để kiểm chứng tính năng tích hợp bên thứ ba giúp cải thiện tỷ lệ duyệt, mình chia user làm 2 nhóm:

• Treatment group → Nhóm user đi qua luồng mới, có tích hợp gọi thông tin tín dụng từ bên thứ ba.

• Control group → Nhóm user vẫn đi qua luồng cũ, không có thay đổi gì.

Cả hai nhóm đều thuộc cùng một phân khúc, ví dụ như nhóm high-risk users tức là những người vốn dĩ hay bị từ chối do thiếu thông tin → Mục tiêu: So sánh trực tiếp hiệu quả giữa luồng cũ và luồng mới, xem luồng mới có cải thiện tỷ lệ duyệt hay không.

Sau một thời gian chạy pilot, mình sẽ tổng hợp số liệu để đánh giá:

• Nếu kết quả tốt → Tỷ lệ duyệt tăng như kỳ vọng, không phát sinh lỗi, trải nghiệm user ổn → Triển khai 100% toàn bộ user.

• Nếu kết quả không như mong đợi → Ví dụ: user có điểm tín dụng tốt nhưng vẫn bị reject, hoặc flow quá chậm khiến user bỏ giữa chừng → Dừng rollout, bắt đầu deep-dive phân tích nguyên nhân, có thể cần:

  • Điều chỉnh logic risk engine

  • Thay đổi ngưỡng điểm xét duyệt

  • Hoặc tệ nhất: quay lại luồng cũ (rollback) → uổng phí nguồn lực (tiền bạc + con người)

6. Một vài bài học của riêng mình

• Discovery hay là một chuyện, nhưng Delivery cũng là nơi "chết người" nếu bạn không đủ sâu sát. Delivery tốt → Discovery dễ hơn. Biết hệ thống giới hạn đến đâu, đánh giá tính khả thi của chiến lược ngay từ đầu.

• Hiểu tech không giúp bạn code nhưng giúp bạn giải quyết vấn đề và nói cùng ngôn ngữ với dev dễ build được trust → làm việc hiệu quả và dễ hơn.

• Làm Product, đặc biệt là trong Fintech, không hề dễ. Không có "best practice" duy nhất cho mọi tình huống.

Lời kết

Nếu bạn đã đọc đến đây, cảm ơn vì đã đồng hành cùng một bài viết có thể xem như "step-by-step" trong việc xây dựng một tính năng thực tế trong Fintech. Hy vọng case study nhỏ này giúp bạn hình dung rõ hơn về bức tranh thực tế phía sau một dòng thông báo tưởng như đơn giản: “Dịch vụ tài chính của bạn đã được phê duyệt.”

And again again. Một câu hỏi rất PM như thường lệ.

“If this article were a product, how would you rate it? In the scale 1 to 10 (if 1 is the worst and 10 is the best)”

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!

Bạn hãy để lại comment hoặc anything cho mình biết nhé👇. Peace !

Còn bạn muốn coi video, thì link ở đây nhen: