在開發應用程序和網站的印度小型軟件公司中增加技術債務：誰負責？

我已經在印度軟件服務行業工作了 10 年，在那段時間裡，我見證了優秀的項目完成並創造了奇蹟。 我見過骨幹團隊在痛苦的條件下不知疲倦地工作，以製造出受到地球另一端人們喜愛的產品。 雖然在這十年中從事一些了不起的項目有很多美好的回憶，但我也目睹了項目走下坡路，軟件產品由於各種原因而變得一團糟。 它發生的次數比我希望在我周圍和我這 10 年來認識的人周圍發生的次數要多。

很多人都在談論項目出錯。 這些模因在互聯網上充斥著整個等級制度如何像叢林中的食物鏈一樣相互追逐。 有些人責怪程序員寫了錯誤的代碼，而另一些人則詛咒管理層做出了無法實現的不切實際的承諾。 有些人甚至指責客戶不了解這個行業的技術先決條件和依賴關係。 但我幾乎沒有聽到有人談論技術債務或代碼債務，並且以文明的方式處理這個問題，而不是互相指責。 我從來沒有從我周圍的人、我參加的活動或我閱讀的本地博客中聽到這個術語。

我是在閱讀美國矽谷的博客和期刊時才知道這個詞的。 這意味著大多數在印度中小型軟件開發公司工作的程序員和軟件主管直到現在才聽說過這個詞。 所以，讓我先解釋一下這個詞本身。 技術債務或代碼債務是軟件開發中的一個概念，它反映了由於現在選擇簡單（有限）解決方案而不是使用需要更長時間的更好方法而導致的額外返工的隱含成本。

讓我分解它以使其簡單。 這是一個計算解決編程和設計問題的成本的概念，這些問題可能會因為選擇構建特定模塊或整個系統的簡單選項而不是選擇構建它的最佳和最有效的方法而增加。 在軟件開發領域，這種你的懶惰和遲到又咬你屁股的現像比其他任何地方都更頻繁地發生。 這幾乎就像 Karma 得到了程序員討厭的社會表徵。

請不要誤解我，我並不是將所有代碼債務都歸咎於程序員。 在印度的小型軟件開發公司中，90% 以上的項目肯定會出現代碼債務，肯定有多個實體負責。 讓我嘗試簡要介紹其中的一些：

1. 不耐煩和過於聰明的客戶

是的，我會從咬那隻餵食的手開始，並且無情地這樣做。 小型外包軟件開發項目市場巨大且高度分散。 有一些真正優秀的公司可以完美地證明這個全球化市場的合理性，而另一些只是寄生公司，他們以這種完美的安排為食，只是因為它不受監管和不受控制。

這導致客戶在根據自己的需求選擇合適的公司合作時犯了錯誤。 雖然沒有適當的審查技能不是他們的錯，但沒有人可以責怪他們沒有基本的街頭智慧來識別垃圾公司和真正的垃圾公司。 現在，一旦他們同意與一支天賦不足的團隊合作，他們就會扼殺他們不切實際的期望和時間表。 不僅如此，他們中的一些人甚至通過在設計和編程中提出自己的建議來展示他們的聰明程度。 （#notallclients ）

如果您曾經是軟件開發公司的客戶，我謙虛地請求您讓他們成為客戶並讓他們完成他們的工作。 試著去看醫生或律師，告訴他們你在谷歌上搜索了什麼以及它對你的問題的看法，看看他們臉上的反應。 沒有哪個領域的專家喜歡被菜鳥推薦他們自己的領域。 軟件工程師也不例外。

如果你找到了一個優秀的軟件開發團隊並且他們看起來很有希望，給他們空間，他們就不會有偷工減料的衝動，這會減少你項目中的代碼債務。 猜猜看，大多數時候，是你們，支付代碼債務的客戶。 聽說過“變更請求”這個詞嗎？ 我敢打賭你們大多數人都有！ 在理想情況下，你不應該在你的生活中聽到這些話。 但這種情況很少發生。 你聽到這些話的次數越多，作為軟件公司的客戶，你就越搞砸了。

2. 懶惰和狡猾的經理

當我在這裡說經理時，指的是軟件開發公司方面擔任項目管理職位的任何人。 無論是項目經理、團隊負責人、交付負責人還是公司老闆，如果您曾經試圖快速洗手項目只是為了結束它並收取您的付款，那麼您就是派對也應歸咎於您項目中的大量技術債務。

儘管這裡最可悲的部分是你們永遠不會支付巨額的技術債務。 要么是客戶通過使用不合格的產品來支付費用，要么是實際支付更多的錢來清潔它。 如果不是客戶，那就是可憐的程序員為此付出了代價，他們不得不無休止地工作，超出了他們的要求。 但幾乎​​從來都不是這些中間人，因此根據我的說法，他們應該是這個技術債務主題中最負責任的實體。

如果你曾經僱用他們中的一個，他們應該具備的最大品質就是道德。 如果他們的道德指南針指向正確的方向，他們將承擔責任並做出有利於該項目的正確決定，這最終將導致更少的技術債務積累。 這讓我想起了馬雲的那句名言，他談到選擇為合適的領導者工作。 非常適合這裡的這種情況。

3. 程序員

哦，是的，我也不會通過責備你們來結束這個話題！ 但是，嘿，#notallprogrammers 對嗎？ 嗯，是的，但幾乎 94% 的程序員。 至少 Tech Mahindra 的首席執行官 CP Gurani 是這麼認為的，幾年前他做出了令人震驚的發現，即 94% 的 IT 畢業生不適合這份工作。 我不知道他究竟是如何得出這個數字的，但作為印度工程學院的產物，並且在過去 10 年見證了整個 IT 工程生態系統，我可以說我傾向於同意 Gurani 先生所說的。

我不想爭論它是 94%、90% 還是 80%。 但是打個比方，就像我們幾乎所有人都知道我們需要麵粉、水和一小撮鹽來製作麵團，以及擀麵杖來製作薄煎餅。 但我們中很少有人能真正製作可食用的薄煎餅。 這是一個非常簡單的過程，但仍然需要一定的天賦和大量的練習才能在這方面表現出色。 編程也是如此。 我們所有人都知道這個食譜，但很少有人真正捲起袖子，弄髒我們的手並練習它，只要它需要掌握這門手藝。

因此，即使一個普通的程序員被委託進行一個項目，他也會在不知不覺中編寫代碼，其中嵌入了技術債務，直到後來他才意識到。 如果你想知道整個行業如何在大多數程序員不適合這份工作的情況下發揮積極作用，那是因為他們高效的經理和經驗豐富的前輩通過艱難的方式學到了東西。 他們幫助那些新手和頭腦在編寫最佳代碼的危險道路上導航，使項目的交付可行，並使其免於沉重的債務。 最終，通過適當的修飾和培訓，讓這些新手變得擅長他們的工作，或者他們最終與 IT 行業告別。

所以，總而言之，我覺得這次合作中的所有 3 個主要方面都應為編譯代碼債務分擔責任。 再說一次，不要把這篇文章當作對行業所有問題的批評。 它就像世界上任何其他行業一樣，有著相當多的恐怖和英雄。 即使在這樣做了 10 年後，我仍然不會用我的生命做任何其他事情。 我喜歡這份工作，我喜歡成為一家致力於來自全球客戶的令人興奮的項目的小公司。

其目的是讓所有 3 個利益相關者承擔更多責任，並讓他們了解這種潛在的軟損失，這種損失是由於合作不當而對他們造成的。 如果軟件開發團隊希望準確計算和衡量他們的技術債務，他們可以遵循基於敏捷方法甚至瀑布方法的嚴格流程模型。 當您遵循這種嚴格的方法時，您將能夠分別標記這些修訂和修復衝刺，並且在一個階段結束時，您將能夠準確計算出您需要多少，並輕鬆進入原因。

我將以塞繆爾·貝克特 (Samuel Beckett) 的這句話作為結束語：