Software Architect: Các bên liên quan (Stakeholder)

Trong bài viết này, chúng ta sẽ tiếp tục tìm hiểu về các bên liên quan (Stakeholder) trong loạt bài viết về Kiến trúc phần mềm (Software Architect).

Lần này chúng ta sẽ nói về mục đích của việc phát triển các dự án, xây dựng các giải pháp kiến ​​trúc và lập trình các thuật toán. Chúng ta sẽ nói về những người thực hiện các công việc này và những người có thể ảnh hưởng đến dự án.

Loạt bài viết về Software Architect

  1. Con đường trở thành kiến ​​trúc sư phần mềm.
  2. Các bên liên quan (Stakeholder) (bài viết này).
  3. Phân loại Software Architect.
  4. Các thuộc tính chất lượng trong Software Architecture.
  5. Tài liệu về Software Architecture.
  6. Chứng chỉ về Software Architecture.
  7. Sách về Software Architecture.
  8. Cheatsheet thiết kế hệ thống.

Các bên liên quan (Stakeholder) là ai?

Luôn có nhiều bên liên quan đến dự án hơn bạn biết; và các bên liên quan đã biết có ít nhất một nhu cầu hơn những gì bạn biết bây giờ. (Tom Gilb)

Bên liên quan (Stakeholder) là một cá nhân hoặc tổ chức có quyền, cổ phần, yêu cầu hoặc lợi ích liên quan đến dự án hoặc các tài sản của dự án đáp ứng nhu cầu và mong đợi của họ.

Nói một cách đơn giản hơn, lợi ích của các bên liên quan có ảnh hưởng nhất định đến dự án, vì vậy ý ​​kiến ​​của họ luôn phải được xem xét. Nếu bạn không làm điều này và bỏ qua một trong những bên liên quan quan trọng, bạn có thể làm hỏng toàn bộ dự án và sẽ tốn kém hơn nhiều so với việc chỉ để một vài lỗi phát sinh trong dự án. Các bên liên quan cung cấp các cơ hội và hạn chế cho hệ thống và là nguồn gốc của các yêu cầu.

Điểm thú vị là thông thường, các bên liên quan không được xác định trước giai đoạn ra quyết định. Nhưng ngay sau khi quyết định được thiết kế, công bố hoặc thực hiện, mọi người bị ảnh hưởng bởi quyết định này sẽ bày tỏ ý kiến ​​của mình. Để cứu dự án khỏi tác hại tiềm tàng, trước tiên bạn nên trả lời các câu hỏi tại sao và cho ai, sau đó chỉ trả lời như thế nào.

Phân loại các bên liên quan

Dự án thường được tạo cho ai? Một câu trả lời thỏa đáng sẽ là - cho người dùng cuối. Người dùng cuối cũng là các bên liên quan trong dự án, tuy nhiên, họ có thể không quan trọng. Do đó, trong phát triển phần mềm, không nên tập trung vào người dùng cuối mà hoàn toàn tập trung vào các bên liên quan.

Không thể liệt kê một danh sách đầy đủ các loại bên liên quan vì đối với các hệ thống khác nhau, chúng có thể khác nhau đáng kể.

Hãy làm nổi bật các bên liên quan sau đây là phổ biến nhất. Ngoài ra, hãy xem xét từng loại về hậu quả khi bỏ qua lợi ích của họ:

Những người tham gia vào dự án và thực hiện nó

  • Nhóm dự án. Hãy tưởng tượng rằng bạn đã phát triển một giải pháp sử dụng ngăn xếp công nghệ .NET. Nhưng có một vấn đề. Bạn có hai mươi nhà phát triển Java có sẵn trong công ty và không ai biết .NET. Tôi cho rằng sau khi bạn nhớ điều này, sẽ không cần phải giải thích tại sao giải pháp được thiết kế là một thảm họa. Và đây là ví dụ đơn giản nhất. Bạn cần biết nhóm để hiểu những công nghệ nào họ biết rõ và những công nghệ nào trong số chúng không nên được sử dụng chỉ vì chúng đang là xu hướng.
  • Đội ngũ quản lý. Giả sử bạn quên hỏi người quản lý dự án của mình về điều gì đó quan trọng trước khi đưa ra quyết định. Nhưng họ sẽ bảo vệ bạn và làm như vậy để giải pháp đã thiết kế đạt được kết quả cuối cùng. Hơn nữa, thông thường, một người quản lý dự án có nhiều thông tin hơn và việc lắng nghe ý kiến ​​của họ là rất hữu ích.
  • Các công ty bên thứ ba. Có thể có nhiều vấn đề khác nhau, từ sự phức tạp khi tích hợp đến việc không thể sử dụng các giải pháp của bên thứ ba.
  • Đội ngũ hỗ trợ. Một tổ chức hoặc một người hỗ trợ hệ thống ở một hoặc nhiều giai đoạn trong vòng đời của nó. Giả sử một kiến ​​trúc sư đã quên đưa ra một hệ thống hỗ trợ. Nó đặt ra những câu hỏi như “Việc thiết kế hệ thống này chỉ là một sở thích, và chúng tôi hỗ trợ nó như thế nào?”.

Những người bị ảnh hưởng bởi dự án và những người sẽ sử dụng các thành phần của dự án

  • Khách hàng. Khách hàng là một trong những bên liên quan chính. Nếu bạn là một kiến ​​trúc sư, thì chỉ có một câu hỏi. Sao bạn có thể quên thảo luận về quyết định của mình với những người trả tiền cho việc phát triển dự án? Tôi sẽ tự trả lời. Dễ thôi. Trong thực tế của tôi, có một ví dụ khi một giải pháp kỹ thuật tuyệt vời để xử lý và đồng bộ hóa dữ liệu thời gian thực được tạo ra. Quyết định này là một trong những quyết định tiên tiến nhất trên thị trường, có tính đến các xu hướng công nghệ mới nhất. Hơn nữa, nó đã được thiết kế thành thạo, thử nghiệm chính xác và hiển thị cho khách hàng. Và sau đó hóa ra là khách hàng muốn một cái gì đó khác biệt. Chính xác hơn là một giải pháp hoàn toàn khác. Và họ hoàn toàn không cần siêu đồng bộ hóa.
  • Thủ trưởng và nhân viên các đơn vị chức năng. Họ hiếm khi gặp trong thực tế, nhưng họ là một trong những bên liên quan khắt khe nhất. Nếu bạn quên họ, thì hãy chuẩn bị tinh thần để họ chọc gậy vào bánh xe của bạn. Ví dụ, bạn đang thiết kế một hệ thống kế toán có ảnh hưởng đến hai bộ phận. Mỗi bộ phận có một trưởng phòng và 15 nhân viên. Hệ thống được thiết kế tối ưu hóa hơn nữa công việc của một trong các bộ phận và cho phép họ giải phóng 12 trên 15 người. Đồng thời, người quản lý rất tham lam quyền lực và bị sốc rằng, do các chức năng bổ sung mà bạn đã phát triển, họ sẽ chỉ có ba nhân viên. Do đó, họ cố gắng tìm kiếm những sai sót trong hệ thống, viết một số lượng lớn email cho tất cả những người chủ chốt trong dự án và đình trệ quá trình với mong muốn chức năng này bị loại bỏ.
  • Người dùng cuối. Cuối cùng chúng tôi đã đến được với họ. Tôi hy vọng họ luôn có ảnh hưởng quan trọng đến dự án, nhưng trên thực tế, điều này không đúng.

Những người không tham gia vào dự án, nhưng vì vị trí hoặc hoạt động của họ có thể ảnh hưởng đến dự án

  • Các nhà quản lý hàng đầu của công ty. Lợi nhuận, thành công và vị thế của công ty cũng như sự thành công của các dự án là điều cần thiết đối với họ. Chúng ta nên cố gắng tính đến điều này.
  • Chủ sở hữu của công ty. Họ rất khó chịu khi nghe những từ “dự án” và “rủi ro” trong một tuyên bố. Cố gắng giảm thiểu chúng khi thiết kế dự án của bạn.
  • Cổ đông và chủ nợ. Lợi nhuận của công ty là đáng kể đối với các bên liên quan này. Hơn nữa, họ muốn có được nó càng sớm càng tốt và ổn định. Thiết kế một giải pháp sẽ được thực hiện trong 5 năm, mặc dù bạn có thể chia nó thành nhiều phần và bắt đầu kiếm tiền vào ngày mai là một sai lầm có thể khiến bạn phải trả giá bằng cả sự nghiệp của mình.
  • Cơ cấu điều tiết. Bạn đã thiết kế một hệ thống không đáp ứng với một số tiêu chuẩn và hướng dẫn, và sau đó giải pháp của bạn bị cấm trên AppStore? Nó là bất cứ điều gì ngoại trừ giải pháp đúng.

Ngoài ra, cần đặc biệt chú ý đến thực tế là các bên liên quan không chỉ có thái độ tích cực đối với dự án mà còn có thái độ tiêu cực. Do đó, chúng tôi sẽ xem xét cách xác định các bên liên quan cho một dự án cụ thể.

Lý thuyết về quản lý các bên liên quan

Lý thuyết về quản lý các bên liên quan lần đầu tiên được Edward Freeman trình bày chi tiết trong cuốn sách “Quản lý chiến lược: Phương pháp tiếp cận các bên liên quan”.

Nó chỉ ra rằng việc hiểu và xác định các nhóm người có thể ảnh hưởng đến một doanh nghiệp hoặc một dự án cụ thể giúp bạn có thể cấu trúc và tối ưu hóa quy trình quản lý.

Và mặc dù quá trình này liên quan nhiều hơn đến lĩnh vực quản lý, nhưng đừng quên rằng chúng ta không chỉ là lập trình viên, mà còn là kiến ​​trúc sư, và điều này cũng áp dụng cho chúng ta.

Trong khái niệm của mình, Edward Freeman đã chia quá trình phân tích và quản lý các bên liên quan thành sáu giai đoạn:

Lý thuyết về quản lý các bên liên quan

Hãy xem xét các giai đoạn này chi tiết hơn.

Xác định tất cả các bên liên quan

Vì các bên liên quan ảnh hưởng đến dự án, tất cả các bên liên quan cần được xác định và nghiên cứu nghiêm ngặt trước khi bắt đầu thiết kế. Nó có thể được thực hiện bởi một nhà phân tích kinh doanh (Business Analyst) hoặc một kiến ​​trúc sư phần mềm (Software Architect). Thông tin về các bên liên quan nên được người quản lý dự án sử dụng ở giai đoạn phân tích nghiệp vụ, trong quá trình tạo kiến ​​trúc và cả khi thực hiện giải pháp đã thiết kế.

Điều rất quan trọng không chỉ là xác định các bên liên quan mà còn phải tìm cách tác động đến họ để sau này dễ dàng thống nhất các vấn đề khác nhau.

Truyền thông là công cụ chính được sử dụng để tác động đến các bên liên quan. Nó phải luôn được sử dụng đầu tiên. Đặc biệt, nó cho phép bạn xác định động cơ hành động của họ theo một cách nhất định.

Để giao tiếp hiệu quả với các bên liên quan, bạn cần biết rõ về họ. Không có điều đó, không thể làm việc hiệu quả.

Bất kỳ phân tích bên liên quan nào cũng bắt đầu bằng việc xác định tất cả các bên liên quan của dự án. Sẽ rất hữu ích nếu sử dụng kỹ thuật động não. Các câu hỏi sau có thể giúp xác định các bên liên quan:

  • Những hành động nào có thể dẫn đến việc không đạt được các mục tiêu của dự án?
  • Ai quan tâm nhất đến việc phát triển dự án này?
  • Có dự án như thế này trước đây không? Nếu có, nó đã thành công?
  • Có cần thiết cho tất cả các phòng ban tham gia vào dự án này không?
  • Những vấn đề nào cần giải quyết trong quá trình thực hiện dự án?
  • Ai biết dữ liệu này tốt hơn những người khác và có thể thiết kế nó một cách độc lập?

Phân tích các bên liên quan cho phép:

  • Xác định lợi ích của các bên liên quan có thể ảnh hưởng đến dự án.
  • Xác định những khó khăn tiềm ẩn có thể làm gián đoạn dự án hoặc làm giảm sự thành công của dự án.
  • Xác định những người chủ chốt cần được thông báo về tiến độ dự án.
  • Xác định các nhóm người cần tham gia ở mỗi giai đoạn của dự án.
  • Đánh giá các phương tiện, quy tắc và nguyên tắc giao tiếp trong suốt dự án.
  • Lập kế hoạch hành động để giảm tác động tiêu cực của các bên liên quan đến quá trình của dự án.

Hãy nhớ rằng giải pháp kiến ​​trúc được thiết kế phải vượt qua nhiều giai đoạn làm việc với các bên liên quan để được công nhận là thành công.

Theo các đề xuất của Object Management Group, chúng tôi có thể phân biệt sáu trạng thái dự án về tính toán, liên quan và thỏa mãn các bên liên quan:

  • Được công nhận - các bên liên quan được xác định.
  • Được đại diện - các phương pháp thu hút các bên liên quan được thỏa thuận và đại diện từ mỗi nhóm bên liên quan được chỉ định.
  • Tham gia - đại diện của các nhóm bên liên quan tham gia tích cực vào dự án và hoàn thành nhiệm vụ của họ.
  • Đồng ý - đại diện của các bên liên quan đều đồng ý.
  • Hài lòng để triển khai - đạt được những kỳ vọng tối thiểu của đại diện các bên liên quan.
  • Hài lòng khi sử dụng - hệ thống đáp ứng hoặc vượt quá mong đợi tối thiểu của các bên liên quan.

Xác định các yêu cầu với sự trợ giúp của các bên liên quan

Sau khi xác định danh sách các bên liên quan, cần hiểu rõ vị trí của họ. Tầm quan trọng và ảnh hưởng của họ cho phép chúng tôi xác định các yêu cầu chính và loại trừ những yêu cầu không cần thiết.

Để làm điều này, bạn có thể sử dụng chiến lược quản lý các bên liên quan sau đây, thường được sử dụng trong quản lý dự án:

Xác định tất cả các bên liên quan

Biểu đồ các bên liên quan là một biểu đồ hai trục với các trục ảnh hưởng và tầm quan trọng:

  • Ảnh hưởng là quyền lực của các bên liên quan trong quản lý dự án. Quyền lực của các bên liên quan trong việc ảnh hưởng đến mức đầu tư của dự án, tham gia vào việc lập ngân sách dự án và có tác động đến những người đưa ra quyết định về các vấn đề quan trọng trong dự án.
  • Tầm quan trọng là sự đóng góp của các bên liên quan vào kết quả dự án. Nó được xác định bởi việc thỏa mãn nhu cầu, giải quyết các vấn đề và lợi ích của mỗi bên liên quan có thể ảnh hưởng đến kết quả dự án như thế nào. Ví dụ, tầm quan trọng là kiến ​​thức hoặc kỹ năng đặc biệt của bên liên quan, cũng như các nhu cầu phải được đáp ứng để dự án trở nên thành công.

Biểu đồ được chia thành bốn nhóm, đó là các nhóm bên liên quan. Các phương pháp làm việc khác nhau được áp dụng cho mỗi nhóm:

  • Nhóm đầu tiên là Ảnh hưởng cao, tầm quan trọng cao - Quan hệ tốt. Cần thiết lập quan hệ làm việc chặt chẽ với các bên liên quan này vì đối với họ, dự án là rất cần thiết. Họ tham gia vào việc thực hiện và ảnh hưởng tích cực đến quá trình và kết quả.
  • Nhóm thứ hai là Ảnh hưởng cao, tầm quan trọng thấp - Giám sát. Các bên liên quan này có quyền thực hiện dự án nhưng không quá quan tâm đến nó. Với sự kết hợp của các yếu tố này, chúng có thể trở thành nguồn rủi ro, vì vậy cần phải theo dõi và quản lý cẩn thận.
  • Nhóm thứ ba là Ảnh hưởng thấp, tầm quan trọng cao - Bảo vệ. Họ yêu cầu các sáng kiến ​​đặc biệt để bảo vệ lợi ích của mình vì dự án khá quan trọng đối với họ, nhưng tác động của họ đến việc thực hiện nó là không đáng kể (hoặc họ không thể ảnh hưởng).
  • Nhóm thứ tư là Ảnh hưởng thấp, tầm quan trọng thấp - Mức độ ưu tiên thấp. Nhóm các bên liên quan này có tham gia và tương đối quan tâm, nhưng không quá nhiều. Do đó, từ góc độ phân bổ sự chú ý, nhóm này có mức độ ưu tiên thấp.

Áp dụng kiến ​​thức của các bên liên quan

Khi danh sách các bên liên quan được hình thành, bản đồ tầm quan trọng ảnh hưởng được vẽ, danh sách các yêu cầu được tạo và được các bên liên quan chính phê duyệt, bạn có thể bắt đầu thiết kế dự án.

Hơn nữa, người quản lý dự án nên làm việc với các bên liên quan chính và đồng hành với họ trong suốt vòng đời của dự án. Người quản lý dự án phải đảm bảo rằng các yêu cầu của các bên liên quan được áp dụng trong quá trình phát triển. Trong trường hợp có những thay đổi đột ngột trong các yêu cầu hoặc bản thân các bên liên quan, người quản lý phải thông báo cho kiến ​​trúc sư, người sẽ phản ứng với những thay đổi này.

Điều quan trọng cần nhớ là nếu kiến ​​trúc sư không đề xuất thuật toán tối ưu nhất, điều này có thể dẫn đến việc dự án trở nên đắt hơn với những hệ quả khác nhau. Nếu kiến ​​trúc sư không xác định được một trong những bên liên quan chính, nó có thể phải trả giá bằng sự nghiệp của mình.

Career PathSoftware ArchitectureProject ManagementBusiness AnalysisArchitecture
Bài Viết Liên Quan:
Software Architect: các loại Software Architect
Trung Nguyen 08/01/2021
Software Architect: các loại Software Architect

Software Architect - bài viết này sẽ giúp bạn tìm hiểu có những loại kiến trúc sư nào? Vai trò của họ là gì?

Software Architect: Con đường trở thành một Software Architect
Trung Nguyen 01/01/2021
Software Architect: Con đường trở thành một Software Architect

Kiến trúc sư phần mềm (software architect) là ai? Vai trò và trách nhiệm của software architect là gì? Làm sao để trở thành một software architect.