專案管理的三角形是乙個眾所周知的模型 ，自古以來一直使用。
我假設大多數軟體開發人員，甚至是初級的軟體開發人員，都對它們熟悉：
就我在軟體行業的個人經驗而言，所有專案都落後於計畫，只有少數幾個例外（小型工時）。 原因可能是由於偶然或有意的初步估計值太低，但這是在另一篇文章中最好解決的主題。
現在，還向專案經理介紹了專案管理的三角形。 該圖背後的想法是，當事情開始惡化時，在乙個或多個邊緣中，乙個必須在另乙個邊緣上進行權衡。 例如，當專案的進度落後於進度時，可能會縮小範圍以保持進度。
但是，以上三角形是錯誤的-或至少是不完整的。 實際模型應如下所示：
很少顯示該版本的模型，而且質量很難定義，難以衡量並且在大多數儀表板中都不會出現。 本質上，當日程安排緊張和/或成本開始超支時，再也沒有人關心質量了（如果有人以前做過）。 這是現在和現在分娩的死亡之路，沒有任何障礙。
我寫了很難定義質量。 即使對於軟體工程師也是如此。 即使廣泛接受的度量標準（例如**覆蓋率）也沒有意義。 然而，程式設計師普遍承認缺乏質量：看似簡單的功能需要花很多時間才能開發出來，因為現有**是一團糟，或者沒有/沒有足夠的測試，或者...（在這裡插入您最喜歡的）。
因為儘管軟體工程師不但謠言四處傳播，而且不僅有創造力的人而且還有交流的人，所以他們提出了技術債務的概念：
技術債務（也稱為設計債務或**債務）是「程式設計中的乙個概念，反映了當使用短期內易於實現的**而不是應用最佳的整體解決方案時出現的額外開發工作」。—維基百科技術債務可以與貨幣債務進行比較。 如果不償還技術債務，它會積累「利息」，從而使以後更難以實施更改。 未解決的技術債務增加了軟體熵。
那真是天才！ 即使對**，軟體開發和軟體質量一無所知的人也可以理解財務基礎知識。 如果您欠下軟體大銀行（great bank of software）的債，那您得稍後償還債務...加利息。
但是，由於一種非常持久的趨勢孤島 ，恐怕與以前的情況相比，此想法僅具有邊際收益。 想一想組織的工作原理：當乙個想法形成時，它就會轉化為具有專用預算的專案。 要指導專案的是專案經理。 現在，如果專案成功（是的，它確實發生了），則該應用程式將成為資產組合的一部分，並被視為產品。 它被分配了乙個產品負責人，在大多數情況下，他與專案經理不是同乙個人。 用外行的術語來說，專案經理要承擔債務並向下乙個專案留出款項，而產品負責人則必須償還債務！
po的「有趣」發展是繼續承擔技術債務以降低維護成本，從而改善其職業發展道路，盡快獲得晉公升，並將責任推給生產線中的下乙個可憐的樹液。
在這個一切，專案，部門，資訊系統，預算以及當然還有責任的孤島時代，即使每個人都可以理解技術債務，許多人還是選擇不關心它，而讓下乙個人來處理他們在其中遇到的問題。第一名。
當然，它並非特定於軟體，因為不幸的是政治人物每天都在證明這一點...
翻譯自:
技術債務？管理債務？
昨天晚上重要客戶再次投訴。這已經是最近幾個月的第三次投訴了！當年為了爭客戶，給客戶迅速開發了跨越三個系統的定製需求。客戶爭到了，這個快速的定製需求就一直當正式工具被用起來。這是第三年了，這個定製功能一直在找麻煩，甚至有可能丟到客戶。昨天晚上是因為其中的乙個系統切換到備份，但是其他系統不認識備份系統的...
解析技術債務
原文 術語 技術債務 是由ward cunningham 首次提出，指的是開發團隊在設計或架構選型時從短期效應的角度選擇了乙個易於實現的方案，但從長遠來看，這種方案會帶來更消極的影響，亦即開發團隊所欠的債務。敏捷專家們就技術債務到底是什麼以及如何對其進行分類給出了自己的看法。martin fowle...
解析技術債務
原文 術語 技術債務 是由ward cunningham 首次提出，指的是開發團隊在設計或架構選型時從短期效應的角度選擇了乙個易於實現的方案，但從長遠來看，這種方案會帶來更消極的影響，亦即開發團隊所欠的債務。敏捷專家們就技術債務到底是什麼以及如何對其進行分類給出了自己的看法。martin fowle...