Quản lý phụ thuộc: Hướng dẫn đầy đủ cho các dự án và sản phẩm

Informatec Digital » Recursos » Quản lý phụ thuộc: Hướng dẫn đầy đủ cho các dự án và sản phẩm

Quản lý sự phụ thuộc là một trong những vấn đề mà mọi người đều phải đối mặt hàng ngày, nhưng ít tổ chức nào giải quyết một cách có hệ thống. Khi không được kiểm soát, sẽ xảy ra sự chậm trễ, những trở ngại khó hiểu xuất hiện, các cuộc họp khẩn cấp được tổ chức để "giải quyết vấn đề", và cuối cùng, các dự án hoặc bị chậm tiến độ hoặc không bao giờ hoàn thành.

Ngược lại, khi các mối phụ thuộc được xác định, trực quan hóa và quản lý hiệu quả, các nhóm sẽ làm việc tự chủ hơn , thời hạn không còn là một trò may rủi, và sự hợp tác giữa các bộ phận trở nên suôn sẻ hơn nhiều. Trong bài viết này, chúng ta sẽ xem xét chi tiết các mối phụ thuộc trong các dự án và sản phẩm kỹ thuật số, các loại phụ thuộc khác nhau tồn tại và cách quản lý chúng trong thực tế bằng cách sử dụng các phương pháp linh hoạt, các khung công tác như Kanban và các công cụ như Jira hoặc phần mềm quản lý dự án.

Trong quản lý dự án và sản phẩm, chúng ta hiểu sự phụ thuộc là gì?

Trong bối cảnh các dự án và phát triển sản phẩm, sự phụ thuộc là mối quan hệ cần thiết giữa hai yếu tố của công việc: một nhiệm vụ, một nhóm, một thành phần kỹ thuật, hoặc thậm chí là một nhà cung cấp bên ngoài. Để một việc gì đó bắt đầu, tiến triển hoặc kết thúc, một việc khác phải xảy ra trước.

Từ góc độ thực tiễn, một sự phụ thuộc có thể là một yêu cầu chức năng (ví dụ: có giỏ hàng trên trang web) hoặc một yêu cầu kỹ thuật thuần túy (có sẵn API, quyền truy cập vào môi trường hoặc triển khai bản phát hành). Ngay cả khi "tác nhân" sử dụng kết quả không phải là con người mà là một dịch vụ khác, chúng ta vẫn coi đó là một sự phụ thuộc.

Trong quản lý dự án, một nhiệm vụ thường được mô tả là phụ thuộc khi việc thực hiện nó phụ thuộc vào việc hoàn thành, bắt đầu hoặc tiến độ của một nhiệm vụ khác. Nếu "Nhiệm vụ B" cần "Nhiệm vụ A" đạt đến một điểm cụ thể để tiếp tục, thì đó là một sự phụ thuộc.

Các mối phụ thuộc không chỉ là phiền toái: chúng tiềm ẩn những rủi ro thực sự . Chúng làm tăng khả năng chậm trễ, vượt chi phí, thậm chí là hủy bỏ một sáng kiến ​​trước khi nó được đưa vào sản xuất. Theo mặc định, mọi mối phụ thuộc đều là một rủi ro với xác suất và tác động nhất định cần được quản lý, chứ không phải bỏ qua.

Các loại phụ thuộc: tổng quan đầy đủ

Để quản lý hiệu quả các mối phụ thuộc, trước tiên chúng phải được phân loại và đặt tên . Tài liệu quản lý dự án và thực tiễn sản phẩm thường phân biệt một số trục: theo bản chất của chúng (logic, dựa trên tài nguyên, bên ngoài, ưu tiên), theo mối quan hệ giữa các nhiệm vụ và theo phạm vi tổ chức.

Các phòng ban được phân loại theo tính chất của chúng.

Các mối quan hệ logic hay quan hệ nhân quả là những mối quan hệ tuân theo một chuỗi các bước không thể tránh khỏi . Bạn không thể sơn tường nếu chưa xây tường; bạn không thể kiểm tra tính năng nếu chưa phát triển tính năng đó. Chúng là những mối quan hệ trực quan nhất.

Sự phụ thuộc tài nguyên phát sinh khi nhiều nhiệm vụ hoặc dự án cạnh tranh nhau để sử dụng cùng một nguồn lực hạn chế : một nhân sự chủ chốt, một nhà thiết kế duy nhất, một nhóm phát triển hệ thống phụ trợ duy nhất, một máy kiểm thử, v.v. Tiến độ công việc không được quyết định nhiều bởi thứ tự logic, mà bởi sự sẵn có thực tế của các nguồn lực đó.

Các phụ thuộc ưu tiên là những phụ thuộc phát sinh từ các quy trình nội bộ hoặc các thực tiễn tốt nhất nhưng không hoàn toàn cần thiết để hoàn thành sản phẩm bàn giao. Ví dụ, một lần xem xét biên tập bổ sung hoặc một bước kiểm thử chất lượng bổ sung mà nhóm quyết định giữ lại vì nó giúp giảm lỗi, ngay cả khi dự án có thể được "kết thúc" chính thức mà không cần đến nó.

Sự phụ thuộc bên ngoài xảy ra khi nhóm bị ràng buộc bởi các yếu tố mà họ không kiểm soát được : nhà cung cấp phải giao nguyên vật liệu, bộ phận pháp lý phải phê duyệt hợp đồng, thời tiết ảnh hưởng đến dự án hoặc cổng thanh toán bên thứ ba phải chứng nhận dịch vụ của họ.

Sự phụ thuộc giữa các nhiệm vụ: các mối quan hệ thời gian kinh điển

Khi đi sâu vào cấp độ lập kế hoạch, sự phụ thuộc giữa các nhiệm vụ thường được mô hình hóa bằng bốn mối quan hệ cơ bản mà bạn sẽ thấy trong lịch trình hoặc biểu đồ Gantt:

Trong mối quan hệ Kết thúc-Bắt đầu (Finish-to-Start - FS), tác vụ kế tiếp không thể bắt đầu cho đến khi tác vụ trước đó hoàn thành. Đây là mối quan hệ phổ biến nhất và được hầu hết các công cụ sử dụng mặc định.

Trong mối quan hệ hoàn thành-hoàn thành (FF), nhiệm vụ tiếp theo không thể hoàn thành công việc của nó cho đến khi nhiệm vụ trước đó cũng đã hoàn thành . Điều này thường xảy ra khi một nhiệm vụ thực chất là tổng của nhiều nhiệm vụ con phụ thuộc lẫn nhau.

Trong trường hợp Khởi động-đến-Khởi động (Start-to-Start - SS), cả hai tác vụ phải được kích hoạt song song . Tác vụ kế tiếp không thể bắt đầu trước tác vụ trước đó, mặc dù sau đó chúng sẽ tiến hành với tốc độ riêng của mình.

Mối quan hệ từ đầu đến cuối (SF), ít phổ biến hơn nhưng vẫn tồn tại, ngụ ý rằng nhiệm vụ A không thể được coi là hoàn thành cho đến khi nhiệm vụ B bắt đầu. Một ví dụ điển hình là việc chuyển ca trong dịch vụ khách hàng: một người không thể rời đi cho đến khi người tiếp theo đến.

Sự phụ thuộc nội bộ, bên ngoài và giữa các nhóm

Ngoài bản chất của chúng, điều quan trọng là phải phân biệt giữa các phụ thuộc nội bộ trong dự án (giữa các nhiệm vụ hoặc nguồn lực mà chính nhóm kiểm soát) và các phụ thuộc bên ngoài, phụ thuộc vào bên thứ ba.

Trong các tổ chức quy mô vừa và lớn, sự phụ thuộc giữa các nhóm ngày càng trở nên quan trọng: khi nhiều nhóm nhỏ, phòng ban hoặc nhà cung cấp cần phối hợp để đạt được kết quả chung. Điều này bao gồm sự phụ thuộc giữa các nhóm sản phẩm, giữa các nhóm nhỏ và các nhóm chức năng chéo (Nhân sự, Mua sắm, Pháp lý), và giữa các nhóm kỹ thuật như nhóm phát triển back-end, front-end, di động và vận hành.

Quản lý phụ thuộc chủ động so với quản lý phụ thuộc thụ động

Cách một tổ chức giải quyết các vấn đề phụ thuộc tạo nên sự khác biệt giữa một văn hóa "chữa cháy" và một môi trường lành mạnh hơn nhiều. Chúng ta có thể nói về hai chiến lược cơ bản : chủ động và phản ứng.

Quản lý phản ứng chỉ giải quyết sự phụ thuộc khi nó bùng nổ : khi thiếu quyền hạn, quyền truy cập, thành phần hoặc API, và nhóm bị mắc kẹt. Đây là tình huống điển hình của việc liên tục ngừng hoạt động, lập kế hoạch lại ngay lập tức và phá vỡ cam kết.

Ngược lại, quản lý chủ động bao gồm việc dành nỗ lực ngay từ đầu để xác định và lập kế hoạch cho các mối phụ thuộc . Nhu cầu được dự đoán trước, năng lực được dành riêng, các cam kết giữa các nhóm được làm rõ và rủi ro được xác định trước khi chúng trở thành vấn đề.

Mặc dù luôn có yếu tố phản ứng (bạn không thể lường trước mọi thứ), nhưng một chiến lược quản lý phụ thuộc hiệu quả phải có yếu tố chủ động mạnh mẽ : phân tích, ưu tiên, chuẩn bị các kịch bản thay thế và thiết lập các sự kiện định kỳ để xem xét trạng thái của các phụ thuộc đó.

Trực quan hóa các mối quan hệ phụ thuộc: từ Kanban đến ma trận trong Jira

Bước quan trọng đầu tiên trong việc quản lý các mối phụ thuộc là làm cho chúng hiển thị rõ ràng với mọi người . Những gì không được nhìn thấy sẽ không được quản lý; nó sẽ gây ra hậu quả. Đây là lúc các phương pháp Kanban, bảng chương trình và các hình thức trực quan hóa khác nhau phát huy tác dụng.

Trong hệ thống Kanban, một trong những nguyên tắc cơ bản là trực quan hóa công việc . Điều này bao gồm việc làm rõ những nhiệm vụ nào phụ thuộc vào nhiệm vụ khác, cũng như những nhiệm vụ nào đang gây cản trở cho các nhóm khác. Việc đánh dấu rõ ràng những mục nào đang "chờ phụ thuộc" giúp tránh những sự cố bất ngờ.

Trong các công cụ như Jira, một cách tiếp cận rất thiết thực là tận dụng trường liên kết vấn đề để kết nối các nhiệm vụ gây cản trở lẫn nhau . Bạn có thể sử dụng các mối quan hệ "chặn" hoặc "phụ thuộc vào", phân biệt giữa các phụ thuộc mạnh (ngăn nhiệm vụ phụ thuộc bắt đầu) và các phụ thuộc yếu hơn (cho phép tiến trình song song trong khi nhiệm vụ kia đang được giải quyết).

Nếu tác vụ cần thiết để giải quyết sự phụ thuộc đó chưa tồn tại, bạn có thể chọn gắn thẻ cho vấn đề bằng một dấu hiệu cụ thể để chỉ ra nhu cầu chưa được giải quyết này. Thẻ này sau đó sẽ cho phép bạn nhóm và hiển thị các sự phụ thuộc chưa được giải quyết này trong các bảng, lộ trình, danh sách công việc tồn đọng hoặc bảng tổng hợp.

Với thông tin này, có thể xây dựng ma trận phụ thuộc trong đó một chiều thể hiện các nhóm hoặc đội của tổ chức , và chiều còn lại thể hiện mốc thời gian. Điều này cho thấy ai phụ thuộc vào ai và khi nào, tạo điều kiện thuận lợi cho việc phân bổ năng lực và đàm phán ưu tiên.

Trước khi hình thức làm việc từ xa được áp dụng rộng rãi, các ma trận này thường được vẽ trên các bảng vật lý. Ngày nay, các plugin và mô-đun của Jira như Advanced Roadmaps, BigPicture và Structure cho phép thể hiện trực quan các mạng lưới phụ thuộc này trong môi trường làm việc kết hợp hoặc hoàn toàn từ xa.

Lớp đặt chỗ và bảng đặt chỗ trong Kanban

Khi đã có cái nhìn tổng quan về các mối phụ thuộc ở cấp độ sản phẩm hoặc tổ chức, bạn có thể tiến thêm một bước nữa và áp dụng khái niệm về các lớp đặt chỗ , từ phương pháp Kanban, để gán các mức độ dịch vụ khác nhau cho việc giải quyết các mối phụ thuộc.

Lớp đặt chỗ được sử dụng để phân loại công việc theo mức độ ưu tiên, tính cấp bách hoặc thời gian giao hàng yêu cầu. Để sử dụng phương pháp này với các mối phụ thuộc, lịch được sử dụng để phân bổ các khoảng thời gian dành riêng cho việc giải quyết chúng, theo ngày, tuần hoặc chu kỳ (ví dụ: Sprint trong các nhóm Scrum).

Thông thường có ba loại dự trữ chính. Thứ nhất, có các nguồn lực được đảm bảo, trong đó công suất được dành riêng để đảm bảo rằng, nếu cần thiết, chúng sẽ có sẵn vào một ngày cụ thể. Những nguồn lực này thường tương ứng với các nhiệm vụ quan trọng nhưng không lường trước được.

Thứ hai là các phụ thuộc đã được đặt trước: đây là những nhiệm vụ đã có thời gian hoàn thành được cam kết . Chúng thường được sử dụng cho các phụ thuộc chặt chẽ mà việc giải quyết chúng cho phép một nhóm khác bắt đầu công việc.

Cuối cùng, các phụ thuộc dự phòng thuộc một loại mà chúng chỉ được giải quyết nếu có đủ dung lượng . Đây thường là những phụ thuộc có thể tạm thời tránh được, hoãn lại trong khi các phần khác của công việc được tiến hành.

Mô hình này rất giống với cách các hãng hàng không quản lý vé: có những chỗ ngồi được đảm bảo với giá rất cao, đặt chỗ tiêu chuẩn và vé chờ phụ thuộc vào việc không bị đặt quá chỗ. Ngay cả trạng thái của vé chờ cũng có thể thay đổi theo thời gian , chuyển từ "đang chờ" sang "đã đặt" hoặc "được đảm bảo" khi ngày đến gần và rủi ro tăng lên.

Các sự kiện nhằm xem xét các mối phụ thuộc và phối hợp các nhóm.

Việc chỉ có bảng đặt chỗ hoặc ma trận phụ thuộc là chưa đủ nếu chúng không được tích hợp vào các quy trình xem xét định kỳ . Điều quan trọng là phải có ít nhất một sự kiện trong quy trình làm việc hiện tại để xem xét và điều chỉnh các mối phụ thuộc này.

Không nhất thiết phải là một cuộc họp mới; nó có thể được tích hợp như một phần cố định trong chương trình nghị sự của các cuộc họp hiện có: ví dụ, trong cuộc họp lập kế hoạch chu kỳ lặp, trong cuộc họp lập kế hoạch PI theo kiểu SAFe, hoặc trong phiên phối hợp giữa các nhóm.

Điều thực sự quan trọng là tất cả các bên liên quan đến việc tạo ra và giải quyết các mối phụ thuộc đều phải có mặt trong quá trình xem xét này . Nếu thiếu cuộc đối thoại trực tiếp (hoặc qua màn hình), rất dễ dẫn đến những kỳ vọng sai lầm, những cam kết đơn phương và những lời hứa không thể thực hiện.

Các mối quan hệ phụ thuộc tốt và xấu: đồng bộ và bất đồng bộ

Nghe có vẻ phi lý, nhưng không phải tất cả các mối quan hệ phụ thuộc đều xấu. Một số mối quan hệ phụ thuộc thúc đẩy sự hợp tác lành mạnh , trong khi những mối quan hệ khác tạo ra sự chia rẽ và mâu thuẫn liên tục. Một cách hữu ích để phân biệt giữa chúng là nói về các mối quan hệ phụ thuộc đồng bộ và không đồng bộ.

Các phụ thuộc bất đồng bộ là những phụ thuộc mà các nhóm không làm việc cùng một lúc hoặc cùng một nhịp độ. Một nhóm Scrum dự định tích hợp vào Sprint hiện tại một công việc phát triển mà một nhóm khác sẽ thực hiện trong Sprint tiếp theo, hoặc một yêu cầu khẩn cấp về quyền truy cập vào một nguồn lực phụ thuộc vào một nhóm thứ ba đang quá tải, là những ví dụ về các phụ thuộc bất đồng bộ gây ra vấn đề.

Ngược lại, sự phụ thuộc đồng bộ xảy ra khi công việc diễn ra trong cùng một khung thời gian . Ví dụ, nhiều nhóm cùng chia sẻ môi trường phát triển và thử nghiệm, hoặc một thư viện phần mềm chung mở cho sự đóng góp từ bất kỳ nhà phát triển nào trong công ty.

Những mối quan hệ phụ thuộc này khuyến khích mọi người tích cực hợp tác và chia sẻ thông tin . Nếu không có chúng, mỗi nhóm sẽ dễ dàng tự cô lập mình trong phạm vi hoạt động riêng. Và sự cô lập này, ngoài việc hạn chế tầm nhìn tổng thể, còn có xu hướng làm suy yếu sự thấu hiểu giữa các phòng ban và làm phức tạp quá trình ra quyết định ở cấp độ tổ chức.

Chiến lược dài hạn nên hướng đến việc giảm thiểu sự phụ thuộc không đồng bộ và tăng cường sự phụ thuộc đồng bộ, ưu tiên các nhóm có quyền tự chủ toàn diện cao hơn và các phương thức hợp tác cởi mở hơn.

Thiết kế cấu trúc tổ chức và đội nhóm nhằm giảm thiểu sự phụ thuộc.

Cấu trúc tổ chức ảnh hưởng trực tiếp đến số lượng và loại hình phụ thuộc. Khi sản phẩm phát triển và số lượng nhóm tăng lên, sẽ xuất hiện nhiều ma sát, chồng chéo và tắc nghẽn hơn . Thông thường, các vấn đề bắt đầu xuất hiện chỉ với hai nhóm nhỏ và trở nên nghiêm trọng hơn với mỗi nhóm mới được thành lập.

Trong các tổ chức tích hợp theo chiều dọc và định hướng sản phẩm, mục tiêu thường là tạo ra các nhóm đa ngành có tính tự chủ cao nhất có thể , rất phù hợp với cấu trúc "nhóm theo luồng" được mô tả trong phần Cấu trúc nhóm. Các nhóm này chịu trách nhiệm về một lĩnh vực kinh doanh hoặc lĩnh vực phụ từ đầu đến cuối.

Ngay cả với các nhóm tự chủ, vẫn cần có các đòn bẩy điều chỉnh để đảm bảo tính nhất quán của sản phẩm và ngăn chặn sự đổ vỡ trong hợp tác nhóm: các trường hợp phân xử lộ trình toàn cầu, các sự kiện lập kế hoạch chung lấy cảm hứng từ Lập kế hoạch PI, bảng chương trình trực quan hóa các mối phụ thuộc, hệ thống thiết kế chung và cộng đồng thực hành, cùng với các cơ chế khác.

Trên thực tế, nhiều công ty cuối cùng phải áp dụng các mô hình lai, trong đó không phải tất cả các kỹ năng đều có mặt trong mọi nhóm . Các nhóm đa chức năng xuất hiện, bao gồm Thiết kế sản phẩm, Dữ liệu, Kiểm thử phần mềm, Di động, Hệ thống phụ trợ hoặc Vận hành, phục vụ nhiều nhóm sản phẩm, tạo ra thêm các phụ thuộc cần được quản lý hiệu quả.

Các phòng ban có đội ngũ đa chức năng: Nhân sự, Mua sắm, Pháp lý…

Bên cạnh các lĩnh vực kỹ thuật, nhiều nhóm còn phụ thuộc vào các đội ngũ đa chức năng trong công ty như Nhân sự, Mua sắm hoặc Pháp lý. Sự phụ thuộc này thường thể hiện ở việc tuyển dụng nhân sự chủ chốt, xây dựng năng lực thông qua các nhà cung cấp bên ngoài, quản lý ngân sách hoặc xem xét pháp lý.

Khi một đội bóng cần ký hợp đồng hoặc tăng cường đội hình mà không kiểm soát được quá trình này , thời gian đưa cầu thủ ra thị trường sẽ bị ảnh hưởng và khả năng dự đoán bị suy giảm. Có thể kích hoạt một số biện pháp để giảm thiểu những tình huống này.

Một lựa chọn là giao phó một số hoạt động traditionally do bộ phận Nhân sự hoặc Mua sắm quản lý cho các nhóm (ví dụ: một phần của quy trình tuyển chọn hoặc mối quan hệ vận hành với nhà cung cấp), với cơ chế quản trị rõ ràng nhưng ít thủ tục rườm rà hơn.

Một cách khác là đàm phán ngân sách dịch vụ sao cho mỗi nhóm có quyền tự quyết định về việc thuê những chuyên gia hoặc dịch vụ nào và khi nào, trong giới hạn đã thỏa thuận.

Ngoài ra, cũng có thể tận dụng việc tích hợp các chuyên gia Nhân sự, Mua sắm hoặc Pháp lý vào các nhóm để đẩy nhanh các quyết định quan trọng , đặc biệt là trong thời kỳ tăng trưởng mạnh hoặc những thay đổi chiến lược quan trọng.

Các phụ thuộc kỹ thuật điển hình: hệ thống phụ trợ, vận hành và ứng dụng di động

Xét về mặt kỹ thuật, có ba nguồn phụ thuộc phổ biến: các nhóm phát triển back-end riêng biệt , các nhóm vận hành (Ops) độc lập và các nhóm phát triển ứng dụng di động hoạt động độc lập.

Khi một nhóm phát triển back-end tập trung phục vụ nhiều nhóm phát triển front-end, điều này tạo ra mối quan hệ khách hàng-nhà cung cấp khó quản lý . Nhóm back-end phải xây dựng API cho tất cả mọi người, cân bằng các ưu tiên bên ngoài mà họ không kiểm soát được, và chịu đựng áp lực. Trong khi đó, các nhóm phát triển sản phẩm gặp phải sự chậm trễ và thất vọng vì không biết khi nào các chức năng họ cần sẽ sẵn sàng.

Như một biện pháp tạm thời, các nhà phát triển back-end có thể được tích hợp vào các nhóm , các hợp đồng giao diện rõ ràng giữa back-end và front-end có thể được định nghĩa, hoặc kiến ​​trúc microservices có thể được phát triển trong đó mỗi nhóm chịu trách nhiệm về các dịch vụ của riêng mình, chấp nhận rằng các phụ thuộc mới sẽ xuất hiện, nhưng dễ quản lý hơn nhiều.

Đối với các nhóm vận hành, sự phụ thuộc thường tập trung vào quản lý môi trường và triển khai . Các nhóm phát triển hoàn thành công việc của họ, nhưng họ cần nhóm vận hành triển khai đến từng môi trường. Nếu nhóm vận hành bị quá tải, các bản phát hành sẽ tồn đọng, được ưu tiên một cách thiếu minh bạch, và nguy cơ giao hàng chậm trễ hoặc vội vàng sẽ tăng lên.

Để cải thiện lĩnh vực này, có thể triển khai hệ thống quản lý trực quan kiểu Kanban cho quy trình phân phối, tích hợp các câu chuyện người dùng cụ thể liên quan đến yêu cầu vận hành vào danh sách công việc tồn đọng của các nhóm, và cung cấp các "nhà máy phần mềm dưới dạng dịch vụ" tự động hóa phần lớn quy trình.

Tuy nhiên, bước tiến thực sự quan trọng đến khi một nền văn hóa DevOps hoàn thiện được áp dụng , nơi bộ phận phát triển và vận hành hợp tác chặt chẽ, việc kiểm thử và triển khai được tự động hóa, và các nhóm có khả năng đưa những thay đổi của họ vào môi trường sản xuất một cách an toàn.

Điều tương tự cũng xảy ra với các nhóm phát triển ứng dụng di động độc lập: kỹ năng chuyên biệt cao của họ (iOS, Android, thiết kế di động, hướng dẫn nền tảng) khiến nhiều tổ chức gộp họ vào một nhóm duy nhất, dẫn đến việc nhóm này phải phục vụ nhiều nhóm nhỏ khác nhau. Điều này tạo ra sự xếp hàng chờ đợi, việc ưu tiên phức tạp và tắc nghẽn khi tất cả các nhóm cùng lúc yêu cầu thay đổi trên nền tảng di động.

Một chiến lược khả thi là duy trì các nhóm di động đó với logic nhóm khám phá đi kèm với các đội, đánh dấu các mẫu, các thành phần có thể tái sử dụng và các thực tiễn tốt, và giải tán đơn vị đó khi phạm vi chức năng trên thiết bị di động tương đương với phiên bản web.

Quản lý phụ thuộc phần mềm: thư viện, khung phần mềm và bảo mật

Ngoài khía cạnh tổ chức, trong phát triển phần mềm, thuật ngữ "phụ thuộc" thường đề cập đến các thư viện, framework và thành phần bên ngoài mà ứng dụng của bạn cần để hoạt động. Ở đây, chúng ta đang nói về các trình quản lý phụ thuộc như Maven, Gradle, npm hoặc Composer.

Quản lý kém các phụ thuộc này có thể dẫn đến xung đột phiên bản , sự cố tích hợp, khó khăn trong bảo trì lâu dài hoặc lỗ hổng bảo mật. Đó là lý do tại sao việc sử dụng các công cụ tự động hóa quá trình tải xuống, phân giải phiên bản và cập nhật có kiểm soát lại rất quan trọng.

Nên cập nhật các thư viện phụ thuộc ở mức độ hợp lý , cân bằng giữa bảo mật và tính ổn định. Việc cập nhật quá mức có thể gây ra lỗi không mong muốn, nhưng việc cập nhật không thường xuyên lại khiến dự án dễ bị tổn thương trước các lỗ hổng đã biết hoặc các phiên bản độc hại trên npm.

Việc giảm thiểu số lượng phụ thuộc cũng là một thực hành tốt: trước khi thêm một thư viện mới, bạn nên tự hỏi liệu nó có thực sự mang lại giá trị hay không, hay liệu đó là điều có thể được xử lý đơn giản hơn. Mỗi phụ thuộc được thêm vào đồng nghĩa với việc tăng diện tích bề mặt cần bảo trì, tiềm ẩn xung đột và trong nhiều trường hợp, ảnh hưởng đến hiệu năng.

Tất cả những điều này cần đi kèm với tài liệu rõ ràng về các thư viện phụ thuộc được sử dụng, phiên bản nào và mục đích sử dụng, cũng như việc kiểm tra tự động nghiêm ngặt để xác minh rằng bản cập nhật không làm hỏng chức năng hiện có. Các công cụ phân tích bảo mật cũng giúp phát hiện các lỗ hổng đã biết trong các thư viện phụ thuộc được thêm vào.

Mẹo thực tế để quản lý các mối phụ thuộc trong dự án

Trong quản lý dự án hàng ngày, có một số phương pháp giúp kiểm soát hiệu quả các mối phụ thuộc . Một số công cụ (Asana, Wrike, Jira, v.v.) đều khuyến nghị một số cách tiếp cận nhất định.

Đầu tiên, điều quan trọng là phải tổ chức các nhiệm vụ trong một công cụ quản lý dự án mạnh mẽ cho phép bạn mô hình hóa sự phụ thuộc giữa các nhiệm vụ, trực quan hóa tiến độ và nhanh chóng xem điều gì đang bị tắc nghẽn và tại sao. Điều này giúp giảm nguy cơ bỏ sót các mối liên hệ quan trọng.

Việc trực quan hóa các mối quan hệ phụ thuộc một cách rõ ràng, bằng cách sử dụng biểu đồ Gantt, sơ đồ lộ trình hoặc bảng Kanban , cũng rất hữu ích . Việc nhìn thấy thứ tự thực hiện và các điểm tắc nghẽn giúp nhóm hiểu rõ hơn lý do tại sao một số nhiệm vụ lại được thực hiện trước hoặc sau họ và chúng ảnh hưởng đến các đồng nghiệp của họ như thế nào.

Một khía cạnh quan trọng khác là giám sát các rủi ro tiềm ẩn liên quan đến sự phụ thuộc. Trong giai đoạn đầu của kế hoạch dự án, nên thảo luận về các rủi ro phụ thuộc cụ thể : quá tải nhân sự chủ chốt, nhà cung cấp bên ngoài, giấy phép đang chờ xử lý hoặc các quyết định kinh doanh chưa hoàn thành.

Cuối cùng, giao tiếp cởi mở giữa các bên liên quan là điều thiết yếu. Giao tiếp không bao giờ là thừa khi xử lý các vấn đề phụ thuộc: nếu ai đó biết rằng họ sẽ bị chậm trễ trong một nhiệm vụ mà những người khác phụ thuộc vào, tốt nhất là nên thông báo cho họ càng sớm càng tốt để mọi người khác có thể điều chỉnh kế hoạch của mình và tránh bị ảnh hưởng nặng nề.

Tác động của các yếu tố phụ thuộc đến sự thành công của dự án

Nắm vững quản lý sự phụ thuộc có tác động trực tiếp đến sự thành công của dự án. Một mặt, nó cho phép kiểm soát toàn diện hơn và lập kế hoạch chiến lược dựa trên thông tin tốt hơn , vì người quản lý dự án có thể thấy tất cả các thành phần kết hợp với nhau như thế nào và xác định một trình tự công việc thực tế.

Mặt khác, nó cải thiện đáng kể khả năng quản lý thời gian và ngăn ngừa sự chậm trễ . Bằng cách hiểu rõ trình tự và sự phụ thuộc của các nhiệm vụ quan trọng, thời hạn có thể được điều chỉnh chính xác hơn, các nhiệm vụ thực sự quan trọng có thể được ưu tiên và hậu quả của việc thay đổi tiến độ nhiệm vụ có thể được phát hiện ngay lập tức.

Hơn nữa, quản lý phụ thuộc tốt giúp giảm thiểu lỗi và tối ưu hóa tài nguyên . Nó tránh việc trùng lặp công sức, giảm thiểu việc làm lại không cần thiết và tạo ra một trình tự thực hiện giúp hạn chế khả năng xảy ra những sai sót tốn kém.

Tất cả những điều này dẫn đến tính linh hoạt và khả năng thích ứng cao hơn: khi những thay đổi là không thể tránh khỏi, việc có một bản đồ rõ ràng về các mối phụ thuộc cho phép bạn tổ chức lại kế hoạch với ít khó khăn hơn , dự đoán được các tác động và định hình lại các ưu tiên với sự phán đoán tốt hơn.

Nhìn chung, việc quản lý hiệu quả các mối liên hệ phụ thuộc giữa các nhiệm vụ, nhóm và các thành phần kỹ thuật trở thành yếu tố then chốt dẫn đến thành công trong cả các dự án đơn lẻ và quá trình phát triển liên tục các sản phẩm kỹ thuật số phức tạp. Các tổ chức ưu tiên các nhóm tự chủ, trực quan hóa rõ ràng, các quy trình phối hợp và một nền văn hóa kỹ thuật vững mạnh sẽ giảm thiểu tắc nghẽn, cải thiện thời gian đưa sản phẩm ra thị trường và cho phép các nhóm làm việc hiệu quả hơn, tập trung hơn vào việc mang lại giá trị thực sự cho người dùng cuối.