軟體開發專案無疑是專案管理中最具風險的學科之一，天然會受到大量變更和不確定性的威脅，事實證明的確如此，我們的平均成功率低於其他更「確定」的業務領域。
我在這裡要向讀者們推薦一下chaos年度報告，自90年代中期以來這份研究報告在該領域就享有盛譽，它基於乙個資料庫，包含了20多年來收集的數千個各種型別和規模的專案。儘管圍繞它的方**有一些爭論，但是這個報告仍能顯示軟體專案的結果是多少糟糕。
偉大的行業思想家已經在努力提公升工具、技術、過程和方法，以應對這一行業症狀，特別是自從電子時代演變到目前數字革命的洪流以來，面臨的挑戰越來越大。我們都在努力追趕這些技術進步，以改善我們的結果。
然而，一場轟轟烈烈過後，我們在管理軟體專案時仍然經常忽略一些通常不為人知的實踐。它們之所以被忽視，可能是因為總把自己置身於技術或系統工程方面的實踐之中，而沒有過多地涉及理論。然而，它們是一種實際和實用的方式，除了承擔起構建軟體應用程式的繁重任務，還可以顯著提高我們的成功率。
因此，我們在這裡討論的主要受眾是所有領導軟體專案的人。順便說一下，我們的討論和方**無關，只是在所做的事情中會保留一些敏捷風格。因此，讀者可以遵循你們在開發過程中採用的特定方**。
當你看到這個標題的時候，不要怕，不用縮回到防空洞裡，這裡沒有槍炮硝煙！
然而，軟體交付和戰爭之間逐步發展出了許多相似之處：在某種程度上兩者都涉及到某種「戰鬥」。在戰爭中，對抗的是敵人。在軟體中，對抗的是「失敗」，而「失敗」是任何業務的敵人。
至少，中國古代兵聖、軍事家孫子的《孫子兵法》和普魯士將軍、軍事思想家克勞塞維茨的《戰爭論》這兩部偉大的戰爭著作，在處理商業衝突和關係方面，給商人們帶來了許多策略上的啟發。
現在，我們這些軟體人員正在為成功而戰，就像軍隊為勝利而戰一樣，我們將利用其相似之處，從戰爭中借鑑三個主要的概念，以贏得我們與失敗的戰鬥。
讓我們看看這些訣竅吧。
客戶不是敵人，專案也不是天生就有衝突的，但是為了對客戶展開「友好」的攻勢，您需要充分了解他的領域和能力。這種預先的了解就是我們所說的專案情報。
這得先偵察一下。你永遠也別把它當作間諜任務，這只是乙個道德問題，只是深入觀察客戶自然流露給我們的東西。但誰會成為「耳目」為你做這件事呢?先看看周圍環境吧。
銷售和售前是贏得新合同的先頭部隊。為取得勝利，他們會花一些時間建立客戶關係，了解人和事，努力去實現目標：簽訂合同。通過這種方式，他們可以接觸到相當多的資訊，不僅是純粹商業相關的，還有關於新戰線商業政策的，以及它的弱點和優點。
因此，如果簽約了合同，銷售和售前情報收集人員就過早地脫離專案，直接丟給實施團隊，而沒有充分利用他們對客戶「領域」的了解帶給團隊幫助，就是重大的損失。
我一直認為，從銷售/售前到專案經理和業務分析師的深度「交接」是團隊協作的良好跡象，也是安全進入專案的乙個非常有價值的工具。這個子流程實際上是合同簽訂前的乙個情報任務，銷售團隊必須好好利用這個任務，為專案管理和團隊提供盡可能多的有用資訊，這些資訊主要有以下四個維度：
通過這種方式，專案經理可以預見實現過程中可能遇到的風險和障礙，從而更好地規劃以減輕這些風險和障礙。至於需求方面，雖然這個資訊仍然有點粗糙，但收集到的資訊將讓分析師能更清晰規劃滿足需求的最佳方式，基於更多的了解去完成他的任務，使他的工作可以事半功倍。
看起來這似乎更多地關乎專案的「進度」，而不是專案的「質量和價值」。但事實上，專案情報對這兩方面都有影響，質量和進度都是一樣的。適當的情報工作可以避免專案上的「噪音」，這些噪音來自與錯誤的人的交流，或容忍了客戶方未經授權的決定。專案雜訊是事情含糊不清的源頭，使開發過程不斷地出現返工的情況，直接影響進度。另一方面，錯綜複雜的整體情況會影響團隊的士氣和對任務的專注力，降低產品的質量和價值。
所以，您可以很容易得出結論，適當的專案情報工作肯定會減少專案上的噪音，使交付更加及時，交付質量和價值更高。
在常見的外包環境中，大多數實現團隊（除了分析師和專案經理）是見不到客戶的，他們對專案的了解僅限於需求規格表、**、uml圖、時間表和測試資料。這對團隊的合作過程有什麼影響呢?
如果以這種枯燥的方式開始乙個專案，可能最後也能完成，但卻犧牲了故事的激勵作用，這是你要付出的代價。肯定，隨著日積月累，你的員工就會對自己的工作感到不滿意，信不信由你，無聊的感覺會逐漸滲入他們的靈魂，使他們開始考慮新的工作。
在關於領導軟體團隊的演講中，我經常問聽眾乙個問題，以深入挖掘他們的經驗，這個問題是：「當你開始乙個新專案時，做的第一件事是什麼?」過去得到的答案幾乎都與資源排程有關，幾乎毫無例外，比如能力規劃、預算、wbs和任務分配等等這些純粹的「管理」方面的東西。
問題是，在這些答案中就沒有「領導」技能，只有管理。這差別可太大了！我們以軍事來模擬，上一問題的正確答案是圍繞新目標激勵團隊，激勵他們做好工作的準備，做好承受一些壓力的心理準備。這就是所謂的「夫戰，勇氣也」。
怎麼做呢?其實很簡單：將實現團隊內部啟動會作為乙個讓每個人與新工作的業務層面保持一致的儀式。主要由專案經理、分析師或者是銷售人員向大家演講，目標是使執行小組能夠全面了解下面這些情況：
允許每個人提問、討論和發表意見，確保每個人都能參與其中。新專案是團隊和公司學習和發展的新機會，讓我們把握住把它做好吧。
當然，您將隨著任務分配進一步了解業務方面的細節。但要確保在**塊、草圖和一堆堆的**中別丟失了總體業務目標。
依我的經驗來看，這種方法可以讓團隊採取更好的行為，因此團隊績效：
採用了這個簡單的策略，你就可以和團隊和客戶一起，順利飛抵目的地。這，就是成功。
第一次交付的魔力：出其不意的原則
戰爭認為，確保勝利的密訣只有乙個，那就是：兵貴神速、速戰速決，或閃電戰，或出其不意，這些都是久經考驗的戰爭戰術！軟體專案要打的仗，不是關於摧毀的，而是關於交付的。
讓我們面對現實吧，沒有什麼比你的第一次交付更能定義你在客戶眼中的形象了。它必須非常有用、令人印象深刻、健壯、穩定和及時。它不必大而全，但是在包含所有功能之前，必須要滿足上述屬性。實際上，敏捷學派的精神就是明智地選擇正確的業務價值(roi)，然後規劃第乙個交付，我們應關心這個非常特殊的里程碑的質量和健壯性，在任何情況下都不應該妥協。
要知道它的風險巨大，如果你的第一次交付不能滿足這種期望，不論是進度還是質量，您的客戶就會佔了你的上風，貫穿整個專案週期：這種情況很難扭轉，必然會帶來許多不利於開發團隊的後果。
另一方面，如果您在第一次交付或sprint中成功地完成了不錯的演示，那麼請放心，您已經採取了正確的「領導」專案的立場，包括「悄悄地」領導了客戶，直到專案結束。堅持下去！
順帶提一下瀑布法的乙個缺點，或者說是關於交付的確定性學派的乙個缺點。瀑布開發通常提倡以較長的階段來構建和交付功能，並按階段反饋給客戶。除非你面對的業務非常非常的確定，比如你設計的產品要面向開放市場，而不是針對特定的客戶需求和時間表，否則長時間脫離客戶代表就會讓人沒了勁頭和熱情，讓大家越來越懈怠。
這就是你應該做的，迅速出擊！
既然提到了快速出擊策略，那肯定不能忘了強調交付過程中的乙個概念性事實，即我所經歷並稱之為「危險地帶」。它實際上是客戶從第一次付款到第一次交付合同產品之間的一段時間。
為什麼它很危險呢?
軟體本質上是無形的產品，你不可能馬上就得到它。即使我們討論的是套裝解決方案，實現和定製客戶的需求仍然需要延遲些時日，得人來做些工作。因此，它不像硬體或汽車，掏了錢就可以直接拿走，或者哪怕需要一些規定的交貨時間，但對於客戶來說需求仍然是有形的，可以從一開始就知道要的是什麼。這意味著，除非你按照客戶預先的期望安裝了第乙個功能塊，否則付費的客戶就感覺花出去的錢不怎麼值得了。
如果這段時間不斷地拉長，專案的風險就會呈指數級增長，你開始在客戶那邊覺得有些「力不從心」，這將反映在團隊身上，對專案產生負面影響。不幸的是，這種情況很難恢復。
構建軟體是一場為了贏得成功的戰爭。從簽訂合同到完成合同，會遇到變更、不確定性、客戶行為或其他團隊相關內部因素的風險，我們很容易受到這些風險的影響。
不妨從戰爭中借鑑一些戰術，這或許是處理這些風險的好辦法。
確保你完成了正確的「專案情報」練習，在參與專案之前已經了解了客戶。激勵你的員工，讓他們充分認識到自己所做的事情的價值，以及它對公司的影響和他們自己職業生涯的影響。用強大的第一次交付征服您的客戶，讓他默許你控制專案的其餘部分。將交付第乙個功能塊或危險區域的時間降到最低。
然後管理你的專案。
medhat sabry是一位軟體開發顧問、演說家和作家，經常出現在自己基於web的開發社群techstamina上，以及其他社交**和專業網路渠道上。他在軟體交付過程的核心領域工作了近40年，對開發行業**現的挑戰有深入的了解，這些挑戰激發了他的熱情，幫助開發人員和公司建立他們的專業耐力，以應對當今軟體市場中不斷增長的壓力和挑戰。
檢視英文原文：from wa***re to outsourced software development
從戰爭到外包軟體開發 如何贏得最後勝利
n n 軟體開發專案無疑是專案管理中最具風險的學科之一，天然會受到大量變更和不確定性的威脅，事實證明的確如此，我們的平均成功率低於其他更 確定 的業務領域。n我在這裡要向讀者們推薦一下chaos年度報告，自90年代中期以來這份研究報告在該領域就享有盛譽，它基於乙個資料庫，包含了20多年來收集的數千個...
從戰爭到外包軟體開發 如何贏得最後勝利
軟體開發專案無疑是專案管理中最具風險的學科之一，天然會受到大量變更和不確定性的威脅，事實證明的確如此，我們的平均成功率低於其他更 確定 的業務領域。我在這裡要向讀者們推薦一下chaos年度報告，自90年代中期以來這份研究報告在該領域就享有盛譽，它基於乙個資料庫，包含了20多年來收集的數千個各種型別和...
從戰爭到外包軟體開發 如何贏得最後勝利
軟體開發專案無疑是專案管理中最具風險的學科之一，天然會受到大量變更和不確定性的威脅，事實證明的確如此，我們的平均成功率低於其他更 確定 的業務領域。我在這裡要向讀者們推薦一下chaos年度報告，自90年代中期以來這份研究報告在該領域就享有盛譽，它基於乙個資料庫，包含了20多年來收集的數千個各種型別和...