Hoàng xuất phát là dân kỹ thuật phần mềm, tham gia mảng phát triển phần mềm từ 2017 đến nay. Mình muốn mang những trải nghiệm cá nhân chia sẻ đến anh em, từ đó anh em thấy gì hay thì có thể tham khảo sử dụng, mà dỡ thì anh em góp ý giúp nhé.
View all posts by hoangphan
Hôm nay chúng ta sẽ tìm hiểu về các vị trí công việc của BA (Business Analyst) nhé.
Theo như cuốn BABOKv3 định nghĩa thì:
Vai trò BA
Vai trò của Business Analyst (BA) là căn chỉnh để các giải pháp được thiết kế và chuyên giao luôn phù hợp với nhu cầu của các bên liên quan. Và những công việc của BA bao gồm:
thấu hiểu các vấn đề và mục tiêu của doanh nghiệp,
phân tích các nhu cầu và giải pháp,
đề ra các chiến lược,
dẫn dắt sự thay đổi, và
tạo điều kiện thuận lợi cho sự hợp tác của các bên liên quan
Những Job Title trong sách nói
Và trong sách có ghi những common job titles như sau.
Công việc BA – BABOKV3
Thì ta có:
Kiến trúc sư nghiệp vụ (Business Architect)
Chuyên viên phân tích hệ thống nghiệp vụ (Business System Analyst)
Chuyên viên phân tích dữ liệu (Data Analyst)
Chuyên viên phân tích doanh nghiệp (Enterprise Analyst)
Chuyên viên tư vấn quản lý (Management Consultant)
Chuyên viên phân tích quy trình nghiệp vụ (Process Analyst)
Quản lý sản phẩm (Product Manager)
Người lĩnh xướng và phát triển sản phẩm (Product Owner)
Kỹ sư thiết kế và quản lý yêu cầu (Requirement Engineer)
Chuyên viên phân tích hệ thống (Systems Analyst)
Ụa Ụa khoan, sao không thấy ông IT Business Analyst trong danh sách trên nhỉ???? :v
Thì thật ra “IT Business Analyst” là một cái title hay được gọi ở Việt Nam, và tuỳ công ty sẽ những loại công việc khác nhau, nhưng nếu tính trên danh sách trên thì IT Business Analyst khá gần với tên Business System Analyst.
Nên khi tìm việc các bạn có thể nghiên cứu về Job Description của mỗi công ty tuyển dụng, họ sẽ yêu cầu công việc mà từ đó chuẩn bị cho phù hợp với yêu cầu tuyển dụng nhé.
Năm 2021 mình có làm cho công ty Blockchain, có CEO là người Mỹ, khi tuyển dụng có một bạn ở Shenzhen (Thâm Quyến, Trung Quốc), job title là Product Manager sinh năm 2K, nhưng task và công việc của bạn là một IT Business Analyst (junior), mà ông CEO ổng hỏi BA là gì, sao mày (ý nói là mình) không phải Title là PM mà là BA, Rồi nó kêu dựa theo kinh nghiệm của nó thì BA được xem như một Junior PM cũng được :v…
Hôm rồi mình có học 1 khoá trên Udemy thì trên đó họ cũng giải thích Business System Analyst
Business System Analyst Hoang Phan Blog
Những vị trí gần giống IT BA ở Việt Nam
Riêng với mình thì mình biết những title hay gặp ở Việt Nam mà hay có dính tới IT Business Analyst như sau:
BA Presale: Thường các bạn này hay kiểu đi cùng với Sale để pre-sale các sản phẩm của công ty (product)/hoặc sản phẩm build outsource, rồi tham gia vào trao đổi nghiệp vụ lúc deal, rồi sau đó viết docs các kiểu, trao đổi với Dev (và phần kỹ hơn thường giao cho IT BA để làm tiếp). Mình cũng từng làm qua vị trí này.
BA triển khai (ERP, …): Thường là cũng join vào Pre-sale, khai thác yêu cầu, tài liệu hoá các yêu cầu, xác nhận, và thường là dạng hiểu rõ về sản phẩm công ty => Sau đó tuỳ yêu cầu sẽ điều chỉnh, cài cắm cho phù hợp nhu cầu mỗi khách hàng.
IT BA: Đã chia sẻ ở bài trước
Consultant: … Mấy ông này là BA lâu năm, có kinh nghiệm và thường tư vấn, triển khai các phần mềm, process các kiểu cho các doanh nghiệp…. à ờ, này mình không chắc tại chỉ biết vậy thôi, k biết có level junior Consultant không nữa.
Product Owner: Ông này có vai trò vận hành, cải tiến sản phẩm và tối ưu hoá sản phẩm, tăng lợi nhuận hoặc 1 lợi ích gì cho sản phẩm/công ty, hay đi trong hệ Scrum/Agile. Nhưng cũng tuỳ công ty, đôi lúc không nhất thiết phải gắn vào Scrum/Agile… Thường product ông PO làm là những sản phẩm product của công ty, yêu cầu ông này phải tham các task vụ liên quan đến nghiên cứu thị trường, hiểu sản phẩm, và biết sắp xếp việc nào ưu tiên trước sau để đẩy ae đội ngũ team Dev chiến. (Mình cũng đang làm vị trí này) => Ở Việt Nam mấy product lớn hay có nhiều PO lắm, ví dụ Momo hay ZaloPay tuyển PO, mỗi PO nắm 1 nhóm sản phẩm/tính năng và tìm hiểu kỹ, tập trung phát triển về nhóm tính năng đó => mang lại hiệu quả cho sản phẩm/công ty.
Product Manager: Ông này thường làm ở mức high level hơn ông PO, về định hướng sản phẩm (thường là nguyên 1 sản phẩm, hoặc 1 nhóm nhánh tính năng trong sản phẩm), ưu tiên nhóm tasks lớn, quản lý về vòng đời, đôi lúc gồm các bước như phỏng vấn, làm việc với nhiều khách hàng khắp nơi. Mục tiêu của ông PM hay gắn với mục tiêu kinh doanh, còn so với ông PO thì mục tiêu thường là mục tiêu phát triển sản phẩm
Câu kết.
Thật ra thì những cái trên một phần cũng là title, và tuỳ mỗi công ty sẽ có những cái khác nhau, ví dụ PO ở công ty A, nhưng đôi lúc công việc lại như PM ở công ty B, hay làm IT BA công ty A thì lại giống ông BA triển khai của công ty B.
Nên khi tìm hiểu và tham gia tìm việc, làm việc, bạn nên đọc yêu cầu của mỗi công ty mà chiến nha.
Như mình làm chả biết title mình là gì luôn :)))) lúc thì BA, lúc thì PO, lúc thì Product Manager, lúc thì Project Manager, rồi tham gia mấy task vụ về UX research…
Nên cứ có kỹ năng nào phù hợp, bạn hỗ trợ dự án và giúp nó phát triển đi đúng định hướng là cứ quất nhé.
IT Business Analyst (ITBA) là một vị trí yêu cầu kết hợp của rất nhiều kỹ năng mềm và kỹ năng chuyên môn nghiệp vụ. Để làm tốt vị trí BA, thì cần khá nhiều thời gian để rèn luyện – nắm vững các kỹ năng và công cụ để phân tích, giao tiếp và làm việc hiệu quả với các bên liên quan.
Trong bài viết này mình sẽ chia sẻ những kỹ năng cần thiết và khá phổ biến khi làm IT Business Analyst nhé.
Bài viết cũ
Cách đây một thời gian mình cũng viết một bài liên quan đến các kỹ năng cần cho một internship khi làm BA theo cách nhìn và cách tuyển dụng của mình.
Tiếp theo đây mình vẫn chia sẻ những kỹ năng khác đầy đủ hơn.
IT Business Analyst cần những kỹ năng gì?
1. Kỹ năng về giao tiếp
Từ giao tiếp ở đây trong tiếng Anh mình đang muốn nói tới từ “Interpersonal skills“,
Nó bao gồm:
Kỹ năng làm việc với những người khác (dev team, stakeholders, c-level,…)
Kỹ năng giao tiếp (communicate): gồm biết cách
Truyền đạt thông tin hiệu quả, rõ ràng, chính xác => này cả việc viết tài liệu & thuyết trình.
Lắng nghe và hiểu nhu cầu từ các bên liên quan
Đàm phán, thương lượng, thường là giải thích solutions, thuyết phục stakeholders theo một hướng nào đó tốt cho dự án, đôi lúc có xung đột giữa các bên cũng biết cách xử lý.
Kỹ năng về ngoại ngữ: Giờ tiếng Anh là một cái buộc phải có của BA, dù bạn BA cho công ty Nhật thì cũng cần phải biết tiếng Anh, đa số các kiến thức về BA, nghiệp vụ, công nghệ được viết trong tiếng Anh => Có tiếng Anh hỗ trợ việc đó, Ngoài ra nếu là công ty sử dụng tiếng Anh trong giao tiếp thì càng tốt, có tiếng Anh => Tăng lương, tăng cơ hội việc làm,… Nếu không là công ty sử dụng tiếng Anh => Thì biết thêm tiếng Nhật, Hàn, Thái … tuỳ mỗi công ty 😀
2. Kỹ năng đặt câu hỏi
Hình như không mấy bài viết về kỹ năng này, nhưng mình nghĩ kỹ năng này rất rất quan trọng cho người làm Business Analyst luôn.
Luôn luôn hỏi “Tại sao?”, “Tại sao?”, và “Tại sao?”.
Câu hỏi này dành cho Stakeholders, các thành viên khác và hỏi cả chính mình, từ đó mà có thể tìm ra được vấn đề gốc rễ, những điều bạn chưa biết, chưa rõ để làm rõ nó, từ đó phân tích ra được giải pháp phù hợp.
Dĩ nhiên là khi hỏi “Tại sao” cũng cần có một sự tinh tế nhất định để phù hợp với từng bối cảnh cụ thể.
Và “tự thì thầm nói chuyện” với bản thân, tự đặt câu hỏi với chính bản thân bạn, đây là một trong những kỹ thuật mình sài để tự khơi gợi (elicitation) và tìm ra đáp án cho các câu hỏi khó.
Bạn hãy nghiên cứu những loại câu hỏi sau, mình nghĩ sẽ có lợi cho bạn đoá:
Câu hỏi làm rõ: Kiểu hỏi để làm rõ vấn đề, những thứ bạn chưa hiểu
Ví dụ 1: “Bạn có thể giải thích ý số 2 là như thế nào được không?”
Ví dụ 2: “Đăng nhập với email, ý bạn là cần mật khẩu hay với OTP?”
Câu hỏi đóng: thường là để xác thực thông tin
Ví dụ: “Vậy đăng nhập với email sẽ gửi một link vào email và người dùng nhấn vào để xác thực đúng không?”
Câu hỏi mở: khuyến khích người khác bày tỏ ý kiến
Ví dụ: “Bạn nghĩ gì về giải pháp này?”
Câu hỏi giả định: đưa vào một tính huống giả định và hỏi xem có những khả năng nào xảy ra hoặc kiểu xem thử người được hỏi phản ứng như thế nào
Ví dụ 1: “Giả sử user đăng ký, và luồng là tự động đăng nhập sau khi đăng ký, vậy email nằm trong blacklist có tự động đăng nhập được hay không?”
Ví dụ 2: “Giả sử như giải pháp không được lãnh đạo duyệt thì sẽ làm gì?”
Câu hỏi thăm dò: nhằm kháp phá sâu hơn về một vấn đề cụ thể, khuyến khích người được hỏi cung cấp thêm thông tin hoặc suy nghĩ kỹ hơn về câu trả lời của họ.
Ví dụ 1: “Bạn có thể cung cấp thêm chi tiết về những phần của hệ thống đang hoạt động chậm?”
Ví dụ 2: “Bạn có thể mô tả cụ thể hơn về ý nghĩa của ‘dễ sử dụng’ trong bối cảnh này không? Ví dụ, bạn đang nghĩ đến giao diện người dùng, tốc độ phản hồi của hệ thống, hay mức độ đào tạo cần thiết cho người dùng mới?”
Ví dụ 3: “Có ví dụ nào từ hệ thống hiện tại hoặc từ các ứng dụng khác mà bạn cho là dễ sử dụng không? Điều gì trong đó mà bạn nghĩ sẽ hữu ích cho hệ thống mới?”
Câu hỏi dẫn dắt: Dẫn mọi người đi theo 1 hướng cụ thể hoặc đồng ý với 1 quan điểm nhấn định => nhưng nên cẩn thận vì tránh ảnh hưởng đến tính khách quan.
Ví dụ 1: “User chắn chắn sẽ thích giao diện mới này hơn, vì nó trực quan hơn nhiều, các bạn thấy vậy đúng không?”
Ví dụ 2: “Bạn cũng đồng ý rằng việc thêm tính năng báo cáo tự động sẽ giúp tiết kiệm rất nhiều thời gian cho team, đúng không?”
Câu hỏi đối chiếu: Kiểu dẫn dắt việc trả lời so sánh 2 hoặc nhiều lựa chọn => giúp đánh giá ưu và nhược điểm của từng phương án
Ví dụ 1: “Giải pháp A và B, cái nào tốt hơn nhỉ?”
Ví dụ 2: “Dự án này nên theo WaterFall hay Agile sẽ phù hợp hơn?”
3. Khả năng “Take notes”
😀 BA thường tham gia nhiều cuộc họp thảo luận, rồi trao đổi với nhiều bên, gathering requirements, tránh bỏ sót những chi tiết quan trọng => Cần take notes lại để sau còn phân tích, đưa ra solutions, viết docs, cập nhật docs các kiểu. Do đó kỹ năng này rất quan trọng với người làm IT Business Analyst.
Nguyên tắc cơ bản
Để tốt khả năng take notes thì có 1 số nguyên tắc cơ bản mình gợi ý như sau, bạn có thể nghiên cứu và học thêm nhé.
Xác định mục tiêu ghi chép: Trả lời những câu hỏi “bạn cần ghi lại những thông tin gì?” “những điểm nào là quan trọng nhất?”
Sử dụng từ khoá/cụm ngắn gọn: Viết ngắn gọn, dùng từ khoá, hoặc dùng các ký hiệu để tiết kiệm thời gian, không gian, vì đâu ai đang nói cái đợi bạn ghi notes lại đâu phải không? =)) => Nhưng không có nghĩa bạn được hỏi lại nhé… do đó tận dụng việc hỏi lại để xác thực thông tin.
Sử dụng ứng dụng, hoặc giấy bút hợp lý, tuỳ thuộc vào cái nào tiện: tuỳ theo mỗi bạn, có thể viết note vào bút nếu bạn ghi chép nhanh và quản lý tốt, còn không thì có thể sài những phần mềm take notes như: Onenote, Evernote, Notion, Sticky Notes, Google Docs, Ms Word. => Như mình thì chỉ sài phần mềm thôi, gõ nhanh hơn nhiều :3
Tổ chức thông tin hợp lý: Nên học vài phương pháp ghi chép phổ biến => từ đó luyện và ghi thành cấu trúc hợp lý kiểu như có tiêu đề, đánh số, gạch đầu dòng,… Sau đọc lại còn biết ý nào ý chính, ý nào ý phụ, tìm kiếm thông tin cũng dễ dàng hơn.
Highlight những điểm quan trọng: Kiểu như sài dấu sao, tô đỏ, tô đậm, gạch chân, để sau này đọc lại còn chú ý những điểm đó
Được thì tổng hợp lại mấy cái bạn notes, xong gửi lại cho team/người tham gia cuộc họp để họ đọc & xác nhận lại. Hoặc đơn giản chỉ gửi thôi.
Bạn cần lắng nghe 1 cách chủ động, đừng ngại hỏi, khi viết xong thì dành thời gian đọc lại, đôi lúc cần điều chỉnh cho hợp lý, lưu trữ nơi dễ truy cập, ngăn nắp.
Phương pháp
Phương pháp outline, cách này mình hay sài: sắp xếp thông tin theo dạng thứ tự từ trên xuống, kiểu như viết sách ấy, đánh 1, 2, 3 hoặc I, II, III,.. cho tiêu đề, dưới thì a, b, c, … gạch đầu dòng (-)
Ví dụ:
1. Yêu cầu dự án
– Hệ thống cần hỗ trợ đa ngôn ngữ
– Phải tích hợp với hệ thống CRM hiện tại
2. Thời hạn và ngân sách
– Thời hạn hoàn thành: 3 tháng
– Ngân sách dự kiến: $50,000
Phương pháp Cornell: Chia làm 3 phần (dạng kẻ bảng),này mình cũng có sài, hay viết trên excel, nhưng cũng ít chứ không nhiều.
Phần 1: Bên trái: Kiểu như ghi từ khoá/ý chính
Phần 2: Bên phải: Ghi chi tiết nội dung (dạng tóm tắt)
Phần 3: Ghi tóm tắt toàn bộ nội dung (mình ít khi viết phần này lắm :v)
Từ khoá/Ý chính
Ghi chép chi tiết
Yêu cầu hệ thống
Hỗ trợ đa ngôn ngữ
Tích hợp với CRM hiện tại
Người dùng cần quyền truy cập hạn chế
Thời hạn & Ngân sách
Thời hạn 3 tháng
Ngân sách $50,000Ví dụ:
Tóm tắt: Dự án yêu cầu hệ thống đa ngôn ngữ, tích hợp với CRM, và phải hoàn thành trong 3 tháng với ngân sách $50,000.
Phương pháp sài mindmap: Mình cũng ít sài mấy này lắm 😀 Nhưng share cho bạn biết, có thể phù hợp với bạn.
4. Kỹ năng gathering requirements
Kiểu các kỹ năng, techniques, hiểu các bước cần thực hiện để làm sao đó Gathering requirements một cách hiệu quả.
Gathering ở đây không phải là “Lấy”, mình cũng không biết dịch sao cho hợp lý, kiểu như bạn phải đi thu thập nhưng không phải nó có sẵn mà bạn phải nỗ lực để khơi gợi, làm việc, trao đổi, phân tích thì mới có được.
Sẽ có 1 bài viết về phần này kỹ hơn ở sau, bạn tìm đọc trong chuỗi bài viết của mình nhé.
5. Kỹ năng Thinking & Visualize
Tư duy phân tích: Phân tích từ vấn đề phức tạp thành những vấn đề nhỏ hơn, để tìm ra được giải pháp.
Tư duy phản biện: Kiểu hỏi, tự phản biện, đánh giá và phân tích thông tin một cách khách quan để đưa ra quyết định sáng suốt.
Tư duy hệ thống: Khả năng hiểu và phân tích một ván đề một cách hệ thống, hơi thiên kiểu như A thì dẫn đến B, Rồi B lại ra 2-3 trường hợp C1, C2, C3, …
Creative thinking: Kiểu tư duy sáng tạo, bạn nghĩ ra cái mới, hoặc tìm ra cách tiếp cận mới mẻ (innovation) để giúp cho dự án đi tới được mục đích một cách hay hơn, không đi theo khuôn khổ.
Tư duy hình dung/mô hình hoá dữ liệu (Visualize): Kiểu như từ một bài toán, mọi người nói và chia sẻ, nhưng những thông tin đó khó hình dung => Ta đưa nó về 1 dạng visualize. Như mình thì mình hay vẽ wireframe, takenote trên đó, vẽ userflow, hoặc modal overview, hoặc là diagram để cấu trúc lại nội dung sau đó dùng nó để phân tích, điều chỉnh thêm.
Tư duy vẽ bức tranh toàn cảnh: Mình hay phân tích vẽ đi từ bức tranh toàn cảnh vào, lúc nào cũng vẽ các thành phần của hệ thống, cách chúng kết nối, sau đó mới đi vào chi tiết hơn.
6. Kỹ năng viết docs/tài liệu
Bao gồm việc vẽ sequence, activity diagram, Usecases, User story, UML, BRD, URD, SRS, …
Kể cả việc vẽ wireframe, mockup, đôi lúc là UI design
Như số 5, bạn đọc thêm trong bài viết mình đã viết trước đó nhé.
Không phải là kiểu bạn cái gì cũng biết, như code bạn không cần biết code giỏi, nhưng ít nhất biết cách hệ thống/code nó hoạt động, ví dụ đang phân tích tính năng “Calendar” cho chọn range ngày A=>B, mà nó yêu cầu animation các kiểu, thì bạn cũng cần biết ít nhiều để mà biết chắc là cái này Dev làm được chứ không đưa ra 1 tính năng mà Dev chả làm được, hoặc tốn rất rất nhiều thời gian, kinh phí.
Như mình thì từ dân Dev ra, trước cũng code được sơ sơ nên giờ phần đó khá lợi thế với mình, kiểu mình có thể ước chừng tính năng mất khoảng bao lâu thì xong nếu Dev đang ở level nào, làm được tính năng đó hay không? Hay thậm chí đi tìm code mẫu gửi cho dev luôn.
Hoặc kiểu như giờ các dự án dính tới vụ API khá nhiều => cần có kiến thức để mà đi đọc docs của đối tác, xem bên mình tích hợp được không? nếu tích hợp được thì luồng như thế nào.
8. Kỹ năng tư duy, chiến lược
Tư duy chiến lược: Khả năng nhìn nhận các vấn đề kinh doanh từ góc nhìn chiến lược, đảm bảo rằng các giải pháp được đề xuất không chỉ giải quyết các vấn đề trước mắt mà còn hỗ trợ mục tiêu dài hạn của doanh nghiệp.
Tư duy hệ thống: Hiểu biết về cách các yếu tố trong hệ thống công nghệ và kinh doanh tương tác với nhau, và cách các thay đổi trong một phần của hệ thống có thể ảnh hưởng đến toàn bộ hệ thống, hoặc ảnh hưởng 1 phần => từ đó nhắc Dev, QC chú ý tới để tránh xảy ra lỗi.
9. Hiểu biết chút về UI/UX
Biết cách vẽ wireframe, biết cách cấu trúc (layers), dùng các phần mềm vẽ như Figma, Axure, Balsamiq đồ.
Biết chút về WCAG để khi mà UI vẽ ra, mình test được, tránh phạm quá lỗi này.
Khi vẽ wireframe, thì không phải vẽ riêng biệt các screens, mà kiểu vẽ rồi link chúng nó lại với nhau, nhấn nút nào thì điều hướng tới đâu, đó là 1 phần của User Flow, UX, nên bạn có hiểu biết về UX để khi vẽ tối ưu được luồng, biết cách đặt button đâu cho hợp lý… Đôi lúc còn biết kiến thức mà cãi lại UI/UX team nữa :v mình hay vậy lắm, kkk. Đùa thôi!!! Tuỳ trường hợp.
10. Hiểu biết về Business/Domain
😀 Ví dụ làm BA Banking, thì bạn phải hiểu nghiệp vụ về Bank, làm bảo hiểm thì phải biết bảo hiểm là gì, nó thường có những tính năng gì, hoạt động ra sao,…
Này chắc không cần giải thích gì nhiều. … 😀
Ngoài ra bạn cũng hiểu thêm chút về tài chính, kiểu như khi build hệ thống nên biết về cách hệ thống làm ra tiền, hệ thống nào build chả support cho việc làm ra tiền đúng không? Hoặc kiểu giống như ảnh hưởng tới tài chính/business á => hiểu biết thì sẽ giúp bạn hiểu cái gốc rễ của việc làm ra hệ thống hơn => đưa những solutions hợp lý, chứ k thể nghe sao là làm vậy, BA phải tư duy lên.
11. Các kỹ năng khác
Mình nghĩ IT BA không chỉ dừng lại là cần những kỹ năng mình kể trên đâu, mà nó cần phối hợp nhiều kỹ năng khác nữa…
Mình chỉ kể 1 phần, trong quá trình làm việc các bạn có thể nhận ra thêm nha.
Bạn tìm và đọc tiếp những bài tiếp theo của mình nhé.
Cũng chính vì có rất nhiều bạn nhắn tin và hỏi mình dạy về IT BA, mình hỏi ngược lại “Tại sao muốn làm BA?” nhiều bạn trả lời rất ngập ngừng, mình cảm giác như các bạn biết tới vì nhiều bài trên mạng đăng giới thiệu về BA sơ qua, chưa hiểu rõ cốt lõi của công việc BA, hoặc nghe lương cao … nên chuyển qua làm.
Mình có search trên google về chủ đề này =)) mà thấy toàn quảng cáo cho IT BA, kiểu như “Tại sao bạn nên làm IT BA”, mình thì không thích làm vậy lắm, chủ yếu là muốn những bạn nghĩ tới việc làm IT BA thì nên tìm hiểu kỹ về nghề IT BA, tự thấu hiểu bản thân => Chọn hướng đi cho đúng.
Nên bài này chính là một bài mình viết ra những câu hỏi để các bạn tự hỏi lại bản thân xem thử là
Tại sao bạn muốn làm IT Business Analyst?
Các câu hỏi để bạn tự hỏi bản thân và từ đó tự trả lời cho câu hỏi “Tại sao bạn muốn làm IT Business Analyst?”
Bạn có thực sự hiểu về công việc của một IT BA hay chỉ bị thu hút bởi những lợi ích như lương cao hoặc cơ hội thăng tiến? => BA không phải dễ như bạn nghĩ
Bạn có nghĩ BA dễ làm hơn ngành khác không? Hoặc kiểu thấy nó dễ hơn vị trí khác trong ngành IT => muốn làm
Bạn có thấy làm IT BA ít áp lực và công việc nhẹ nhàng hơn so với các vị trí công việc khác đúng không? Như mình thì mình thấy đúng =)) Vì mình thích và cảm giác như mình đang đi đúng, nhưng mình nghĩ với những bạn khác thì không phải như vậy, mình từng đưa bài toán hơi khó 1 tíu thôi, thấy những bạn BA đó làm mà bảo muốn nản luôn…. Nên ở góc nhìn của bạn cũng chưa chắc là đúng => Tìm hiểu kỹ, nghe những người từng làm kể đã.
Bạn có thích làm về công nghệ không? => Làm IT BA buộc phải làm liên quan đến công nghệ.
Bạn thực sự đã hiểu về tất cả những công việc IT BA sẽ làm chưa? => Chưa hiểu thì phải tìm hiểu thật là kỹ để biết và làm
Bạn có thích giao tiếp và làm việc với nhiều người từ các bộ phận khác nhau không? => Phải thường xuyên trao đổi, họp hành, khi lên vị trí cao hơn, việc họp còn nhiều hơn thời gian ngồi phân tích và viết tài liệu nữa, chưa kể thường được/bị người này người kia hỏi nghiệp vụ
Bạn có khả năng tự tìm hiểu một thông tin mới không? => BA là người đi tìm hiểu, nghiên cứu, có kiến thức rộng để đưa ra những giải pháp phù hợp => Phải luôn trong tâm thế tìm hiểu và học hỏi, đặc biệt là tự tìm hiểu.
Bạn có khả năng tự học không? Tìm hiểu để học kỹ năng mới=> Có những dự án rất rất mới, không có ai chỉ cho bạn, mà bạn lại là người đi đầu trong dự án => bạn phải có khả năng tự học, tự tìm hiểu, tự suy luận để có những kiến thức mới phù hợp với dự án. Chưa kể công nghệ thay đổi liên tục, buộc người làm trong lĩnh vực IT phải luôn cập nhật cái mới để tìm ra cái phù hợp nhất trong từng giai đoạn.
Bạn có khả năng truyền đạt ý tưởng và thông tin phức tạp một cách rõ ràng, dễ hiểu không? => Thật ra câu hỏi này thì mang tính tương đôi, bạn có thể trao dồi thêm trong quá trình học và làm BA, nếu đã có rồi thì tốt, chưa có thì nên học, làm nghề, ngành nào cũng cần cái này.
Bạn đã có kiến thức nền tảng về IT chưa? => Nên trao dồi và nắm các kiến thức cơ bản trước khi vào làm, đừng mộng tưởng việc học xong 1 khoá học là có thể đi làm, cũng sẽ có công ty chấp nhận ấy, nhưng… làm việc thiếu kiến thức IT thì sờ chét lắm nhoa, và cũng khó lên ví trị cao được => Bạn đang làm/định hướng làm IT BA mà.
Bạn có sẵn sàng đối mặt với thách thức mới /dự án khó không? => Thường thì cũng có rất nhiều dự án dễ, nhưng cũng không thiếu những dự án trung bình và khó, như mình chỉ nghe 1 đề bài đơn giản là “Xây dựng hệ thống tối ưu lợi nhuận” và từ mỗi câu đó, và một số dự án tương tự => Mình phải tự xâu chuỗi, tự chiến, kiểu đôi lúc vô thế bí không biết làm gì tiếp, mà cũng không có ai để hỏi, sờ chét cực kì => Phải có những kỹ năng bóc tách, tìm ra vấn đề gốc rể và cách xử lý từng phần nhỏ, cũng như chịu được áp lực cao thì mới ra được một phân tích hệ thống đầy đủ và hợp lý với yêu cầu được.
Bạn kỳ vọng gì về sự nghiệp IT BA? (Thăng tiến, mức lương, sự ổn định, cơ hội học hỏi,…)
Bạn có sự kiên nhẫn không? => Đôi lúc đợi KH rep, hoặc kiểu yêu cầu 1 cái gì đó từ các bên mà không được hỗ trợ, hoặc bị gây khó dễ nữa => Bạn chịu được không?
Bạn có thích viết không? Thực tế thì việc viết docs cũng chiếm kha khá thời gian cho những bạn mới vào làm BA => nên cảm giác khúc đầu mới đi làm chả phân tích gì mấy, thời gian chính toàn viết docs
Bạn có linh hoạt, và chịu được sự môi trường thường xuyên thay đổi không? => Làm BA thì phải linh hoạt, đôi lúc đổi xoành xoạch ấy
Có vài câu chuyện liên quan đến BA bị Dev, QC, KH chèn ép, kiểu ở giữa bị mọi người gây sức ép ấy => Bạn chịu được không?
Bạn làm IT BA có phải là kế hoạch dài hạn không? Hay chỉ là 1 bước đệm để lên 1 vị trí khác?
Có kế hoạch phát triển sự nghiệp chưa?
Liệu do IT BA đang “hot” nên nhảy qua, hay thật sự thích làm IT BA?
Bạn chuyển việc => Vậy bạn có sẵn sàng bỏ kha khá kinh nghiệm cũ để qua làm IT BA để bắt đầu một sự nghiệp mới không?
Bạn có khả năng/thói quen tự hỏi bản thân không? => Kinh nghiệm của mình là thường khi phân tích, tự hỏi bản thân là 1 kỹ năng vô cùng quan trọng trong việc tìm ra được giải pháp đó….
Bạn có thích việc gì cũng tới tay mình không? => Tuỳ công ty, nhưng mình thấy kha khá bạn làm BA, trong đó có cả mình. Kiểu như việc gì cũng tới tay, bạn có khả năng chịu được áp lực, làm nhiều đầu việc cùng 1 lúc như vậy không? HOặc kiểu multitasking, bị nhiều người làm phiền ấy…. Như mình là vừa làm (công việc của) Project Manager, Product Manager, 50% việc của UI Design, UX design, BA, PO, QC Lead, hỗ trợ khách hàng (CS), thậm chí đôi lúc là Graphic design, … có khi sắp tới là code luôn =)).
Bạn có nói chuyện với mấy người làm IT BA chưa? Có hỏi họ về kinh nghiệm đi làm, nghe những câu chuyện trong ngành chưa? => Tham gia thử group trên tele của mình để đọc thử nhé: https://t.me/businessanalystvietnam
Xung đột giữa các bên (giữa các khách hàng, stakeholders với nhau, giữa dev, QC,…) liệu bạn có thích xen vào và xử lý không? => Thực tế không phải là thích hay không? Mà là tuỳ tình huống bạn nên tham gia vào để giải quyết, đôi lúc đó là 1 phần công việc của bạn
Bạn có nhút nhát khi đưa ra ý kiến cá nhân không? => Làm BA không phải là nghe răm rắp theo người khác, mà bạn phải tự nhận định đúng sai, đôi lúc bạn phải định hướng, bản thân đưa ra quyết định, solution và giải thích, thuyết phục người khác => Do đó nếu bạn thấy nhát khi phải đối chấp, thảo luận, tranh luận với người khác,… thì bạn nên học cách để có thể làm được nhé. Như hiện tại với mình, C-level của công ty mình hay của đối tác, việc mình thảo luận thẳng thắn, chỉ ra cái sai, đưa ra giải pháp là chuyện bình thường, mà mình cũng đã làm điều này từ những năm đầu tiên đi làm rồi, nhưng lúc đó chưa đủ trình để được nói chuyện trực tiếp với C-level thôi.
…
Cũng nhiều câu hỏi rồi đó, bạn hãy đọc và tự trả lời cho bản thân => từ đó rút ra được câu trả lời phù hợp, xem thử mình thực sự thích IT BA và muốn làm không nhé…
Như cách bạn đọc hiểu về khái niệm BA và IT BA ở bài trước, ta có thể thấy vị trí IT Business Analyst đóng một vai trò quan trọng trong các dự án phát triển phần mềm, và cải tiến quy trình. Là một trong những cầu nối cực kì quan trọng giữa bộ phận kỹ thuật và kinh doanh, đảm bảo rằng các giải pháp được phát triển phù hợp với nhu cầu doanh nghiệp và các bên liên quan.
Vai trò của IT Business Analyst Hoàng Phan Blog
1. Thu thập và quản lý yêu cầu:
Thu thập yêu cầu: Làm việc với các stakeholders (bên liên quan) từ đó xác định được mục tiêu, yêu cầu từ họ thông qua các việc thực hiện như: phỏng vấn, khảo sát, hội thảo, đọc tài liệu hiện có, ….
Xác định và làm rõ yêu cầu: Phân tích và làm rõ yêu cầu, làm sao mà ta hiểu đúng và đầy đủ những yêu cầu đó. Từ đó dự vào kinh nghiệm và kiến thức cá nhân để chuyển đổi thành các yêu cầu về kỹ thuật, đảm bảo rằng đội ngũ dự án có thể thực hiện chúng một cách hiện quả ở bước transition.
Quản lý các yêu cầu: Thường có nhiều sự thay đổi, do đó cũng cần viết lại để quản lý, cũng như đưa ra sự ưu tiên cho từng yêu cầu, đảm bảo sao đó đáp ứng được trong sản phẩm release ra cuối cùng.
2. Phân tích quy trình
Hiểu về quy trình hiện tại: BA cần hiểu về quy trình, nghiệp vụ hiện tại của vấn đề/doanh nghiệp
Xác định và tìm phương án cải tiến: Xác định vấn đề và các cơ hội để cái tiến trong quy trình. Làm sao đó có thể giảm chi phí, tăng hiệu quả, mang lại giá trị cho doanh nghiệp.
3. Đề xuất giải pháp
Đề xuất giải pháp: Dựa trên yêu cầu đã thu thập được, khơi gợi, phân tích để đề xuất nhưng giải pháp phù hợp. Giải pháp có thể là phần mềm mới, cải tiến quy trình, thay đổi chiến lược, làm thêm tính năng, điều chỉnh tính năng,…
Đánh giá giải pháp: BA đánh giá các giải pháp dựa trên nhiều tiêu chí như: chi phí, lợi ích, rủi ro, tính khả thi => đưa ra giải pháp tốt và phù hợp nhất.
4. Xây dựng và trình bày tài liệu
Tạo tài liệu yêu cầu: BA chịu trách nhiệm tạo ra các tài liệu chi tiết như: Business Requirement Document (BRD) – Tài liệu yêu cầu kinh doanh, nghiệp vụ, User Requirement Document (URD) – Tài liệu yêu cầu người dùng, Software Requirements Specification (SRS) – Tài liệu yêu cầu phần mềm, Functional Requirement Specification / Functional Specification Document (FRS/FRD) Tài liệu yêu cầu chức năng, Các loại như Use Case, User Stories, Product Vision,…
Tài liệu hỗ trợ việc test: Checklist, Testcases, Testplan.
Trình bày giải pháp: BA trình bày các giải pháp đề xuất và các tài liệu yêu cầu cho các bên liên quan để đảm bảo rằng mọi người đều hiểu rõ và đồng ý với những gì sẽ được thực hiện. Việc này kiểu đi xuyên suốt quá trình phát triển, Dev hỏi, QC hỏi, Sếp hỏi, Khách hàng hỏi,… BA trả lời thông tin nghiệp vụ.
5. Hỗ trợ kiểm thử
Việc này BA cũng có phần đó nha =)), thường thì việc test sẽ nằm trong tay QC, nhưng BA cũng là người tham gia vào, đôi lúc sẽ xem thử khi lên thực tế sản phẩm thì có cần điều chỉnh gì không => từ đó điều chỉnh yêu cầu cho hợp lý
Test để xem thử giải pháp được phát triển có đúng yêu cầu đã đề ra hay không.
Tham gia viết Checklist, testcases, kiểm thử chấp nhận người dùng (User Acceptance Testing – UAT) => đi kèm với việc report bugs
6. Hỗ trợ thiết kế
BA cũng tham gia vào giai đoạn thiết kế (tuỳ công ty), thường BA là người tìm hiểu khá kỹ về nghiệp vụ, và luồng hệ thống chạy => có thể đề xuất các liên kết giữa các màn hình (User Flow)
Tham gia review & đánh giá thiết kế cùng với đội ngũ UI để xem đã meet requirements hay chưa.
Đề xuất giải pháp phù hợp để phụ trợ thêm cho đội ngũ UI/UX trong việc thiết kế giao diện và luồng người dùng.
7. Quản lý thay đổi
Dĩ nhiên quá trình phát triển phần mềm luôn có sự thay đổi ít nhiều, có thể xuất phát từ các stakeholders, hoặc từ chính BA thấy chưa hợp lý và đề xuất thay đổi => Cần quản lý thay đổi một cách hệ thống và không ảnh hưởng tiêu cực đến tiến độ, cũng như chất lượng dự án.
Đảm bảo sự đồng thuận: Thay đổi => Thì phải đề xuất => Rồi có sự đồng thuận từ nhiều bên => Áp dụng việc thay đổi, đôi lúc có những thay đổi tác động tới các bên khác và các dự án khác => cũng cần làm việc để việc thay đổi không ảnh hưởng quá nhiều hoặc có nhiều thì các bên đều xử lý tốt để mang tới 1 kết quả chung tốt nhất có thể.
8. Tạo cầu nối giữa các bên.
Truyền đạt thông tin: BA đóng vai trò là cầu nối giữa các bộ phận kinh doanh, các bên liên quan và kỹ thuật, đảm bảo rằng các yêu cầu và mục tiêu của doanh nghiệp được truyền đạt rõ ràng và chính xác đến nhóm phát triển.
Giải quyết xung đột: BA giúp giải quyết các xung đột giữa nhu cầu kinh doanh và khả năng kỹ thuật, đảm bảo rằng giải pháp cuối cùng phù hợp với cả hai bên.
9. Hỗ trợ triển khai
Thường giai đoạn triển khai, BA sẽ hỗ trợ trong việc đào tạo người dùng, viết tài liệu hướng dẫn, đôi lúc còn phải đi cài cắm nữa cơ 😀
10. Đánh giá hiệu quả giải pháp
Đánh giá sau khi triển khai: Sau khi giải pháp được triển khai, BA đánh giá hiệu quả của nó so với các mục tiêu ban đầu. Họ thu thập phản hồi từ người dùng, phân tích dữ liệu hiệu suất, và xác định liệu giải pháp có đáp ứng được kỳ vọng hay không.
Đề xuất cải tiến: Nếu cần thiết, BA đề xuất các cải tiến hoặc điều chỉnh để tối ưu hóa giải pháp hoặc giải quyết các vấn đề phát sinh sau khi triển khai.
Kết luận
IT Business Analyst đóng một vai trò rất quan trọng trong quy trình phát triển phần mềm, giúp việc thực hiện phân tích, triển khai dự án trơn tru và đúng yêu cầu, nhưng có thể trong công ty bạn hoặc đội phát triển của bạn không có ai có title là “Business Analyst”, vậy thì hãy tìm hiểu thêm các bài phía sau để hiểu vì sao nhé.
Bài viết đầu tiên trong chuỗi tự học Business Analyst của Hoàng Phan. Blog.
Giới thiệu
Mấy năm gần đây ngành “IT Business Analyst” được tìm kiếm nhiều hơn, đi đâu cũng nghe bàn luận về việc tìm hiểu và làm BA. Bạn bè mình cũng hỏi thăm khi biết mình làm việc ở vị trí BA, cũng có bạn đã chuyển qua làm với mức lương khá ổn hơn nhiều so với công việc hiện tại của các bạn.
Nhớ năm 2017 mình mới đi làm và lúc đó ở công ty mình lúc đó vị trí BA chỉ dành cho mấy anh đã có rất rất nhiều năm kinh nghiệm, thế mà qua sau 1-2 năm sau, nhiều bạn dù chưa có kinh nghiệm vẫn làm được, và cũng như công việc BA được chia nhỏ tasks hơn, khó thì người có kinh nghiệm làm, các công việc còn đơn giản, dễ, thì giao cho các bạn mới tập tành vào nghề. Thế là nó trở nên phổ biến như bây giờ.
IT Business Analyst là gì? Hoàng Phan Blog
IT Business Analyst là gì?
IT Business Analyst (hay được gọi là Chuyên viên phân tích nghiệp vụ IT), là một trong những vai trò trong các dự án công nghệ thông tin và xây dựng phần mềm.
Nhiều bạn thì hay định nghĩa BA là:
Người phiên dịch
Là người làm Document cho dự án
Là cầu nối, giao tiếp giữa các bên (Dev team, Stakeholders, khách hàng,…)
Vậy giờ bóc tách từ cái tên IT Business Analyst ra để xem nhé.
IT: Information Technology (Công nghệ thông tin)
Business: thường được học là Kinh doanh, nhưng trong ngữ cảnh này còn có nghĩa là “Nghiệp vụ”
Analyst: là chỉ người làm những công việc liên quan đến nghiên cứu, tìm hiểu rõ hơn, đưa ra giải pháp, dự đoán,… Dịch tiếng Việt là “Người làm phân tích”
Do đó người làm IT Business Analyst là người làm công việc liên quan đến NGHIÊN CỨU, TÌM HIỂU, PHÂN TÍCH, LÀM RÕ, đưa ra GIẢI PHÁP, và những công việc đi theo như Họp hành, viết tài liệu (tài liệu hoá), truyền đạt thông tin, quản lý các yêu cầu, hỗ trợ triển khai, …
Những phần ở trên mình tập trung nói sâu về công việc IT BA, còn riêng Business Analyst (BA) thì nó hiện diện ở khắp mọi nơi.
Miễn sao người làm những công việc đó tìm ra được “Need” (nhu cầu, yêu cầu thực sự) để đưa ra được những Solution (giải pháp) và mang lại những giá trị cho doanh nghiệp, cá nhân, tổ chức, những bên liên quan (stakeholders). Bạn đọc khái niệm về Business Analysis (Việc/tasks mà Business Analyst sẽ làm) từ cuốn BABOK v3.
Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. (BABOK v3)
Thường thì cái “need” này cũng là một từ khoá, khi mà chính những người/doanh nghiệp đưa ra yêu cầu nhưng họ cũng không biết họ muốn thực sự là gì, thường yêu cầu khá chung chung => đó đó người làm việc này (BA) phải phân tích, sử dụng các kỹ thuật khác nhau để tìm ra Need và chỉ ra cho họ thấy.
Quy trình Business Analysis
Và thường thì BA sẽ làm theo quy trình sau, và IT BA cũng áp dụng quy trình này luôn
Quy trình Business Analyst => Tìm ra need
Thường thì bắt đầu từ Business Requirements (Yêu cầu về nghiệp vụ)
Cần trả lời được câu hỏi là “tại sao tôi muốn điều này?“
Điều này chính là các vấn đề mà doanh nghiệp đang gặp phải và có một mục tiêu cần giải quyết.
Cần xác định rõ là cần thay đổi hoặc thực hiện một giải pháp nào đó để mang lại giá trị cho doanh nghiệp ví dụ như tăng doanh thủ, giảm chi phí, cải thiện hiệu quả công việc,…
Stakeholder requirements
Cần trả lời câu hỏi là “Yêu cầu từ các bên liên quan là gì?“
Từ việc biết được mục tiêu cần giải quyết, BA sẽ làm việc với các bên liên quan để hiểu rõ nhu cầu và mong muốn của họ.
Stakeholder thì có thể là khách hàng, người dùng cuối (enduser), các nhà quản lý, các đội hỗ trợ, đội nghiệp vụ của công ty,…
Solution requirements
Cần trả lời câu hỏi “Tôi muốn gì?“
Từ yêu cầu và mong muốn của stakeholders, BA sẽ tìm ra các giải pháp cụ thể để đáp ứng những yêu cầu của họ, gồm những yêu cầu về chức năng, phi chắc năng.
Solutions có thể bao gồm: tính năng, hành vi/cách hoạt động/User flow của hệ thống, hiệu suất, tiêu chuẩn bảo mật, …
Transition requirements
Cần trả lời câu hỏi “Điều kiện là gì?“
Khi đã có giải pháp thì bắt đầu xây dựng và triển khai, cần xác định những điều kiện như đội ngũ phát triển, phát triển trong bao lâu, những ai tham gia vào, cần làm những gì?, kiểm thử, cơ sở hạ tầng,… để làm sao đó mà giải pháp được áp dụng tốt vào thực tiễn, giúp cho việc chuyển từ trạng thái hiện tại của doanh nghiệp sang trạng thái mới mong muốn trong tương lai (nhờ áp dụng giải pháp).
Và dĩ nhiên khi triển khai cũng cần phải đánh giá lại kết quả, chứ không phải làm 1 lần là xong, do đó mà có “Assess outcomes” ở trên mũi tên cuối.
Đánh giá để đảm bảo các yêu cầu ban đầu đã được đáp ứng Business Requirements chưa?
Và tiếp đó sẽ có những vấn đề, yêu cầu mới phát sinh ra => quay lại bước quy trình để điều chỉnh và cải thiện để đáp ứng tốt nhất yêu cầu từ doanh nghiệp.
Các dự án được làm ra luôn cần được điều chỉnh, thay đổi theo thời gian để phù hợp với những yêu cầu về nghiệp vụ/kinh doanh của doanh nghiệp theo từng giai đoạn.
Một ví dụ vui về giải pháp
Ví dụ vui về giải pháp Business Analyst
Một ví dụ về việc làm BA trong cuộc sống hằng ngày:
Ngày mai anh em phải làm việc tại nhà, nhưng ở khu vực nhà bạn lại có lịch cúp điện, mà công việc cần xử lý ngay, vậy nếu theo như Quy trình Business Analysis chúng ta sẽ làm như sau:
Xác định Business Requirements (mục tiêu): Hoàn thành công việc một cách hiệu quả kể cả khi cúp điện.
Một số giải pháp (solutions) mà có thể có:
Tranh thủ tối nay làm việc trước hoàn thành sớm và báo công ty mình làm việc trước như vậy
Di chuyển ra quán cà phê nơi có điện để làm việc
Sử dụng pin laptop + phát 4G từ điện thoại và tranh thủ hoàn thành việc thời thời gian sử dụng PIN.
Sử dụng pin dự phòng
…
Các bên liên quan:
Công ty và Khách hàng: Chờ nhận kết quả công việc từ bạn, bạn phải chịu trách nhiệm khi không hoàn thành công việc đúng hẹn
Các thành viên trong đội ngũ làm việc cùng bạn, cần bạn làm việc cùng khung giờ để hỗ trợ nhau, cập nhật thông tin hoặc công việc có liên quan.
Bản thân bạn: xong công việc còn đi cà phê với bạn đúng 8g tối,… hoặc tránh mất uy tín vì trễ hẹn công việc,…
Chọn giải pháp phù hợp với các stakeholders và tuỳ trường hợp:
Thời gian cúp điện ngắn => Có thể dùng pin laptop để hoàn thành công việc
Cúp điện dài => Đi ra quán cf cho chắc, hoặc qua nhà bạn, qua co-working, hoặc lên công ty :v
Nhà có sẵn máy phát điện, pin dự phòng => Sử dụng máy phát điện, pin dự phòng và làm tại nhà
Buộc phải ở nhà trông con => Thuê máy phát điện chẳng hạn để làm việc tại nhà và vừa có thể trông con, hoặc dẫn con tới co-working space/coffee để vừa trông con vừa làm.
Buộc phải làm cùng lúc với mọi người trong công ty để hỗ trợ qua lại => Không nên làm trước, hoặc làm trước 1 phần và cần đi ra nơi có điện để online và làm việc trong suốt thời gian mọi người khác trong công ty đang làm.
Transition:
Tuỳ theo giải pháp phù hợp nhất => Thực hiện cho phù hợp.
Ví dụ chọn làm việc trước: Chuẩn bị danh sách công việc, thời gian bao lâu để hoàn thành, sức khoẻ đảm bảo, báo trước cho công ty,…
Ví dụ chọn di chuyển đến nơi có điện: Thì cần chuẩn bị và mang theo thiết bị cần thiết, chuẩn bị hoặc tính phương án ăn uống cho phù hợp
Ví dụ chọn sử dụng pin điện thoại, laptop: Thì sạt đầy pin, tối ưu hoá việc sử dụng pin, giảm độ sáng màn hình
Ví dụ chọn sử dụng máy phát điện: Cho chạy máy trước và kiểm tra kết nối điện, mua xăng hay nhiên liệu để chạy được trong khung thời gian cần có điện,…
Một ví dụ về công việc IT BA trong làm phần mềm.
Mình đang có trung tâm tiếng Anh, hiện tại hệ thống quản lý khoá học, lớp học đã có học viên, giáo viên, khoá học nào, học bao nhiêu buổi.
Hiện tại khi mà có học viên đăng ký học, ví dụ 32 buổi học, thì người quản lý lớp học sẽ thêm vào trong hệ thống từng buổi học một, rất tốn thời gian dù đã biết trước lịch học vào những thứ mấy, khung giờ nào trong 1 tuần, có được lịch của giáo viên với học viên này rồi.
Do đó ta có thể phân tích và tìm ra giải pháp như sau:
Xác định Business Requirements (mục tiêu): Có thông tin về khoá học, người quản lý giảm thiểu thời gian thêm các buổi học vào hệ thống.
Các bên liên quan:
Người quản lý lớp học, có thông tin cơ bản về khoá học và muốn giảm thời gian thêm dữ liệu vào hệ thống
Giáo viên: Cung cấp danh sách các buổi trống có thể dạy học viên, xem được danh sách các buổi học có trước.
Học viên: Cung cấp lịch học, xem được buổi học tiếp theo.
Một số giải pháp (solutions) mà có thể có:
Viết công thức trên file excel, và tạo ra danh sách các buổi học, copy và bỏ vào trường nhập dữ liệu, hệ thống thêm các buổi đó vào db và hiển thị lên cho từng role sử dụng hệ thống
Có 3 trường dữ liệu gồm nhập giáo viên, nhập học viên, nhập lịch học theo tuần, số buổi học => nhấn nút và hệ thống tự chạy.
Thuê thêm người vào phụ.
Chọn giải pháp phù hợp với các stakeholders:
Thêm dữ liệu trên excel, thì việc cập nhật lịch của giáo viên phải bị x2 lần khi nhập cả ở excel và hệ thống, người quản lý cũng phải nhập thông tin và quản lý file excel, cũng như hệ thống bị tách rời, và cũng cần build logic cho việc thêm lớp
Thêm dữ liệu trên hệ thống thì giáo viên cập nhật dữ liệu 1 lần, người quản lý có thông tin toàn bộ trên hệ thống, điền vào và chạy, nhưng việc develop tính năng sẽ có chút phức tạp và tốn chi phí hơn, và chi phí này cần xem xét có phù hợp với chi phí trung tâm có thể cho phép làm không? => Có
Thuê thêm người phụ thì chi phí sẽ không chi nhiều ngay lúc đầu, nhưng về lâu về dài chi phí khá cao so với việc xây dựng hệ thống, cũng như phức tạp hơn trong việc quản lý nhân sự
=> Chọn phương án số 2, dữ liệu trên 1 hệ thống quản lý duy nhất, tốn chi phí xây dựng ban đầu hơi cao tíu nhưng nằm trong phần chi phí chấp nhận.
Transition:
Dự trù kinh phí
Phân tích các tính năng, cách hoạt động, logic, làm file hướng dẫn cho giáo viên nhập thông tin lịch rãnh, cấu trúc lại hệ thống DB cho phù hợp
Hi mọi người, team mình vừa go live tính năng Seitrace Insights và với việc phân tích tính năng này, mình sử dụng AI rất nhiều để phục vụ việc phân tích, thiết kế và vẽ luồng nghiệp vụ.
Nhờ đó mà mình có kinh nghiệm để viết lại bài blog này để chia sẻ
cách mình đã dùng AI cho việc phân tích và vẽ sequence diagram một cách nhanh chóng
tiết kiệm khá nhiều thời gian, rút ngắn thời gian phân tích, và Dev cũng có thêm thời gian để develop tính năng khi mà yêu cầu về timeline khá gấp rút.
2. Công cụ AI sử dụng
Mình chỉ sử dụng 2 công cụ AI trong đợt này đó là ChatGPT4.0 và Mermaid
ChatGPT thì mình không biết phiên bản miễn phí 3.5 có hỗ trợ tốt được như bản mình đang sài không, mình sài Poe trả phí nên sài ChatGPT4 và các AI khác khá sướng 😀 Mà thiết nghĩ GPT3.5 cũng có support sẵn rồi.
Mermaid bạn có thể lựa chọn dùng phiên bản live tại: https://mermaid.live/ hoặc dùng Visual Studio Code và cài plugin Markdown Preview Mermaid Support
plugin mermaid hoangphan.blog
3. Bước phân tích cơ bản
Thật ra mỗi bạn BA, và tuỳ theo công ty sẽ có những cách phân tích khác nhau để đạt được mong muốn, mình với vai trò là một Product Manager, góc nhìn và cách phân tích của mình sẽ đi từ overview => đến chi tiết.
Mình chia làm các giai đoạn phân tích tính năng
Bước 1: Sử dụng thử các sản phẩm có sẵn trên thị trường mà có tính năng tương tự
Bước 2: Tập trung suy nghĩ và định hình những thành phần, Actors, tasks cần làm để xây dựng tính năng.
Bước 3: Dùng AI để research dựa theo keyword để tìm các kiến thức xung quanh tính năng/partner
Bước 4: Dùng AI để bắt đầu vẽ luồng…
Bạn có thể đọc bài “Phân tích tính năng subscription” của mình để biết được cách mình đã phân tích, ở bài này mình sẽ tập trung vào phần vẽ luồng
4. Sử dụng ChatGPT để vẽ ra luồng
Ở bước này mình cơ bản chỉ chat với ChatGPT và đưa ra yêu cầu cụ thể nhất có thể.
Thường thì các bạn có thể sử dụng để vẽ sequence diagram, flow chart hoặc activity diagram sẽ khá là ok nha.
Ví dụ:
Hi, Mình muốn xây dựng tính năng bán API của một Explorer blockchain SEI.
Hiện tôi đã có nguồn dữ liệu có sẵn.
Hãy giúp tôi vẽ luồng Sequence diagram, thanh toán sử dụng Coinbase, phần subscription (Subscription Management sẽ được đội ngũ tự phát triển)
Luồng người dùng sẽ chọn gói Advanced hoặc Professional, sau đó yêu cầu Sub Mgmt Server tính toán để cho User xác nhận, Khi xác nhận => xử lý để qua bên Coinbase tạo hoá đơn, Và khi có hoá đơn cần gửi cho user thông tin qua kênh Front end và Email.
User sẽ thanh toán
Sử dụng Mermaid
Thì mình sẽ nhận được một luồng bằng chữ như dưới => Copy bỏ vào trong công cụ Mermaid online, hoặc trên Visual Studio Code
mermaid-sequence text Hoang Phan blog
Và sẽ nhận được luồng như sau.
mermaid-sequence-diagram Hoang Phan.blog
Nhưng dĩ nhiên luồng sẽ chưa thể đúng 100%, do đó bạn cần chat và trao đổi, yêu cầu chỉnh sửa thêm với ChatGPT để cho luồng chính xác nhất.
Bạn có thể đọc đoạn demo của mình bên dưới để biết cách mình đã trao đổi với ChatGPT như thế nào để có luồng nhé.
… Thế là có luồng rồi :v. Khá tiết kiệm thời gian, thậm chí đôi lúc AI hỗ trợ mình vẽ ra các luồng mà mình cũng không nghĩ tới luôn. Nhưng cần có những lưu ý sau khi sử dụng AI vẽ diagram.
5. Lưu ý khi sử dụng AI vẽ diagram
Cần phải phân tích cơ bản, high level trước, khi gặp vấn đề thì sẽ nhờ AI để ra thêm ý tưởng, cũng như luồng còn thiếu, hoặc hỏi để tham khảo.
AI không thể thay thế được mình, bạn không thể đưa một bài toán chung chung mà nó giải và đưa ra luồng cho bạn
Phải chat và hỏi nhiều lần để AI làm gần sát với ý đồ của bạn nhất.
AI là trợ lý của bạn, giúp bạn có thêm ý tưởng, luồng chưa hiểu, nhưng việc rà soát lại luồng, đọc docs chính thống là rất quan trọng. Ví dụ như trong bài toán mình vừa giải, mình phải cần kiến thức về API để đọc rất nhiều docs API chính thống của 3rd để xác định xem luồng của AI vẽ đúng, và có thể sử dụng với bên thứ 3 không.
Bạn cũng cần có kinh nghiệm, quan điểm, ý kiến, tư duy riêng để check lại xem luồng, ý kiến của AI đưa ra đúng không.
6. Kết luận.
Mình gần đây nghiên cứu về các công cụ về AI, và sài khá nhiều loại khác nhau, thật sự thấy nó rất tiện ấy… Bạn thử sài đi nha 😀 Giờ mình xem AI như là 1 trợ lý, vừa rồi có ngồi cf với vài người bạn bàn luận về chủ đề, rất rất nhiều bạn đã áp dụng trong công việc và hiệu quả nhiều rồi. Bạn hãy thử sài đi nhé 😀
Và việc vẽ diagram này là một trong những ứng dụng mình thấy rất tiện, tiết kiệm thời gian, hi vọng sẽ giúp bạn làm việc nhanh và hiệu quả hơn với cách mình đã dùng.
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
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 blockshash 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
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
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:
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.
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:
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).
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 historyAPI 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
Hello, I am Hoàng Phan, you can call me “King” in English. This is my very first blog post written in English. I hope you find it clear and enjoyable to read! 😀
Today I want to share what I did research about pump.fun
Overview
Pump.fun is a project on the Solana blockchain designed to facilitate fair fundraising for MEME coin through the use of a linear bonding curve mechanism.
I researched & asked pump.fun about the bonding curve, they told me that their bonding curve is similar to Uniswap V2 where x*y = k represents a linear bonding curve. This coin allows for dynamic pricing influenced by market demand and supply.
Target to raise to 85 SOL with 796M Meme tokens and add LP pair to DEX, and burn the LP token and the MEME coin has no owner.
While user joining the launchpad, user can change their mind to sell their tokens/shared back to Bonding Curve.
Create MEME COIN
Before creating any Meme coin, the creator must first establish a Solana wallet, deposit some SOL (at least 0.021 SOL for creating fee) into it, and then register an account on pump.fun.
Creator fills out Ticker, meme name & description ⇒ Then choose the number of token to buy right after token created (First buy in SOL ⇒ Tokens [optional])
The system will create/mint 1B Tokens
Add 794M Tokens to Bonding Curve
206M Token is used to create Pair on TOKEN/SOL on Raydium and Add LP there if the bond can fill.
If creator set first buy (in SOL) ⇒ Bonding Curve will execute the swap for that first buy
The price will increase when more SOL & less Tokens in Bonding curve (more buy ⇒ gain price, and more sell ⇒ dump price, it follows the rule of Uniswap V2 Bonding Curve x*y = k )
1% fee for buy/sell actions, it will come to pump.fun team’s wallet
example buy 1 SOL, you will pay 1 SOL + 0.01 SOL (1% fee)
sell and receive 1 SOL ⇒ user can only receive 99% of 1 SOL = 0.99, then 0.01 SOL (1% fee) will be sent to pump.fun team’s wallet
List on Raydium
Once the bond reaches 100% (0 TOKEN & 85 SOL in bonding curve) ⇒ (maybe) a cronjob will run & execute to create pair on Raydium & add LP
6 Sol will be taken for fees (2 to pump, 4 to Raydium), then 79 SOL + 20% of tokens (206m) will seed the LP.
Bonding Curve ⇒ Transfer 85 SOL to wallet 39azUYFWPz3VHgKCf3VChUwbpURdCHRxjWVowf5jUJjg then this wallet will transfer to the team’s wallet 2 SOL (deduct fee ⇒ 1.85 SOL) & create PAIR + Add LP (79 SOL + 206M Tokens)
Add LP on pump.fun
Right after add LP ⇒ they are will be burned ⇒ No one owner
Pump LP on pump.fun project
Update the UI on pump.fun after Raydium listing, so now user can trade on Raydium via pump.fun & see the new chart of pair TOKEN/SOL on Raydium. => can check the UI here: https://pump.fun/GzqmrcsvGkAiTpJrYTYav2j5F3NquE3x1gcDR71Jpump
Some other features
King of the hills: To achieve “King of the Hill” status, about 45 SOL is required, marking the halfway point in token sales.
King of the hill on pump.fun
When a token’s market cap hits around $30K, it overtakes the current “King of the Hill” and is featured prominently. This visibility often attracts new buyers but can also be exploited by scammers.
Thread: This is using for discussing about the project, user can comment/replies free even you did not buy/invest to that tokens.
Bubble Map: just use the framework to show the address & token’s holding.
Marketcap
I just copy message from pump.fun team wrote to me for question asking about how to calculate MC on pump.fun.
We have virtual (non real) reserves for both Sol and tokens. This sets the parameters and initial price in the bonding curve. The market cap is the initial ratio (price) of the virtual Sol and tokens multiplied by the total supply of tokens.
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
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
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
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
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
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é.
Ây yahhh, lâu quá rồi bận xây dựng dự án Trung tâm Tiếng Anh mới, nên mình cũng ít có thời gian viết blog lại.
Nay một ngày dậy sớm hơn mọi ngày, mình dành ít thời gian chia sẻ về việc một ông Anh chuyển việc từ mechanical (cơ khí) hơi thiên về làm khuôn nhựa và thiết kế in ấn trên ly, vật phẩm physical trở thành một UI Designer (ảnh nói ảnh chỉ biết ít về UX à, nên mình gọi là UI Designer nha) với mức lương tăng từ 12 triệu/tháng lên 2000$ sau 2 năm.
Câu chuyện này nhằm mục đích truyền cảm hứng cho nhiều bạn với mong muốn cố gắng để đạt được những thành tựu tốt hơn về lương bổng, chứ không có ý khoe gì nha (à có 1 tíu khoe 😀 =)) )
Và qua câu chuyện mình cũng chia sẻ tips và các khoá học mà anh đó đã dùng.
Kể về ông Anh và cơ duyên gặp
Ông Anh mình kể tên là “T” sinh năm 1991 hiện đang ở Đà Nẵng.
Khoảng hơn 2 năm trước, ảnh làm mechanical (cơ khí) thiên về làm khuôn nhựa và thiết kế kiểu bao bì, rồi mấy cái in lên ly, đồ vật phẩm.
Sau đó ảnh nghiên cứu và quyết định chuyển hướng sang làm liên quan đến IT => Chọn ngành UI Design
Riêng vợ ảnh làm giáo viên dạy tiếng Anh được 10 năm và cũng chuyển hướng làm BA => Và giờ đang thấy phù hợp với hướng QC hơn nên chuyển qua làm QC (mình mới advise hôm rồi))
Thời điểm 2023, ảnh quen mình vì vợ ảnh có đọc blog + kết bạn fb, mình đăng tin tuyển dụng tuyển UI Design cho team, thì ảnh liên hệ để apply làm việc với bên mình => Từ đó dẫn tới việc anh em làm việc chung.
Chuyển việc sang UI Designer, lương từ 12 triệu lên 2000$Chuyển việc sang UI Designer, lương từ 12 triệu lên 2000$Chuyển việc sang UI Designer, lương từ 12 triệu lên 2000$
Hiện tại thời điểm mình viết bài này, ảnh đã nhận công việc 2000$ và đang làm việc remotely tại nhà.
Tips và các khoá học
Từng bước anh đó chỉ mình (để mình share lại cho cháu mình đang làm BA và học thêm về UI Designer, định hướng chuyển làm Product Designer)
Đa số mình copy từ trong tin nhắn của ảnh qua.
Bước 1:
Học figma hì, khoá học bất kỳ, utube free cho tiện, chú ý mấy cái sau nè:
autolayout
responsive
color & typo: style, variable
Bước 2: là đăng ký patreon anh Trí Tâm xem hết các video ảnh làm project – siêu hữu ích lun mà k hiểu sao view hiện tại cực kỳ thấp
Hiện giờ a Tâm k có bài mới, nhưng mình vẫn đăng ký vào xem đc
Ảnh quay video lúc làm việc á, xưa anh coi 1 video 3-4 lần, ngáp cũng coi, ớn cũng coi, coi để để ý detail nhỏ nhất của ảnh lun
Học đc siêu nhiều thứ hay ho, từ process làm việc, tạo component, naming, layout bố cục tất tần tật
Bước ni nếu cần thì bợ 1 bộ UI kit của ảnh về phân tích và chép theo lại UI để hiểu là ok
Hoặc khoá bên Telos, học cỡ 1,5 tháng (học giỏi nhất đc free học phí) => Ảnh được free.
Bước 3: học 1 khoá ux foundation – anh Nguyễn Vương Chung
Bước 4: mua mobbin, vẽ theo cỡ 10 flows, làm chỉnh chu để bỏ zô porfolio
Sau đó chiến project thực tế để nạp thêm kinh nghiệm thui
Nhận xét của mình
Câu chuyện thật nên chia sẻ để mọi người học hỏi
Thật ra anh này lúc mới gặp mình, thì chưa có kn làm product nhiều nha, vẫn chú tâm làm UI.
Anh e chia sẻ kinh nghiệm với nhau, thật lòng mà nói anh này trong 2 năm cố gắng liên tục, nên thấy skills ảnh grow nhanh, mình từng tuyển nhiều Designer tầm cỡ 5 năm kn hoặc hơn, mà về cách build UI chưa bằng ảnh về tốc độ & độ chính xác.
Mình chưa nói đến vấn đề về branding/visuallize nha.
Mình nghĩ mới 2 năm kn, lên đc lead UI Design là khá là nhanh, trong khi trước đó chưa có kn làm UI & product.
Và mình cũng nhận thấy luôn là giờ ảnh đang làm Design cho bên mình, về việc tối ưu chi phí thì ảnh là lựa chọn hàng đầu luôn. 😄 (Tại team mình có 1 người làm visual, bổ sung qua lại thì sẽ tạo nên 1 bộ hoàn hảo mà tối ưu chi phí)
Mình được ảnh chỉ làm UI tầm cỡ 16 tiếng, mình đã vẽ và dùng được khá nhiều công cụ/tip hay luôn. (Ảnh chỉ mình về UI Design, mình chỉ ảnh về tư duy product, cách overview hệ thống & research tính năng)
Còn lý do vì sao ảnh grow nhanh thì đọc đoạn chat nha 😀
Chuyển việc sang UI Designer, lương từ 12 triệu lên 2000$
Mình thấy, việc chuyển hướng và thay đổi công việc hiện tại quan trọng nhất và là định hướng, và sự quyết tâm. Mình đã được chia sẻ, tâm sự cũng như tư vấn cho những bạn có xu hướng chuyển việc và làm nghề IT, những người chuyển việc thành công, đạt được mức lương HƠN mong đợi đa số là họ cố gắng từng ngày, rèn luyện và học tập thường xuyên để nâng cao trình độ.
Hiện tại mức lương của bạn có thể thấp, nhưng nếu cố gắng và có định hướng tốt, có thể sau 1 năm, 2 năm bạn sẽ có sự thay đổi nhanh chóng và đạt được mục tiêu của mình.
Bản thân mình cũng từ làm việc kiếm lương đủ sống, mơ việc có thể mua chung cư trả góp thôi đã khó, nhưng sau sự cố gắng đã đạt được một mức lương tốt hơn rất nhiều, vừa có thể lo cho gia đình, vừa có thể có khoảng dư để đạt được mục đích khác nhau, nhất là việc chuyển về Nha Trang sống, làm việc remotely.
Bạn nào cần thông tin của anh “T” và cần ảnh hỗ trợ hay chỉ đơn giản là nói chuyện và chia sẻ, liên hệ mình => Mình sẽ hỏi ý ảnh và chia sẻ thông tin để anh em nói chuyện nha.
