Phương pháp thiết kế cơ cấu tổ chức doanh nghiệp

Cơ cấu tổ chức Team Agile

Chúng ta đã quen thuộc với khái niệm xây dựng cơ cấu tổ chức thành các Team Agile độc lập, tự chủ thay vì cơ cấu tổ chức phân cấp truyền thống. Ví dụ như mô hình tổ chức của Spotify  đã trở thành ví dụ mẫu. Hoặc, cơ cấu tổ chức Scrum với các role developer + scrum master + product owner và cross function cũng đã được rất nhiều lý thuyết và thực hành mô tả.

Tuy nhiên, nền tảng lý thuyết nào làm cơ sở để thiết kế cơ cấu tổ chức cho một doanh nghiệp có nhiều team? Cuốn sách: Team Topologies, IT Revolution Press. Skelton, Matthew. đã mô tả phương pháp luận để có thể xây dựng cơ cấu tổ chức phù hợp cho toàn bộ tổ chức như vậy. Bài viết tóm tắt nhanh các luận điểm chính của tác giả.

Nguyên lý thiết kế cơ cấu tổ chức

Xuất phát từ luật Conway cho rằng chính cơ cấu tổ chức đã khiến cho không thể có được một thiết kế sản phẩm tốt.

[Conway’s law] creates an imperative to keep asking: “Is there a better design that is not available to us because of our organisation?” —Mel Conway, Toward Simplifying Application Development, in a Dozen Lessons.

Trong thời đại công nghệ thông tin, cấu trúc phần mềm/hệ thống thông tin của các doanh nghiệp ngày càng trở nên rắc rối khi mở rộng. Các rắc rối gồm xung đột giữa các thành phần, bộ phận cấu thành ngày càng phức tạp: chỗ thì quá phụ thuộc, chỗ thì rời rạc thiếu liên kết. Vậy theo Conway Law, nguyên nhân gốc rễ đến từ cơ cấu tổ chức của chính doanh nghiệp cũng rời rạc, phụ thuộc chồng chéo và xung đột lẫn nhau.

Ruth Malan đã phát biểu theo một cách khác, được coi là định luật Conway cho thời kỳ hiện đại:

Nếu kiến trúc của hệ thống và kiến trúc của tổ chức trái ngược nhau, thì kiến trúc của tổ chức sẽ thắng.

Điều này có ý nghĩa chiến lược quan trọng đối với bất kỳ tổ chức nào thiết kế và xây dựng hệ thống thông tin/phần mềm, cho dù trong nội bộ hay hay cho khách hàng.

Từ các định luật này, kết hợp cùng các nghiên cứu và khảo sát, tác giả đi đến khẳng định rằng: các doanh nghiệp nên nhìn nhận việc phát triển đội ngũ và cơ cấu tổ chức của mình chính là ánh xạ để đạt được kiến trúc phần mềm mong muốn. Mục tiêu cuối cùng là đạt được kiến trúc hệ thống phần mềm hỗ trợ khả năng hoàn thành công việc của các team - từ thiết kế đến triển khai - mà không yêu cầu băng thông giao tiếp quá cao giữa các team. Nói nôm na là: cơ cấu tổ chức thế nào, kiến trúc sản phẩm hệ thống/phần mềm cũng tương tự.

‍Các ví dụ áp dụng nguyên lý

Giả sử ta có 4 team A, B, C, D phát triển một hệ thống phần mềm. Trong mỗi team có Frontend Developer và Back Developer. Tuy nhiên có 1 team DBA đứng riêng rẽ và một team vận hành (Ops) đứng riêng. Kết quả doanh nghiệp sẽ có một hệ thống phần mềm với hệ quản trị cơ sở dữ liệu tập trung và 4 nhóm ứng dụng độc lập do 4 team lập ra. Các ứng dụng sẽ kết nối vào cơ sở dữ liệu tập trung do team DBA quản lý, kiểm soát và phân quyền.

Xét thêm một ví dụ khác nếu tổ chức thành các team với mục tiêu phát triển các Micro Service, chịu trách nhiệm với data source của chính họ. Doanh nghiệp sẽ có sản phẩm phần mềm với kiến trúc dạng các Micro Service.

Các loại team trong cơ cấu tổ chức

Để thuận tiện cho việc định hình các team, tác giả chỉ ra có 4 loại hình mẫu team, khi thiết kế cơ cấu tổ chức có thể cân nhắc áp dụng

Stream Aligned Team

“Stream” là luồng công việc liên tục phù hợp với lĩnh vực kinh doanh hoặc khả năng của tổ chức. Đây có thể là một sản phẩm hoặc dịch vụ, một tập hợp các tính năng, một hành trình của người dùng hoặc một cá nhân người dùng.

Stream là một loạt các công việc liên tục đòi hỏi sự rõ ràng về mục đích và trách nhiệm, trực tiếp tạo ra giá trị kinh doanh doanh nghiệp có thể tồn tại. Team phù hợp với Stream là Team được liên kết với một Stream công việc duy nhất, có giá trị. Không để 1 team ôm đồm nhiều Stream cùng lúc.

Mỗi team có quy trình công việc riêng, Team được trao quyền để xây dựng và cung cấp giá trị cho khách hàng một cách nhanh chóng, an toàn và độc lập nhất có thể. Team không bị bắt buộc phải giao cho các Team khác thực hiện các phần của công việc của mình.

Stream-Aligned Team này trực tiếp tạo ra Business Value, chuyển giao giá tị liên tục đến khách hàng, trực tiếp tiếp nhận các phản hồi từ khách hàng và cải tiến liên tục. Để thực hiện vai trò trách nhiệm này, Stream-Aligned là một team cross function, bao gồm các chức năng đầy đủ:

• Application security

• Commercial and operational viability analysis

• Design and architecture

• Development and coding

• Infrastructure and operability

• Metrics and monitoring

• Product management and ownership

• Testing and quality assurance

• User experience (UX)

Enabling Team

Các Stream Algned Team sẽ liên tục cải tiến về kỹ năng, quy trình, năng lực, nhờ đó mà hiệu suất và năng suất ngày càng tiến bộ và vượt trội. Nhưng thực tế với sự chạy đua theo Stream công việc trực tiếp tạo ra giá trị kinh doanh, các thành viên trong team thường đầu tắt mặt tối. Thời gian để có thể đầu tư vào học hỏi cải tiến, nâng cao kỹ năng và năng lực là khá hạn chế. Do đó vai trò của Enabling Team bao gồm các chuyên gia trong lĩnh vực nhất định có mục tiêu giúp thu hẹp khoảng cách về năng lực, chuyển giao năng lực cho Stream Aligned Team; từ đó nâng cao năng suất.

Enabling Team cần liên kết với các Stream Aligned Team, thực hành các nghiên cứu, thử các tùy chọn và đưa ra các đề xuất sáng suốt về công cụ, phương pháp ứng dụng. Điều này cho phép Stream Aligned Team có thời gian để phát triển các năng lực trong khi “đầu tắt mặt tối" mà không cần phải đầu tư nỗ lực nghiên cứu và tìm hiểu. Các ví dụ mà Enabling Team tác động đến Stream Aligned Team như: user experience, architecture, testing, engineering, continuous delivery, deployments, test automation.

Platform Team

Mục đích của Platform Team là tạo khả năng cho Stream Aligned Team thực hiện công việc tự chủ và tự động. Theo đó, Stream Aligned Team toàn quyền sở hữu đối với việc xây dựng, chạy và sửa ứng dụng của họ trong quá trình sản xuất. Còn Platform Team sẽ cung cấp các dịch vụ, công cụ nội bộ để giảm tải công việc cho các Stream Aligned Team team.

Định nghĩa về ”Platform” được Evan Bottcher đưa ra, là các API, thư viện lập trình, công cụ, dịch vụ, kiến thức và hỗ trợ được sắp xếp như một sản phẩm nội bộ. Các Stream Aligned Team có thể tận dụng Platform để cung cấp các tính năng của sản phẩm cho khách hàng với tốc độ phát triển cao hơn. Nhờ sử dụng Platform, Stream Aligned Team sẽ giảm thiểu sự phụ thuộc và ràng buộc cổ chai vào các team khác.

Cách tiếp cận này đã được áp dụng thành công trong nhiều tổ chức thời đại internet. Kiến thức của Platform Team được cung cấp tốt nhất thông qua khả năng tự phục vụ thông qua cổng web, API có thể lập trình thay cho các hướng dẫn sử dụng dài dòng. “Tính dễ sử dụng” là yếu tố cơ bản để áp dụng Platform, sản phẩm của Platform Team cần đáng tin cậy, có thể sử dụng và phù hợp với mục đích, bất kể chúng được khách hàng nội bộ hay bên ngoài sử dụng.

Trên thực tế, các Platform Team sẽ tập trung vào việc cung cấp một số lượng nhỏ các dịch vụ có chất lượng chấp nhận được thay vì một số lượng lớn các dịch vụ có nhiều vấn đề về chất lượng. Họ sẽ luôn phải cân bằng giữa nỗ lực đầu tư với chất lượng. Cũng như các sản phẩm thương mại, platform có thể cung cấp các mức cam kết dịch vụ khác nhau. Nếu tất cả các Stream Aligned Team đòi hỏi tất cả các dịch vụ đều ở mức cao cấp (ví dụ: không có thời gian ngừng hoạt động, tự động mở rộng quy mô, tự phục hồi trong trường hợp thất bại), thì Platform Team có thể sẽ không thể đáp ứng được nhu cầu với nguồn lực hạn chế hiện tại.

Một Platform tốt cung cấp các standard, sample, API và các phương pháp hay nhất đã được kiểm chứng rõ ràng cho các Stream Aligned Team sử dụng để đổi mới, cải tiến nhanh chóng và hiệu quả. Một Platform tốt sẽ giúp các Stream Aligned Team dễ dàng làm những việc phù hợp theo cách phù hợp với tổ chức. Điều này áp dụng cho tất cả các loại phát triển sản phẩm, không chỉ những loại liên quan đến phần mềm.

Theo cách cũ, Platform được các quản trị viên hệ thống xây dựng và chạy mà không sử dụng các kỹ thuật phát triển phần mềm được xác định rõ ràng (thực hành Agile, TDD, phân phối liên tục, quản lý sản phẩm, v.v.); hoặc nó nhận được quá ít sự đầu tư và sự quan tâm từ doanh nghiệp đến nỗi nó không bao giờ giúp được các team khác, thậm chí có thể cản trở họ.

Sub-System Team

Sub-System Team chịu trách nhiệm xây dựng và duy trì một phần của công việc trên Stream mà phụ thuộc nhiều vào kiến thức chuyên môn, đến mức hầu hết các thành viên trong nhóm phải là chuyên gia trong lĩnh vực kiến thức đó để có thể hiểu và thực hiện các thay đổi. Mục tiêu là giảm tải các yêu cầu và đỏi hỏi về năng lực, kỹ năng, kiến thức chuyên môn của Stream Algned Team khi không thể mong đợi có đủ các chuyên gia cần thiết tham gia đầy đủ như là thành viên của Stream Algned Team. Vì nếu Stream Algned Team nào cũng cần phải đủ chuyên sẽ không khả thi và có hiệu quả về chi phí.

Ví dụ các kiến thức như codec xử lý video, mô hình toán học, thuật toán thống kê theo thời gian thực, hệ thống báo cáo giao dịch cho các dịch vụ tài chính, công cụ nhận dạng khuôn mặt. Những kiến thức này chỉ có một số ít chuyên gia là am hiểu với chi phí lương rất cao. Như vậy nếu doanh nghiệp có nhiều Stream Aligned Team, thì không thể đòi hỏi trobg Team nào cũng phải có chuyên gia như vậy.

Điều gì được dùng để xác định nên để 1 phân đoạn vẫn thuộc về Stream Aligned Team hay tách riêng giao cho Sub-System Team. Căn cứ là dựa vào phải năng lực hiểu biết về kiến thức chuyên môn của team, không dựa trên tải trọng cơ học của công việc.

Mối quan hệ giữa các team

Trong mô tả cơ cấu tổ chức của doanh nghiệp, một thành phần hay bị bỏ qua là mô tả mối quan hệ qua lại giữa các team  1 team có thể sử dụng các dạng quan hệ khách nhau với team khác nhau, tùy thuộc đặc thù công việc, nhiệm vụ. Nhìn chung có 3 loại quan hệ:

• Collaboration: làm việc gần sát, trực tiếp phối hợp.
  
• Facilitating: làm việc bằng cách trợ giúp team khác hoặc được trợ giúp.
• X as Serviced: Tiêu thụ dịch vụ hoặc cung cấp dịch vụ tới team khác, tối thiểu hóa sự giao tiếp, cộng tác trực tiếp.

Ví dụ team A là 1 stream-aligned team, cung cấp phần mềm tài chính. Team A có thể sẽ phải cộng tác với team B khi team này cung cấp các tư vấn chuyên gia về các chỉ số tài chính và sử dụng dịch vụ của team C cung cấp platform, thư viện lập trình cho phần mềm tài chính của A.

Quan hệ Collaboration

Đối với mối quan hệ cộng tác, hai team phối hợp cùng nhau tạo ra giá trị.

Lợi điểm là tốc độ sáng tạo diễn ra nhanh, ít mất thời gian cho việc chuyển giao công việc giữa các team. Hạn chế của mô hình này chính bởi sự chia sẻ trách nhiệm giữa các team có thể dẫn đến nguy cơ không rõ ràng vai trò trách nhiệm khiến cho sự cộng tác làm giảm năng suất thay vì tăng năng suất như kỳ vọng. Một team nên sử dụng chế độ cộng tác với tối đa một team khác tại một thời điểm; không nên cộng tác với nhiều team cùng một lúc.

Quan hệ cộng tác này thường được áp dụng trong việc tương tác giữa Stream Aligned Team với Platform team,  giữa Stream Aligned Team với Sub System Team hoặc giữa Sub System Team với Platform team.

Quan hệ X-as-Service

X-as-a-Service phù hợp với các tình huống cần một hoặc nhiều nhóm sử dụng Platform như thư viện, API mà không cần nỗ lực nhiều cho việc giao tiếp giữa các nhóm. Trong đó thành phần của hệ thống được cung cấp như một dịch vụ để team khác sử dụng một cách hiệu quả, tự chủ. Quan hệ này nên được áp dụng đối với các công việc mà hoàn toàn có thể dự đoán được, các công việc với các quy trình rõ ràng.

Ưu điểm của quan hệ tương tác này là sự rõ ràng về vai trò trách nhiệm từ đó làm giảm việc giao tiếp quan lại không cần thiết giữa các team. Nguy cơ chính lại nằm trong tính chất rõ ràng trách nhiệm có thể kéo theo hạn chế về đổi mới sáng tạo khi các team tự trói buộc mình trong phạm vi đã được giao.

Quan hệ này thường áp dụng với quan hệ giữa Stream-aligned team và platform team, giữa sub-system team với platform team. Quan hệ này cũng được xem xét trong quan hệ giữa stream-aligned team với sub-system team xét trong bối cảnh sử dụng 1 thư viện, một thành phần độc lập do sub-system team cung cấp.

Quan hệ dạng Facilitating

Kiểu tương tác facillitating này phù hợp với các tình huống trong đó một hoặc nhiều team sẽ được hưởng lợi từ sự giúp đỡ, đào tạo, huấn luyện một số khía cạnh trong công việc của họ. Mục tiêu là giúp team hoạt động hiệu quả hơn, học hỏi nhanh hơn, hiểu công nghệ mới tốt hơn, đồng thời phát hiện và loại bỏ các vấn đề hoặc trở ngại chung giữa các team. Team đóng vai trò hỗ trợ cũng có thể giúp phát hiện ra những lỗ hổng hoặc mâu thuẫn trong các thành phần và dịch vụ hiện có được các team khác sử dụng. Các team tương tác bằng cách sử dụng facillitating thường làm việc với nhiều team khác, phát hiện và giảm các vấn đề giữa các team và giúp thông báo hướng và khả năng của những thứ như thư viện, API và platform được cung cấp dưới dạng dịch vụ bởi các team khác. Team sử dụng quan hệ facillitating đến các team khác sẽ không tham gia vào việc xây dựng hệ thống phần mềm chính, mà tập trung vào chất lượng tương tác giữa các team.

Ưu điểm của kiểu tương tác quan hệ này là giúp loại bỏ các rào cản thiếu đồng bộ giữa các team trong tổ chức. Nhược điểm là đòi hỏi thành viên của nhóm phải có kinh nghiệm dày dặn trong khi không trực tiếp tham gia xây dựng một phần nào của toàn bộ hệ thống phần mềm. Do không trực tiếp theo công việc, việc xây dựng quan hệ facillitating thường gặp rào cản bởi sự xa lạ giữa các nhóm khi tương tác với nhau.

Quan hệ này thường áp dụng giữa Enabling team trợ giúp các stream-aligned team, sub-system team hoặc platform team. Quan hệ này cũng được áp dụng trong giai đoạn ban đầu thành lập một stream-aligned team sẽ cần trợ giúp trong việc tiếp cận các kỹ năng, kiến thức mới chuyển giao từ các stream-aligned team, sub-system team hoặc platform team khác có liên quan công việc.

Lựa chọn xây dựng mối quan hệ

‍Tùy thuộc vào giai đoạn, vai trò, nhiệm vụ giữa hai team mà lựa chọn hình thức quan hệ tương tác phù hợp. Nhưng nhìn chung thì một team thường lựa chọn các hình thức quan hệ với team khác như bảng và hình dưới đây mô tả.

Kết luận

Các nguyên lý và phân loại trong Cuốn sách: Team Topologies, IT Revolution Press. Skelton, Matthew. đã đặt nền móng ban đầu cho phép các doanh nghiệp có thể thiết kế cơ cấu tổ chức của mình phù hợp với với sản phẩm, dịch vụ và chiến lược mục tiêu mà mình mong muốn. Đồng thời giúp mở rộng doanh nghiệp và có thể tìm kiếm và đáp ứng nhiều hơn các cơ hội kinh doanh.

Tuyển dụng Agile Coach. Working Remote làm việc bất cứ địa điểm nào bạn thích, Quản lý linh hoạt theo Agile