Loading...
Tìm kiếm

Tag Archives: bài học rút ra

Categories Business Analyst Tự học IT BA

UML là gì? Giới thiệu các loại diagram Business Analyst hay dùng

by hoangphan Posted on
UML là gì? Các loại diagram Business Analyst hay dùng

Một bài trong chuỗi tự học IT Business Analyst cho người mới bắt đầu

Giới thiệu

Làm Business Analyst (BA), một trong những công cụ mạnh mẽ nhất mà chúng ta sử dụng để truyền đạt các yêu cầu và mô hình hóa các luồng, các hệ thống phức tạp là dùng UML.

Với bài viết này, Hoàng sẽ trình bày chi tiết hơn về UML, vai trò của nó trong công việc của một IT Business Analyst, và cách thức nó giúp chúng ta tối ưu hóa quá trình phát triển phần mềm.

UML là gì?

UML (Unified Modeling Language) là ngôn ngữ mô hình hóa tiêu chuẩn được sử dụng để biểu diễn và trực quan hóa thiết kế của hệ thống phần mềm. UML không phải là một ngôn ngữ lập trình, mà là một ngôn ngữ trực quan giúp chúng ta truyền đạt các yêu cầu, thiết kế, và cấu trúc hệ thống một cách hiệu quả giữa các bên liên quan.

Mình thì thấy UML nó giống như 1 bộ quy tắc/syntax để đưa ra 1 chuẩn thống nhất để mô hình và trực quan hoá phần mềm khác nhau, nó có nhiều loại mô hình/diagram, và cũng kiểu triển khai sao cho đơn giản, dễ tiếp cận và phổ biến đến mọi người.

Tại sao UML quan trọng đối với IT Business Analyst?

Là Business Analyst, một trong những tác vụ chúng ta cần phải làm đó là cầu nối giữa doanh nghiệp và nhóm phát triển (Dev team). Do đó mà chúng ta sẽ làm việc với các khách hàng/stakeholders để thu thập yêu cầu, làm rõ và xác nhận, sau đó chúng ta sẽ truyền đạt yêu cầu đó đến cho đội ngũ Dev. Vậy truyền đạt không phải chỉ nói là xong mà chúng ta cần phải viết tài liệu, mô tả, để làm sao dễ hiểu, chính xác và hiệu quả nhất. Mà thường để dễ hiểu cần hình minh hoạ, lưu đồ (diagram), thì UML chính là công cụ quan trọng trong việc đó => Giúp các bên dễ dàng hình dung và thảo luận về hệ thống.

Một số lợi ích mà IT Business Analyst có thể dễ thấy khi dùng UML:

  • Mô hình hoá yêu cầu: Dĩ nhiên UML là dùng để mô hình hoá 😀 nên nó sẽ giúp ta mô hình hoá yêu cầu, mà khi mô hình hoá lên mọi người đọc sẽ dễ hiểu hơn là đọc chữ không.
  • Truyền đạt yêu cầu hiệu quả: UML giúp chúng ta trình bày các yêu cầu và thiết kế hệ thống một cách rõ ràng và dễ hiểu, ngay cả với các bên không phải là Dev team. Các diagram UML giúp thu hẹp khoảng cách giữa doanh nghiệp và nhóm phát triển phần mềm (Dev).
  • Giảm thiểu hiểu lầm: Sử dụng UML giúp giảm thiểu sự hiểu lầm giữa các bên liên quan vì sơ đồ trực quan có thể truyền đạt nhiều thông tin hơn so với mô tả bằng ngôn ngữ tự nhiên.
  • Quản lý yêu cầu hiệu quả: Không chỉ về phần truyền đạt, mà UML còn giúp cho các yêu cầu được quản lý một cách hiệu quả, có hệ thống. Rồi phần dễ dàng theo dõi tiến độ nữa, mình cũng hay dùng các UML rồi đổi màu để đánh trạng thái phần nào đã xong.
  • Linh hoạt với nhiều mô hình phát triển phần mềm khác nhau: Ví dụ như Scrum/Agile, WaterFall, V-model, …
  • Tái sử dụng tốt: Thường nếu chung 1 luồng gần giống nhau, BA cũng hay dùng lại các diagram cho các dự án, tài liệu khác nhau.
  • Quản lý rủi ro và đánh giá tác động: Nhờ các diagram mà chúng ta có thể nhìn dự án một cách tổng quản, xem xét khi làm tính năng A thì ảnh hưởng tới những tính năng nào, rủi ro ra sao, đôi lúc cũng liên quan đến các chi phí phát sinh như cần phải có server A, server B,… Từ đó mà tránh đi được những vấn đề trước khi chúng trở nên nghiêm trọng.

Danh sách các loại UML Diagram

Mình để 1 hình các bạn xem là sẽ hiểu có những loại nào ha, hiện theo Wiki thì có 14 loại.

14 loại UML Diagrams
14 loại UML Diagrams
  • Sơ đồ lớp (Class Diagram)
  • Sơ đồ đối tượng (Object Diagram)
  • Sơ đồ tình huống sử dụng (Use Cases Diagram)
  • Sơ đồ trình tự (Sequence Diagram)
  • Sơ đồ cộng tác (Collaboration Diagram hay là Composite Structure Diagram)
  • Sơ đồ trạng thái (State Machine Diagram)
  • Sơ đồ thành phần (Component Diagram)
  • Sơ đồ hoạt động (Activity Diagram)
  • Sơ đồ triển khai (Deployment Diagram)
  • Sơ đồ gói (Package Diagram)
  • Sơ đồ liên lạc (Communication Diagram)
  • Sơ đồ tương tác (Interaction Overview Diagram – UML 2.0)
  • Sơ đồ phối hợp thời gian (Timing Diagram – UML 2.0)
  • Sơ đồ hồ sơ (Profile Diagram)

Về phần details giải thích từng cái bạn có thể xem video ngay ở dưới, hoặc các bạn đọc bài này nè, khá là hay luôn đó, có sẵn hình minh hoạ.

Learn 14 types of UML diagrams in one article

Ngoài ra các bạn có thể xem thêm ở trang sau

https://www.uml-diagrams.org/ 

Học, hiểu và vẽ UML

Thiệt mà để chỉ các bạn vẽ khá là tốn nhiều thời gian, nhiều khi cần phải làm video cơ. Mình xưa tự học được => mình nghĩ các bạn cũng sẽ tự học được.

Trên youtube giờ search có rất nhiều video hướng dẫn vẽ, dưới đây là 1 video, các bạn có thể xem và học nha 😀 mình đỡ làm lại

Các loại UML diagram hay được dùng

Đây là 1 khảo sát về việc sử dụng UML

Mức độ sử dụng các loại UML Diagram
Mức độ sử dụng các loại UML Diagrams

Trên là mức độ sử dụng của các loại UML diagrams, nhưng không phải chỉ áp dụng cho BA mà là cho tổng quan chung.

Qua thực tế sử dụng, với kinh nghiệm sử dụng của mình thì có những loại sau BA hay sử dụng:

  • Activity diagram (Nhiều chúa)
  • Sequence diagram (Nhiều chúa)
  • Class diagram (nhiều)
  • Usecase (Tuỳ công ty =)) có cty dùng User Stories (một phương pháp khác) nên ít sài Use case hơn)
  • State machine (hay gọi là State diagram) (nhiều)

Mình thấy cũng khá đúng so với cái survey trên.

Khi làm với Dev, nói sâu về tổng quan hệ thống, kiến trúc hệ thống, deployment các kiểu thì mình cũng có sài, nhưng không nhiều bằng ở trên

  • Component diagram
  • Deployment diagram
  • Package diagram
  • Object diagram

Các diagram khác hay được sử dụng.

  • Sơ đồ khối (Flowchart), khá tương đồng với cái Activity diagram, có vài chỗ khác, nhưng mình hay dùng để thay cho nhau (Flowchart <> Activity diagram)
  • Mô hình ERD (The Entity-Relationship Model)
  • Sơ đồ luồng dữ liệu (Data Flow Diagram – DFD)
  • BPMN (dùng không nhiều lắm, mình có cho survey, bạn có thể xem ở hình dưới)
Khảo sát về việc sử dụng BPMN khi là Business Analyst
Khảo sát về việc sử dụng BPMN khi là Business Analyst

Thì có (42+7+3)% = 52% số người đã votes không sử dụng BPMN trong công việc

51% số người đã votes có sử dụng, nhưng có thể thấy là tận 26% hiếm khi sử dụng.

Tổng 52+51 >100% vì được làm tròn 😀 á.

 

Cả 4 cái mình vừa liệt kê trên không phải là UML, nhưng thuộc loại hay được dùng, mình sẽ viết thêm bài viết về 4 loại trên cho các bạn tìm hiểu nhé, chờ đấy…

Các phần mềm dùng vẽ diagram mình sài

Khi là sinh viên mình hay sài StartUML (https://staruml.io/)

Khi đi làm thực tế thì mình sài:

Có research và sử dụng thử qua các tool:

  • Lucidchart
  • SmartDraw
  • Creately.com
  • PlantUML
  • clickup.com

Kết bài

Cảm ơn các bạn đã đọc đến đây,.. vẫn là như cũ – hi vọng qua bài viết các bạn lại có thêm kiến thức về BA, biết thêm về UML, các loại UML, những loại nào hay sài và những loại nào cũng hay sài nhưng không phải là UML.

Và các công cụ mình hay sài để vẽ các diagram là gì => từ đó bạn có thể thử sài, học cách sài cho công việc của bạn.

Categories Business Analyst Chia sẻ

Giao tiếp hiệu quả giữa Business Analyst và devs, testers, designers

by hoangphan Posted on
Business Analyst giao tiếp hiệu quả với Developers, Testers, Designers

Chào mọi người 😀

Giới thiệu

Vẫn là Hoàng đây, hôm rồi có bạn nhắn hỏi về “Vấn đề giao tiếp trong nhóm, kiểu làm sao để giao tiếp hiệu quả giữa dev, tester, design với BA”

Với kinh nghiệm làm việc và quản lý một vài đội nhóm, từ BA, PO, PM, QC tới UI Design, mình xin phép chia sẻ kinh nghiệm cá nhân đế các bạn đọc có cùng thắc mắc.

Trong bài này mình đổi cách xưng hô tí nhé, vì người đặt câu hỏi là 1 bạn nữ nhỏ hơn mình vài tuổi, nên mình xin phép xưng “Anh” “Em”

Ý chính từ ý kiến cá nhân

1. Hiểu những việc họ làm sẽ giúp em giao tiếp dễ với họ.

2. Nên chia sẻ nghiệp vụ với họ (họp nhóm/họp 1-1) để giới thiệu rõ nghiệp vụ, business rule, luồng, Đặc biệt là chia sẻ trên tinh thần mình hiểu, mình tự tin, và mục đích chia sẻ để họ hiểu thay vì qua loa cho xong việc.

3. Nói chuyện vui vẻ/ tâm sự chuyện thường ngày với họ.

1. Hiểu sâu về công việc của các bộ phận khác:

Ví dụ em thử học 1 khoá về dev sơ sơ, mò thử vài cái cơ bản về dev xem sao… or design thì thử học 1 khoá về design nhỏ trên youtube.

A Business Analyst is learning UI Design skills
A Business Analyst is learning UI Design skills

A thì nghĩ 1 số bạn nói là dư, nhưng với kinh nghiệm của anh, nhờ biết các kiến thức này mà từ lúc intern anh làm việc với mọi người rất suôn sẻ

Anh từng dev game, hiểu độ khó của việc dev ra sao, từng code web, từng code mobile app (Swift), code cả app trên win, đa phần là lúc còn sinh viên với những năm làm thêm freelancer, nên khi nói chuyện với dev, dù vấn đề khó anh vẫn nói chuyện với họ rất bình thường, thậm chí có thể trao đổi technical sâu với CTO trong công ty và CTO đối tác.

Từng làm QC Manual & Auto => a làm việc với QC cũng rất mượt =]], kiểu có thể nói chuyện về việc test như nào, đặt priority test ra sao, test plan kiểu gì, kiểm soát tiến độ, dùng phương pháp nào để test, dùng tool nào, Auto thì đang sài ngôn ngữ nào, Xpath hay code, sài thư viện nào, tool auto nào…

Design thì anh cũng tự vẽ & trao dồi thêm kinh nghiệm từ Design nữa. Nên bản thân cũng tự có thêm skill, nhiều lúc làm với Design thì biết cách diễn giải với ngôn ngữ của Design, dùng đúng các khái niệm như Auto-layout, Responsive, Hi-fi design, Prototype, Wireframe, Mockup, Component, Section, Animation,…

2. Chia sẻ kiến thức nghiệp vụ một cách toàn diện

Em hãy tổ chức các buổi họp nhóm hoặc 1-1 để giới thiệu chi tiết về nghiệp vụ, business rule và luồng công việc.

Chia sẻ với tinh thần tự tin, hiểu rõ và mong muốn truyền đạt kiến thức, không chỉ đơn thuần là hoàn thành nhiệm vụ.

Giải thích cả bức tranh tổng thể, từ bài toán kinh doanh đến cách hệ thống tạo ra giá trị cho người dùng.

Business Analyst trình bày trước Devs, Testers, Designers
Business Analyst trình bày trước Devs, Testers, Designers

Ví dụ thực tế: 

Anh sẽ không chỉ chia sẻ những phần của họ, mà anh chia sẻ từ bài toán business, làm sao kiếm ra tiền, cách nhìn nhận từ users, ví dụ như nay có mấy phần FE không cần hiểu là tính năng chạy như thế nào, chỉ cần share userflow & data đó từ BE trả ra là bạn tích hợp được rồi, nhưng anh lại chia sẻ thêm là vì sao nó phải chạy như vậy, phía BE phải dùng công thức như nào để bạn làm, biết đâu lúc code bạn cũng phát hiện ra bug từ Be trả kết quả sai thì sao 😀

Rồi hôm bữa ngồi chia sẻ về 1 dự án kiểu dạng nhận tiền users để mang đi đầu tự động thông qua Smart Contract, thì anh cũng chia sẻ luồng user bỏ tiền, rồi hệ thống làm gì, có công thức gì mà giúp tiền users đi đến những nơi khác và kiếm lợi nhuận, trường hợp nào sẽ lỗ, trường hợp nào sẽ lời, lỗ thì hệ thống phải làm sao, lời thì sao, … từ đó mà Design có thể bổ sung những trường hợp báo rủi ro lỗ, thêm các bước xác nhận risk trong đầu tư, … Mà vì được nghe rõ về Business => Designer họ cũng sẵn sàng chia sẻ kinh nghiệm design, chỉ tip design => Mình cũng được nâng cao kỹ năng desgin.

3. Nói chuyện vui vẻ như bạn bè.

Anh nghĩ công việc & chuyện đời thường mọi người cứ vui vẻ với nhau, làm việc khoẻ hơn rất nhiều, anh không chỉ áp dụng với trong team, mà còn áp dụng với đối tác đồ nữa.

Xưa làm mảng mobile banking, anh cũng hay đi ăn với bạn bên bank. Nên khi cần gì rắc rối nhờ họ là họ giúp mình ngay.

BA đi ăn cùng Devs, QCs, Designers
BA đi ăn cùng Devs, QCs, Designers

 

Các ý bổ sung, hơi thiên về kỹ năng

  • Anh em nên thống nhất 1 quy trình làm việc chung, ví dụ như stand-up meeting hằng ngày. Thẳng thắn chia sẻ/trao đổi/ chỉ ra lỗi sai của nhau trong khi làm việc
  • Làm gì cũng có plan, ví dụ sprint plan.
  • Làm rõ mục tiêu/kết quả của sprint/dự án/phase
  • Sử dụng công cụ tracking hiệu quả, như anh là sài Trello/Jira, kéo task liên tục, thường la mấy đứa để nó update task đúng.
  • Đánh version/commit code rõ ràng (này bạn Dev Lead hay nhắc nhở mấy đứa dev trong team =)) commit không rõ ràng là bị ăn chửi =)) )
  • Anh cũng hay hỏi mọi người ý kiến, chia sẻ idea để phát triển dự án, với 1 phần họ cảm thấy mình tôn trọng họ.
  • Nên dùng cách giao tiếp khác nhau với đối tượng khác nhau, ví dụ Designer => thì em không thể dùng các từ ngữ kỹ thuật bên Dev để nói chuyện.
  • Cập nhật tài liệu thường xuyên (wiki, SRS, URD, User Stories,…)
  • Tổ chức mấy buổi review UI cho các bên, Tester/BA/Dev cũng nên join. rồi nhờ mọi người cho ý kiến nữa.
  • Tăng cường chat, đặc biệt là chat nhóm, tránh chat riêng (Direct Message)
  • Nên tổ chức retrospective, anh lâu lâu thấy team không ổn, hoặc dự án nó đi sai với kế hoạch là anh làm ngay, anh không follow agile là hết sprint là làm, anh làm ít hơn, chỉ khi cần thiết thôi. => mọi người góp ý, nhìn nhận sai sót, đưa ra phản hồi để xây dựng.
  • Khi diễn giải nghiệp vụ => Nên sài biểu đồ nhiều vô, ít chữ thôi => Đi từ tổng quan đến chi tiết.

Kết bài

Hi vọng với những kinh nghiệm và ý kiến cá nhân sẽ giúp bạn đọc sẽ giao tiếp hiệu quả hơn nữa khi làm việc với QC, Dev, Designer.

Hãy để lại comment hoặc chia sẻ đến bạn bè nếu thấy hay nhé.

Categories Business Analyst Chia sẻ

IT Business Analyst sử dụng AI trong những công việc nào? (phần 2)

by hoangphan Posted on
IT Business Analyst sử dụng AI Artificial Intelligence) - Hoàng Phan Blog

Tiếp tục phần một “Ứng dụng AI trong công việc IT Business Analyst”

Lời giới thiệu

Dưới đây là các task vụ trong BA/PO/PM mình đã áp dụng AI để thực hiện. Nhưng trước khi đọc phần này, bạn nhớ đọc phần 1 nhé, phần 1 là những nhận định cá nhân chung về các công cụ AI.

Viết user story và Acceptance Criteria

Role của mình cũng hay viết User Story, và việc xử dụng AI để viết và để viết hiệu quả mình thường sử dụng ChatGPT để thực hiện task vụ này.

Bạn có thể xem video dưới đây để hiểu cách viết nhé.

Link video: https://youtu.be/LY0DsQr3YSg

Và hướng dẫn viết Acceptance Criteria

Link video: https://youtu.be/ywGnz9i3ztw

Dĩ nhiên là với AC, bạn có thể viết theo syntax “GWT” Given When Then

Scenario 1: Successful Admin Login

Given an administrator is on the Shared Login Page for Teachers and Admins,
And the administrator has a valid Email and Password,
When the administrator enters the correct Email and Password,
And clicks the “Login” button,
Then the system should authenticate the administrator,
And redirect the administrator to the Admin Dashboard,
And display the Admin Dashboard interface.

Và từ đó suy ra Decision Table

Tip từ bản thân mình cho phần viết này là bạn hãy input thật rõ chi tiết về User story bạn muốn, hoặc add những idea bạn đã nghĩ ra cho phần User story và bảo AI bổ sung hoặc viết chỉnh chu hơn cho User Story.

Các bạn có thể đọc đoạn này cho phần ví dụ nhé: https://poe.com/s/QdDjRA6gk2rq5MX9S37m

Ngoài ra bạn hãy thử sử dụng: https://userstorygenerator.ai/ để viết nha.

Phụ viết rõ hơn về yêu cầu

Thường thì mình có idea về tasks, và cũng hơi hơi làm biết để làm chi tiết, hoặc cụ thể hoá theo 1 cách đầy đủ => Đây là cơ hội để nhờ AI hỗ trợ =))

Mình đưa ví dụ, bạn có thể tự áp dụng thêm nha.

Như ví dụ dưới đây mình có idea về làm tròn số và có nhiều trường hợp khác nhau, mình cứ mô tả theo cách mình hiểu.

Cuối cùng với những dòng mình viết kiểu khá dài dòng, AI có thể đọc hiểu và viết gọn lại cho mình => Thậm chí mình biết ae Dev đang dùng ngôn ngữ lập trình nào, mình copy mẫu luôn cho họ.

AI hỗ trợ viết lại yêu cầu rõ ràng và gọn hơn
AI hỗ trợ viết lại yêu cầu rõ ràng và gọn hơn

Hay ví dụ như viết checklist, testcase mình cũng mô tả rồi nhờ AI hỗ trợ làm rõ và viết ra các cases

AI hỗ trợ viết testcase/checklist
AI hỗ trợ viết testcase/checklist

Với trường hợp viết testcase như này, bạn cần input thật rõ business rule cho AI để nó viết cho đầy đủ, thậm chí bạn cũng phải suy luận, đọc và kiểm tra lại xem AI đã viết đủ và đúng chưa nữa.

Vẽ Diagram

Mình sử dụng kết hợp ChatGPT + Mermaid hoặc ChatGPT + Draw.io

Các loại biểu đồ mà ChatGPT có thể hỗ trợ gồm:

  • Flowchart => Tận dụng làm Activity Diagram luôn cũng được
  • State diagram
  • Grantt chart
  • Sequence Diagram (Mình hay sài nhất)
  • Class diagram
  • ERD
  • User Journey
  • Object Diagram

Mình thì hay sài Flow chart và sequence nhất, mấy loại khác thì mình hay sài kiểu khác hơn. Các bạn cứ thử mò và tìm cách sử dụng nhé, nhớ là tự mày mò => tìm được “AI Prompting” và sử dụng nó nhiều lần để thuần thục nhé.

Bước 1: Cứ nói chuyện với AI (Prompting), sau đó khi AI đã hiểu được bài toán => Bảo tạo ra diagram (với loại Mermaid), ví dụ: “Tạo sequence diagram cho tính năng đăng nhập của giáo viên, các actor trong hệ thống gồm: Teacher, UI, BE, AuthService, sử dụng syntax Mermaid”

Bước 2: Copy đoạn code được tạo ra từ AI, bỏ vào một trong những công cụ hỗ trợ view từ Code sang Diagram.

Sử dụng ChatGPT vẽ sequence diagram - Hoàng Phan Blog
Sử dụng ChatGPT vẽ sequence diagram – Hoàng Phan Blog
  • Mermaid Live Editor: https://mermaid.live/ => Cứ copy code và bỏ vào bình thường theo loại bạn muốn
Sử dụng Mermaid tạo diagram - Hoàng Phan Blog
Sử dụng Mermaid tạo diagram – Hoàng Phan Blog
  • Dùng Markdown, có thể sài trên github, visual studio code, thì trước đoạn code bạn bổ sung “`mermaid
  • Hiển thị trên draw.io thì bạn làm theo như hình dưới đây, sau đó paste code vào và nhấn lưu để hiển thị.
Sử dụng Draw.io và ChatGPT tạo diagram - Hoàng Phan Blog
Sử dụng Draw.io và ChatGPT tạo diagram – Hoàng Phan Blog

Mình hay sài Mermaid/Draw.io nên dùng cách này, các bạn cũng có thể sài những format khác như PlanUML, StartUML nhé.

Vẽ wireframe/mockup

Nói thật với các bạn là có nhiều người nhắn tin hỏi mình về AI để vẽ mấy wireframe/mockup, mà thực sự mình rất ít khi sài :D. Kiểu giống như là cả team mình sài Figma, xong rồi mình đi sài những công cụ khác để vẽ rồi copy qua, khi cần edit nó cũng bất tiện ấy.

Một phần là khi vẽ wireframe, rõ là bước này chính là bước Elicitation của mình luôn, hay đặt câu hỏi, phân tích tới đâu vẽ tới đó, vừa visualize ý tưởng lên cho dễ hình dùng khi phân tích

Chưa kể là mình vẽ wireframe khá là nhanh :v không tốn mấy thời gian, tốn là tốn thời gian ngồi suy nghĩ luồng nghiệp vụ sao cho hợp lý ấy.

=> nên mình hay sài công cụ https://excalidraw.com/, và figma bạn đọc bài viết này nhé.

Đọc thêm  Công cụ vẽ wireframe và diagram tuyệt vời mình tìm được cho Business Analyst.
Đọc thêm  Figma Professional miễn phí: Công Cụ Đắc Lực Cho Business Analyst

Còn cho những bạn tò mò và muốn thử nghiệm xem thử sài AI thì thử những công cụ mình liệt kê dưới đây nha.

  • Visily.ai (thiệt là mình chưa sài =)) mà thấy group nào cũng đề cập => Mình đưa vào list)
  • Miro: Có hỗ trợ AI vẽ diagram
  • Jeda.ai: https://www.youtube.com/shorts/ekdmMBXSP0Q?feature=share
  • Relume Library (on Figma): https://youtu.be/8eNnr6GPClU
  • UIZard.io:
  • Plugin Figma: https://www.figma.com/community/plugin/1355208994639626356/codia-ai-designgen-prompt-to-ui-for-website-landing-page-blog
  • https://uxpilot.ai/
  • https://creatie.ai/

Mình chỉ gợi ý, các bạn tự xem video mà mày mò thêm nhé, mình ít sài,… nên mình sẽ không quá nói chi tiết 😀

Mình có 1 mẹo cho các bạn đó là “Sử dụng ChatGPT để tạo prompting và dùng những đoạn mô tả đó bỏ vào trong các công cụ Generate ra Wireframe”

Link video: https://youtu.be/BdRD_cSdL44

Điểm mình quan tâm ở công cụ này đó là làm sao để mình sài, và khi có kết quả được tạo ra => Khi mình bàn giao dự án cho người khác, họ vẫn tiếp tục sử dụng được resource mình đã tạo ra trước đó và họ điều chỉnh, chỉnh sửa. => Các bạn nhớ chọn công cụ phù hợp nhé. Mình thì mình vẫn trung thành với Figma 😀

Ngoài việc sử dụng AI để vẽ, mình còn dùng Pinterest, Behance để tham khảo các ideas để vẽ Wireframe sao cho hợp lí.

Viết lệnh SQL

Mình cũng hay sài để kiểu query, hoặc thậm chí các vấn đề hơi thiên về code tíu là mình sài AI để hỗ trợ.

Dĩ nhiên là yêu cầu người viết cũng cần có kiến thức sẵn về SQL để thực hiện đọc hiểu và xác thực tính chính xác của câu lệnh cho AI tạo ra.

Phần này khá phổ biến nên có rất nhiều AI hỗ trợ, mình thì sài Poe có sẵn ChatGPT, Claude, thì mình sẵn sài những con này luôn.

Bạn có thể xem video dưới đây biết biết cách sài nha.

TÓM TẮT cách sử dụng

Some best practices:

1) Set the context

2) Give ChatGPT a role to play (ex: SQL expert)

3) Describe your table(s)

4) Tell the AI what you want a query to do

 

Link video: https://youtu.be/RVYtfKZNYNM

Nghiên cứu domain knowledge

Mình làm ở mảng blockchain, và dự án đi khá nhanh. Như một bài mình từng đề cập trước đây là khi làm các dự án Blockchain, tỉ lệ cao là hay đi copy lẫn nhau rất nhiều, ví dụ ứng dụng A có trên blockchain Ethereum, nhưng loại ứng dụng A lại chưa có trên một mạng mới, ví dụ Sei blockchain, thì mình sẽ tham khảo các dự án đã build sẵn đó (dự án A), đọc code, đọc tài liệu, cách nó hoạt động.

Các bạn có thể tham khảo các tip sau để nghiên cứu các Domain Knowledge mà các bạn chưa hiểu, hoặc chưa làm qua để học thêm cái mới, hoặc là dự án bắt buộc làm nhưng mình có kiến thức chưa đủ nhiều.

Mình sài Poe, và sài lõi Claude.AI (Claude-3.5-Sonnet) để thực hiện

Mình có những tips sau cho bạn để thực hiện.

Tip 1: Yêu cầu tóm tắt.

Thường thì các dự án blockchain hay có whitepaper, hoặc docs cho Developer, Users.

Thì mình sẽ tải file về, hoặc gửi link docs cho AI, bảo nó tóm tắt nhanh để mình hiểu.

Bước này chính là bước để mình hiểu tổng quan về cách dự án nó hoạt động.

Thậm chí có thể kêu AI vẽ lưu đồ để hiểu cách mà hệ thống đang chạy.

Tóm tắt docs với Claude - Hoàng Phan Blog
Tóm tắt docs với Claude – Hoàng Phan Blog

Trong quá trình tóm tắt, có thể bạn chưa hiểu hết thì có thể hỏi lại kỹ hơn để nó giải thích

Tip 2: Hỏi lại những gì AI trả lời/giải thích, để nó trả lời rõ hơn.

Ở bước này bạn có thể đặt lại câu hỏi với ý rõ hơn cho từng phần nhỏ, vì AI cũng không phải thần thánh do đó đôi lúc trả lời thiếu ý, hoặc chưa hiểu rõ kiến thức đó => Hỏi lại

Khi chưa hiểu bạn có thể hỏi lại AI để giải thích rõ hơn
Khi chưa hiểu bạn có thể hỏi lại AI để giải thích rõ hơn

Tip 3: Giải thích như một trẻ em

Thật ra nhiều lúc AI trả lời cũng hơi hơi khó hiểu, do đó bạn hãy bảo nó giải thích như một đứa trẻ em (độ tuổi cỡ 10 hoặc nhỏ hơn), thì nó sẽ giải thích và ví dụ đơn giản để bạn dễ hiểu.

AI giải thích như trẻ em sẽ giúp bạn dễ hiểu hơn
AI giải thích như trẻ em sẽ giúp bạn dễ hiểu hơn

Tip 4: Đặt Q/A, hoặc kiểu câu hỏi giả định

Thường thì trong quá trình giải thích, bạn cần hỏi ngược lại AI khá là nhiều, một trong những câu hỏi mình hay đặt ra là câu hỏi “Giả định”

Ví dụ ở bài toán này mình sẽ hỏi lại là “Có khi nào tiền người dùng bỏ vào Vault thì sẽ bị giảm lợi nhuận (tiền bị âm) không?”

Câu hỏi giả định sử dụng AI
Câu hỏi giả định sử dụng AI

Tip 5: Bảo AI cung cấp thêm keyword để nghiên cứu 

Khi bạn nghiên cứu, thường có nhiều từ khoá để bạn học thêm kiến thức liên quan đến dự án, do đó việc hỏi thêm keyword để tự nghiên cứu đi details hơn sẽ giúp bạn hiểu dự án hơn.

Hỏi AI thêm về Keyword
Hỏi AI thêm về Keyword

Sau khi có danh sách => Bạn bảo nó tiếp tục giải thích các keyword đó.

Tip 6: Sử dụng thêm nhiều nguồn tài liệu khác nhau

Ngoài ra bạn nên cung cấp nhiều nguồn tài liệu khác nhau để AI học và cùng trao đổi => Từ đó nắm rõ kiến thức hơn.

Đọc code và giải thích cách code hoạt động

Như bài toán ở trên, lúc mình tìm hiểu thì cần đụng tới code, hoặc như bài toán subscription mình từng viết trước đây thì cần đọc hiểu API.

Do đó mình luôn nhờ ChatGPT/Claude hỗ trợ trong việc giải thích code, mình thì hay tải code về + attach code vào trong AI để nó đọc và giải thích cách hoạt động.

Nhờ AI giải thích code - Hoàng Phan Blog
Nhờ AI giải thích code – Hoàng Phan Blog

Và từ đó sẽ hiểu nghiệp vụ của dự án chi tiết hơn => Mà hiểu rồi thì lúc thực hiện checklist, viết các case test cụ thể hơn

Hỗ trợ phần UX Writing

AI có 1 lợi thế rất tốt về ngôn ngữ, do đó mình luôn tận dụng để AI hỗ trợ mình trong việc viết các UX writing khi làm UI cho các dự án.

Ví dụ như 1 tooltip mình không biết phải nên hiển thị gì cho gọn mà đọc dễ hiểu, mình viết những ý của mình ra, rồi bảo AI nó viết lại một số câu phù hợp, và mình đọc cũng như chọn lựa cái nào phù hợp nhất.

UX Writing - Hoàng Phan Blog
UX Writing – Hoàng Phan Blog

 

Viết docs cho user (User Guide)

Mình hay sài AI để viết docs, đặc biệt là docs viết tiếng Anh.

Input đầu vào là mình hay bảo nó re-write lại nhưng viết hay hơn, dùng từ vựng của level B1 trở xuống (thường mình bảo nó viết theo trình độ A2-B1)

Ở phần này bạn chat và cung cấp ngữ cảnh đầy đủ, ideas từ bạn nó sẽ viết lại khá hay.

Bạn có thể đọc docs này của seitrace.com, mình dùng AI hỗ trợ rất nhiều.

https://docs.seitrace.com/

User docs được viết bằng AI
User docs được viết bằng AI

Tạo idea dự án

Này chắc các bạn cứ search google là ra nhiều video hướng dẫn lắm. Mình thường nghĩ ra 1 ideas, và trong đầu mình đã phân tích sẵn những cái mình muốn, nhưng nằm ở mức chưa quá rõ ràng details, nhưng về mặt tổng quan đã có.

Lúc này mình sẽ xem AI là một người bạn chuyên gia trong mảng đó, và mình sẽ hỏi đáp, rồi chia sẻ + hỏi cảm nghĩ của con AI về cái ý tưởng đó, rồi bảo nó cho những ý tưởng tương tự 😀

Cái này hơi mơ hồ, với lại mình không thể chia sẻ mấy cái đoạn chat mình đã nói chuyện với AI, các bạn tự nghiên cứu thêm nhé, mình chỉ share ideas thôi.

Tóm tắt nội dung cuộc họp

Otter.ai => Công cụ này các bạn search và sài đi 😀 hịn đó.

Kiểu như vào google meet hoặc một công cụ họp khác như Team, Zoom => sẽ bật con AI lên để sử dụng, nó sẽ hỗ trợ việc ghi lại nội dung cuộc họp, rồi tóm tắt.

Với việc sử dụng cả tháng nay mình thấy nó ghi nhận và tóm tắt khá chính xác nha.

Nó còn tạo sẵn luôn các action cần phải thực hiện luôn (kiểu như tasks – đầu việc)

Theo công cụ này bảo thì nó hiện tại đang hỗ trợ English (US, UK), Spanish, French.

“We currently only support transcribing in English, Spanish, and French; however, we hope to support more languages in the future. Stay tuned!”

Hỗ trợ viết mail, report, viết nội dung tuyển dụng,…

Thiệt là mình sài AI hỗ trợ phần viết khá nhiều, đặc biệt là viết tiếng Anh, xưa môn ngữ văn, viết văn có 5/10 điểm à => Tiếng Anh viết cũng dỡ.

Mình cứ viết ý, bảo AI nó re-write lại, hoặc thậm chí là copy từ nguồn khác :v chả lẽ viết lại y chang => Bỏ qua AI nó đổi lại cho :)))

Mà nó viết format khá ok á nha, ae cứ thử nhé.

Mình đã áp dụng cho:

  • Viết email
  • Viết nội dung tuyển dụng
  • Viết Report
  • Chỉnh sửa proposal
  • …

Học tiếng Anh

Đối với mình, để làm BA mà sử dụng tiếng Anh giao tiếp được thì trình độ khoảng rơi vào C1 (theo chuẩn IELTs, một số chuẩn khác C1 đôi lúc cũng hơi ảo, kiểu dễ)… 

Thì việc mình nâng cao trình độ tiếng Anh lên việc dùng AI cũng là một lựa chọn tốt.

Mình có sài Elsa AI (premium) để luyện phát âm.

Ngoài ra thì có luyện nói với giáo viên tiếng Anh của mình, chắc các bạn thường xuyên đọc blog mình cũng biết mình có tự mở một trung tâm tiếng Anh có thuê giáo viên Philippines dạy 1 kèm 1.

Hoặc sài con ChatGPT 4o á, cũng đang hỗ trợ khá tốt, mình đã test rồi, nhưng bạn nào đã có kỹ năng nói rồi thì luyện với nó sẽ tốt hơn với việc các bạn mới. => Này các bạn cứ search youtube là có mấy video test á.

Viết code/build app

Mình thì lai lai giữa BA, PM, QC, UI Design, rồi cả Dev nữa… không quá giỏi dev nhưng hiểu logic và có thể tự build 1 sản phẩm từ A->Z dạng như CRM, mini app, các app không quá nặng về hạ tầng.

Do đó việc dùng AI hỗ trợ việc code là 1 lợi thế rất lớn với mình 😀

Mình có dùng con Claude Sonnet và Cursor AI. Ae có thể search hoặc nt hỏi mình để sharing thêm nha.

Kết bài

Ở trên là những công cụ AI mình đã sử dụng để phục vụ cho việc làm IT Business Analyst, hi vọng các bạn có nguồn tham khảo cũng như trải nghiệm và có thể áp dụng vào công việc thực tế.

Categories Business Analyst Chia sẻ

Ứng dụng AI trong công việc IT Business Analyst (phần 1)

by hoangphan Posted on
Ứng dụng của IT trong IT Business Analyst - Hoàng Phan Blog

Hi các bạn đọc giả, lại là Hoàng đây.

Trong thời gian vừa qua, với việc AI được biết đến rộng rãi, đặc biệt là khi OpenAI đã cho ra mắt ChatGPT vào cuối năm 2022 (30/11/2022). Làm cho nhiều người quan tâm cũng như trải nghiệm sử dụng AI, nhưng mình cũng không chắc là nhiều bạn đã thực sử hiểu nhiều về AI và đã áp dụng nó vào công việc được chưa.

Với bài viết này, hôm nay mình xin phép chia sẻ những suy nghĩ và trải nghiệm cá nhân, cũng như qua việc sử dụng AI vào thực tế công việc.

Cần hiểu về AI

Hiện tại, đối với mình thì AI là một công cụ hỗ trợ đắc lực cho mình, với việc sử dụng qua những công cụ như ChatGPT, Claude, Midjourney,… những công cụ hay được nhắc tới. Mình chưa nhắc tới một số công cụ AI trong robot, hay AI trong tự động lái nha, chuỗi tự động hoá, …

Thì những công cụ này sẽ nhận vào 1 input đầu vào (AI Prompting) và gửi cho AI, AI sẽ sử dụng các mô hình học máy để phân tích và hiểu dữ liệu, từ đó đưa ra và tạo những câu trả lời hoặc hành động dựa trên dữ liệu đã xử lý để trả ra cho User. Trong quá trình trao đổi trong một cuộc trò chuyện (1 đoạn chat) thì AI cũng sẻ học tập, cải thiện để phân tích ra những dữ liệu và điều chỉnh cho đáp án phù hợp.

Cách AI hoạt động cơ bản
Cách AI hoạt động cơ bản

Vậy cần hiểu “AI Prompting” là gì?

AI Prompting mô tả hình thức mà con người có thể giao tiếp với AI bằng ngôn ngữ tự  nhiên, để cho AI có thể hiểu và trả kết quả đúng như ta mong muốn.

Và khi ta biết cách tạo AI Prompting để AI hiểu ý muốn của chúng ta và thực hiện theo ý của ta => Ta có thể gọi nó là “Làm chủ và sử dụng AI”

Do đó khi các bạn tìm hiểu và sử dụng 1 công cụ AI nào đó, thì hãy bỏ chút thời gian nghiên cứu về cú pháp trao đổi với AI, mỗi AI lại có một cái prompting cho hiệu quả khác nhau. Việc sử dụng AI có hiệu quả hay không là nhờ cách bạn nghĩ ra Prompting phù hợp nhất.

Hiện nay trên youtube/google chia sẻ rất rất nhiều tips để làm được những điều này. Và các bạn có thể học hỏi, sử dụng AI nhiều từ đó có những kinh nghiệm riêng, viết Prompt A mà chưa đúng thì điều chỉnh, thêm bớt để cho phù hợp hơn, nếu chưa được thì lại tiếp tục gửi Prompting mới => dần dần sẽ tạo thành kinh nghiệm.

Prompting AI - Hoàng Phan Blog
Prompting AI – Hoàng Phan Blog

AI có thể thay thế hoàn toàn một BA không?

Theo mình là không?

Bản chất thì BA là làm những công việc như Gathering requirement, elicitation, … thì giờ khi làm việc BA vẫn sẽ làm những bước đó, AI không thể thay thế, nó chỉ là góp sức thêm, vẫn cần người suy nghĩ và viết Prompting

Nhận định sai về AI

AI không thể giải quyết ngay 1 bài toán lớn, mà ta phải mơn mớn cung cấp dữ liệu, phân rã từng task nhỏ và giao cho AI ⇒ Do đó cũng cần người phân tích/ bóc tách cho dữ liệu đầu vào cung cấp cho AI những dữ liệu phù hợp và đầy đủ. Sau đó là tổng hợp/ đánh giá dữ liệu đầu ra từ AI, vì AI cho rất nhiều insight, và không phải cái nào cũng đúng ⇒ Người sử dụng AI cũng cần có kinh nghiệm về Tech, về BA trước đó để nhận định đúng sai.

Cho ví dụ ở đây về bài toán phân tích luồng subscription trong thanh toán dự án Seitrace của mình:

  • Mình đã hiểu subscription nó hoạt động ra sao
  • Nhờ AI tư vấn những bên cung cấp dịch vụ
  • Mình phải vào đọc tài liệu/ đọc code/API của những dự án đó + nhờ AI support giải thích nhanh
  • Sau khi hiểu ⇒ Nhờ AI đánh giá các bên phù hợp nhất với nhu cầu ⇒ mình check và kiểm chứng lại
  • Tổng hợp luồng tổng quan để đi qua 1 bên cung cấp thứ 3 phù hợp với bên mình nhất ⇒ Và mô tả cách hoạt động cho AI ⇒ AI vẽ luồng Sequence phù hợp.
Đọc thêm  Vẽ diagram sử dụng AI giúp Business Analyst tiết kiệm thời gian

Tức là AI ở đây được sài kiểu như giúp mình làm chi tiết hơn cho một số công việc. Từ một tasks lớn cần 3 ngày giải quyết xong, thì có thể nhờ AI mà ta giảm bớt 1 số công việc chi tiết nhưng lại tốn nhiều thời gian => Từ đó giảm còn 1 ngày để hoàn thành xong task.

Nhưng sẽ làm giảm lượng nhân sự trong một đội ngũ (Tức là dùng AI giúp doanh nghiệp giảm chi phí thuê nhân công)

Ví dụ thực tế là ở công ty mình, lượng việc khá nhiều và nếu trước kia chưa sử dụng AI mình nghĩ phải cần tuyển thêm 1-2 bạn BA để phụ tasks (Bản thân mình là 1 manager nên khá hiểu câu chuyện estimate task). Nhưng với việc mình biết sử dụng AI, làm cho hiệu quả công việc mình tăng lên rất nhiều => từ đó với ngày xưa 3 ngày xong 1 tasks lớn, thì giờ mình vẫn với 3 ngày đó có thể làm thêm 1-2 tasks với độ khó tương tự => Không cần tuyển thêm vẫn cover được.

Giả dụ một công ty với đội ngũ 20 nhân sự BA, và giờ Công ty biết cách đưa AI vào sử dụng, mình chỉ ví dụ là các bạn biết sử dụng ở mức tương đối (trung bình), và giúp các bạn giảm được 20% thời gian thực hiện task => Thì từ 20 nhân sự công ty có thể chỉ tuyển 16 nhân sự… (này là mình ví dụ =)) vì không chắc các công ty có đưa AI vào làm việc hoặc có vi phạm privacy gì không nữa)

Thách thức và lợi thế của người sử dụng AI

=)) Đôi lúc mình cũng cảm giác não mình bớt suy nghĩ logic đi 1 tí, cứ đụng là AI =)) cũng sợ lâu quá bị lụt nghề, hoặc thậm chí giảm đi tính tư duy… giống như xưa sài máy tính cầm tay á => làm giảm khả năng tính nhẩm 😐 đôi lúc kiểu 35 + 18 = XX thì lôi máy tính ra bấm :3 hoặc kiểu gõ lên google để tìm ra đáp án thay vì tính nhẩm (có kết quả nhanh hơn).

Thách thức:

  • Như ở trên có nói, dễ bị phụ thuộc quá nhiều vào nó
  • AI đôi lúc đưa ra insight ẩn => làm ta bị đánh lạc hướng/ đi sai hướng
  • Bảo mật dữ liệu, đôi lúc dùng => dữ liệu bị chia sẻ ra ngoài
  • Chi phí… nếu công ty tự build thì chi phí khá cao, còn đối với User sài bình thường thì như sài ChatGPT mỗi tháng 20$ cũng khá cao nếu bạn không biết tận dụng AI vào việc giúp bạn giảm hiệu suất, cũng như đôi lúc ngại việc trả tiền cho AI
  • Tốn công training, AI mà… cần 1 lượng dữ liệu khá lớn, với các công ty lớn thì dĩ nhiên cần training khá nhiều, còn sài cá nhân cũng phải biết cách nạp dữ liệu cho nó để nó có 1 context, dữ liệu từ đó phân tích và đưa ra đáp án đúng cho bạn.
  • Độ chính xác,… thiệt lòng mà nói thì AI… hiện tại độ chính xác cũng kiểu 80-20 (cảm nhận cá nhân),… mình qua thời gian thấy AI cung cấp dữ liệu khá ổn, đúng được cỡ 80%, còn 20%… hay sai lắm. Vậy lỡ bạn sài và không nhận ra 20% cái sai kia thì … toang. 😐
AI trả lời sai - Hoang Phan blog
AI trả lời sai – Hoang Phan blog

Lợi thế:

  • Tăng hiệu quả công việc: như chia sẻ ở trên rồi
  • Tạo tài liệu, … đây là 1 phần của tăng hiệu quả công việc, giúp ta có thể tạo tài liệu nhanh hoặc với một idea với một số ý nội dung => AI có thể giúp để Gen ra chi tiết hơn
  • Hỗ trợ tăng insight, đôi lúc bị bí ý tưởng, hoặc nghĩ không ra, cho AI 1 input và cố gắng trò chuyện với AI kiểu như AI là một chuyên gia từ đó có thêm nhiều insight + keyword để tìm hiểu thêm
  • Giúp dịch thuật: Giúp tóm tắt thông tin, Q/A, đôi lúc là dịch từ ngôn ngữ khác sang ngôn ngữ “tiếng Việt” cho bạn đọc hiểu.
  • Tìm thông tin/câu trả lời nhanh hơn… với cách trước đây ta sử dụng google để tìm đáp án, như hôm rồi mình tìm số liệu về doanh thu của 1 số competitors, search google tốn rất nhiều thời gian, nhưng sài AI => Nó cho mình kết quả có vẻ nhanh hơn,.. với này cũng tuỳ topic, thông tin mình đang tìm nhé.
  • Hỗ trợ ra quyết định =)) Cung cấp thêm thông tin và gợi ý để hỗ trợ ra quyết định lẹ hơn.

=> Bạn biết sài => là đã có thêm ít nhất 1 lợi thế rồi đó.

 

Bài cũng hơi hơi dài rồi, nên mình tách ra phần 2… sẽ trình bày “BA sử dụng AI trong những công việc nào? dùng AI nào?” và những lưu ý khi sử dụng AI nhé.

Categories Blockchain Business Analyst

Phân tích tính năng subscription

by hoangphan Posted on
Bảng giá thanh toán

Vừa rồi đội ngũ dự án mình đã xây dựng xong những tính năng cơ bản của Seitrace – một dự án Explorer official và lớn nhất trên SEI blockchain, và cũng là explorer đầu tiên hỗ trợ một chain chạy song song EVM/Cosmos.

 

Giới thiệu

Với vai trò là Product Manager của dự án, cũng như sự đặt hàng của nhiều anh em developer trên mạng SEI blockchain về việc sử dụng API miễn phí và có trả phí để lấy dữ liệu on-chain đã visualize về sử dụng trên dự án của họ, mình đã research về cách xây dựng tính năng Subscription/mua API. Bài viết hôm nay mình sẽ chia sẻ những gì mình đã phân tích được một cách tổng quan về:

Tính năng subscription dưới góc nhìn của một Product Owner/ Business Analyst

 

Seitrace
Seitrace

Dữ liệu trả ra API từ đâu mà có?

Nếu bạn nào có phát triển các dự án trên blockchain, sẽ biết là các dữ liệu on-chain sẽ được lưu trữ trên các block, trong mỗi block sẽ chứa nhiều transactions, và các block này sẽ nối lại với nhau tạo thành một chuỗi các blocks

Transactions in blocks
Transactions in blocks
hash of block
hash of block

Còn phía dự án Seitrace, Sẽ kết nối với các node RPC của blockchain => Crawl dữ liệu thô từ blockchain về (thông tin các transactions, blocks, status, smart contracts, …) => decode/xào nấu những dữ liệu đó sao cho dễ dùng => dùng Indexer để lập chỉ mục và lưu trữ các dữ liệu đã xào nấu vào những database riêng của Seitrace để từ đó truy vấn nhanh chóng và hiệu quả.

Và các dữ liệu này sẽ được dùng để hiển thị ra trên ứng dụng Seitrace, và cũng với những dữ liệu này phía dự án cũng cho các bên dự án khác sử dụng thông qua API, nhưng sẽ có những mức phí khác nhau.

Kế hoạch phân tích

Để có thể phân tích đầy đủ thì mình list out ra thành những task nhỏ cần làm

Things to do
Things to do

Mình thì cũng hay phân tích các dự án lớn và đi từ đầu (từ lúc mới có ý tưởng), thậm chí là chưa bao giờ làm qua, nhưng thường ngại các phần thanh toán, vì dính nhiều cái liên quan đến pháp lý, đăng ký theo công ty, chia sẻ lợi nhuận nên thường sẽ research đầu tiên => trong bài toán này mình cũng nghiên cứu phần payment đầu tiên.

Luồng thanh toán

Để tìm bên cung cấp dịch vụ thanh toán, thì cần nghĩ tới việc thanh toán thì có thanh toán 1 lần, hoặc thụ động, và một loại nữa là gọi hằng tháng (subscription) để trừ tiền 😀 Và ngoài ra thì bên hỗ trợ thanh toán phải hỗ trợ cho các bên dự án crypto, thanh toán quốc tế với nhiều quốc gia, có phương thức thanh toán qua crypto.

=> Đối với loại thụ động, hoặc thanh toán 1 lần thì dễ, kiểu như gửi số tài khoản cho user chuyển qua => rồi có 1 bộ listen để xem nếu user đã thanh toán => thì chuyển trạng thái thành công.

=> Đối với loại thanh toán hằng tháng => thì trừ tự động => phải qua một bên thứ 3 và cho accept các loại thẻ, hoặc hỗ trợ kiểu như ví đã nạp tiền sẵn và tự động trừ.

Bảng giá thanh toán
Bảng giá thanh toán

Sau một hồi check qua nhiều phương án thanh toán, mình nhận thấy có những phương án phù hợp nhất:

  • Stripe: https://stripe.com/pricing – phí có hơi cao 1 tíu, có hỗ trợ upgrade, downgrade (nâng gói/hạ gói), hỗ trợ thanh toán qua thẻ, có hỗ trợ các dự án crypto, có hỗ trợ thanh toán qua crypto (USDC), tài liệu gần như đầy đủ nhất 😀 đáng để anh em đọc và học hỏi.
  • Coinbase commerce:  https://www.coinbase.com/commerce – phí rẻ hơn bên stripe, có hỗ trợ refund, hỗ trợ payment 100% = crypto luôn, nhưng chưa hỗ trợ tự động trừ tiền mỗi tháng.

Một số kênh khác các bạn có thể tham khảo trong luồng thanh toán:

  • https://developer.bitpay.com/reference/create-a-subscription
  • https://developer.coingate.com/reference/renew-subscription

Bên mình đã chọn sử dụng Coinbase commerce với 2 lý do, 1. Stripe phí cao :v, 2. Thủ tục Stripe khá rờm rà, mất 1 thời gian dài để contact, làm việc, và sau đó tích hợp, trong khi tính năng này chỉ có 8 tuần để phân tích, thiết kế, phát triển và test => Ưu tiên sài Coinbase, khi lượng user tăng quá nhiều và nhu cầu thanh toán qua thẻ tăng => Tích hợp Stripe sau.

Học tiếng Anh online

Tư vấn học tiếng Anh (159K/h)

1 kèm 1 trực tuyến cùng giáo viên Philippines

Đăng ký ngay

Nhưng… sau khi đã chốt sử dụng Coinbase ở giai đoạn đầu và phân tích luồng xong, tới bước dev & đăng ký tài khoản 😀 Coinbase cũng rườm rà =)) bữa giờ team mình đăng ký đã được 3 tuần rồi mà chưa xong :D, mặc dù công ty bên mình là bên UK luôn mà thủ tục khá lâu :D….

=> Chốt lại là chơi check bằng tay trước, kiểu như tới ngày thanh toán thì nhắn tin cho tụi mua API để gửi bill (hay kiểu số tài khoản á), rồi nó chuyển vào xong rồi check xem tiền vào chưa và apply manual trong Admin dashboard.

=)) Công cốc 1 ngày research và vẽ luồng của mình 😀 – cơ mà đợi khi dự án chạy ổn cũng như lượng người mua API tăng lên thì tích hợp sau cũng được, luồng vẽ rồi sau dev chiến thôi 😀

—

Nhưng ở đây mình cũng sẽ chia sẻ luồng payment cho mọi người xem luôn há.

Với Stripe: (Khi lượng user tăng quá nhiều + có nhu cầu thanh toán qua phương thức truyền thống)

  • Stripe đã hỗ trợ sẵn luồng subscription => Sẽ sử dụng luôn của bên đó (có cả upgrade, downgrade, cancel, …) => Cần đăng ký tài khoản & cài đặt các gói => Seitrace không cần xây dựng “Subscription System“
  • Thường Stripe lại ưu tiên thanh toán qua các kênh truyền thống (credit card, debit card), nên sẽ kết hợp với xử lý qua Coinbase commerce để xuất bill, cũng như thanh toán với nhiều nguồn tiền crypto hơn (BTC, ETH, USDC, USDT, …) từ Metamask (phổ biến nhất trong crypto), Coinbase wallet.
  • Do đó khi một giao dịch được hoàn tất qua kênh Coinbase Commerce => Bên webhook của trả về cho Seitrace & Seitrace trả về lại cho bên Stripe để cập nhật.
  • Vì luồng này khá quen thuộc và docs của Stripe khá rõ => Anh em đọc thêm trên đó nha.

Bước 1: Stripe đưa ra thông tin subscription mỗi tháng

Bước 2: Gọi từ Stripe qua hub của hệ thống mình => Gọi qua bên Coinbase Commerce

Bước 3: User sau khi thanh toán xong => gọi ngược lại Stripe để update theo luồng Upgrade/Downgrade

Trong quá trình trên, ae có thể gọi về system và store data/logs lại nhé

Với chỉ thanh toán qua Coinbase Commerce: (sẽ develop sau khi lượng user tăng lên, cũng như đăng ký được với Coinbase)

  • Với việc đi qua Coinbase commere, và chưa có subscription system => Seitrace phải tự xây.
  • Khi tự xây thì sẽ liên quan đến các luồng upgrade, downgrade, thanh đổi gói, cancel gói, … => mình sẽ nói ở phần dưới của bài viết sau nhé.
  • Thì luồng cơ bản của thanh toán => Khi phát sinh thanh toán (bạn xem sequence diagram ở dưới nhé) – từ bước số 2.

Với việc thanh toán có thể phát sinh từ nhiều luồng (thanh toán lần đầu, thanh toán khi mua thêm credit, thanh toán phát sinh, thanh toán hằng tháng, thanh toán khi thay đổi gói (upgrade/downgrade), …)

Với thanh toán nhưng check manual: (đang develop => này đỡ tốn thời gian đợi accept từ các bên nền tảng 3rd, mà có thể giảm thời gian dev, test => từ đó mục tiêu 8 tuần build xong tính năng (cùng với nhiều tính năng khác release trong giai đoạn này) sẽ dễ dàng hơn)

=)) Luồng này chưa vẽ, tại như luồng qua Coinbase, mà bỏ bớt, bạn đọc có thể xem luồng trên và bỏ đi bước gọi qua Coinbase Commerce API, thay vào đó gửi thông tin thanh toán (Số tiền, thông tin/mô tả thanh toán, địa chỉ nhận tiền, thời gian phải thanh toán) qua email, cũng như trả vào FE để hiển thị lên màn hình, thậm chí có nút share public để gửi qua tin nhắn cho user, có thể có đếm giờ/hoặc không tuỳ logic => Và khi thanh toán xong => vào Admin dashboard update trạng thái thanh toán => tự động gửi mail báo cho user sau khi update trạng thái.

Luồng subscription, upgrade, downgrade

Ở đây mình chỉ copy 1 phần nhỏ luồng cho anh em xem nhé, ae nào khi nào cần làm kỹ thì có thể phân tích kỹ hơn 😀 Share hết bí mật sao được 😀 

Giả sử có các gói Subscription

– Miễn phí (Free): $0/tháng

– Advanced: $100/tháng

– Professional: $200/tháng

Luồng các trường hợp

1. Từ Free -> Advanced

– Trạng thái ban đầu: Người dùng đang sử dụng gói Free.

– Hành động: Người dùng chọn nâng cấp lên gói Advanced.

– Xử lý:

  + Người dùng sẽ được yêu cầu thanh toán $100 cho tháng đầu tiên của gói Advanced.

  + Sau khi thanh toán, gói của người dùng sẽ được nâng cấp ngay lập tức lên gói Advanced.

  + Kỳ thanh toán tiếp theo sẽ là $100 vào cùng ngày tháng sau.

2. Từ Advanced -> Free

– Trạng thái ban đầu: Người dùng đang sử dụng gói Advanced với phí $100/tháng.

– Hành động: Người dùng chọn hạ cấp xuống gói Free.

– Xử lý:

+ Gói Advanced sẽ tiếp tục được duy trì cho đến cuối chu kỳ thanh toán hiện tại.

+ Sau khi kết thúc chu kỳ thanh toán hiện tại, gói của người dùng sẽ tự động chuyển về gói Free.

+ Không có khoản hoàn tiền cho phần thời gian chưa sử dụng của gói Advanced.

3. Từ Advanced -> Professional

– Trạng thái ban đầu: Người dùng đang sử dụng gói Advanced với phí $100/tháng.

– Hành động: Người dùng chọn nâng cấp lên gói Professional.

– Xử lý:

+ Phần tiền đã trả cho gói Advanced sẽ được tính tỷ lệ theo số ngày đã sử dụng trong tháng.

+ Số tiền còn lại sẽ được khấu trừ vào chi phí của gói Professional.

+ Người dùng sẽ thanh toán số tiền chênh lệch để nâng cấp lên gói Professional.

+ Ví dụ: Nếu người dùng đã sử dụng gói Advanced được 15 ngày, số tiền còn lại là $50. Người dùng sẽ cần thanh toán thêm $150 để nâng cấp lên gói Professional.

+ Ngay sau khi thanh toán, gói của người dùng sẽ được nâng cấp lên gói Professional.

4. Từ Professional -> Advanced

– Trạng thái ban đầu: Người dùng đang sử dụng gói Professional với phí $200/tháng.

– Hành động: Người dùng chọn hạ cấp xuống gói Advanced.

– Xử lý:

+ Gói Professional sẽ tiếp tục được duy trì cho đến cuối chu kỳ thanh toán hiện tại.

+ Sau khi kết thúc chu kỳ thanh toán hiện tại, gói của người dùng sẽ tự động chuyển về gói Advanced với phí $100/tháng.

+ Không có khoản hoàn tiền cho phần thời gian chưa sử dụng của gói Professional.

Tổng Kết

– Nâng cấp (Upgrade): Người dùng sẽ phải thanh toán chi phí chênh lệch tương ứng với số ngày còn lại trong chu kỳ thanh toán hiện tại.

– Hạ cấp (Downgrade): Người dùng sẽ tiếp tục sử dụng gói hiện tại cho đến hết chu kỳ thanh toán và không có khoản hoàn tiền cho phần thời gian chưa sử dụng của gói cao hơn.

 

Ngoài ra còn luồng từ monthly qua yearly/annual, và ngược lại kết hợp với việc từ gói rẻ -> gói mắc hơn, hoặc mắc hơn -> rẻ hơn. Các trường hợp này sẽ tuỳ logic của từng dự án mà thay đổi khác nhau 1 ít. Và cũng khá phức tạp khi có trường hợp gói mắc về gói rẻ, nhưng vì từ monthly qua annual => có phát sinh phí, nghĩa là mắc qua rẻ nhưng lại không phải luồng downgrade như ở trên có đề cập 😀

 

Đối với bên Seitrace =)) sau khi mình phân tích đủ các luồng, Dev khóc => quyết định không chơi luồng upgrade/downgrade ở giai đoạn này vì nguồn lực build không đủ => chặn luồng này luôn, chỉ hỗ trợ upgrade/downgrade, hoặc chuyển monthly qua yearly hoặc ngược lại thì đều phải nhắn tin :))) 

Thật ra thì với mình khi phân tích mình nhìn đủ các trường hợp để mang ra trao đổi, còn với tư duy xây dựng product mình hay build basic với mục đích chính là sử dụng được, cover được các case nhưng có thể làm manual ở giai đoạn đầu, và sau đó sẽ tự động hoá dần, điều này nằm sâu trong tư duy của mình từ khi chuyển qua làm product, thậm chí khi mình tự xây trung tâm tiếng Anh enrichenglish.net cũng đang áp dụng như vậy, chạy được, ra doanh thu rồi khi có thời gian, nguồn lực sẽ nâng cấp dần dần, cũng như biết chỗ nào sai và sửa.

Bạn xem luồng manual bên mình ở dưới nhé.

 

Subscription first time

Ở luồng này thì mình viết bằng text với idea cơ bản nhé:

  • Xét xem đang là sub lần đầu => Server xử lý và tính giá tiền, thời hạn + thông tin các kiểu
  • Trả cho UI để hiển thị => user confirm => tạo bill và gửi yêu cầu qua Coinbase để tạo bill bên Coinbase
  • Trả thông tin lại cho user (UI và email) => user thanh toán
  • => Đợi user thanh toán và Webhood của Coinbase trả kết quả => update gói & thời hạn mới của gói cho user ở phía Sub Mgmt Server + gửi mail successful
  • Đối với không thanh toán => huỷ bill sau khi hết hạn.

Trước khi sub => Thì cũng có các luồng liên quan đến đăng nhập, tạo gói free, xử lý các logic để phân biệt đang gói nào, và đang thực hiện luồng sub lần đầu hay upgrade/downgrade,….

Payment monthly

  • Có 1 con Cronjob sẽ quét DB subscription daily => phát hiện anh nào tới hạn thanh toán (có thể set là 5 ngày trước khi hết hạn)
  • Tạo thông tin thanh toán và gửi qua Coinbase Commerce tạo bill
  • => gửi thông tin bill qua email cho user
  • => Đợi user thanh toán và Webhood của Coinbase trả kết quả => update gói & thời hạn mới của gói cho user ở phía Sub Mgmt Server + gửi mail successful
  • Đối với không thanh toán => thì quét nhắc lại trước khi hết hạn 24h
  • Trường hợp hết hạn mà không thanh toán => update gói về free (cancel package) + gửi email cancellation

Sử dụng API => Trừ tiền

Luồng này thì có nhiều phương án, các bạn có thể tham khảo thêm từ các subscription API khác nhé, mình chỉ liệt kê 1 số luồng và không nói quá sau, bạn nào làm tới tính năng này thì research thêm sau nhé.

  • Dựa theo gói => giới hạn tính năng, lượt request theo giây, giờ, ngày, tháng,… và khi hết thì không được sài nữa (Giống như đăng ký 4Gb của các nhà mạng 😀 tốc độ nhanh chậm, ngày nhiêu Gb :v hết thì không được sài nữa)
  • Cũng là trường trên nhưng mà hết thì được sài với tốc độ chậm 😀
  • Cũng là trường hợp trên nhưng khi hết thì tính giá riêng (thường mắc hơn rất nhiều so với mua gói, và trừ tiền dần trong tài khoản) => này khó áp dụng khi không có cà thẻ hoặc tiền có sẵn trong tài khoản => có thể ignore.
  • Cũng là trường hợp đầu tiên, nhưng khi hết thì được mua thêm những gói mini khác (ví dụ như mua thêm 1Gb sử dụng trong 24h với tốc độ của gói đã mua trước đó)
  • Hoặc cho sài tẹt ga, nhưng cũng có giới hạn tốc độ theo giây, theo giờ (kiểu như mua gói mạng dây Viettel trả tiền theo tháng hoặc 12 tháng tặng 1 tháng, có tốc độ đó thì mạng chạy chậm hơn, nhưng được sài tẹt ga)
  • Hoặc quy ra thành Credit, cứ mỗi lượt sẽ trừ tiền bớt, sài nhiều thì hết sớm, sài ít thì lâu hết, có thể mua thêm gói mini nếu hết 😀
  • Hoặc là mua thêm cộng dồn (kiểu trả nhiêu sài nhiều rồi trừ dần – như tiền nạp vào thuê bao di động)

Và tuỳ theo gói sẽ có các luồng trừ tiền/limit khác nhau.

Bên mình sau khi nghiên cứu thì thấy hướng credit sẽ dễ develop hơn, ít tốn nguồn lực => chọn và sau này tuỳ nhu cầu của người dùng cũng như áp dụng số liệu product research để thay đổi sau.

Bên mình cũng thêm luồng khi sử dụng gần hết data => sẽ gửi email báo (một dạng warning) => thì thêm con cronjob quét daily.

Về giao diện

Về mặt giao diện thì có thể phân ra các nhóm màn hình sau:

  1. Màn hình thông tin bán các gói API, đăng ký mua (kiểu như mấy trang landing page quảng cáo á) => do có thanh toán => tích hợp UI thanh toán vào (ví dụ đăng ký 4G, các bạn vào app xem list gói + nhấn đăng ký + confirm thanh toán, hoặc nhắn tin qua tổng đài đăng ký ấy).
  2. Luồng quản lý gói & dữ liệu đã sử dụng, ở đây sẽ hiển thông tin gói chi tiết, số lượng credit, lưu lượng, limit đã sử dụng, còn lại bao nhiêu, và có nút mua thêm các gói mini, cũng như nơi tạo và quản lý API key. Kèm theo đó là dữ liệu bill history, API usage logs, chart usage các kiểu
API billing history
API billing history
API key stats
API key stats

3. Giao diện phía quản lý của Seitrace (Admin dashboard)

  • Danh sách customers
  • Customer details + thông tin gói, subscription, change plan for user,….
  • Nơi cấu hình các package (Gói, thông tin gói, các limit, giá gói theo tháng, năm, giảm giá,….)
  • Cấu hình giá trị của từng API theo credit, … rồi bên Pro, Free thì như thế nào,…
  • Ngoài ra còn các giao diện tính năng khác, tuỳ theo người phân tích có thể đưa ra cho phù hợp

Kết luận

  • Bài toán subscription được nhiều bên xây dựng rồi, bạn có thể tham khảo các logic mình phân tích, và ánh xạ lên nhiều bên khác nhau để chọn cho phù hợp, hoặc tự build.
  • Với mỗi dự án thì nhu cầu sẽ khác nhau do đó bạn có thể linh hoạt điều chỉnh tính năng
  • Dự án bên mình nguồn lực khá ít, do đó xây dựng theo hướng đơn giản trước, khi doanh thu và nhu cầu tăng => sẽ mở rộng dần
  • Đối với người phân tích dự án thì nhìn rộng và phân tích các trường hợp có thể xảy ra, thậm chí có thể phân tích hết trước dù khi làm chỉ là 1 phần nhỏ, hoặc chọn phân tích kỹ phần sẽ làm và phần chưa làm có thể chỉ phân tích luồng chính và đi details sau khi cần.
  • Luồng này liên quan đến tiền của người dùng do đó phần security khá quan trọng 😀 anh em cũng lưu ý kỹ nha.
  • Phần thanh toán hằng tháng thì nên sài qua bên thứ 3 nếu cho thanh toán qua thẻ, vì liên quan đến nhiều license và quy định bảo mật 😀
  • Anw, bài viết khá dài, cảm ơn bạn đã đọc đến đây nha <3
Categories Chia sẻ

Bài học rút ra từ việc leo núi

by hoangphan Posted on
Bài học rút ra từ việc leo núi - Hoàng Phan Blog

Giới thiệu

Từ lâu mình đã thích việc leo núi và enjoy cái moment lúc ngắm nhìn thiên nhiên, cây cối. Khi còn ở Sài Gòn, giai đoạn sinh viên thì kiểu thích và đi leo mấy núi như núi Bà Đen, Chứa Chang đồ á.

Lúc về Nha Trang thì mình leo núi thường xuyên hơn, trung bình 1 tháng 2-3 lần leo núi, cứ mỗi cuối tuần thì chạy xe trong thành phố rồi leo thôi, rất tiết kiệm thời gian khi chỉ tốn 2-3 tiếng cho 1 lần như vậy, nhiều thì những núi cao hơn sẽ mất 7-8 tiếng. Vừa để rèn luyện sức khoẻ, vừa để ngắm nhìn thiên nhiên và giảm bớt áp lực/stress từ công việc.

Leo núi ở Nha Trang
Leo núi ở Nha Trang

 

Bài học rút ra

Sau những lần leo núi mình thấy có những cái khá giống với việc đặt mục tiêu và đi tới mục tiêu. Để mình kể các bạn từng chi tiết riêng, sau đó sẽ đưa ra những nhận định nằm ở cuối nhé.

Chuyện dễ bỏ cuộc khi leo núi

Những thời điểm đầu mình leo núi, mình thấy khá chật vật và chưa biết cách leo làm sao tiết kiệm sức và tới đỉnh nhanh.

Thực tế là khi mình leo, bắt đầu đi mình leo rất nhanh, vì lúc đó còn sức, còn khoẻ, chân chưa mỏi. Nhưng mới leo được cỡ 1/20 đoạn đường cần leo thì thở hổn hển, tim đập nhanh. Đặc biệt là lần đầu leo cảm giác như muốn bỏ cuộc dù mới đi được cỡ 1/5 đoạn đường sau nhiều lần nghỉ mệt. Những lần đầu leo là cứ khúc đầu tăng tốc, leo nhanh được 1 đoạn ngắn, xong nghỉ mệt đâu đó 5-10 phút, hết mệt lại leo nhanh, rồi lại nghỉ mệt 5-10 phút, càng về sau càng nghỉ mệt nhiều hơn. Thế là tổng thời gian leo cứ thế bị tăng lên rất nhiều, mà tại những thời điểm dừng lại để nghỉ mệt lại càng có suy nghĩ bỏ cuộc, càng về sau cái suy nghĩ bỏ cuộc nó càng tăng lên.

Từ bỏ - Hoang phan Blog
Từ bỏ – Hoang phan Blog

Mình liên tưởng tới lúc xưa khi còn là sinh viên và những năm đầu làm việc, ngoài việc học và công việc trên công ty mình hay có các ý tưởng thêm và cố gắng tự xây dựng/build sản phẩm riêng của mình. Giai đoạn đầu của các dự án mình lao vào làm hì hục, cày đêm cày khuya liên tục, lúc đó kiểu rất hào hứng nên dành rất nhiều thời gian cho nó, quên nghỉ ngơi luôn ⇒ hay bị burn out ⇒ dẫn tới chán nản và bỏ cuộc ⇒ cuối cùng cũng không đi tới đâu cả và bỏ đi rất nhiều công sức đã làm trước đó rất sớm. Giống y chang việc leo núi, nếu không leo cùng bạn, không có người đốc thúc để cố gắng sau nhiều lần dừng lại nghỉ mệt thì mình đã bỏ cuộc ngay những bước đầu tiên. Còn việc build dự án riêng lại không có ai đốc thúc nên mình đã bỏ cuộc rất nhiều lần.

Leo núi từng bước một, ít khoảng nghỉ

Nhớ giai đoạn đầu vừa về Nha Trang, leo núi gặp một ông người Đức 65 tuổi, ổng hay leo canh khoảng 9g sáng. :v mình và bạn mình leo lên trước ổng khoảng đâu 15 phút, nhưng ổng leo đi sau ⇒ rồi đi ngang và nói chuyện với tụi mình ⇒ cuối cùng là mình đi được nữa đường, ông chú đó đã leo lên tới đỉnh, lúc đi theo được tới mốc 3/4 đường thì lại gặp ông chú đi xuống và nói chuyện với tụi mình, cuối cùng khi lên tới đỉnh :v ông chú đã xuống gần tới chân núi.

Mới đầu mình cứ nghĩ chắc là do ông chú leo thường xuyên nên quen với việc leo núi, thành ra ổng leo nhanh. Nhưng sau 1 thời gian leo mình lại thấy leo thường xuyên chỉ là 1 yếu tố, nó còn nhiều yếu tố khác nữa mà sau nhiều lần leo núi mình nghiệm ra được. Trong đó yếu tố mình thấy giúp mình lên đỉnh núi vừa ít mệt vừa tiết kiệm thời gian đó chính là đi từng bước một thật chậm rãi.

Tức là trong suốt quá trình leo, đặc biệt là khúc đầu leo, mình sẽ leo thật chậm rãi từng bước một thôi – giống như việc giữ sức vậy đó. Nhờ vào việc leo từng bước một ngắn, đều, không bước vội thì nhịp tim của mình nó chỉ tăng lên 1 tíu chứ không tăng lên vượt ngưỡng ⇒ từ đó toàn bộ cơ thể (đặc biệt là tim) rất ít mệt ⇒ dẫn tới việc không cần nghỉ nhiều ⇒ thậm chí là không cần nghỉ mà leo 1 mạch lên luôn 😀 (giống ông chú người Đức 65 tuổi mình nói ở trên)

Ở trên mình có nói đó, 1 lần nghỉ ngơi mất đâu 5-10 phút, giả sử 1 lần leo nên ngọn núi cao có 330m à, mình phải nghỉ ngơi tận 10 lần, tổng thời gian nghỉ ngơi trung bình mất tiu 50 phút 😀 =)).

Mà thời gian nghỉ 50 phút này là còn dài hơn tổng thời gian mình leo lên tới đỉnh sau khi đã rút ra được bài học này 😀

Từng bước nhỏ, đạt được mục tiêu
Từng bước nhỏ, đạt được mục tiêu

Rồi mình lại liên tưởng tới lúc làm việc, học tập và dự án cá nhân. Cứ có chiến thuật và đi từng bước một, làm liên tục và đều – lâu lâu ngừng lại nghỉ ngơi nhẹ thôi rồi tiếp tục. Không nên để rơi vào tình trạng burn out thì vẫn còn sức để chiến tiếp và theo dự án được dài hơi hơn, không chắc sẽ thành công nhưng giúp mình đi được dài hơi với một ý định gì đó. Mình đã áp dụng và thật sự thấy có hiệu quả cho một số dự định cá nhân, đừng quá sức và bỏ cuộc là được.

Kinh nghiệm và sức bền là điều cần khi leo núi

Núi nhỏ – thấp thì không nói, nhưng với những ngọn núi cao, dài, địa hình khó khăn thì kinh nghiệm và sức bền là điều cần lưu ý rất nhiều.

Ví dụ như ở trên mình ngẫm ra được việc bước từng bước nhỏ và đều là sau 1 thời gian leo ở Nha Trang mình mới tự nhận ra ⇒ đó là nhờ nhiều lần leo và quan sát nên mới có kinh nghiệm. (Mặc dù trước đó có leo ở núi Bà Đen, Chứa Chang nhưng lúc thời điểm đó mình rất gầy và kiểu khoẻ nữa =)) thành ra leo thấy easy quá mà k để ý luôn, sau về Nha Trang tăng so với xưa 15 Kg nên khác lắm 😀 ).

Còn sức bền thì khỏi nói rồi, leo các ngọn núi dài, hoặc đơn giản như núi Cô Tiên ở Nha Trang có 3 ngọn, để leo hết cả 3 ngọn trong thời gian ngắn thì cũng cần có sức bền. Mà sức bền cũng nhờ những lần leo núi trước đó hoặc rèn luyện các môn thể chất khác để tăng lên.

Vậy trong công việc và học tập cũng y chang luôn, phải làm thì mới có kinh nghiệm, tự ngẫm ra kinh nghiệm cho bản thân, rồi sức bền khi chiến các dự án dài hơi, fix bugs liên miên. Nên khi học hành thì cũng cần rèn luyện, ví dụ việc học tiếng Anh – khúc đầu học ít phút thôi cho quen dần, đỡ phải nản cũng như rút ra các bài học ⇒ rồi sau đó sẽ có kinh nghiệm và sức bền thì tăng độ khó của bài học, cũng như tăng thêm thời gian học. Hoặc là với đi làm, giờ muốn làm dự án khó và dài hơi thì trong khi đang làm các công ty bây giờ nè, rãnh thì xin thêm dự án đi, hoặc tốt hơn thì nên tự nghĩ ra ý tưởng rồi tự build, như ông anh “T” trong bài viết mình có đề cập trước đó, ảnh tìm thêm job ngoài để làm vừa để học hỏi thêm kinh nghiệm nhanh nhất, vừa là để kiếm thêm thu nhập, thêm nữa ảnh còn build thêm các thiết kế cá nhân để đưa vào portfolio. Rồi trước khi ảnh làm các dự án lớn, ảnh cũng học rồi rèn luyện từ các dự án nhỏ đi lên để lấy kinh nghiệm và sức bền từ đó có thể chiến được các dự án dài hơi hơn 😀

Uống nước ít hơn (nhưng đủ) trong quá trình leo núi

Khúc đầu mình leo núi thì hay mang nhiều nước lắm, vì sợ thiếu nước, chưa kể vì leo núi hay mệt nhanh khi khúc đầu cứ có sức nhiêu là leo nhiêu ⇒ mệt nhiều ⇒ dừng nhiều ⇒ uống nước nhiều.

Núi cô Tiên thời gian đầu mình leo, lên được một ngọn núi đầu tiên sẽ bay 1,5l nước. Nên lúc nào mình cũng mang cỡ tầm 2-2,5l cho 1 lần leo núi là 1 đỉnh.

Nhưng những lần uống nước đó hay có tác dụng phụ, kiểu như xốc hông nè, mất nước điện giải nè, mắc tè nè.

Một mặt khác nữa là mang nhiều nước thì nặng hơn, làm mình cũng kiểu nhanh mệt hơn 1 tíu.

Đặc biệt mấy lần đầu leo, nghỉ mệt nhiều thì lại uống càng nhiều nước =)).

So với khi làm việc mình cũng thấy giống y chang, đang làm việc chán nản/mệt mỏi cần nghỉ ngơi thường xuyên thì lôi điện thoại lướt lướt facebook, insta, twitter (x) các kiểu, càng burn out mà không có kinh nghiệm điều chỉnh là càng lao đầu vào sài lướt mạng xã hội các kiểu nhiều hơn ⇒ Nếu ai hiểu về dopamine thì sẽ biết là các việc như vậy làm tăng dopamine lên rất cao, sau đó cơ thể phải tự giảm xuống thấp hơn mức trung bình để cân bằng, và từ đó càng làm cho ta nản việc tiếp tục làm việc. Mà việc cân bằng này cũng cần có kinh nghiệm và sự quyết tâm nha.

Dopamine bị crash khi bị sử dụng sai cách
Dopamine bị crash khi bị sử dụng sai cách

Do đó nếu chỉ giải trí ở mức vừa đủ, không quá lạm dụng, hoặc dùng các phương án như tập thể dục, ngắm cảnh, healing đồ các kiểu thì dopamine tăng ở mức an toàn giúp ta làm việc hiệu quả hơn.

Và việc leo núi, uống nước vừa phải hợp lý cũng sẽ giúp ta giảm bớt những tác dụng phụ đi. Mà mình nghĩ cũng từ nhiều yếu tố, ví dụ có kinh nghiệm, biết cách leo núi từng bước nhỏ đều đặn cũng giúp cho việc uống nước ở mức vừa đủ, đi đều, ít mệt ⇒ ít khát và ít cần bổ sung nước hơn. Mà nhớ ông chú 65 tuổi ở trên không? Ổng leo không mang nước luôn =)) ổng cầm có 1 cái cây gậy, quần đùi, áo 3 lỗ leo núi thôi, chứ không mang theo gì cả.

P/s: Mình nghĩ chắc là sẽ có người phản biện là sao không uống nước tăng điện giải cho có điện giải trở lại – … ờ thì mình lấy ví dụ để suy ra cách áp dụng cho công việc thôi… và việc dùng nước tăng điện giải so qua với công việc thì kiểu dùng các cách như tập thể dục, ngủ đủ giấc để cân bằng dopamine tốt nhất ấy là giống nhau.

Chọn thời điểm leo núi.

Thật ngu ngốc khi 2-3 tháng đầu leo núi, mình luôn chọn leo từ 9g sáng và xuống núi đâu đó lúc giữa trưa =)).

Giữa trời tiết mùa hè nắng nóng mà leo giờ đó đúng là kiểu đi phá sức á chứ, thời gian đầu vì leo khung giờ đó mà mình thấy kiểu mệt, da cháy nắng luôn, mà bị mất sức + cần bổ sung nước rất nhiều, dẫn đến nhiều thứ hơn.

Sau này khi nhiều người leo xuống núi cũng là lúc mình leo lên người ta hay bảo là nên leo sáng sớm hoặc chiều tối, mình đổi qua khung khác để leo thì kiểu chả thấy mệt gì cả (do lúc đó đã kèm theo việc áp dụng chiến thuật đi từng bước ngắn và đều)

Thì việc này cũng giống như đi làm, hay xây dựng dự án cá nhân, luôn cần chọn đúng thời điểm và khung giờ hợp lý. Ví dụ như có những người làm việc hiệu quả vào ban đêm ⇒ thì ban ngày làm các việc không cần quá tập trung, ban đêm thì các việc khó, cần suy nghĩ nhiều, tập trung nhiều. Mà đôi lúc cứ nghĩ là mình hợp khung giờ đêm rồi cứ thức 2-3 giờ đêm làm để hại sức khoẻ cũng không đúng nhé (y chang việc leo núi 9g sáng – 12g trưa của mình). Sao không thử ngủ sớm rồi dậy sớm thử khung giờ sáng sớm xem sao 😀 (như mình chọn đổi khung giờ sang leo từ 3g chiều)

 

Còn khi xây dự án, mình đã và đang làm nhiều dự án thì mới nhận ra việc thực hiện xây dựng/ ra mắt sản phẩm đúng thời điểm rất quan trọng, ví dụ các dự án trong thị trường Blockchain, năm cuối 2021-cuối 2023 là thời điểm rất ít dự án ra mắt, vì giá thị trường, đặc biệt BTC đang có xu hướng giảm, nên đa số các dự án ra mắt thời điểm này ngủm mất tiu, nhưng gần đây thì trường lại sôi nổi trở lại, nhiều nguồn tiền đi vào ⇒ các dự án xây dựng gần đây lại có cơ hội thành công cao hơn. Hay công ty mình cũng vậy, khi làm các dự án, thì mua giảm giá bên mình chỉ nghiên cứu, thử nghiệm và khi thị trường quay trở lại là thời điểm tốt để xây dựng các dự án.

Cần có các bước chuẩn bị trước khi leo núi.

Trong quá trình leo núi, cũng cần có sự chuẩn bị, dù là nhỏ hoặc đơn giản nhưng cũng cần làm đúng và phù hợp.

Ví dụ trước khi leo núi thì không nên ăn quá no, dễ bị xốc hông, nên do đó nên ăn trước ít nhất 30 phút và ăn vừa phải để leo.

Hay là việc mang theo nước, cũng nên mang vừa phải, không quá nhiều, không quá ít ⇒ mà này cũng cần leo và thử nghiệm nhiều lần trước để rút ra kinh nghiệm á nha.

Vừa đủ là tốt nhất
Vừa đủ là tốt nhất

Rồi khi leo cũng cần khởi động trước nữa, chứ không phải bụp cái là leo ngay, dễ bị trật chân khi mà không khởi động.

Rồi để leo được núi cao và dài, địa hình khó thì cần phải rèn luyện trước đó, tập chạy thể dục, rè luyện thể chất, leo núi nhỏ trước, thử nghiệm nhiều lần và tăng dần độ khó, độ cao lên. Chứ lần đầu leo mà đi leo mấy núi mất 7-8 tiếng leo thì dễ toang lắm.

Và trong công việc cũng vậy nốt, cần có sự chuẩn bị.

  • Lúc chưa có kinh nghiệm đi làm ⇒ thì làm dự án mẫu, học kỹ kiến thức, tự thực hành theo tưởng tượng hoặc tìm mentor hỗ trợ.
  • Các kỹ năng cần thiết như chỉnh sửa ảnh, video, kiến thức cơ bản công nghệ thông tin, ngoại ngữ cũng cần phải biết, không quá giỏi cũng được nhưng cần biết để khi cần mà sài tới liền.
  • Việc học có lúc nghĩ nó không cần tới, nhưng lúc cần là có sài liền, chứ đợi lúc cần mới đi học thì tốn thêm mớ thời gian, hoặc đôi lúc nghĩ mà tiếc bị lỡ mất cơ hội. Ví dụ như mình đồng ý nghỉ việc và bỏ ra 100 triệu đi qua Philippines học tiếng Anh, để khi có cơ hội là mình nắm bắt ngay, nhiều lần mình nghĩ nếu không có tiếng Anh thì mình đã lỡ đi cơ hội việc làm như bây giờ, không có những trải nghiệm tốt hơn. Hoặc việc lúc cấp 2, cấp 3 mò về Photoshop cũng là lợi thế khi mà khi đi làm sài những công cụ vẽ như Figma, Balsamiq, XD,… mình chả cần học gì mà cứ vào sài thôi. Hay là kỹ năng nói chuyện trước đám đông, dẫn dắt cuộc họp ⇒ mình đã phải mất hơn 3 năm để rèn luyện, tham gia các hoạt động Đoàn Hội, dẫn dắt các bạn đi tổ chức sự kiện ở nhiều nơi, gặp các cấp lãnh đạo ở các huyện, xã. Kỹ năng bạn học nó sẽ ở trong bạn, có thể thời điểm hiện tại nó chưa bùng nổ, nhưng khi có cơ hội nó bộc phát ra thì việc công việc thuận lợi hay lương bổng tăng gấp nhiều lần cũng có ngày diễn ra thôi :D.
  • Tự rèn luyện thêm trong quá trình đi làm cũng là một bước chuẩn bị cho tương lai, thời gian 8 tiếng 1 ngày đi làm, bạn thường sẽ có ít nhất 1-2 tiếng buổi tối, hãy tận dụng nó đi ⇒ những người chiến thắng/thành công sẽ là những người biết tận dụng khoảng khung giờ đó :D.

Kết luận việc leo núi

😀 Mình lấy cớ việc leo núi để liên tưởng và viết bài, đôi lúc có mấy cái nhìn có vẻ hơi vô lý 1 tíu :D, dưới đây là những điều mình rút ra được:

  • Dễ bỏ cuộc nếu khúc đầu của bất kỳ dự án/ kế hoạch nào cũng làm không có kế hoạch, lao vào chiến, không biết nghỉ ngơi hợp lý.
  • Bước từng bước 1, có kế hoạch rõ ràng, duy trì mỗi ngày 1 ít, nhưng mà thường xuyên và có khoảng nghỉ hợp lý sẽ giúp bạn dài hạn từng bước đi tới vạch đích.
  • Kinh nghiệm và sức bền là cần thiết, do đó hãy cố gắng rèn luyện thường xuyên để nâng cao kinh nghiệm làm việc/học tập và sức bền từ những dự án nhỏ ⇒ sau đó sẽ chiến được dự án khó, phức tạp và dài hạn.
  • Cân bằng cuộc sống và làm việc, không nên để bị burn out, nản trí và sau đó lướt những điều vô bổ trên internet thường xuyên ⇒ tăng dopamine quá độ ⇒ không có hứng thú làm việc nữa.
  • Thời điểm học, rèn luyện và làm là quan trọng, chọn khung giờ bạn làm việc hiệu quả nhất, né tránh thức quá khuya gây hại sức khoẻ, giảm trí nhớ. Khi làm dự án cũng chọn thời điểm thích hợp để làm và ra mắt sản phẩm.
  • Cần chuẩn bị kỹ năng và kiến thức từ sớm, bất kỳ thời gian rãnh nào cũng quý giá cả, tận dụng phù hợp để nâng cao kỹ năng.

Qua bài viết, hi vọng được nhiều bạn đoán nhận, nếu có góp ý hay bình luận, hãy để lại lời nhắn cho mình nhé.