【編者按】互聯網行業一夜之間變富翁的事件不足為奇,但是失敗的案例也比比皆是。 因此,如何管理好軟件項目儼然成為人們口中經常提及的話題。作者 Harri Paavola發表了《 軟件項目為何失敗?》這篇博文,筆者從中摘譯了一些。我們一起來看下:
所謂“失敗”也就意味著與他們的預期不一致。”失敗可以分為三種:
以上三個問題,很難說其中一個問題凌駕于另外兩個問題之上或者說某個問題更為常見。
缺乏遠見和權力
幾年前,芬蘭最高的一座公寓樓就建在了我家附近(與其他城市最高的建筑物相比,這并不算高)。左邊呈現的這幅圖是當時參與競賽的設計圖,而右邊的則是實際呈現出的效果。
建筑行業VS.軟件行:舉個例子,目前房地產很火,造什么樣的房子,只要資金到位,都能保質保量的造好。造10層樓,1層用多少人,每天做什么,很容易計劃,分配任務,人力資源,而且需求是不會變的。沒見過造房子,蓋了3層之后改主意了,拆了重新蓋。而軟件就大大不同了,需求的變化是不可避免的,而且凡是做過項目的人都知道,需求的變化實際上還挺頻繁。這樣一來,很容易造成計劃趕不上變化。
當工程項目拖延了工期,可以多加人手,把工期趕回來。而軟件就不這么簡單了,新來的人要熟悉項目的內容就要花時間,工期很難完全趕上。很多IT的老總們體會不到這個問題,總以為多加人手,加班就能搞定。真正的有效的項目管理是要靠一個有效的管理體系來支撐的。
糟糕的開始
許多產品還未完成就被叫停了,這跟產品負責人也有關系。那么,在什么情況下會挑選下一任產品經理來負責該項目呢?――原先的產品負責人不喜歡該產品,對該產品毫不在乎。
當產品負責人對產品沒有強烈的欲望時,那么他對產品的質量也不會有太大的要求。如果長期目標威脅到短期目標(獎勵機制),他會以快速且不負責的心態完成,如此一來,產品功能也跟著下降,最后呈現出的結果差強人意。比如Nokia推出的手機以及Windows Vista系統,事實表明,很少有人愿意為此而買單。
管理人的軟弱
軟件開發,尤其是在管理層上,包含大量的政治色彩。有時,高層管理不會讓產品負責人追逐他們的夢想。這現象很普遍――不讓新的產品蠶食老產品。高層管理人無法接受這樣的市場蠶食。長此以往,我們所擁有的都是些殘缺的產品。不僅如此,有時其他產品負責人當看到新產品會吃掉現有產品的銷售份額時,他們也會發動反擊。當然這種行為建立在獎勵機制上,銷售下降,獎金也會跟著下降。
產品負責人的無能=產品的失敗
如果產品負責人對產品沒有強烈的責任心,那么該產品必定是失敗的;如果產品負責人沒有為公司制定夢想,那么產品失敗;如果產品負責人敵不過其他產品負責人,那么該產品也是失敗的。
發布壞的、不完整、不合適的代碼
蘋果公司發布的" goto fail"就出現了Bug,這個bug會引起中間人攻擊,bug的描述中說,這個問題是因為丟掉了對連接認證的合法性檢查的步驟。就這因為這個Bug,所有 iOS設備與SSL有關的都出現了漏洞。Goto Fail成為一個經典事件。(這里推薦閱讀酷殼網陳皓的這篇 Bug解析)
開發商的莫不關心
很多開發者不使用任何靜態分析工具以及不執行任何代碼審查過程,儼然已經成為一種普遍現象。從代碼技術層面來說無需進行高質量的代碼審查就意味著該團隊中的每一個成員都能編寫出高質量的代碼。很明顯這種假設是錯的。
實踐證明,大多數團隊中至少有一名開發者無法真正做到高效編程。因為每個人都會有心情不好的時候,當某個人意志薄弱時難免會出錯。
每個人都想成為老好人
即便在代碼審查過程中發現了錯誤的代碼,很多人還是選擇隨它去了。這是因為每個人都想充當老好人。而通常這類錯誤的決定以及誤解都是由同一類人造成的。
當審查者查找出錯誤,哪怕是有一丁點錯誤也不放過,長此以往這就使得審查者與開發者之間不再和諧,開發者認為審查者是在故意找茬,兩者的矛盾慢慢就會產生。(推薦閱讀: 測試者和開發者,為何我們不能友好地相處?),審查者自身也認為這樣顯得太過苛刻,于是他們給自己放松了標準。
開放但不等于成功,滿足用戶所需才是最重要
盡管微軟在Windows 8上注入了大量心血,但其市場份額并不理想,業界對此也褒貶不一,很多用戶認為Metro界面和老的桌面體系并存,但融合的卻不那么平滑,有種非此即彼的分裂感覺。
這里還有兩個原因,筆者一句話帶過,即不聽――大多數不去輕易的嘗試產品,不愿傾聽別人的反饋;不問――大多數人不會主動去問別人意見。寫在最后
產品失敗存在很多因素,只有做到做到面面俱到,方可在軟件開發領域分得一杯羹。
英文出自: page
下一篇 如何選擇適合自己的編程語言