3個軟體開發專案失敗的原因

更新於 發佈於 閱讀時間約 5 分鐘
raw-image

提及專案失敗,過往的專案管理課程通常的定義都是那些超過預定期限、超過預算或無法結案的專案。隨著時間的變遷,對失敗的看法也有了新的定義。於現今主流的專案管理思維上,重新把失敗定義為沒能產生預期價值。不管如何定義專案失敗,每年有很多專案也是面對失敗收場。

根據我多年從仕管理軟體開發專案的經驗,提出一些我認為對於這一類的專案來說,主要的失敗原因,以供參考。

缺乏優秀的產品經理

每位客戶都會有大大小小的需要或痛點希望滿足。畢竟沒有需求,就不會有專案。在嘗試滿足他們的需求之前,就必須要先了解他們各種的需要,以為後續決定打造什麼軟體作好準備。

我在此所指的產品經理,是需要在前線理解客戶需求重要的一員。他們有很多時候也需要身兼業務分析的角色,深入了解客戶日常的業務工作。同時,也需要理解對方在工作的過程中所有碰到的困難和挑戰。只有在了解清楚對方的基礎業務後,才能真正理解對方正在面對的問題,且能提供有意義的解決方案。

例如一位倉庫管理者能通過掃瞄貨品上的條碼記錄它們進出倉庫。但他在面對數量較多的貨物時,則需要花很長的時間來記錄它們,這導致貨品轉換的效率低下。

在真正理解客戶面對的痛點和需求後,則需要對需求作排序和整理。這一過程的困難在於,需求並單獨存在的。很多時候它會影響其他人的需求和現有的業務流程。

一位優秀的產品經理,則需要有能力釐清各個需求之間的關系。列如能得悉某兩個需要是互斥的,或看似兩個不同的需求,但其核心內容是重覆的。另外,他們還需要發現需求中間缺少的部份,這些部份通常是因為人在表達需要時,一定有所缺失或默認聽眾對某些內容已經有認知,毋需說明。但在欠缺這些默認部份的情況下,則可能嚴重影響後續軟體的開發。

另一方面,產品經理還需要知道軟體開發團隊的能力和極限。因為只有在知道限制在那裡的情況下,才能避免對客戶的需求過度承諾。另外也能誘導客戶往更實際的方向思考或提供更可行的解決方案,為客戶帶來價值。

縱上所述,我認為一位優秀的產品經理需要有方法能理解他人真實的需要,且有足夠的耐心和有條理的記錄和整理各種需求。要知道一個人的需求可能很簡單,但是一群的加在一起的需求就不是那麼的清晰的了。所以產品經理是為專案的最開始打下良好的基礎的關鍵,並成為後續軟體投入開發期間最主要的助力。

欠缺良好的軟體設計

一個良好的軟體設計,它能為軟體在投產及營運時提供支撐,並能穩定地為客戶提供服務。在面對未來不斷變化的業務場景,也能因為設計留有良好的擴展性和靈活性帶來幫助。換句話說,軟體設計就是建築界的設計圖。每一棟建築在施工前也必須把設計最好,才能實際投入興建。不然的話建出來的大樓可能東倒西歪,不能居住。

我覺得設計軟體和其他工程類的專案有很大的差異,工程類專案因為發展已經很長一段時間,某程度上已經有大量的設計軟體補助設計師們,如建大樓或橋樑等3D模擬軟體。另外業界也有大量的培訓課程,訓練設計師們如何設計各種建築。相對的,在軟體開發這一塊,相關的教學課程並不多,造成軟體分析和架構師較難學習何為良好的軟體設計。同時,能輔助軟體設計的工具並不多,更導至軟體系統設計的困難。

我覺得,某種原因可能是因為在編寫軟體的語言,存在太多不同的語言。有一些語言底層設計的邏輯可能分別不大,有些則完全不同。而且這些語言的發展速度極其迅速。架構的變化也愈來愈多。從早期的S/C架構到之後B/S架構到現在雲端架構,在設計上也會有不同。基於以上的理由,要支援這麼多元又複雜的環境並不容易。

當然,缺乏良好設計的軟體可能會在實際投入運營時帶來各種問題,而且軟體的工能愈多樣愈複雜,問題可能會更多,甚至可能會為企業帶來不必要的損失。我們在新聞上常聽到什麼資料外涉,某程度就是因為系統bug等原因造成的。

沒因應軟體專案特性選擇管理流程

軟體開發是一門極度複雜的科學。它千變萬化,像水一樣能以各種形狀填滿各種業務場景中間的空洞。因此,管理這樣一個千變萬化的東西,只有一套專案管理流程可不能有效的解決問題。專案經理必須要了解將要開發軟體的特性,應用適合的管理方法,才能為開發團隊帶來幫助的同時,同時為客戶帶來幫助和價值。

據我所知,現在發展出的專案管理方法已經有很多種。最為人所熟識的方法可能要數由PMI推出的PMBOK方法論。但這一套方法論要套用在各種軟體開發生命週期(SDLC)上則不是那麼容易。要知道現在的SDLC已經發展出多種不同的方法。如瀑布式方法,軟體在完成整個生命週期後一次性交付給客戶。另外也有每次只軟體交付一部份功能或特性的增量式方法。還有軟體開發專案最熱門的疊代式方法(又名敏捷開發)。最後有適應性 (Adaptive) 和極限開發 (Extreme),以上每一個方法都是為了解決不同的軟體開發場境而設計。

面對縱多的開發方式,專案經理能意識地為專案選擇合適的方法嗎?另一方面,企業在專案管理方式上是否具備足夠的靈活性,讓專案經理能在合規的情況下選擇最適合的方法?還是只有一套指定的管理流程,專案經理必須服從?

選擇錯誤的管理流程,可能會為專案執行帶來一定的麻煩。例如面對需求或方案不太確定的專案,在執行時必定會帶來大量的變更。雖然團隊可能不太喜歡變更,但是有可能有些需要是要到專案很後期,如完成整合測試並給客戶實際體驗時,才能知道。如果專案是以客戶價值為主的話,則必須需要變更。如果專案管理流程上對變更設置嚴格的變更控制流程的話,則團隊將會需要花費大量時間處理文件相關的工作,這些花費的時間並非實際地為客戶提供價值。

總結

以上我從專案開始、執行到管理方面,認為軟體開發專案可能帶來失敗的原因。希望每一位專案經理在選擇團隊成員的時候要注意,另外企業也不要忘記人材的培訓工作。畢竟企業是由人來運營的,只有成功的專案才能同時為企業自身和客戶帶來價值和利潤。歡迎大家留下你們的意見。

avatar-img
7會員
27內容數
閱讀是為了通過書本認識世界、獲取靈感和改善自己或身邊的人的生活。在此主要分享一些我自己從書中獲得的一些靈感、啟發、見解等內容
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
Seng Wong的沙龍 的其他內容
在這個資訊爆炸和愈來愈複雜的世代,瞭解管理的重要性能幫助你更有效率地完成任務。管理不僅適用於企業管理者,對每個有抱負的人來說都是必要的技能。透過管理技能,你可以更有效地進行時間管理和金錢管理,並實現個人生活和職場目標。
專案是為了人而存在,沒有人的話就不需要專案了。但要知道人是這個社會上最難管理的生物。和一般的職能經理有實權不同,專案經理在很多情況下是沒有多少權力的,因此更難以管理人的行為。專案管理知識體系 (PMBOK)指南第七版中,把「利害關係人」這個績效域放在了第一位,可見這個部份的管理跟其他部份的管理更為重
在這個資訊爆炸和愈來愈複雜的世代,瞭解管理的重要性能幫助你更有效率地完成任務。管理不僅適用於企業管理者,對每個有抱負的人來說都是必要的技能。透過管理技能,你可以更有效地進行時間管理和金錢管理,並實現個人生活和職場目標。
專案是為了人而存在,沒有人的話就不需要專案了。但要知道人是這個社會上最難管理的生物。和一般的職能經理有實權不同,專案經理在很多情況下是沒有多少權力的,因此更難以管理人的行為。專案管理知識體系 (PMBOK)指南第七版中,把「利害關係人」這個績效域放在了第一位,可見這個部份的管理跟其他部份的管理更為重
你可能也想看
Google News 追蹤
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
在專案管理中,如何有效經營利害關係人是確保專案成功的關鍵。這篇文章分享了一些技巧,包括識別利害關係人、設定期望、保持良好溝通及找到共同利益等策略,幫助讀者在專案中建立良好的關係,減少誤解和不必要的驚喜,最終達成專案目標。
Thumbnail
你是否曾提案要為客戶做許多事,卻得不到客戶買單或認同。 或是簽了約,客戶要你做更多事,或是與合約不相符? 據國際專管機構統計至少80%專案執行失敗,表示專案成功機率20%是偏低的,因為在一個充滿變數的商業環境中,如果你公司面臨著一個重大的挑戰。
與其體驗失敗,不如管理失敗。失敗其實有很多類型,而由於是親身體驗,失敗前後自己感受到的差異,很值得寫下來,記錄下來,接著去提煉其中得到的領悟,化成一些秘訣,教給後輩。以我在科學研究的經驗,失敗是一種,讓我的嗅覺變得更加敏感的寶貴經驗。很多研究的思路,一開始真的是死路,處處碰壁。
1. 完善計畫與靈活應變: - 很多人在做計畫時,會把一套計畫做得非常完美。然而,實施計畫時,總會有意外情況發生,使計畫無法順利執行。這時候有兩個辦法,一個是留下足夠多的餘量,可能是時間,可能是資源。另一個辦法,就是事先準備好B計畫,當局勢發展不如預期時,你可以依據這個替代計畫來應對。
「很多人做計畫都是把一套計畫做得很完美。」 「然而到了實施計畫時,總會有沒有預想到的情況發生,讓計畫無法順利執行。」 「這時候有兩個辦法,一個是留下足夠多的餘量,可能是時間,可能是資源。」 「另一個辦法,就是事先準備好B計畫。」 這幾句話節錄自吳軍老師矽谷來信3的內容[1],
Thumbnail
1.新創公司失敗的十大主因: 產品與市場需求不符 資金不足 團隊不和 行銷策略失誤 競爭對手太強大 法規限制 管理不善 擴張過快 缺乏創新 時機不對 2.每個失敗原因都附有國際和台灣的實際案例 Segway和HTC 3D手機(產品與市場需求不符)
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。
Thumbnail
無限學院的為期一年的專案到接案沒達標 - 2024.05.06 2023.08.11 ## 目標/期待 * 做出一個「網站」,能狗做到「分析數據」 * 想先做練習* 以求職的來說的話,想往「數據」分析的路走* R 語言: 語法* Tableau(商管):* 後端: PHP + SQL
Thumbnail
這篇文章探討了在軟體開發中的技術債可能來自哪些原因,以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇,提供了對於技術債的思考與建議,針對開發人員在需要做出無奈的技術決策時,提供了一些建議。此外,還提供了一些在做出技術決策時的方法,如保留抽象層和避免vendor lock-in。
Thumbnail
這篇文章探討了在專案開發中遇到的時間壓力和執行困難,以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
在專案管理中,如何有效經營利害關係人是確保專案成功的關鍵。這篇文章分享了一些技巧,包括識別利害關係人、設定期望、保持良好溝通及找到共同利益等策略,幫助讀者在專案中建立良好的關係,減少誤解和不必要的驚喜,最終達成專案目標。
Thumbnail
你是否曾提案要為客戶做許多事,卻得不到客戶買單或認同。 或是簽了約,客戶要你做更多事,或是與合約不相符? 據國際專管機構統計至少80%專案執行失敗,表示專案成功機率20%是偏低的,因為在一個充滿變數的商業環境中,如果你公司面臨著一個重大的挑戰。
與其體驗失敗,不如管理失敗。失敗其實有很多類型,而由於是親身體驗,失敗前後自己感受到的差異,很值得寫下來,記錄下來,接著去提煉其中得到的領悟,化成一些秘訣,教給後輩。以我在科學研究的經驗,失敗是一種,讓我的嗅覺變得更加敏感的寶貴經驗。很多研究的思路,一開始真的是死路,處處碰壁。
1. 完善計畫與靈活應變: - 很多人在做計畫時,會把一套計畫做得非常完美。然而,實施計畫時,總會有意外情況發生,使計畫無法順利執行。這時候有兩個辦法,一個是留下足夠多的餘量,可能是時間,可能是資源。另一個辦法,就是事先準備好B計畫,當局勢發展不如預期時,你可以依據這個替代計畫來應對。
「很多人做計畫都是把一套計畫做得很完美。」 「然而到了實施計畫時,總會有沒有預想到的情況發生,讓計畫無法順利執行。」 「這時候有兩個辦法,一個是留下足夠多的餘量,可能是時間,可能是資源。」 「另一個辦法,就是事先準備好B計畫。」 這幾句話節錄自吳軍老師矽谷來信3的內容[1],
Thumbnail
1.新創公司失敗的十大主因: 產品與市場需求不符 資金不足 團隊不和 行銷策略失誤 競爭對手太強大 法規限制 管理不善 擴張過快 缺乏創新 時機不對 2.每個失敗原因都附有國際和台灣的實際案例 Segway和HTC 3D手機(產品與市場需求不符)
Thumbnail
這篇文章描述了作者從兼職開發轉為全職開發的過程,並分享了從混進學界指日可待的積極態度。作者也提及自己在專案製作與個人生活上的矛盾與感想,最後分享了專案管理和敏捷開發相關的文章與影片。
Thumbnail
無限學院的為期一年的專案到接案沒達標 - 2024.05.06 2023.08.11 ## 目標/期待 * 做出一個「網站」,能狗做到「分析數據」 * 想先做練習* 以求職的來說的話,想往「數據」分析的路走* R 語言: 語法* Tableau(商管):* 後端: PHP + SQL
Thumbnail
這篇文章探討了在軟體開發中的技術債可能來自哪些原因,以及如何自動化偵測與修復技術債。作者透過分享不同情境下的技術債選擇,提供了對於技術債的思考與建議,針對開發人員在需要做出無奈的技術決策時,提供了一些建議。此外,還提供了一些在做出技術決策時的方法,如保留抽象層和避免vendor lock-in。
Thumbnail
這篇文章探討了在專案開發中遇到的時間壓力和執行困難,以及如何無效應對這些挑戰。 沒有工時估算、客戶溝通、交付時間表設定、程式品質管理、工作量管理、合同和專業態度等方面的建議。