Quản lý Nợ Kỹ thuật với DX và AI

Mỗi công ty, lớn hay nhỏ, đều lo lắng về nợ kỹ thuật. Gartner ước tính rằng khoảng 40% hệ thống cơ sở hạ tầng có vấn đề này. Trong một cuộc khảo sát của CIO bởi McKinsey, gần một phần ba cảm thấy rằng hơn 20% ngân sách sản phẩm mới của họ được dành để giải quyết các vấn đề liên quan đến nợ kỹ thuật. Nhưng trái với những gì nhiều người tin, đây không chỉ là vấn đề mã hóa; nó cũng là vấn đề về trải nghiệm nhà phát triển (DX). Bởi vì khi các nhà phát triển phải làm việc với kiến trúc không đầy đủ, công cụ lỗi thời và quy trình phát triển không tốt, năng suất, hiệu suất và tinh thần làm việc sẽ bị ảnh hưởng.

Việc ưu tiên nợ kỹ thuật với nhà phát triển trong tâm trí, tập trung vào cách họ tiếp cận công việc, công cụ họ sử dụng và sự tiến bộ trong sự nghiệp họ có thể đạt được, giúp các đội tập trung và giao hàng nhanh hơn. Đây là lý do tại sao cách các công ty quản lý nợ kỹ thuật đang thay đổi, được thúc đẩy bởi DX và sự tập trung ngày càng tăng vào công cụ AI.

Đẩy mạnh DX

Cách các nhà phát triển thường được giới thiệu để bắt đầu công việc thường không được như mong đợi. Có thể mất vài tuần để ai đó bắt đầu đóng góp vào một dự án. Một khi họ đã có thể thêm các tính năng nhỏ hoặc bản vá, thì không phổ biến khi thấy dịch vụ tích hợp liên tục (CI) thất bại do một điều gì đó hoàn toàn không liên quan đến các thay đổi họ đã thực hiện. Đây cơ bản là bộ thử nghiệm thất bại do các vấn đề chất lượng kém, và nhà phát triển không gửi các thay đổi để làm cho bộ thử nghiệm bị hỏng. Đây là một thử nghiệm không ổn định, được viết kém và chỉ hoạt động 90% thời gian. Đội ngũ hiện tại có thể chấp nhận được điều này – nó chỉ làm chậm quá trình – nhưng công cụ có thể lỗi thời và làm mất tinh thần cho bất kỳ ai bên ngoài tổ chức.

Đây là một ví dụ trong số nhiều ví dụ về những điều cản trở trải nghiệm DX đúng đắn. Một cách để ngăn chặn điều này là có một người lãnh đạo được chỉ định trong đội ngũ kỹ sư và phát triển phần mềm của bạn. Nhiều tổ chức nhỏ không có một người lãnh đạo DX, nhưng các tổ chức lớn và thành công thì có. Những chuyên gia này theo dõi các điều như thời gian cần thiết để một nhà phát triển mới thiết lập môi trường. Và nếu hai tuần là quá lâu, họ sẽ tìm cách cắt giảm thời gian đó một nửa.

Có các công cụ để giúp đỡ, như CircleCI, với các tính năng bản địa sẽ theo dõi sự không ổn định của bộ thử nghiệm. Điều cần thiết là có ai đó lãnh đạo và停止 sau mỗi sprint để giải quyết một số thay đổi sẽ làm cho mã dễ dàng bảo trì và làm việc trong tương lai. Điều này phụ thuộc vào việc có một lãnh đạo quan tâm đến việc cải thiện DX. Để làm cho điều đó xảy ra, hãy tìm kiếm một kỹ sư cấp cao, đi cùng với một thành viên nhân viên tương đối mới có thể cung cấp phản hồi về các khoảng trống có thể.

Ngoài ra, IDC dự đoán rằng thị trường tự động hóa thử nghiệm phần mềm được hỗ trợ bởi AI sẽ tiếp tục tăng trưởng với tốc độ CAGR là 31,2% cho đến năm 2027, vì vậy hãy đảm bảo rằng bạn đang tận dụng công nghệ này tối đa.

Thước đo và dấu hiệu cảnh báo

Có nhiều thước đo bạn có thể theo dõi khi đánh giá cách nợ kỹ thuật ảnh hưởng đến đội ngũ của bạn. Một số thước đo cơ bản là “thời gian sửa chữa” hoặc “thời gian tính năng”. Hãy nói rằng bạn nhận thấy một lỗi và biết cách sửa chữa nó. Một số công cụ có thể theo dõi thời gian từ việc viết mã đến sản xuất. Ví dụ, bạn sẽ có thể thấy một bản vá nhỏ mất hai ngày làm việc để sửa chữa và giao hàng, khi đội ngũ của bạn cần phải làm điều đó trong vài giờ. Bạn cũng có thể theo dõi tỷ lệ, như số lượng bản vá lỗi so với số lượng tính năng hoàn thành.

Cũng có những cách để xác định khi vấn đề về tinh thần ảnh hưởng đến hiệu suất của đội ngũ của bạn. Các lãnh đạo DX có thể chạy khảo sát hàng quý để xác định mức độ hài lòng của một nhà phát triển khi làm việc trên một dự án hoặc một phần của nó. Họ có thể đi sâu và hỏi về các lĩnh vực cụ thể như quá trình tích hợp liên tục. Và bạn luôn có thể theo dõi tỷ lệ luân chuyển hoặc thay đổi trong đội ngũ của mình. Nếu bạn nhận thấy rằng mọi người liên tục rời đi, họ có thể cảm thấy như các mối quan tâm của họ không được lắng nghe.

Làm việc với AI

Sự gia tăng của công cụ AI được cho là sẽ làm cho các nhà phát triển và kỹ sư trở nên năng suất hơn và sản phẩm được giao hàng nhanh hơn, nhưng nợ kỹ thuật làm chậm quá trình này. Hãy nói rằng bạn sử dụng một công cụ như GitHub hoặc Copilot để giúp với các thay đổi mã, sau đó gửi yêu cầu kéo, và CI mất vài giờ để trả lời. Trong thời gian đó, một nhà phát triển có làm việc trên một điều gì khác không? Kiểm tra email? Đây là một sự chuyển đổi ngữ cảnh và một kẻ giết năng suất.

Nhà phát triển muốn làm việc trên các sản phẩm nơi họ có thể chỉ tập trung vào mã. Công cụ là để giúp họ đưa mã đến sản xuất, không phải là một chướng ngại vật liên tục. AI có thể tiết kiệm thời gian, nhưng đó là trách nhiệm của các đội ngũ kỹ thuật để xác định các tiêu chuẩn của họ về sự phức tạp có thể chấp nhận được. Để làm điều này, trước tiên hãy đảm bảo rằng bất kỳ mã nào được thêm vào nhánh chính của bạn có mức nợ kỹ thuật có thể chấp nhận được. Trước đó, hãy có một cuộc thảo luận mở và có được sự đồng ý từ đội ngũ kỹ thuật về ngưỡng nợ kỹ thuật và chất lượng mã có thể chấp nhận được. Hãy đảm bảo rằng mọi người đều biết rằng việc vượt quá mức đó sẽ yêu cầu khắc phục ngay lập tức. Một khi bạn đã xác định được các tiêu chuẩn đó, AI sẽ phát huy tác dụng.

Có một trường hợp cho các tác nhân AI với các kỹ sư đóng vai trò là người điều phối. Một cuộc khảo sát của Capgemini với 1.100 giám đốc điều hành tại các doanh nghiệp lớn đã tiết lộ rằng 82% dự định tích hợp các tác nhân AI trong ba năm tới, và họ đã bắt đầu ảnh hưởng đến tương lai của công việc. Bạn có thể đang xem một báo cáo lỗi và thấy rằng nó đủ nhỏ để một tác nhân AI xử lý từ khâu bắt đầu đến khâu xem xét mã, giúp đội ngũ của bạn tiết kiệm thời gian và giải phóng họ để xử lý công việc phức tạp hơn. Tuy nhiên, đôi khi khi chúng ta theo đuổi các công cụ này một cách mù quáng, có những sự đánh đổi mà AI khó có thể xem xét.

Đó là khi một ý kiến con người trở thành yếu tố quyết định.

Đồng bộ hóa nợ kỹ thuật với mục tiêu

Làm thế nào để bạn đồng bộ hóa việc giảm nợ kỹ thuật với các mục tiêu bạn đang cố gắng đạt được hoặc các kết quả đo lường được? Điều này quay trở lại vấn đề nợ kỹ thuật có thể chấp nhận được, và đôi khi trong kinh doanh, bạn phải giao hàng nhanh. Bạn có thể làm như vậy với kiến thức rằng sản phẩm không thể mở rộng quy mô, và có thể có các vấn đề về hiệu suất khi thời gian trôi qua. Thường xuyên, một nhà phát triển sẽ ghi chú lại để quay lại vấn đề này sau, khi có thời gian để giải quyết các vấn đề này, nhưng điều này hiếm khi xảy ra. Và khi văn hóa kém này chiếm ưu thế, trong đó bạn phải giao hàng vào ngày mai, tác động của nợ kỹ thuật trở nên rõ ràng.

Điều này có thể chấp nhận được đối với một công ty khởi nghiệp, nhưng không phải đối với một doanh nghiệp đã hoạt động trong một thập kỷ. Bạn cần bắt đầu thay đổi văn hóa của mình sớm và chủ động để quản lý nợ kỹ thuật; nếu không, bạn sẽ phải chi một khoản tiền lớn để sửa chữa các lỗi sản xuất hoặc lo lắng về bảo mật và tuân thủ.

Cuối cùng, có các thước đo để giúp truyền đạt giá trị của việc tái cấu trúc hoặc trả nợ kỹ thuật cho các bên liên quan. Thời gian có thể là một trong những yếu tố này, từ khâu bắt đầu đến sản xuất, hoặc từ khi mở một yêu cầu kéo đến khi hợp nhất và giao hàng đến sản xuất. Một yếu tố khác là thời gian trung bình để sửa chữa (MTTR). Trong trường hợp này, bạn có thể đã tìm thấy một lỗi hoặc một bản xây dựng bị hỏng, và bạn đo lường thời gian cần thiết để đội ngũ của bạn sửa chữa nó. Bạn cũng có thể theo dõi số lượng lỗi trong sản xuất. Nếu bạn thấy số lượng này tăng lên, có thể có vấn đề liên quan đến nợ kỹ thuật.

Nợ kỹ thuật với lãi suất

Mỗi tổ chức có thể dành một vài giờ mỗi tuần để cải thiện DX của mình để giúp giảm nợ kỹ thuật. Nếu không, bạn có thể phải trả giá cho điều đó sau, có thể bằng cách giảm hiệu suất, giảm đáng kể tốc độ phát triển, hoặc các vấn đề về bảo mật. Ví dụ, đội ngũ kỹ sư và nhà phát triển của bạn có thể đã trì hoãn việc nâng cấp Ruby on Rails trong một thập kỷ. Đột nhiên, chi phí dự án tăng lên 500.000 đô la vì phiên bản Ruby đã lỗi thời bốn thế hệ, để lại cho bạn một lượng mã và các phụ thuộc lỗi thời.

Nếu bạn đã nâng cấp dần dần, bạn sẽ không gặp phải tình huống này. Vì vậy, hãy hỗ trợ đội ngũ phát triển phần mềm của bạn và trả tiền khi bạn đi. Nếu không, nợ kỹ thuật đó sẽ quay lại ám ảnh bạn, với lãi suất.