在线看片,日韩av黑人影音先锋撸,韩国三级年轻的小婊孑,麻豆国产精品va在线观看约

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

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

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

不了解產品

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

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

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

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

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

假設即事實

決策是每個產品開發(fā)的核心部分。

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

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

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

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

缺乏溝通

溝通很重要。真的么?這句話你聽過多少次?天天說無數(shù)次。

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

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

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

關鍵要點是什么?

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

商業(yè)與技術語言的障礙

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

技術人員用技術術語，業(yè)務人員不明白;技術人員希望業(yè)務人員做出技術決策，但業(yè)務人員不知道如何做出決定，因為他們不了解技術觀點;商務人士用商業(yè)術語，技術人員不明白;業(yè)務人員試圖在不理解的情況下使用技術術語;在商業(yè)和技術中使用不同含義的相同詞匯。

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

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

錯誤 404：未找到上下文

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

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

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

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

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

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

團隊內部孤島

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

我們從產品的角度來看。

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

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

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

最后

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

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