4 rủi ro về nợ công nghệ mà startup của bạn cần tránh

Nợ công nghệ là chi phí nằm ngoài bảng cân đối cần phải thực hiện trong tương lai. Nó tích tụ bằng cách chọn giải pháp kỹ thuật giới hạn/giá rẻ hơn ngay bây giờ và đẩy lùi giải pháp đầy đủ/giá đắt hơn đến tương lai. Bằng cách không triển khai giải pháp đầy đủ ngay bây giờ, các công ty phải đối mặt với nhu cầu 'làm lại' phần mềm phát triển trong tương lai.

Sau khi làm việc chặt chẽ với hơn 25 startup trong quá trình họ đi từ giai đoạn sơ khai đến giai đoạn tăng trưởng, tôi đã hiểu được cách nợ công nghệ kích thích việc làm lại và những gì các startup nên làm để tránh nó và chuyển sang mức độ tiếp theo.

Các startup thường xem xét lợi ích ngắn hạn của việc giao hàng nhanh để đạt được các mốc quan trọng, chiếm được khách hàng quan trọng, hoặc huy động vốn cho vòng gọi vốn tiếp theo. Cũng phổ biến khi các startup thêm chức năng không phải là phần của lộ trình gốc bằng cách lơ là quan điểm dài hạn.

Không thể hoàn toàn tránh khỏi việc làm mọi thứ theo cách nhanh chóng và bẩn bựa trong một startup. Tuy nhiên, nếu bạn không trả nợ công nghệ đúng hạn, nợ cộng với 'lãi suất' tích lũy, làm cho việc thực hiện thay đổi sau này trở nên khó khăn hơn.

Dưới đây là bốn cách thông thường mà các startup tích tụ nợ công nghệ.

1. Hãy để tôi làm quen với khách hàng trước và tập trung vào lộ trình sản phẩm sau

Trong khi tùy chỉnh tính năng cho một sản phẩm để chiếm được khách hàng, các startup thường xem xét khả năng và thiết kế chung của sản phẩm. Họ không nhìn xa hơn những nhu cầu ban đầu, và do đó, họ xây dựng một sản phẩm không hữu ích cho một đối tượng lớn.

Ví dụ, tôi đã làm việc với một công ty đã xây dựng hai phiên bản của cùng một sản phẩm - một phiên bản được tùy chỉnh cho một khách hàng quan trọng, và phiên bản thứ hai là một sản phẩm chung. Công việc tùy chỉnh liên tục kéo dài trong suốt một năm. Điều này trở thành một ác mộng cho đội ngũ khi việc hợp nhất và ổn định sản phẩm đẩy đội ngũ quay lại 20 tháng về tổng số giờ làm việc.

Một sản phẩm không thể là đặc biệt cho từng khách hàng, nhưng việc triển khai có thể. Tuy nhiên, chủ doanh nghiệp thường bị quyến rũ bởi triển vọng ban đầu và thực hiện triển khai thay vì phát triển sản phẩm.

Yêu cầu từ khách hàng quan trọng thường xuyên buộc họ phải thêm các tính năng cần thiết vào sản phẩm một cách nhanh chóng. Trong thực tế, những đề xuất như vậy làm cho việc đàm phán về hạn chế thời gian trở nên khó khăn, dẫn đến việc các startup cắt giảm và đi tắt.

Trong hối hả để đáp ứng các hạn chế thời gian, họ không xem xét nền tảng như một toàn bộ và cách nó sẽ chứa đựng tất cả những thay đổi tùy chỉnh này sau này.

Các startup thường có khoảng 18 tháng để huy động vốn cho cấp độ tiếp theo. Vì vậy, chi tiêu hơn một phần tư vào việc làm lại sẽ làm chậm cơ hội của họ trong việc chuyển sang cấp độ gọi vốn tiếp theo.

Thêm các nhà phát triển mới vào đội để tăng tốc làm lại không phải là một lựa chọn khả thi. Ai đó từ bên ngoài có thể không hiểu đầy đủ về lý do và nội dung của dự án, và điều này có thể ảnh hưởng đến toàn bộ đội ngũ.

Bài học: Làm lại một sản phẩm để tổng hợp tính năng từ triển khai cụ thể cho khách hàng có thể mất một phần tư mỗi năm.

2. Sản phẩm của tôi ổn định, tại sao phải thay đổi?

Các startup thường trở nên tự mãn khi có đủ khách hàng trả tiền cho sản phẩm của họ trong một lĩnh vực cụ thể. Họ thường tận dụng lợi thế của người đi trước để có đà đầu tiên. Sau đó, đối thủ trực tiếp hoặc gián tiếp xuất hiện và bắt đầu xơi tái thị phần của họ.

Đây là lúc ổn định của kiến trúc, thiết kế, công nghệ, và phiên bản thường bị bỏ qua trong cuộc đua để thêm tính năng mới cho sản phẩm dựa trên doanh thu dự đoán.

Nhưng chỉ tập trung vào việc làm cho sản phẩm giàu tính năng có thể là một sai lầm. Quan trọng là phải hỏi liệu cơ sở có đủ tốt để chứa đựng những bổ sung tính năng mới hay không.

Đối với một sản phẩm phần mềm, cơ sở là công nghệ và kiến trúc. Cả hai đều không dễ biến đổi. Nếu gánh nặng của tính năng quá nặng, cơ sở có thể sụp đổ.

Cơ sở là điều làm cho quy mô trở nên có thể, hoặc không. Việc mở rộng sản phẩm không chỉ là về xử lý lượng; nó cũng đòi hỏi việc triển khai tính năng một cách nhanh chóng. Phiên bản nâng cấp của kiến trúc hoặc công nghệ là mảnh nhẹ, phù hợp hơn cho việc thêm tính năng và mang lại trải nghiệm tốt hơn. Ngoài ra, nhà phát triển không muốn làm việc với công nghệ lạc hậu, điều này ảnh hưởng đến năng suất và làm giảm tinh thần làm việc.

Một rào cản lớn khác ngăn chặn startup cập nhật công nghệ là ROI. Doanh nghiệp không muốn làm gián đoạn quy trình thông thường nếu lượng khách hàng trả tiền là đủ.

Tôi trải qua điều này trực tiếp khi đề xuất việc viết lại công nghệ cho một khách hàng. Đó là một công việc đòi hỏi từ 80-100 tháng lao động, và khách hàng không muốn chi tiêu thời gian đó để viết lại mã cho một sản phẩm ổn định đang tạo ra doanh thu liên tục.

Thật không may, công ty này hiện đang chi tiêu nhiều thời gian hơn cho việc làm lại và chiêu trò để duy trì sự ổn định của sản phẩm.

Bài học: Khi năng suất của đội giảm dưới mức chấp nhận được, việc áp dụng công nghệ mới giúp tăng tốc phát triển sản phẩm lên 2-3 lần.

3. Chúng tôi đã áp dụng công nghệ mã nguồn mở - nó đã được bảo đảm cho tương lai

Mã nguồn mở chắc chắn là một lựa chọn tốt cho các startup. Trong những ngày đầu, các startup lo lắng chủ yếu về sản phẩm của họ và ROI của nó. Điều này là tự nhiên vì một công ty ở giai đoạn này thường không có khách hàng trả tiền.

Một số công ty ở giai đoạn sớm thậm chí không có nhà đầu tư. Trong các hoàn cảnh như vậy, việc áp dụng biện pháp chi phí hiệu quả là một động thái dễ dự đoán.

Nhưng để sử dụng phần mềm mã nguồn mở, người ta phải liên tục nâng cấp lên phiên bản mới khi chúng phát hành. Bỏ qua một cái có thể không gây ra nhiều vấn đề, nhưng không nâng cấp hai hoặc ba phiên bản lớn có thể tạo ra một nợ công nghệ lớn, mà có thể mất một nỗ lực khổng lồ để giải quyết. Quá trình này có thể tiêu thụ nhiều tháng lao động với đội ngũ chuyên sâu.

Ví dụ, trong một dự án của tôi, khách hàng đã phải dành một đội ngũ phát triển trong bốn tháng để tích hợp các thay đổi để có thể nâng cấp. Điều này là một phần tư của cả năm tài chính - điều này đối với một startup có thể làm đổ vỡ giao dịch. Nếu công ty đã nâng cấp đúng hạn, họ chỉ phải đối mặt với một sự trễ hai tuần.

Tôi cũng đã thấy các dự án nơi những triển khai như vậy không khả thi. Trong một trường hợp như vậy, chúng tôi đang sử dụng framework Broadleaf Commerce cho một thị trường thương mại điện tử.

Để đền bù cho thiếu sót về tính năng, các nhà phát triển bắt đầu xây dựng chiêu trò để hỗ trợ tùy chỉnh cho framework. Khi các bản nâng cấp cho Broadleaf trở nên có sẵn, họ không dành thời gian cho nó.

Sau này, sau một số phiên bản lớn, việc nâng cấp trở nên không thể và công ty bị mắc kẹt với một framework không chuẩn với các bản vá. Kết quả là, đội ngũ dành nhiều thời gian thêm khả năng vào framework, những khả năng đó là một phần của các phiên bản bị bỏ lỡ.

Các công ty cập nhật phần mềm mã nguồn mở thường xuyên cũng có lợi ích ở những khía cạnh khác. Các framework mã nguồn mở được cập nhật đi kèm với nhiều tính năng tích hợp, miễn phí. Điều này giảm chi phí tổng dự án và giải phóng một lượng lớn công suất của nhà phát triển có thể được sử dụng để phát triển các tính năng cốt lõi khác.

Bài học: Chuyển đổi hơn hai phiên bản lớn của một framework mã nguồn mở đòi hỏi hơn 25% của băng thông hàng năm của toàn bộ đội.

4. Hãy đáp ứng nhu cầu ngay lập tức và tổ chức lại sản phẩm chỉ khi cần thiết

Trong một nỗ lực để chiếm lĩnh thị trường ban đầu hoặc đáp ứng nhu cầu kinh doanh ngày càng tăng, hầu hết các startup cố gắng đáp ứng nhu cầu ngay lập tức và tránh mọi chướng ngại. Bằng cách làm điều này, họ phớt lờ những thách thức công nghệ trong tương lai.

Lý do điều này xảy ra thường là do các nhóm kỹ thuật thường chỉ có tầm nhìn hạn chế về tương lai của một startup, điều quan trọng để đưa ra quyết định kiến trúc nhất định.

Nhưng ngay cả khi có tầm nhìn đầy đủ, bạn có thể phải tập trung hơn vào nhu cầu trung hạn xem xét ROI của việc triển khai các giải pháp phức tạp vào thời điểm đó.

Người lãnh đạo kỹ thuật nên có đầy đủ kiến thức về NFRs, ngay cả khi chọn giải pháp ngắn hạn. Quan trọng là dành thời gian riêng để xử lý nợ công nghệ mà NFRs có thể tích lũy lên.

Nếu nợ này không được thanh toán đúng hạn, nó sẽ làm destabilize kiến trúc dẫn đến việc tổ chức lại hoàn toàn. Việc tổ chức lại có vẻ là một quyết định dễ dàng, nhưng nó mất vài tháng, và tổ chức lại cùng lúc với việc phục vụ khách hàng hiện tại là một thách thức.

Để mô tả thêm về khía cạnh này, hãy để tôi chia sẻ một trải nghiệm thực tế khác. Một khách hàng đang tìm kiếm nhà đầu tư bán lẻ và họ đã xác định rõ thị trường họ muốn khám phá - đã giảm lượng dữ liệu họ cần lọc

Khi chúng tôi đang thực hiện xử lý theo lô, dữ liệu đã được rút gọn không ảnh hưởng đến chúng tôi. Nhưng với sự đầu tư đổ vào, công ty mở rộng từ một đơn vị khu vực và trở thành một người chơi quốc gia.

Một kết quả rõ ràng là tăng thêm lượng dữ liệu, làm cho quản lý xử lý theo lô trở nên khó khăn. Việc mở rộng nhanh để đáp ứng yêu cầu trở thành một vấn đề lớn. Nợ công nghệ kiểu này là tốt cho một kịch bản kinh doanh cụ thể, nhưng có thể kích hoạt sự hỗn loạn nếu chiến lược kinh doanh thay đổi.

Bài học: Hiểu rõ tầm nhìn cho sản phẩm và xác định Yêu cầu Phi Chức Năng (NFRs) trước sẽ tránh được việc cần tổ chức lại hoàn toàn.

Điểm chính

Số phận của các startup và nợ công nghệ liên quan chặt chẽ. Nếu các công ty giai đoạn đầu phớt lờ nợ công nghệ quá lâu, họ có thể đối mặt với thách thức lớn khi tổ chức lại sản phẩm với chi phí liên quan tăng theo thời gian. Hiện thực này sẽ ảnh hưởng đến kết quả kinh doanh cả về phát triển sản phẩm và ROI.

Mặc dù biết một số hiện thực nhưng nhiều startup vẫn thất bại trong việc quản lý nợ công nghệ trong sự vội vã để đạt được mốc tiếp theo. Việc xác định những thách thức trong tương lai và giữ cho startup của bạn sẵn sàng cho tương lai đòi hỏi kế hoạch, kỷ luật và nỗ lực liên tục.