一個歷時3年的專案失敗記錄 (轉)
我們專案組主要進行某種終端產品的開發,以這個產品搭配現有的形成一個通訊平臺,在這個通訊平臺上可以做很多的應用。我們這個產品的整套方案是從國外一家公司買過來的。下面稱它為BET公司。該產品還是屬於比較先進的,國內雖然也有一些廠家能生產,但一般以半成品組裝的形式,而我們可以拿到評估電路版和大部分,做一些專門的應用。整個專案歷時3年,我是在專案進行到一半的時候加入的,到最後沒有看到專案的成功商用。總結了一下,覺得有很多教訓。
和方案供應商溝通不善
BET公司提供的原始碼中有不少,在開發過程中造成不少問題,我們也向BET反映過,但是一直沒有得到解決,相反,BET只顧不斷追著我們付清費用(技術支援費用 or 解決方案費用),有大概6-7個月的時間,在技術支援上和BET公司一直處於糾纏狀態,沒有得到任何形式的技術支援。我記得有一段時間最後,BET公司和我們的來往中都是要錢--不給,要求先解決問題這些僵局中。到後來產品差不多完成了,bug不知為何又不用理睬了,我也不知道後文怎樣。
這個問題我想不能簡單的推到某一方身上,也許是因為雙方溝通不善。
計劃無序,疲於應付
到今天我一直沒有明白,我們專案組的這個產品到底是什麼時候成熟的。在去年年底和今年春節過後的一段時間,我變得突然非常忙。因為那時候要把產品給客戶演示,那時候通宵達旦的加班,苦不堪言。我以前也算是一個工作狂了,可到最後一次我開始對工作失去興趣。我覺得整個專案組似乎沒有一個演進計劃,產品一直沒有處於一個成熟階段,每次都是客戶說,我要這個功能,然後就開始拼命的加上這個功能。而沒有對產品有一個比較明確的目標。
後來和另一位同事,他認為,到了專案後期,來電諮詢的客戶不少,可一直沒有出現第一個成功的案例。歸根到底,領導一般不願意先進行投入產出一個比較成熟的產品,而是一味的依賴著手中的並不是很成熟的產品希望可以先談上一個訂單,這其實也是一個通病,公司沒有相應的激勵機制,看不到前景,一般人都不願意投入,這又扯遠了。
極大的人員浪費
一個team大概35個人,分為、,硬體部分分為2個小組,大概有14人左右,軟體部分則分為3個小組,共23個人,其中有2個小組共14人左右,他們先是分別在做兩個極富前瞻性的子專案RP和RW,在國內外的通訊市場上,這兩個子專案本身都是非常龐大的,許多公司都是投入數百人和極大的物力進行研究。而且國內還沒看到這兩個子專案有大規模商用的需要,我不知道在這個專案組裡出於什麼目的啟動這兩個子專案,最後,這兩個子專案的“原型”是做出來了,只是1個純粹演示用,在PC上執行,脫離了真正的硬體平臺,開發人員除了熟悉一下語言和外一無所獲,另一個我一直沒見過它的真面目,據瞭解也是沒有實用性,做了等於沒做,僅僅是熟悉了一下BET的方案,沒有任何實際用途。
後來我反覆為這兩個子專案尋找理由,我認為這可能是整個公司和專案組的機制造成的。首先,它是一個屬於預研性的專案,在啟動之初是不是沒有市場壓力?所以會啟動這兩個子專案?但是,這個理由很不充分。
產品定位不明確,層出不窮的新想法
專案組有過1年多的延期,最開始我們做的是一個具體的產品,一個具體的通訊平臺,到了後來,覺得這個市場很有限,於是轉做這個通訊平臺上的應用,由賣具體的平臺轉移到賣這個平臺上的應用,再到後來,扯上了整合的問題,還要賣PC上跑的相關的軟體系統和各種亂78糟的東西。實際上,PC上跑的那套軟體系統只有一個人做,和外面那些專業的公司在某些方面有一定的差距。在和客戶討論時,一會兒說我們這個目前這套系統是演示用的,我們主要賣通訊平臺,一會又說,當然,我們也能做整套系統(只要有訂單...)到了最後,我們又開始將這個通訊平臺上的開發工具作為一個賣點,折騰來去,還是沒拿到訂單。
有一次陪著專案組經理和主管這個產品的市場經理討論,他說了一些很難聽然而確實很實際的話,我不管你能夠做什麼,我知道你什麼都能做,問題是你要把東西拿出來,然後我才能去賣...
話又說回來,除非經驗非常豐富的專案經理,擁有軟硬體各方面的經驗,同時又要對該行業、市場比較瞭解,否則,很難對產品定位做出一個結論的,市場定位常常是在實踐中不斷演進。領導者要儘自己最大能力,預測到可能會出現的情況,做到心中有數。
開發中存在的問題
有一次,我們和外地的一家公司合作開發一個應用,在完成這個應用的2個月後,我再次測試這個系統,發現對方的協議莫名其妙的已經更改了。我轉去問team裡的一個介面人員,他說上一次測試的時候發現協議有問題,一個符號傳不出來,改成用2個符號來傳,所以就臨時更改了,也沒通知我。
我們先後和很多第三方廠商合作,應用軟體、協議都是根據要求一改再改,非常煩人。一些常見的情況,協議的欄位起始位變化了、協議要進行擴充,在後面多加上一些內容,更煩人的一些情況,相同的應用系統,幾個第三方的廠商的協議是完全不同的,所以要做好幾套協議解釋,我當時沒有預料到這種情況,後來改協議的時候都是一邊在改,一邊在咒罵。一開始如果就預計到這種情況,把協議做成的方式,想用那種就用那種。不過這也是迫於無奈,目前我們的產品還沒有實力去要求別人接收我們的東西。
沒有人在初始開發的時候就能看到產品最終的樣子,制定好詳細的計劃,所以我們遇到的問題幾乎都是不可避免的,我們唯有想方設法去降低問題的機率。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-991777/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一個失敗專案的專案筆記(轉)筆記
- 記一個失敗的專案
- 一次失敗的專案經歷以及反省
- 一個SaaS專案失敗的原因 從個人角度覆盤專案失敗的5個重要原因
- ERP專案失敗的原因(轉)
- 專案失敗五宗罪(轉)
- 記一次專案談判的失敗經歷,要拒絕免費開發!
- 記錄一次刪除檔案失敗的問題
- 專案交付為什麼失敗?-記我在某個專案中的迷思
- 失敗的敏捷專案敏捷
- 記一次GI安裝失敗(root.sh在第一個node上失敗)的除錯經歷除錯
- 軟體專案失敗因素分析(轉)
- ERP專案失敗的四個非技術性陷阱(轉)
- 大學裡面的幾個失敗專案
- 記一次 Valet 安裝失敗記錄
- 專案團隊管理的失敗經驗(轉)
- 專案失敗並非如想象般普遍(轉)
- 專案研發為什麼失敗?(轉)
- 專案失敗並非如想象般普遍 (轉)
- 糟糕的範圍管理導致專案失敗(轉)
- 軟體開發專案失敗的3個原因
- 避免專案失敗的六個基本關注點
- 一保健品專案運作失敗的原因和啟示(轉)
- Drone構建失敗,一次drone依賴下載超時導致構建失敗的爬坑記錄
- 那些騰訊投資失敗的專案
- 軟體開發專案失敗原因分析(轉)
- 專案研發為什麼會失敗?(轉)
- 記錄一次失敗的騰訊前端實習生電面前端
- 誰應該承擔專案失敗的責任?(轉)
- SpringBoot專案引入Elasticsearch時啟動失敗Spring BootElasticsearch
- 機器學習專案失敗的9個原因,你中招了嗎?機器學習
- 盤點敏捷專案失敗的6個主要原因敏捷
- 準備的一年的專案上線失敗
- 記錄一次C語言中free(p)失敗C語言
- 專案失敗的十種徵兆
- 【docker】記錄一次nginx啟動失敗的檢測DockerNginx
- 記錄一個新專案遇到的 MySQL 問題MySql
- 其中一個mview失敗,一個命令來剔除失敗mview的所需的logView