工程責任

傳統上，工程師的主要職責是設計產品，為了形狀、適合和功能。目前為止運作得很好，或者更好，對吧？那麼，這取決於你如何看待它。今天有相當大規模的組織回報超過最後期限，延遲項目或完全取消項目。

產品正在改變，這給行業帶來了新的挑戰。形成了機械化程度越來越低，計算機化也越來越多。傳統硬體正處於次要地位，更多的電子產品正在湧入。隨著產品變得越來越複雜，工程師必須找到新的方法，在更短的時間內提供高品質的產品。”敏捷”是實現這一目標的一種方法。定義敏捷的特性是任務從當天到隔天的分配以及資源的分配。強調個人的責任，這就是我們將在這篇文章中討論的內容。

傳統的硬體設計方法

工程一直是個人責任感高的行業。例如，工程師在圖紙和藍圖上簽名，表示他們對設計的認可。如果出現問題，組織會知道該從哪裡排除故障。工程師可以為他們的決定辯護。

但這種長期的責任文化正在開始轉變。這是產品變得更智能和更多連接的另一個結果。隨著這些項目中電氣硬體和軟體的增加，主要工程師與專業工程師一起研究設計備選方案。這種複雜性的產品需要更多的協作。很少有工程師擁有自主制定設計決策所必需的機械、電氣和軟體學科專業知識。

增加協作不僅僅發生在工程師之間。這些工程師有機會在整個開發過程中與非工程利益相關者合作。除了產品的功能之外，還有更多要考慮的問題。還必須考慮定價，可製造性和服務程序等事項。雖然這些因素不屬於工程領域，但它們確實影響了產品設計。所有這些部分必須結合在一起，以創造最好的設備。

在過去，工程師有責任獨自承擔更多的責任。當一位工程師簽下一張圖紙時，他們的名譽就在案子上。如果事情沒有按計劃進行，那麼管理人員和管理人員就會來找那個工程師，從而導致很多保守的設計決策。沒人想把不完善的產品歸咎於此。而不是嘗試更具創新性的東西，最好是安全地玩。

硬體設計的快速方法

工程管理人員知道，他們過去用於機械導向的項目管理方法對於智能互聯產品而言效率不高。他們需要更快速和彈性的開發流程。需要增強團隊的努力。敏捷專注於提高合作，以在更短的時間內完成任務。

敏捷是一種項目管理方法，最初朝向軟體開發，但越來越多邁向硬體開發。它忽略了“一個人做一件工作”的心態，更加注重在團隊上的方法。它也從一般的文檔轉向，進行更多的面對面互動。

隨著這種合作的增長，今天的工程師們承擔了新的責任。他們的任務需要更多的軟技術，包括有效影響他人的社交技巧和習慣。在敏捷途徑中，沒有人“擁有”設計的任何部分，因為一切都是共同努力。在敏捷中，有個叫做衝刺的時期（通常是兩週），每個人都在努力完成一套既定的目標。Scrum是此過程的框架。Scrum Master是負責分配任務，截止日期以及誰負責任務的人。

在Scrum中，可能會有一個人被指派在某一天的某個產品上工作，然後在第二天被分配到不同的東西。每日會議審查已完成的任務以及仍未完成的任務。如果一項任務需要更多的關注，Scrum Master可以重新分配資源。雖然個人責任較少，但作為一個團隊仍然存在責任制。

這種新方法允許更大的彈性、適應性和速度。如果需要，重新分配工作要容易得多。Agile系統佔用的時間更少，並使團隊能夠在整個產品開發過程中執行更頻繁的檢查。它不僅對工程師有用，對客戶也有用。更頻繁的檢查意味著使客戶端在循環中進行新的變動。工程師可以在一開始收到反饋並進行調整，而不是等到最後一刻才改變方向。當不同的人輪流完成各種任務時，它為新的觀點和想法留下了空間。一副新鮮的眼睛可以提供不同的解決方案或者補捉其他人沒有做過的錯誤。

摘要

隨著產品的不斷變化，工程師的工作也在不斷變化。公司必須找到新的方法來保持競爭優勢，這意味著改變開發過程。將一項任務分配給一個人可能在過去是有效果的，但它已無法適用。組織需要能夠快速適應並展示彈性。敏捷的這個合作架構可以幫助提高產品開發效率。