Việc hiểu lý do tại sao một số tính năng nhất định không được cung cấp thường có thể là một thách thức. Ban quản lý có thể đổ lỗi cho đội kỹ thuật, trong khi đội kỹ thuật chỉ trích ban quản lý. Trong khi đó, phía doanh nghiệp bị kẹt ở giữa, cố gắng xác định nguyên nhân gốc rễ đồng thời thúc đẩy kết quả bất kể hoàn cảnh nào. Tình huống này thường xảy ra sau khi công ty tăng trưởng đáng kể hoặc khi các vấn đề trước đó vốn dễ khắc phục đã bị bỏ qua theo thời gian. Có một quan niệm sai lầm phổ biến rằng mọi vấn đề trong một công ty công nghệ đều thuần túy là vấn đề kỹ thuật; Đây là xa sự thật.

Trong bài viết này, tôi sẽ phác thảo các lĩnh vực trong tổ chức của công ty có thể cản trở đáng kể việc cung cấp tính năng. Tôi cũng sẽ đề xuất hướng điều tra để xác định nguyên nhân cốt lõi, sau đó có thể chuyển lên cấp cao hơn hoặc giải quyết trong phạm vi quyền hạn của bạn.

Điều quan trọng là phải hiểu môi trường làm việc của chúng ta trước khi thực hiện bất kỳ thay đổi hoặc cải tiến nào. Mặc dù nhiều cuốn sách sâu sắc đã được viết về chủ đề này nhưng không phải tất cả các phương pháp tiếp cận đều phù hợp với mọi công ty. Đây không phải là sự phản ánh việc làm sai điều gì đó mà là sự thừa nhận về bản chất riêng của mỗi công ty.

Một lưu ý quan trọng là những hiểu biết sâu sắc được chia sẻ ở đây chủ yếu liên quan đến phát triển phần mềm và có thể áp dụng nhiều nhất cho các công ty hoặc bộ phận có từ 50 nhân viên trở lên.

Cơ cấu tổ chức

Đầu tiên và quan trọng nhất, hãy hiểu quy mô và cấu trúc của công ty bạn. Xác định các bộ phận khác nhau và làm rõ những mong đợi của bạn từ mỗi bộ phận. Đánh giá xem tất cả các bộ phận này có cần thiết hay không. Tạo sơ đồ cơ cấu tổ chức, nêu chi tiết từng bộ phận và vai trò của chúng, đảm bảo bạn hiểu rõ họ làm gì và tại sao họ tồn tại. Thông thường, mỗi bộ phận bao gồm một số nhóm — hãy đưa những nhóm này vào sơ đồ của bạn nhưng hiện tại không mô tả chúng mà chỉ giữ nguyên tên nhóm.

Khi các công ty phát triển, cơ cấu tổ chức có thể trở nên phức tạp, gây khó khăn cho việc theo dõi tiến độ. Trong sự phức tạp này, bạn có thể không hiểu được lý do ban đầu đằng sau việc thành lập các phòng ban hoặc nhóm nhất định. Một số nhóm có thể đã được thành lập để giải quyết các vấn đề không còn phù hợp nữa. Ở đây, nó có thể trông như thế nào ở cấp độ cao.

Khi bạn đã có sơ đồ rõ ràng về cơ cấu tổ chức của mình, điều gì sẽ xảy ra tiếp theo?

Hệ thống phân cấp nhân viên

Tiếp theo, điều cần thiết là phải vạch ra thứ bậc của nhân viên. Hiểu ai báo cáo cho ai và tại sao là rất quan trọng. Người quản lý tuyến cần giao tiếp hiệu quả với cấp dưới của mình, cho dù họ quản lý một đơn vị kinh doanh lớn hay một nhóm nhỏ. Giao tiếp phải rõ ràng, bằng ngôn ngữ kỹ thuật hoặc kinh doanh, vì việc xử lý cả hai ngôn ngữ này có thể là một thách thức. Ở các công ty lớn hơn, có thể có những người quản lý trực tiếp và chức năng với các lĩnh vực trách nhiệm riêng biệt, cần được thể hiện rõ ràng trong sơ đồ phân cấp của bạn.

Hệ thống phân cấp nhân viên không chỉ làm rõ các dòng báo cáo mà còn giúp xác định các ngành dọc trong tổ chức. Ngành dọc là các cấu trúc phân cấp đóng vai trò là tài nguyên được chia sẻ giữa nhiều bộ phận, chẳng hạn như nhà thiết kế, nhân sự, DevOps và thậm chí cả nhà phát triển. Mặc dù ngành dọc có thể rất có lợi nhưng đôi khi chúng có thể trở thành điểm nghẽn, đặc biệt khi các nhà phát triển làm việc trên các dự án khác nhau và báo cáo cho những người quản lý không quen với các mục tiêu kinh doanh hoặc thách thức kỹ thuật. Kết quả là, các nhà phát triển không nhận được phản hồi phù hợp, các nhà quản lý không có bối cảnh phù hợp. Do đó, hiểu được hệ thống phân cấp là rất quan trọng để xác định và phân tích các vấn đề tiềm ẩn hoặc mức độ ưu tiên của các nhiệm vụ. Cuối cùng bạn sẽ có một cái gì đó như thế này.

Chú thích

CEO – Giám đốc điều hành
CPO - Giám đốc sản phẩm
CTO - Giám đốc kỹ thuật
COO - Giám đốc điều hành
HD — Trưởng Phòng Thiết Kế
PO — Chủ sở hữu sản phẩm
HE - Trưởng phòng Kỹ thuật
HS — Trưởng phòng kinh doanh
HM — Trưởng phòng Tiếp thị
D - Nhà phát triển
PM - Giám đốc sản phẩm
TL — Trưởng nhóm công nghệ
EM - Giám đốc kỹ thuật
S - Giám đốc bán hàng
M - Nhà tiếp thị

So sánh cơ cấu tổ chức của bạn với các dòng báo cáo để hiểu rõ hơn về sự tham gia của từng nhân viên vào các hoạt động khác nhau. Hơn nữa, việc điều chỉnh cơ cấu tổ chức của bạn với hệ thống phân cấp nhân viên có thể giúp xác định xem các cá nhân có đang làm việc trong cùng một bộ phận và nhóm và hướng tới một mục tiêu chung hay không. Mẫu ánh xạ hoàn toàn tùy thuộc vào bạn nhưng nó có thể thích điều này.

Trách nhiệm của đội

Điều quan trọng là phải xác định rõ ràng lĩnh vực mà mỗi nhóm hoạt động. Nếu một nhóm làm việc với mã, hãy chỉ định các dịch vụ họ sử dụng và những dịch vụ họ sở hữu. Đáng ngạc nhiên là những điều này thường có thể khác nhau. Xác định xem nhóm chỉ hoạt động trong một bộ phận hay đó là nhóm nền tảng làm việc trên các tính năng cốt lõi được các nhóm khác sử dụng mà không trực tiếp thay đổi chúng.

Việc tạo một bảng có thể rất hữu ích với các cột sau: tên nhóm, bộ phận, danh sách các dịch vụ được sở hữu, danh sách các dịch vụ chung mà nhóm có thể sửa đổi nhưng không sở hữu (lý tưởng nhất là không nên có những dịch vụ như vậy) và một mô tả ngắn gọn . Bảng này sẽ giúp bạn kiểm tra xem liệu nhiều nhóm có đang làm việc trên cùng một cơ sở mã hay không, dẫn đến xung đột hoặc liệu có sự thiếu rõ ràng về lĩnh vực trách nhiệm của họ hay không. Nó cũng có thể tiết lộ liệu một nhóm có chủ yếu sửa lỗi hay thực hiện nhiều nhiệm vụ khác nhau mà không có sự tập trung rõ ràng hay không.

Mức độ chi tiết này rất quan trọng để xác định sự chồng chéo, xung đột và lỗ hổng trong trách nhiệm của nhóm, đảm bảo sự cộng tác suôn sẻ hơn và thực hiện dự án hiệu quả hơn.

Trách nhiệm của nhân viên

Ngoài việc mô tả các nhóm, điều quan trọng là phải hiểu vị trí của nhân viên nói chung và chuẩn bị mô tả chi tiết về trách nhiệm của họ. Thông thường, những gì ban quản lý hình dung có thể khác biệt đáng kể so với những gì nhân viên thực sự đang làm. Ngành phát triển phần mềm có nhiều vị trí khác nhau và kỳ vọng của mỗi công ty có thể khác nhau rất nhiều. Ví dụ: vai trò của Giám đốc kỹ thuật có thể rất khác nhau, chưa kể đến các vai trò như Người quản lý phân phối, Nhà khoa học dữ liệu, Kiến trúc sư, Trưởng nhóm kỹ thuật, v.v. Ở một số công ty, một người có thể phải đảm nhiệm nhiều vai trò.

Đặt kỳ vọng rõ ràng cho từng vị trí là điều cần thiết. Sự rõ ràng này không chỉ giúp theo dõi các hoạt động một cách chính xác mà còn đảm bảo rằng nhân viên hiểu những gì được mong đợi ở họ và những gì nằm ngoài phạm vi của họ. Điều này áp dụng cho tất cả các vị trí trong tổ chức. Xác định vai trò rõ ràng giúp ngăn chặn sự chồng chéo, giảm nhầm lẫn và đảm bảo rằng mọi người đều làm việc hướng tới các mục tiêu chung một cách hiệu quả và có tổ chức.

Quá trình cung cấp tính năng

Đến bây giờ, bạn nên hiểu rõ về cấu trúc công ty, hệ thống phân cấp nhân viên và trách nhiệm của họ. Mặc dù mọi thứ có vẻ khó hiểu nhưng mục tiêu trước tiên là hiểu trạng thái hiện tại trước khi thực hiện bất kỳ thay đổi nào. Bây giờ là lúc mô tả quy trình phân phối tính năng của bạn — cách các tính năng kinh doanh chuyển từ ý tưởng ban đầu sang sản xuất.

Vui lòng không tập trung ở đây vào các khía cạnh kỹ thuật như CI/CD mà vào quy trình từ doanh nghiệp đến nhà phát triển, giả sử các nhà phát triển viết mã và triển khai nó trực tiếp vào sản xuất. Mục đích là để xác định bất kỳ vấn đề nào trong quy trình của bạn từ doanh nghiệp đến nhóm và xem nhân viên giải quyết vấn đề đó tốt như thế nào.

Hãy xem xét các khía cạnh sau:

• Bạn có thường xuyên lên kế hoạch cho các tính năng mới và phân công công việc cho từng bộ phận và nhóm không?
• Bạn thiết lập và đo lường các chỉ số hiệu suất chính như thế nào?
• Bạn có sử dụng cột mốc không? Ai tham gia vào quá trình chuẩn bị ban đầu của họ? Bạn lên kế hoạch cho họ với nhóm như thế nào?
• Ai điều phối quá trình lập kế hoạch và thực hiện?
• Bạn có thực sự là một công ty linh hoạt? Bạn có sử dụng các khuôn khổ như SAFe, Prince2 hay PMP hay bạn có thứ gì đó được tùy chỉnh phù hợp với mình không?
• Bạn xử lý các nhiệm vụ phức tạp giữa các nhóm và kiểm soát tiến độ như thế nào? Bạn có cách tiếp cận có hệ thống hay bạn tin rằng mọi việc sẽ được giải quyết bằng cách nào đó?

Hãy nhớ rằng, mỗi cấp độ quản lý và báo cáo đều tăng thêm sự phức tạp và không chắc chắn, bất kể hướng đi nào. Cuối cùng, sơ đồ quy trình của bạn phải trả lời một câu hỏi đơn giản: “Làm thế nào?”

Bạn có thể chơi với các mẫu và điều chỉnh nó theo nhu cầu của bạn. Đây là ví dụ cấp cao về quy trình phân phối không có người đóng vai trò chính điều chỉnh việc phân phối nhưng có khung thời gian.

Nếu bạn không chắc chắn về cách tạo sơ đồ này, hãy cân nhắc sử dụng BPMN (Mô hình và ký hiệu quy trình nghiệp vụ) hoặc định dạng đơn giản hơn như hình chữ nhật và đường kẻ để đảm bảo sự rõ ràng và dễ hiểu giữa tất cả các bên liên quan. Điều quan trọng là làm cho quá trình trở nên rõ ràng và dễ hiểu.

Thu thập phản hồi

Khi bạn đã vạch ra cấu trúc công ty, hệ thống phân cấp nhân viên, nhóm và trách nhiệm vị trí cũng như quy trình phân phối, hãy chia sẻ tất cả những phát hiện của bạn với tổ chức và tiến hành một cuộc khảo sát, tốt nhất là ẩn danh. Đường cơ sở này nêu bật cách thức hoạt động của công ty bạn. Mặc dù bạn có thể đã tự mình chuẩn bị phần tổng quan này hoặc ủy quyền một số nhiệm vụ nhưng có thể các nhà phát triển, nhà thiết kế và nhà phân tích không trực tiếp tham gia. Phản hồi của họ là rất quan trọng để đánh giá tính chính xác của những phát hiện của bạn.

Yêu cầu nhân viên đánh giá chất lượng tài liệu của bạn. Họ nghĩ gì về quá trình giao hàng? Nó có thực sự phản ánh cách mọi việc được thực hiện không? Họ thấy những trở ngại ở đâu?

Mong đợi nhiều khiếu nại và phản hồi khác nhau sẽ giúp bạn tinh chỉnh những phát hiện của mình để phù hợp hơn với thực tế hoạt động của công ty. Phản hồi này rất quan trọng vì bối cảnh thường bị bỏ sót qua nhiều cấp độ phân cấp và việc thu thập thông tin đầu vào từ tất cả các cấp sẽ cung cấp bức tranh rõ ràng, chính xác hơn về tổ chức.

Ước tính kết quả

Bây giờ bạn đã có bản mô tả toàn diện về cách thức hoạt động của công ty hoặc các phòng ban, bạn có thể bắt đầu phân tích và tìm kiếm các vấn đề tiềm ẩn. Đường cơ sở này cung cấp một điểm khởi đầu rõ ràng để hiểu và giải quyết vấn đề.

Dưới đây là một số lĩnh vực cần tập trung vào:

• Các phòng ban của bạn có được tổ chức chặt chẽ không? Các dòng báo cáo có rõ ràng không?
• Người quản lý trực tiếp có thể thực sự đưa ra phản hồi về lĩnh vực trách nhiệm của họ không?
• Có sự nhầm lẫn hoặc không chắc chắn trong việc chuyển đổi các yêu cầu kinh doanh thành các nhiệm vụ kỹ thuật không?
• Có sự phụ thuộc nào vào các nhóm khác gây ra sự chậm trễ trong quá trình phát triển không?
• Nhân viên có tham gia vào các hoạt động nằm ngoài phạm vi trách nhiệm chính của họ và cản trở nhiệm vụ chính của họ không?
• Hệ thống phân cấp nhân viên phù hợp với cấu trúc nhóm như thế nào?
• Hệ thống phân cấp báo cáo có hiệu quả hay có những khoảng trống trong giao tiếp và bối cảnh?
• Có phải các nhóm khác nhau đang làm việc trên cùng một dịch vụ, dẫn đến xung đột và lãng phí thời gian khi quyết định quyền sở hữu nhiệm vụ?
• Có đội hoặc bộ phận nào không có trách nhiệm được xác định rõ ràng hoặc thiếu những người đóng vai trò chủ chốt không?
• Có một số nhóm không được tích hợp vào bất kỳ bộ phận nào?

Cuối cùng, bạn có thể chuẩn bị một danh sách các vấn đề thực sự mà công ty bạn gặp phải, đó là điều bạn sẽ giải quyết. Hãy ưu tiên chúng từ những vấn đề quan trọng đòi hỏi sự tương tác ngay lập tức đến những cải tiến “tốt nên có”.

Cách thực hiện thay đổi

Bạn có thể thắc mắc, “Tất cả điều này nghe có vẻ tuyệt vời, nhưng làm cách nào để tôi thực sự cải thiện mọi thứ?” Đó là một câu hỏi hay và câu trả lời trung thực phụ thuộc vào những vấn đề cụ thể mà bạn xác định và nhu cầu kinh doanh của bạn. Tuy nhiên, một lời khuyên quan trọng là tránh cố gắng thay đổi mọi thứ cùng một lúc. Thay vào đó, hãy thực hiện các thay đổi nhỏ dần dần, đánh giá kết quả và lặp lại. Hãy nhớ rằng, cách tiếp cận linh hoạt không chỉ có tác dụng trong phát triển phần mềm mà còn có thể áp dụng cho bất kỳ loại thay đổi nào của tổ chức.

Dưới đây là một số bước để hướng dẫn quá trình cải tiến của bạn:

• Đảm bảo nhân viên biết chính xác vai trò của họ bao gồm những gì và những gì nằm ngoài trách nhiệm của họ.
• Tạo các phòng ban hoặc lĩnh vực được xác định rõ ràng và chỉ định các nhóm cụ thể cho từng lĩnh vực.
• Xác định các lĩnh vực trách nhiệm rõ ràng và giảm thiểu sự chồng chéo giữa các phòng ban và nhóm.
• Hãy cân nhắc việc làm quen với cách tiếp cận Cấu trúc liên kết nhóm, phương pháp này giới thiệu các nhóm nền tảng, liên kết theo luồng, hỗ trợ và hệ thống con phức tạp để giải quyết các khía cạnh khác nhau của việc phát triển phần mềm.
• Xem xét và điều chỉnh hệ thống phân cấp nhân viên của bạn để phù hợp với các miền và nhóm mới thành lập.
• Đảm bảo cấu trúc báo cáo rõ ràng và việc theo dõi tiến độ dễ dàng.
• Chọn phương pháp hoặc khuôn khổ bạn sẽ sử dụng để phân phối tính năng và theo dõi kết quả.
• Kiểm tra các thay đổi ở bất kỳ bộ phận nào, tốt nhất là những bộ phận không quan trọng và đánh giá tác động, tinh chỉnh cách tiếp cận của bạn dựa trên phản hồi và kết quả.
• Liên tục cải tiến bằng cách áp dụng tư duy đã chọn vào những thay đổi của tổ chức.

Bằng cách làm theo các bước này, bạn có thể thực hiện những thay đổi mang tính gia tăng, có hiểu biết để dần dần cải thiện hiệu suất và hiệu suất của tổ chức.

Bản tóm tắt

Tôi nhằm mục đích nêu bật những vấn đề phổ biến có thể phát sinh ở bất kỳ công ty hoặc bộ phận nào. Tôi cố tình tránh đề xuất các khuôn khổ hoặc cách tiếp cận cụ thể vì mỗi công ty đều có mục tiêu và cấu trúc riêng và điều quan trọng là phải quyết định điều gì phù hợp nhất với bạn.

Một lần nữa, thật dễ dàng để đổ lỗi cho các nhà phát triển, nhưng hãy nhớ rằng, họ có thể không biết về các ưu tiên kinh doanh hoặc bị cản trở bởi quy trình phân phối không rõ ràng. Đôi khi, chính doanh nghiệp tạo ra những rào cản một cách vô thức. Tôi hy vọng bài viết này sẽ giúp thực hiện những bước đầu tiên để cải thiện.