關於軟體開發

對於乙個處在組建的軟體技術組織來說，的確有很多的問題，這包括來自目標專案的和組織內部的。

就乙個成熟的軟體工程組織來說。

首先，她應該確定自己的技術規範，採用什麼樣的軟體工程模型將直接影響專案的過程和結果，如採用的是瀑布式的軟體模型，這實際上也是大多數開發小型專案（更準確的說應該是一些小的程式產品）的一般做法，它由需求開始，然後是分析、設計、程式設計、測試、交付。

的確，軟體開發也確實是按照上述過程實現的。但是，對於乙個中型或者以上的專案，問題的凸顯是嚴重的，因為這種模型，無法控制質量、週期、資源和風險等因素的折中。我們開發所依據的需求在整個專案的進展中是不可能一成不變的，絕大多數的需求蠕變瀑布模型是無法控制的。這樣的最終結果將導致使用者無法認可專案產品的可用性。然後，分析設計、編碼實施、測試是乙個根據專案規模有著相當時間週期的工作，這是規律性的東西，在環境條件的限制下是無法改變的。在這個過程中你能保證客戶的耐心和支付的信心嗎？這個問題將直接導致專案的資金風險增高。僅僅這兩點就足以使專案流產或者失敗。

乙個成功的專案應該有乙個明確的技術規範體系指導下工程模型構架，這一點是保證專案成功的決定性因素，這遠比幾個個人技術能力超群的程式設計師重要。

在這樣的指導思想下，團隊的結構因該是多層次技術人員和管理系統結合的綜合體。他要求人員不但具有一專多能的技術素質，同時更為重要的是他們必須是規範化技術體系的一部分，這才是高效團隊的基礎。現在很多的軟體組織無法達到這種團隊要求，就將團隊的效率的提高的希望寄託在行政管理上，這也是我國計畫經濟體制留下的最頑固的管理方式，將乙個無論什麼樣的單位或部門以一種類似集中營的形式進行管理。這種管理的弊端我不想多說，您可以在任何一家倒閉的國有企業裡找到最好的答案。

軟體工程改進很多公司都在喊，但誰都無法實現。好多公司都是在技術組織組建初期，沒有建立乙個科學的技術規範體系，隨著專案開展，結果造成個人積累遠高於組織積累，最終導致由於個人處於利益的原因使得規範化切入受阻，從而使企業的技術體系建立失敗。這可以看成是失敗過程管理的典型案例。其他公司要好一些嗎？就我所接觸，很難說。這是回答普遍性問題的開始。

這個問題，我想我們看看國外就可以有些感悟了，在美國這樣的資訊化發達的西方國家，他們的規範化執行的很好，為什麼？你可能要說，他們的情況不一樣，人家素質高，對人身對價值的理解不同，而且他們的環境多好呀。我們能比嗎？這些回答有一些是不無道理的。但是，這些回答沒有找的核心問題或者說本質所在。從我在國外的同學和親戚，從事軟體工作的情況來看，他們並非比我們更具有很高的覺悟，況且，覺悟這個東西，在這裡並不起什麼作用，他們環境好，這是事實，的確他們的環境很好，但是，並不只是硬環境，更重要的是軟環境。他們工作的回報是可以為自己獲得持續的物質獲利的，更直白一點，他們每參與乙個專案，成果中就擁有屬於自己的產權部分，這些都是要體現持續效益的，所以我們才聽說美國有很多軟體金領，他們工作到35歲退休時已經躋身富人圈了。這與我國的科技企業職務科技成果歸屬有著本質的區別，人家35歲退休到了我們這裡被扭曲成了「高軟體的技術壽命是35或者30歲，之後就沒有靈感了」，可笑之極。

現在你知道人家為什麼會自發知覺的去執行規範化技術體系了吧，因為組織的目標就是他們個人的目標，他們不會在一些個人積累上有所保留，因為組織目標的加快實現，可以促織個人目標的加快實現。我們身邊的組織可能做到嗎？在國內一些公司不厭其煩的重複著過河拆橋的過程，需要技術的時候找幾個人，東西一做出來立馬就炒人。技術人員們不得不從乙個技術成功中被提出來，又進入下乙個零起點。所以才有那麼多的跳槽。個人積累在這種情況下才變得如此的重要，使得很多的技術人員在工作中技術的交流表現得那樣的諱莫如深。

在這樣的大環境下，什麼軟體過程、up、xp、技術文件、專案管理、規範化體系統統都只能流於形式。所以在csdn中才有了code與程式設計師隱私的話題。所以才有評估國內erp實施結果，失敗的多成功的少。

如果，你將公司的技術團隊交給我管理，我將首先確定公司的技術規範和過程體系，然後根據這種體系結構的角色要求去物色人選，當然不一定很多人，這要求被選中的人可以擔當不同的角色，為保證專案順利成功的實施，我必須獲得激勵和懲罰人員的權力和資源。而且這些都因該是可持續的。

先就談這些吧，相信我們還有很多的交流機會的。

關於軟體開發

關於對日軟體開發

關於敏捷軟體開發

關於軟體開發「隱喻」

關於軟體開發

關於對日軟體開發

關於敏捷軟體開發

關於軟體開發「隱喻」

相關推薦