Cách xác định Tech Debt vs. Product Debt vs. Business Debt

Bài viết gốc: https://medium.com/big-on-development/how-to-address-tech-debt-vs-product-debt-vs-business-debt-42d43d5f768c

Tác giả: Julius Uy - Chief Technology Officer at ZilLearn

Ngày xửa ngày xưa, trong một hang động đầy các software engineers, trong không khí vang vang tiếng phàn nàn "Product manager chẳng bao giờ quan tâm đến tech debt cả, họ nghĩ có 9 bà mẹ thì có thể đẻ ra một đứa bé trong 1 tháng à." Những Engineers buộc phải vá víu đủ thứ khi mà các tính năng mới của sản phẩm đến liên tục và các Engineers tội nghiệp không có quyền năng để tuyên bố dừng lại và sửa chữa các lỗ hổng trên sản phẩm. Với cách làm việc ấy, tổng thể sản phẩm như một cái xô nước với chằng chịt lỗ rò rỉ, và rồi di sản họ để lại cho thế hệ Engineers tiếp theo là khối tài sản dirty code, công ty chật vật với việc giữ cho kiến thức không bị mất đi, kéo theo việc dành càng ngày càng nhiều tài nguyên hơn để giữ cho sản phẩm chạy trong hấp hối thay vì chết hoàn toàn.

Cùng lúc đó, cũng giống như các Engineers phàn nàn về các Product managers, vùng đất còn tồn tại một hang động khác với đầy các PM. Họ vung vẩy vẽ vời thứ ma thuật của mình để xoa dịu những vị thần của họ:  VP of Sales, Head of Business Development, và the Head of Strategic Partnerships. Trên cả ba vị thần ấy là chúa tể tối cao, the CEO. Tất cả PM cùng đồng thanh:"Chúng ta sẽ không thể nào có MVP khi các vị thần luôn muốn mọi yêu cầu của họ đều phải được đáp ứng vào hôm qua. Và khi tất cả mọi thứ đều ưu tiên cao, thì chẳng có gì được ưu tiên cả!!" "Họ cũng chưa làm xong việc" các PM vừa nói vừa chỉ vào bức tranh của các Engineers. Bọn chuột trong phòng lab đang than phiền không ngớt về cách các Interservice giao tiếp, về các luồng dữ liệu đang chạy loạn xạ, cả việc OAuth implementation nữa,  rằng chất lượng của chúng đều tệ và cần sửa chữa. Mặc dù khách hàng vẫn có thể đăng nhập và có thể sử dụng các tính năng. Tại sao họ lại không hiểu nhỉ? Giá như chúng hiểu về cuộc sống của một PM, có lẽ chúng sẽ không phàn nàn về những điều này nữa.

Và trên đỉnh Olympus, vùng đất của các vị thần. The CEO nhìn xuống những PM và Engineers trách móc "Tại sao chúng lại chậm thế? Ta đang mất dần những cơ hội kinh doanh chỉ bởi vì chúng muốn xây dựng một cung điện có tất cả mọi thứ, trong khi cái ta cần chỉ là một cái lều để kiếm đủ tiền cho vòng phát triển sản phẩm tiếp theo."¹

Nếu bạn thấy mình trong câu chuyện trên thì chúc mừng! Bạn đang làm việc cho một công ty công nghệ đấy.

Tất cả đều thật, mỗi vị trí trong một công ty đều có những pain points của mình². Bên cạnh việc các phòng ban có vẻ không quan tâm lắm đến vấn đề của phòng ban khác thì Thật ra mọi người đều đi làm để hướng về điều tốt đẹp. Do đó, nếu mọi người đang làm tốt công việc của mình thì họ cũng đồng thời phàn nàn về người khác, vấn đề nằm ở giao tiếp (cụ thể hơn đó là sự đứt gãy trong việc giao tiếp với nhau)

Nội bộ công ty càng liên kết,  càng ít xuất hiện những phàn nàn như trên. Những ai đã từng trải qua các công ty start up với core team chỉ tầm 5 người sẽ rõ về điều này hơn ai hết. Lúc này hầu như chẳng có vấn đề gì trong giao tiếp, tất cả mọi người đều dễ dàng đi cùng một hướng vì tất cả mọi thứ đều được truyền đạt dễ dàng.

Các Engineers luôn thích những kỹ thuật tiên tiến. Một câu đùa phổ biến là các Engineers đang viết những dòng code lỗi thời của ngày mai trong ngày hôm nay. Tôi đã viết ở đây và nghĩ nó cũng đúng ở bất cứ đâu rằng , nếu công ty của bạn sẽ phá sản trong 6 tuần nữa, thì việc chuyển đổi từ Android Java code đã cũ sang ngôn ngữ Kotlin hiện đại hơn chẳng giúp được gì cho bạn, bất kể những bị thần đến từ Google có nói gì với bạn đi chăng nữa. Như Peter Cohan đã nhắc đi nhắc lại trong cuốn Scaling Your Startup, Cái công ty cần là chạy nước rút để có thanh khoản. Có nghĩa, công ty cần phải đạt được điểm mà nó có đủ dòng tiền để đầu tư vào các phát triển trong tương lai. Và nhiều lần tôi thấy các engineers ở cấp giám đốc hay VP không hiểu vấn đề này.

Bên cạnh đó, Có một nghiên cứu thú vị chỉ ra rằng những người thuộc type ENTP và  ESTP thường có xu hướng thể hiện hành vi thái nhân cách cao hơn bình thường. (Tôi không có ý công kích. Đây chỉ là một kết quả nghiên cứu. Và thật ra để có được thế giới ngày hôm nay những người loại này có đóng góp không nhỏ)

Hai loại nhân cách này rất gần với các doanh. Họ rất khó để thương lượng vì họ thường rất tự tin kết hợp với khả năng tranh luận giỏi và cả hay bác bỏ. Trong khi những loại nhân cách này có xu hướng thiếu kiên nhẫn và nóng nảy thì họ cũng thường thông minh hơn những người khác. Họ giỏi trong việc hoạch định các high level concept nhưng cũng thường xem nhẹ các rủi ro của công ty. Nói cách khác, họ rất giỏi thuyết phục các nhà đầu tư và tăng lòng tin khách hàng nhưng lại gặp bất lợi trong việc phân tích chi tiết.

Đương nhiên,  việc này dễ dẫn tới bất đồng trong giao tiếp. Khi bạn làm những việc tốt cho công ty theo cách bạn nghĩ nhưng lại có một CEO không đễ cộng tác thì thường bạn sẽ tìm cách làm sau lưng anh ta, và hậu quả vòng xoáy tiêu cực sẽ lặp đi lặp lại cho đến khi công ty sụp đổ.³

Và những Product manager, những chiến binh trong cuộc chiến "Trách nhiệm vĩ đại đi kèm với không quyền lực". Lo sợ mình trở thành kẻ ngốc trong mắt  CEO và các Engineers, thường đem tới một Roadmap đẹp đẽ thứ cũng thường không thể hiện thực được vì hàng loạt các cản trở vẫn đang tồn tại trong công ty.

Hãy lưu ý rằng việc sửa lỗi về Tech thường có chi phí rẻ hơn sửa các lỗi liên quan đến sản phẩm. Một lỗi phần mềm có thể sửa trong vài tiếng. Một lỗi sản phẩm thường tốn cả tháng. Trách nhiệm của các PM thường cao hơn các Engineer.

Một cách dễ hiểu thì, tech debts là những thứ làm chậm quá trình development. Product debts là những thứ làm funnel AARRR  kém hiệu quả. Các công ty thường giải quyết các "khoản nợ" này như thế nào? Thường chúng sẽ được giải quyết bằng việc alignment và làm việc này thường xuyên. Nếu việc kinh doanh thất bại có nghĩa tất cả sẽ thất bại. Thú vị thay tất cả  tech debt và product debt đều là business debts. Từng vấn đề đến từ team engineers và product managers đều là vấn đề của doanh nghiệp. Nên nếu ai đó đang kêu gọi việc giải quyết các tech debt và product debt, anh ta hoàn toàn có thể đưa chúng về business debt sau đó sắp xếp độ ưu tiên từ cao đến thấp để giải quyết. Về mặt bản chất, mọi thứ nên được cân nhắc như business debt.

Một ví dụ, nếu tôi cần chuyển đổi code từ Java sang Kotlin, tôi cần phải đưa ra được impact của việc thay đổi này mang lại. Như hầu hết các ước tính, một dự đoán thông minh là đủ tốt.⁴ Giả sử ước tính của tôi việc chuyển đổi này sẽ tốn 50,000$ mỗi tháng trong 6 tháng tiếp theo nhưng sẽ tiết kiệm được 100,000$ cho mỗi tháng kể từ tháng thứ 7 thì sẽ rất dễ dàng để người ra quyết định chọn lựa giữa các đề xuất khác.

Nhìn chung, bạn có thể đánh ưu tiên dựa trên Impact vs. Effort. Những thứ đem đến Impact cao với  effort thấp (cost thấp), hãy làm chúng đầu tiên và đánh ưu tiên cho những thứ khác theo đó. ⁵

Những thảo luận sâu hơn nên được viết trong các bài viết khác mà tôi tin rằng cũng đã được viết ở đâu đó. Do đó, tôi sẽ kết ở đây. Chúc các bạn lạm việc chung vui vẻ!

Nếu bạn thích bài viếc này, tôi sẵn lòng kết nối qua LinkedIn. Tôi cũng đang vận hàng một tổ chức phi lợi nhuận tên Big O(n) Development.

___

¹ Bạn cũng có hang của những người vô thần, dẫn dắt bới  VP of Operations, những người chửi rủa cả CEO, PM và Engineers vì xây dựng những sản phẩm không ra đâu

² Nếu có người trong số họ không cảm thấy đau đớn, chắc chắn có gì đó sai ở đây!

³ Để làm rõ, có các tính cách đặc trương cho Engineers và  Product Managers nữa. Họ cũng có những yếu điểm của riêng mình (và nhìn chung, phải được loại bỏ, Nếu bạn cần đi nhanh, bạn cần dọn dẹp những thứ ngăn cản bạn)

⁴ Take note: intelligent guess.

⁵Dĩ nhiên, trong các công ty lớn, bạn sẽ luôn có những giám đốc điều hành với nhiều năm kinh nghiệm, người có tên đc viết chữ vàng trên nền đỏ mà bạn không có lựa chọn nào khác ngoài việc nghe theo yêu cầu của họ (vì nhiều khi họ sẽ nổi cơn thịnh nộ và nó sẽ làm bạn trả giá đắt).