Technical Foundations for PMs: [TechPM#2] System Thinking, Visualization & Diagrams 101
System Thinking và Visualization (with Diagram) là hai "vũ khí" mà mình giúp mình sống sót trong hành trình làm product
(Nếu bạn lần đầu đến với blog mình)
Hey. How are you doing ! Mình là Thiện, đang làm Product ở một công ty Fintech.
Disclaimer:
+ Mình sẽ sử dụng xen lẫn giữa tiếng Anh và tiếng Việt vì đôi khi đây là thói quen hằng ngày trong công việc lẫn cuộc sống (các bạn thông cảm bỏ qua). Cũng như mình thấy 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 google hoặc 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é. 1. Tản mạn
Trong một buổi offline gần đây với Andie (đang là Product tại GeekUp) và Bảo (đang là Product tại Kredivo) trong cộng đồng Breaking into Product Management. Yeah, cuộc trò chuyện 4 tiếng khá là thú vị đến nỗi chúng mình quên mất selfie lưu giữ kỷ niệm. Các chia sẻ chủ yếu xoay quanh các công việc mà mọi người đang làm trong domain Fintech hoặc Digital Banking. Trong cuộc trò chuyện, mình có để ý một số keyword có vẻ được nhắc đi nhắc lại nhiều lần một như một phản xạ. Điều này thể hiện rằng không ít thì nhiều đây là những thứ sẽ đi theo xuyên suốt trong công việc hằng ngày của các bạn đang làm sản phẩm. Và 2 keywords này thường đi kèm với nhau là System Thinking (Tư duy hệ thống) và Visualization (Mô hình hoá)
“Khi muốn hệ thống thông tin và suy nghĩ mạch lạc, rạch ròi hơn → hãy thử visualize (mô hình hóa)” - Andie.
Trước khi đi sâu hơn, mình muốn hồi tưởng một chút về ngày xưa. Nếu nói về 2 khái niệm System Thinking (Tư duy hệ thống) và Visualization (Mô hình hoá) này thì chắc có lẻ mình đã tiếp xúc từ hồi ngồi trên ghế đại học. “Ảo tưởng nhẹ chút xíu” Tính ra, thế là mình có lợi thế cạnh tranh khi bắt đầu chuyển ngành sang product, khởi điểm 0.1 (0.2) lên đến 1 thay vì từ 0 lên đến 1 (giả dụ nếu được so với một bạn học về các ngành nghệ thuật hoặc kinh tế).
Hồi bậc ĐH, thì mình được học cách tư duy hệ thống bằng cách mô hình hoá hệ thống đấy bằng đủ thứ biểu đồ. Mỗi hệ thống là một sơ đồ, một tiêu chuẩn nào là bản vẽ kỹ thuật, bản vẽ chế tạo, sơ đồ hệ thống điện, sơ đồ hệ thống thuỷ lực khí nén, sơ đồ tác động lực… Ôi thôi học tá lả xong giờ ra trường tới hiện tại thì quên sạch các tiêu chuẩn vẽ cho từng hệ thống vì chuyển ngành mất tiêu rồi (ấy nói quên nhẹ vậy thôi, chớ nhìn vẫn còn nhớ sơ sơ nhé, cái nào bánh răng, cái nào là trục, ổ lăn, lắp thế nào hay là hệ thống mạch điện này lắp và chạy thế nào). Tuy nhiên đối với mình, nhờ học nhiều về cách mô hình hoá nhiều hệ thống ở ĐH đã giúp mình phát triển tư duy hệ thống trong công việc làm sản phẩm hiện tại. Mình luôn cố gắng bắt đầu từ góc nhìn tổng thể, rồi dần đi sâu vào chi tiết khi gặp bất kỳ vấn đề nào.
Viết tới đây làm mình liên tưởng tới việc System Thinking cũng sẽ giúp bạn cải thiện kỹ năng giao tiếp với các stakeholder như này. Bằng cách “leo lên / leo xuống” trong nấc thang abstraction (tư duy hệ thống một cách tổng quát đến chi tiết) giúp từng người nghe cụ thể dễ dàng hiểu hơn - điều này được đề cập trong bài viết The Ladder of Abstraction and the Public Speaker
Ví dụ tổng quát: Khi thảo luận về một tính năng, một số người nghe chỉ cần biết về mặt flow tổng thể như hệ thống A cần giao tiếp với hệ thống B để ra được kết quả cho hệ thống C xử lý. Họ chỉ cần dừng ở mức đó là đủ. Tuy nhiên, có những người nghe sẽ có nhu cầu được biết sâu hơn rằng hệ thống A sẽ gửi data cụ thể gì cho hệ thống B. Hệ thống B khi nhận cần validate gì không và sẽ xử lý data đó theo logic như thế nào.
Trở lại với bản thân, mình cũng đang cố gắng áp dụng System Thinking và Visualization trong công việc hằng ngày khi viết PRD cho các tính năng và sau đó giảng giải PRD này cho cả Business lẫn team Engineer ở bên Singapore và Trung Quốc. Flow của mình thông thường khi viết PRD lẫn brief PRD sẽ là diễn giải background, context tại sao lại cần build tính năng này. Sau đó là đi từ tổng quát nhất, tình trạng hệ thống hiện tại (As-is) và thay đổi của hệ thống sắp tới (To-be). Hệ thống lại cách các service nội bộ liên kết và giao tiếp với nhau, các service của nội bộ sẽ liên kết với service bên ngoài thế nào để mọi thứ có thể chạy trơn tru ra được đúng kết quả mình mong muốn.
Nói có vẻ dễ nhưng cũng khá trầy trật. Chính mình cũng trải nghiệm khi có các cuộc họp quá kỹ thuật nếu chỉ cố gắng diễn đạt bằng lời, bằng văn bản, mọi thứ đôi khi lại càng rối. Còn những cuộc họp nào mình có chuẩn bị các hình ảnh mô hình hoá hệ thống, những mô hình logic hệ thống nội bộ... lại trở thành cứu cánh → thay đổi cách giao tiếp từ những tài liệu dài dòng, khó đọc, sang các hình ảnh trực quan khiến cuộc trao đổi giữa mình và các bạn Engineer / Regional Product dễ hiểu, dễ thống nhất ý kiến với nhau hơn. Khiến những ý tưởng phức tạp khi nói hoặc viết trở nên dễ hiểu, rõ ràng và có cấu trúc.
Nhân tiện, một số sơ đồ để mô hình hoá lại hệ thống mà mình hay sử dụng hiện tại. Thật ra mấy cái sơ đồ này không chỉ cần dành riêng cho PO/BA/Tech PM gì đâu. Mà mình nghĩ nó ai ai cũng có thể sử dụng:
2.Diagrams 101
2.1 Sequence Diagram
Sequence diagrams (sơ đồ tuần tự) làm đúng như tên gọi của chúng, mô tả xác định trình tự cách tương tác giữa các hệ thống.
Việc thể hiện trình tự giúp mình hiểu rõ hơn cách các hệ thống giao tiếp với nhau. Mình cảm thấy sequence diagram giúp người khác xem rõ hệ thống hơn và có thể nhanh chóng nhận ra các vấn đề, kích thích những câu hỏi đáng giá như
“Nếu người dùng bị kẹt thì thế nào?”
“Nếu hệ thống A đã gửi cho hệ thống B, nhưng hệ thống B không nhận được thì sao”
“Nếu hệ thống đó bị down thì …?”
“Làm sao biểu diễn các trường hợp lỗi?”
Ví dụ bên dưới là sequence diagram mình vẽ để giải thích cho các Engineer hiểu được sơ lược luồng FrontEnd và BackEnd (API) hoạt động như thế nào. Khi User thao tác trên FE, thì hệ thống S sẽ thực hiện và giao tiếp với hệ thống B như thế nào trong xuyên suốt cả một luồng onboarding.
Mình để code mẫu bên dưới. Bạn có thể thử tại tool này. (mình dùng UML, bạn có thể dùng tool Mermaid, dùng chatGPT tạo lại đoạn code từ platform UML → platform Mermaid )
@startuml
autonumber
actor User as user
participant S as s
participant B as b
title Onboarding - Happy case
user -> s: Start Onboarding Flow
s -> s: User fill info and Proceed
s -> s: Show OTP Landing Page,\n trigger OTP Flow
== OTP flow==
s -> b: trigger API sendOTP
note right: Send SMS OTP \n code to customer
b --> s:
user -> s: Fill in OTP code
note left: Customer read SMS \n (or system auto read) \n and fill in OTP code
s -> b: trigger API verifyOTP
b --> s:
s -> user: Show "Application in Progress" Page
== Activation flow==
s->b: Card Application
b-->s: Response Card Application
|||
s->b: Final Callback Card Application
b-->s: Response Final Callback Card Application
|||
group Inquiry Application Status
s -> b: Trigger Inquiry Card Application Result
b --> s: Card Application Result
end
s -> user: Show Application's Result Page
footer [ThienNguyen]
@end
@enduml2.2 Flow Chart
Nếu sequence diagram giúp ta hình dung tương tác giữa các hệ thống, thì flow chart ở phạm vi nhỏ hơn so với, tập trung làm rõ logic hoạt động phức tạp bên trong của một hệ thống đơn lẻ. Logic kiểm tra ở bước này là gì. Nếu YES thì thế nào. Nếu NO thì ra sao.
Flow chart này cũng được thống nhất nội bộ và sau đó có thể là guideline để giúp dev code logic chính xác hơn, giúp QA tạo test case chuẩn hơn.
Mình để code mẫu bên dưới. Lần này mình dùng tool Mermaid thay vì UML. Bạn có thể dùng thử
graph LR
landingPage(User: Thien Nguyen) --> whiteList{Whitelist}
whiteList -- Yes --> instructionPage(Instruction Page)
instructionPage --> eKYC(Selfie / IC Upload / NFC Verify)
eKYC --> addInfo(Add Info, trigger Risk Engine)
addInfo --> riskEngine{Need more ext info?}
riskEngine -- Yes --> externalConsent{Consent confirmation?}
riskEngine -- No --> partnerOTP(Bank OTP)
externalConsent -- Yes --> externalOTP(SignOTP)
externalConsent -- No --> partnerOTP(Bank OTP)
externalOTP(SignOTP) -- Success --> getExtInfo(Get Ext Info)
externalOTP(SignOTP) -- Failed --> partnerOTP(Bank OTP)
getExtInfo(Get Ext Info) --> partnerOTP(Bank OTP)
whiteList -- No --> End
partnerOTP(Bank OTP) --> End
2.3 Entity-Relationship Diagram (ERD)
ERD là một công cụ mô hình hóa dữ liệu trừu tượng, được sử dụng để thể hiện và thiết kế cơ sở dữ liệu. Nó tập trung vào việc xác định các "thực thể" (những đối tượng quan trọng trong hệ thống, ví dụ: Khách hàng, Sản phẩm, Đơn hàng), các "thuộc tính" của chúng và "mối quan hệ" giữa các thực thể đó. Nó mô tả các quy tắc nghiệp vụ và cấu trúc dữ liệu theo cách dễ hiểu cho cả người làm kỹ thuật và người dùng nghiệp vụ.
(có bài ERD là gì của a Thịnh cũng dễ hiểu, mọi người xem qua)
Mình chỉ sử dụng tới ERD khi mà tính năng mình có liên quan đến quá nhiều hệ thống trong quá trình phân tích yêu cầu nghiệp vụ. Xem liên kết giữa các thực thể trong các hệ thống. Và main case chính thực ra ERD giúp mình hiểu thêm về mô hình quản lý dữ liệu hiện tại trong các hệ thống trong công ty (khi mà nó quá to)
Do cách vẽ và hình dáng của Class Diagram và ERD này khá giống nhau. Nên mình tạm sử dụng tool dbdiagram dùng ngôn ngữ DBML (Database Markup Language) để vẽ ERD mỗi khi cần. Dưới đây là ví dụ thôi chớ nó không hoàn toàn chính xác đâu nhé.
// Mô hình các lớp từ Class Diagram trong định dạng DBML cho dbdiagram.io
// Lưu ý: dbdiagram.io chủ yếu dùng cho sơ đồ cơ sở dữ liệu,
// nên các phương thức của lớp sẽ không được thể hiện trực tiếp.
Table Buyer {
id int [pk, not null]
name varchar(255)
email varchar(255)
phone varchar(20)
}
Table Seller {
id int [pk, not null]
name varchar(255)
email varchar(255)
phone varchar(20)
}
Table SaleOrder {
id int [pk, not null]
name varchar(255)
date_order timestamp
buyer_id int //key
seller_id int //key
amount_total float
created_at timestamp [default: 'now()']
}
Table CRM {
id int [pk, not null]
name varchar(255)
description text
sale_order_id int //key
}
// Relationship
Ref: SaleOrder.buyer_id > Buyer.id //(One-to-Many) relationship
Ref: SaleOrder.seller_id > Seller.id //(One-to-Many) relationship
Ref: CRM.sale_order_id <> SaleOrder.id //(One-to-One) relationship
2.4 BPMN (Business Process Modeling Notation)
Ở vị trí Product hiện tại mình rất ít sử dụng đến sơ đồ này. Nhưng thời mình còn làm BA ở công ty ERP thì mình đánh giá rất cao về “vũ khí” này để trao đổi và mô hình hoá những luồng nghiệp vụ phức tạp của khách hàng doanh nghiệp.
Đã có anh Thịnh Note chuyên gia viết về BPMN này là anh Thịnh Note nên mình sẽ không viết lại quá nhiều. Mời các bạn cùng thẩm:
https://thinhnotes.com/chuyen-nghe-ba/bpmn-va-su-loi-hai-cua-no/
https://thinhnotes.com/chuyen-nghe-ba/giai-ngo-cac-ky-hieu-bpmn/
https://thinhnotes.com/chuyen-nghe-ba/quay-toi-ben-voi-bpmn/
2.5 Free Flow
Vô chiêu thắng hữu chiêu. “Free Flow” là kiểu sơ đồ mình dùng nhiều nhất – không theo chuẩn nào cả. Mục tiêu duy nhất là: vẽ sao cho mình hiểu. Khi gặp một vấn đề rối quá, mình thường viết tất cả ý nghĩ ra giấy, gom nhóm lại thành từng object rồi vẽ các liên hệ. Nắm tổng quan trước, rồi mới đi vào chi tiết sau. Vẽ xong cái này rồi thì mình mới bắt đầu tạo mấy mô hình “đúng chuẩn” để làm tài liệu hoặc đem đi trao đổi. Mình sử dụng tool offline thuần khiết thì một tờ giấy A4 và một cây bút chì. Nếu online thì mình sử dụng Excalidraw (bản free là đủ).
3.End
Viết dong dài nhưng tổng kết lại thì System Thinking và Visualization (with Diagram) là hai "vũ khí" mình dùng mỗi ngày để hiểu vấn đề rõ hơn, truyền đạt tốt hơn và làm việc hiệu quả hơn với team, từ Engineer đến Business.
Tư duy hệ thống giúp mình nhìn bao quát trước khi đi sâu, còn mô hình hóa giúp mình nghĩ rõ ràng và giao tiếp mạch lạc. Càng đi sâu vào product, mình càng tin rằng: nếu không thể vẽ ra được, thì có khi mình chưa thực sự hiểu nó.
Nếu bạn cũng đang vật lộn với các hệ thống phức tạp và không biết bắt đầu từ đâu thì thử vẽ một cái gì đó ra trước đã. Bắt đầu từ một hình tròn, một đường nối..biết đâu mọi thứ sẽ dần sáng tỏ ✍️