Loading...
Tìm kiếm

Tag Archives: IT BA

Categories Chia sẻ

Workshop – Lộ trình phát triển nghề BA, kinh nghiệm thi chứng chỉ quốc tế CCBA/CBAP

by hoangphan Posted on

Nhân dịp đầu năm 2024, BA Zone (Hoàng làm Admin tại cộng đồng này) ra mắt trang tin BA School. Với mục tiêu kết nối và mang lại giá trị cho cộng đồng. Đội ngũ BA Zone tổ chức một sự kiện miễn phí dành cho cộng đồng Business Analyst Việt Nam.

Sau một thời gian dài lắng nghe tâm sự về những khó khăn khi làm Business Analyst nhưng chưa biết bắt đầu từ đâu. Nhất là trong bối cảnh thị trường tuyển dụng BA ngày càng khó hơn như hiện tại. Ngoài kiến thức nền tảng, các doanh nghiệp lớn giờ đây đã đưa những yêu cầu về ứng viên cần có chứng chỉ BA quốc tế như CCBA, CBAP như một điều kiện bắt buộc cần có.

IIBA cũng đưa ra thống kê những ứng viên có chứng chỉ quốc tế có nhiều cơ hội việc làm tốt hơn và có mức lương cao hơn 12%.

Vậy nên đội ngũ Admin BA Zone đã quyết định tổ chức một buổi Workshop online để giúp các bạn tìm hiểu về nghề BA dễ dàng hơn. Đặc biệt là giúp các bạn đang làm Business Analyst có kế hoạch thi chứng chỉ quốc tế như CCBA, CBAP được thuận lợi hơn.

Trong buổi workshop này, chúng ta sẽ cùng nhau chia sẻ những nội dung:

Phần 1: Giới thiệu cộng đồng BA Zone

Phần 2: Lộ trình phát triển nghề Business Analyst

Phần 3: Giới thiệu tổ chức IIBA và các chứng chỉ BA Quốc Tế

Phần 4: Kinh nghiệm thi chứng chỉ CCBA và CBAP 

  • Cách ôn thi chứng chỉ BA hiệu quả, tiết kiệm chi phí
  • Cách đọc sách Babok v3 hiệu quả
  • Hướng dẫn làm đề thi thử
  • Những kinh nghiệm khi làm bài thi
  • Những vùng kiến thức trọng tâm cần biết khi thi CCBA/CBAP
  • Những mẹo làm bài giúp bạn tăng tỷ lệ đỗ chứng chỉ

Phần 5: Giao lưu, trao đổi cùng khán giả.

Buổi Workshop có sự góp mặt của các khách mời là đội ngũ Admin BA Zone:

Host chương trình:

  • Phúc Nguyễn – Founder BA Zone | Business Analyst Lead VNPAY
  • Hoàng Phan – Admin BA Zone | Co-Founder Cavies Labs

Chia sẻ nội dung chính về CCBA/CBAP:

Mai Thị Ánh Hồng | BA Lead Viettel AI

Certification of Capability in Business Analysis™ (CCBA®)

Certified Business Analysis Professional (CBAP®)

Project Management Professional (PMP)

ISTQB

Ms.Hồng có hơn 5 năm là Kỹ sư Giải pháp nghiệp vụ tại Viettel AI.

Tham gia phát triển nhiều sản phẩm lớn trong lĩnh vực Phân tích dữ liệu và Trí tuệ nhân tạo…Đặc biệt với vai trò Admin, Mentor BA Zone Ms. Hồng sẽ chia sẻ những kinh nghiệm rất hữu ích về kì thi CCBA và CBAP.

Hà Mạnh Trí Toàn | Senior Business Analyst

Bachelor of Business in Information Systems, Minor in Logistics and Supply Chain -RMIT

Master of IT – Major in Information Systems and Business Analysis – Griffith University – tại Úc
Certification of Capability in Business Analysis™ (CCBA®) – IIBA – 2020

Certified Business Analysis Professional (CBAP®) – IIBA – 2023

Trong quá trình làm Business Analyst, Mr.Toàn cũng đã thi 2 chứng chỉ BA chuyên nghiệp dành cho BA đó là chứng chỉ CCBA năm 2020 và chứng chỉ CBAP năm 2023. Đây là chứng chỉ cao nhất do IIBA quốc tế cấp. Đặc biệt Mr. Toàn còn chia sẻ kinh nghiệm thực tế khi du học Master BA dành cho các bạn quan tâm.

Với Workshop lần này, đội ngũ Admin mang đến những kiến thức, kinh nghiệm, trải nghiệm về nghề BA. Những kỹ năng nền tảng cần có để giúp BA phát triển hơn trong sự nghiệp.

Đặc biệt sự kiện online miễn phí vì cộng đồng – Bên cạnh đó các bạn sinh viên năm 4 tham gia sự kiện còn có cơ hội được tham gia chương trình “BA Zone Mentorship Program” miễn phí dành cho các bạn sinh viên muốn làm BA.

Với phương châm “Learning and Sharing Knowledge for BA”, mục tiêu của BA Zone là nơi học hỏi, chia sẻ và giúp cộng đồng BA phát triển.

Thời gian diễn ra sự kiện:

Đặc biệt sự kiện giới hạn chỉ có 100 vé tham gia, các bạn nhanh tay đăng ký. Chúng tôi sẽ gửi thông tin chi tiết đến email của bạn

Categories Chia sẻ

Hướng dẫn tạo landing page trong vòng 1 tiếng với domain riêng bằng Unicorn Platform và Github Page

by hoangphan Posted on
Xây dựng landing page trong vòng 1 tiếng với Unicorn Platform và Github Page

Vừa rồi mình có tính xây dựng vài trang landing page cho các dự án cá nhân của mình, do đó được @khoanguyen là CEO Nocode VietNam giới thiệu cho công cụ Unicorn Platform để tạo ra các trang static pages.

Kết hợp với thêm kiến thức trước đó về việc tự host 1 static page lên Github Page và gắn domain vào thì mình có thể xây dựng được 1 trang okela.

Vậy từng bước như thế nào?

 

Từng bước xây dựng Landing Page với Unicorn Platform

Bước 1: Truy cập https://unicornplatform.com/ và đăng ký một tài khoản

Bước 2: Tạo page => Chọn template và kéo thả (thêm, xoá, sửa) các sections + cập nhật nội dung

Bước 3: Kết nối các form (nếu có) với database/nơi dữ liệu xuất ra (Như google sheet, mailchimp,…)

Bước 4: Cập nhật thông tin SEO, Feature image, Title, Description cho trang web

Bạn xem tất cả các bước từ đăng ký đến khi tạo ra website và tự host lên github page qua video sau nhé:

Tải source về và xoá branding

Bước 1: Nhấn setting -> Export HTML => Và download file Assets và name.html về

Để tải về được thì bạn phải đăng ký tài khoản https://unicornplatform.com/pricing/ với giá 9$/tháng

Bước 2: Giải nén file assets và copy file name.html vào trong thư mục vừa giải nén

Bước 3: Đổi tên file name.html thành index.html

Bước 4: mở file index.html trên trình duyệt và xem thử nó đã hiển thị như mình đã thiết kế trên UnicornPlatform hay chưa?

Bước 5: Mở file index.html với trình chỉnh sửa code như Visual Studio Code, Notepad, Hoặc Sublime Text để xoá đi branding UnicornPlatform

Host lên trên Github Page

Bước 1: Bạn tạo tài khoản Github nếu chưa có và tạo 1 repository để làm nơi lưu trữ code của static page

Bước 2: Sử dụng phần mềm Github Desktop clone code từ repository bạn mới tạo về local (máy tính của bạn)

Bước 3: Copy code từ thư mục lúc nãy bạn download vào trong thư mục bạn vừa clone từ Github về.

Bước 4: Bạn commit và push dữ liệu lên ngược lại trên github

Bước 5: Cấu hình Github page (bạn xem kỹ video của mình có hướng dẫn rồi nhé)

Gắn Domain

Bạn thực hiện gắn domain theo như hướng dẫn.
Mình dùng cloudflare để làm DNS cho domain của mình, bạn xem kỹ video để làm theo nhé.

 

Sau khi gắn xong bạn có thể có 1 trang web như mình 😀 https://blockchainba.hoangphan.blog/

Có gì chưa ok thì bạn có thể comment trên bài đăng youtube của mình, mình sẽ làm video hướng dẫn cụ thể hơn cho những bước bạn chưa hiểu nha.

Categories Blockchain Business Analyst

Business Analyst trong Mảng Blockchain: Liệu Cần Biết Đầu Tư Crypto?

by hoangphan Posted on

Câu hỏi đặt ra…

Khi nghe tới Blockchain, nhiều bạn chưa thử tiếp xúc nhiều sẽ nghe nó cao siêu, và sợ rằng giờ mình không biết gì về nó, thì có thể làm việc trong ngành Blockchain với vị trí liên quan đến phân tích nghiệp vụ hay không? Và liệu rằng BA có cần kiến thức đầu tư crypto, hay thậm chí là tham gia đầu tư hay không???

Thế giới blockchain có ảo diệu, khó tiếp cận?
Thế giới blockchain có ảo diệu, khó tiếp cận?

Thống nhất với các bạn đọc thế này, từ BA trong các bài viết của mình thường sẽ nói đến người làm công việc Phân tích nghiệp vụ, và những người này có thể có title là BA (Business Analyst), PO (Product Owner), PM (Product Manager), Research, Product Designer, UX/UI Designer, đôi lúc là Business Owner, Tester,… miễn là họ có làm công việc liên quan đến nghiên cứu về sản phẩm blockchain (IT) và tìm cách phân tích để xây dựng nên được product.

Câu trả lời ngắn gọn

Yeah, để trả lời câu hỏi trên, với kinh nghiệm đã tham gia chinh chiến rất nhiều dự án, từ dự án công ty, dự án làm với vài anh em, rồi đến những dự án cá nhân, rồi tham gia thi mấy cuộc thi về Blockchain và đạt nhiều lần giải nhất, nhì.

  • Làm các dự án blockchain mình thấy không khác gì các dự án thông thường, đôi lúc lại thấy dễ hơn khi làm các dự án blockchain.
  • Còn về phần đầu tư crypto thì không bắt buộc bạn phải biết đầu tư mới làm được các dự án blockchain, nhưng nếu bạn biết cách tìm hiểu và dùng 1 ít lộ phí để trải nghiệm thì giúp bạn tiếp cận được với dự án tốt hơn.

Tại sao như vậy?

Phần thứ nhất, về câu chuyện khó dễ trong việc làm dự án blockchain với dự án khác blockchain.

Mình nhận thấy làm việc tại các dự án blockchain thì khi mà bạn hiểu rõ về dự án, có kiến thức vững chắc về nghiệp vụ/hệ thống thì các dự án blockchain không khác gì các dự án thông thường, đôi lúc dễ hơn các dự án thông thường, như so sánh với hệ thống quản lý doanh nghiệp kiểu ERP, CRM hay Banking, Fintech, thì các dự án blockchain mình tham gia nó có đôi chút dễ hơn 1 tíu, vì những cái core như phần sổ cái là đã có những chain đi trước, mình có thể dùng opensource hoặc fork trực tiếp từ chain (thường là EVM) đang chạy tốt về sài và phát triển tiếp tính năng. Thậm chí là các sản phẩm vây quanh blockchain cũng có sẵn như Bridge, Dex (swap), Loan, Borrow,…

Ngoài ra vì các dự án blockchain họ hay kiểu opensource, document, thông tin được public, mình lại thấy dễ tìm hiểu và học hỏi từ những dự án có sẵn, từ đó có thể copy về hoặc biến tấu để xây dựng các dự án riêng. Còn trong trường hợp xưa mình làm về mobile banking, tìm tài liệu rất khó để học cũng như hiểu sâu về luồng, hoặc các dự án về bảo hiểm, core bank, những dự án như này phải đi làm công ty, có cơ hội tiếp xúc và có tài liệu để đọc chứ ít khi tài liệu hệ thống lại được phanh phui ra cho bất kỳ ai đọc cũng được.

Làm về blockchain không quá khó như bạn nghĩ.
Làm về blockchain không quá khó như bạn nghĩ.

Phần thứ hai, về việc biết đầu tư không bắt buộc phải biết nhưng vì sao nên biết?

Đầu tư crypto có nhiều loại, mấy loại mà nhiều người hay biết tới là mua coin trên sàn CEX như Binance, Mexc, BingX, Coinbase, … nhưng còn nhiều kiểu đầu tư khác như mua ở Dex, mua qua presale ở IDO, ICO, và nhiều kiểu khác nữa.

Vậy nếu người làm nghiệp vụ từng thử mua Sh*t coin trên một IDO nào đó, hoặc Swap token trên 1 Dex nào đó, thì họ được trải nghiệm từng bước một và nắm nhiều kiến thức buộc họ phải biết để đầu tư.

  • Từ tạo ví, biết về private key, lưu trữ seed phrases
  • Chuyển tiền từ CEX về Wallet với chain phù hợp => nắm được sự khác nhau giữa các chain, chuyển token cùng chain/khác chain
  • Hiểu về cách IDO hoạt động, FCFS là gì, Lottery trong IDO, launchpad,…
  • Hiểu về DEX, swap token, LP, Farming,..
  • Và nhiều kiến thức khác.

Mình đã từng thuê outsourcing cho công ty mình từng làm, mình nhận thấy một số bạn chưa bao giờ tham gia 1 dự án Launchpad, thì lại nghĩ ra không đủ trường hợp, build một dự án real mà thiếu đủ thứ, nhất là các tính năng vô cùng quan trọng xử lý các trường hợp đặc biệt lại không có, dẫn đến việc nguy hiểm khi làm business.

Như vậy nếu được trải nghiệm qua thực tế thì insight của người làm BA sẽ tốt hơn rất nhiều dẫn đến việc xây dựng dự án được đầy đủ hơn.

Dĩ nhiên còn nhiều yếu tố khác như phải thử ngẫm ra các trường hợp đặc biệt, đặt bản thân người phân tích vào trường hợp đó và tìm cách giải quyết.

Ví dụ như làm cái launchpad về token, khi có một dự án đăng ký, lên kế hoạch xong mọi thứ, truyền thông và cho chạy, nhưng tới gần ngày cho user vào đặt mua trước, thì dự án lại huỷ kế hoạch, hoặc thay đổi kế hoạch => Phải có những tính năng xử lý trường hợp này để mà refund tiền về cho người dùng tự động, hoặc cho người dùng claim tokens, hoặc nếu người dùng chưa vung tiền ra thì có thông báo, hoặc huỷ dự án đó và cho phép rút tiền về. Mình vẫn nhớ lần trước không có tính năng huỷ, và nếu dự án thay đổi là tiền bị mắc kẹt mãi trên blockchain => dự án mất tiền.

Nhưng cũng có rất nhiều dự án có môi trường testnet/devnet, và bạn tha hồ mà vào vọc, do đó không sợ phải mất tiền, và những dự án này hoàn toàn public, nên câu này cũng là câu ủng hộ cho việc làm dự án blockchain thì không cần phải biết về đầu tư, mình thấy đôi lúc biết đó chút ít thôi, chỉ để thử nghiệm để hiểu hệ thống hoạt động ra sao, và kèm theo đọc tài liệu nữa, thực tế biết nhiều toàn mất tiền vì “NGU” nếu không chuyên về đầu tư 😀 Nên biết nhiều nhiều về phần nghiệp vụ và biết ít ít về đầu tư nếu không chuyên là đủ nha :D.

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

Nghiệp vụ Blockchain cho Business Analyst

Image 1 of 8

Kết luận.

Trong khi việc am hiểu sâu sắc về đầu tư crypto không phải là yêu cầu bắt buộc cho một Business Analyst trong mảng blockchain, nhưng việc này chắc chắn sẽ mang lại lợi thế lớn. Kiến thức và kinh nghiệm thực tế sẽ giúp BA đưa ra quyết định chính xác, phát triển dự án mạnh mẽ.

Ngoài ra hãy tự tin tham gia mảng blockchain, vì thực sự nó không khó như bạn nghĩ, nếu dự án bự thì chắc chắn sẽ luôn có những người có kinh nghiệm ở sẵn đó và hướng dẫn bạn, còn nếu dự án nhỏ thì bạn có cơ hội học hỏi, đôi lúc là dự án không quá khó như những dự án bạn từng làm ở các công ty truyền thống. Với lại tài liệu nghiệp vụ, kỹ thuật ở các dự án blockchain là gần như public, do đó mà tha hồ mà học nghiệp vụ.

 

Categories Business Analyst

Phân biệt các môi trường phát triển phần mềm

by hoangphan Posted on
Các môi trường phát triển phần mềm

Mấy bữa trước ngồi chia sẻ cho một bạn BA mới vào làm mảng blockchain nắm thêm các môi trường phát triển phần mềm, nên sẵn có dịp viết lại để chia sẻ đến mọi người, có vẻ nó sẽ là kiến thức khá cũ với mọi người, nhưng đôi lúc bạn phân vân không biết được testing environment và staging environment khác nhau như thế nào, hay thỉnh thoảng lại bảo dev là “Deploy lên cho mình test với” thì dev hỏi lại “Deploy lên môi trường nào?”, hoặc thậm chí là bạn không biết khi nào gọi tên môi trường cho đúng và phù hợp, hi vọng dưới góc nhìn của một BA sẽ giúp bạn hiểu các môi trường này và áp dụng, triển khai nó một cách an toàn, hiệu quả.

Các môi trường trong phát triển phần mềm

Những môi trường mà mình nhắc đến trong bài viết hôm nay sẽ gồm có: Localhost (Development), Testing, Staging, Production, Sandbox, và một môi trường có thể hơi hơi lạ với một số người là Pilot, Devnet, Testnet.

Trước hết cho cái hình để bạn dễ hình dung hơn

Phân biệt các môi trường phát triển phần mềm
Phân biệt các môi trường phát triển phần mềm

Môi trường Development/Localhost:

  • Môi trường này là môi trường người Dev dựa theo tài liệu của BA và xây dựng tính năng trên máy của tính (local) của họ, người khác không thể truy cập server ngoài họ.
  • Database kết nối: Là database test, hoặc sandbox (tẹo mình sẽ giải thích sandbox là gì)
  • Người thực hiện test:
    • Người thực hiện test trên môi trường này chính là người Dev luôn, hoặc là một người Dev khác họ pull code về và chạy thử, test lại tính năng.
    • Đôi lúc team test nội bộ sẽ pull code của Dev xây dựng xong về test trên máy local của team test nội bộ luôn, nhưng mình nghĩ này có nhưng ít.
  • Vai trò của BA: Thường là hỗ trợ giải thích tính năng, nghiệp vụ, kiểm thử tính năng mới/hoặc bug fixed.

NOTE: BA cũng được xem như một phần của team test nội bộ

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

Môi trường Testing:

  • Môi trường này thường là môi trường được đội ngũ team test nội bộ chạy kịch bản kiểm thử đã được thiết kế trước, giúp tìm lỗi và sự cố trong phần mềm, đảm bảo chất lượng phần mềm trước khi lên những môi trường tiệm cận production, hoặc production.
  • Còn về phần dev thì xem thử mấy tính năng họ code có tích hợp được với code có sẵn hay code của người khác chạy được trơn tru hay không?
  • Database kết nối: Là database test hoặc sandbox
  • Người thực hiện test:
    • Người thực hiện chính là nhóm kiểm thử nội bộ
    • Dev đôi lúc sẽ vào test để kiểm tra lỗi có bị như nhóm kiểm thử nội bộ đã report hay không.
  • Vai trò của BA: Thường là hỗ trợ kiểm thử, review bugs, đứng ra làm việc giữ tester và dev để xác nhận bug là bug thật hay có thể bỏ qua, giải quyết tranh cãi giữa họ, có thể dùng môi trường này để UAT (một số trường hợp).

Môi trường Staging:

  • Cũng là môi trường test nhưng tập trung vào phần tương thích và ổn định của phần mềm trước khi triển khai, môi trường này gần như sát với môi trường production.
  • Database kết nối: Là database test hoặc sandbox, đôi lúc có thể cắm trên database production hoặc là lấy database production clone ra và đổi hay dấu đi những thông tin nhạy cảm như email, số điện thoại, id nhận notification,…
    • Tại vì khúc này môi trường cần gần giống với production để khi go live tránh xảy ra lỗi hoặc sự cố không đáng xảy ra nên cần phải có configuration/phần cứng, service tương tự với production.
    • Có những cái khi mà dev chạy trên local/testing env thì thấy ngon nghẻ, nhưng đẩy lên production cái sinh ra lỗi => Cũng là một lý do để có môi trường staging để tạo cơ hội cho dev tìm lỗi liên quan đến configuration, tính tương thích với phần cứng.
  • Người thực hiện test:
    • Người thực hiện chính là khách hàng hoặc nhóm kiểm thử nội bộ
    • Dev kiểm tra lỗi do KH hoặc tester report.
    • Đôi lúc vẫn có thể cho một số nhóm user đặc biệt test cùng (kiểu như sài thử và đưa ra feedback)
  • Vai trò của BA: UAT, follow nắm thông tin từ khách hàng khi họ test, trao đổi nghiệp vụ nếu cần, review lại bugs, confirm một số bugs có tranh cãi.

Môi trường Production:

  • Là môi trường chạy thật với người dùng và dữ liệu thật
  • Database kết nối: Là database thật.
  • Người thực hiện test:
    • Tester thực hiện test khi release sản phẩm
    • Dev kiểm tra lỗi do người dùng cuối report
    • BA follow hoặc kiểm tra lỗi do người khác report.
    • Người dùng cuối sử dụng
  • Vai trò của BA: Tương tác với người dùng cuối hoặc nhận thông tin từ bên khác liên quan đến lỗi, giải quyết vấn đề phát sinh, hỗ trợ người dùng, hoặc phân tích dữ liệu/ux để tìm ra những giải pháp tốt hơn cho phần mềm.

Môi trường Pilot:

  • Môi trường này mình mới biết từ năm 2019 khi làm các dự án liên quan đến banking.
  • Là môi trường chạy thật với một nhóm người dùng đặc biệt và dữ liệu thật, nhóm này sẽ đưa ra các nhận xét góp ý cho ứng dụng.
  • Thường thì Pilot sẽ nằm sau giai đoạn UAT và trước khi lên production
  • Test trên thời gian thực để tìm ra lỗi.
  • Không phải dự án nào cũng có môi trường này
  • Database kết nối: Là database thật.
  • Người thực hiện test:
    • Nhóm người dùng cuối đặc biệt được lựa chọn sẵn để sử dụng trước sản phẩm.
    • Nhóm kiểm thử team nội bộ và khách hàng.
  • Vai trò của BA: Tương tác với nhóm người dùng đặc biệt để thu thập phản hồi, ý kiến góp ý, từ đó giải quyết các vấn đề phát sinh.
  • Đây cũng là một môi trường xác minh tính sẵn sàng của dự án, nên mọi thứ giống y chang production, chỉ khác là cho một nhóm người sài, những người dùng cuối khác chưa được sài.

Môi trường Sandbox:

  • Sau khi xem xét thì thấy Sandbox không nên xếp vào nhóm của Localhost, testing, staging, pilot, production, mà nó là 1 kiểu thể loại khác.
  • Có thể hiểu nó là môi trường thật dùng thử, thường được sài cho những hệ thống liên quan đến tiền bạc, tài chính, payment
  • Vì là dùng thử nên nó là database thử (test) chứ không phải database thật, hoặc là clone từ thật ra, chỉ cần thay đổi endpoint (api) thì sẽ có thể giúp phần mềm hoạt động trên môi trường real.
  • Nếu không có sandbox thì khi test có thể khó cover nỗi những tính năng liên quan đến tiền thật.
  • Mình thấy nó khi làm blockchain, hoặc banking, billing, AAS, payment gateway.
  • Một số tên khác
    • Testnet/Devnet: Môi trường test/sandbox của một blockchain
    • Goerli, Sepolia: Môi trường testnet/sandbox của Ethereum.

Lưu ý khi làm việc trên các môi trường khác nhau.

  • Không nên để khách hàng vào môi trường testing, sau khi mình làm với rất nhiều khách hàng cho thấy để KH vào môi trường test họ sẽ thấy những cái không hay, hoặc có khi họ không hiểu mình đang làm gì và tưởng là mình đang làm sai yêu cầu, hoặc gây ảnh hưởng đến quá trình test của team nội bộ khi KH vào và thay đổi một số cấu hình.
  • Ở môi trường local host -> Có những trường hợp cần chạy cronjob liên tục hay sửa database sướng hơn trên môi trường testing (dù trên testing env vẫn thực hiện được nhưng đôi lúc gặp khó khăn)
  • Chia thành nhiều môi trường testing hoặc kế hoạch release trên testing env theo từng giai đoạn để tránh bug nó bị lộn xộn, ví dụ như báo bug xong dev fix và đẩy ngay lên testing mà không báo, hoặc 2-3 testers nhảy vào test chung 1 môi trường nhưng lại thay đổi DB có ảnh hưởng lẫn nhau, làm cho kết quả test bị rối hoặc bị sai.
  • Điều quan trọng là phải có môi trường Testing độc lập để không ảnh hưởng đến các môi trường khác và giúp dev tập trung vào việc tìm lỗi và sửa chúng, chứ đụng lỗi cái báo và fix liền, xong deploy lên test liền thì không hay.
  • Môi trường Staging, Pilot đôi lúc không cần thiết phải có mà có thể gộp lại thành môi trường testing thôi, lý do chính là khá tốn chi phí, tài nguyên khi phải cần gần giống với môi trường production.
  • Khi test ở Pilot hoặc Staging, BA cần kiểm tra lại với các thành viên khác vì có dính tới database thật, có thể sẽ gửi những kết quả test đến cho người dùng thật, do đó nên phân nhóm người dùng được nhận hoặc thay đổi email/phone thật thành những dữ liệu test.
  • Đối với môi trường Pilot, luôn phải có một kế hoạch liên quan đến việc Rollback release để khi có trường hợp xấu sẽ xử lý được.

Kết bài.

Với những chia sẻ của mình hi vọng các bạn hiểu được từng môi trường phát triển phần mềm, cũng như nhiệm vụ và trách nhiệm một BA làm việc trong từng môi trường, sẽ có những thay đổi trong tên gọi của môi trường, hay trách nhiệm của người làm BA trong từng dự án, công ty khác nhau.

Categories Business Analyst

Phân biệt Sketch, Wireframe, Mockup, Prototype cho anh em Business Analyst

by hoangphan Posted on

Khi mình làm việc với nhiều anh em Business Analyst, mình thấy nhiều bạn dùng các từ Sketch, Wireframe, Mockup và Prototype đôi lúc sai ngữ cảnh, ý nghĩa. Nên mình viết lại bài này, hi vọng sẽ giúp bạn hiểu hơn về các khái niệm, dùng khi nào và cách dùng cho hợp lý nhé.

1. Sketch

  • Là bản phác thảo một cái gì đó trên giấy hoặc trên bản vẽ ở máy tính.
  • Nó cung cấp cho mình những thông tin cơ bản.
Sketch
Sketch

DÙNG KHI NÀO?

  • Thường là giai đoạn đầu của việc phân tích, mình hình thành ra ý tưởng, luồng, màn hình cơ bản.
  • Mình hay vẽ đại ra trên giấy để có cái nhìn vô một cách trực quan để dễ hình dung và phân tích.

CÁCH DÙNG:

Vẽ đơn giản, dễ hình dung,  tiết kiệm thời gian, vẽ miễn sao dễ hiểu và nhanh, dễ truyền đạt ý tưởng chứ không cần vẽ cho đẹp.

Dùng giấy, hoặc phần mềm Excalidraw, Balsamiq, Figma

 

2. Wireframe

  • Là kiểu thiết kế có các thông tin cơ bản, giao diện cơ bản đủ thành phần (ví dụ phải đủ các trường, dữ liệu, nút button…)
  • Và bản thiết kế này thì không cần màu mè gì nhiều, không cần quá đẹp, nhìn vô là hiểu trên màn hình sẽ có nội dung ra sao, nút đặt chỗ nào, …
Wireframe
Wireframe
Đọc thêm  Công cụ vẽ wireframe và diagram tuyệt vời mình tìm được cho Business Analyst.

DÙNG KHI NÀO?

  • Trong khi phân tích chi tiết, viết tài liệu nghiệp vụ, business rule, trước khi làm UI, khi làm các bước về luồng màn hình.
  • Giúp cho thấy được sự luân chuyển giữa các màn hình (điều hướng), cách các màn hình làm việc với nhau.

CÁCH DÙNG:

  • Vẽ đơn giản, đầy đủ thông tin trên màn hình,  dễ hình dung,  tiết kiệm thời gian.
  • Đừng thêm màu mè quá nhiều, chỉ dùng các màu đơn giản để đánh dấu tạo điểm nhấn, nút quan trọng,…
  • Thông tin trên màn hình nên đầy đủ về trường, nút, …
  • Đi kèm với mô tả Business Rule hoặc viết tài liệu hoặc comment/chú thích.
  • Vẽ đường mũi tên để chỉ sự điều hướng giữa các màn hình, hoặc đôi lúc gắn nút điều hướng trên ứng dụng design để có thể thể hiện sự tương tác giữa các màn hình => giúp cho việc trình bày với KH, stakeholders khác dễ hình dung hơn.
  • Mình hay dùng Balsamiq, Figma, Excalidraw, Adobe XD, Giấy, hoặc Ipad (với bút) để tạo wireframe.

3. Mockup (UI)

  • Là kiểu thiết kế trực quan, khá giống với phiên bản thực tế khi xây dựng web/ứng dụng. Có màu đầy đủ, có mấy yếu tố như đổ bóng, viền, animation kèm theo,…
  •  Vẽ kỹ tới mức mà Front-end designer có thể nhấn vào và xem kích thước chính xác, có các thành phần CSS, responsive.
  • Mình làm công ty thì thấy mọi người hay gọi là UI, Bảng design
Mockup
Mockup
Đọc thêm  Figma Professional miễn phí: Công Cụ Đắc Lực Cho Business Analyst

DÙNG KHI NÀO?

  • Thường thì BA chả đụng gì trong phần thiết kế UI mà chỉ làm phần review luồng, nút có đủ chưa, phù hợp với tính năng nghiệp vụ đang làm hay không?
  • Thường được làm sau bước đã xong tài liệu nghiệp vụ/hoặc làm song song dạng cuốn chiếu với tài liệu nghiệp vụ.
  • Được dùng khi thiết kế trực quan, cụ thể để từ đó dựng nên giao diện web/ứng dụng.
  • Khi mà cần đánh giá yếu tố màu, phong cách, thương hiện, phối giữa các đối tượng giao diện, hình ảnh, sự chuyển động.

CÁCH DÙNG:

  • Thường BA ít/không làm phần này, mà là Designer sẽ lo, do đó BA có thể đi sâu vào mục review đánh giá, góp ý cũng như bổ sung thêm các thông tin còn thiếu trên giao diện, hay sự tương tác giữa các màn hình sao cho khớp với yêu cầu nghiệp vụ.
  • Nếu bạn có kỹ năng về phần giao diện này thì bạn có thể góp ý cũng như đưa ý kiến cá nhân nếu thấy sản phẩm mockup chưa được phù hợp.
Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

Prototype

  • Là một bản như Mockup mà nó có thể hoạt động được khi mình gắn sự liên kết giữa các màn hình và user có thể thao tác được. Mục tiêu chính là để mô phỏng sự tương tác giữa người dùng và giao diện.

DÙNG KHI NÀO?

  • Phần này thường bên BA dùng để đi trình bày với khách hàng, stakeholders, mô phỏng ứng dụng thực tế 
  • Hoặc có thể xem và đánh giá trước khi code để chắc chắn rằng bản giao diện phù hợp, luồng tính năng hợp lý, hoặc làm cả việc nhờ người dùng đánh giá,…

CÁCH DÙNG:

  • Cũng là phần Design lo là chính, BA thường phụ phần gắn tương tác giữa các màn hình.
  • Lưu ý khi bật prototype thì chọn màn hình cho phù hợp, mà mở ở mức 100% để cảm nhận nó giống thật, không bị phóng to, hay thu nhỏ mà đánh giá sai về giao diện.
  • Với mình thì mình đánh giá cả độ tương phản, rồi test WCAG.
  • Ngoài ra Prototype còn hay được dùng cho các ứng dụng xây tạm thời, mô phỏng giao diện và build ra app/web để đưa ra cho người dùng thấy (có thể viết một vài tính năng cơ bản mà chưa xây dựng đủ, dùng dữ liệu giả,…)

Kết bài.

Cảm ơn bạn đã đọc bài viết của mình, nếu có gì sai sót hoặc chưa đúng thì để lại comment cho mình nhé.

Categories Business Analyst

Thực tập IT Business Analyst cần những kỹ năng gì?

by hoangphan Posted on
Thực tập sinh IT BA cần những kỹ năng gì?

Hi lại là Hoàng đây!

Chắc có lẽ nhiều bạn đang còn ngồi trên ghế nhà trường, hoặc đang đi làm có ý định thực tập vị trí IT Business Analyst quan tâm rằng

“Cần những kỹ năng gì để có thể được nhận làm vị trí thực tập sinh IT Business Analyst.”

Dưới đây là góc nhìn của mình, một người từng tuyển dụng nhiều vị trí BA chia sẻ về các kỹ năng mình cần tìm ở một bạn ứng viên thực tập sinh IT Business Analyst.

Ba kỹ năng chính mình tìm ở Thực tập sinh.

  • Kỹ năng về logic và hiểu về hệ thống
  • Kỹ năng về giao tiếp
  • Kỹ năng về documentation.

Vậy chi tiết từng kỹ năng mình yêu cầu như thế nào?

Kỹ năng đầu tiên: Logic và hiểu về hệ thống

Theo quan điểm của mình thì người IT BA phải là người có thể suy luận logic và đưa ra những giải pháp hợp lý cho dự án phần mềm, mà để làm được điều này thì bản thân người làm cũng phải hiểu về tư duy hệ thống, đối với level thực tập, fresher thì tư duy hệ thống cơ bản là bắt buộc, ví dụ như tư duy Ba tầng của phần mềm gồm có tầng giao diện (UI), tầng xử lý nghiệp vụ – logic và tầng kết nối lưu trữ dữ liệu. Cách hệ thống hoạt động cho luồng đăng nhập, thì user phải nhập thông tin đăng nhập tại giao diện (UI) và gửi yêu cầu đến xử lý ở tầng nghiệp vụ – logic, và từ tầng này sẽ truy xuất và so sánh kiểm tra với dữ liệu trong hệ thống để biết được thông tin đăng nhập có khớp không?

Ba tầng xử lý trong IT BA
Ba tầng trong ứng dụng phần mềm.

Hay là cách phần mềm hoạt động như thế nào, có thể tư duy ra được các trường hợp có thể xảy ra, giống như chuyện suy luận “nếu hôm nay mình quên học bài” thì sẽ có những trường hợp nào xảy ra như “không thuộc bài”, “bị cô giáo phạt”, “bị lên sổ đầu bài”, “mẹ biết bố mẹ buồn”,… thì khi áp dụng vô phần mềm, ví dụ đăng nhập thì phải tư duy được người dùng có thể dùng phương thức nào để đăng nhập như “email/pass”, “số điện thoại/pass”, …. và trong email/pass lại có những trường hợp nào có thể xảy ra  như “email không hợp lệ”, “email không tồn tại”, “mật khẩu bị sai”, … hoặc đăng nhập xong thì phải có tư duy suy luận là hiển thị màn hình gì? màn hình hiển thị cần những thông tin gì? những thông tin đó ở đâu, các trường hợp có thể xảy ra khi đăng nhập thành công.

Do đó khi phỏng vấn thực tập sinh hay fresher, thường câu hỏi của mình sẽ hỏi đến các câu hỏi thực tiễn để xem các bạn có tư duy logic suy luận như thế nào? và hiểu cách hệ thống chạy ra sao? mình sẽ chưa quan tâm đến trong cuộc phỏng vấn thì ứng viên có trả lời hoàn hảo hay không, mà sẽ quan tâm đến cách ứng viên đi tìm ra câu trả lời sao cho phù hợp và đưa ra “giải pháp” phù hợp theo tư duy logic của ứng viên.

Đọc thêm  Khoá học nghiệp vụ Blockchain cho Business Analyst

Kỹ năng thứ hai: Giao tiếp

Tiếng Anh là một lợi thế cực lớn cho các bạn làm IT BA, với nỗi đau trước đó của mình, khi bắt đầu làm BA thì tiếng Anh của mình ở đâu đó 500-600 TOEIC, mà còn giao tiếp (nghe/nói) cực yếu nữa, khi làm dự án Âu Mỹ hay Sin thì mình bị ngợp, cũng như mình tìm thông tin chưa quá tốt và tốn nhiều thời gian khi phải gần như là sài Translate rất nhiều, gặp khách hàng trực tiếp thì lúc nào cũng cần có một bạn làm công việc như PM đi cùng để giúp mình, rất là bất tiện.

Nên thường mình cũng sẽ khá quan tâm đến kỹ năng tiếng Anh của ứng viên, dĩ nhiên ở mức giao tiếp cơ bản đủ sài. Hoặc giống như lúc mình xuất phát với vị trí BA, thì đọc hiểu cơ bản là mình chấp nhận nhưng luôn dặn ứng viên là cần phát triển thêm về Giao tiếp.

Tiếng Anh thì tuỳ thuộc công ty và dự án, nếu dự án ít dùng hay không dùng thì tiếng Anh không quá bắt buộc, nhưng có tiếng Anh là một lợi thế cho BA. Ngoài liên quan đến làm việc giữa anh em dự án, khách hàng, thì còn ảnh hưởng đến việc tìm kiếm thông tin hay học hỏi thêm kỹ năng BA từ nơi khác, đặc biệt là các nguồn tài liệu tiếng Anh.

Giao tiếp và trao đổi tốt là một điều rất cần của một BA, khi mà BA là nơi cầu nối giữa Khách hàng và Đội ngũ phát triển dự án, thì việc giao tiếp là bắt buộc. Giao tiếp ở đây là khái niệm khá chung chung, nó bao gồm cả việc nói chuyện với khách hàng, khơi gợi khách hàng để họ chia sẻ ra những cái NEED (dịch tạm là yêu cầu/cần) của họ, trao đổi trong lúc làm việc, kết nối anh em đội ngũ, hay trình bày ý tưởng, chia sẻ quan điểm cá nhân, thuyết phục mọi người.

Communication Kỹ năng giao tiếp
Kỹ năng giao tiếp

Do đó với phần giao tiếp này mình thường hay hỏi về tính cách, rồi công việc, các hoạt động từng tham gia ở sinh viên hay cách ứng viên trả lời phỏng vấn.

 

Kỹ năng thứ ba: Documentation

Kỹ năng này là kỹ năng cuối cùng mà mình thường tìm ở ứng viên, nhưng độ quan trọng nó sẽ không cao bằng 2 yêu cầu phía trên, vì bản chất người làm công việc BA là người có tư duy và đưa ra giải pháp, cách trao đổi nói chuyện với mọi người để giải quyết vấn đề trong phát triển phần mềm, phải có tư duy thì mới có giải pháp được, còn việc viết lại tài liệu là một kỹ năng theo sau bổ trợ cho tư duy và giải pháp để giúp làm rõ giải pháp cũng như truyền tải giải pháp ra một cách dễ dàng hơn.

Nhưng ứng viên cũng cần PHẢI biết để thể hiện rằng ứng viên biết về BA sẽ làm những loại việc gì? có tìm hiểu và tìm cách học các kỹ năng về documentation, wireframing.

Kỹ năng sketch
Kỹ năng sketch

Đa phần bây giờ khi tìm trên google sẽ ra ngay là documentation thì cần học cách viết BRD, URD, SRS, User Story, … rồi vẽ sketch, wireframe,… học về UML, BPMN.

Đọc thêm  Balsamiq Wireframe miễn phí - công cụ cho Business Analyst

 

Đọc thêm  Thực tập IT Business Analyst cần những kỹ năng gì?
Review wireframe/mockup dễ hơn với tool Axure Cloud.”]

 

Nên thường ở đoạn kỹ năng này mình sẽ hỏi các câu hỏi liên quan đến việc các bạn ấy biết là BA cần làm gì ở phần viết tài liệu, tài liệu nào sẽ được dùng trong trường hợp nào, đã học được công cụ gì rồi, diagram A thì khi nào sài, diagram B khi nào sài, …

 

Kết bài

Với kinh nghiệm từng tìm vị trí thực tập, rồi đến giai đoạn mình tìm ứng viên là thực tập sinh, fresher rồi các bạn làm công việc BA ở các level cao hơn, phỏng vấn vài chục bạn BA để tuyển dụng. Khi tuyển dụng thực tập sinh ba kỹ năng quan trọng mà mình cần tìm ở thực tập sinh IT Business Analyst là Tư duy logic, hiểu về hệ thống, kỹ năng về giao tiếp và trình bày trên tài liệu, biết các công cụ cơ bản để trình bày.

Hi vọng bài viết trên sẽ giúp các bạn trả lời phần nào thắc mắc “Thực tập sinh IT Business Analyst cần những kỹ năng gì?”, giúp các bạn sớm chuẩn bị đầy đủ những kỹ năng phù hợp để ứng tuyển vị trí BA.