S-BA: Business Analyst and Beyond

25/10/2022

🔥💥⚡️ Cơ hội dành cho tất cả mọi người - những "nhà lập trình viên nhân dân" (Citizen developer).

Những bạn BA hoặc non-BA của S-BA: Business Analyst and Beyond chỉ cần am hiểu nghiệp vụ thì đều có thể tạo ra ứng dụng cho mình hoặc công ty mình dựa vào những nền tảng Low/No-code. Thế giới công nghệ đang quá rộng mở với chúng ta.

[PHẦN MỀM NO-CODE SẼ CHIẾM LĨNH THỊ TRƯỜNG VÀO NĂM 2024]

Tương lai của công nghệ sẽ như thế nào? Một số người cho rằng đó là sự phát triển của robot hoặc có lẽ trí tuệ nhân tạo (AI) sẽ tối ưu cuộc sống của con người. Nhưng khi nói đến thế giới của công việc, một trong những thay đổi quan trọng nhất sẽ đến trong thời gian ngắn đó là việc dịch chuyển từ sử dụng các sản phẩm, dịch vụ được xây dựng thông qua code cứng (hard code) sang no-code.
Đến năm 2024, phần mềm no-code sẽ thống trị lĩnh vực công nghệ và hơn thế nữa.
Giới công nghệ từ lâu đã ca ngợi các dạng phần mềm này như một cách để tạo điều kiện tiếp cận web và cung cấp cho người lao động thông thường khả năng thực hiện loại công việc mà trước đây chỉ dành riêng cho các kỹ sư phần mềm. Từ phát triển ứng dụng, đến đối chiếu tài khoản, đến lập bản đồ trải nghiệm khách hàng, chúng ta đang tiến tới một tương lai nơi tự động hóa sẽ thay thế công việc thường được hoàn thành bởi con người trong tất cả các loại ngành.
Và, tất nhiên, sự gia tăng của tự động hóa sẽ đi đôi với tương lai no code.
Khi thảo luận về tương lai của No code, chúng ta phải thừa nhận rằng khái niệm này không quá xa vời. Thậm chí, ai đó có thể ý kiến rằng đã có sự xuất hiện của No-code. Nó đã thay đổi môi trường làm việc hiện đại và tạo ra một thế hệ các nhà phát triển ứng dụng mới - “những lập trình viên nhân dân” (citizen developer)

🔶🔥✔️ Các ứng dụng No-code có thể mang lại nhiều lợi ích hơn so với những kĩ sư phần mềm thuần túy.

Thường khi nghe đến từ “code”, mọi người sẽ nghĩ đến hình ảnh của một kỹ sư phần mềm, cặm cụi sử dụng một ngôn ngữ lập trình nào đó mà nhiều người khác không thể hiểu được. Và mặc dù các ứng dụng No-code có thể làm cho công việc của các kỹ sư phần mềm được thu xếp hiệu quả hơn, chúng cũng có thể mang lại lợi ích cho những người khác tại nơi làm việc. Với sự gia tăng của các ứng dụng No-code, khái niệm "lập trình viên nhân dân” được ra đời.
Các nhà “lập trình viên nhân dân” này là những người không biết code cũng không xuất thân từ nền tảng kỹ thuật phần mềm, họ là những người trong doanh nghiệp, ví dụ như lãnh đạo, nhân viên, tự xây dựng các ứng dụng công nghệ thông tin cho mình, hoặc cho người khác bằng cách sử dụng các công cụ được phép của bộ phận công nghệ thông tin trong doanh nghiệp, mặc dù họ không cần có kiến thức lập trình (no-code) hoặc chỉ cần biết ở mức cơ bản (low-code). Họ chứng minh tương lai của công nghệ không nằm trong tay của thiểu số các kỹ sư phần mềm mà là của đa số mọi người.
Các nhà lập trình viên nhân dân này có thể là chủ doanh nghiệp sử dụng nền tảng no-code CMS để xây dựng trang web thương mại điện tử của họ hoặc nhà thiết kế đồ họa sử dụng công cụ thiết kế no-code để tạo ra sản phẩm hoàn hảo.
Họ thậm chí có thể là nhà tiếp thị truyền thông, bằng cách sử dụng công cụ no-code cho việc lập lịch biểu các hoạt động để duy trì sự hiện diện thương hiệu của họ trên mạng xã hội. Nhìn chung, không có giới hạn cho các nhà “lập trình nhân dân”. Môi trường làm việc dần chuyển sang hướng tự động hóa hơn nữa, đòi hỏi nhiều ứng dụng no-code hơn.

🔶🔥✔️ Phần mềm No-code giúp cắt giảm công việc kiểm tra ngược hệ thống khi có vấn đề
Phần mềm No-code mang lại lợi ích cho các nhà lập trình nhân dân, và cũng hữu ích cho các nhà phát triển ứng dụng truyền thống. Coding là một quá trình dài, nhưng trớ trêu thay, các nhà phát triển phần mềm thường có thời hạn nghiêm ngặt. Do đó, tình huống thường gặp là nhà phát triển phần mềm quay lại để kiểm tra, giải quyết vấn đề, lỗi phần mềm sau khi đã code xong.
Bởi vì phần mềm no-code sắp xếp hợp lý quá trình phát triển và giảm thiểu rất nhiều thời gian cho việc coding, các nhà phát triển phần mềm có thể dành nhiều thời gian hơn, tối ưu hơn cho giải quyết các vấn đề quan trọng hơn.
Khi công nghệ tiến tới một tương lai No-code, chúng ta có thể sẽ thấy sự thay đổi công việc hàng ngày của các lập trình viên phần mềm. Sự dịch chuyển đó, đến cuối cùng, có thể là điều tốt nhất. Với nhiều thời gian hơn để tập trung vào giải quyết các vấn đề một các bao quát, các nhà phát triển phần mềm sẽ có ít nhu cầu cần kiểm tra ngược lại hệ thống mỗi khi phát hiện lỗi hơn. Thay đổi này có thể sẽ tiết kiệm thời gian cho các dự án, cải tiến công nghệ theo những hướng mà không thể thực hiện được nếu không có phần mềm no-code.

🔶🔥✔️ Khách hàng sẽ đầu tư vào phần mềm mới nếu nhu cầu của họ được đáp ứng trong thời gian ngắn
Bạn có thể cho rằng 2024 cho sự xoay chuyển này là thời hạn không đủ dài để thế giới công nghệ tiến tới một tương lai No-code. Bạn có thể cho rằng các công ty công nghệ không sẵn sàng đầu tư vào những thay đổi lớn như vậy chỉ trong vài năm.
Nhưng sự thật là các công ty công nghệ đang tìm cách tự động hóa các quy trình của họ và giải quyết nhu cầu tăng trưởng phát triển.
Những khách hàng B2B có kinh nghiệm thường sẽ chỉ tương tác với các nỗ lực tiếp thị nếu sản phẩm đó có thể tháo gỡ được các vấn đề hàng đầu mà họ trăn trở. Và yếu tố thúc đẩy phổ biến nhất đến việc mua hàng đó là sản phẩm có thể giải quyết được nhu cầu của doanh nghiệp họ trong thời gian ngắn.
Một số nhu cầu quan trọng nhất mà lĩnh vực công nghệ phải giải quyết là khoảng cách kỹ năng ngày càng lớn và nhu cầu bắt kịp với sự chuyển đổi ngày càng tăng của công nghệ.
Vì nền tảng No-code tự động hóa các quy trình tốn thời gian, các công ty sẽ cần phải áp dụng các ứng dụng này để theo kịp các đối thủ cạnh tranh của họ. Tuy nhiên, khi quan ngại đến vấn đề khoảng cách kỹ năng ngày càng tăng, phần mềm No-code sẽ giúp giải quyết phần nào những lo lắng này bằng cách cho phép mọi người trở thành những nhà “lập trình nhân dân”.

🔶🔥✔️ Tương lai No-code đã ở quanh chúng ta
Tính đến năm 2021, 455 triệu trang web sử dụng WordPress - nền tảng CMS cung cấp cả cách phát triển trang web No-code và Low-code. Trước khi phát triển các trang web như Wix, WordPress hay Squarespace, tất cả các website đều được xây dựng bằng code bởi lập trình viên truyền thống.
Với việc bình dân hóa việc tạo web, các nền tảng này cho phép người bình thường xây dựng các trang web của riêng họ.
Các chủ doanh nghiệp tìm ra hình thức bán hàng trực tuyến mới khiến thương mại điện tử bùng nổ. Trên thực tế, tính đến năm 2022, hơn 6,3 triệu trang web sử dụng plugin WooCommerce của WordPress, chứng minh cách mà các ứng dụng No-code đã định hình thế giới thương mại điện tử trực tuyến.
No-code cũng đã thay đổi môi trường làm việc cả online và offline. Trong thế giới làm việc ngày nay, chúng ta phải thừa nhận rằng tự động hóa sẽ tăng tốc các quy trình đã từng tốn rất nhiều thời gian để thực hiện. Và sự tự động hóa đó thường đến từ các ứng dụng No-code hoặc Low-code.
Ví dụ: Công cụ quản lý dự án Monday, được hơn 152.000 công ty sử dụng tính đến năm 2021, chứa các tính năng cho phép tự động đồng bộ hóa dữ liệu, tích hợp các công cụ chức năng công việc khác và tùy chỉnh các ứng dụng cần thiết cho doanh nghiệp.
Đặc biệt với xu hướng ảo hóa/ trực tuyến hóa các môi trường làm việc, các công cụ quản lý dự án này trở nên cần thiết để giữ cho các thành viên dự án đi đúng kế hoạch.

🔶🔥✔️ Kết luận
Công nghệ No-code có thể nghe giống như viễn tưởng xa vời, nhưng thực tế là nó đã ở quanh đây. Phần mềm No-code đã tạo ra một thế giới đầy những nhà "lập trình nhân dân”, thu nhỏ khoảng cách về kỹ năng và tạo ra những cách thức mới để những người không có kinh nghiệm về code có thể thay đổi thế giới làm việc.
Mặc dù năm 2024 có vẻ là một thời gian ngắn để các công ty công nghệ thích ứng với tương lai No-code nhưng nhiều doanh nghiệp đã bắt đầu quen với nó, có thể thông qua phần mềm quản lý dự án, tạo ứng dụng hay hình thức tự động hóa khác.
Khi các công ty công nghệ lớn hơn áp dụng các quy trình này, họ sẽ mở đường cho nhiều doanh nghiệp hơn làm theo vì xu hướng sợ bị tụt lại phía sau.
No-code đã chứng minh nó đã xuất hiện để tồn tại.

Source: CDP

06/07/2022

[S-WORD] KANBAN

Kanban được coi là một phương pháp Agile nhưng không nhất thiết cần có tính lặp, cho phép phần mềm được phát triển trong một chu kỳ phát triển lớn.

Trong Kanban, Các hạng mục công việc được hiển thị trực quan để cung cấp cho người tham gia một cái nhìn về tiến độ và quy trình, từ đầu đến cuối — thường thông qua bảng Kanban. Công việc được kéo theo khả năng cho phép, thay vì đẩy công việc vào quy trình khi được yêu cầu.

Lợi ích của việc sử dụng Kanban có thể kể đến :
🔸 Lập kế hoạch linh hoạt
🔸 Chu kì thời gian làm việc được rút ngắn
🔸 Ít tắc nghẽn
🔸 Số liệu trực quan
🔸 Chuyển giao liên tục

Kể từ năm 2004 được áp dụng lần đầu vào quá trình phát triển phần mềm tại Microsoft, Kanban đã được nhiệt tình áp dụng trong các nhóm CNTT, Ops, DevOps và ứng dụng phần mềm. Việc áp dụng Kanban trong ngành IT và phần mềm giúp cải tiến về quy trình, giảm thời gian và đáp ứng nhu cầu về sản phẩm từ khách hàng.

27/06/2022

KHÁC BIỆT GIỮA CÔNG TY PHẦN MỀM PRODUCT VÀ CÔNG TY PHẦN MỀM OUTSOURCE

Với sự phát triển nhanh chóng của công nghệ trong thời đại 4.0, ngành công nghệ thông tin (IT) của Việt Nam ngày càng phát triển thần tốc. Song hành với đó là sự ra đời của nhiều các công ty phần mềm Product và công ty phần mềm Outsource. Hãy cùng tìm hiểu về hai thuật ngữ trên và sự khác biệt giữa hai hình thức công ty phần mềm này.

CÔNG TY PHẦN MỀM PRODUCT

Công ty phần mềm product là những công ty tự xây dựng sản phẩm, quảng bá và bán các sản phẩm ứng dụng phần mềm do chính họ làm ra. Nhóm khách hàng chủ yếu là những người dùng cuối (end-user) và doanh thu sẽ đến từ việc họ trả tiền để mua những phần mềm đó. Đặc trưng của những công ty phần mềm product là sẽ tập trung vào sự hài lòng của người dùng cuối để phát triển sản phẩm, nỗ lực hoàn thiện từ lúc bắt đầu đến khi nhận được phản hồi của khách hàng và tiếp tục ngày càng hoàn thiện theo từng năm. Đồng thời một ưu điểm của công ty Product là sẽ cung cấp dịch vụ tư vấn hỗ trợ cho khách hàng, không chỉ giúp tìm ra những vấn đề còn tồn đọng trong doanh nghiệp, mà còn có thể thiết kế ra sản phẩm phù hợp nhất với nhu cầu và thực tiễn nhất với khách hàng.

CÔNG TY PHẦN MỀM OUTSOURCE

Các công ty phần mềm outsource hay các công ty gia công phần mềm tập trung vào việc viết mã cho các trang web, web / ứng dụng di động hoặc trò chơi. Các công ty outsource sẽ không tập trung vào một phần mềm nhất định do chính họ làm ra mà sẽ chuyển từ sản phẩm này sang sản phẩm khác một cách nhanh chóng. Những công ty gia công sẽ chỉ làm việc với một hoặc một vài vấn đề nhỏ trong một khoảng thời gian nhất định, trái ngược với sự gắn bó suốt chu kỳ sản phẩm như công ty phần mềm product. Nhược điểm của những công ty Outsource là không cung cấp dịch vụ tư vấn cho khách hàng, mà thay vào đó nhiệm vụ của khách hàng là tạo ra chiến lược sản phẩm và lựa chọn công nghệ phù hợp cho ứng dụng.

Mỗi loại hình công ty phần mềm đều có ưu nhược điểm riêng, tuy nhiên nếu bạn đang tìm cho doanh nghiệp của mình một giải pháp công nghệ hoàn thiện, phù hợp nhất với nhu cầu doanh nghiệp và được đặt trải nghiệm của người dùng làm trọng tâm thì công ty Product nên là lựa chọn ưu tiên hàng đầu.

22/06/2022

[S-WORD] SCRUM

Scrum là một framework về quy trình và quản lý giúp giải quyết các vấn đề phức tạp, nhưng vẫn đảm bảo tính hiệu quả, sáng tạo và sản phẩm được tạo ra phải đạt được giá trị cao nhất.

Với Scrum, sản phẩm được xây dựng trên 1 chuỗi các quy trình lặp lại (gọi là Sprint) gồm:
🔸 Sprint planning: Lên kế hoạch của đội dự án, xác định nhiệm vụ cần hoàn thành.
🔸 Daily stand-up (Daily scrum): Trao đổi công việc giữa đội phát triển.
🔸 Sprint demo: Chia sẻ về những công việc đã được hoàn thành.
🔸 Sprint retrospective: Đánh giá lại và đưa ra giải pháp hành động cho Sprint tiếp theo.

Các sprint diễn ra đều đặn, mỗi một sprint là cơ hội để học hỏi điều chỉnh nhằm đạt được sự phù hợp và kết quả tốt nhất.

Scrum hoạt động dựa trên ba giá trị cốt lõi: Minh bạch (transparency), Thanh tra (inspection) và Thích nghi (adaptation).

15/06/2022

[S-WORD] EPIC

Epic là thuật ngữ được sử dụng trong phương pháp quản trị dự án Agile, ám chỉ đến User Story lớn (Large User Story) mà không thể hoàn thiện và chuyển giao trong một phân đoạn lặp lại của Agile, hoặc là đủ lớn để có thể phân rã thành các User Stories nhỏ hơn.

Epic có sự tương đồng với User Story, nhưng lại có xu hướng sử dụng theo một cách rất khác. Hai cách dùng phổ biến là:
🔸 Dùng Epic như một sáng kiến: Công ty có những mục tiêu chiến lược cấp cao hoặc các hoạt động được thiết kế để đạt được mục tiêu nhất định. Một số team dựa vào những sáng kiến này để nhóm User Stories và Deliverables - giao phẩm.
🔸 Dùng Epic như là chức năng cốt lõi: một số team sẽ nhóm User Stories và Deliverables - giao phẩm dựa vào chức năng chính, ví dụ như: nhóm lãnh đạo, nhóm bán hàng…

11/06/2022

Nếu ... là một môn thể thao

08/06/2022

[S-WORD] AGILE

Triết lý phát triển phần mềm Agile được mô tả là một phương pháp phát triển phần mềm linh hoạt sao cho có thể đưa sản phẩm đến tay người dùng càng nhanh càng tốt, với 4 giá trị cốt lõi:
🔸 Cá nhân và sự tương tác hơn là quy trình và công cụ
🔸 Phần mềm chạy tốt hơn là tài liệu đầy đủ
🔸 Cộng tác với khách hàng hơn là đàm phán hợp đồng
🔸 Phản hồi với sự thay đổi hơn là bám theo kế hoạch

Đặc trưng của Agile chính là tính lặp, mỗi dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại, được gọi là Iteration hoặc Sprint, thường có khung thời gian ngắn từ 1 – 4 tuần.

Trong mỗi một phân đoạn, nhóm phát triển thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử theo từng mức độ phù hợp khác nhau để cho ra các phần nhỏ của sản phẩm. Các phương pháp tuân theo triết lý Agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể.

31/05/2022

[S-WORD] USER STORY

User Story mô tả yêu cầu đối với các chức năng hoặc tính năng theo góc độ phía người sử dụng. Một User Story thường đề cập yêu cầu đơn giản nhất và là về một và chỉ một chức năng, hoặc một tính năng.

User Story có thể được xây dựng bởi bất cứ ai, có thể từ chính khách hàng, đại điện của khách hàng hoặc đội ngũ phát triển sản phẩm.Khi có sự kết hợp trao đổi từ nhiều phía, đảm bảo sự thông suốt giữa khách hàng và nhóm phát triển, định hướng xây dựng cùng các tính năng của sản phẩm sẽ trở nên thực tiễn và phù hợp hơn.

Hoạt động xây dựng User Story có thể diễn ra trong suốt quá trình phát triển dự án, đồng nghĩa với bất cứ lúc nào các bên tham gia cũng có thể thêm vào các User Story mới.

29/05/2022

🤫🤫🤫

27/05/2022

NHỮNG PHƯƠNG THỨC MOI MÓC THÔNG TIN TỪ KHÁCH HÀNG

Như đã được định nghĩa trong bài viết trước, Elicitation là một dạng kĩ năng nhằm tiếp cận một cách có cấu trúc để có thể “moi móc” được thông tin cũng như yêu cầu từ khách hàng. Việc moi móc thông tin này có thể tiến hành thông qua nhiều phương thức khác nhau, tiêu biểu có thể kể đến:

🔸Brainstorming:

Là phương pháp sử dụng sự sáng tạo để tìm ra giải pháp cho một vấn đề. Để có thể brainstorming tập trung và hiệu quả, các Business Analyst có thể thành lập một nhóm với đại diện của tất cả các bên liên quan (stakeholders) để nắm bắt các yêu cầu thay vì phải trực tiếp liên lạc với stakeholder.

🔸Phân tích tài liệu:

Trong bước này, BA sẽ xem xét tài liệu hiện có với mục đích xác định các requirement để thay đổi hoặc cải tiến. Những nguồn tài liệu bao gồm kế hoạch dự án đã có từ trước, đặc điểm hệ thống, tài liệu quy trình, hồ sơ nghiên cứu thị trường, phản hồi của khách hàng, biên bản cuộc họp và tài liệu hướng dẫn sử dụng. Việc phân tích tài liệu được thực hiện trước khi lên lịch cho các buổi tìm hiểu các requirements chuyên sâu hơn hoặc các cuộc phỏng vấn với các stakeholder.

🔸Prototyping:

Đây là việc sử dụng các phiên bản thử nghiệm (prototype) hoặc các mockup, wireframe để xác nhận nghiệp vụ với stakeholders. Lợi ích khi sử dụng prototyping là giúp BA bớt công sức thu thập yêu cầu về UI (giao diện người dùng). Việc sử dụng các phiên bản thử nghiệm giúp nhận được phản hồi sớm, từ đó thúc đẩy sự tham gia của các stakeholder vào việc trao đổi các yêu cầu.

🔸Workshop:

Workshop là cuộc họp mà có nhiều người cùng tham gia thảo luận về một vấn đề cụ thể. Tổ chức workshop là một cách hiệu quả để các bên liên quan có thể cùng thảo luận về yêu cầu của mỗi bên và tìm cách cân bằng lợi ích các bên. Các sự kiện hội thảo giúp BA và các stakeholder cộng tác, giải quyết mâu thuẫn và đi đến sự thống nhất.

🔸Khảo sát:

Là việc sử dụng mẫu khảo sát hoặc danh sách các câu hỏi có sẵn để thu thập thông tin từ câu trả lời, phản hồi của stakeholder. Sau đó, các câu trả lời được phân tích để chắt lọc thành các yêu cầu. Các cuộc khảo sát ít tốn kém hơn so với các kỹ thuật moi móc thông tin (elicitation) khác, dễ thực hiện và có thể tạo ra cả kết quả định tính và định lượng.

24/05/2022

[S-WORD] STAKEHOLDER REQUIREMENT

Theo BABOK: “Stakeholder Requirements describe the needs of stakeholders that must be met in order to achieve the business requirements.”

Như vậy, Stakeholder Requirement là những yêu cầu cụ thể của từng bên liên quan - stakeholder, thể hiện được nhu cầu cụ thể của các stakeholder nhằm đạt được các Business Requirement.

Các yêu cầu của stakeholder sẽ liên quan trực tiếp tới các vai trò cụ thể của họ đồng thời cả những bộ phận, hệ thống có sự tham gia của họ.

Stakeholder Requirement được cho là cầu nối giữa yêu cầu về tầng chiến lược và yêu cầu mặt giải pháp. Vì vậy Business Requirement và Stakeholder Requirement cần phải ăn khớp và bổ trợ cho nhau, hay nói cách khác Business Requirement chỉ đạt được khi Stakeholder Requirement đã được đảm bảo.

Về tài liệu output của loại yêu cầu này, trong các dự án phát triển theo mô hình Waterfall có thể là User Requirement Document (URD), Functional Requirement Document (FRD). Còn đối với dự án phát triển theo mô hình Agile/Scrum thì đó là User Story, Product Backlog, Product requirement document.

23/05/2022

🧐🧐🧐

20/05/2022

[S-WORD] ELICITATION

Requirement hay các yêu cầu là phần quan trọng nhất mỗi khi bắt đầu triển khai một dự án. Requirement đối với nghiệp vụ của BA sẽ được tồn tại trong 2 giai đoạn của một dự án: Giai đoạn moi móc thông tin của khách hàng (Elicitation) và Giai đoạn phân tích (Analysis).

Elicitation là một dạng kĩ năng nhằm tiếp cận một cách có cấu trúc để có thể “moi móc” được thông tin cũng như yêu cầu từ khách hàng. Thông thường ban đầu các yêu cầu chỉ ở trong suy nghĩ của các stakeholders và chưa được nêu ra, vậy nên elicatation là khơi gợi thông tin từ khách hàng, "hô biến” những yêu cầu còn chưa được phát biểu kia thành những requirement đã được phát biểu. Đây chính là nền tảng của bất kỳ dự án nào, vì requirement chính xác là điều kiện cần để tạo ra một phần mềm chính xác và khớp với nhu cầu của khách hàng.

Elicitation là một trong những giai đoạn phức tạp và thách thức nhất trong quá trình phát triển phần mềm, đòi hỏi nhiều nỗ lực giao tiếp và khả năng phân tích. Đây là bước then chốt trong việc xác định ngân sách, ước tính thời gian và phạm vi của một dự án. Nếu như việc moi móc thông tin sai lệch, không chính xác sẽ dẫn đến nguy cơ dự án bị thất bại và phải huỷ bỏ.

Các kỹ thuật để có thể moi móc được thông tin của khách hàng bao gồm: brainstorming, phân tích tài liệu đang được sử dụng bởi khách hàng, phỏng vấn, khảo sát, workshop,… Đặc biệt cần kết hợp sử dụng hai hoặc nhiều kỹ thuật với nhau để lấy được thông tin đầy đủ và hữu ích nhất từ phía người dùng.

16/05/2022

[S-WORD] STAKEHOLDER

Stakeholder là thuật ngữ ám chỉ những cá nhân hay nhóm người, tổ chức có quan hệ mật thiết với doanh nghiệp.

Stakeholder có thể là những người thuộc doanh nghiệp nhưng cũng có thể là người ngoài. Họ được chia sẻ về nguồn lực, có thể tác động hay chịu tác động một cách trực tiếp hoặc gián tiếp tới doanh nghiệp trong các vấn đề về chiến lược, kế hoạch, hoạt động kinh doanh,…

Các stakeholder tham gia vào việc xây dựng và phát triển dự án với các hoạt động:
▫ Quản lý sự phát triển của dự án
▫ Làm chủ dự án
▫ Tham gia vào quá trình phát triển của sản phẩm
▫ Làm việc với sản phẩm
▫ Trực tiếp hoặc gián tiếp liên quan đến các quy tắc và quy định của việc sử dụng sản phẩm
▫ Chịu ảnh hưởng bởi sự phát triển sản phẩm.

Trong một dự án, quyền hạn của stakeholders được chia làm 04 mức độ:
🔸 Players: những người liên quan tới dự án và có nhiều quyền hạn.
🔸 Subjects: những người liên quan tới dự án nhưng chỉ có quyền hạn thấp
🔸 Context Setters: những người ít liên quan đến dự án nhưng có quyền hạn cao
🔸 Crowd: những người không liên quan nhiều đến dự án đồng thời cũng không có nhiều quyền hạn trong dự án.

Bằng cách này, các stakeholder có trách nhiệm trong dự án có thể được cấp quyền và quản lý dễ dàng. Từ đó, BA có thể áp dụng ma trận phân nhiệm RACI nhằm tìm đúng người, đúng vai trò để làm việc

Mọi người thường hay nhầm lẫn giữa shareholders và stakeholders, trong khi shareholder hay cổ đông là người nắm cổ phần của công ty, thường quan tâm tới lợi nhuận của doanh nghiệp và việc cổ phiếu tăng giảm để có thể kiếm lợi thì stakeholder sẽ quan tâm sâu sắc tới các hoạt động của doanh nghiệp và sự thành công ngay cả không sở hữu cổ phần.

12/05/2022

[S-WORD] BRD - BUSINESS REQUIREMENT DOCUMENT

BRD thường được mô tả là là tập hợp các mong muốn của doanh nghiệp gồm có yêu cầu nghiệp vụ và yêu cầu của các bên liên quan.

BRD được phát triển dựa trên nền tảng là Business Requirement, những yêu cầu ở tầng cao nhất của doanh nghiệp nên sẽ xuất hiện đầu tiên trong các quy trình phát triển của tổ chức. Nó mô tả chiến lược mà công ty đang nỗ lực để đạt được trong tương lai.

BRD chính là câu trả lời cho câu hỏi “Tại sao có các yêu cầu?”; “Kết quả mong đợi – sự thay đổi từ hệ thống là gì?”. Ngoài ra BRD chính là công cụ để Business Analyst có thể sử dụng trong trao đổi với các stakeholder có liên quan trực tiếp tới các vấn đề chiến lược hoạt động của doanh nghiệp.

09/05/2022

[S-WORD] BUSINESS REQUIREMENT

Theo BABOK: “Business Requirement is statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.”

Business Requirement là các yêu cầu ở tầng cao nhất và phổ quát nhất, mô tả nhu cầu và đưa ra các lý do về sự cần thiết thay đổi. Các Business Requirement được xây dựng phục vụ cho chiến lược của doanh nghiệp và là cơ sở cốt lõi để phát triển thành các tầng yêu cầu tiếp theo. Các đặc điểm dấu hiệu của Business Requirement:
🔸 Thường là các mục tiêu dài hạn của tổ chức
🔸 Được áp dụng cho toàn tổ chức
🔸 Được đưa ra bởi các nhà lãnh đạo thuộc hàng C-Level, Director hoặc các Manager,…

Sản phẩm đầu ra của Business Requirement sẽ dưới dạng các loại tài liệu: Business Requirement Document - BRD, Product Vision, Business Case, thường trong các dự án đi theo mô hình Waterfall. Còn trong dự án phát triển theo Agile/Scrum đó có thể là Epic, Feature hay Scope Document.

05/05/2022

SỰ KHÁC BIỆT GIỮA BUSINESS ANALYST & DATA ANALYST

Data Analyst và Business Analyst là hai nghề có sự tương đồng trong cái tên khiến cho nhiều người nhầm tưởng rằng chúng tương tự và giống nhau. Tuy nhiên trên thực tế thì Data Analyst và Business Analyst hoàn toàn khác nhau từ khái niệm đến công việData Analyst và Business Analyst là hai nghề có sự tương đồng trong cái tên khiến cho nhiều người nhầm tưởng rằng chúng tương tự và giống nhau. Tuy nhiên trên thực tế thì Data Analyst và Business Analyst hoàn toàn khác nhau từ khái niệm đến công việc.

⭐️ Data Analyst (chuyên viên phân tích dữ liệu) là người có trách nhiệm thực hiện các phân tích sâu về dữ liệu ở nhiều dạng như đồ thị, biểu đồ, sơ đồ, báo cáo và bảng biểu. Sau khi phân tích sẽ sử dụng những dữ liệu đó để xác định xu hướng và tạo lên mô hình dự đoán những gì có thể xảy ra ở trong tương lai.

⭐️ Business Analyst (chuyên viên phân tích nghiệp vụ) là người đứng giữa, kết nối khách hàng với bên kinh doanh và đội kỹ thuật của doanh nghiệp.

Không chỉ khái niệm, mà trong công việc 2 ngành nghề này vẫn có nhiều điểm khác nhau, có thể kể đến như:

🔸Về kĩ năng

Business Analyst đòi hỏi các kiến thức khoa học dữ liệu, kỹ năng giao tiếp, phân tích và giải quyết vấn đề, kĩ năng đàm phán cũng như khả năng quản lý. Trong khi đó, Data Analyst cũng sẽ cần những kĩ năng gần như tương tự như vậy nhưng thiên về các con số, kỹ thuật cũng như khả năng phân tích dữ liệu.

🔸Về vai trò

Business Analyst cung cấp các đặc tả chức năng thiết lập nền tảng của thiết kế hệ thống công nghệ. Trong khi đó Data Analyst sẽ dành phần lớn thời gian để nghiên cứu dữ liệu và tạo báo cáo hiển thị thông tin chi tiết, từ đó trích xuất ra được ý nghĩa của dữ liệu.

🔸Về mục tiêu trọng tâm

Business Analyst coi cả hai loại dữ liệu bao gồm dữ liệu thu thập và dữ liệu phân tích là nền móng với trọng tâm cuối cùng là làm hài lòng khách hàng. Trong khi đó, Data Analyst làm việc trực tiếp với dữ liệu, lấy dữ liệu làm trung tâm và coi dữ liệu là nguồn tham khảo chính.

Trên đây là những điểm khác nhau cơ bản giữa Business Analyst với Data Analyst. Mong rằng thông qua bài viết này các bạn sẽ có cái nhìn chính xác hơn về sự khác biệt của hai ngành nghề này.

04/05/2022

Không ngờ tới phải không?

30/04/2022

Xin chúc tất cả mọi người có một kỳ nghỉ lễ 30/4 - 1/5 vui vẻ, ấm áp bên gia đình, bạn bè và người thân.

Mừng đại lễ 30/4 - 1/5, Symper xin kính chúc Quý Khách hàng, Quý Đối tác một kỳ nghỉ lễ thảnh thơi, thư thái, có nhiều niềm vui và những giây phút ý nghĩa bên người thân, bạn bè.

_______________
On the occasion of the Reunification Day 30/4 and International Labor Day 1/5, Symper would like to wish Our Customer and Partner a happy, relaxing and meaningful holiday season with relatives and friends.

27/04/2022

🤔🤔🤔

22/04/2022

Có còn hơn không!!!

16/04/2022

Tiếp tục với nội dung trong bài viết trước, bài viết này sẽ giúp định hình rõ hơn về ba vai trò còn lại trong 6 vị trí quan trọng thường thấy trong một dự án phần mềm: Project Manager - Quality Assurance - UI/UX Designer

🔸 Project Manager (PM)

Với cương vị là quản lý của toàn bộ dự án, Project Manager có vai trò lên kế hoạch và luôn phải đảm bảo tiến độ cũng như kết quả của việc thực hiện dự án vẫn đang theo đúng kế hoạch.

Project Manager là người đưa ra các quyết định trong dự án đồng thời thống nhất được kết quả input và output của các vị trí khác, đặc biệt chính là việc đảm bảo BA và DEV có thể thống nhất giữa yêu cầu của khách hàng và sản phẩm. Như vậy, Project Manager luôn cần tham gia vào tất cả các khâu của quy trình phát triển phần mềm và quản lý được tất cả các vấn đề xung quanh dự án.

🔸 Quality Assurance (QA)

Nhiều người hay bị nhầm lẫn giữa công việc QA và QC, tuy nhiên khác với công việc QC về kiểm tra xung quanh sản phẩm nhằm đảm bảo chất lượng, QA lại là công việc đề xuất, đưa ra quy trình làm việc giữa các bên, đưa ra các tài liệu nhằm đảm bảo chất lượng sản phẩm.

Hiện nay tại một số dự án vừa và nhỏ, công việc QA có thể được giao trực tiếp cho QC hoặc được đảm nhiệm bởi chính Project Manager.

🔸 UX/UI Designer

UX Designer đảm nhiệm vai trò xây dựng các trải nghiệm dành cho người dùng sản phẩm còn UI Designer chính là người thiết kế các giao diện phần mềm hiển thị cho người sử dụng. Đây chính là các công việc nằm trong bước thứ hai của quy trình phát triển phần mềm, khâu thiết kế.

Các sản phẩm đầu ra của UX/UI Designer chính là cơ sở để đội ngũ Developer có thể lập trình ra sản phẩm với đầy đủ các tính năng và hiển thị.

👉 6 vai trò đã được đề cập đều đóng góp những giá trị riêng cho dự án, không cái nào có thể thay thế cái nào. Tùy theo tính chất và quy mô dự án, nhiều vai trò hoàn toàn có thể được giao trách nhiệm thực hiện bởi chỉ một người và cũng có những vai trò khác phát sinh nằm ngoài những cái đã được đề cập.

Tuy nhiên, có đầy đủ các vị trí, vai trò chỉ là điều kiện cần, điều kiện đủ lại chính là sự phối hợp ăn ý trong công việc các thành viên trong dự án. Chỉ có như vậy, dự án mới có thể đạt đến mục tiêu chung nhất là sự thành công.

12/04/2022

Như đã đề cập trong bài viết về Quy trình phát triển phần mềm, việc xây dựng phần mềm thường được trải qua 5 bước Yêu cầu - Thiết kế - Lập trình - Kiểm thử - Triển khai. Quy trình này yêu cầu sự tham gia của tất cả các bộ phận trong dự án phần mềm, và thường được chia thành 6 vai trò cụ thể.

Bài viết này sẽ giới thiệu 3 vai trò thường hay được nhắc đến nhất trong mỗi dự án, chính là Developer - Business Analyst - Tester/Quality Control

🔸 Developer (DEV)

Developer có thể hiểu theo nghĩa rộng là người phát triển và trong trường hợp này chính là để chỉ đội ngũ lập trình phát triển sản phẩm.

Đội ngũ developer sẽ tham gia bắt đầu từ bước thứ hai, thiết kế sản phẩm, để đưa ra những ý kiến nhằm thể thực tiễn hóa các yêu cầu về sản phẩm và đóng vai trò chủ đạo trong bước lập trình sản phẩm. Ở các bước sau đó, đội ngũ developer có nhiệm vụ sửa những lỗi phát sinh từ khâu kiểm thử và bổ sung thêm những tính năng còn thiếu hoặc cần thêm mới cho phù hợp.

🔸 Business Analyst (BA)

Chuyên viên phân tích nghiệp vụ đóng vai trò là người xây dựng toàn bộ đầu vào cho quy trình phát triển sản phẩm. Đội ngũ BA trong mỗi dự án cần lắng nghe những nhu cầu, yêu cầu từ phía khách hàng, từ đó tìm kiếm và nghiên cứu ra giải pháp.

Các giải pháp được đề xuất chính là đầu vào của tất cả các khâu phía sau và là đầu vào trực tiếp của khâu thiết kế và lập trình sản phẩm.

🔸 Tester/ Quality Control (QC)

Vai trò Tester - Kiểm thử và Quality Control - Kiểm soát chất lượng có thể được hiểu là hai công việc khác nhau. Trong đó, việc kiểm thử là chính là bước liền kề ngay sau bước lập trình, lấy input là sản phẩm lập trình của DEV nhằm kiểm tra được xem liệu sản phẩm có hoạt động đúng, không có lỗi .

Còn kiểm soát chất lượng là công việc cần thực hiện ngay từ khi bắt đầu triển khai xây dựng sản phẩm và kéo dài đến cuối nhằm đảm bảo sản phẩm luôn đạt được đúng những tiêu chuẩn đã đề ra ban đầu và không đi lệch hướng, lệch yêu cầu của khách hàng.

Công việc QC và Testing có những hoạt động riêng biệt nhưng cũng có nhiều giao thoa nên trong đa số các dự án, cả hai công việc đều được thực hiện bởi một vai trò và thường được gọi đồng thời bằng cả hai cái tên QC hoặc Tester tùy theo công việc phát sinh.

👉 Tại bài viết tiếp theo, Symper - Trang thông tin về Business Analyst sẽ tiếp tục làm rõ ba vai trò quan trọng còn lại trong một dự án: Project Manager - Quality Assurance - UI/UX Designer