是的，軟件開發絕不是在公園里散步。

       我們經常解決無法預見的問題，如果你不犯這些常見的軟件開發錯誤，許多問題是可以避免的。我將引導大家解決錯誤，這些錯誤可能會破壞自己的辛勤工作并使有前途的項目白白失敗！

       作為開發人員、分析師、產品負責人、主管或 CTO，我遇到過這些所有問題，盡管有些看起來很基礎，但它們仍然會傷害你的團隊。請與我深入了解～

       不了解產品

       為什么軟件開發如此令人興奮？對我來說，這是因為有機會學到很多行業的知識。通過引入該領域的項目來創造并塑造它們的未來。比如人們有機會在人力資源、醫療保健、金融和各種行業的產品上創造價值。

       雖然了解不同領域令人興奮，但也極其具有挑戰性。

       如果你渴望構建成功的產品，則必須了解其行業背景。對于我而言，軟件開發不是編碼，而是關于在盈利的同時為最終用戶尋找最佳解決方案。

       軟件工程師的關鍵要點是——了解業務核心和應該實現的每個功能。如果你只是一個聽命令的機器人，那開發可能是工作鏈條中最昂貴的部分，每個錯誤并不便宜。

       我相信技術咨詢和代碼審查任務是技術專家的附加價值，他們可以糾正最初雇用你的公司業務人員的錯誤觀點。而能夠交換意見是團隊相對于個人的最大優勢。

       假設即事實

       決策是每個產品開發的核心部分。

       很自然地，人們對以前的項目和假設看法會發揮作用。請注意這些問題，猜測比詢問別人更簡單，但它很危險！如果你碰巧做對了，那么幸運的，但如果不是，在開發周期的后期如果出現問題，那將會付出很昂貴的代價。

       如何避免這種悲傷但常見問題呢？

       與你的團隊保持聯系，互相支持。如果你處理一個超級復雜的問題并且無法就最終結果達成一致，請咨詢或準備一個小型實踐。

       咨詢該領域的專家或用戶可以對這件事有新的認識。假設和實驗特征的結果非常適合收集反饋，它允許人們實現一個可能是錯誤的行為，但已經具有驗證其正確性的機制。該機制可能是一個指標、一項調查、一個關于該功能的實驗性質的可預見警告，包括獲取用戶反饋的簡單方法，然后由你和團隊為特定假設選擇最優機制。

       缺乏溝通

       溝通很重要。真的么？這句話你聽過多少次？天天說無數次。

       然而在與各種規模和性質的團隊合作后，這仍是一個問題。而創建一個沒有人害怕發言的安全開放的環境，是避免無聲的積壓改進、制定毫無意義的沖刺計劃和漫無目的的每日 Scrum 會議最行之有效的方法。

       如果您想要的不僅僅是將項目從一列移動到另一列，請找到一位能幫助您指導開發的導師。比如你遵循 Scrum 框架但沒有 Scrum Master，則應該去找一個。就像足球運動員不會在沒有教練的情況下比賽。

       當你意外發現只有 10% 的后端為你剛剛完成的新 FE 功能做好了準備，或者實現的 API 調整不兼容時，去專注于溝通吧，它可以避免你在 sprint 結束時有意外驚喜。

       關鍵要點是什么？

       建立團隊精神，讓人們喜歡彼此分享想法，如果覺得溝通太困難，請找一位 Scrum Master 或教練來簡化整體流程。

       商業與技術語言的障礙

       相互理解是有效團隊的基石。軟件開發將兩個通常不知道如何溝通的世界結合在一起。以下是一些事情向南而失去意義的例子：

       是不是很熟悉？如果想誠實地交流，而不是假裝交流，請了解您的聽眾并使用他們理解的詞語。

       從上下文開始，概述問題，提出解決方案，解釋結果，提供示例，并確保你的聽眾完全理解。

       錯誤 404：未找到上下文

       假設為功能準備新需求。你可以簡單地描述該功能應該做什么，為什么重要，以及它將如何讓它更接近目標。

       或者，您可以概述從 A 到 Z 的所有內容，而一點沒有討論的余地。哪一個更好？我相信大多數開發人員會更喜歡第一種方法。

       新需求是討論的起點，而不是最終作業。因此，產品負責人應該始終從上下文描述和反饋收集開始。了解問題及其背景的團隊成員更有可能提出更好的想法。讓開發人員按照所寫的內容精確地編程會浪費工程師們的潛力，并會導致誤解。

       “為什么的問題”不是不信任或攻擊性的表現，而是興趣的表現，它是區分成功團隊和不成功團隊的關鍵。

       是什么讓產品負責人重蹈覆轍？時間壓力是一個答案，但不能成為借口。有時需求完成得太晚了，開發人員的反饋沒有空間。設計已完成，文檔已編寫。在這種情況下，停止并丟棄需求可能具有挑戰性，但如果您沒有找到原因的答案，這仍然是值得的。

       一些資源被浪費了，但許多資源被節省了，所以這里的教訓是——盡快共同參與并從為什么開始。

       團隊內部孤島

       你的團隊由后端、Web、移動、業務或測試人員的不同孤島組成。你需要所有這些都有意義地進行，沒有人可以做所有的事情。每個氣泡或筒倉都應該有自己的沖刺目標嗎？

       我們從產品的角度來看。

       從一個項目開始，項目和用戶故事都不應該被孤島隔開。他們不應該指定哪個倉可以完成這項工作。重要的是為 sprint 評審提供一個可交付部分——最終用戶可用的東西。

       如果團隊經常無法在一個 sprint 中交付完整功能，要么是 backlog 項太大，要么是團隊結構錯誤，要么是 sprint 太短。讓孤島合作來改進工作流程，永遠不要將孤島分配給順序沖刺，讓它們相互等待

       積極主動，走出孤島，從一開始就精誠合作，調整流程并盡可能實現自動化。

       最后

       當然，沒有硬技能就不可能編碼。無論您處于什么職位，合作、溝通或演說技巧等軟技能將決定將項目推進何種成功程度。優秀的公司不會尋找能夠勝任工作的人士，而是尋找能夠提供附加值的人才。

       合作，理解他人，永遠追求最好！

       本文由培訓無憂網長沙牛耳教育課程顧問老師整理發布，希望能夠對想在長沙參加影視動漫培訓的學生有所幫助。更多課程信息可關注培訓無憂網電腦IT培訓頻道或添加老師微信：15033336050

      注：尊重原創文章,轉載請注明出處和鏈接 http://m.hebeijilong.cn/news-id-13968.html 違者必究！部分文章來源于網絡由培訓無憂網編輯部人員整理發布,內容真實性請自行核實或聯系我們，了解更多相關資訊請關注程序開發頻道查看更多，了解相關專業課程信息您可在線咨詢也可免費申請試課。關注官方微信了解更多：150 3333 6050