盤點軟體開發專案的 10 大失敗原因,其中一個就是「你訂了年度計畫」

【為什麼我們要挑選這篇文章】有不少的軟體開發專案最後以失敗收場,但深究原因,通常不是技術性或是沒有人才的問題,而是專案管理的方式。以下,是軟體專案失敗的 10 個失敗原因。(責任編輯:郭家宏)

本文是能夠揭示技術遷移和解構專案背後真相的系列文章之一。

作者在過去三年裡參加過幾個 BIG REWRITE™、DECOUPLING™ 和 SCALABILITY™ 專案,在此,作者決定分享眾多類似專案失敗的原因,希望此文可以幫助讀者及早發現軟體開發過程中的不良趨勢,讓大家引以為戒。

所以,軟體開發的夥伴們,快來看看自己中槍沒有!

火燒屁股後才開始招募

在專案半途擴充團隊成員以求求工作效率的立刻提升,這簡直是一個瘋狂的想法,就好比房屋失火時才開始買保險,以希望保存已經被大火燒燬的傢俱一樣不切實際。

請記住,團隊中每增加一名新成員,現有團隊中就會有一名老員工的工作效率降低一半,而且這一種現象從新員工開始入職時便會發生。此外,根據 Tuckman 的團隊發展階段理論,每當有新成員加入團隊時,團隊還會經歷組建期(Forming)、激盪期(Storming)、規範期(Norming)和執行期(Performing)這第四個時期,甚至每次新成員的加入都會使團隊使重複經歷這樣一發展階段(期間有不同的矛盾衝突點需要領導者分階段協調)!

沒有調動起團隊全體成員

當只有一小部分人(通常為「架構師」)來單獨決定使用何種技術棧時,你的專案就會陷入困境。這就是為什麼管理層最終會抱怨團隊失信:架構師可能選了最好的技術棧,但如果沒有整個團隊的參與,再好的技術也無法實際部署,就好比身體在接受不相容器官之後的排異反應一樣,而且情況只會變得更糟。

如果技術棧是由業務人員基於一些流行詞甚至和商務夥伴那兒聽來的流言所決定的,那基本上一連串諸如「這不是我的工作」、「跟你說了這樣不行」、「用另一種做好多了」或者「這是老張的錯」的抱怨即將向你湧來 — 切忌拍腦子做決定。

我的建議:如果團隊需要對結果負責,那麼請將決策留給團隊進行。切記!

缺乏規劃

計劃不足便意味著走向失敗。
——一個比我博學的人

我認為這種行為通常發生在「放飛自我型」的軟體開發人員身上,他們認為寫程式碼更像是一門藝術而非工藝,無需詳細計劃。不過,這種情況不止發生在開發人員身上,截止 2018 年,仍有一些商業人士相信他們「就差一個工程師了」,他們認為只要有了個想法和開發者,他們告訴開發者做什麼他們就會做什麼。

你不懂!

軟體開發者可不像是鐵匠。鐵匠可能會面臨著使用材料的品質、煤的品質或工具品質方面的不確定性,但軟體開發所面臨的不確定性要高得多。軟體開發人員首先需要明確需求,尋找解決方案,驗證解決方案,最後執行並實現——就為了一個需求,他們可能需要一次又一次地重複這個過程。

不堅守決定

專注(FOCUS)就是堅守一條道路直到成功)
——羅伯特.清崎

亨利.福特(福特汽車公司的建立者)的決策原則要點是切忌延遲下決策,要能夠快速做出決定;而一旦做了決定,就不要再改變主意——頻繁變卦會導致整個團隊事倍功半並最終把任務搞砸。下定決心吧!

與其做個半成品,不如做好半個成品。
—— Jason Fried,《Rework》

堅守錯誤的決定

人們在決定是否去做一件事情的時候,不僅是看這件事對自己有沒有好處,而且也看過去是不是已經在這件事情上有過投入,這是典型的沉沒成本謬論。因為「我們已經投入了很多 xx」(已經發生不可收回的支出,如時間、金錢、精力等沉沒成本),或者「我們一直都是這樣做」而無法放棄糟糕決定是一種無能的表現,也是一種來源於擔心對決策失誤做負責、並堅持繼續往錯誤方向前進的危險行為。

這注定會將會帶領團隊陷入一次死亡之旅。

陳詞濫調的雞湯時間:

請記住,無論你在錯誤的道路上走多遠都要回頭;即使你選擇了正確的道路,如果你站在那兒什麼都不做,你最終都會被超過。

缺乏人員規劃

如果沒有人員規劃,核心人員最後會偏離他們的原始職責而去處理一些無計劃、無法預料且最無關緊要的工作。如果團隊人員編制已滿,那麼還是要對參與專案的應有人數進行一些現實的規劃。如果專案計劃是遷移一個成熟的應用,那麼魔數(人們拍腦子想出的數大多為 3/4/7)在這裡可不管用,隨便挑個數字都不會讓你更接近你的目標。

逃避心態

逃避心理會讓你矇蔽雙眼,假裝什麼事情都進展順利;你會逃避一些顯而易見的事情,即使它們就在眼前;它還讓你忽略了兩個星期後的專案 DDL(死線),而你其實已經落後兩個月的工作量了。儘早迎難而上,軟體開發不應該像潘普洛納奔牛節一樣——不要去躲避那些公牛,因為它們最終會趕上你並把你頂翻。

如果你真的有所顧慮,就讓你的開發人員提出問題,這些開發員可擅長抱怨那些最微小的變化了。如果你培養了一種公平、公正且人人都有機會發言的開放性企業文化,無論問題有多敏感或是誰導致了這個問題,你的開發人員都會聲嘶力竭地向你提問,尖叫著跟你說「天要塌了」。

計劃太遠

當只有兩個月的路線清晰度時,卻計劃了一年的工作量。

一年的計劃只是個幻想。你可能年初時覺得你什麼都安排好了,但等情人節再看看吧——你會開始希望你的計劃更靈活一些,團隊更適應一些了。為什麼就不給自己省些麻煩,就只做一季度的計劃呢?在作者看來,一季度是計劃的最佳時間。此外,設定季度目標意味著你更有可能實現這些目標,因為你將處理的不確定性更少,並且你的目標會更加現實。

試著在專案管理中進行一整年的工作規劃,並像你計劃建造房屋一樣規劃軟體,這完全就是一種浪費。

如果颶風來襲了呢?

如果伊隆.馬斯克決定接管網路並創建一支殭屍機器人軍隊呢?

如果你部署產品的唯一選擇,是將你的應用程式裝入一個外接硬碟並帶到亞馬遜的數據中心呢?

如果為了做到這一點你必須和馬斯克的殭屍機器人軍隊搏鬥呢?

這些都是合情合理的問題。同樣合理的還有「你認為它要花多長時間?」或者「我們應該在這個用戶故事中加多少個故事點呢?」。

你不是在建房子。房屋設計很容易,因為一切都已完成,你只需挖洞添點膠水,然後把房屋的每個部分放在一起就搞定了。但使用軟體時,你甚至得先創造個想要挖洞的位置,然後才能進行後續操作。

房屋建造和軟體開發的唯一相似處是在術語上,應用實際概念時卻大相逕庭。你不會在建房時中採用疊代策略,否則你就是在建一座新房,而且只有在拆掉舊房的情況下你才能建造一座新房子。

不要再因為「你需要交付了」或者「你在獲投可以重構程式碼」這些原因而去建構那些非模組化且架構得亂七八糟的破爛軟體了,後患無窮!

我不是說單片軟體(非模組化)很糟糕,但一個模組化的整體結構在短期內比你找到的任何基於微整合服務的無價值工作運轉得更好。但你建構之前要多考慮,使用個合適的前端框架,選個符合你需要的 UI 庫並徹底對他們徹底瞭解。

錯誤衡量

我不打算談論具體的測量方法,畢竟這個必須由讀者自行決定。無論程式開發速度還是產品推出時間,你應該客觀地評估你的當前情況,並基於此找出你需要衡量的標準。

在此舉一個有關錯誤衡量的個人例子。

我們假設我的目標是增加我的電子郵件訂閲者數量,那麼我就不應該太關注網站訪客量。如果我開始瘋狂地關注後者,那麼幾個月後我就會覺得我已經非常受歡迎了,並且我就會像已經擁有更多的電子郵件訂閲者一樣生活——大多數崇拜幻想世界故事的人都是這樣生活的。但反過來,我其實也可以查看我的訂閲者列表,從而注意到沒有任何訂閲者數的進步,接著會查看訪客量,結果發現網站上其實很多人瀏覽但沒有訂閲,從而便可以繼續探求瀏覽者不訂閲的原因。

過程太過僵硬

據我的經驗,發生這種情況是因為人們過於死守交付流程,但實際的關注點應該在於交付的內容,許多使用 SCRUM(敏捷開發)的團隊也在抱怨它太死板了。在我看來它的確有些僵硬,但不乏一些主觀性的偏見存在。其實客觀來講,任何敏捷的開發流程都具有很強的適應性和靈活性,但我們的天性就只是照搬書中的所有內容(特別是當我們被規則馴化後),從而使得一切都看起來非常僵硬。

正如 Vasco Duarte 在他的作品《No Estimates》中所說:「建造軟體就跟疏通浴室管道一樣——為了把廁所修好你還得再建三座房子。」軟體開發的本質就是當你準備好解決一個問題的途中,還發現了其他三個問題需要解決。在 Quora 上有一個很好的類比,擁有近三十年軟體開發工作經驗的 Channing Walton 借用「泡茶」形象,闡述了軟體開發過程的艱辛。

Q:我該如何向一個非軟體從業者解釋軟體開發過程有多複雜、多耗時、多易錯?

A:讓他們描述製作一杯茶所需的步驟,他們可能會說:
1. 燒水
2. 把茶放進鍋裡
3. 將水煮沸後倒入鍋中
4. 等 5 分鐘
5. 把茶倒進杯子裡
6. 往杯子里加牛奶
7. 喝掉

接下來便是最有趣的部分,你需要開始繼續問這些問題:
燒水?那麼:
水來自哪裡?
水壺在哪裡?
你怎麼把水倒進水壺裡?
你怎麼知道多少水放入水壺裡?
沒有水/水壺/電的時候怎麼辦?
如果填滿感測器出現故障(溢出)怎麼辦?
如果沸騰感測器出現故障怎麼辦?

把茶放進鍋裡?那麼:
鍋是在哪裡,如果沒有鍋怎麼辦?我們應該在煮沸之前想到這個問題嗎?
茶在哪裡?是哪一種茶?我們是否應該先問一下,如果我們沒有合適的茶該不該繼續這麼做?以及關於溢出和感測器的類似問題怎麼辦?

倒開水?那麼:
你確定它在沸騰嗎?怎麼能確保澆注的機器從水壺中得到正確的“完成”信號?
你怎麼確定機器倒酒器知道鍋的位置?
如果在傾倒期間鍋翻倒怎麼辦?

諸如此類的問題,你可以繼續問上幾個小時,他們會感到無聊並說:「這種程度的細節考量是愚蠢的!」此時你的目的就達到了,你只需要微笑點頭說道:「是的,但整個(軟體開發的)過程的確就是這樣。」

原文 傳送門

(本文經合作夥伴 大數據文摘 授權轉載,並同意 TechOrange 編寫導讀與修訂標題,原文標題為 〈细数重写大型软件失败的十大原因 〉。首圖來源:Pxhere CC Licensed)

更多關於寫程式與專案管理的技巧

只懂摩爾定律就 low 了!軟體工程師還必需知道這 5 項定律
軟體工程師的職涯該如何發展?AppWorks School 校友要跟你講 3 個熱血故事
台灣正缺軟體工程師!新鮮人年薪中位數破 70 萬台幣,但他不能只會「寫程式」


我們正在找夥伴!

2019 年我們的團隊正在大舉擴張,需要你的加入跟我們一起找出台灣創新原動力! 我們正在徵 《採訪社群編輯》、《助理編輯》,詳細職缺與應徵辦法 請點我

點關鍵字看更多相關文章: